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

[Stephen Kent <[e-mail]>]

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

So, to be clear, a new CRL and manifest are issued every 24 hours, but 
the manifest EE cert has a 7-day lifespan, right? Since you say that the 
manifest EE cert is a one-time use, this clearly contradicts the text in 
the manifest spec. Please do change the validity interval.

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

It would seem that each old manifest cert lives on a CRL for about 6 
days, so there might be 5 or 6 of them on the CRL at any time, 
needlessly. That's not awful, but it's not pretty either.


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

I am curious- do you track how often a new manifest needs to be issued 
because a ROA has changed? It would be useful to know if manifests are 
being reissued frequently only because a timer dictates it, not because 
any object covered by the manifest has actually changed.

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

I don't think any text requires that a new CRL MUST be issued with every 
new manifest, although the opposite is obviously true if the old 
manifest EE cert is revoked. If a new manifest is issued 8 hours before 
the old one expires, and if there are no changes in the objects covered 
by the manifest, other than a new CRL, and if that CRL is also unchanged 
in terms of the revoked certs being listed, then there seems to be a lot 
of churn for no obvious reason.

> 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.
>
>> ... 
> 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.
cert path validation is always top-down, as per 5280 and its predecessors.
> 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).

Well, we've been reminded by Job that RSC doesn't assume distribution 
via the RPKI, so ...

I propose the following text to begin Section 6:

Each RP MUST use the current manifest of a CA to control addition of listed

files to the set of signed objects the RP employs for validating basic RPKI

objects: certificates, ROAs, and CRLs. Any files not

listed on the manifest MUST NOT be used for validation of these objects.

However, files not listed on a manifest MAY be employed to validate other

signed objects, if the profile of the object type explicitly states that

such behavior is allowed. Note that relying on files not listed in a

manifest may allow an attacker to effect substitution attacks against such

objects.

Steve