Hi Russ, > 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. > > > > I see and have no problem with this. > > > >> That is what this texts says, generate a > >> new EE certificate for each preficlen file. > > > > No, the text says "The Certification Authority (CA) SHOULD sign only one > > prefixlen file..." > > that literally means (at least to me) that the CA _itself_ signs a file. > > This is what triggered me, > > as CAs never sign application data (to my best knowledge). I believe more > > accurate > > wording should be chosen. > > I think the following resolves your concern. > > OLD: > > 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]). > > NEW: > > The Certification Authority (CA) The CA MUST > generate a new End Entity (EE) certificate for each signing of a > particular prefixlen file. The private key associated with the > EE certificate SHOULD sign only one prefixlen file. That is, > a new key pair SHOULD be generated > for each new version of a particular prefixlen file. > The EE certificate used in this fashion is termed a "one-time-use" > EE certificate (see Section 3 of [RFC6487]).
Yes, thank you. > >>> 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. > > > > If they were debated for that document, then perhaps some clarification > > should be given > > as to how interpret this combination of SHOULD and MUST (at least in this > > document). > > For me this combination is inconsistent. > > I hope the reference that is being added to RFC 9632 will provide the reader > with important context. See the > review from Michael Richardson. Russ, I read Michael's review (https://mailarchive.ietf.org/arch/msg/rtg-dir/p3Lspi2EcdhvI_4om9X44--o6Jc/) and RFC 9632 and also RFC 6487. I still have doubts whether my understanding is correct. Sorry for being nerd, but literally reading what is written in the draft ,I believe that the following sequence of actions is valid: 1. A new version of a prefixlen file appears 2. EE wants to sign this file, but it decides not to request a new certificate and to use an existing one instead (because of SHOULD) And another presumably valid sequence of actions: 1. A new version of a prefixlen file appears 2. EE wants to sign this file and requests a new certificate from CA 3. CA issues a new certificate (MUST) 4. EE ignores the new certificate and uses the old one to sign the new file (because of SHOULD) Are these sequences of actions acceptable? If yes, then the text above (the new text) means (in my understanding) that the CA MUST always issue a new EE certificate if it is requested to (it is obvious, IMHO, but let it be), but the EE is free (in some situations) not to request a new certificate (or is free to ignore the new certificate) and use an old one instead, but generally it is preferable to request a new certificate. Is this interpretation correct? If yes, then it would be helpful to at least hint what these situations might be. And in this case "one-time-use" of certificates is not guaranteed. If no, then I'm badly missing something and will be happy to learn what it is. > >>> 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. > > > > I understand this. But then no requirement should be given to > > make "additional checks specified in [RFC3779] associated with ... > > Autonomous System Identifier Delegation certificate extension" > > since this extension is never included in the said EE certificates. > > I now understand your comment. I suggest: > > OLD: > > 3. Construct and validate the certification path for the signer's > certificate. All of the needed certificates are expected to be > readily available in the RPKI repository. 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. > If certification path validation is unsuccessful, then validation > MUST fail. > > NEW: > > 3. Construct and validate the certification path for the signer's > certificate. All of the needed certificates are expected to be > readily available in the RPKI repository. 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. > If certification path validation is unsuccessful, then validation > MUST fail. Perfect, thank you. Regards, Valery. > >>> 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. > > > > Definitely. > > Russ= _______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
