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]).
>
>>> 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.
>
>>> 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.
>
>>> 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]
