A Profile for BGPsec Router Certificates, Certificate Revocation Lists, and Certification Requests
draft-ietf-sidr-bgpsec-pki-profiles-21

A few strictly editorial comments:

- IDNits complains about some undefined references.

- Abstract: Why is the phrase "(to routers within an Autonomous System)" in parentheses?

-2: draft-ietf-sidr-bgpsec-protocol explicitly excludes non-capitalized versions of 2119 words. This draft does not. It seems different 2119 approaches among the various bgpsec draft could be confusing to the reader.

I'm posting a No-Objection, but I think Dale is correct in raising the remaining issues. Commenting those below:

> 3.1.1.  Subject 
> 
>   However, each
>   certificate issued by an individual CA MUST contain a Subject name
>  that is unique to that CA context.
> 
> E-mail from Sean Turner on 22 Dec 2016 says:
> 
>    I think this is just a case of a missing "CA" in front of the
word
>    "context" so tweaking it to: ".... that is unique to that CA
>    context".  The certs only need to be unique on a per CA basis the
>    subject name does not need to be unique across the whole of the
>    RPKI.  The combination of issuer+subject+serial # plus all the
>    parent certs provides the uniqueness.
> 
> However, there doesn't seem to be a standard meaning of the phrase
> "CA
> context".  I can't find any occurrences in any RFC or in any I-D
> other
> than draft-ietf-trans-threat-analysis-NN.

Is a good question.

> It seems to me that the best solution is to put a cleaned-up version
> of Sean's statement "The combination of issuer+subject+serial # plus
> all parent certs provides the uniqueness." into the draft, as that is
> admirably clear.  (Unless, of course, there is a standard PKI phrase
> for that requirement, in which case that could be used.)  For
> instance:
> 
>   However, the combination of subject name, serial number, issuer,
>   and certification path must be globally unique.

That would be clearer for me, assuming that is what was actually meant, of course :-)

> 3.3.  BGPsec Router Certificate Validation 
> 
>   The validation procedure used for BGPsec Router Certificates is
>   identical to the validation procedure described in Section 7 of
>   [RFC6487] (and any RFC that updates this procedure), as modified
>   below.  For example, in step 3: "The certificate contains all
>   field
>   that must be present" - refers to the fields that are required by
>   this specification.
> 
> This picks up the changes from Sean Turner's e-mail of 22 Dec 2016
> except it omits changing "that updates this procedure" to "that
> updates that procedure", which seems to me to necessary to make the
> wording correct.

I think that’s right.

>   step 3: "The certificate contains all field that must be present"
> 
> This doesn't match the text in RFC 6487, despite claiming to be
> quoted:
> s/all field/all fields/ and s/must/MUST/.

Right.

> 7.  IANA Considerations
> 
>   No IANA allocations are request of IANA, ...
> 
> I think this should be "No IANA allocations are requested of IANA",
> or
> probably better "No allocations are requested of IANA".
> 
> E-mail from Sean Turner on 22 Dec 2016 says "Alvaro had a similar
> comment on the IANA considerations and he suggested the first
> option.", but no change has been made.

OK

Following along with Stephen's discuss thread.

Thanks for addressing my discuss points. 

OLD COMMENTS below, I didn't edit 'em...

- section 2: I think this is a bit badly written: "The use
of BGPsec Router Certificates in no way affects RPKI RPs
that process Manifests and ROAs because the public key
found in the BGPsec Router Certificate is used only to
verify the signature on the BGPsec certificate request
(only CAs process these) and the signature on a BGPsec
Update Message [ID.sidr-bgpsec-protocol] (only BGPsec
routers process these)." Do you mean that there's no way
that an entity can confuse a Manifest, ROA, CSR or BGPsec
update so there's no issue with which public keys are used
to verify the signatures on those data structures?

- section 3: As noted in my comments on the BGPsec
protocol, it'd be better to call out the SKI here if you
don't add the direct ref to 6487 to the BGPsec protocol
draft.