A Profile for BGPsec Router Certificates, Certificate Revocation Lists, and Certification Requests
updates
- rfc-6487 — A Profile for X.509 PKIX Resource Certificates
Extracted elements (23)
CAs are required by the RPKI Certificate Policy (RFC 6484) to issue properly formed BGPsec Router Certificates regardless of what is in the certificate request. This means CA behavior overrides request content: EE-only certificates are always issued, invalid Key Usage values are dropped, the BGPsec EKU is always added, and the SIA extension is always removed.
Operators may include multiple ASNs in a single BGPsec Router Certificate, but this creates a fragility: the certificate becomes invalid if any one ASN is removed from a superior CA certificate. Issuing separate certificates per ASN avoids this interdependency.
The BGPsec Router Certificate profile is intentionally based on the RPKI Resource Certificate profile (RFC 6487), and issuance has minimal impact on existing RPKI CAs because CA certificate and CRL profiles remain unchanged; only processing of a new profiled certificate request is added.
BGPsec Relying Parties must support two distinct algorithm suites: RFC 8208 algorithms for validating BGPsec signatures, and RFC 7935 algorithms for validating signatures on BGPsec certificates, RPKI CA certificates, and RPKI CRLs.
BGPsec Router Certificates are not used to process manifests and ROAs or to verify signatures on Certificates or CRLs; their use is limited to verifying BGPsec certificate request signatures (by CAs) and BGPsec UPDATE message signatures (by BGPsec routers).
A BGPsec router MUST require the EKU extension be present in a received BGPsec Router Certificate and MUST reject certificates that do not contain the BGPsec Router EKU, even if they include the anyExtendedKeyUsage OID.
BGPsec Router Certificate requests: if the EKU extension is included, id-kp-bgpsec-router MUST be present and the CA MUST honor the request for that value.
BGPsec Router Certificate validation requires: the BGPsec Router EKU must be present, SIA and IP Resources extensions must be absent, AS Resources extension must be present, and the subjectPublicKeyInfo must conform to RFC 8208.
BGPsec Router Certificates MUST include the Extended Key Usage (EKU) extension containing the id-kp-bgpsec-router OID (id-kp 30). This extension must not be marked critical.
BGPsec Router Certificates stored in a repository following RFC 6481 MUST use a .cer filename extension for the certificate file.
Each BGPsec Router Certificate MUST include the AS Resources extension with one or more ASNs, and the 'inherit' element MUST NOT be specified.
In certificate request processing, the CA MUST NOT honor the cA boolean if set to TRUE in the Basic Constraints extension, and MUST NOT honor requests to include the SIA extension.
It is RECOMMENDED that the Subject common name attribute contain the literal string 'ROUTER-' followed by the 32-bit ASN encoded as eight hexadecimal digits, and the serial number attribute contain the 32-bit BGP Identifier encoded as eight hexadecimal digits.
The IP Resources extension MUST be omitted from BGPsec Router Certificates; it is not used in this context.
The Subject Information Access (SIA) extension MUST be omitted from BGPsec Router Certificates; it is not used in this context.
BGPsec Router Certificates are EE certificates only; the Basic Constraints extension must not be present. The private key may be used multiple times to generate signatures across multiple BGPsec_PATH attribute Signature Segments.
The BGPsec Router Certificate is an X.509 EE certificate issued under an RPKI CA certificate. It binds one or more ASNs to a public key, authorizing the router holding the corresponding private key to emit BGPsec UPDATE messages on behalf of those ASes.
The id-kp-bgpsec-router Extended Key Usage OID is defined as { id-kp 30 }, where id-kp is the standard PKIX key purpose arc { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) kp(3) }.
The subjectPublicKeyInfo field in BGPsec Router Certificates is specified by RFC 8208, which defines the BGP-specific algorithms and key formats. This differs from the algorithms used for RPKI CA certificates (RFC 7935).
This document updates two OID entries in IANA's SMI Security for PKIX registries: id-mod-bgpsec-eku (module identifier, id-mod 84) in the 'SMI Security for PKIX Module Identifier' registry, and id-kp-bgpsec-router (id-kp 30) in the 'SMI Security for PKIX Extended Key Purpose' registry.
A BGPsec Router Certificate's essential security function is the secure binding of one or more ASNs to a public key, consistent with the RPKI allocation/assignment hierarchy. It validates signatures on BGPsec Signature Segment origination of signed path segments per RFC 8205.
A BGPsec Router Certificate will fail standard RPKI validation (RFC 6487) because its cryptographic algorithms differ from those used for RPKI CA certificates. Relying Parties must identify the EKU to determine the appropriate validation constraint and algorithm set.
Hash collisions in Subject Key Identifier or Issuer Key Identifier generation are unlikely but possible. A Subject Key Identifier collision might cause the incorrect certificate to be selected from cache, resulting in failed signature validation; operators should be alerted if detected.