[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Bill, I agree with your basic observations, but you may be
oversimplifying somewhat. Nonetheless, I
Bill, I agree with your basic observations, but you may be oversimplifying somewhat. Nonetheless, I think you are
on to something important. Please forgive me if I refer to an X.509 V3 format for purposes of this discussion since
we haven't settled on anything else -- the important part of the discussion doesn't really have anything to do with
the format anyway.
>>> Bill Frantz <frantz@netcom.com> 04/24/96 04:24pm >>>
>It seems to me that there are two uses for certificates. I suspect we want to support both of them.
>(1) Certificates as Capabilities. In this use, I would expect that the entity (person or program) who wanted to
exercise some capability would pass the certificate giving it the authority along with the request to exercise that
authority. There would be no need for directory lookups except those needed by the entity to organize the
certificates it had been given. In addition to having several certificates, the entity might also have several
key-pairs, where only it knows that they represent the same entity.
According to Warwick Ford, at the ISO/IEC and ITU-T editing meeting on X.509 DAM1 certificate extensions, several
changes were made to the Draft Amendment that might be useful in supporting the kinds of requirements you have
discussed. Although I haven't yet seen the final text (Warwick promised to post it within a couple of weeks), one
of the changes was supposed to allow the use of a NULL Distinguished Name. In addition, several new options
were added to the GeneralName, including URI, IP-address, and objet identifier. This was in addition to the previous
name forms which included DNS names, RFC822 names, and I forget the others. The General name is now usable
for any of the following: end entity, CA, CRL issuer, and CRL distribution point.
(A number of other very good changes were made in the area of criticality, key usage bits, optional name
constraints, indirect CRLs, the hold mechanism, delta CRLs, and matching rules, but I'll let Warwick summarize
those, as they don't seem to be germane to this discussion.)
If, as I would argue, one of the primary purposes for having a Distinguished Name in a certificate is to facilitate the
indexing and retrieval of that certificate from a repository, then the absence of a DN would obviously make the
retrieval of a certificate somewhat more difficult, but if the entity claiming the capability also forwards the signed
certificate which validates the capability, then no repository may be necessary. If the subjectAlternateName field is
also NULL or missing entirely, then the X.509 certificate would collapse to approximately what you are discussing
-- a bare bones certificate which contains a public key (without necessarily stating or implying who is assigned or
bound to that key); plus one or more attributes, either standardized or private; plus an indication of who signed the
certificate, i.e., granted the capability. It is even conceivable, although I would hesitate to recommend it, that the
name of the issuer is not included in any form at all, implying that only the certificate chain back to an out-of-band
communicated root key can be used to validate the assignment of that capability. On the other hand, if you are
willing to make some use of a General Name for the issuer, then the new name constraints extension provides
some flexible mechanisms which can be used to control the propagation of capability granting authority, either by
name subordination or by subtree length.
Without arguing the pros or cons of ASN.1 and the structure of X.509 certificates, then, it appears that the new
amendments provide most of the capability to support capabilities :-) that might be required. Since that might be
very useful, even in an X.509 world, I would invite people who might be more familiar with capability architectures
than I am to look deeply at this problem, and see whether anything is missing.
>(2) Certificates as Identity Attributes. This is basically the X.500/X.509 directory lookup problem. You have some
kind of unique name for an entity and want to get a public key. Or perhaps you have some kind of attribute and
want to fetch the certificates which contain that attribute. This use of certificates can use third-party signers, to
validate the data, and perhaps some standards about the attributes (or unique name) to make searching system
usable. (N.B. A unique name is an attribute which is guaranteed to be included in only one certificate in this model.)
There are really two or three different and independent problems here. The first is how an entity might be named,
and the second is how any attribute, perhaps including the DN, might be searched for in a directory or database. IN
the case of X.500 directories, the DN is obviously intended as the primary search criteria, but the use of he
subjectAltnames as an alias or secondary search criteria is also obvious. And unlike the DN, the subjectAltname is
not necessarily restricted to being globally unique, although this may cause some interesting database design and
consistency issues. The second is who signs the certificate -- that could be an independent third party, or a
Kerberos-like ticket-granting authority, or even the second (relying) party. That really has to do with the trust model
and the CA's policy, but the flexibility is there to support such mechanisms.
I do disagree with your assertion that "a unique name is an attribute which is guaranteed to be included in only one
certificate." A unique name is guaranteed to be unique with respect to an entity, i.e., no other entity will have that
name. That does NOT mean that one entity could not have multiple certificates, and indeed in most cases this will
be the case. I will have one certificate for signature purposes, another for domestic encrypted e-mail, perhaps
another for electronic commerce, and maybe a few more with restricted key lengths so that correspondents in
encryption-challenged countries will still be able to have a limited degree of protection for their messages.
In the X.509 model, then, we can have as little as a single attribute per certificate, or as many as we choose.
These attributes may include, and by implication be bound to, a Distinguished Name in a wide variety of formats, in
order to facilitate the repository lookup problem, and in addition may contain aliases or alternate name forms. The
precise semantics regarding the equivalence (strict equivalence, subset, or superset) between these various
name forms are not specified in X.509, and probably should be specified in the CA's policy. To the extent that these
attributes may represent capabilities, it may be sufficient for the assignee to simply validate his request by digitally
signing his request and forwarding the appropriate certificate, or the user might include some form of ID by which
the certificate pertaining to that entity can be retrieved from a repository.
In addition, looking at the certificate as a capability-granting ticket, it appears that the existing mechanisms of
expiration date and CRL checking would be entirely sufficient for relatively long-lasting capabilities. For very
short-lived capabilities, it will be necessary to check with some on-line server, but exactly the same problem is
presented with respect to high-value transactions which are validated by a conventional identity certificate, .e.g.,
for stock trading.
>The first use would tend to encourage certificates which have only one meaning, to reduce the bandwidth
required to send them, while the second encourages certificates which say everything there is to be said about an
entity (with possible multiple signers), because of the tendency to want unique names. If we treat the unique
name as a non-unique attribute, then we have the situation where each entity can have many certificates in "the
database", and lookups can proceed by asking for all certificates where the name_attribute == X and
some_other_attribute == Y.
I believe that you are correct in looking at the bandwidth required to send a certificate along with a request, vs.
looking it up in a repository. Obviously this is a function of the application and the network topology, and it is
difficult to answer such a question in the abstract. The major conclusion from my point of view is that X.509 V3
seems to be capable of supporting all of the identified functional requirements reasonably well. Whether a different
means of encoding such certificates is a requirement issue seems to be primarily a religious question, depending
on your views regarding ASN.1
>Have I missed anything?
I don't think so, in general.
------------------------------------------------------------------------
Bill Frantz | The CDA means | Periwinkle -- Computer Consulting
(408)356-8506 | lost jobs and | 16345 Englewood Ave. frantz@netcom.com | dead teenagers | Los Gatos, CA
95032, USA