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 protected]
https://www.ietf.org/mailman/listinfo/sidr
