< draft-ietf-sidr-bgpsec-algs-11.txt		draft-ietf-sidr-bgpsec-algs-12.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) August 6, 2015		Updates: 6485bis (if approved) November 3, 2015
	Intended status: BCP		Intended status: BCP
	Expires: February 7, 2016		Expires: May 6, 2016
	BGPsec Algorithms, Key Formats, & Signature Formats		BGPsec Algorithms, Key Formats, & Signature Formats
	draft-ietf-sidr-bgpsec-algs-11		draft-ietf-sidr-bgpsec-algs-12
	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-rfc6485bis).		Public Key Infrastructure (draft-ietf-sidr-rfc6485bis).
	Status of this Memo		Status of this Memo
	skipping to change at page 2, line 5 ¶		skipping to change at page 2, line 5 ¶
	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
	described in the Simplified BSD License.		described in the Simplified BSD License.
			Table of Contents
			1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
			1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
			2. Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . 3
			3. Asymmetric Key Format . . . . . . . . . . . . . . . . . . . . 4
			3.1. Public Key Format . . . . . . . . . . . . . . . . . . . . 4
			3.2. Private Key Format . . . . . . . . . . . . . . . . . . . . 4
			4. Signature Format . . . . . . . . . . . . . . . . . . . . . . . 4
			5. Additional Requirements . . . . . . . . . . . . . . . . . . . 4
			6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
			7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
			8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
			9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
			9.1. Normative References . . . . . . . . . . . . . . . . . . . 6
			9.2. Informative References . . . . . . . . . . . . . . . . . . 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 issuing		speakers (i.e., routers). CAs use these algorithms when issuing
	skipping to change at page 3, line 20 ¶		skipping to change at page 3, line 32 ¶
	CRLs, which would revoke BGPsec certificates, MUST be as		CRLs, which would revoke BGPsec certificates, MUST be as
	specified in [ID.sidr-rfc6485bis].		specified in [ID.sidr-rfc6485bis].
	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-rfc6485bis].		MUST be as specified in [ID.sidr-rfc6485bis].
	o The hashing algorithm use when generating certification requests		o The hashing algorithm used 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 [RFC6487].		identifiers [RFC6487].
	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-rfc6485bis].		[ID.sidr-rfc6485bis].
	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 [RFC2986] or in Certificate Request Message Format (CRMF)		field [RFC2986] or in Certificate Request Message Format (CRMF)
	POPOSigningKey algoirthm field [RFC4211].		POPOSigningKey algorithm field [RFC4211].
	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-rfc6485bis]. The remainder of this section addresses key		[ID.sidr-rfc6485bis]. The remainder of this section addresses key
	formats found in the BGPsec router certificate requests and in BGPsec		formats found in the BGPsec router certificate requests and in BGPsec
	Router Certificates.		Router 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.
	The values for the structures and their sub-structures follow:		The values for the structures and their sub-structures follow:
	o algorithm (which is an AlgorithmIdentifier type): The id-		o algorithm (which is an AlgorithmIdentifier type): The id-
	ecPublicKey OID MUST be used in the algorithm field, as specified		ecPublicKey OID MUST be used in the algorithm field, as specified
	in 2.1.1 of [RFC5480]. The value for the associated parameters		in Section 2.1.1 of [RFC5480]. The value for the associated
	MUST be secp256r1, as specified in 2.1.1.1 of [RFC5480].		parameters MUST be secp256r1, as specified in Section 2.1.1.1 of
			[RFC5480].
	o subjectPublicKey: ECPublicKey MUST be used to encode the		o subjectPublicKey: ECPoint MUST be used to encode the
	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
	skipping to change at page 5, line 20 ¶		skipping to change at page 5, line 14 ¶
	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
	the phased introduction of additional encryption algorithms and key		the phased introduction of additional encryption algorithms and key
	specifications, and also accommodate the orderly deprecation of		specifications, and also accommodate the orderly deprecation of
	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 are not specified in this
	document.		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
	skipping to change at page 5, line 48 ¶		skipping to change at page 5, line 43 ¶
	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 Suite Specification		Digest Signature Algorithm Specification
	Algorithm Algorithm Identifier Pointer		Algorithm Algorithm Suite Pointer
	+----------------------------------------------------------------+		Identifier
	| SHA-256 | ECDSA P-256 | TBD | RFC 5480 |
	+----------------------------------------------------------------+		+-------------------------------------------------------+
			| Reserved | Reserved | 0x0 | This draft |
			+-------------------------------------------------------+
			| SHA-256 | ECDSA P-256 | TBD | RFC 5480 |
			+-------------------------------------------------------+
			| Unassigned | Unassigned | TBD..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 for producing [ID.sidr-		The author wishes to thank Geoff Huston for producing [ID.sidr-
	rfc6485bis], which this document is heavily based on. I'd also like		rfc6485bis], which this document is heavily based on. I'd also like
	to thank Roque Gagliano for his review and comments.		to thank Roque Gagliano, David Mandelberg, and Sam Weiller for their
			review 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,
End of changes. 12 change blocks.
	17 lines changed or deleted		46 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/