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

Hi,

> On 13 May 2020, at 18:11, Stephen Kent <stkent=40verizon.net@dmarc.ietf.org> wrote:
> 
> Guys,
>>> I will revise the text describing how to handle this case, based on WG
>>> consensus. Your approach is very robust, but also complex. Since there
>>> should be only one CRL in the manifest, and since Tim says that no
>>> RPKI CA generates more than??? one, I tend to favor a simple
>>> requirement here, but ...
>> indeed no ca SHOULD push more than one CRL.  but i do not think i would
>> recommend not defending against it.
>> 
>> randy
> 
> I think we all agree that the revised Section 6 text needs to accommodate the possibility that a manifest will list more than one CRL, even though this OUGHT NOT happen (see RFC 6919). The only question?? is how hard do we require an RP to work if it encounters more than one CRL. I prefer a simple approach to selecting one, and a mandatory warning. Rob has offered a more sophisticated, and complex approach, based on his working RP code.

What may not have been clear from my earlier message is that I agree that in today's world it's worth supporting the possibility of more than one .crl like Rob A. has done.

That said, we are looking to improve things here, and reducing corner cases is good.

This is about the number of current .crl files on a manifest, not about files that may still linger in the repository under the directory - e.g. for other keys. Even if it is not explicit, RFC 6480 certainly points at having one CRL per keypair. And 6 out of 6 independent CA implementations have done exactly that. Therefore I think it would be perfectly safe to add a requirement in the MFT RFC update that there MUST be one CRL only. This will simplify things greatly for RPs.

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.

Tim

> 
> I await a consensus from the WG.
> 
> Steve
> 
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops