[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Discuss comments on draft-ietf-pkix-logotypes

Steve & Margaret:

Actually, I do not agree. Clearly, the application relying on a certificate should not trust the information in a certificate that cannot be validated. But, there are many reasons that a certificate cannot be validated, and we are discussing what should be displayed to the human user to tell them about the reason for the validation failure.

The human use needs to know which certificate has the problem as well as the nature of the problem. Logo is one facility available to the GUI developer to help tell the human which certificate could not be validated.

If a certificate can't be validated, this MUST be clearly indicated. I do not think there is any disagreement on this point.

Not being able to validate a certificate may have many causes. For example, a certificate may not chain up to a configured trust anchor. This situation is fairly common today, and it MUST NOT prevent display of certificate content, with appropriate warning, otherwise the human user will not have enough information to correct the configuration. RFC 3280 does not prevent the display of traditional certificate fields when the certificate cannot be validated, and I fear that preventing display of some information (but not other information) introduces a new threat.

I have consulted with one of the other authors of this document, and we believe that the text in section 6 is correct.

Russ


At 08:37 AM 9/18/2003 -0400, Steven M. Bellovin wrote:
In message <5.1.0.14.2.20030918000512.03e434c0@mail.windriver.com>, Margaret Wa
sserman writes:
>
>I would feel more comfortable with this specification if the
>security consideration sections said that the client MUST
>NOT display any logo information, unless the certificate has
>been validated with the CA.
>
>In that case, I agree that the CA should be trusted to
>associate the right logo information (for some definition)
>with the certificate.
>
>But, displaying logos for unvalidated certificates along
>with a warning message only seems like a good way to distract
>users from taking the warning seriously.
>

Margaret, that's Certificate Processing 101 -- the whole purpose of a
certificate is to get third party verification of the information.
Now, there's debate in the security community about whether or not this
is a good idea in the first place -- Matt Blaze has been quoted as
saying that third party certificate authorities will protect you from
anyone from whom they won't take money -- but there's no debate
whatsoever on the need to verify the signature before using the
information.

Now -- what to do if the verification fails in some fashion is an
interesting question in human factors.  Often, the correct response is
to display *all* useful information from the certificate to help the
human decide what to do, since many verification failures result from
benign causes.  For example, for three straight years Microsoft let its
primary code-signing certificate expire in a certain sense, and
Microsoft's software properly objected to using it.  But the software
let me satisfy myself that it was a bureaucratic failure, not a
security one, so I went ahead and used it.  (I also got to tease my
friends at Microsoft Security, but that's another matter...)  Should
the software have displayed the logo to me during that process?

If you want an additional warning, I'm not going to object.  But it
should be worded something like this:

        As with all other fields in a certificate, logo information
        MUST NOT be used until the validity of the certificate has been
        successfully checked.


--Steve Bellovin, http://www.research.att.com/~smb