Subject: [sidr] comments on draft-ietf-sidr-rpki-manifests-05.txt

From: Sandra Murphy <[email-masked]>
Date: Wed, 2 Dec 2009 20:27:00 -0500 (Eastern Standard Time)

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.

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

--Sandy

---

From: Geoff Huston <[email-masked]>
Date: Sat, 5 Dec 2009 08:49:18 +1100

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

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