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?
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?
_______________________________________________
OPSAWG mailing list -- [email protected]
To unsubscribe send an email to [email protected]
