Re: [Sidrops] rev 4 (corrected CRLDP source changes, thanks to Tim)

Agree.

RIPE NCC’s validator 2 implemented somewhat complicated logic for 
picking up “the latest valid manifest with the latest valid CRL”
and in the validator 3 it had been changed to a much simpler version
“pick up the latest manifest, validate it, and makes sure it has 
a hash pointing to a valid CRL”.

In the last 2 years of running both versions we have not seen any 
discrepancies in the results reported by them that would be attributed 
to this specific change of the algorithm. So for all (99.9% of?) 
practical purposes, nailing it down to “manifest MUST include exactly 
one hash pointing to a CRL” would be preferable. Let alone it would 
allow for simpler and more efficient RP code.

--
Mikhail Puzanov,
Senior Software Engineer,
RIPE NCC

> On 15 May 2020, at 11:18, Oleg Muravskiy <oleg@ripe.net> wrote:
> 
> On 15 May 2020, at 09:08, Martin Hoffmann <martin@opennetlabs.com> wrote:
>> 
>> Stephen Kent wrote:
>>> Tim,
>>> 
>>>> If not, then indeed we need to have a discussion about how to deal
>>>> properly with multiple CRLS. E.g. do you check *all* of them for
>>>> each issued certificate, or do you only check the CRL matching the
>>>> CRLDP of that certificate? I would also be very curious to know
>>>> which use case warrants having this complexity.  
>>> 
>>> My suggestion is the KISS approach - first .crl file that has a valid 
>>> hash is the one to use, and others are ignored. That's less forgiving 
>>> than what Rob accommodates, but being forgiving here might take
>>> pressure of a CA to do its job properly.
>> 
>> I’m not sure it really does. Rather, it will lead to strange looking
>> issues: If the wrong CRL accidentally made it onto the manifest and it
>> comes first, all objects are invalid even though everything sort of
>> looks fine. This may even come and go if a CA reorders the CRLs when
>> it reissues the manifest[0]. If all CRLs are referenced by objects, some
>> objects suddenly are invalid while others aren’t.
>> 
>> I think invalidating the manifest with a clear warning is the more
>> straightforward approach and much easier to debug.
> 
> I tend to agree with this approach. It will keep RFC and validator’s code simple and force CAs to fix their bugs.
> 
> Oleg
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops