< draft-ietf-sidr-bgpsec-algs-14.txt		draft-ietf-sidr-bgpsec-algs-15.txt >
	Secure Inter-Domain Routing Working Group S. Turner		Secure Inter-Domain Routing Working Group S. Turner
	Internet-Draft IECA, Inc.		Internet-Draft IECA, Inc.
	Updates: 6485bis (if approved) November 10, 2015		Updates: 6485bis (if approved) April 21, 2016
	Intended status: Standards Track		Intended status: Standards Track
	Expires: May 13, 2016		Expires: October 23, 2016
	BGPsec Algorithms, Key Formats, & Signature Formats		BGPsec Algorithms, Key Formats, & Signature Formats
	draft-ietf-sidr-bgpsec-algs-14		draft-ietf-sidr-bgpsec-algs-15
	Abstract		Abstract
	This document specifies the algorithms, algorithm parameters,		This document specifies the algorithms, algorithm 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 (ID.sidr-rfc6485bis).		Public Key Infrastructure (ID.sidr-rfc6485bis).
	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."
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2016 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
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 2, line 15 ¶		skipping to change at page 2, line 15 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Asymmetric Key Pair Formats . . . . . . . . . . . . . . . . . 3		3. Asymmetric Key Pair Formats . . . . . . . . . . . . . . . . . 3
	3.1. Public Key Format . . . . . . . . . . . . . . . . . . . . 4		3.1. Public Key Format . . . . . . . . . . . . . . . . . . . . 4
	3.2. Private Key Format . . . . . . . . . . . . . . . . . . . . 4		3.2. Private Key Format . . . . . . . . . . . . . . . . . . . . 4
	4. Signature Format . . . . . . . . . . . . . . . . . . . . . . . 4		4. Signature Format . . . . . . . . . . . . . . . . . . . . . . . 4
	5. Additional Requirements . . . . . . . . . . . . . . . . . . . 4		5. Additional Requirements . . . . . . . . . . . . . . . . . . . 4
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 5		6. Security Considerations . . . . . . . . . . . . . . . . . . . 4
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 6		9.1. Normative References . . . . . . . . . . . . . . . . . . . 5
	9.2. Informative References . . . . . . . . . . . . . . . . . . 7		9.2. Informative References . . . . . . . . . . . . . . . . . . 7
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
	1. Introduction		1. Introduction
	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 processing		speakers (i.e., routers). CAs use these algorithms when processing
	requests for BGPsec Router Certificates [ID.sidr-bgpsec-pki-		requests for BGPsec Router Certificates [ID.sidr-bgpsec-pki-
	profiles]. BGPsec routers use these algorithms when requesting		profiles]. Examples when BGPsec routers use these algorithms include
	BGPsec certificates [ID.sidr-bgpsec-pki-profiles], signing BGPsec		requesting BGPsec certificates [ID.sidr-bgpsec-pki-profiles], signing
	Update messages [ID.sidr-bgpsec-protocol], and verifying BGPsec		BGPsec Update messages [ID.sidr-bgpsec-protocol], and verifying
	Update messages [ID.sidr-bgpsec-protocol].		BGPsec Update messages [ID.sidr-bgpsec-protocol].
	This document is referenced by the BGPsec specification [ID.sidr-
	bgpsec-protocol] and the profile for BGPsec Router Certificates and
	Certification Requests [ID.sidr-bgpsec-pki-profiles]. Familiarity
	with these documents is assumed. Implementers are reminded, however,
	that, as noted in Section 2 of [ID.sidr-bgpsec-pki-profiles], the
	algorithms used to sign CA Certificates, BGPsec Router Certificates,
	and CRLs are found in [ID.sidr-rfc6485bis].
	This document updates [ID.sidr-rfc6485bis] to add support for a) a		This document updates [ID.sidr-rfc6485bis] to add support for a) a
	different algorithm for BGPsec certificate requests, which are issued		different algorithm for BGPsec certificate requests, which are issued
	only by BGPsec speakers; b) a different Subject Public Key Info		only by BGPsec speakers; b) a different Subject Public Key Info
	format for BGPsec certificates, which is needed for the specified		format for BGPsec certificates, which is needed for the specified
	BGPsec signature algorithm; and, c) a different signature format for		BGPsec signature algorithm; and, c) a different signature format for
	BGPsec signatures, which is needed for the specified BGPsec signature		BGPsec 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.sidr-bgpsec-pki-profiles].		[ID.sidr-bgpsec-pki-profiles].
	skipping to change at page 3, line 21 ¶		skipping to change at page 3, line 16 ¶
	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
	The algorithms used to compute signatures on CA certificates, BGPsec		The algorithms used to compute signatures on CA certificates, BGPsec
	Router Certificates, and CRLs are as specified in Section 2 of		Router Certificates, and CRLs are as specified in Section 2 of
	[ID.sidr-rfc6485bis]. The remainder of this section addresses		[ID.sidr-rfc6485bis]. This section addresses BGPsec algorithms, for
	algorithms used when BGPsec routers request certificates, RPKI CAs		example these algorithms are used by BGPsec routers to request BGPsec
	verify BGPsec certification requests, BGPsec routers generate BGPsec		certificates, by RPKI CAs to verify BGPsec certification requests, by
	Update messages, and when BGPsec routers verify BGPsec Update		BGPsec routers to generate BGPsec Update messages, and by BGPsec
	messages:		routers to verify BGPsec Update message:
	o The signature algorithm used MUST be the Elliptic Curve Digital		o The signature algorithm used MUST be the Elliptic Curve Digital
	Signature Algorithm (ECDSA) with curve P-256 [RFC6090][FIPS186].		Signature Algorithm (ECDSA) with curve P-256 [RFC6090][DSS].
	o The hash algorithm used MUST be SHA-256 [SHS].		o The hash algorithm used MUST be SHA-256 [SHS].
	Hash algorithms are not identified by themselves in certificates or		Hash algorithms are not identified by themselves in certificates or
	BGPsec Update messages. They are represented by an OID that combines		BGPsec Update messages. They are represented by an OID that combines
	the hash algorithm with the digital signature algorithm as follows:		the hash algorithm with the digital signature algorithm as follows:
	o The ecdsa-with-SHA256 OID [RFC5480] MUST appear in the PKCS #10		o The ecdsa-with-SHA256 OID [RFC5480] MUST appear in the PKCS #10
	signatureAlgorithm field [RFC2986] or in Certificate Request		signatureAlgorithm field [RFC2986] or in Certificate Request
	Message Format (CRMF) POPOSigningKey algorithm field [RFC4211],		Message Format (CRMF) POPOSigningKey algorithm field [RFC4211],
	skipping to change at page 3, line 50 ¶		skipping to change at page 3, line 45 ¶
	generated.		generated.
	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 Pair Formats		3. Asymmetric Key Pair Formats
	The key formats used to compute signatures on CA certificates, BGPsec		The key formats used to compute signatures on CA certificates, BGPsec
	Router Certificates, and CRLs are as specified in Section 3 of		Router Certificates, and CRLs are as specified in Section 3 of
	[ID.sidr-rfc6485bis]. The remainder of this section addresses key		[ID.sidr-rfc6485bis]. This section addresses key formats found in
	formats found in the BGPsec router certificate requests and in BGPsec		the BGPsec router certificate requests and in BGPsec Router
	Router Certificates.		Certificates.
	The ECDSA private keys used to compute signatures for certificate		The ECDSA private keys 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.
	The values for the structures and their sub-structures follow:		The values for the structures and their sub-structures follow:
	skipping to change at page 4, line 45 ¶		skipping to change at page 4, line 40 ¶
	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. This profile should be updated to specify such future		security. This profile should be updated to specify such future
	requirements, when appropriate.		requirements, when appropriate.
	CAs and RPs SHOULD be capable of supporting a transition to allow for		The recommended procedures to implement such a transition of key
	the phased introduction of additional encryption algorithms and key		sizes and algorithms is specified in [RFC6916].
	specifications, and also accommodate the orderly deprecation of
	previously specified algorithms and keys [RFC6919]. 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 are not specified in this
	document, see Section 6 in [ID.sidr-bgpsec-protocol] for more
	information.
	6. Security Considerations		6. Security Considerations
	The Security Considerations of [RFC3279], [RFC5480], [RFC6090],		The Security Considerations of [RFC3279], [RFC5480], [RFC6090],
	[ID.sidr-rfc6485bis], and [ID.sidr-bgpsec-pki-profiles] apply to		[ID.sidr-rfc6485bis], and [ID.sidr-bgpsec-pki-profiles] apply to
	certificates. The security considerations of [RFC3279], [RFC6090],		certificates. The security considerations of [RFC3279], [RFC6090],
	[ID.sidr-rfc6485bis], [ID.sidr-bgpsec-pki-profiles] apply to		[ID.sidr-rfc6485bis], [ID.sidr-bgpsec-pki-profiles] apply to
	certification requests. The security considerations of [RFC3279],		certification requests. The security considerations of [RFC3279],
	[ID.sidr-bgpsec-protocol], and [RFC6090] apply to BGPsec Update		[ID.sidr-bgpsec-protocol], and [RFC6090] apply to BGPsec Update
	messages. No new security considerations are introduced as a result		messages. No new security considerations are introduced as a result
	of this specification.		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 in the Resource
			Public Key Infrastructure (RPKI) group.
	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
	SHA-256 and the signature algorithm ECDSA on the P-256 curve		SHA-256 and the signature algorithm ECDSA on the P-256 curve
	[RFC5480].		[RFC5480].
	BGPsec Algorithm Suites Registry		BGPsec Algorithm Suites Registry
	Digest Signature Algorithm Specification		Digest Signature Algorithm Specification
	Algorithm Algorithm Suite Pointer		Algorithm Algorithm Suite Pointer
	Identifier		Identifier
	+-------------------------------------------------------+		+-------------------------------------------------------+
	| Reserved | Reserved | 0x0 | This draft |		| Reserved | Reserved | 0x0 | This draft |
	+-------------------------------------------------------+		+-------------------------------------------------------+
	| SHA-256 | ECDSA P-256 | TBD | RFC 5480 |		| SHA-256 | ECDSA P-256 | TBD | RFC 5480 |
	+-------------------------------------------------------+		+-------------------------------------------------------+
	| Unassigned | Unassigned | TBD..0xF | This draft |		| Unassigned | Unassigned | TBD+1..0xE | This draft |
	+-------------------------------------------------------+		+-------------------------------------------------------+
	| Reserved | Reserved | 0xF | This draft |		| Reserved | Reserved | 0xF | This draft |
	+-------------------------------------------------------+		+-------------------------------------------------------+
	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 [RFC7120]. Assignments consist of a digest algorithm		defined in [RFC7120]. 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.
	8. Acknowledgements		8. Acknowledgements
	The author wishes to thank Geoff Huston and George Michaelson for		The author wishes to thank Geoff Huston and George Michaelson for
	producing [ID.sidr-rfc6485bis], which this document is entirely based		producing [ID.sidr-rfc6485bis], which this document is entirely based
	on. I'd also like to thank Roque Gagliano, David Mandelberg, Sam		on. I'd also like to thank Roque Gagliano, David Mandelberg, Tom
	Weiler, and Stephen Kent for their reviews and comments.		Petch, Sam Weiller, and Stephen Kent for their reviews and comments.
	9. References		9. References
	9.1. Normative References		9.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 48 ¶		skipping to change at page 6, line 34 ¶
	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.
	[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for		[RFC6916] Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility
	X.509 PKIX Resource Certificates", RFC 6487, February 2012.		Procedure for the Resource Public Key Infrastructure
			(RPKI)", BCP 182, RFC 6916, April 2013.
	[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code		[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code
	Points", BCP 100, RFC 7120, January 2014.		Points", BCP 100, RFC 7120, January 2014.
	[SHS] National Institute of Standards and Technology (NIST), "FIPS
	Publication 180-3: Secure Hash Standard", FIPS Publication
	180-3, October 2008.
	[ID.sidr-rfc6485bis] Huston, G., and G. Michaelson, "The Profile for		[ID.sidr-rfc6485bis] Huston, G., and G. Michaelson, "The Profile for
	Algorithms and Key Sizes for use in the Resource Public Key		Algorithms and Key Sizes for use in the Resource Public Key
	Infrastructure", draft-ietf-sidr-rfc6485bis, work-in-		Infrastructure", draft-ietf-sidr-rfc6485bis, work-in-
	progress.		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.sidr-bgpsec-pki-profiles] Reynolds, M. and S. Turner, "A Profile		[ID.sidr-bgpsec-pki-profiles] Reynolds, M. and S. Turner, "A Profile
	for BGPSEC Router Certificates, Certificate Revocation		for BGPSEC Router Certificates, Certificate Revocation
	Lists, and Certification Requests", draft-ietf-sidr-bgpsec-		Lists, and Certification Requests", draft-ietf-sidr-bgpsec-
	pki-profiles, work-in-progress.		pki-profiles, work-in-progress.
	[FIPS-186-3] National Institute of Standards and Technology, U.S.		[DSS] National Institute of Standards and Technology (NIST), U.S.
	Department of Commerce, "Digital Signature Standard", FIPS		Department of Commerce, "Digital Signature Standard", FIPS
	186-4, July 2013.		Publication 186-4, July 2013.
			[SHS] National Institute of Standards and Technology (NIST), U.S.
			Department of Commerce, "Secure Hash Standard", FIPS
			Publication 180-4, August 2015.
	9.2. Informative References		9.2. Informative References
	None.		None.
	Authors' Addresses		Authors' Addresses
	Sean Turner		Sean Turner
	IECA, Inc.		IECA, Inc.
	3057 Nutley Street, Suite 106		3057 Nutley Street, Suite 106
End of changes. 19 change blocks.
	52 lines changed or deleted		38 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/