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?

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?

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.

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.


Nits:
1. From reading Section 6 it was not immediately clear for me what is meant by "address range"
   in the context of signing certificate (e.g., in the sentence "The address range 
   of the signing certificate MUST cover all prefixes in the signed prefixlen file.".
   As I realized later, this address range is specified in the IP Address Delegation Extension
   defined in RFC 3779, but this is not explicitly mentioned in the draft.
   It would be helpful if this is said explicitly referencing RFC 3779 close to the beginning of Section 6.

2. Section 6. In the same sentence "The address range of the signing certificate MUST cover all prefixes
   in the signed prefixlen file." I wonder why a single address range is mentioned. 
   From my reading of RFC 3779 the IP Address Delegation Extension can specify multiple ranges, 
   not a single one (SEQUENCE OF IPAddressOrRange).

3. Section 6. I'd rather move para starting with "An address range A "covers" address range B..." closer 
   to the requirement "The address range of the signing certificate MUST cover all prefixes in the signed 
   prefixlen file." for readability. 

4. Section 6. I think that the following requirement "All of the above steps MUST be successful to consider the prefixlen
   file signature as valid." is not needed - the draft already have RFC 2119 language for each step of the validation algorithm.

5. Section 7. "The prefixlen files MUST be published via and fetched using HTTPS [RFC9110]." While I think this is 
   a good requirement, I wonder why other secure protocols are prohibited? Or say out-of-band delivery?

6. Section 7. "To dedicate a signing private key for signing a prefixlen file, an RPKI
   Certification Authority (CA) may issue a subordinate certificate
   exclusively for the purpose shown in Appendix A.". I believe "as" is missing here, but even in this case
   I'd rather make this sentence more clear by clarifying the purpose.
   I also wonder whether "may" should be "MAY" here.

7. Section 8 uses acronim CGNAT. Perhaps CGN is meant?