Skip to main content

BGPsec Algorithms, Key Formats, and Signature Formats
RFC 8608

Yes

Warren Kumari

No Objection

(Alissa Cooper)
(Barry Leiba)
(Deborah Brungard)
(Magnus Westerlund)
(Mirja Kühlewind)

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

Alvaro Retana Yes

Comment (2019-04-11 for -04)
I support Alexey's DISCUSS: this document should be marked as Obsoleting rfc8208.

Warren Kumari Yes

Roman Danyliw No Objection

Comment (2019-04-03 for -04)
Thank you for this easy to read update to RFC8208.  Below are a few editorial comments:

(1) Section 1. Editorial nit. 
s/BGPsec uses a different algorithm [RFC6090] [DSS] as compared to the rest of the RPKI by using a different algorithm that provides similar security with smaller keys making the certificates smaller;/
BGPsec uses a different algorithm [RFC6090] [DSS] as compared to the rest of the RPKI that provides similar security with smaller keys making the certificates smaller;/

(2) Section 2.  Editorial nit.
s/This section addresses BGPsec algorithms; for example, these algorithms are used by BGPsec routers to sign and verify BGPsec UPDATE messages./
This section addresses the algorithms used by BGPSec [RFC6090] [DSS].  For examples, these algorithms are used by BGPSec routers to sign and verify BGPsec UPDATE messages./

(3) Section 2.  The sentence “To identify which algorithm is used, the BGPsec UPDATE message contains the corresponding algorithm ID in each Signature_Block of the BGPsec UPDATE message” seems redundant given that the first sentence of Section 2.1 says something very similar.

(4) Section 2.1. Editorial nit.  Make the use of constants here consistent with the description of “special-use Algo ID”.  s/0x00 and 0xFF/0x00 (0) and 0xFF (255)/

(Adam Roach; former steering group member) (was Discuss) No Objection

No Objection (2019-04-15)
Thanks for addressing my DISCUSS.

(Alexey Melnikov; former steering group member) (was Discuss) No Objection

No Objection (2019-04-15)
Thank you for addressing my DISCUSS.

(Alissa Cooper; former steering group member) No Objection

No Objection (for -04)

                            

(Barry Leiba; former steering group member) No Objection

No Objection (for -04)

                            

(Benjamin Kaduk; former steering group member) No Objection

No Objection (2019-04-08 for -04)
Section 2.2.1

   Hash algorithms are not identified by themselves in certificates or
   BGPsec UPDATE messages.  They are represented by an OID that combines
   the hash algorithm with the digital signature algorithm as follows:

   o  The ecdsa-with-SHA256 OID [RFC5480] MUST appear in the Public-Key
      Cryptography Standards #10 (PKCS #10) signatureAlgorithm field
      [RFC2986] or in the Certificate Request Message Format (CRMF)
      POPOSigningKey algorithm field [RFC4211]; where the OID is placed
      depends on the certificate request format generated.

The first paragraph talks of "certificates" but this last sentence talks
about "certificate request"s.  Are we trying to talk about both?

Section 7

The IANA considerations are perhaps not as accurate as they could be.
For example, we could say that the BGPsec Algorithm Suite Registry was
originally created by RFC 8208 and has been updated to refer to this
document, and similarly for the P256-SHA256 codepoint.
(Just moving the references over would seem to be even more appropriate
if this document were fully Obsoleting 8208.)

Appendix A

Do we want to note that the certificates are expired but the examples
are still useful within that constraint?  (They were valid at the time
RFC 8208 was published but it seems imprudent to try to assume that the
examples would always be valid, when writing a document such as this.)

(Deborah Brungard; former steering group member) No Objection

No Objection (for -04)

                            

(Magnus Westerlund; former steering group member) No Objection

No Objection (for -04)

                            

(Martin Vigoureux; former steering group member) No Objection

No Objection (2019-04-11 for -04)
Hi

if this obsoletes 8208 then the iana registry looks fine.
If it is an update I see no reason to change the reference from 8208 to This Document for the identifiers 8208 had defined.

-m

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

No Objection (for -04)

                            

(Suresh Krishnan; former steering group member) No Objection

No Objection (2019-04-10 for -04)
Thanks for providing a BGPsec IPv6 example. I think it would be better if the next hop address comes out of the documentation range instead of the benchmarking range.