On Thursday 02 October 2008 22:43:02 Frank Hecker wrote: <snip> > * Microsec has a separate root used for OCSP, and apparently does not > offer OCSP as a general public service; please see the comments in the > bug. I'd like those of you who are OCSP experts to look at this issue > and tell us if you see any potential problems there.
Comment #3 in that bug indicates that they're not expecting Mozilla to support "OCSP under a separate root". When Microsec be include their OCSP Responder URL in an end-entity certificates that they issue, FF3 will by default attempt to check the certificate's status via OCSP. This OCSP check will of course fail, because: i) the OCSP signer certificate does not chain up to a trusted Root, and... ii) RFC2560 section 4.2.2.2 (and therefore FF3, I presume) insists that "a certificate's issuer MUST either sign the OCSP responses itself or it MUST explicitly designate this authority to another entity", and this condition is not met. On Saturday 04 October 2008 12:54:10 Eddy Nigg wrote: > The default settings of FF3 is to use OCSP and as you mentioned, this isn't > going to work (as you mentioned already). Yes and no. IINM, FF3 by default has the "When an OCSP connection fails, treat the certificate as invalid" tickbox set to *disabled*, meaning that most users won't see browser warnings. Therefore, IMHO, if Microsec don't think it's a problem, then it's not a problem. (The other effect of a failed OCSP lookup in FF3 is that an EV cert will lose its EV status, but I don't believe that Microsec are an EV certificate issuer at present). On a related note... It might interest you to know that the Microsoft CryptoAPI does support "OCSP under a separate root" in Windows XP and Vista. I recently asked our contact at Microsoft to explain to me why this RFC2560-non-compliant feature exists. He said: "The feature to allow OCSP responses to be signed by a certificate under a different root was added for customers with branch networks that cannot connect to the CA's revocation repository, either because the customer do not want to allow those machines to connect to the Internet directly, the connection has limited bandwidth, or the branch network is physically disconnected for extended periods (such as those on a ship)." > This first public comment period will be for one week, and then I'll > make a preliminary determination regarding this request. > > Frank > > [1] Fun fact: Within Hungary names are normally given in "Eastern order" > (i.e., like China or Japan) with surname first. In this case I've > transposed to Western order (I think). -- Rob Stradling Senior Research & Development Scientist Comodo - Creating Trust Online Office Tel: +44.(0)1274.730505 Fax Europe: +44.(0)1274.730909 www.comodo.com Comodo CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
