BTW #1, Suppose an implementation is checking for the revocation of a
particular certificate in a v2 CRL. I'd assume that the presence of an
unrecognized critical extension in the crlExtensions would cause the entire
CRL to be ignored. Does the presence of an unrecognized critical extension
in the crlEntryExtensions field of a revocation list entry for a different
certificate (different userCertificate serial number) cause the entire CRL to
be rejected, or is just that element of revokedCertificates skipped?
Good question. Because no-one has thought up any critical crlEntryExtensions
yet, this is the first time I have heard this question asked. I would like
to see the ISO text clarified on this (we can clarify it in the forthcoming
90-day ballot). My initial view is that the whole CRL should be rejected -
can you suggest any scenario where this would be bad?
My initial reaction is that for a CRL entry with an unrecognized critical
extension: if its serial number is not one we're looking for, ignore the entry
and parse the rest of the CRL; if it is, abort processing of the CRL and
complain: the CA has made an invalid assumption about the user community.
I would have thought that perhaps there would only be a CRL entry critical
extension if some form of 'special handling' of the revoked certificate was
required, which would indicate that this certificate was only being used in
a particular application. Thus there probably should have been a
complementary critical extension in the issued certificate itself, so that
a user outside of this application, unable to perform this special handling,
would never be using the certificate.
Having a CRL receiver ignore extensions in entries revoking certificates it
doesn't have would then be beneficial in that a CA doesn't need to issue
multiple (simultaneous) CRLs for each flavour of critical extension.
------------------------------------------------------------
Mark Wahl; M(_dot_)Wahl(_at_)isode(_dot_)com; ISODE Consortium;
http://www.isode.com/