Bob:
Maybe I can get some help from Warwick and Mark (please, guys?), or at least
some moral support and guidance as to how to shepard such changes through the
IETF processes. The specification of the format itself should require a
minimal effort.
Yes, the format is in my posting of December 17. All you have to do is write a
short paragraph to go with it. It seems perfectly reasonable to me to include
this in the MIME/PEM spec now to give us a migration path forward. Note that
the v3 certificate spec is 100% backward compatible with v1, i.e., if we define
the field as being the v3 format you can still carry a v1 certificate in it
(but the inverse would not be true).
I haven't mention the new CRL format, but we would certainly want to include v2
of the CRL at the same time.
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?
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. 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?
Otherwise, I am concerned about Ned's point that the IETF might reject it
because the ISO standard hasn't been adopted yet.
Certificate Format:
Certificate ::= SIGNED { SEQUENCE {
version [0] Version DEFAULT v1,
serialNumber CertificateSerialNumber,
signature AlgorithmIdentifier,
issuer Name,
validity Validity,
subject Name,
subjectPublicKeyInfo SubjectPublicKeyInfo,
issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL,
-- If present, version must be v2 or v3
subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL,
-- If present, version must be v2 or v3
extensions [3] Extensions OPTIONAL
-- If present, version must be v3 --} }
Version ::= INTEGER { v1(0), v2(1), v3(2) }
Extensions ::= SEQUENCE OF Extension
Extension ::= SEQUENCE {
extnId EXTENSION.&id ({ExtensionSet}),
critical BOOLEAN DEFAULT FALSE,
extnValue OCTET STRING
-- contains a DER encoding of a value of type
&ExtnType
-- for the extension object identified by extnId
-- }
The extensions field allows addition of new fields to the structure without
modification to the ASN.1 definition. An extension field consists of an
extension identifier, a criticality flag, and a canonical encoding of a data
value of an ASN.1 type associated with the identified extension. When an
implementation processing a certificate does not recognize an extension, if the
criticality flag is FALSE, it may ignore that extension. If the criticality
flag is TRUE, unrecognized extensions shall cause the structure to be considered
invalid, i.e., in a certificate, an unrecognized critical extension would cause
validation of a signature using that certificate to fail.
The following object class is used to define specific extensions. Specific
extensions may be defined in ITU-T Recommendations | International Standards or
by any organization which has a need.
EXTENSION ::= CLASS
{
&id OBJECT IDENTIFIER UNIQUE,
&ExtnType
}
WITH SYNTAX
{
SYNTAX &ExtnType
IDENTIFIED BY &id
}
--------------------------------------
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 }}
If any extensions included in a CertificateList are defined as critical, the
version element of the CertificateList shall be present. If no extensions
defined as critical are included, the version element shall be absent.
----------------------------------
Any discussion of use of specific v3 extensions would be best deferred to a new
project which updates RFC 1422. Perhaps we can start moving now on getting
that new project established.
I would certainly like to see that happen, but I will defer to the WG chair
and/or the area director for practical guidance as to how to proceed.
Bob
Robert R. Jueneman
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254
617/466-2820
Jueneman(_at_)GTE(_dot_)COM