[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.  Assumptions:

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
    are

    [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.  Validation

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).

Conclusion:

    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)