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.

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

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

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

Regards,
Valery.

> Russ

_______________________________________________
OPSAWG mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to