[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Thoughts on the draft
> In message <199608272308.SAA09092@entropy.sbc.com>, "Brian M. Thomas" writes:
> Another example:
> Imagine an international Passport Certificate, which holds information
> about your person (name, address, nationality etc); each time you want
> to travel to some country which would require some sort of visa, you
> just go to their embassy and get your certificate signed (and it would
> expire when the visa would expire). Now, instead of having one
> certificate for each country, it might be easier to have just one
> certificate and multiple signatures.
The procedures that we have discussed for this kind of scheme basically
say that the operator at the embassy sees your passport cert, and on
verification of that (and your non-appearance on any list of suspected
international terrorists), he issues the visa, which says that his key
certifies that your key has permission to enter the country. Those who
depend on his certification do so because they trust him, not because
they trust the US passport office. Further, the signatures of the
other embassies are not interesting to this one, and are information
which you may not wish this embassy to know about.
The philosophy we have been espousing is that every privilege is
explicitly issued by one principal to another. Yes, this does cause
certificates to proliferate, but we tend to like this, because it more
closely constrains the meaning of each certificate.
> It also seems that some support for multiple signatures is there
> already, even if just to support the DUAL-SIG: attribute.
This is true, but the DUAL-SIG attribute exists specifically to support the
case where the subject itself must sign. This is the use that Carl points
out in S3.13 on unwanted attributions. I'm not entirely convinced on that
either; perhaps Carl will defend it, but I don't think it argues generally
for multiple issuer signatures.
> But it does not say anything (for or against) duplicate auth fields.
> If there is support for it, it should be explicitly declared.
Clarifying the language wouldn't hurt, I'm sure.
> I agree on the simplicity part, however i believe we can have shared
> certificates without using ASN1 or some other similarly (or more)
> complex monstrosity.
Certainly the language for specifying or encoding the cert wouldn't
have anything to do with its content. I referred, however, to
composition and usage rules that did not appear in the certificate
itself.
> I find however that this example is farther away from the PolicyMaker
> mindframe; what i have in mind is essentially a simplified (?) PM: one
> just provides a library that gives access to the internals of a
> certificate (chain) and then leaves the application do all the hard
> work. The analogy with WWW cgi-bin scripts comes to mind (imagine the
> attributes of a certificate as the variables passed on a script, which
> checks their validity). I'm not sure yet if this is a/the correct
> approach, but it seems so (to me) at this point.
Actually, I think that what I specified does that. What I don't think
should be on the application programmer's mind is whether a collection
of certificates actually adds up to a valid chain or not, just as with
RSADSI's TIPEM certificate library: you provide qualifications for a
chain (in this case, a subject name and name/key information for your
trusted root[s]), and it builds one, utilizing whatever methods you
pre-specify for finding them by their different attributes. You can
then examine each of the links in the chain independently if you wish.
But questions of whether a chain from one key as issuer to another key
as subject can be constructed are, hopefully, purely mechanistic, and
can be as long as the certs themselves are kept as simple as possible.
On top of all that, I wasn't really finding fault with your expression
of the methods; merely putting it out in a form that was easier for me
to understand. I've had to put up with that from Carl and Bill too,
and they from me, so don't be put off by that...
> I would be nice to have shared certificates though. For example,
> if X and Y are applications which are different but both trust an
> application Z's certificates, then it would make sense to just have Z
> create sharable certificates and X/Y use those fields of the
> certificate they really care about, instead of having Z create
> certificates depending on who it is destined for (of course, this is
> assuming that X's and Y's certificates are not all that different).
> - -Angelos
I really don't believe there is reason to invent a new mechanism to do what
simple certificates do more simply. In this case, if X and Y both trust Z,
they declare their trust severally by means of certificates. Therefore the
combination of certificates as(issuer, subject, auth):
(X, Z, <something indicating trust in Z, such as delegation>) and
(Z, user, <privilege>)
would work for X, whereas a similar cert for Y giving Z the same auth
would work for Y, and neither X nor Y had to have Z's certificate
in their possession to grant the permission. Notice that one or the
other had to get a copy of it first to sign it, then the other, then it
had to be passed back to the certificate repository. None of
this is necessary with this scheme, and the delegation of authority is
clear and precise. Again, when the chain was collapsed, the resultant
privilege was (X, user, <privilege>). Of course, X and Y can both
avoid all the individual interactions by saying in a policy cert:
(myKey, anyKey, <privilege, where anyKey presents a cert from Z>)
This, in the presence of Z's certificate above, would have the same
result. The draft also specifically mentions a similar idea in S3.8
concerning certificate structure, preferring the simpler single
signature scheme.
brian
Brian Thomas - Distributed Systems Architect bt0008@entropy.sbc.com
Southwestern Bell bthomas@primary.net
One Bell Center, Room 23Q1 Tel: 314 235 3141
St. Louis, MO 63101 Fax: 314 331 2755
Follow-Ups: