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

[Stephen Kent <[e-mail]>]

Tim,
> ...
> 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.
I agree that the focus of this discussion is files listed on a specific 
manifest. If a CA has a different key, and thus a different cert, the 
CRL issued under that key will be on a different manifest, and thus is 
not part of the concern here.
> 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.
One CRL per manifest is my goal as well.
> 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.

Steve