Network Working Group S. Turner
Internet-Draft IECA
Updates: [ID.sidr-rpki-algs] July 26, 2011
Intended Status: Standards Track
Expires: January 27, 2012
BGP Algorithms, Key Formats, & Signature Formats
draft-turner-sidr-bgpsec-algs-00
Abstract
This document specifies the algorithms, algorithms' parameters,
asymmetric key formats, asymmetric key size and signature format used
in BGPSEC (Border Gateway Protocol Security). This document updates
the Profile for Algorithms and Key Sizes for use in the Resource
Public Key Infrastructure (draft-ietf-sidr-rpki-algs).
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 27, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Turner Expires January 27, 2012 [Page 1]
Internet-Draft BGPSEC Algorithms, Key & Signature Formats July 26, 2011
1. Introduction
This document specifies:
o the digital signature algorithm and parameters;
o the hash algorithm and parameters;
o the public and private key formats; and,
o the signature format
used by Resource Public Key Infrastructure (RPKI) Certification
Authorities (CA), and BGPSEC (Border Gateway Protocol Security)
speakers (i.e., routers). CAs use these algorithms when issuing
BGPSEC Router Certificates [ID.bgpsec-pki-profiles] and CRLs
[ID.sidr-res-cert-profile]. BGPSEC routers use these when requesting
certificates [ID.bgpsec-pki-profiles], generating BGPSEC Update
messages [ID.sidr-bgpsec-protocol], and verifying BGPSEC Update
messages.
This document is referenced by the BGPSEC specification [ID.bgpsec-
protocol] and the profile for BGPSEC Router Certificates and
Certification Requests [ID.bgpsec-pki-profiles]. Familiarity with
these documents is assumed. Implementers are reminded, however,
that, as noted in Section 2 of [ID.bgpsec-pki-profiles], the
algorithms used to sign CA Certificates, BGPSEC Router Certificates,
and CRLs are found in [ID.sidr-rpki-algs].
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
[RFC2119].
2. Algorithms
Four cryptographic algorithms are used to support BGPSEC:
o The signature algorithm used when issuing certificates and CRLs
MUST be as specified in [ID.sidr-rpki-algs].
o The signature algorithm used in certification requests and BGPSEC
Update messages MUST be Elliptic Curve Digital Signature
Algorithm (ECDSA) [DSS].
o The hashing algorithm used when issuing certificates and CRLs
MUST be as specified in [ID.sidr-rpki-algs].
o The hashing algorithm use when generating certification requests
and BGPSEC Update messages MUST be SHA-256 [SHS]. Hash
algorithms are not identified by themselves in certificates, or
Turner Expires January 27, 2012 [Page 2]
Internet-Draft BGPSEC Algorithms, Key & Signature Formats July 26, 2011
BGPSEC Update messages instead they are combined with the digital
signature algorithm (see below).
NOTE: The exception to the above hashing algorithm is the use of
SHA-1 [SHS] when CAs generate authority and subject key
identifiers [ID.bgpsec-pki-profiles].
To support BGPSEC, the algorithms are identified as follows:
o In certificates and CRLs, an Object Identifier (OID) is used.
The value and locations are as specified in section 2 of
[ID.sidr-rpki-algs].
o In certification request, an OID is used. The ecdsa-with-SHA256
OID [RFC5480] MUST appear in the PKCS #10 signatureAlgorithm
field [RFC4211] or in Certificate Request Message Format (CRMF)
POPOSigningKey signature field [RFC2986].
o In BGPSEC Update messages, the ECDSA with SHA-256 Algorithm Suite
Identifier from Section 7 is included in the Signature-Block
List's Algorithm Suite Identifier field.
3. Asymmetric Key Format
The RSA key pairs used to compute signatures on CA certificates,
BGPSEC Router Certificates, and CRLs are as specified in section 3 of
[ID.sidr-rpki-algs]. The remainder of this section addresses key
formats found in the BGPSEC router certificate requests and in BGPSEC
Router Certificates.
The ECDSA key pairs used to compute signatures for certificate
requests and BGPSEC Update messages MUST come from the P-256 curve
[RFC5480]. The public key pair MUST use the uncompressed form.
3.1. Public Key Format
The Subject's public key is included in subjectPublicKeyInfo
[RFC5280]. It has two sub-fields: algorithm and subjectPublicKey.
The values for the structures and their sub-structures follow:
o algorithm (which is an AlgorithmIdentifier type): The id-
ecPublicKey OID MUST be used in the algorithm field, as specified
in 2.1.1 of [RFC5480]. The value for the associated parameters
MUST be secp256r1, as specified in 2.1.1.1 of [RFC5480].
o subjectPublicKey: ECPublicKey MUST be used to encode the
certificate's subjectPublicKey field, as specified in Section 2.2
of [RFC5480].
Turner Expires January 27, 2012 [Page 3]
Internet-Draft BGPSEC Algorithms, Key & Signature Formats July 26, 2011
3.2. Private Key Format
Local Policy determines private key format.
4. Signature Format
The structure for the certificate's and CRL's signature field MUST be
as specified in Section 4 of [ID.sidr-rpki-algs]. The structure for
the certification request's and BGPSEC Update message's signature
field MUST be as specified in Section 2.2.3 of [RFC3279].
5. Additional Requirements
It is anticipated that BGPSEC will require the adoption of updated
key sizes and a different set of signature and hash algorithms over
time, in order to maintain an acceptable level of cryptographic
security to protect the integrity of BGPSEC. This profile should be
updated to specify such future requirements, when appropriate.
CAs and RPs SHOULD be capable of supporting a transition to allow for
the phased introduction of additional encryption algorithms and key
specifications, and also accommodate the orderly deprecation of
previously specified algorithms and keys. Accordingly, CAs and RPs
SHOULD be capable of supporting multiple RPKI algorithm and key
profiles simultaneously within the scope of such anticipated
transitions. The recommended procedures to implement such a
transition of key sizes and algorithms is not specified in this
document.
6. Security Considerations
The Security Considerations of [RFC3279], [RFC5480], [ID.sidr-rpki-
algs], and [ID.bgpsec-pki-profiles] apply to certificates. The
security considerations of [RFC3279], [ID.sidr-rpki-algs],
[ID.bgpsec-pki-profiles] apply to certification requests. The
security considerations of [RFC3279] and [ID.sidr-bgpsec-protocol]
apply to BGPSEC Update messages. No new security are introduced as a
result of this specification.
7. IANA Considerations
The Internet Assigned Numbers Authority (IANA) is requested to define
the "BGPSEC Algorithm Suite Registry" described below.
An algorithm suite consists of a digest algorithm and a signature
algorithm. This specification creates an IANA registry of one-octet
BGPSEC algorithm suite identifiers. Additionally, this document
registers a single algorithm suite which uses the digest algorithm
Turner Expires January 27, 2012 [Page 4]
Internet-Draft BGPSEC Algorithms, Key & Signature Formats July 26, 2011
SHA-256 and the signature algorithm ECDSA on the P-256 curve
[RFC5480].
BGPSEC Algorithm Suites Registry
Digest Signature Algorithm Suite Specification
Algorithm Algorithm Identifier Pointer
+----------------------------------------------------------------+
| SHA-256 | ECDSA P-256 | TBD | RFC 5480 |
+----------------------------------------------------------------+
Future assignments are to be made using either the Standards Action
process defined in [RFC5226], or the Early IANA Allocation process
defined in [RFC4020]. Assignments consist of a digest algorithm
name, signature algorithm name, and the algorithm suite identifier
value.
10. Acknowledgements
The author wishes to thank Geoff Huston for producing [ID.sidr-rpki-
algs], which this document is heavily based on.
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification
Request Syntax Specification Version 1.7", RFC 2986,
November 2000.
[RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and
Identifiers for the Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 3279, April 2002.
[RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of
Standards Track Code Points", BCP 100, RFC 4020, February
2005.
[RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure
Certificate Request Message Format (CRMF)", RFC 4211,
September 2005.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
Turner Expires January 27, 2012 [Page 5]
Internet-Draft BGPSEC Algorithms, Key & Signature Formats July 26, 2011
IANA Considerations Section in RFCs", BCP 26, RFC 5226, May
2008.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
[RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
"Elliptic Curve Cryptography Subject Public Key
Information", RFC 5480, March 2009.
[DSS] National Institute of Standards and Technology (NIST), FIPS
Publication 186-3: Digital Signature Standard, June 2009.
[SHS] National Institute of Standards and Technology (NIST), "FIPS
Publication 180-3: Secure Hash Standard", FIPS Publication
180-3, October 2008.
[ID.sidr-res-cert-profile] Huston, G., Michaelson, G., and R.
Loomans, "A Profile for X.509 PKIX Resource Certificates",
draft-ietf-sidr-res-certs, work-in-progress.
[ID.sidr-rpki-algs] Huston, G., "A Profile for Algorithms and Key
Sizes for use in the Resource Public Key Infrastructure",
draft-ietf-sidr-rpki-algs, work-in-progress.
[ID.sidr-bgpsec-protocol] Lepinski, M., "BGPSEC Protocol
Specification", draft-lepinski-bgpsec-protocol, work-in-
progress.
[ID.bgpsec-pki-profiles] Reynolds, M. and S. Turner, "A Profile for
BGPSEC Router Certificates, Certificate Revocation Lists,
and Certification Requests", draft-turner-sidr-bpgsec-pki-
profiles-00, work-in-progress.
11.1. Informative References
None.
Authors' Addresses
Sean Turner
IECA, Inc.
3057 Nutley Street, Suite 106
Fairfax, VA 22031
USA
Turner Expires January 27, 2012 [Page 6]
Internet-Draft BGPSEC Algorithms, Key & Signature Formats July 26, 2011
EMail: turners@ieca.com
Turner Expires January 27, 2012 [Page 7]