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

[Stephen Kent <[e-mail]>]

Tim,

> 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


done.

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


I agree this change would make the doc simpler, but I need to hear from 
other CAs to confirm that NOBODY issues multi-use EE certs in manifest 
before making this change.

> - 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?

Recall that 4.2.1 calls for the manifest EE cert (if single use) to have 
a validity period that matches that of the manifest, to avoid the need 
to revoke that cert when a new manifest is issued. So, unless a new 
manifest is issued before the old one expires, it is intentional that 
the cert for the old manifest not be revoked.

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

does it do this in all cases? since you indicate that you are employing 
single-use EE certs here, that behavior runs counter to 4.2.1, unless 
the new manifest is issued before the old one expires. Also, do you 
remove the revoked EE cert from the CRL as soon as it expires, which 
should usually be before the next manifest is issued.

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

as I said, unless a CA issues a new manifest before the next scheduled 
issue time, this ought not be an issue.


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

The notion of manifest scope is defined in Section 2. It says that "... 
all published signed objects that are verifiable using EEcertificates 
[RFC6487] issued by this CA." are in scope. So, based on that text, it 
would seem that the RSC and RTA objects are in scope. Also, the RTA ID 
indicates that these objects may appear on a manifest, so I find the 
proposed, revised text confusing.

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