Bob Jueneman writes:
Certificate ::= SIGNED {SEQUENCE {
version [0] Version DEFAULT FOR PEM v3,
serialNumber CertificateSerialNumber,
signature AlgorithmIdentifier,
issuer Name,
validity Validity,
subject Name,
subjectPublicKeyInfo SubjectPublicKeyInfo,
issuerAttributes [1] IMPLICIT IssuerAttributes OPTIONAL
-- If present, version must be v3
subjectAttributes [2] IMPLICIT SubjectAttributes OPTIONAL
-- If present, version must be v3 --}}
Note that the previous issuerUniqueIdentifier and subjectUniqueIdentifier
attributes now become just one each of many possible additional attributes
relating to the issuer and the subject. For that reason, the version 1 and
2 definitions of Certificate are compatible subsets of the proposed version
3.
Well, not strictly "compatible" as a v2 certificate with a UI won't be
DER-equivalent with a "v3" certificate with a UI in the attribute list!
Why not leave the v2 fields in the new Certificate definition, and define
rules (if there are no attributes to be signed, make a v1 certificate, if the
only attributes are unique identifiers, make a v2 certificate, otherwise make
a new-style certificate).
[However, since this aspect of the suggestion was criticized when it
was proposed previously, I would be quite happy to leave the '93 UID fields
alone, and add these additional attributes as pure extensions. I would also
be happy to have someone clean up any errors or misunderstandings of the
ASN.1 syntax. RRJ 3/22/94]
Please don't re-use the tags - issuerAttributes and subjectAttributes should
have different numbers. Also consider that the ITU, after defining
Certificate v2 might decide to define its own Certificate v3, and this would
result in significant confusion. Why not make this version 1972825?
1. It allows the current X.509 certificate to be extended an a compatible
way. In fact, since to the best of my knowledge there are NO X.500
implementations available as yet that support strong authentication,
implementing this certificate format per se should have zero impact on any
of the DSAs or DUAs.
The PASSWORD project demonstrated DSAs/DUAs which supported strong
authentication: OSISEC+QUIPU (UCL), SecuDE+QUIPU (GMD), Mavros+PIZZARO (INRIA).
Others on this list can provide more information.
4. It seems to provide a means of supporting X.500 strong authentication,
PEM, and other forms of certificate-based authentication with a common
identity validation mechanism.
I'm not sure what you mean for the X.500 case - what is the advantage over an
X.509(1993) v2 certificate?
2. Define a new attribute, called ietfCertificate, and register it under
the IANA's OID.
Technically there would be no difference, but politically I think it would be
better for it to be registered with the name "pemCertificate". There are other
IETF WG's interested in certificates.
I would appreciate the serious consideration of this proposal at the WG,
and if there is a reasonable consensus I would be willing to transform
this text into a formal Internet Draft or take whatever other next steps
are required.
Don't forget to include the pemCRL attribute type, which has a syntax but not
a defined OID.
-------------------------------------
Mark Wahl; M(_dot_)Wahl(_at_)cs(_dot_)ucl(_dot_)ac(_dot_)uk; Univ.
Coll. London