Re: [Sidrops] proposed, revised text for Section 6

[Oleg Muravskiy <[e-mail]>]

Steve,

> On 7 May 2020, at 17:38, Stephen Kent <[e-mail]> wrote:
> 
> Tim,
> 
>> ...
>> I agree.
>> 
>> I think all CA implementations already do the following, which is implied by RFC 6487 and 6481 in particular. But the text is not sufficiently explicit. Updates will help, especially RP software.
>> 
>> * There is only ever one (1!) *current* CA certificate issued for a given key (implied by RFC6492)
>> * This CA certificate has the following SIA entries:
>>     - id-ad-caRepository pointing to its full publication point
>>     - id-ad-rpkiManifest pointing to a manifest in that publication point
>>     - (still optionally) id-ad-rpkiNotify pointing to the RRDP (RFC 8182) notification file
>> 
>> * For a CA certificate (i.e. a single key) there will be ONE current MFT only
>> * For a CA certificate (i.e. a single key) there will be ONE current CRL only
>> * That CRL name and hash MUST match the one and only .crl file on the MFT
>> * Any issued (EE or CA) certificate under this CA certificate (single key) MUST use a CRLDP that matches the name of this .crl file, under the issuing CA certificate's id-ad-caRepository
> 
> This all sounds appropriate to me. I can state these assumptions in the intro for Section 6.

I like this as well.

> What do we want to do if we encounter two or more .crl files in a manifest? use the first one, ignore any others, and issue a warning?
> 
> What do we want to do if the CRLDP in a CA cert does not match the file name in the manifest? Issue a warning and use the .crl file from the manifest?

I would suggest that we only use a CRL that is on a manifest AND matches the CRLDP in a CA cert (and all the above conditions that Tim mentioned are also true). If there are also other CRLs in the manifest, we ignore them with a warning.  

If there are CRLs in the manifest, but none matches the CRLDP, we continue as if there is no valid CRL (so follow rules of section 6.1 of your revised text).

Oleg