< draft-kivinen-ipsecme-signature-auth-04.txt		draft-kivinen-ipsecme-signature-auth-05.txt >
	IP Security Maintenance and Extensions T. Kivinen		IP Security Maintenance and Extensions T. Kivinen
	(ipsecme) INSIDE Secure		(ipsecme) INSIDE Secure
	Internet-Draft December 9, 2013		Internet-Draft March 28, 2014
	Updates: RFC 5996 (if approved)		Updates: RFC 5996 (if approved)
	Intended status: Standards Track		Intended status: Standards Track
	Expires: June 12, 2014		Expires: September 29, 2014
	Signature Authentication in IKEv2		Signature Authentication in IKEv2
	draft-kivinen-ipsecme-signature-auth-04.txt		draft-kivinen-ipsecme-signature-auth-05.txt
	Abstract		Abstract
	The Internet Key Exchange Version 2 (IKEv2) protocol has limited		The Internet Key Exchange Version 2 (IKEv2) protocol has limited
	support for the Elliptic Curve Digital Signature Algorithm (ECDSA).		support for the Elliptic Curve Digital Signature Algorithm (ECDSA).
	The current version only includes support for three Elliptic Curve		The current version only includes support for three Elliptic Curve
	groups, and there is fixed hash algorithm tied to each curve. This		groups, and there is fixed hash algorithm tied to each curve. This
	document generalizes the IKEv2 signature support so it can support		document generalizes the IKEv2 signature support so it can support
	any signature method supported by the PKIX and also adds signature		any signature method supported by the PKIX and also adds signature
	hash algorithm negotiation. This is generic mechanism, and is not		hash algorithm negotiation. This is generic mechanism, and is not
	skipping to change at page 1, line 40 ¶		skipping to change at page 1, line 40 ¶
	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 12, 2014.		This Internet-Draft will expire on September 29, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2014 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 41 ¶		skipping to change at page 2, line 41 ¶
	A.2.1. dsa-with-sha1 . . . . . . . . . . . . . . . . . . . . 12		A.2.1. dsa-with-sha1 . . . . . . . . . . . . . . . . . . . . 12
	A.2.2. dsa-with-sha256 . . . . . . . . . . . . . . . . . . . 13		A.2.2. dsa-with-sha256 . . . . . . . . . . . . . . . . . . . 13
	A.3. ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . 13		A.3. ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	A.3.1. ecdsa-with-sha1 . . . . . . . . . . . . . . . . . . . 13		A.3.1. ecdsa-with-sha1 . . . . . . . . . . . . . . . . . . . 13
	A.3.2. ecdsa-with-sha256 . . . . . . . . . . . . . . . . . . 13		A.3.2. ecdsa-with-sha256 . . . . . . . . . . . . . . . . . . 13
	A.3.3. ecdsa-with-sha384 . . . . . . . . . . . . . . . . . . 14		A.3.3. ecdsa-with-sha384 . . . . . . . . . . . . . . . . . . 14
	A.3.4. ecdsa-with-sha512 . . . . . . . . . . . . . . . . . . 14		A.3.4. ecdsa-with-sha512 . . . . . . . . . . . . . . . . . . 14
	A.4. RSASSA-PSS . . . . . . . . . . . . . . . . . . . . . . . . 14		A.4. RSASSA-PSS . . . . . . . . . . . . . . . . . . . . . . . . 14
	A.4.1. RSASSA-PSS with empty parameters . . . . . . . . . . . 14		A.4.1. RSASSA-PSS with empty parameters . . . . . . . . . . . 14
	A.4.2. RSASSA-PSS with default parameters . . . . . . . . . . 15		A.4.2. RSASSA-PSS with default parameters . . . . . . . . . . 15
	Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 15		A.4.3. RSASSA-PSS with SHA-256 . . . . . . . . . . . . . . . 15
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15		Appendix B. IKEv2 Payload Example . . . . . . . . . . . . . . . . 16
			B.1. sha1WithRSAEncryption . . . . . . . . . . . . . . . . . . 16
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
	1. Introduction		1. Introduction
	This document adds new IKEv2 ([RFC5996]) authentication method to		This document adds new IKEv2 ([RFC5996]) authentication method to
	support all kinds of signature methods. The current signature based		support all kinds of signature methods. The current signature based
	authentication methods in the IKEv2 are per algorithm, i.e. there is		authentication methods in the IKEv2 are per algorithm, i.e. there is
	one for RSA Digital signatures, one for DSS Digital Signatures (using		one for RSA Digital signatures, one for DSS Digital Signatures (using
	SHA-1) and three for different ECDSA curves each tied to exactly one		SHA-1) and three for different ECDSA curves each tied to exactly one
	hash algorithm. This design starts to be cumbersome when more ECDSA		hash algorithm. This design starts to be cumbersome when more
	groups are added, as each of them would require new authentication		signature algorithms, hash algorithms and elliptic curves are to be
	method and as with ECDSA there is no way to extract the hash		supported:
	algorithm from the signature, each ECDSA algorithm would need to come
	with fixed hash algorithm tied to it.
	With the SHA-3 definitions coming out, it is seen that it might be		o The RSA Digital Signatures format in the IKEv2 is specified to use
	possible that in the future the signature methods are used with SHA-3		RSASSA-PKCS1-v1_5 padding, but Additional RSA Algorithms and
	also, not only SHA-2. This means new mechanism for negotiating the		Identifiers for X.509 document recommends the use of the newer
	hash algorithm for the signature algorithms is needed.		RSASSA_PSS (See section 5 of [RFC4055]) instead.
			o With ECDSA and DSS there is no way to extract the hash algorithm
			from the signature, thus, for each new hash function to be
			supported with ECDSA or DSA new authentication methods would be
			needed. Support for new hash functions is particularly needed for
			DSS because the current restriction to SHA-1 limits its security,
			meaning there is no point of using long keys with it.
			o The tying of ECDSA authentication methods to particular elliptic
			curve groups requires definition of additional methods for each
			new group. By combination of new ECDSA groups with various hash
			functions the number of required authentication methods may grow
			unmanageable. Furthermore, the restriction of ECDSA
			authentication to a specific group is inconsistent with the
			approach taken with DSS.
	The RSA Digital Signatures format in the IKEv2 is specified to use		With the selection of SHA-3, it is seen that it might be possible
	RSASSA-PKCS1-v1_5, but there has been some discussions that newer		that in the future the signature methods are used with SHA-3 also,
	padding methods should be preferred instead of PKCS #1 version 1.5		not only SHA-2. This means new mechanism for negotiating the hash
	(See section 5 of [RFC4055]). The DSS Digital Signatures format in		algorithm for the signature algorithms is needed.
	the IKEv2 is specified to always use SHA-1, which limits the security
	of that, meaning there is no point of using long keys with it.
	This documents specifies two things, one is one new authentication		This documents specifies two things, one is one new authentication
	method, which includes the enough information inside the		method, which includes enough information inside the Authentication
	Authentication payload data that the signature hash algorithm can be		payload data that the signature hash algorithm can be extracted from
	extracted from there (see Section 3). The another thing is to add		there (see Section 3). The another thing is to add indication of
	indication of supported signature hash algorithms by the peer (see		supported signature hash algorithms by the peer (see Section 4).
	Section 4). This allows peer to know which hash algorithms are		This allows peer to know which hash algorithms are supported by the
	supported by the other end and use one of them (provided one is		other end and use one of them (provided one is allowed by policy).
	allowed by policy). There is no need to actually negotiate one		There is no need to actually negotiate one common hash algorithm, as
	common hash algorithm, as different hash algorithms can be used in		different hash algorithms can be used in different directions if
	different directions if needed.		needed.
	The new digital signature method needs to be flexible enough to		The new digital signature method needs to be flexible enough to
	include all current signature methods (RSA, DSA, ECDSA, RSASSA-PSS,		include all current signature methods (RSA, DSA, ECDSA, RSASSA-PSS,
	etc), and also allow adding new things in the future (ECGDSA, ElGamal		etc), and also allow adding new things in the future (ECGDSA, ElGamal
	etc). For this the signature algorithm is specified in the same way		etc). For this the signature algorithm is specified in the same way
	as the PKIX ([RFC5280]) specifies the signature of the Certificate,		as the PKIX ([RFC5280]) specifies the signature of the Certificate,
	i.e. there is simple ASN.1 object before the actual signature data.		i.e. there is simple ASN.1 object before the actual signature data.
	This ASN.1 object contains the OID specifying the algorithm, and		This ASN.1 object contains the OID specifying the algorithm, and
	associated parameters to it. In normal case the IKEv2		associated parameters to it. In normal case the IKEv2
	implementations supports fixed amount of signature methods, with		implementations supports fixed amount of signature methods, with
	skipping to change at page 4, line 37 ¶		skipping to change at page 4, line 46 ¶
	parameters which might be needed for algorithms like RSASSA-PSS.		parameters which might be needed for algorithms like RSASSA-PSS.
	To make implementations easier, the ASN.1 object is prefixed by the		To make implementations easier, the ASN.1 object is prefixed by the
	8-bit length field. This length field allows simple implementations		8-bit length field. This length field allows simple implementations
	to be able to know the length of the ASN.1 without the need to parse		to be able to know the length of the ASN.1 without the need to parse
	it, so they can use it as binary blob which is compared against the		it, so they can use it as binary blob which is compared against the
	known signature algorithm ASN.1 objects, i.e. they do not need to be		known signature algorithm ASN.1 objects, i.e. they do not need to be
	able to parse or generate ASN.1 objects. See Appendix A for commonly		able to parse or generate ASN.1 objects. See Appendix A for commonly
	used ASN.1 objects.		used ASN.1 objects.
	The ASN.1 used here are the same ASN.1 which is used in the		The ASN.1 used here is the same ASN.1 which is used in the
	AlgorithmIdentifier of the PKIX (Section 4.1.1.2 of [RFC5280])		AlgorithmIdentifier of the PKIX (Section 4.1.1.2 of [RFC5280])
	encoded using distinguished encoding rules (DER) [CCITT.X690.2002].		encoded using distinguished encoding rules (DER) [CCITT.X690.2002].
	The algorithm OID inside the ASN.1 specifies the signature algorithm		The algorithm OID inside the ASN.1 specifies the signature algorithm
	and the hash function, which are needed for signature verification.		and the hash function, which are needed for signature verification.
	The EC curve is always known by the peer because it needs to have the		The EC curve is always known by the peer because it needs to have the
	certificate or the public key of the other end before it can do		certificate or the public key of the other end before it can do
	signature verification and public key specifies the curve.		signature verification and public key specifies the curve.
	Currently only the RSASSA-PSS uses the parameters, for all others the		Currently only the RSASSA-PSS uses the parameters, for all others the
	parameters is either NULL or missing. Note, that for some algorithms		parameters is either NULL or missing. Note, that for some algorithms
	skipping to change at page 11, line 48 ¶		skipping to change at page 11, line 48 ¶
	Profile ([RFC4055]) for more information.		Profile ([RFC4055]) for more information.
	A.1.1. sha1WithRSAEncryption		A.1.1. sha1WithRSAEncryption
	sha1WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2)		sha1WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2)
	us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 }		us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 }
	Parameters are required, and they must be NULL.		Parameters are required, and they must be NULL.
	Name = sha1WithRSAEncryption, oid = 1.2.840.113549.1.1.5		Name = sha1WithRSAEncryption, oid = 1.2.840.113549.1.1.5
	Length = 17		Length = 15
	0000: 300f 300d 0609 2a86 4886 f70d 0101 0505		0000: 300d 0609 2a86 4886 f70d 0101 0505 00
	0010: 00
	A.1.2. sha256WithRSAEncryption		A.1.2. sha256WithRSAEncryption
	sha256WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 11 }		sha256WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 11 }
	Parameters are required, and they must be NULL.		Parameters are required, and they must be NULL.
	Name = sha256WithRSAEncryption, oid = 1.2.840.113549.1.1.11		Name = sha256WithRSAEncryption, oid = 1.2.840.113549.1.1.11
	Length = 17		Length = 15
	0000: 300f 300d 0609 2a86 4886 f70d 0101 0b05		0000: 300d 0609 2a86 4886 f70d 0101 0b05 00
	0010: 00
	A.1.3. sha384WithRSAEncryption		A.1.3. sha384WithRSAEncryption
	sha384WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 12 }		sha384WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 12 }
	Parameters are required, and they must be NULL.		Parameters are required, and they must be NULL.
	Name = sha384WithRSAEncryption, oid = 1.2.840.113549.1.1.12		Name = sha384WithRSAEncryption, oid = 1.2.840.113549.1.1.12
	Length = 17		Length = 15
	0000: 300f 300d 0609 2a86 4886 f70d 0101 0c05		0000: 300d 0609 2a86 4886 f70d 0101 0c05 00
	0010: 00
	A.1.4. sha512WithRSAEncryption		A.1.4. sha512WithRSAEncryption
	sha512WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 13 }		sha512WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 13 }
	Parameters are required, and they must be NULL.		Parameters are required, and they must be NULL.
	Name = sha512WithRSAEncryption, oid = 1.2.840.113549.1.1.13		Name = sha512WithRSAEncryption, oid = 1.2.840.113549.1.1.13
	Length = 17		Length = 15
	0000: 300f 300d 0609 2a86 4886 f70d 0101 0d05		0000: 300d 0609 2a86 4886 f70d 0101 0d05 00
	0010: 00
	A.2. DSA		A.2. DSA
	With different DSA algorithms the parameters are always omitted.		With different DSA algorithms the parameters are always omitted.
	Again we omit dsa-with-sha224 as there is no hash algorithm in our		Again we omit dsa-with-sha224 as there is no hash algorithm in our
	IANA registry for it.		IANA registry for it.
	See Algorithms and Identifiers for PKIX Profile ([RFC3279]) and PKIX		See Algorithms and Identifiers for PKIX Profile ([RFC3279]) and PKIX
	Additional Algorithms and Identifiers for DSA and ECDSA ([RFC5758]		Additional Algorithms and Identifiers for DSA and ECDSA ([RFC5758]
	for more information.		for more information.
	skipping to change at page 13, line 4 ¶		skipping to change at page 12, line 49 ¶
	IANA registry for it.		IANA registry for it.
	See Algorithms and Identifiers for PKIX Profile ([RFC3279]) and PKIX		See Algorithms and Identifiers for PKIX Profile ([RFC3279]) and PKIX
	Additional Algorithms and Identifiers for DSA and ECDSA ([RFC5758]		Additional Algorithms and Identifiers for DSA and ECDSA ([RFC5758]
	for more information.		for more information.
	A.2.1. dsa-with-sha1		A.2.1. dsa-with-sha1
	dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)		dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
	x9-57(10040) x9algorithm(4) 3 }		x9-57(10040) x9algorithm(4) 3 }
	Parameters are absent.		Parameters are absent.
	Name = dsa-with-sha1, oid = 1.2.840.10040.4.3		Name = dsa-with-sha1, oid = 1.2.840.10040.4.3
	Length = 13		Length = 11
	0000: 300b 3009 0607 2a86 48ce 3804 03		0000: 3009 0607 2a86 48ce 3804 03
	A.2.2. dsa-with-sha256		A.2.2. dsa-with-sha256
	dsa-with-sha256 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2)		dsa-with-sha256 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2)
	country(16) us(840) organization(1) gov(101) csor(3) algorithms(4)		country(16) us(840) organization(1) gov(101) csor(3) algorithms(4)
	id-dsa-with-sha2(3) 2 }		id-dsa-with-sha2(3) 2 }
	Parameters are absent.		Parameters are absent.
	Name = dsa-with-sha256, oid = 2.16.840.1.101.3.4.3.2		Name = dsa-with-sha256, oid = 2.16.840.1.101.3.4.3.2
	Length = 15		Length = 13
	0000: 300d 300b 0609 6086 4801 6503 0403 02		0000: 300b 0609 6086 4801 6503 0403 02
	A.3. ECDSA		A.3. ECDSA
	With different ECDSA algorithms the parameters are always omitted.		With different ECDSA algorithms the parameters are always omitted.
	Again we omit ecdsa-with-sha224 as there is no hash algorithm in our		Again we omit ecdsa-with-sha224 as there is no hash algorithm in our
	IANA registry for it.		IANA registry for it.
	See Elliptic Curve Cryptography Subject Public Key Information		See Elliptic Curve Cryptography Subject Public Key Information
	([RFC5480]), Algorithms and Identifiers for PKIX Profile ([RFC3279])		([RFC5480]), Algorithms and Identifiers for PKIX Profile ([RFC3279])
	and PKIX Additional Algorithms and Identifiers for DSA and ECDSA		and PKIX Additional Algorithms and Identifiers for DSA and ECDSA
	([RFC5758] for more information.		([RFC5758] for more information.
	A.3.1. ecdsa-with-sha1		A.3.1. ecdsa-with-sha1
	ecdsa-with-SHA1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)		ecdsa-with-SHA1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
	ansi-X9-62(10045) signatures(4) 1 }		ansi-X9-62(10045) signatures(4) 1 }
	Parameters are absent.		Parameters are absent.
	Name = ecdsa-with-sha1, oid = 1.2.840.10045.4.1		Name = ecdsa-with-sha1, oid = 1.2.840.10045.4.1
	Length = 13		Length = 11
	0000: 300b 3009 0607 2a86 48ce 3d04 01		0000: 3009 0607 2a86 48ce 3d04 01
	A.3.2. ecdsa-with-sha256		A.3.2. ecdsa-with-sha256
	ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2)		ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
	us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 2 }		us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 2 }
	Parameters are absent.		Parameters are absent.
	Name = ecdsa-with-sha256, oid = 1.2.840.10045.4.3.2		Name = ecdsa-with-sha256, oid = 1.2.840.10045.4.3.2
	Length = 14		Length = 12
	0000: 300c 300a 0608 2a86 48ce 3d04 0302		0000: 300a 0608 2a86 48ce 3d04 0302
	A.3.3. ecdsa-with-sha384		A.3.3. ecdsa-with-sha384
	ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2)		ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
	us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 3 }		us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 3 }
	Parameters are absent.		Parameters are absent.
	Name = ecdsa-with-sha384, oid = 1.2.840.10045.4.3.3		Name = ecdsa-with-sha384, oid = 1.2.840.10045.4.3.3
	Length = 14		Length = 12
	0000: 300c 300a 0608 2a86 48ce 3d04 0303		0000: 300a 0608 2a86 48ce 3d04 0303
	A.3.4. ecdsa-with-sha512		A.3.4. ecdsa-with-sha512
	ecdsa-with-SHA512 OBJECT IDENTIFIER ::= { iso(1) member-body(2)		ecdsa-with-SHA512 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
	us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 4 }		us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 4 }
	Parameters are absent.		Parameters are absent.
	Name = ecdsa-with-sha512, oid = 1.2.840.10045.4.3.4		Name = ecdsa-with-sha512, oid = 1.2.840.10045.4.3.4
	Length = 14		Length = 12
	0000: 300c 300a 0608 2a86 48ce 3d04 0304		0000: 300a 0608 2a86 48ce 3d04 0304
	A.4. RSASSA-PSS		A.4. RSASSA-PSS
	With the RSASSA-PSS the algorithm object identifier is always id-		With the RSASSA-PSS the algorithm object identifier is always id-
	RSASSA-PSS, but the hash function is taken from the parameters, and		RSASSA-PSS, but the hash function is taken from the parameters, and
	it is required. See [RFC4055] for more information.		it is required. See [RFC4055] for more information.
	A.4.1. RSASSA-PSS with empty parameters		A.4.1. RSASSA-PSS with empty parameters
	id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 }		id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 }
	Parameters are empty, but the ASN.1 part of the sequence must be		Parameters are empty, but the ASN.1 part of the sequence must be
	there. This means default parameters are used (same as the next		there. This means default parameters are used (same as the next
	example).		example).
	Name = RSASSA-PSS with empty parameters, oid = 1.2.840.113549.1.1.10		0000 : SEQUENCE
	Length = 17		0002 : OBJECT IDENTIFIER RSASSA-PSS (1.2.840.113549.1.1.10)
	0000: 300f 300d 0609 2a86 4886 f70d 0101 0a30		000d : SEQUENCE
	0010: 00
			Length = 15
			0000: 300d 0609 2a86 4886 f70d 0101 0a30 00
	A.4.2. RSASSA-PSS with default parameters		A.4.2. RSASSA-PSS with default parameters
	id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 }		id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 }
	Here the parameters are present, and contains the default parameters,		Here the parameters are present, and contains the default parameters,
	i.e. SHA-1, mgf1SHA1, saltlength of 20, trailerfield of 1.		i.e. SHA-1, mgf1SHA1, saltlength of 20, trailerfield of 1.
	0000 : SEQUENCE		0000 : SEQUENCE
	0002 : SEQUENCE		0002 : OBJECT IDENTIFIER RSASSA-PSS (1.2.840.113549.1.1.10)
	0004 : OBJECT IDENTIFIER RSASSA-PSS (1.2.840.113549.1.1.10)		000d : SEQUENCE
	000f : SEQUENCE		000f : CONTEXT 0
	0011 : CONTEXT 0		0011 : SEQUENCE
	0013 : OBJECT IDENTIFIER Sha-1 (1.3.14.3.2.26)		0013 : OBJECT IDENTIFIER Sha-1 (1.3.14.3.2.26)
	001a : NULL		001a : NULL
	001c : CONTEXT 1		001c : CONTEXT 1
	001e : OBJECT IDENTIFIER id-mgf1 ( 1.2.840.113549.1.1.8)		001e : SEQUENCE
	0029 : SEQUENCE		0020 : OBJECT IDENTIFIER 1.2.840.113549.1.1.8
	002b : OBJECT IDENTIFIER Sha-1 (1.3.14.3.2.26)		002b : SEQUENCE
	0032 : NULL		002d : OBJECT IDENTIFIER Sha-1 (1.3.14.3.2.26)
	0034 : CONTEXT 2 (1 bytes)		0034 : NULL
	0036 : INTEGER 20 (0x14)		0036 : CONTEXT 2
	0037 : CONTEXT 3 (1 bytes)		0038 : INTEGER 0x14 (5 bits)
	0039 : INTEGER 01 (0x01)		003b : CONTEXT 3
			003d : INTEGER 0x1 (1 bits)
	Name = RSASSA-PSS with default parameters,		Name = RSASSA-PSS with default parameters,
	oid = 1.2.840.113549.1.1.10		oid = 1.2.840.113549.1.1.10
	Length = 58		Length = 64
	0000: 3038 3036 0609 2a86 4886 f70d 0101 0a30		0000: 303e 0609 2a86 4886 f70d 0101 0a30 31a0
	0010: 29a0 0906 052b 0e03 021a 0500 a116 0609		0010: 0b30 0906 052b 0e03 021a 0500 a118 3016
	0020: 2a86 4886 f70d 0101 0830 0906 052b 0e03		0020: 0609 2a86 4886 f70d 0101 0830 0906 052b
	0030: 021a 0500 8201 1483 0101		0030: 0e03 021a 0500 a203 0201 14a3 0302 0101
	Appendix B. Examples		A.4.3. RSASSA-PSS with SHA-256
	XXX Examples missing		id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 }
	XXX Most likely include examples for sha1WithRSAEncryption and dsa-		Here the parameters are present, and contains the SHA-256 for both
	with-sha256 or something like that. I do not think we need all		the hash and mgf, saltlength of 32, and trailerfield of 1.
	possible signature examples.
			0000 : SEQUENCE
			0002 : OBJECT IDENTIFIER RSASSA-PSS (1.2.840.113549.1.1.10)
			000d : SEQUENCE
			000f : CONTEXT 0
			0011 : SEQUENCE
			0013 : OBJECT IDENTIFIER Sha-256 (2.16.840.1.101.3.4.2.1)
			001e : NULL
			0020 : CONTEXT 1
			0022 : SEQUENCE
			0024 : OBJECT IDENTIFIER 1.2.840.113549.1.1.8
			002f : SEQUENCE
			0031 : OBJECT IDENTIFIER Sha-256 (2.16.840.1.101.3.4.2.1)
			003c : NULL
			003e : CONTEXT 2
			0040 : INTEGER 0x20 (6 bits)
			0043 : CONTEXT 3
			0045 : INTEGER 0x1 (1 bits)
			Name = RSASSA-PSS with sha-256, oid = 1.2.840.113549.1.1.10
			Length = 72
			0000: 3046 0609 2a86 4886 f70d 0101 0a30 39a0
			0010: 0f30 0d06 0960 8648 0165 0304 0201 0500
			0020: a11c 301a 0609 2a86 4886 f70d 0101 0830
			0030: 0d06 0960 8648 0165 0304 0201 0500 a203
			0040: 0201 20a3 0302 0101
			Appendix B. IKEv2 Payload Example
			B.1. sha1WithRSAEncryption
			The IKEv2 AUTH payload would start like this:
			00000000: NN00 00LL XX00 0000 0f30 0d06 092a 8648
			00000010: 86f7 0d01 0105 0500 ....
			Where the NN will be the next payload type (i.e. that value depends
			on what is the next payload after this Authentication payload), the
			LL will be the length of this payload, and after the
			sha1WithRSAEncryption ASN.1 block (15 bytes) there will be the actual
			signature, which is omitted here.
			Note to the RFC editor / IANA, replace the XX above with the newly
			allocated authentication method type for Digital Signature, and
			remove this note.
	Author's Address		Author's Address
	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
End of changes. 29 change blocks.
	84 lines changed or deleted		139 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/