(Discussion on whether the Certificate with ISO extensions would continue to
have the same AttributeType OIDs as the X.509(93) and X.509(88) certificates,
2.5.4.36 and 2.5.4.37, for use with Directory. Would there be problems due
to combination of the "extensibility rules" of the '93 Directory: unexpected
additional elements in SEQUENCEs should be ignored, and the requirement that
unknown critical extensions somewhere inside these unexpected elements cause
the certificate verification to fail?)
Surely you aren't implying that we would need to support the '93 version of
X.500 before we could support the inclusion of such an attribute type?
This new syntax could be supported in both '88 or '93 Directory systems.
How does this square with the notion of the CRITICAL flag?
I'd think it depends on the Defect/extension handling process.
One reading is that assuming the same OID is used for the attributes as the
X.509(93) userCertificate and caCertificate, then if there was certificate
with a critical extension of a type which was to be 'unknown', an X.509(88)
system conformance-tested before 1993 would reject the certificate (though
because it has invalid syntax), but both an X.509(88) system conformance-
tested after 1993 and an X.509(93) system conformance-tested to current
standards would 'incorrectly' accept the certificate, as it is ignoring the
extension element as required by X.519(93).
(Another example: the element tagged context 25 in DAS CommonArguments was a
"SET OF EXTENSION OPTIONAL" in X.511(88), but is a "BIT STRING OPTIONAL" in
X.511(93), where the setting of certain bits indicate "criticality". A '93
system can reject a SET OF received from an '88 system, but an '88 system is
expected to ignore a BIT STRING if received from a '93 system.)
|(Note that if an OID is to be assigned to the ASN.1 module which defines these
| types, it should probably be different ...but an OID wasn't assigned for
| Appendix A of 1422)
Should it have been?
In the X.208(88) (ASN.1) a module's OID was optional. An OID should probably
be given to a module if its types are being exported and used in other ASN.1,
but this was not the case for 1422. I don't think module OIDs are exchanged
in any protocols.
===
If the X.509(93) format were to be used in the Crocker/Freed/Galvin/Murphy
MIME-PEM, and assuming a gateway of some kind (even just signed but unencrypted
text/plain only) from MIME-PEM to PEM-1421 were possible, all the sender's
CA's and PCA's will need to be able to generate CRLs w/o any critical
extensions. The gateway may be able to obtain the entire certificate path as
seen by each recipient and ensure there are no critical extensions there, but
it cannot prevent a CRL from being issued after the message has been gatewayed
but before it is received.
------------------------------------------------------------
Mark Wahl; M(_dot_)Wahl(_at_)isode(_dot_)com; ISODE Consortium;
http://www.isode.com/