[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: single <auth> per cert (was Re: "auth" --> "tag" ?? )
Bryce, <bryce@digicash.com>, writes:
> On to a more technical issue, I'm still trying to understand
> the issues about having single or multiple <auth> (cum <tag>)
> fields in a cert. But even without understanding the issues,
> can I suggest that having only one is simpler, and is easier to
> use in simple applications? Perhaps more complex applications
> can (a) add a layer of abstraction on top of SPKI to handle
> certs in bundles and/or (b) wait for SPKI 1.1.
One point I don't fully understand relates to the certificate merging
rules and to multiple authorization tags in a cert. When we merge a
cert chain, we are suppose to intersect the auth tags. I never really
knew what this intersection meant, but I had tentatively supposed that
it referred to cases where there were multiple auth tags in a cert.
The intersect would then be a matter of simply identifying those tags
which match in all the certs being combined. This could be an automated
process which would not require understanding the actual meaning of the
tags.
However, with one auth tag per cert this interpretation, shaky as it
may have been, is certainly incorrect. In that case, I suppose the
intersection is a semantic operation which is tag specific. For example,
if the auth tag gave some authority to spend a certain amount of money,
then the intersection might be a matter of choosing the minimum value
specified in the tags.
This would imply that there is no way for an automated process to
perform the chain collapse unless it was armed with some understanding
of the meaning of the auth tags, sufficient to identify what it meant
to intersect them.
Hal
Follow-Ups: