Ian,
Ian G wrote:
Nelson Bolyard wrote:
Frank Hecker wrote:
However there still appears to be an open question as to whether having an
AIA extension with OCSP URL in the Microsec root certificate will cause a
problem with NSS. (Nelson wrote that he was going to investigate this, but I
don't recall seeing a followup to this.)
Sorry, I did get the answer but forgot to write it up. :-/
Although we haven't tested it with libPKIX, as far as I know, OCSP URLs
in root certs will not be a problem for NSS. NSS will never check a
self-issued cert for OCSP revocation.
Ah, ok, excellent, that helps with the big question: Can we
conclude from this that roots cannot be revoked by means of the
OCSP/CRL channel?
Roots cannot be revoked by OCSP/CRL channels. You only need to read PKIX
standards (RFC3280 for one) to figure that out. Trust anchors are
outside the scope of these revocation protocols.
(Therefore they can only really be replaced by an adjustment to the
root list?)
Correct.
And -- broader question for the policy wonks as well as the coders
-- are we actually happy that this is a good thing: revocation of
roots is not a CRL/OCSP possibility? Should we write this up as a
policy statement somewhere? Or should we treat it as a bug to be
filed & fixed?
You should take that up with the IETF if you want the CRL and OCSP
protocols changed to allow root revocation.
IMO, the more roots we have in NSS/PSM, the greater likelihood it is
that one of them will be compromised one day.
We should be prepared for the eventuality and we have several means of
dealing with that, which I just described in another post to Eddy.
Unfortunately there is no standards-compliant way of dealing with that
problem in general.
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
