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.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/