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?
Are there any examples of extensions for CRLs?
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?
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'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...
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?
None of PEM 1421-1424 specified attribute OIDs as they did not discuss PEM use
of the Directory.
Historically, several organizations specified (different) OIDs for the
pemRevocationList.
My blue books are still packed, and I don't remember where the attribute ID
and/or OID is specified for an attribute such as Certificate that is part of
the standard.
They were defined in X.520(88) and X.509(93).
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?
If this were to be done, might it be a good idea to put a comment in this
spec suggesting that implementors should not develop MIME/PEM products which
make use of #8003 as this is an interim mechanism?
In addition, if it is necessary we can specify theformat as a completely
self-contained attribute with an IANA OID, and later, when v3 has been
ratified, then _surprise_ we change our OID to the standard and everyone is
happy.
Except for implementors whose products would be assuming the IANA OID and
become noninteroperable with those based on the new document, and people
deploying these attributes in the Directory by publishing X.500 Schema
information. I would suggest checking out the archives of the ASID WG
<ietf-asid(_at_)umich(_dot_)edu> which just had a discussion of the problems of
changing
attribute OIDs.
------------------------------------------------------------
Mark Wahl; M(_dot_)Wahl(_at_)isode(_dot_)com; ISODE Consortium;
http://www.isode.com/