Bob/Mark:
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.
Not necessarily. Suppose that we have an extension field which indicates the
reason for the revocation. If the reason is an innocuous one, i.e., change of
name after marriage, or change of address, then there is no reason to actually
reject a document that was signed using that certificate -- it may just be
arriving late.
This seems to imply that the certificate is still valid for some applications
(e.g. document handling) but possibly not valid for others (e.g. login).
The certificate is revoked regardless. If some application has a local policy
that permits it to use revoked certificates (subject to revocation reason) then
that is up to that application.
It could be argued as to whether the Reason of Revocation field _should_ be
marked as critical -- we should discuss that further -- but it is clear that
there is no corresponding extension in the certificate itself. (This may not
always be the case, however.)
Reason should not be critical. The semantics if an implementation does not
recognize the reason code are that the safest course should be followed, i.e.,
consider revocation for the worst imaginable reason therefore do not use the
certificate. This is simply defaulting to the v1 CRL behaviour where we do not
have reason codes.
I would suggest that perhaps there is a critical extension that would need to
be placed in all certificates issued by this [P]CA: the extension (of syntax
SET OF OBJECT IDENTIFIER) would be defined as:
If this certificate is ever revoked the application must be
capable of correctly interpreting the semantics of all the CRL
entry extensions listed here, regardless of their criticality.
If it could not and the certificate were revoked the application
in its handling of the revocation might violate the [P]CA policy,
and thus should not make use of this certificate for any purpose.
Not sure I follow you here. Provided default CRL-processing gives safest
behaviour, I cannot see why any of this is necessary.
Suppose that a certificate includes the granting of several kinds of
authorities. Would it be possible to revoke only one of those authorities,
leaving the others intact? If so, that extension should be marked critical,
and
if the processing software can't handle that the entire certificate should be
rejected. A new certificate should be made available in either case, but it
might not be necessary to go get one immediately.
Not a valid use of X.509 certificates. These certificates are used for binding
a public key to an identity. Revocation of an attribute certificate may
involve
a different process.
I don't feel any of the examples given so far are good reasons for introducing
critical extensions. As I have stated before, critical extensions are
dangerous
for interoperability reasons, hence should be avoided unless there is any risk
of an older system behaving insecurely by virtue of its having ignored a newer
extension. The sole purpose of the criticality mechanism is to support
migration
through graceful addition of new extensions.
In fact, I believe we can likely get by without ever needing to define any
critical cRLEntryExtensions. This is supported by the argument that, in the
vast majority of extensions I can conceive of, the treatment of the extension
would be the same regardless of whether or not we flagged it as critical or
noncritical.
Presumably the correct semantics of the criticality indicator on
cRLEntryExtensions should be: If a CRL-using implementation does not understand
a critical extension, then it should take the safest course of action, i.e.,
consider the certificate whose serial number is listed to be invalid.
Most of the time, this will lead to exactly the same behaviour as when a
CRL-using implementation encounters a non-critical extension it does not
understand - it will ignore that extension and proceed with considering the
certificate revoked. The only time you would need to flag a cRLEntryExtension
as critical would be if this extension is indicating that the situation is more
serious than other extensions imply. For example, if there is one extension
which indicates an innocuous revocation reason, plus another extension which
indicates a serious revocation reason, the implementation may react invalidly
if
it understands the first extension but not the second.
Perhaps, if extensions are designed intelligently, we can avoid all such
situations.
Warwick.