Looking at the http://www.win.tue.nl/hashclash/rogue-ca/ attack specifically...
The "Equifax Secure Global eBusiness CA-1" self-signed Root Certificate trust anchor does *not* contain the Authority Info Access extension or CRL Distribution Points extension. The Rogue CA Certificate does *not* contain the Authority Info Access extension or CRL Distribution Points extension. (The legitimate certificate that has the same signature as the Rogue CA Certificate does contain the CRL Distribution Points extension, but that's irrelevant). So, with zero potentially suitable CRL/OCSP URLs available, this surely means that that Rogue CA Certificate is essentially *unrevokable* by normal means, and that any certificates issued by the Rogue CA Certificate are essentially *unrevokable* by anyone other than the attacker. The CA (RapidSSL) could have thwarted the attack by using a stronger hash algorithm, or by generating random certificate serial numbers instead of guessable sequential ones. I think it's sensible to expect this attack on MD5 to be repeated by other attackers, and to expect a similar attack on SHA-1 in the future. Therefore, we should consider putting in place some safeguards now. Some ideas: Perhaps the Mozilla CA Certificate Policy could mandate that all CAs must (after a certain date) generate long, randomized certificate serial numbers? Perhaps the NSS code could reject (after a certain date) certificates with short serial numbers, on the assumption that they are sequential and therefore potentially guessable? (Perhaps future updates to RFC5280 and the CABForum EV Guidelines could recommend or require long, randomized certificate serial numbers as well?) On Tuesday 06 January 2009 01:31:55 Paul Hoffman wrote: > At 4:01 PM -0800 1/5/09, Nelson B Bolyard wrote: > >Paul Hoffman wrote, On 2009-01-05 08:54: > >> At 3:09 PM +0100 1/5/09, Ian G wrote: > >>> [...] Hence, once we rogue-players have created a certificate like > >>> this, the CA cannot revoke it using its own control mechanisms. [...] > >> > >> I am not convinced the article is correct. If it is correct, it is a > >> serious but easily-fixed bug in IE. That is, if a trust anchor contains > >> a AIA that points to an OCSP responder, and the rogue sub-CA has an AIA > >> that points to a different OCSP responder, the validation process should > >> should check the OCSP of the trust anchor. > > > >I'm surprised that you wrote that, for several reasons. Let me explain > >some of them. For brevity, I will use the following terms: > > > >child - the cert whose revocation we want to check > >parent - the cert for the CA that issued the child cert > >sibling - another cert issued by the same parent CA > >grandparent - the cert for the issuer of the parent cert. > > > >Everything I write below about OCSP is also true for CRLs, IINM. > > > >1) It's not generally true that you can use the OCSP URL in the parent > >cert to check the OCSP status of a child cert. This is because it is > >not generally the case that the issuer of the child is also the issuer > >of the parent (that is, that parent == grandparent, parent is a root). > > > >2) It's also not generally true that you can use the OCSP URL in a > >sibling to check the OCSP status of a child. This is because the parent > >may have multiple OCSP responders and may use different responders for > >different certs that it issues. Indeed, the parent could put a unique > >OCSP URL into every cert it issues. > > > >3) A corollary of (2): Even when parent == grandparent, and hence parent > >is also a sibling, it's not generally true that you can use the OCSP URL > >from the parent to check the OCSP status of a child. > > All of that is true (and is true for CRLs, I believe), but it is not what I > was speaking to. The recent MD5 attack creates a rogue sub-CA, that is a > new child of one of your trust anchors. The Microsoft article made it sound > (to me, at least) that if the rogue sub-CA (the child) has a AIA, then IE > will not look in the parent's AIA to determine the status of the child. If > that's true, it is broken. Each level of the family can have its own AIA > that applies to all of its children, not just to end entities. > > >4) Trust anchors are not necessarily roots. > > Of course. I'm not seeing where that is relevant here, but I could be > missing something. > > >5) Most roots don't have AIA cert extensions. Only 8 out of the 125 roots > >in nssckbi have them. > > Now *that* is sad. I was hoping for closer to 50%. It does not make my > argument wrong, just pretty moot. > > --Paul Hoffman > _______________________________________________ > dev-tech-crypto mailing list > dev-tech-crypto@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-tech-crypto -- 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
