< draft-ietf-sidr-bgpsec-algs-01.txt		draft-ietf-sidr-bgpsec-algs-02.txt >
	Secure Inter-Domain Routing Working Group S. Turner		Secure Inter-Domain Routing Working Group S. Turner
	Internet-Draft IECA		Internet-Draft IECA
	Updates: [ID.sidr-rpki-algs] December 5, 2011		Updates: 6485 (if approved) March 26, 2012
	Intended Status: Standards Track		Intended Status: Standards Track
	Expires: June 7, 2012		Expires: September 27, 2012
	BGP Algorithms, Key Formats, & Signature Formats		BGP Algorithms, Key Formats, & Signature Formats
	draft-ietf-sidr-bgpsec-algs-01		draft-ietf-sidr-bgpsec-algs-02
	Abstract		Abstract
	This document specifies the algorithms, algorithms' parameters,		This document specifies the algorithms, algorithms' parameters,
	asymmetric key formats, asymmetric key size and signature format used		asymmetric key formats, asymmetric key size and signature format used
	in BGPSEC (Border Gateway Protocol Security). This document updates		in BGPSEC (Border Gateway Protocol Security). This document updates
	the Profile for Algorithms and Key Sizes for use in the Resource		the Profile for Algorithms and Key Sizes for use in the Resource
	Public Key Infrastructure (draft-ietf-sidr-rpki-algs).		Public Key Infrastructure (RFC 6485).
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on June 7, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2011 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	skipping to change at page 2, line 16 ¶		skipping to change at page 2, line 16 ¶
	This document specifies:		This document specifies:
	o the digital signature algorithm and parameters;		o the digital signature algorithm and parameters;
	o the hash algorithm and parameters;		o the hash algorithm and parameters;
	o the public and private key formats; and,		o the public and private key formats; and,
	o the signature format		o the signature format
	used by Resource Public Key Infrastructure (RPKI) Certification		used by Resource Public Key Infrastructure (RPKI) Certification
	Authorities (CA), and BGPSEC (Border Gateway Protocol Security)		Authorities (CA), and BGPSEC (Border Gateway Protocol Security)
	speakers (i.e., routers). CAs use these algorithms when issuing		speakers (i.e., routers). CAs use these algorithms when issuing
	BGPSEC Router Certificates [ID.bgpsec-pki-profiles] and CRLs		BGPSEC Router Certificates [ID.bgpsec-pki-profiles] and CRLs
	[ID.sidr-res-cert-profile]. BGPSEC routers use these when requesting		[RFC6487]. BGPSEC routers use these when requesting BGPSEC
	BGPSEC certificates [ID.bgpsec-pki-profiles], generating BGPSEC		certificates [ID.bgpsec-pki-profiles], generating BGPSEC Update
	Update messages [ID.sidr-bgpsec-protocol], and verifying BGPSEC		messages [ID.sidr-bgpsec-protocol], and verifying BGPSEC Update
	Update messages [ID.sidr-bgpsec-protocol].		messages [ID.sidr-bgpsec-protocol].
	This document is referenced by the BGPSEC specification [ID.bgpsec-		This document is referenced by the BGPSEC specification [ID.bgpsec-
	protocol] and the profile for BGPSEC Router Certificates and		protocol] and the profile for BGPSEC Router Certificates and
	Certification Requests [ID.bgpsec-pki-profiles]. Familiarity with		Certification Requests [ID.bgpsec-pki-profiles]. Familiarity with
	these documents is assumed. Implementers are reminded, however,		these documents is assumed. Implementers are reminded, however,
	that, as noted in Section 2 of [ID.bgpsec-pki-profiles], the		that, as noted in Section 2 of [ID.bgpsec-pki-profiles], the
	algorithms used to sign CA Certificates, BGPSEC Router Certificates,		algorithms used to sign CA Certificates, BGPSEC Router Certificates,
	and CRLs are found in [ID.sidr-rpki-algs].		and CRLs are found in [RFC6485].
	This document updates [ID.sidr-rpki-algs] to add support for a) a		This document updates [RFC6485] to add support for a) a different
	different algorithm for BGPSEC certificate requests, which are only		algorithm for BGPSEC certificate requests, which are only issued by
	issued by BGPSEC speakers; b) a different Subject Public Key Info		BGPSEC speakers; b) a different Subject Public Key Info format for
	format for BGPSEC certificates, which is needed for the specified		BGPSEC certificates, which is needed for the specified BGPSEC
	BGPSEC signature algorithm; and, c) a different signature format for		signature algorithm; and, c) a different signature format for BGPSEC
	BGPSEC signatures, which is needed for the specified BGPSEC signature		signatures, which is needed for the specified BGPSEC signature
	algorithm. The BGPSEC certificate are differentiated from other RPKI		algorithm. The BGPSEC certificate are differentiated from other RPKI
	certificates by the use of the BGPSEC Extended Key Usage defined in		certificates by the use of the BGPSEC Extended Key Usage defined in
	[ID.bgpsec-pki-profiles].		[ID.bgpsec-pki-profiles].
	1.1. Terminology		1.1. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	[RFC2119].		[RFC2119].
	2. Algorithms		2. Algorithms
	Four cryptographic algorithms are used to support BGPSEC:		Four cryptographic algorithms are used to support BGPSEC:
	o The signature algorithm used when issuing BGPSEC certificates and		o The signature algorithm used when issuing BGPSEC certificates and
	CRLs, which would revoke BGPSEC certificates, MUST be as		CRLs, which would revoke BGPSEC certificates, MUST be as
	specified in [ID.sidr-rpki-algs].		specified in [RFC6485].
	o The signature algorithm used in certification requests and BGPSEC		o The signature algorithm used in certification requests and BGPSEC
	Update messages MUST be Elliptic Curve Digital Signature		Update messages MUST be Elliptic Curve Digital Signature
	Algorithm (ECDSA) [RFC6090].		Algorithm (ECDSA) [RFC6090].
	o The hashing algorithm used when issuing certificates and CRLs		o The hashing algorithm used when issuing certificates and CRLs
	MUST be as specified in [ID.sidr-rpki-algs].		MUST be as specified in [RFC6485].
	o The hashing algorithm use when generating certification requests		o The hashing algorithm use when generating certification requests
	and BGPSEC Update messages MUST be SHA-256 [SHS]. Hash		and BGPSEC Update messages MUST be SHA-256 [SHS]. Hash
	algorithms are not identified by themselves in certificates, or		algorithms are not identified by themselves in certificates, or
	BGPSEC Update messages instead they are combined with the digital		BGPSEC Update messages instead they are combined with the digital
	signature algorithm (see below).		signature algorithm (see below).
	NOTE: The exception to the above hashing algorithm is the use of		NOTE: The exception to the above hashing algorithm is the use of
	SHA-1 [SHS] when CAs generate authority and subject key		SHA-1 [SHS] when CAs generate authority and subject key
	identifiers [ID.bgpsec-pki-profiles].		identifiers [ID.bgpsec-pki-profiles].
	To support BGPSEC, the algorithms are identified as follows:		To support BGPSEC, the algorithms are identified as follows:
	o In certificates and CRLs, an Object Identifier (OID) is used.		o In certificates and CRLs, an Object Identifier (OID) is used.
	The value and locations are as specified in section 2 of		The value and locations are as specified in section 2 of
	[ID.sidr-rpki-algs].		[RFC6485].
	o In certification request, an OID is used. The ecdsa-with-SHA256		o In certification request, an OID is used. The ecdsa-with-SHA256
	OID [RFC5480] MUST appear in the PKCS #10 signatureAlgorithm		OID [RFC5480] MUST appear in the PKCS #10 signatureAlgorithm
	field [RFC4211] or in Certificate Request Message Format (CRMF)		field [RFC4211] or in Certificate Request Message Format (CRMF)
	POPOSigningKey signature field [RFC2986].		POPOSigningKey signature field [RFC2986].
	o In BGPSEC Update messages, the ECDSA with SHA-256 Algorithm Suite		o In BGPSEC Update messages, the ECDSA with SHA-256 Algorithm Suite
	Identifier from Section 7 is included in the Signature-Block		Identifier from Section 7 is included in the Signature-Block
	List's Algorithm Suite Identifier field.		List's Algorithm Suite Identifier field.
	3. Asymmetric Key Format		3. Asymmetric Key Format
	The RSA key pairs used to compute signatures on CA certificates,		The RSA key pairs used to compute signatures on CA certificates,
	BGPSEC Router Certificates, and CRLs are as specified in section 3 of		BGPSEC Router Certificates, and CRLs are as specified in section 3 of
	[ID.sidr-rpki-algs]. The remainder of this section addresses key		[RFC6485]. The remainder of this section addresses key formats found
	formats found in the BGPSEC router certificate requests and in BGPSEC		in the BGPSEC router certificate requests and in BGPSEC Router
	Router Certificates.		Certificates.
	The ECDSA key pairs used to compute signatures for certificate		The ECDSA key pairs used to compute signatures for certificate
	requests and BGPSEC Update messages MUST come from the P-256 curve		requests and BGPSEC Update messages MUST come from the P-256 curve
	[RFC5480]. The public key pair MUST use the uncompressed form.		[RFC5480]. The public key pair MUST use the uncompressed form.
	3.1. Public Key Format		3.1. Public Key Format
	The Subject's public key is included in subjectPublicKeyInfo		The Subject's public key is included in subjectPublicKeyInfo
	[RFC5280]. It has two sub-fields: algorithm and subjectPublicKey.		[RFC5280]. It has two sub-fields: algorithm and subjectPublicKey.
	skipping to change at page 4, line 23 ¶		skipping to change at page 4, line 23 ¶
	certificate's subjectPublicKey field, as specified in Section 2.2		certificate's subjectPublicKey field, as specified in Section 2.2
	of [RFC5480].		of [RFC5480].
	3.2. Private Key Format		3.2. Private Key Format
	Local Policy determines private key format.		Local Policy determines private key format.
	4. Signature Format		4. Signature Format
	The structure for the certificate's and CRL's signature field MUST be		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		as specified in Section 4 of [RFC6485]. The structure for the
	the certification request's and BGPSEC Update message's signature		certification request's and BGPSEC Update message's signature field
	field MUST be as specified in Section 2.2.3 of [RFC3279].		MUST be as specified in Section 2.2.3 of [RFC3279].
	5. Additional Requirements		5. Additional Requirements
	It is anticipated that BGPSEC will require the adoption of updated		It is anticipated that BGPSEC will require the adoption of updated
	key sizes and a different set of signature and hash algorithms over		key sizes and a different set of signature and hash algorithms over
	time, in order to maintain an acceptable level of cryptographic		time, in order to maintain an acceptable level of cryptographic
	security to protect the integrity of BGPSEC. This profile should be		security to protect the integrity of BGPSEC. This profile should be
	updated to specify such future requirements, when appropriate.		updated to specify such future requirements, when appropriate.
	CAs and RPs SHOULD be capable of supporting a transition to allow for		CAs and RPs SHOULD be capable of supporting a transition to allow for
	skipping to change at page 4, line 48 ¶		skipping to change at page 4, line 48 ¶
	previously specified algorithms and keys. Accordingly, CAs and RPs		previously specified algorithms and keys. Accordingly, CAs and RPs
	SHOULD be capable of supporting multiple RPKI algorithm and key		SHOULD be capable of supporting multiple RPKI algorithm and key
	profiles simultaneously within the scope of such anticipated		profiles simultaneously within the scope of such anticipated
	transitions. The recommended procedures to implement such a		transitions. The recommended procedures to implement such a
	transition of key sizes and algorithms is not specified in this		transition of key sizes and algorithms is not specified in this
	document.		document.
	6. Security Considerations		6. Security Considerations
	The Security Considerations of [RFC3279], [RFC5480], [RFC6090],		The Security Considerations of [RFC3279], [RFC5480], [RFC6090],
	[ID.sidr-rpki-algs], and [ID.bgpsec-pki-profiles] apply to		[RFC6485], and [ID.bgpsec-pki-profiles] apply to certificates. The
	certificates. The security considerations of [RFC3279], [RFC6090],		security considerations of [RFC3279], [RFC6090], [RFC6485],
	[ID.sidr-rpki-algs], [ID.bgpsec-pki-profiles] apply to certification		[ID.bgpsec-pki-profiles] apply to certification requests. The
	requests. The security considerations of [RFC3279], [ID.sidr-bgpsec-		security considerations of [RFC3279], [ID.sidr-bgpsec-protocol], and
	protocol], and [RFC6090] apply to BGPSEC Update messages. No new		[RFC6090] apply to BGPSEC Update messages. No new security are
	security are introduced as a result of this specification.		introduced as a result of this specification.
	7. IANA Considerations		7. IANA Considerations
	The Internet Assigned Numbers Authority (IANA) is requested to define		The Internet Assigned Numbers Authority (IANA) is requested to define
	the "BGPSEC Algorithm Suite Registry" described below.		the "BGPSEC Algorithm Suite Registry" described below.
	An algorithm suite consists of a digest algorithm and a signature		An algorithm suite consists of a digest algorithm and a signature
	algorithm. This specification creates an IANA registry of one-octet		algorithm. This specification creates an IANA registry of one-octet
	BGPSEC algorithm suite identifiers. Additionally, this document		BGPSEC algorithm suite identifiers. Additionally, this document
	registers a single algorithm suite which uses the digest algorithm		registers a single algorithm suite which uses the digest algorithm
	skipping to change at page 5, line 34 ¶		skipping to change at page 5, line 34 ¶
	+----------------------------------------------------------------+		+----------------------------------------------------------------+
	Future assignments are to be made using either the Standards Action		Future assignments are to be made using either the Standards Action
	process defined in [RFC5226], or the Early IANA Allocation process		process defined in [RFC5226], or the Early IANA Allocation process
	defined in [RFC4020]. Assignments consist of a digest algorithm		defined in [RFC4020]. Assignments consist of a digest algorithm
	name, signature algorithm name, and the algorithm suite identifier		name, signature algorithm name, and the algorithm suite identifier
	value.		value.
	10. Acknowledgements		10. Acknowledgements
	The author wishes to thank Geoff Huston for producing [ID.sidr-rpki-		The author wishes to thank Geoff Huston for producing [RFC6485],
	algs], which this document is heavily based on. I'd also like to		which this document is heavily based on. I'd also like to thank
	thank Roque Gagliano for his review and comments.		Roque Gagliano for his review and comments.
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification		[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification
	Request Syntax Specification Version 1.7", RFC 2986,		Request Syntax Specification Version 1.7", RFC 2986,
	skipping to change at page 6, line 31 ¶		skipping to change at page 6, line 30 ¶
	Infrastructure Certificate and Certificate Revocation List		Infrastructure Certificate and Certificate Revocation List
	(CRL) Profile", RFC 5280, May 2008.		(CRL) Profile", RFC 5280, May 2008.
	[RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,		[RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
	"Elliptic Curve Cryptography Subject Public Key		"Elliptic Curve Cryptography Subject Public Key
	Information", RFC 5480, March 2009.		Information", RFC 5480, March 2009.
	[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic		[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic
	Curve Cryptography Algorithms", RFC 6090, February 2011.		Curve Cryptography Algorithms", RFC 6090, February 2011.
			[RFC6485] Huston, G., "The Profile for Algorithms and Key Sizes for
			Use in the Resource Public Key Infrastructure (RPKI)",
			RFC 6485, February 2012.
			[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for
			X.509 PKIX Resource Certificates", RFC 6487, February 2012.
	[SHS] National Institute of Standards and Technology (NIST), "FIPS		[SHS] National Institute of Standards and Technology (NIST), "FIPS
	Publication 180-3: Secure Hash Standard", FIPS Publication		Publication 180-3: Secure Hash Standard", FIPS Publication
	180-3, October 2008.		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		[ID.sidr-bgpsec-protocol] Lepinski, M., "BGPSEC Protocol
	Specification", draft-ietf-sidr-bgpsec-protocol, work-in-		Specification", draft-ietf-sidr-bgpsec-protocol, work-in-
	progress.		progress.
	[ID.bgpsec-pki-profiles] Reynolds, M. and S. Turner, "A Profile for		[ID.bgpsec-pki-profiles] Reynolds, M. and S. Turner, "A Profile for
	BGPSEC Router Certificates, Certificate Revocation Lists,		BGPSEC Router Certificates, Certificate Revocation Lists,
	and Certification Requests", draft-ietf-sidr-bpgsec-pki-		and Certification Requests", draft-ietf-sidr-bpgsec-pki-
	profiles, work-in-progress.		profiles, work-in-progress.
	11.1. Informative References		11.1. Informative References
End of changes. 17 change blocks.
	43 lines changed or deleted		40 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/