Skip to main content

A Profile for BGPsec Router Certificates, Certificate Revocation Lists, and Certification Requests
RFC 8209

Yes

Alvaro Retana

No Objection

(Alexey Melnikov)
(Alia Atlas)
(Alissa Cooper)
(Benoît Claise)
(Deborah Brungard)
(Joel Jaeggli)
(Mirja Kühlewind)
(Spencer Dawkins)
(Suresh Krishnan)
(Terry Manderson)

Note: This ballot was opened for revision 18 and is now closed.

Alvaro Retana Yes

(Alexey Melnikov; former steering group member) No Objection

No Objection (for -19)

                            

(Alia Atlas; former steering group member) No Objection

No Objection (for -19)

                            

(Alissa Cooper; former steering group member) No Objection

No Objection (for -19)

                            

(Ben Campbell; former steering group member) No Objection

No Objection (2017-01-04 for -19)
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.

(Benoît Claise; former steering group member) No Objection

No Objection (for -19)

                            

(Deborah Brungard; former steering group member) No Objection

No Objection (for -19)

                            

(Jari Arkko; former steering group member) No Objection

No Objection (2017-01-05 for -20)
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

(Joel Jaeggli; former steering group member) No Objection

No Objection (for -19)

                            

(Kathleen Moriarty; former steering group member) No Objection

No Objection (2017-01-04 for -19)
Following along with Stephen's discuss thread.

(Mirja Kühlewind; former steering group member) No Objection

No Objection (for -19)

                            

(Spencer Dawkins; former steering group member) No Objection

No Objection (for -19)

                            

(Stephen Farrell; former steering group member) (was Discuss) No Objection

No Objection (2017-01-04 for -20)
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.

(Suresh Krishnan; former steering group member) No Objection

No Objection (for -19)

                            

(Terry Manderson; former steering group member) No Objection

No Objection (for -19)