In my previous message on this subject to Steve Crocker and John Lowry, I went
through a number of reasons why I believe the current ('88 and '93) definitions
of the X.509 certificate are inadequate, in particular because they do not
provide
an extensible set of attributes for users (and issuers) that are would be
signed
but would not be part of the DN for the user or issuer.
My specific suggestion, then, is that we define a new X.509 certificate type
that could
contain both a minimal DN (a true DN) to unambiguously identify the user and
facilitate looking up additional information in the Directory), AND it would
contain
an arbitrary number (extensible) of additional attribute values to provide
additional
useful information that can and should be signed by the CA.
At the risk of displaying my ignorance of the fine points of ASN.1, I would
propose
the following new definition for a version 3 X.509 certificate:
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 --}}
Version ::= INTEGER {V1(0), v2(1), v3(2) }
CertificateSerialNumber ::= INTEGER
AlgortihmIdentifier ::= SEQUENCE {
algorithm ALGORITHM.&ID({SupportedAlgorithms)},
parameters ALGORITHM.&Type ({SupportedAlgorithms}{ @algorithm})
OPTIONAL }
Validity ::= SEQUENCE {
notBefore UTCTime,
notAfter UTCTime }
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING }
Other than the version number, the only changes are that the v2 attributes
issuerUniqueIdentifier and subjectUniqueIdentifier are replace with
IssuerAttributes
and SubjectAttributes, respectively, as defined by:
IssuerAttributes ::= SET SIZE (1..MAX) OF
AttributeTypeAndValue
SubjectAttributes ::= SET SIZE (1..MAX) OF
AttributeTypeAndValue
AttributeTypeAndValue ::= SEQUENCE
type ({AttributeType}),
value ({AttributeValue
({SupportedAttributes}{(_at_)type)})}
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.
With the new definition, the DN should reasonably be confined to the proposed
NADF
naming rules for civil authorities, i.e., conform more or less to the "What God
Intended"
rule.
But the additional attribute fields could contain anything and everything that
a CA would
be willing to sign, including attributes defined with private OID
qualifications, where
the ASN.1 syntax would hopefully be made available through the directory itself,
but the semantics may or may not be widely known outside of that private domain.
Reasonable examples of such attributes would certainly include the X.400 ORA
and/or the Internet mail address (assuming that an internationally standardized
OID
is assigned), roleName (another not-yet-standardized attribute), description
(5'2", eyes of
blue), and of course the very useful caveatEmptor attribute.
[caveatEmptor="Everything which is not explicitly allowed by virtue of some
other
attribute signed by this CA is hereby forbidden and eschewed, and any purported
contract, agreement, or obligation to the contrary is and shall be forever
deemd to be
null and void and without merit or value."]
(I probably ought to think about it a little more, but for now I don't see why
any of
the various authorization attributes could not be included in this X.509
certificate,
assuming that the CA is empowered to grant that authorization. If not, then we
might end up with a number of these certificates, perhaps one issued by the
Post Office
for a residential user, one by his employeer, one by MasterCard, one by
Blockbusters,
etc., each with separate authorization attributes pertaining to that enterprises
function.)
I feel that the benefit of this proposal is that:
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.
2. It would allow DSAs and DUAs to be gracefully extended to support additional
attributes that may not have even been thought of to date, without requiring
that the DIT
be modified globally (thereby probably causing the entire system to crash.)
3. It provides a mechanism whereby PEM users can capture both the essential
and perhaps merely useful information within a certificate, without having to
have X.500
up and operational in order to support PEM, and without having to worry that
some new
attribute would "break" X.500.
4. It seems to provide a means of supporting X.500 strong authentication, PEM,
and other forms of certificate-based authentication with a common mechanism.
That is,
it should support a more or less generic national public-key infrastructure
that could be
further expanded to handle everything from gaining access to a national health
service (one particular attribute in a certificate signed by Health and Human
Services
or one of their CA agents, perhaps the Post Office), to filing income tax
returns
electronically, to purchasing goods and digitally signing the receipt with your
American
Express certificate.
The drawbacks would appear to relatively minor, and might literally amount to a
few
additional lines of code to search through the sequence of additional
attributes,
assuming that the attribute syntax is already specified. If not, and if the
attribute is really
needed, then it would have had to have been specified sooner or later in any
case.
I hope that this clarifies the proposal I put forward last Friday.
Bob