On Wednesday 15 October 2008 15:14:10 István Zsolt BERTA wrote: > > Just a thought... > > If Nelson's investigation does find that the OCSP AIA extension in your > > Root Certificate is a problem for NSS, is there really anything to stop > > you from issuing a new Root Certificate? This new Root Certificate could > > be identical to your current Root Certificate except for i) different > > serial number, and ii) OCSP AIA removed. > > As the old and new Root Certificates would have the same Subject Name and > > Key, they would effectively be interchangeable. > > Theoretically, we could issue such a certificate, but we would like to > avoid this if possible. > Our current root certificate is already used in many systems and many > applications, and it also appears in a vast number of timestamped > signatures (of ETSI TS 101 903 format). I am afraid, we would not be > able to forget about our current root certificate completely, but we > would need to use the two roots in parallel. As many of these systems > or applications are not under our control, the two roots could lead to > problems we cannot foresee.
István, I must confess that I'm not too familiar with the ETSI TS 101 903 timestamped signature format. Do these signatures include a copy of your current root certificate? If yes, then I agree that there might be "problems we cannot foresee". It might interest you to know that GlobalSign have recently "refreshed" their Root Certificate in Mozilla NSS: https://bugzilla.mozilla.org/show_bug.cgi?id=406794 Presumably GlobalSign don't foresee any problems with using "two roots in parallel". But then, I guess GlobalSign may not be intending to support the same range of systems and applications that Microsec support. > I have also reread relevant sections from RFC 5280 and X.509, and I > have not found any requirement for checking the revocation status for > trust anchors. I found that a trust anchor is an input to the path > validation algorithm, and - even if it is presented as a self-signed > certificates - it is not included as a part of the certification path. > The path validation algorithm checks the revocation status of members > of the certification path only. > > However, I do accept that it is awkward to have an OCSP AIA extension > in a root certificate. > > Regards, > > István > _______________________________________________ > 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
