Steve:
One immediate observation about the proposed CRL format:
CertificateList ::= SIGNED { SEQUENCE {
version Version OPTIONAL,
-- if present, version must be v2--
signature AlgorithmIdentifier,
issuer Name,
thisUpdate UTCTime,
nextUpdate UTCTime OPTIONAL,
revokedCertificates SEQUENCE OF SEQUENCE {
userCertificate CertificateSerialNumber,
revocationDate UTCTime,
crlEntryExtensions Extensions OPTIONAL } OPTIONAL,
crlExtensions [0] Extensions OPTIONAL }}
The OPTIONAL nature of the nextUpdate field is not consistent with
the CRL format in PEM RFC 1422. Can you explain the reasoning ?
For some environments, nextUpdate was considered unnecessary, e.g., if the CRL
issue cycle is fixed by policy and known to all users in an environment the
field is not needed. Nevertheless, for other environments, it is quite
reasonable to say that this field must always be present (this amounts to
"profiling" the standard). The PEM (RFC 1422) environment is in the latter
category, i.e., use of this field is mandated. Assuming PEM starts using the
new extension fields, other similar stipulations may arise. For example, the
PEM infrastructure spec. may mandate use of the RFC822Name field in all
certificates for PEM use, even though this is an optional field in the
standard.
I do not see such differences as being incompatibilities - they simply reflect
the situation that PEM use of X.509 represents a specialization of the more
general standard.
Warwick