Unidentified subject!
P.Lister@cranfield.ac.uk
Tue, 10 Jun 97 18:10:27 +0100
> I agree that this is often the primary requirement for the user, but
> a form which has an HTTPS: action doesn't appear secure to the user unless
> the browser cue (e.g., the unbroken key) indicates that the page
> containing the form is secure. Security is pretty confusing to the
> average user anyway and every idea I've come up with for starting the
> secure path with the submit has quickly broken when I look for
> vulnerabilities.
While I have as much faith in users understanding security as you,
most people get the difference between signed vs unsigned and
encrypted vs plaintext. The whole point is to tell the user that the
form she's about to fill in can be trusted (even if it wasn't
encrypted), but that the data she's about to upload WILL be encrypted,
just as banks will happily dish out application forms for their
products to anyone and everyone, but the completed forms should be
treated as confidential. To be regarded as genuine, a certificate
chain must still connect the form back to a certificate that the
browser trusts, even though the actual form itself may have been
pulled from a cache. The certificates can cached with the form or
independently like PGP keyservers.