WG co-chair hat OFF
As a co-author of this draft I would like to respond to these comments.
On 03/12/2009, at 12:27 PM, Sandra Murphy wrote:
> In reviewing the repository structure draft, I was looking at the manifest
> draft to see if it answered some of my questions. I came up with the
> following comments on the manifests draft. This doesn't imply that I've done
> a full review of the manifest draft.
>
> These comments are made strictly as working group member. I do not make
> these comments as wg chair. Wg chair hat off.
>
>
>
> comments on draft-ietf-sidr-rpki-manifests-05.txt
>
> (1) Multiple manifests
>
> It appears to me that the algorithm described in the manifest document:
>
> 3. Check that every file at the publication point appears in one and
> only one manifest, and that every file listed in each manifest
> appears at the publication point.
>
> implies that the union of the manifests matches the union of the objects at
> the publication point. So if multiple CAs publish in the same publication
> point, one manifest might list some of the objects produced by one CA and
> some of the objects produced by another, as long as another manifest
> associated with the other CA includes all the other objects produced by that
> CA.
>
> I don't think that is the intent. I thought a manifest was specific to one
> CA and listed all that CA's objects but no other CA's objects. Other
> language in the document says that a manifest contains objects associated
> with one CA. But this is the definitive text, and it would be good to have
> it precise.
>
I believe that section 2 of this document is already clear on this. I won't
reproduce the text here, but I note that the text in section 2 covers the
situation of multiple CA's using the same repository publication point.
It is true that the pseudo algorithms in sections 7 and 8.1 are not complete,
in that an implementor that relies on these sections and only these sections to
construct an implementation would not apply the necessary tests to validate
that the constraints in section 2 apply.
> (2) Manifests
>
> The document says that multiple CAs might publish objects in the same
> publication point. Manifests are supposed to list all objects produced by
> one CA. If there is just one CA publishing in a publication point, that's
> easy - retrieve all files from that publication point and compare to the
> manifest.
>
> If there are several CAs that publish to one publication point, what is the
> algorithm for the manifest to be checked? I'd guess:
>
> download all objects from publication point
>
> sort them out by which CA issued them or issued the EE that signed them
>
> pick the group that is associated with the CA that issued the EE that
> signed the manifest.
>
> check the manifest listing against that group
>
> Would it be good to actually mention this? (Presuming it is correct.)
I believe you are referring to the algorithm section 8.1, and step 3 in
particular. It appears that what you are wanting to do is provide some form of
algorithm for checking the Manifest Scope, as defined in section 2.
One way of doing this is to add a new step 5 to the steps listed in section 8.1
for the draft:
"5. Check that the contents of each manifest match the scope constraints as
specified in section 2."
I suspect that the process could be further improved by the addition of the
term "current manifest" to delineate between the most recent manifest issued by
a CA (the "current" manifest) and multiple "current" manifests issued by
multiple CAs.
The proposed text for the pseudo code is then:
1. For each entity using this publication point, select the entity's
current manifest (where the "current" manifest is the manifest
issued by this CA having highest manifestNumber among all valid manifests,
and
where manifest validity is defined in Section 7).
* If the publication point does not contain a valid manifest,
see Section 8.2 Lacking a valid manifest, the
following tests cannot be performed.
2. Check that the current time is between thisUpdate and nextUpdate.
* If the current time does not lie within this interval then see
Section 8.4, but still continue with the following tests.
3. Check that every file at the publication point appears in one and
only one current manifest, and that every file listed in each current
manifest that is published at this publication point also is
published at the publication point.
* If there exists files at the publication point that do not
appear on any manifest, or files listed in a manifest that do
not appear at the publication point then see Section 8.5 but
still continue with the following test.
4. Check that listed hash value of every file listed in each
current manifest matches the value obtained by hashing the file at the
publication point.
* If there exist files at the publication point whose hash does
not match the hash value listed in the manifest, then see
Section 8.6.
5. Check that the contents of each current manifest match the manifest scope
constraints as specified in section 2.
I'd like to confirm with you that the proposed text addresses your comments -
could you please let the WG know if this is indeed an acceptable approach to
the issue you have raised?
Geoff
WG Co-chair hat OFF
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
