BGPsec Algorithms, Key Formats, and Signature Formats
obsoletes
- rfc-8208 — BGPsec Algorithms, Key Formats, and Signature Formats
updates
- rfc-7935 — The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure
Extracted elements (21)
BGPsec uses ECDSA P-256 rather than the RSA-based algorithms in the rest of RPKI to achieve similar security with smaller keys and signatures, thereby reducing certificate and PDU sizes.
Private key format is left to local policy (Section 3.1.2), as it is an implementation concern not requiring interoperability specification.
Separate Experimentation (0xF7–0xFA) and Documentation (0xFB–0xFE) algorithm ID ranges are reserved so that experimental and documentation use cannot clash with deployed assigned algorithm IDs, preventing misconfiguration of production routing elements.
Algorithm agility transitions (key size updates, new signature/hash algorithms) are anticipated over time; RFC 6916 specifies the recommended procedures for such transitions in the RPKI context.
This document updates RFC 7935 to support a different algorithm for BGPsec certificate requests, a different Subject Public Key Info format for BGPsec certificates, and different signature formats — all differentiated from other RPKI certificates by the BGPsec Extended Key Usage OID defined in RFC 8209.
A router encountering a Documentation algorithm ID (0xFB–0xFE) SHOULD treat it as an unsupported algorithm as specified in RFC 8205 Section 5.2.
A router encountering an Experimentation algorithm ID (0xF7–0xFA) outside of an experimental network SHOULD treat it as an unsupported algorithm as specified in RFC 8205 Section 5.2.
ECDSA private keys for certificate requests and BGPsec UPDATE messages MUST be associated with the P-256 elliptic curve domain parameters, and the public key MUST use the uncompressed form.
ECPoint MUST be used to encode the certificate's subjectPublicKey field as specified in RFC 5480 Section 2.2.
Reserved algorithm IDs 0x00 and 0xFF MUST NOT be used in a Signature_Block; if encountered, the router MUST treat the BGPsec UPDATE message as malformed per RFC 4271.
The certificate and CRL signature field structure MUST follow RFC 7935 Section 4; the certification request and BGPsec UPDATE message signature field MUST follow RFC 3279 Section 2.2.3.
The ecdsa-with-SHA256 OID MUST appear in the PKCS #10 signatureAlgorithm field or CRMF POPOSigningKey algorithm field for BGPsec certificate requests.
The id-ecPublicKey OID MUST be used in the algorithm field of subjectPublicKeyInfo, with the associated parameters MUST being secp256r1, as specified in RFC 5480 Sections 2.1.1 and 2.1.1.1.
The signature algorithm used MUST be ECDSA with curve P-256, and the hash algorithm MUST be SHA-256, for algorithm suite identifier 0x01.
Unassigned algorithm IDs (0x02–0xF6) MUST NOT be used until officially assigned. A router encountering an unassigned algorithm ID in a Signature_Block SHOULD process it as an unsupported algorithm per RFC 8205 Section 5.2.
Five algorithm ID types are defined: Reserved (0x00, 0xFF), Signature (currently 0x01), Unassigned (0x02–0xF6), Experimentation (0xF7–0xFA), and Documentation (0xFB–0xFE).
The Algorithm Suite Identifier is a one-octet field within each Signature_Block of a BGPsec UPDATE message that identifies which digest and signature algorithm pair was used to produce the signature.
IANA created the 'BGPsec Algorithm Suites' registry in the RPKI group. One-octet algorithm suite identifiers map to digest and signature algorithm pairs. Future assignments require the Standards Action process. The registry currently includes 0x00 (Reserved), 0x01 (SHA-256/ECDSA P-256), 0x02–0xF6 (Unassigned), 0xF7–0xFA (Experimentation), 0xFB–0xFE (Documentation), and 0xFF (Reserved).
The security considerations of RFC 3279, RFC 5480, RFC 6090, RFC 7935, RFC 8209, and RFC 8205 apply to certificates, certification requests, and BGPsec UPDATE messages respectively. No new security considerations are introduced by this specification.
A BGPsec Signature Segment contains the Subject Key Identifier (SKI, 20 bytes), a 2-byte Length field, and a DER-encoded ECDSA signature encoded as per RFC 3279 Section 2.2.3 (typically 70–72 bytes for P-256).
The BGPsec Path Attribute Signature Block contains a 2-byte Length, a 1-byte Algorithm Suite Identifier, and one or more Signature Segments; the example shows a 191-byte Signature Block with Algo ID 0x01.