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

[Tim Bruijnzeels <[e-mail]>]

Hi Steve,

> On 6 May 2020, at 22:09, Stephen Kent <stkent=[e-mail]> wrote:
> 
>> I wonder how far we should get with listing all possible inconsistencies in this document, but from my developer’s perspective I think  we should list as much as possible, if we want RP software to behave in the same way.
> agreed.  I will try to address the inconsistencies you noted; feel free to suggest others.
>> 
>> Going through what we described in RFC8488, one of such inconsistencies is when manifest contains more than one CRL entry.
> RFC 8488 talks only about the requirement to omit the optional CRL filed in the generic CMS format we adopted. It does not address the issue you mention here, i.e., what if the manifest includes more than one CRL. But, I agree that there does not appear to be an explicit prohibition of having more than one CRL enumerated in a manifest. We should say this explicitly. Next question: what do we do if we encounter more than one?
>> Another is when the manifest is not in the publication point of a CA certificate. There are two distinct links from the CA certificate – one to the publication point, and one to the manifest. 
> yes, and 6487 does not say that the manifest must be in the directory specified by the pub point URI (id-ad-caRepository) Maybe we should revise 6487 to make that a requirement. I can address that here as well.
>> Technically, the manifest link could contain different directory than a publication point link. If you discover a manifest by following the manifest link, and follow the rules applied above, using the link from the CA cert (and not the location of the manifest), you would not catch this discrepancy.
>> Also note  that similar discrepancy could exist with the CRL location (as it also has its own link from the cert), but that one is covered by the new text above.
> yes, 6487 does not require the CRLDP to point to a file in the pub point specified by the id-ad-caRepository URL in the CA cert. Again, how about a revision to 6487 to clarify this? It would make life simpler.
> 

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

Did I miss anything still?

Tim