Mark:
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).
This is a non-issue because of the version field in the certificate. An
implementation (of any vintage) recognizing only version i should not accept a
certificate with a version greater than i. This permits us to store all
versions in the one attribute-type without change os OID. (Of course, having
now introduced the certificate extensibility mechanism with the
criticality/non-criticality feature, there should be no need for any more
versions after v3.)
Warwick