< draft-kivinen-ipsecme-oob-pubkey-09.txt		draft-kivinen-ipsecme-oob-pubkey-10.txt >
	IP Security Maintenance and Extensions (ipsecme) T. Kivinen		IP Security Maintenance and Extensions (ipsecme) T. Kivinen
	Internet-Draft INSIDE Secure		Internet-Draft INSIDE Secure
	Updates: 7296 P. Wouters		Updates: 7296 (if approved) P. Wouters
	Intended status: Standards Track Red Hat		Intended status: Standards Track Red Hat
	Expires: October 13, 2015 H. Tschofenig		Expires: October 22, 2015 H. Tschofenig
	April 2015		April 20, 2015
	More Raw Public Keys for IKEv2		More Raw Public Keys for IKEv2
	draft-kivinen-ipsecme-oob-pubkey-09.txt		draft-kivinen-ipsecme-oob-pubkey-10.txt
	Abstract		Abstract
	The Internet Key Exchange Version 2 (IKEv2) protocol currently only		The Internet Key Exchange Version 2 (IKEv2) protocol currently only
	supports raw RSA keys. In constrained environments it is useful to		supports raw RSA keys. In constrained environments it is useful to
	make use of other types of public keys, such as those based on		make use of other types of public keys, such as those based on
	Elliptic Curve Cryptography. This documents adds support for other		Elliptic Curve Cryptography. This documents adds support for other
	types of raw public keys to IKEv2.		types of raw public keys to IKEv2.
	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 October 13, 2015.		This Internet-Draft will expire on October 22, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 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 (http://trustee.ietf.org/		Provisions Relating to IETF Documents
	license-info) in effect on the date of publication of this document.		(http://trustee.ietf.org/license-info) in effect on the date of
	Please review these documents carefully, as they describe your rights		publication of this document. Please review these documents
	and restrictions with respect to this document. Code Components		carefully, as they describe your rights and restrictions with respect
	extracted from this document must include Simplified BSD License text		to this document. Code Components extracted from this document must
	as described in Section 4.e of the Trust Legal Provisions and are		include Simplified BSD License text as described in Section 4.e of
	provided without warranty as described in the Simplified BSD License.		the Trust Legal Provisions and are provided without warranty as
			described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Certificate Encoding Payload . . . . . . . . . . . . . . . . . 2		3. Certificate Encoding Payload . . . . . . . . . . . . . . . . 3
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 3		4. Security Considerations . . . . . . . . . . . . . . . . . . . 4
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
	7.1. Normative References . . . . . . . . . . . . . . . . . . . 4		7.1. Normative References . . . . . . . . . . . . . . . . . . 5
	7.2. Informative References . . . . . . . . . . . . . . . . . . 4		7.2. Informative References . . . . . . . . . . . . . . . . . 5
	Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . . 5		Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 6
	Appendix A.1. ECDSA Example . . . . . . . . . . . . . . . . . . 5		A.1. ECDSA Example . . . . . . . . . . . . . . . . . . . . . . 6
	Appendix A.2. RSA Example . . . . . . . . . . . . . . . . . . . 6		A.2. RSA Example . . . . . . . . . . . . . . . . . . . . . . . 8
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Introduction		1. Introduction
	Secure DNS allows public keys to be associated with domain names for		Secure DNS allows public keys to be associated with domain names for
	usage with security protocols like Internet Key Exchange Version 2		usage with security protocols like Internet Key Exchange Version 2
	(IKEv2) [RFC7296] and Transport Layer Security (TLS) [RFC5246] but it		(IKEv2) [RFC7296] and Transport Layer Security (TLS) [RFC5246] but it
	relies on extensions in those protocols to be specified.		relies on extensions in those protocols to be specified.
	In [RFC5996] IKEv2 had support for PKCS #1 encoded RSA keys, i.e., a		In [RFC5996] IKEv2 had support for PKCS #1 encoded RSA keys, i.e., a
	DER-encoded RSAPublicKey structure (see [RSA] and [RFC3447]). Other		DER-encoded RSAPublicKey structure (see [RSA] and [RFC3447]). Other
	raw public key types are, however, not supported. In [RFC7296] this		raw public key types are, however, not supported. In [RFC7296] this
	feature was removed, and this document adds support for raw public		feature was removed, and this document adds support for raw public
	keys back to IKEv2 in a more generic way.		keys back to IKEv2 in a more generic way.
	The TLS Out-of-Band Public Key Validation specification ([RFC7250])		The TLS Out-of-Band Public Key Validation specification ([RFC7250])
	adds generic support for raw public keys to TLS by re-using the		adds generic support for raw public keys to TLS by re-using the
	SubjectPublicKeyInfo format from the X.509 Public Key Infrastructure		SubjectPublicKeyInfo format from the X.509 Public Key Infrastructure
	Certificate profile [RFC5280].		Certificate profile [RFC5280].
	This document is similar to the TLS Out-of-Band Public Key Validation		This document is similar to the TLS Out-of-Band Public Key Validation
	specification, and applies the concept to IKEv2 to support all public		specification, and applies the concept to IKEv2 to support all public
	key formats defined by PKIX. This approach also allows future public		key formats defined by PKIX. This approach also allows future public
	key extensions to be supported without the need to introduce further		key extensions to be supported without the need to introduce further
	enhancements to IKEv2.		enhancements to IKEv2.
	To support new types of public keys in IKEv2 the following changes		To support new types of public keys in IKEv2 the following changes
	are needed:		are needed:
	o A new Certificate Encoding format needs to be defined for carrying		o A new Certificate Encoding format needs to be defined for carrying
	the SubjectPublicKeyInfo structure. [cert-encoding] specifies		the SubjectPublicKeyInfo structure. Section 3 specifies this new
	this new encoding format.		encoding format.
	o A new Certificate Encoding type needs to be allocated from the		o A new Certificate Encoding type needs to be allocated from the
	IANA registry. [iana] contains this request to IANA.		IANA registry. Section 5 contains this request to IANA.
			The base IKEv2 include support for RSA and DSA signatures, but the
			Signature Authentication in IKEv2 [RFC7427] extended IKEv2 so that
			signature methods over any types of keys can be used.
			Implementations using raw public keys SHOULD use the Digital
			Signature method described in the RFC7427.
			When using raw public keys, the authenticated identity is not usually
			the identity from the ID payload, but instead the public key itself
			is used as identity for the other end. This means that ID payload
			contents might not be useful for authentication purposes. It might
			still be used for policy decisions, for example to simplify the
			policy lookup etc.
	2. Terminology		2. 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", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	3. Certificate Encoding Payload		3. Certificate Encoding Payload
	Section 3.6 of RFC 7296 defines the Certificate payload format as		Section 3.6 of RFC 7296 defines the Certificate payload format as
	shown in [payload].		shown in Figure 1.
	1 2 3		1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Next Payload |C| RESERVED | Payload Length |		| Next Payload |C| RESERVED | Payload Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Cert Encoding | |		| Cert Encoding | |
	+-+-+-+-+-+-+-+-+ |		+-+-+-+-+-+-+-+-+ |
	~ Certificate Data ~		~ Certificate Data ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Figure 1: Certificate Payload Format.
	To support raw public keys, the field values are as follows:		To support raw public keys, the field values are as follows:
	o Certificate Encoding (1 octet) - This field indicates the type of		o Certificate Encoding (1 octet) - This field indicates the type of
	certificate or certificate-related information contained in the		certificate or certificate-related information contained in the
	Certificate Data field.		Certificate Data field.
	Certificate Encoding Value		Certificate Encoding Value
	----------------------------------------------------		----------------------------------------------------
	Raw Public Key TBD		Raw Public Key TBD
	o Certificate Data (variable length) - Actual encoding of the		o Certificate Data (variable length) - Actual encoding of the
	certificate data.		certificate data.
	In order to provide a simple and standard way to indicate the key		In order to provide a simple and standard way to indicate the key
	type when the encoding type is 'Raw Public Key', the		type when the encoding type is 'Raw Public Key', the
	SubjectPublicKeyInfo structure of the PKIX certificate is used. This		SubjectPublicKeyInfo structure of the PKIX certificate is used. This
	is a a very simple encoding, as most of the ASN.1 part can be		is a a very simple encoding, as most of the ASN.1 part can be
	included literally, and recognized by block comparison. See		included literally, and recognized by block comparison. See
	[RFC7250] Appendix A for a detailed breakdown. In addition,		[RFC7250] Appendix A for a detailed breakdown. In addition,
	[examples] has several examples.		Appendix A has several examples.
	In addition to the Certificate payload, the Cert Encoding for Raw		In addition to the Certificate payload, the Cert Encoding for Raw
	Public Key can be used in the Certificate Request payload. In that		Public Key can be used in the Certificate Request payload. In that
	case the Certification Authority field MUST be empty if the "Raw		case the Certification Authority field MUST be empty if the "Raw
	Public Key" certificate encoding is used.		Public Key" certificate encoding is used.
	Implementations MUST follow the public key processing rules of		For RSA keys, the implementations MUST follow the public key
	section 1.2 of the Additional Algorithms and Identifiers for RSA		processing rules of section 1.2 of the Additional Algorithms and
	Cryptography for PKIX ([RFC4055]) even when the SubjectPublicKeyInfo		Identifiers for RSA Cryptography for PKIX ([RFC4055]) even when the
	is not part of a certificate, but rather sent as a Certificate Data		SubjectPublicKeyInfo is not part of a certificate, but rather sent as
	field. This means that RSASSA-PSS and RSASSA-PSS-params inside the		a Certificate Data field. This means that RSASSA-PSS and RSASSA-PSS-
	SubjectPublicKeyInfo structure MUST be sent when applicable.		params inside the SubjectPublicKeyInfo structure MUST be sent when
			applicable.
	4. Security Considerations		4. Security Considerations
	An IKEv2 deployment using raw public keys needs to utilize an out-of-		An IKEv2 deployment using raw public keys needs to utilize an out-of-
	band public key validation procedure to be confident in the		band public key validation procedure to be confident in the
	authenticity of the keys being used. One way to achieve this goal is		authenticity of the keys being used. One way to achieve this goal is
	to use a configuration mechanism for provisioning raw public keys		to use a configuration mechanism for provisioning raw public keys
	into the IKEv2 software. "Smart object" deployments are likely to		into the IKEv2 software. "Smart object" deployments are likely to
	use such preconfigured public keys.		use such preconfigured public keys.
	Another approach is to rely on secure DNS to associate public keys		Another approach is to rely on secure DNS to associate public keys
	with domain names using the IPSECKEY DNS RRtype [RFC4025]. More		with domain names using the IPSECKEY DNS RRtype [RFC4025]. More
	information can be found in DNS-Based Authentication of Named		information can be found in DNS-Based Authentication of Named
	Entities (DANE) [RFC6394].		Entities (DANE) [RFC6394].
	This document does not change the security assumptions made by the		This document does not change the security assumptions made by the
	IKEv2 specification since "Raw RSA Key" support was already available		IKEv2 specification since "Raw RSA Key" support was already available
	in IKEv2. This document only generalizes raw public key support.		in IKEv2. This document only generalizes raw public key support.
	5. IANA Considerations		5. IANA Considerations
	This document allocates a new value from the IKEv2 Certificate		This document allocates a new value from the IKEv2 Certificate
	Encodings registry:		Encodings registry:
	TBD Raw Public Key		TBD Raw Public Key
	6. Acknowledgements		6. Acknowledgements
	skipping to change at page 4, line 35 ¶		skipping to change at page 5, line 29 ¶
	([RFC7250]).		([RFC7250]).
	7. References		7. References
	7.1. Normative References		7.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.
	[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,		[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
	Housley, R. and W. Polk, "Internet X.509 Public Key		Housley, R., and W. Polk, "Internet X.509 Public Key
	Infrastructure Certificate and Certificate Revocation List		Infrastructure Certificate and Certificate Revocation List
	(CRL) Profile", RFC 5280, May 2008.		(CRL) Profile", RFC 5280, May 2008.
	[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P. and T.		[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
	Kivinen, "Internet Key Exchange Protocol Version 2		Kivinen, "Internet Key Exchange Protocol Version 2
	(IKEv2)", STD 79, RFC 7296, October 2014.		(IKEv2)", STD 79, RFC 7296, October 2014.
			[RFC7427] Kivinen, T. and J. Snyder, "Signature Authentication in
			the Internet Key Exchange Version 2 (IKEv2)", RFC 7427,
			January 2015.
	7.2. Informative References		7.2. Informative References
	[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography		[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
	Standards (PKCS) #1: RSA Cryptography Specifications		Standards (PKCS) #1: RSA Cryptography Specifications
	Version 2.1", RFC 3447, February 2003.		Version 2.1", RFC 3447, February 2003.
	[RFC4025] Richardson, M., "A Method for Storing IPsec Keying		[RFC4025] Richardson, M., "A Method for Storing IPsec Keying
	Material in DNS", RFC 4025, March 2005.		Material in DNS", RFC 4025, March 2005.
	[RFC4055] Schaad, J., Kaliski, B. and R. Housley, "Additional		[RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional
	Algorithms and Identifiers for RSA Cryptography for use in		Algorithms and Identifiers for RSA Cryptography for use in
	the Internet X.509 Public Key Infrastructure Certificate		the Internet X.509 Public Key Infrastructure Certificate
	and Certificate Revocation List (CRL) Profile", RFC 4055,		and Certificate Revocation List (CRL) Profile", RFC 4055,
	June 2005.		June 2005.
	[RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using		[RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using
	the Elliptic Curve Digital Signature Algorithm (ECDSA)",		the Elliptic Curve Digital Signature Algorithm (ECDSA)",
	RFC 4754, January 2007.		RFC 4754, January 2007.
	[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security		[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.2", RFC 5246, August 2008.		(TLS) Protocol Version 1.2", RFC 5246, August 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.
	[RFC5996] Kaufman, C., Hoffman, P., Nir, Y. and P. Eronen, "Internet		[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
	Key Exchange Protocol Version 2 (IKEv2)", RFC 5996,		"Internet Key Exchange Protocol Version 2 (IKEv2)", RFC
	September 2010.		5996, September 2010.
	[RFC6394] Barnes, R., "Use Cases and Requirements for DNS-Based		[RFC6394] Barnes, R., "Use Cases and Requirements for DNS-Based
	Authentication of Named Entities (DANE)", RFC 6394,		Authentication of Named Entities (DANE)", RFC 6394,
	October 2011.		October 2011.
	[RFC7250] Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S. and		[RFC7250] Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and
	T. Kivinen, "Using Raw Public Keys in Transport Layer		T. Kivinen, "Using Raw Public Keys in Transport Layer
	Security (TLS) and Datagram Transport Layer Security		Security (TLS) and Datagram Transport Layer Security
	(DTLS)", RFC 7250, June 2014.		(DTLS)", RFC 7250, June 2014.
	[RSA] R. Rivest, , A. Shamir, and L. Adleman, "A Method for		[RSA] R. Rivest, , A. Shamir, , and L. Adleman, "A Method for
	Obtaining Digital Signatures and Public-Key		Obtaining Digital Signatures and Public-Key
	Cryptosystems", February 1978.		Cryptosystems", February 1978.
	Appendix A. Examples		Appendix A. Examples
	This appendix provides examples of the actual payloads sent on the		This appendix provides examples of the actual payloads sent on the
	wire.		wire.
	Appendix A.1. ECDSA Example		A.1. ECDSA Example
	This first example uses the 256-bit ECDSA private/public key pair		This first example uses the 256-bit ECDSA private/public key pair
	defined in section 8.1 of the IKEv2 ECDSA document [RFC4754].		defined in section 8.1 of the IKEv2 ECDSA document [RFC4754].
	The public key is as follows:		The public key is as follows:
	o Algorithm : id-ecPublicKey (1.2.840.10045.2.1)		o Algorithm : id-ecPublicKey (1.2.840.10045.2.1)
	o Fixed curve: secp256r1 (1.2.840.10045.3.1.7)		o Fixed curve: secp256r1 (1.2.840.10045.3.1.7)
	o Public key x coordinate : cb28e099 9b9c7715 fd0a80d8 e47a7707		o Public key x coordinate : cb28e099 9b9c7715 fd0a80d8 e47a7707
	9716cbbf 917dd72e 97566ea1 c066957c		9716cbbf 917dd72e 97566ea1 c066957c
	o Public key y coordinate : 2b57c023 5fb74897 68d058ff 4911c20f		o Public key y coordinate : 2b57c023 5fb74897 68d058ff 4911c20f
	dbe71e36 99d91339 afbb903e e17255dc		dbe71e36 99d91339 afbb903e e17255dc
	The SubjectPublicKeyInfo ASN.1 object is as follows:		The SubjectPublicKeyInfo ASN.1 object is as follows:
	0000 : SEQUENCE		0000 : SEQUENCE
	0002 : SEQUENCE		0002 : SEQUENCE
	0004 : OBJECT IDENTIFIER id-ecPublicKey (1.2.840.10045.2.1)		0004 : OBJECT IDENTIFIER id-ecPublicKey (1.2.840.10045.2.1)
	000d : OBJECT IDENTIFIER secp256r1 (1.2.840.10045.3.1.7)		000d : OBJECT IDENTIFIER secp256r1 (1.2.840.10045.3.1.7)
	0017 : BIT STRING (66 bytes)		0017 : BIT STRING (66 bytes)
	00000000: 0004 cb28 e099 9b9c 7715 fd0a 80d8 e47a		00000000: 0004 cb28 e099 9b9c 7715 fd0a 80d8 e47a
	00000010: 7707 9716 cbbf 917d d72e 9756 6ea1 c066		00000010: 7707 9716 cbbf 917d d72e 9756 6ea1 c066
	00000020: 957c 2b57 c023 5fb7 4897 68d0 58ff 4911		00000020: 957c 2b57 c023 5fb7 4897 68d0 58ff 4911
	00000030: c20f dbe7 1e36 99d9 1339 afbb 903e e172		00000030: c20f dbe7 1e36 99d9 1339 afbb 903e e172
	00000040: 55dc		00000040: 55dc
	The first byte (00) of the bit string indicates that there is no		The first byte (00) of the bit string indicates that there is no
	"number of unused bits", and the second byte (04) indicates		"number of unused bits", and the second byte (04) indicates
	uncompressed form ([RFC5480]). Those two octets are followed by the		uncompressed form ([RFC5480]). Those two octets are followed by the
	values of X and Y.		values of X and Y.
	The final encoded SubjectPublicKeyInfo object is as follows:		The final encoded SubjectPublicKeyInfo object is as follows:
	00000000: 3059 3013 0607 2a86 48ce 3d02 0106 082a		00000000: 3059 3013 0607 2a86 48ce 3d02 0106 082a
	00000010: 8648 ce3d 0301 0703 4200 04cb 28e0 999b		00000010: 8648 ce3d 0301 0703 4200 04cb 28e0 999b
	00000020: 9c77 15fd 0a80 d8e4 7a77 0797 16cb bf91		00000020: 9c77 15fd 0a80 d8e4 7a77 0797 16cb bf91
	00000030: 7dd7 2e97 566e a1c0 6695 7c2b 57c0 235f		00000030: 7dd7 2e97 566e a1c0 6695 7c2b 57c0 235f
	00000040: b748 9768 d058 ff49 11c2 0fdb e71e 3699		00000040: b748 9768 d058 ff49 11c2 0fdb e71e 3699
	00000050: d913 39af bb90 3ee1 7255 dc		00000050: d913 39af bb90 3ee1 7255 dc
	This will result in the final IKEv2 Certificate Payload:		This will result in the final IKEv2 Certificate Payload:
	00000000: NN00 0060 XX30 5930 1306 072a 8648 ce3d		00000000: NN00 0060 XX30 5930 1306 072a 8648 ce3d
	00000010: 0201 0608 2a86 48ce 3d03 0107 0342 0004		00000010: 0201 0608 2a86 48ce 3d03 0107 0342 0004
	00000020: cb28 e099 9b9c 7715 fd0a 80d8 e47a 7707		00000020: cb28 e099 9b9c 7715 fd0a 80d8 e47a 7707
	00000030: 9716 cbbf 917d d72e 9756 6ea1 c066 957c		00000030: 9716 cbbf 917d d72e 9756 6ea1 c066 957c
	00000040: 2b57 c023 5fb7 4897 68d0 58ff 4911 c20f		00000040: 2b57 c023 5fb7 4897 68d0 58ff 4911 c20f
	00000050: dbe7 1e36 99d9 1339 afbb 903e e172 55dc		00000050: dbe7 1e36 99d9 1339 afbb 903e e172 55dc
	Where NN is the next payload type (i.e. the type of the payload that		Where NN is the next payload type (i.e. the type of the payload that
	immediately follows this Certificate payload).		immediately follows this Certificate payload).
	Note to the RFC editor / IANA, replace the XX above with the newly		Note to the RFC editor / IANA, replace the XX above with the newly
	allocated Raw Public Key number (in hex notation), and remove this		allocated Raw Public Key number (in hex notation), and remove this
	note.		note.
	Appendix A.2. RSA Example		A.2. RSA Example
	This second example uses a random 1024-bit RSA key.		This second example uses a random 1024-bit RSA key.
	The public key is as follows:		The public key is as follows:
	o Algorithm : rsaEncryption (1.2.840.113549.1.1.1)		o Algorithm : rsaEncryption (1.2.840.113549.1.1.1)
	o Modulus n (1024 bits, decimal):		o Modulus n (1024 bits, decimal):
	1323562071162740912417075551025599045700		1323562071162740912417075551025599045700
	3972512968992059076067098474693867078469		3972512968992059076067098474693867078469
	7654066339302927451756327389839253751712		7654066339302927451756327389839253751712
	9485277759962777278073526290329821841100		9485277759962777278073526290329821841100
	9721044682579432931952695408402169276996		9721044682579432931952695408402169276996
	5181887843758615443536914372816830537901		5181887843758615443536914372816830537901
	8976615344413864477626646564638249672329		8976615344413864477626646564638249672329
	04996914356093900776754835411		04996914356093900776754835411
	o Modulus n (1024 bits, hexadecimal): bc7b4347 49c7b386 00bfa84b		o Modulus n (1024 bits, hexadecimal): bc7b4347 49c7b386 00bfa84b
	44f88187 9a2dda08 d1f0145a f5806c2a ed6a6172 ff0dc3d4 cd601638		44f88187 9a2dda08 d1f0145a f5806c2a ed6a6172 ff0dc3d4 cd601638
	e8ca348e bdca5742 31cadc97 12e209b1 fddba58a 8c62b369 038a3d1e		e8ca348e bdca5742 31cadc97 12e209b1 fddba58a 8c62b369 038a3d1e
	aa727c1f 39ae49ed 6ebc30f8 d9b52e23 385a4019 15858c59 be72f343		aa727c1f 39ae49ed 6ebc30f8 d9b52e23 385a4019 15858c59 be72f343
	fb1eb87b 16ffc5ab 0f8f8fe9 f7cb3e66 3d8fe9f9 ecfa1230 66f36835		fb1eb87b 16ffc5ab 0f8f8fe9 f7cb3e66 3d8fe9f9 ecfa1230 66f36835
	8ceaefd3		8ceaefd3
	o Exponent e (17 bits, decimal): 65537		o Exponent e (17 bits, decimal): 65537
	o Exponent e (17 bits, hexadecimal): 10001		o Exponent e (17 bits, hexadecimal): 10001
	The SubjectPublicKeyInfo ASN.1 object is as follows:		The SubjectPublicKeyInfo ASN.1 object is as follows:
	0000 : SEQUENCE		0000 : SEQUENCE
	0003 : SEQUENCE		0003 : SEQUENCE
	0005 : OBJECT IDENTIFIER rsaEncryption (1.2.840.113549.1.1.1)		0005 : OBJECT IDENTIFIER rsaEncryption (1.2.840.113549.1.1.1)
	0016 : NULL		0016 : NULL
	0018 : BIT STRING (141 bytes)		0018 : BIT STRING (141 bytes)
	00000000: 0030 8189 0281 8100 bc7b 4347 49c7 b386		00000000: 0030 8189 0281 8100 bc7b 4347 49c7 b386
	skipping to change at page 7, line 44 ¶		skipping to change at page 9, line 25 ¶
	00000050: 39ae 49ed 6ebc 30f8 d9b5 2e23 385a 4019		00000050: 39ae 49ed 6ebc 30f8 d9b5 2e23 385a 4019
	00000060: 1585 8c59 be72 f343 fb1e b87b 16ff c5ab		00000060: 1585 8c59 be72 f343 fb1e b87b 16ff c5ab
	00000070: 0f8f 8fe9 f7cb 3e66 3d8f e9f9 ecfa 1230		00000070: 0f8f 8fe9 f7cb 3e66 3d8f e9f9 ecfa 1230
	00000080: 66f3 6835 8cea efd3 0203 0100 01		00000080: 66f3 6835 8cea efd3 0203 0100 01
	The first byte (00) of the bit string indicates that there is no		The first byte (00) of the bit string indicates that there is no
	"number of unused bits". Inside that bit string there is an ASN.1		"number of unused bits". Inside that bit string there is an ASN.1
	sequence having 2 integers. The second byte (30) indicates that this		sequence having 2 integers. The second byte (30) indicates that this
	is beginning of the sequence, and the next byte (81) indicates the		is beginning of the sequence, and the next byte (81) indicates the
	length does not fit in 7 bits, but requires one byte, so the length		length does not fit in 7 bits, but requires one byte, so the length
	is in the next byte (89). Then starts the first integer with tag (02)		is in the next byte (89). Then starts the first integer with tag
	and length (81 81). After that we have the modulus (prefixed with 0		(02) and length (81 81). After that we have the modulus (prefixed
	so it will not be a negative number). After the modulus there follows		with 0 so it will not be a negative number). After the modulus there
	the tag (02) and length (03) of the exponent, and the last 3 bytes		follows the tag (02) and length (03) of the exponent, and the last 3
	are the exponent.		bytes are the exponent.
	The final encoded SubjectPublicKeyInfo object is as follows:		The final encoded SubjectPublicKeyInfo object is as follows:
	00000000: 3081 9f30 0d06 092a 8648 86f7 0d01 0101		00000000: 3081 9f30 0d06 092a 8648 86f7 0d01 0101
	00000010: 0500 0381 8d00 3081 8902 8181 00bc 7b43		00000010: 0500 0381 8d00 3081 8902 8181 00bc 7b43
	00000020: 4749 c7b3 8600 bfa8 4b44 f881 879a 2dda		00000020: 4749 c7b3 8600 bfa8 4b44 f881 879a 2dda
	00000030: 08d1 f014 5af5 806c 2aed 6a61 72ff 0dc3		00000030: 08d1 f014 5af5 806c 2aed 6a61 72ff 0dc3
	00000040: d4cd 6016 38e8 ca34 8ebd ca57 4231 cadc		00000040: d4cd 6016 38e8 ca34 8ebd ca57 4231 cadc
	00000050: 9712 e209 b1fd dba5 8a8c 62b3 6903 8a3d		00000050: 9712 e209 b1fd dba5 8a8c 62b3 6903 8a3d
	00000060: 1eaa 727c 1f39 ae49 ed6e bc30 f8d9 b52e		00000060: 1eaa 727c 1f39 ae49 ed6e bc30 f8d9 b52e
	skipping to change at page 8, line 31 ¶		skipping to change at page 10, line 17 ¶
	00000020: 8100 bc7b 4347 49c7 b386 00bf a84b 44f8		00000020: 8100 bc7b 4347 49c7 b386 00bf a84b 44f8
	00000030: 8187 9a2d da08 d1f0 145a f580 6c2a ed6a		00000030: 8187 9a2d da08 d1f0 145a f580 6c2a ed6a
	00000040: 6172 ff0d c3d4 cd60 1638 e8ca 348e bdca		00000040: 6172 ff0d c3d4 cd60 1638 e8ca 348e bdca
	00000050: 5742 31ca dc97 12e2 09b1 fddb a58a 8c62		00000050: 5742 31ca dc97 12e2 09b1 fddb a58a 8c62
	00000060: b369 038a 3d1e aa72 7c1f 39ae 49ed 6ebc		00000060: b369 038a 3d1e aa72 7c1f 39ae 49ed 6ebc
	00000070: 30f8 d9b5 2e23 385a 4019 1585 8c59 be72		00000070: 30f8 d9b5 2e23 385a 4019 1585 8c59 be72
	00000080: f343 fb1e b87b 16ff c5ab 0f8f 8fe9 f7cb		00000080: f343 fb1e b87b 16ff c5ab 0f8f 8fe9 f7cb
	00000090: 3e66 3d8f e9f9 ecfa 1230 66f3 6835 8cea		00000090: 3e66 3d8f e9f9 ecfa 1230 66f3 6835 8cea
	000000a0: efd3 0203 0100 01		000000a0: efd3 0203 0100 01
	Where NN is the next payload type (i.e. the type of the payload that		Where NN is the next payload type (i.e. the type of the payload that
	immediately follows this Certificate payload).		immediately follows this Certificate payload).
	Note to the RFC editor / IANA, replace the XX above with the newly		Note to the RFC editor / IANA, replace the XX above with the newly
	allocated Raw Public Key number, and remove this note.		allocated Raw Public Key number, and remove this note.
	Authors' Addresses		Authors' Addresses
	Tero Kivinen		Tero Kivinen
	INSIDE Secure		INSIDE Secure
	Eerikinkatu 28		Eerikinkatu 28
	HELSINKI, FI-00180		HELSINKI FI-00180
	FI		FI
	Email: kivinen@iki.fi		Email: kivinen@iki.fi
	Paul Wouters		Paul Wouters
	Red Hat		Red Hat
	Email: pwouters@redhat.com		Email: pwouters@redhat.com
	Hannes Tschofenig		Hannes Tschofenig
End of changes. 38 change blocks.
	63 lines changed or deleted		92 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/