Re: [Sidrops] draft-ietf-sidrops-6486bis-04.txt

[Tim Bruijnzeels <[e-mail]>]

Dear Steve,

Thank you for taking this effort!

I have some comments / questions I would like to bring up.


- Section 2 Manifest Scope

This section may benefit from a reference to RFC 6481. In particular, it may not be clear to the reader now that there MUST be only one CRL issued under a CA (certificate). Perhaps replace:
 
   o  the most recent CRL issued by this CA, and

With:

   o  the single, most recent, CRL issued by this CA [RFC 6481], and


- Section 3 Manifest Signing

Job talked a bit about this as well. From my point of view, I believe that all CA implementations use single-use EE certificates for manifests. I don't see a use-case for multi-use in this context.

This is not a showstopper to me, but I think that we have an opportunity to say the single use EE certificates MUST be used, and if we have just one option then this will make the document easier to parse and reason about. E.g. section 4.2.1 can be simplified.


- Section 5 Manifest Generation

There is no text here that says that the single use EE certificate for the previous manifest (if single-use applies) should be revoked. Although later it is implied that a manifest can be revoked. Is this intentional?

Currently my CA implementation revokes old manifests. It is trying to be thorough.

That said, I think there is little point in doing this. The reason is that if an RP would find the new CRL, but still have the old manifest because of some timing issue - then it would find that the CRL hash does not match what is said on the manifest. It would be a failed fetch as described in section 6. Revoking the current manifest on its current CRL is possible, but somewhat hard to achieve with single-use EEs (assuming random serials are used) as well as obviously ill-advised.

One could therefore argue that rather than revoking previous manifest, the 'thisUpdate' or possibly 'manifestNumber' should be leading in selecting an eligible manifest - should an RP have multiple validly signed and current manifests for the same CA somehow. Not revoking previous manifests would help to avoid the "chicken and egg" issue raised in section 6. It is not clear to me that this would really be less safe.

But look, really, rather than trying to pick an argument over this, I raise this because I would like to see explicit text in the document that says what's expected here :)


- Section 6

I believe we have had discussions as a WG and concluded that any current RPKI object (such as ROAs) which are NOT on a manifest can be considered out-of-scope and de-facto invalid by RP software. Notable exception to this would be objects which are never intended to be published inside the regular RPKI such as RSC and RTA objects in future. 

If I misunderstood please let me know. But otherwise might I suggest updating the first sentence:

Current:
 
   Each RP must determine which signed objects it will use for
   validating assertions about INRs and their use (e.g., which ROAs to
   use in the construction of route filters). ...

Suggest:

   Each RP MUST use the current manifest of a CA and add each listed
   file to the set of signed objects it will use for validating assertions
   about INRs and their use (e.g., which ROAs to use in the construction
   of route filters). Any files not listed on the manifest MUST NOT be
   used for validation, unless the profile of its RPKI object type
   explicitly states otherwise. ...


Tim


> On 1 Jun 2021, at 15:36, Stephen Kent <stkent=[e-mail]> wrote:
> 
> I revised the text in Section 6 to reflect the suggestion Ties de Kock made in an off-list exchange in late December of last year. Although our esteemed chairs said that someone else would assume responsibility for this I-D early this year, that has not happened. Moreover, there has been no more on-list discussion of this topic, so I elected to complete the agreed-upon changes and publish an update before the old version expired.
> 
> Steve
> 
> _______________________________________________
> Sidrops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidrops