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

[Tim Bruijnzeels <[e-mail]>]

Dear Steve, WG,

> On 14 Jun 2021, at 15:53, Stephen Kent <stkent=[e-mail]> wrote:
> 
> 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.

Krill defaults to 24 hours for the next update time on CRLs and Manifests. The not-after time on the manifest EE currently still defaults to 7 days following discussions we had about this in sidr many years ago. I am quite happy to change this match the next update time instead as this document now instructs.

But in any case a new Manifest and CRL are issued by default 8 hours before they would go stale. I don't dare to leave this much longer, I think a CA operator needs this window to be able to deal with unforeseen outages.

When a manifest is replaced the previous EE cert is revoked - and its not-after (expire) time is remembered. When that time has passed the entry is removed.

All these values are configurable. I don't know for sure how other CA implementations do this. It would be good to hear from them. Based on memory at least the RIPE NCC managed CA uses a similar strategy.


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

As above, I don't dare to leave this to the last moment.

Furthermore, there could be other changes like a change in ROAs that require a new manifest to be issued.

Which reminds me.. I am not sure now if or where this is required, but in order to keep things simple to reason about I always issue a new manifest and CRL together.

It's not that the CRLs get huge, because revocations for expired EE certificates get removed as well. But, then again, I still think these manifest EE revocations are most likely not needed at all because with this -bis because RPs would only accept a new CRL with a changed hash, when they have already seen the replacement manifest.

> 
> 
> 
>> - 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 EE certificates [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. 

I am not vested in the text I proposed.

I believe that for normal top-down validation RPs need not consider any objects not found on manifests. This seems to align with what you are saying.

But what I am after is the following. RTA as proposed supports the idea of out-of-band exchanges of RTA objects, where those objects may NOT appear in RPKI. I believe RSC supports this option as well (but I need to re-read). So, in short, they may or may not appear on manifests. So, I would prefer that RPs can still do ad-hoc validation of RTA objects which they received out-of-band. Typically the RTA EE certificate would refer to a CRL and parent CA certificate which can be found in the RPKI (and manifests).

Open to other text and discussion.

Tim


> 
>> 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
> _______________________________________________
> Sidrops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidrops