Thanks, Mark, you've made some excellent comments.
Care to join me as coauthor of an Internet Draft?
Bob Jueneman writes:
Certificate::= SIGNED {SEQUENCE {
version[0] Version DEFAULT FOR PEM v3,
serialNumberCertificateSerialNumber,
signatureAlgorithmIdentifier,
issuerName,
validityValidity,
subjectName,
subjectPublicKeyInfoSubjectPublicKeyInfo,
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]
Good point. So be it. Unless the rules for when to use what style certificate
bother anyone?
Please don't re-use the tags - issuerAttributes and subjectAttributes should
have different numbers.
I'm not sure that I understand you here. Are you suggesting that if I want to
use an existing attribute, say description, that I should have to create one or
two new attributes, subjectDescription and issuerDescription? I hope not!
I'll grant that my knowledge of ASN.1 is far from comprehensive, but surely
we can tell the difference in the usage?
Are you suggesting that when I said
IssuerAttributes::=SET SIZE (1..MAX) OF AttributeTypeAndValue
SubjectAttributes::=SET SIZE (1..MAX) OF AttributeTypeAndValue
AttributeTypeAndValue::=SEQUENCE
type({AttributeType}),
value({AttributeValue ({SupportedAttributes}{(_at_)type)})}
I really should have said
IssuerAttributes::=SET SIZE (1..MAX) OF IssuerAttributeTypeAndValue
SubjectAttributes::=SET SIZE (1..MAX) OF SubjectAttributeTypeAndValue
IssuerAttributeTypeAndValue::=SEQUENCE
type({AttributeType}),
value({AttributeValue ({SupportedAttributes}{(_at_)type)})}
SubjectAttributeTypeAndValue::=SEQUENCE
type({AttributeType}),
value({AttributeValue ({SupportedAttributes}{(_at_)type)})}
If so, I would be happy to make the change, but I don't understand the reason
why.
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?
Well, because I was not too subtly trying to put pressure on the X.509 folks to
adopt
this suggestion. But if this certificate format is registered under the IANA,
the NADF, or
elsewhere with its own OID, do you really think that confusion would result?
(Did you pick 1972825 for some reason I missed, or was this just a large random
number?)
(Actually, this brings up a very important philosophical point regarding
obsolete
attributes. Presently, the ITU and various pilot projects are busily creating
new
attributes as people discover that X.520/X.521 doesn't really satisfy their
needs. Once
X.500 really gets rolling, individual organizations will start creating private
attributes
to meet _their_ needs. Presumably, other users and organizations may come to
see
the need for an attribute that someone else has registered, and may want to have
it promoted to a "higher" level, i.e., one that is more likely to be supported
by a
wider variety of DUAs, etc.)
(What then happens to the older attributes? And how should software such as
certificate
creation programs "know" to migrate to the new standard?)
(So far, the only hope for keeping the explosion of attrbutes under some form
of control
would seem to be the almost mandatory use by attribute creators of the
AttributeTypeDescription attribute discussed in the subschema administration
section of X.501 '93. It does at least provide a vay of disseminating the ASN.1
syntax of an arbitrary attribute, defines the various case matching rules,
etc., and
it provides a description field. I _hope_ that this is intended to be a
SEMANTIC
description, so that when such an attribute is presented to the user, she will
know what it is supposed to MEAN. I'm afraid, however, that the description
will be used to tell implementors what the ASN.1 was trying to say regarding
the syntax.)
(Lets suppose that the IETF adopts a new pemCertificate attribute, and that a
year or
two later the ITU adopts exactly the same definition. What happens then? One
possibility would be for the AttributeTypeDescription to be replaced with an
alias
of the new ITU definition. But this would leave the old attribute undefined, so
this
would only work if the old and the new attributes were precisely the same,
except
for the name and OID.)
(Another possibility would be to set the Obsolete flag in the
AttributeTypeDescription
to deprecate its further use, but this conveys no useful information as to what
the
replacement should be. It seems to me, then, that the AttributeTypeDescription
is in a sense broken, and that if the obsolete flag is set that there should be
a
seeAlso attribute present. This would serve as a pointer to the new attribute
that
replaces the old, or at least some text that explains what is going on.)
(Do you agree? If so, is there some mechanism whereby we can report this as a
defect?)
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?
I'm not that there is any strong advantage in the case of X.500. But then, I'm
not
yet up to speed on exactly how strong authentication will work within X.500.
Steve Kent implied that there would have to be a one-for-one match between
the DN of the user and the DN within the certificate, and I'm not so sure.
I can imagine that an entity (not necessarily a human) has multiple listings
(even for human users, especially in a Yellow Pages context), and yet he would
have only one identity certificate. Presumably the ACL implementation would
record
who is allowed to change what attributes, instead of providing "rights" within
the certificate itself -- I just don't know. But given all the problems we have
been
having in PEM, I have to anticipate that similar problems will arise in X.500.
My main point was to try to draw together X.500 authentication, PEM, AOCE, EDI,
and
similar applications with a certificate structure that was strong enought to
support them
all, at least from an identity standpoint.
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.
Interesting! How have people been coding this attribute, then? Are you
suggesting that
this should be included in an ID? Or was this just a reminder to the IANA or
whomever
that this still needed to be registered?
Richard Ankney also raised a couple of points:
1. To handle attributes in the UniqueID, why not: "The UniqueID BIT STRING
contains the DER encoding of a SET OF Attribute" or something similar?
At this point I think I'd rather leave well enough alone. I think we need
additional
attributes, not more stuff encoded within existing attributes. That's one
objection I
have to Francisco Jordan's contribution.
2. The UniqueID attribute is not (in my version of X.500 '93) used in the
RDN; thus it only helps in distinguishing serial reuse of the real DN.
Hmmn. You say the "real" DN. One use would be for the situation where a
single user has two certificates, and we need to be able to tell them apart.
Another reason for some additional attributes. Even if we had X.500 up and
running,
it would be necessary to have some way of indicating which certificate is
supposed to
be used for what. From an information hiding principle point of view, I hate to
go
mucking around inside the certificate trying to decide which one to select. Even
worse, IMHO, is DMS's encoding of attribute rights, clearance levels, etc.,
within
the algorithm-specific information.
A second use for the UID would be to distinguish between two users, either in
time or space, who happened to have the same DN. I think you are suggesting
that
some other "real" attribute should be used to separate such cases, such as a
multivalued RDN containing the commonName and serial (employee ID). If so, then
I think you are right.
Again, thanks for the useful comments.
Bob