[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Multi-Tag-Cert Tag Creation and Validation
I outline here a scheme for multi-tag certificates that I believe makes the
"match-up" of tags straightforward, and also makes them exactly as unique as
they need to be. But you be the judge.
Creating and Verifying Multi-Tag Certificates:
1.1 Every certificate has a cert-id unique among those created by
a given issuer, and distinct from the cert-id of any ancestor
certificate from which the issuer key derives authorities of
interest. This applies to any issuer's autocerts as well.
Note: In a mesh, there may be multiple immediate "parent"
certs to a key. Between occasions where you have additional
certifications made to your key, the set of all possible
ancestor certificates to your key is fixed, and reasonably
assumed to be cached locally.
1.2 Every tag in a certificate you issue has a tag-id constructed
of the form <some-cert-id>-<small-index> detailed below.
HINT: For a single-tag cert, the tag-id is simply the cert-id
of the cert which grants your key-as-issuer authority.
1.3 With the exception of an originating autocert, the software that
supports you in contructing and signing a certificate
a. expects one or more parent certificates be present, along
with at least the cert-ids of all ancestors to the selected
parents (certificates where your key is the subject.)
This may be simply one of your autocerts.
b. allows you to select (and *diminish*) tags from any of these
parent cerificates, so automatically carrying over each tag's
tag-id, unchanged, into your taglist.
c. allows you to create new tags whose authority flows from a
selected autocert, with tag-ids formed by taking that cert-id
and appending a counter-number, local only to the certificate
being contructed. (Three-digit counters should suffice!)
You become the termination point in validating these tags.
1.4 Given any public key, you can locate/obtain all of that key's
current certificates. So by extension, you can gather the current
ancestry of certificates.
2. Certificate Creation:
2.1 You are principal Pi with key KPi.
To make the example interesting, assume that you have had your key
certified by principals P1 and P2 (KP1 and KP2). These certificates
[C1.KPi] KP1!(KPi,S1) (KP1 says KPi is authorized tags in S1)
[C2.KPi] KP2!(KPi,S2) (KP2 says KPi is authorized tags in S2)
(assume C1 and C2 both say "may-delegate")
Your autocert might be
[Ci.KPi] KPi!(KPi,Pi) (KPi says Pi is keyholder for KPi)
2.2 You create a certificate for friend Pn (KPn) with taglist T where
T = subset(union(S1,S2)) + tags authored with yourself as root.
Let us assume likewise that S1 and S2 are rooted by P1 and P2
for simplicity here.
This certificate for Pn would be [Ci.KPn] KPi!(KPn,T)
3.1 Principal Pn presents KPn to P1, asserting the right to exercize
some authorities t = subset(T). For a test of full coverage, we
may suppose t covers T and see what gets rejected. Put another
way, KPn asks what it is authorized for from P1, a worst-case.
3.2 Principal P1 conducts validation as follows: (an illustration)
(apologies for not rolling this up into an algorithm definition)
a. via KPn, consults cert [Ci.KPn] KPi!(KPn,T)
(T is root node in a mesh of taglists)
Since Kpi <> KP1:
b. via KPi, consults certs C1.KPi, C2.KPi, Ci.KPi
b.1 C1.KPi = KP1!(KPi,S1) [branch T.S1]
KP1 is self (verifier), so this completes 1 chain to self.
b.2 C2.KPi = KP2!(Kpi,S2) [branch T.S2]
Since KP2 <> KP1:
c. via KP2, consult (autocert) KP2!(KP2,P2)
But this is an alien autocert, so we backup the mesh to the previous
branch-point, discarding taglist S2.
Note: Had KP2 been certified by KP1, we would have determined this
at the next link, and kept branch T.S2.
b.3 Ci.KPi = KPi!(KPi,Pi)
This is another alien autocert. It is also an immediate parent to
Ci.KPn, so there is no branch to form (and hence to discard.)
3.3 This exhausts all possible paths to self (the verifier P1).
We now do a list-wise intersection of all taglists for the nodes
remaining in the mesh. In this particular case, it is just the
single branch T.S1 (ie, the taglists T and S1)
In general, we collect only those tags whose tag-id appears in
each remaining taglist, resulting in a set for each such tag-id.
On each tagset (single tag-id) we conduct tag-wise intersection,
reducing each set to a single tag.
These tags are accepted as valid to P1.
(apologies for arm-waving here, getting sleepy).
I believe this scheme for tag-id formation satisfies
a. proper threading of an end-tag through its anscestor tags.
b. makes tag-ids exactly as "global" as they need to be.
c. makes their generation meaningful rather than arbitrary.
(But don't take my word for it.)
____TONY____ (speaking for myself, as if)