Mark:
I haven't mention the new CRL format, but we would certainly want to include
v2 of the CRL at the same time.
Thus the nextUpdate field becomes optional?
While nextUpdate is optional in ASN.1 terms, it is perfectly reasonable for RFC
1422 to state that, for PEM (or other Internet?) purposes, this optional field
must always be present.
Are there any examples of extensions for CRLs?
The CRL extensions in the PDAM are: cRLNumber (non-crit),
issuingDistributionPoint (crit), and deltaCRLIndicator (crit). The CRL entry
extensions are reasonCode, expirationDate, instructionCode, and invalidityDate
(all non-critical). I shall post the PDAM later this week.
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?
BTW #2, Suppose a CA administrator has determined a certificate is to be
revoked, and would like to include a critical extension in the revocation list
entry for that certificate. How does the administrator find out what
critical extensions are supported by the implementations of all the intended
recipients of this CRL? This problem doesn't occur with RFC 1422: presenting
a CRL with a valid signature to any implementation will cause the certificates
listed to be marked as revoked, flushed from the cache etc.
I would hope this is a non-issue. As you obviously realize, critical
extensions
are somewhat dangerous things, and I hope that very few will ever be defined
and
those only on a community-wide basis and with very good justification. For
example the issuingDistributionPoint and deltaCRLIndicator critical CRL
extensions are used to generate quite special forms of CRL which are stored in
different directory entry or different attribute to regular CRLs, hence do not
really present an interoperability problem.
I'd suggest that if you were to publish an RFC which includes the criticality
mechanism, you include some text on how an implementation is to find out
what these extensions are. If no list of critical extensions is published
simultaneously, then I would think some implementations would be coded in such
a way to simply reject anything with a critical extension, somewhat defeating
the purpose of early publication of the v3 format. However, if it was
stated (for instance) that certificate extensions were to be registered with
the IANA, and all implementations for use on the Internet must be capable of
recognizing any extensions listed in the "assigned numbers" RFC series within
6 months after publication of that RFC, and optionally may also include
support for per-organization or per-PCA defined extensions...
I would hope that we could specify at a quite high level - i.e., within the
revised RFC 1422 spec itself - exactly which critical extensions (for both
certificates and CRLs) are permitted. We would want to avoid new critical
extensions appearing dynamically without serious review by the wider community.
What is the best way to formally distinguish between the PEM/MIME or IETF
version of X.509 v3 and the ISO/ITU version, perhaps with a unique attribute
ID?
I suppose that we could arbitrarily pick a version number such as
8003, and then change it to 3 in our spec when the ISO spec is finalized?
(re Bob's comments): As stated elsewhere, I think OIDs are a non-issue. Also,
unless we have a document covering v3 advancing to proposed draft standard
before July, there is no need to worry about versions either. Assume the
balloted ISO v3 spec for the present.
Warwick