On Wednesday 04 June 2008 21:32:17 Nelson B Bolyard wrote: > Rob Stradling wrote, On 2008-06-04 04:45: > > 2. Give each affected CA the opportunity to submit a replacement > > 1024-bit RSA Root Certificate for inclusion in new versions of Mozilla > > software. Each of these replacement Root Certificates would exactly > > match the to-be-removed Root Certificate (in terms of Subject name, > > Public Key and Subject Key Identifier), but would have a different Serial > > Number and a more acceptable Not After date. > > That plan appeals to me.
:-) > > Disadvantages: > > - Each affected CA would have to spend some time reissuing their Root > > Cetificate. > > Rob, in the past, any time that we have suggested that a CA issue a new > root CA cert for any reason, even if only to change something minor, > we've received much feedback saying that doing so represents a huge > challenge and investment for the CAs, necessitating modifications to > CPSes, triggering new audits, etc. etc. One gets the impression from > those replies that this is something the CAs would rather avoid at > (nearly) all cost. I'm not convinced a new audit would be required, and I don't think CPS changes are quite as expensive as the CAs you cite have suggested. Also...just a thought...I wonder if any part of the Mozilla CA Certificate Policy could be updated to make 1024-bit Root Certificate replacement less hassle? On a kind-of-related note... Bug 406794. GlobalSign want to do something very similar to what I've suggested, albeit with a 2048-bit Root Key and extending (rather than reducing) the expiry date. It's obviously not too much of "a huge challenge and investment" for them. > > - There may be some (solvable, I think) interoperability problems for > > CAs that choose to include the "authorityCertSerialNumber" field in the > > Authority Key Identifier extension of certificates issued by their > > 1024-bit Root Certificates. > > Yes, that's also an issue. NSS treats AKID extensions as requirements. > When the issuer says to the relying party, through an AKID extension, > "you must rely on the issuer cert with this issuer name and serial number" > NSS does so. I'm afraid the solution, for CAs that used that field, > may be for them to reissue certs with the offending AKID extension. Could that behaviour of NSS be changed? If future NSS versions were to treat "authorityCertSerialNumber" as merely a hint, then I don't think that any certs would need to be reissued for my proposal to work. > We keep telling CAs NOT to include the part of an AKID that names the > issuer's issuer and the issuer's serial number, but many CAs keep on doing > it anyway. The OpenSSL programs that create certs do that by default, > IINM, requiring extra work (I gather) to avoid including that info in the > AKID. I have suspected for some time now that the reason CAs keep > including that info is because they haven't figured out how to stop the > OpenSSL program from doing so. :( > > _______________________________________________ > 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
