[cabfpub] Web Security Context: User Interface Guidelines

Rick Andrews Rick_Andrews at symantec.com
Tue Sep 18 17:46:46 UTC 2012


> -----Original Message-----
> From: Gervase Markham [mailto:gerv at mozilla.org]
> Sent: Tuesday, September 18, 2012 6:06 AM
> To: Rick Andrews
> Cc: Yngve N. Pettersen (Developer Opera Software ASA); public at cabforum.org
> Subject: Re: [cabfpub] Web Security Context: User Interface Guidelines
> 
> On 23/08/12 23:31, Rick Andrews wrote:
> > I'm very curious to hear from Brian, Gerv and Ryan what they think
> > about this document, and whether they would consider complying with
> > these guidelines.
> 
> At least two Mozilla people contributed to that document, so I suspect
> we are generally approving of it. Of course, contribution doesn't imply
> total endorsement, and in general, I'd say that our understanding of UI
> best practice is always (we hope!) improving, and we would not want to
> be bound to a particular static set of guidelines issued at a point in time.
> 
> I note that it says: " When, during TLS
> > negotiation, the end-entity certificate presented or one of the
> > intermediate certificates in the certificate chain are found to have
> > been revoked, error signaling of class danger (6.4.3 Danger Messages)
> > MUST be used."
> 
> Do you think that Firefox doesn't do that?
> 
> Gerv

Back in June there was a thread about revocation checking in Firefox in which you and Bob Relyea indicated that FF uses two different libraries, and one of those libraries did not check intermediates.

I'm reattaching the relevant part of the thread:

On 06/25/2012 02:25 AM, Rob Stradling wrote:
> On 22/06/12 15:36, Gervase Markham wrote:
>> On 21/06/12 17:56, Rick Andrews wrote:
>>> We discussed this on the call today – here’s the bug indicating that 
>>> Mozilla sometimes checks the status of intermediates, but not in all cases.
>>>
>>>     _https://bugzilla.mozilla.org/show_bug.cgi?id=155481_
>> As I read that bug, it relates to which of the the 2 (!) verification 
>> engines NSS decides to use. The new one, "libpkix", is used for EV 
>> certs, and will check the entire chain if configured to do so. The 
>> old one, used for other certs, does not.
>>
>> But I'm happy for Bob or another NSS hacker on this list to correct 
>> me :-)
> Hi Gerv.  I'll don my amateur NSS hacker hat...
>
> AIUI (but I could be wrong) from [1], Firefox's PSM component 
> currently calls CERT_PKIXVerifyCert for EV certs, but uses an older 
> function for non-EV certs.  This apparently means that Firefox 
> currently never automatically downloads and checks CRLs for 
> Intermediate certificates in non-EV chains.
>
> Your statement that libpkix is already used for EV certs can't be 
> true, because bug 764393 - a bug with the non-libpkix code - bites EV certs too.
>
> My perception is that Bob (Relyea) is indeed an authority on NSS, but 
> that questions about how Firefox uses NSS should probably be directed 
> at Brian Smith or Kai Engert.
How NSS works does have some bearing here. The old (non-libpkix) interface does not check OCSP on intermediate certs, but does check preloaded CRLs for intermediates. It does not fetch CRLs on the fly.

The new libpkix interface allows the application to choose whether or not to do OCSP checks. Since I work with Kai and Brian, I have a pretty good idea what PSM is currently doing. Right now PSM uses the old interface for all initial certificate processing. If the validation is successful, PSM then checks to see if the cert has an EV oid and then does a separate EV validation. That EV validation uses the libpkix code.

If you are testing to see if FF is checking OCSP status by looking at the OCSP request, then in would look like it is checking status for EV certs but not for other certs. I believe, however, the an EV failure will only drop the EV chrome, not fail the entire connection (this is where Kai would be able to provide better information), so even in the EV case, we only fail the EV portion, not the entire connection.

Brian and Kai are working in eventually getting full libpkix integration into PSM. This issue in particular is one of the drivers.

bob


>
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=531067#c6
>
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=764393
>
>



More information about the Public mailing list