On Thursday 05 June 2008 12:05:42 Eddy Nigg (StartCom Ltd.) wrote: > Rob Stradling: > >> 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. > > Yes, I agree with you. I suppose that this is part of the key management > a CA performs, which in itself is audited. Issuing new keys according to > the defined procedures and CP/CPS doesn't require re-auditing per se, > perhaps only if there were substantial other changes to the > infrastructure which aren't related to the mere issuing of additional keys. > > > 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? > > I don't agree however with this. CAs usually have to go through the full > cycle for having roots included and we shouldn't make other exceptions. > The EV inclusions were exceptionally rushed enough I'd say...Also it's > an excellent opportunity to review CAs which sometimes never were really > looked at.
I have no objection to Mozilla reviewing "CAs which sometimes never were really looked at" in days gone by. :-) > Additionally, most of the times the old and the new root will be both > present in NSS for some time in order to allow a smooth transition, > until the old root is being removed. Not so. With my proposal, the old and new roots would *not* both be present in any NSS versions. The old one would be removed when the new one gets added. Eddy, I think you've missed the main point of my proposal. I am suggesting that each existing valid-for-too-long 1024-bit RSA Root Certificate should be replaced with a valid-for-not-too-far-beyond-2010 1024-bit RSA Root Certificates *WITH THE SAME KEY*. > > On a kind-of-related note... > > Bug 406794. GlobalSign want to do something very similar > > No, this isn't the same really, it's not a new key per se. Precisely. So, as I said, it is the same thing. > > 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. > > Mhhh, maybe I'm missing something here, but how should replacing a root > with a different key and key size not have an effect on this? Certs will > have to be issued from the new root at some point and I'm not sure how a > certificate signed from a 1024 bit key doesn't require re-issuance from > a new 2048 key if the old key becomes obsolete and the EE cert is still > valid. > > > Regards > Signer: Eddy Nigg, StartCom Ltd. <http://www.startcom.org> > Jabber: [EMAIL PROTECTED] <xmpp:[EMAIL PROTECTED]> > Blog: Join the Revolution! <http://blog.startcom.org> > Phone: +1.213.341.0390 -- 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
