[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Tag-lists
Carl --
Here is a proposal for having tag-lists in certificates. Rather than using
the (* set) proposal, which only allows tags if they have different
tag types, we use the following form instead of the (tag ...) form:
(tag-list (t1 ...)
(t2 ...)
...
... )
more-or-less as we talked about for ACL's. Here there are NO restrictions
on what the tag types t1, t2, ..may be; there may be repetitions.
(Note that I'm not proposing dropping *-sets; they are still useful for
other purposes.)
There is only one technical difficulty with allowing such forms into SDSI/SPKI.
Let me describe the problem, and then give a way of solving it.
The problem is that with a certificate chain, you don't know how to
compose/reduce them if they have tag-lists instead of tags. With two
certificates, each having a tag-list of size 100, there are 10000 possible
ways to try matching them up. Composing tag-lists is not a nice thing to
have in the system.
Solution: Make a rule that in a valid certificate chain, it must be specified
which tag in the tag-list is being used. That is, the system should
not have to figure it out; the creator of the certificate chain
should make this determination and indicate the solution.
Note: This doesn't really change things much. If the tags were broken out
into separate certificates, someone would still have to figure out
how to pick the right ones and order them into a chain.
Fine point: How to indicate the choice of tag to be used in the certificate?
This can be done with an auxiliary index into the tag-list.
Thus, a certificate-with-tag-list plus index can be treated just
as an ordinary certificate for certificate chain processing purposes.
I like the tag-list since it helps us unify ACL's and certificate bodies
further, and doesn't place arbitrary constraints on the list of tags you
can have with the *-set construction. It should help efficiency, since you
only have to sign one certificate body...
Ron Rivest
Follow-Ups: