Subject: [sidr] Manifests and the Repository Structure

From: Sandra Murphy <[email-masked]>
Date: Fri, 17 Oct 2008 13:44:54 -0400 (Eastern Daylight Time)

The repository structure document reads:

in section 2.2:

    Becuase a CA is associated with a single key pair an entity performss
    the equivalent of a key rollover operation by generating a new CA
    instance as well as a new key pair.  In such cases the entity may
    chose to continue of use a single repository publication point for
    both CA instances.  In such cases the repository publication pooint
    will contain the CRL, manifest and subordinate certificates of both
    CA instances.

In section 2.3, which is talking about multi-use EE certificates

    It is consistent with this specification, but not recommended
    practice, that all subordinate EE certificates of a given CA share a
    common publication repository.  In this case the repository
    publication point would contain multiple manifest objects, one for
    each EE certificate that has placed objects into this common
    publication point.  Each manifest is limited in scope to listing the
    objects signed by the EE certificate.

In section 3:

    o  Each CA publication directory in the publication repository should
       contain the products of this CA, including those objects signed by
       single-use EE certificates that have been issued by this CA.  The
       signed products of related CA's that are operated by the same
       entity may share the CA publication directory.  Aside from
       subdirectories, no other objects should be placed in a publication
       repository directory.

Rob Austein's message of 19 Sep 2008 says:

>The problem is that the manifest is a not a listing of the active
>entity's outputs, it's a listing of the outputs issued by a particular
>CA certificate.  Now that David has finished beating us up about the
>term "rollover", the mapping from CA to CA certificate is 1:1, just to
>further confuse matters, and we lack a good term for the entity that
>controls a publication point and maps 1:1 with the publication point.
>
>There's a subtlety here that may not be obvious (thanks to Sandy for
>asking about it): the publication point, in the sense of a filesystem
>directory, is common to all current CA certificates in use by this
>nameless entity that we used to call a CA.  Normally that's exactly
>one CA certificate, except during rollover, when both the old and new
>CA certificates are valid; now that David has whacked us with proper
>PKI terminology, the process that we call rollover is really a process
>of generating a new CA and reissuing all of the old CA's products
>under the new CA.
>
>The manifest, however, is specific to a particular CA certificate.
>This means that during rollover the manifest will not cover the entire
>content of the directory; instead, there will be two certificates,
>each with its own manifest, and the two manifests between them will
>cover the content of the directory.

My question to which Rob refers was about how many manifests exist at
a publication point.  I think the repository structure and Rob's
message indicate that there might be more than one manifest at a
publication point, and no one manifest covers all items in the
publication point.

I don't think that the current text in the manifests draft quite
carries that thought completely all the way through.  My question to
Rob last time was private, I'm taking the risky step of asking the
question this time in public.

For example, in the intro:

    A manifest is an object that lists of all of the other signed objects
    issued by the authority responsible for a publication point in the
    repository system.

Depending on whether "the authority" means what Rob calls "the nameless
entity" or "the CA certificate" (plus single use EE certificates signed
by the CA cert?) , this would mean either that the  manifest lists all
the signed objects in the publication point period,  or that the
manifest lists only those signed objects in the publication point that
were signed using just one private key.

For the purpose of writing the manifest validation code, I think the
difference matters.

Section 5.1 on manifest generation says only:

4.	Construct the manifest content.

Who knew that might need explaining?  My first guess at the algorithm
is something like: take the EE cert that (refers to the public key
that is associated with the private key that) will sign the manifest,
take the CA cert that (refers to the public key associated with the
private key that) signed the EE cert, and list all signed objects in the
publication point that are signed by (the private key yada yada) that CA
cert.  Except that the repository structure draft in section 2.2 & 3
says that the publication point also includes objects signed by an EE
certificate "where the EE certificate was issued by this CA".  I
believe that means that the manifest object also lists the signed
objects associated with EE certs in the publication point that
are associated with the CA cert.

And in section 8.1, Tests for Determining Manifest State

    For a given publication point, the relying party should perform the
    following tests to determine the manifest state of the publication
    point:

    1.  Select the manifest having highest manifestNumber among all valid
        manifests (where manifest validity is defined in Section
        Section 7).

I think this was intended to refer to choosing among manifests you have
downloaded, not multiple manifests at the publication point.

    3.  Check that every file at the publication point appears on the
        manifest, and that every file on the manifest appears at the
        publication point.

If a manifest lists only those signed objects signed by one particular
private key (aka signed by one particular "CA", if I read Rob's message
correctly above, or signed by a single use EE cert signed by this same
one particular "CA", if I read the repository structure draft
correctly), then this language needs to be made more precise, something
like: take the EE cert that was used in signing the manifest,
take the CA cert that was used in signing the EE cert, and list all
signed objects in the publication point that are signed by that CA
cert.  The repository structure draft in section 2.2 & 3 says that the
publication point also includes objects signed by an EE certificate
"where the EE certificate was issued by this CA".  I believe that means
that the manifest object also lists the signed objects associated with
EE certs in the publication point that are associated with the CA cert.

Yes?

That section reads further:

        *  If there exists files at the publication point that do not
           appear on the manifest, or files on the manifest that do not
           appear at the publication point then see Section 8.5
           but still continue with the following test.

If there are several manifests at the publication point, then this
branch gets taken every time, right?

Section 8.5 Mismatch between Manifest and Publication Point says:

    If there exist otherwise valid signed objects that do not appear on
    any manifest, then provided the manifest is not stale (see Section
    Section 8.4) it is likely that their omission is an error by the
    publisher.

The use of the word "any" here is important and indicates that you only
have an error condition if you check all the manifests, which means
you must aggregate the results of all the manifests before you decide
you have an error.  Yes?  But objects listed in any one manifest but
missing from the publication point constitute an error that you can
check in each manifest independently.  Right?

--Sandy
_______________________________________________
sidr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sidr

---

From: Geoff Huston <[email-masked]>
Date: Sat, 25 Oct 2008 09:46:24 +1100

Thanks for these comments Sandy.

I've tried to address these comments in the next release of the  
manifest draft (-04) which will be put into the internet drafts  
collection very shortly.

     Geoff