--- 1/draft-ietf-sidrops-bgpsec-algs-rfc8208-bis-02.txt 2018-09-20 08:13:12.122507706 -0700 +++ 2/draft-ietf-sidrops-bgpsec-algs-rfc8208-bis-03.txt 2018-09-20 08:13:12.166508761 -0700 @@ -1,19 +1,19 @@ Internet Engineering Task Force (IETF) S. Turner Internet-Draft sn3rd Updates: 8208 (if approved) O. Borchert Intended status: Standards Track NIST -Expires: March 9, 2019 September 5, 2018 +Expires: March 23, 2019 September 19, 2018 BGPsec Algorithms, Key Formats, and Signature Formats - draft-ietf-sidrops-bgpsec-algs-rfc8208-bis-02 + draft-ietf-sidrops-bgpsec-algs-rfc8208-bis-03 Abstract This document specifies the algorithms, algorithm parameters, asymmetric key formats, asymmetric key sizes, and signature formats used in BGPsec (Border Gateway Protocol Security). This document updates RFC 8208 ("BGPsec Algorithms, Key Formats, and Signature Formats") by adding Special-Use Algorithm IDs and correcting the range of unassigned algorithms IDs to fill the complete range. @@ -105,22 +105,24 @@ This document updates [RFC7935] to add support for a) a different algorithm for BGPsec certificate requests, which are issued only by BGPsec speakers; b) a different Subject Public Key Info format for BGPsec certificates, which is needed for the specified BGPsec signature algorithm; and c) different signature formats for BGPsec signatures, which are needed for the specified BGPsec signature algorithm. The BGPsec certificates are differentiated from other RPKI certificates by the use of the BGPsec Extended Key Usage as defined in [RFC8209]. BGPsec uses a different algorithm [RFC6090] - [DSS] as compared to the rest of the RPKI to minimize the size of the - protocol exchanged between routers. + [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; these algorithms also result in smaller + signatures, which makes the PDUs smaller. Appendix A contains example BGPsec UPDATE messages as well as the private keys used to generate the messages and the certificates necessary to validate the signatures. 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in