Valery:
> Document: draft-ietf-opsawg-prefix-lengths
> Title: Publishing End-Site Prefix Lengths
> Reviewer: Valery Smyslov
> Review result: Has Issues
>
> I have reviewed this document as part of the security directorate's ongoing
> effort to review all IETF documents being processed by the IESG. These
> comments were written primarily for the benefit of the security area
> directors.
> Document editors and WG chairs should treat these comments just like any other
> last call comments.
>
> The document describes a way to augment the Routing Policy Specification
> Language with information about the length of the prefixes.
>
> Issues.
>
> 1. Section 6. The following text is confusing:
>
> The Certification Authority (CA) SHOULD sign only one prefixlen file
> with each generated private key and SHOULD generate a new key pair
> for each new version of a particular prefixlen file. The CA MUST
> generate a new End Entity (EE) certificate for each signing of a
> particular prefixlen file. An associated EE certificate used in this
> fashion is termed a "one-time-use" EE certificate (see Section 3 of
> [RFC6487]).
>
> First, in my understanding of how PKI works, CAs never signs anything rather
> than other certificates and CRLs, In particulat, CAs never sign application
> data. So I failed to understand what is the first sentence about. Am I missing
> something?
In the RPKI, an fresh EE certificate is generated for signing an object. That
is what this texts says, generate a new EE certificate for each preficlen file.
> Then, it is not clear to me how these SHOULD and MUST are aligned with each
> other and how the first SHOULD is aligned with "one-time-use" of EE
> certificate. For me this looks inconsistent. Am I missing something?
I do not recall the discussion that lead to this combination of SHOULD and
MUST. I would be fine with all of them being MUST; however, it aligns with the
text in RFC 9632. These words were originally debated for that document.
> 2. Section 6, list item 3.
>
> The certification path
> MUST be valid according to the validation algorithm in [RFC5280]
> and the additional checks specified in [RFC3779] associated with
> the IP Address Delegation certificate extension and the
> Autonomous System Identifier Delegation certificate extension.
>
> A few paras above there is a requirement:
>
> The signing certificate MUST NOT include the Autonomous System
> Identifier Delegation certificate extension [RFC3779].
>
> If the Autonomous System Identifier Delegation extension cannot
> be present in the certificate, then I wonder how to perform additional checks
> specified in RFC 3779 for this extension.
RFC 3779 talks about number resources, which are AS number and IP address
blocks. The EE certificate should only include IP address blocks.
> 3. Section 7. "If the prefixlen file is signed, and the signer's certificate
> changes, the signature in the prefixlen
> file MUST be updated."
>
> How a certificate can be changed? Perhaps the situation when the certificate
> becomes invalid (expired or revoked) is meant? But how to update the signature
> in this case? The CA must first issue a new certificate and only after that
> this "MUST" can be accomplished. So, I think this sentence should be expanded
> to clarify what is meant and what is the needed sequence of actions in this
> situation.
Would "replaced" work better? I suggest:
If the prefixlen file is signed, and the signer's certificate
is replaced with another certificate, then the signature in
the prefixlen file MUST be updated so that it can be properly
validated with the new certificate.
Russ
_______________________________________________
OPSAWG mailing list -- [email protected]
To unsubscribe send an email to [email protected]
