> 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. 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
