On Tuesday 03 June 2008 07:28:33 Michael Ströder wrote: > Eddy Nigg (StartCom Ltd.) wrote: > > Paul, I think that the general idea (of Frank and others) is, to make a > > requirement on new roots and act on the 1024 bit keys at some point in > > the future. > > I also support the idea of throwing out 1024 bit keyed roots at a not so > distant point in the future.
For those 1024-bit RSA Root Certificates that are *already included* in Mozilla software, I think that a distinction should be drawn between: A. Those that expire before NIST's 2010 deadline. B. Those that expire soon after 2010. C. Those that expire well beyond 2010. For now, let "soon after = before 2013" and "well beyond = after 2013". I think that type A and B Root Certificates can be left to expire naturally before being removed from future versions of Mozilla software. I have a suggestion regarding what Mozilla could do *right now* with type C Root Certificates... 1. Remove each type C Root Certificate from Mozilla ASAP, but also... 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. Advantages: + Mozilla would be able to prevent the reliance on 1024-bit RSA Root CA Keys according to a time schedule set by Mozilla. + This prevention time schedule would take effect ASAP. There would be no need to wait until 2013 to remove type C Root Certificates from Mozilla, which means that... + Versions of Mozilla software published between ASAP and 2013 would not trust any 1024-bit RSA Root Keys beyond 2013. (I think that, come 2013, we can expect some users to be using old versions of Mozilla software). Disadvantages: - Each affected CA would have to spend some time reissuing their Root Cetificate. - Mozilla representatives would have to spend some time checking the replacement certificates and writing patches to remove/include the original/replacement certificates. - 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. Am I trying to make things too complicated? Or does anybody think that this idea is worth considering? > I also hope that this will sort out some of > the issues with root CA certs concerning so-called "cross-signing" and > liberal use of sub CAs. > > > are issued from that root since we've successfully transitioned to the > > newer 4096 bit root. > > FYI: A VPN product of a major vendor simply does not work with 4096 bit > root. > > Ciao, Michael. > _______________________________________________ > 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
