[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Multi-Tag-Cert Tag Creation and Validation
>I don't see any reason to have either cert-id or tag-id.
>A multi-tag cert, if we allow it, must be semantically identical to a set of
>single-tag certs with the same tags. Those single-tag certs don't have any
>tag-id and wouldn't need any cert-id.
I may be way off base here (its been known to happen) but I see a certain
utility in having all tags have a tag-id (of sorts), functionally the cert-id
originating ancestor cert granting the original authority. My reasoning:
1. It has been said that the relying party (cert verifier) represents both
the beginning and end of the validation chain. That is, when a key is
presented to it with a given request for services, the certificate(s) on
the key presented must eventually lead back to the verifier. If the tag
in question was only an authority delegated to it "from above", the
request should functionally be presented to the above principal.
2. I assume (wrongly?) that I may have my key, or keys, certified by many
distinct (or seemingly distinct) principals. While it may not be wise
to imbue too much in a single key, that should be my own problem. Under
the assumption that the presentation of my key + request to a verifier
causes them to gather up the (multiple) certificates on my key, they
could examine the enclosed tags discard those whose tag-id matches none
of their own autocerts. More to the point, my request would indicate
which authorities (tags) on my immediate cert(s) that I wish to exercise,
and these would have tag-ids indicating that the verifier is the issuer
of the original authority, so delegated at least as far as the issuer of
my own certs.
3. These tags-ids are not really required, but are intended as a convenience.
I assumed they would aid in the match-up of tags in chain-collapse.
Are there any major errors in my understanding of the basics here?