< draft-kivinen-ipsecme-signature-auth-02.txt   draft-kivinen-ipsecme-signature-auth-03.txt >
IP Security Maintenance and Extensions T. Kivinen IP Security Maintenance and Extensions T. Kivinen
(ipsecme) INSIDE Secure (ipsecme) INSIDE Secure
Internet-Draft October 18, 2013 Internet-Draft November 14, 2013
Updates: RFC 5996 (if approved) Updates: RFC 5996 (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: April 21, 2014 Expires: May 18, 2014
Signature Authentication in IKEv2 Signature Authentication in IKEv2
draft-kivinen-ipsecme-signature-auth-02.txt draft-kivinen-ipsecme-signature-auth-03.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 April 21, 2014. This Internet-Draft will expire on May 18, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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
skipping to change at page 2, line 17 skipping to change at page 2, line 17
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 Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Authentication Payload . . . . . . . . . . . . . . . . . . . . 4 3. Authentication Payload . . . . . . . . . . . . . . . . . . . . 4
4. Hash Algorithm Notification . . . . . . . . . . . . . . . . . 6 4. Hash Algorithm Notification . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. Selecting Public Key Algorithm . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9
Appendix A. Commonly used ASN.1 objects . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . . 10
A.1. PKCS#1 1.5 RSA Encryption . . . . . . . . . . . . . . . . 10 Appendix A. Commonly used ASN.1 objects . . . . . . . . . . . . . 11
A.1.1. sha1WithRSAEncryption . . . . . . . . . . . . . . . . 10 A.1. PKCS#1 1.5 RSA Encryption . . . . . . . . . . . . . . . . 11
A.1.2. sha256WithRSAEncryption . . . . . . . . . . . . . . . 10 A.1.1. sha1WithRSAEncryption . . . . . . . . . . . . . . . . 11
A.1.3. sha384WithRSAEncryption . . . . . . . . . . . . . . . 11 A.1.2. sha256WithRSAEncryption . . . . . . . . . . . . . . . 12
A.1.4. sha512WithRSAEncryption . . . . . . . . . . . . . . . 11 A.1.3. sha384WithRSAEncryption . . . . . . . . . . . . . . . 12
A.2. DSA . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 A.1.4. sha512WithRSAEncryption . . . . . . . . . . . . . . . 12
A.2.1. dsa-with-sha1 . . . . . . . . . . . . . . . . . . . . 11 A.2. DSA . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
A.2.2. dsa-with-sha256 . . . . . . . . . . . . . . . . . . . 11 A.2.1. dsa-with-sha1 . . . . . . . . . . . . . . . . . . . . 12
A.3. ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . 12 A.2.2. dsa-with-sha256 . . . . . . . . . . . . . . . . . . . 13
A.3.1. ecdsa-with-sha1 . . . . . . . . . . . . . . . . . . . 12 A.3. ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . 13
A.3.2. ecdsa-with-sha256 . . . . . . . . . . . . . . . . . . 12 A.3.1. ecdsa-with-sha1 . . . . . . . . . . . . . . . . . . . 13
A.3.3. ecdsa-with-sha384 . . . . . . . . . . . . . . . . . . 12 A.3.2. ecdsa-with-sha256 . . . . . . . . . . . . . . . . . . 13
A.3.4. ecdsa-with-sha512 . . . . . . . . . . . . . . . . . . 12 A.3.3. ecdsa-with-sha384 . . . . . . . . . . . . . . . . . . 14
A.4. RSASSA-PSS . . . . . . . . . . . . . . . . . . . . . . . . 13 A.3.4. ecdsa-with-sha512 . . . . . . . . . . . . . . . . . . 14
A.4.1. RSASSA-PSS with empty parameters . . . . . . . . . . . 13 A.4. RSASSA-PSS . . . . . . . . . . . . . . . . . . . . . . . . 14
A.4.2. RSASSA-PSS with default parameters . . . . . . . . . . 13 A.4.1. RSASSA-PSS with empty parameters . . . . . . . . . . . 14
Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 13 A.4.2. RSASSA-PSS with default parameters . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
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 ECDSA
groups are added, as each of them would require new authentication groups are added, as each of them would require new authentication
skipping to change at page 4, line 38 skipping to change at page 4, line 38
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 are the same ASN.1 which is used in the
AlgorithmIdentifier of the PKIX (Section 4.1.1.2 of [RFC5280]). The AlgorithmIdentifier of the PKIX (Section 4.1.1.2 of [RFC5280])
algorithm OID inside the ASN.1 specifies the signature algorithm and encoded using distinguished encoding rules (DER) [CCITT.X690.2002].
the hash function, which are needed to signature verification. The The algorithm OID inside the ASN.1 specifies the signature algorithm
EC curve is always known by the peer because it needs to have the 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
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
there is two possible ASN.1 encoding possible, one with parameters there is two possible ASN.1 encoding possible, one with parameters
being NULL and others where the whole parameters is omitted. This is being NULL and others where the whole parameters is omitted. This is
because some of those algorithms are specified that way. When because some of those algorithms are specified that way. When
encoding the ASN.1 implementations should use the preferred way, i.e. encoding the ASN.1 implementations should use the preferred way, i.e.
if the algorithm specification says "preferredPresent" then parameter if the algorithm specification says "preferredPresent" then parameter
skipping to change at page 7, line 28 skipping to change at page 7, line 28
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Notify Payload Format. Figure 3: Notify Payload Format.
Protocol ID is 0, SPI Size 0, and Notify Message Type <TBD from Protocol ID is 0, SPI Size 0, and Notify Message Type <TBD from
status types>. The Notification Data value contains list of 16-bit status types>. The Notification Data value contains list of 16-bit
hash algorithm identifiers from the newly created Hash Algorithm hash algorithm identifiers from the newly created Hash Algorithm
Identifiers for the IKEv2 IANA registry. Identifiers for the IKEv2 IANA registry.
5. Security Considerations 5. Selecting Public Key Algorithm
This specification does not provide a way for the peers to indicate
the public / private key pair types they have. I.e. how can the
responder select public / private key pair type that the initiator
supports. There is already several ways this information can be
found in common cases.
One of the ways to find out which key the initiator wants the
responder to use is to indicate that in the IDr payload of the
IKE_AUTH request of the initiator. I.e initiator indicates that it
wants the responder to use certain public / private key pair by
sending IDr which indicates that information. This means the
responder needs to have different identities configured and each of
those identities needs to be tied up to certain public / private key
(or key type).
Another way to get this information is from the Certificate Request
payload sent by the initiator. For example if the initiator
indicates in his Certificate Request payload that it trust CA which
is signed by the ECDSA key, that will also indicate it can be process
ECDSA signatures, thus responder can safely use ECDSA keys when
authenticating himself.
Responder can also check the key type used by the initiator, and use
same key type than the initiator used. This does not work in case
the initiator is using shared secret or EAP authentication, as in
that case it is not using public key. If initiator is using public
key authentication himself this is most likely the best way for the
responder to find the type the initiator supports.
In case the initiator uses a public key type that the responder will
not support, the responder will reply with AUTHENTICATION_FAILED
error. If initiator has multiple different keys it can try different
key (and perhaps different key type) until it finds key that the
other end accepts. Initiator can also use the Certificate Request
payload sent by the responder to help deciding which public key
should be tried. In normal case if initiator has multiple public
keys, there is configuration that will select one of those for each
connection, so the proper key is know by configuration.
6. Security Considerations
The "Recommendations for Key Management" ([NIST800-57]) table 2 The "Recommendations for Key Management" ([NIST800-57]) table 2
combined with table 3 gives recommendations for how to select combined with table 3 gives recommendations for how to select
suitable hash functions for the signature. suitable hash functions for the signature.
This new digital signature method does not tie the EC curve to the This new digital signature method does not tie the EC curve to the
specific hash function, which was done in the old IKEv2 ECDSA specific hash function, which was done in the old IKEv2 ECDSA
methods. This means it is possible to use 512-bit EC curve with methods. This means it is possible to use 512-bit EC curve with
SHA1, i.e. this allows mixing different security levels. This means SHA1, i.e. this allows mixing different security levels. This means
that the security of the authentication method is the security of the that the security of the authentication method is the security of the
skipping to change at page 8, line 10 skipping to change at page 9, line 5
The current IKEv2 uses RSASSA-PKCS1-v1_5, which do have some problems The current IKEv2 uses RSASSA-PKCS1-v1_5, which do have some problems
([KA08], [ME01]) and does not allow using newer padding methods like ([KA08], [ME01]) and does not allow using newer padding methods like
RSASSA-PSS. This new method allows using other padding methods. RSASSA-PSS. This new method allows using other padding methods.
The current IKEv2 only allows using normal DSA with SHA-1, which The current IKEv2 only allows using normal DSA with SHA-1, which
means the security of the regular DSA is limited to the security of means the security of the regular DSA is limited to the security of
SHA-1. This new methods allows using longer keys and longer hashes SHA-1. This new methods allows using longer keys and longer hashes
with DSA. with DSA.
6. IANA Considerations 7. IANA Considerations
This document creates new IANA registry for IKEv2 Hash Algorithms. This document creates new IANA registry for IKEv2 Hash Algorithms.
Changes and additions to this registry is by expert review. Changes and additions to this registry is by expert review.
The initial values of this registry is: The initial values of this registry is:
Hash Algorithm Value Hash Algorithm Value
-------------- ----- -------------- -----
RESERVED 0 RESERVED 0
SHA1 1 SHA1 1
SHA2-256 2 SHA2-256 2
SHA2-384 3 SHA2-384 3
SHA2-512 4 SHA2-512 4
MD5 is not included to the hash algorithm list as it is not MD5 is not included to the hash algorithm list as it is not
considered safe enough for signature hash uses. considered safe enough for signature hash uses.
Values 5-1023 are reserved to IANA. Values 1024-65535 are for Values 5-1023 are reserved to IANA. Values 1024-65535 are for
private use among mutually consenting parties. private use among mutually consenting parties.
7. Acknowledgements This specification also allocates one new IKEv2 Notify Message Types
- Status Types value for the SIGNATURE_HASH_ALGORITHMS.
8. Acknowledgements
Most of this work was based on the work done in the IPsecME design Most of this work was based on the work done in the IPsecME design
team for the ECDSA. The design team members were: Dan Harking, team for the ECDSA. The design team members were: Dan Harking,
Johannes Merkle, Tero Kivinen, David McGrew, and Yoav Nir. Johannes Merkle, Tero Kivinen, David McGrew, and Yoav Nir.
8. References 9. References
8.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.
[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.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)", "Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 5996, September 2010. RFC 5996, September 2010.
8.2. Informative References 9.2. Informative References
[CCITT.X690.2002]
International Telephone and Telegraph Consultative
Committee, "ASN.1 encoding rules: Specification of basic
encoding Rules (BER), Canonical encoding rules (CER) and
Distinguished encoding rules (DER)", CCITT Recommendation
X.690, July 2002.
[KA08] Kuehn, U., Pyshkin, A., Tews, E., and R. Weinmann, [KA08] Kuehn, U., Pyshkin, A., Tews, E., and R. Weinmann,
"Variants of Bleichenbacher's Low-Exponent Attack on "Variants of Bleichenbacher's Low-Exponent Attack on
PKCS#1 RSA Signatures", Proc. Sicherheit 2008 pp.97-109. PKCS#1 RSA Signatures", Proc. Sicherheit 2008 pp.97-109.
[ME01] Menezes, A., "Evaluation of Security Level of [ME01] Menezes, A., "Evaluation of Security Level of
Cryptography: RSA-OAEP, RSA-PSS, RSA Signature", Cryptography: RSA-OAEP, RSA-PSS, RSA Signature",
December 2001. December 2001.
[NIST800-57] [NIST800-57]
skipping to change at page 10, line 13 skipping to change at page 11, line 17
Cryptography for the Financial Services Industry: The Cryptography for the Financial Services Industry: The
Elliptic Curve Digital Signature Algorithm (ECDSA)", Elliptic Curve Digital Signature Algorithm (ECDSA)",
ANSI X9.62, November 2005. ANSI X9.62, November 2005.
Appendix A. Commonly used ASN.1 objects Appendix A. Commonly used ASN.1 objects
This section lists commonly used ASN.1 objects in binary form. This This section lists commonly used ASN.1 objects in binary form. This
section is not-normative, and these values should only be used as section is not-normative, and these values should only be used as
examples, i.e. if this and the actual specification of the algorithm examples, i.e. if this and the actual specification of the algorithm
ASN.1 object is different the actual format specified in the actual ASN.1 object is different the actual format specified in the actual
specification needs to be used. These values are taken form the New specification needs to be used. These values are taken from the New
ASN.1 Modules for the Public Key Infrastructure Using X.509 ASN.1 Modules for the Public Key Infrastructure Using X.509
([RFC5912]). ([RFC5912]).
A.1. PKCS#1 1.5 RSA Encryption A.1. PKCS#1 1.5 RSA Encryption
These algorithm identifiers here include several different ASN.1 These algorithm identifiers here include several different ASN.1
objects with different hash algorithms. In this document we only objects with different hash algorithms. In this document we only
include the commonly used ones i.e. the one using SHA-1, or SHA-2 as include the commonly used ones i.e. the one using SHA-1, or SHA-2 as
hash function. Some of those other algorithms (MD2, MD5) specified hash function. Some of those other algorithms (MD2, MD5) specified
for this are not safe enough to be used as signature hash algorithm, for this are not safe enough to be used as signature hash algorithm,
skipping to change at page 10, line 40 skipping to change at page 11, line 44
Additional Algorithms and Identifiers for RSA Cryptography for PKIX Additional Algorithms and Identifiers for RSA Cryptography for PKIX
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.
XXX binary object missing Name = sha1WithRSAEncryption, oid = 1.2.840.113549.1.1.5
Length = 17
0000: 300f 300d 0609 2a86 4886 f70d 0101 0505
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.
XXX binary object missing Name = sha256WithRSAEncryption, oid = 1.2.840.113549.1.1.11
Length = 17
0000: 300f 300d 0609 2a86 4886 f70d 0101 0b05
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.
XXX binary object missing Name = sha384WithRSAEncryption, oid = 1.2.840.113549.1.1.12
Length = 17
0000: 300f 300d 0609 2a86 4886 f70d 0101 0c05
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.
XXX binary object missing Name = sha512WithRSAEncryption, oid = 1.2.840.113549.1.1.13
Length = 17
0000: 300f 300d 0609 2a86 4886 f70d 0101 0d05
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 11, line 35 skipping to change at page 13, line 4
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.
XXX binary object missing Name = dsa-with-sha1, oid = 1.2.840.10040.4.3
Length = 13
0000: 300b 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.
XXX binary object missing Name = dsa-with-sha256, oid = 2.16.840.1.101.3.4.3.2
Length = 15
0000: 300d 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.
XXX binary object missing Name = ecdsa-with-sha1, oid = 1.2.840.10045.4.1
Length = 13
0000: 300b 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.
XXX binary object missing Name = ecdsa-with-sha256, oid = 1.2.840.10045.4.3.2
Length = 14
0000: 300c 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.
XXX binary object missing Name = ecdsa-with-sha384, oid = 1.2.840.10045.4.3.3
Length = 14
0000: 300c 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.
XXX binary object missing Name = ecdsa-with-sha512, oid = 1.2.840.10045.4.3.4
Length = 14
0000: 300c 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).
XXX binary object missing Name = RSASSA-PSS with empty parameters, oid = 1.2.840.113549.1.1.10
Length = 17
0000: 300f 300d 0609 2a86 4886 f70d 0101 0a30
0010: 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.
XXX binary object missing 0000 : SEQUENCE
0002 : SEQUENCE
0004 : OBJECT IDENTIFIER RSASSA-PSS (1.2.840.113549.1.1.10)
000f : SEQUENCE
0011 : CONTEXT 0
0013 : OBJECT IDENTIFIER Sha-1 (1.3.14.3.2.26)
001a : NULL
001c : CONTEXT 1
001e : OBJECT IDENTIFIER id-mgf1 ( 1.2.840.113549.1.1.8)
0029 : SEQUENCE
002b : OBJECT IDENTIFIER Sha-1 (1.3.14.3.2.26)
0032 : NULL
0034 : CONTEXT 2 (1 bytes)
0036 : INTEGER 20 (0x14)
0037 : CONTEXT 3 (1 bytes)
0039 : INTEGER 01 (0x01)
Name = RSASSA-PSS with default parameters,
oid = 1.2.840.113549.1.1.10
Length = 58
0000: 3038 3036 0609 2a86 4886 f70d 0101 0a30
0010: 29a0 0906 052b 0e03 021a 0500 a116 0609
0020: 2a86 4886 f70d 0101 0830 0906 052b 0e03
0030: 021a 0500 8201 1483 0101
Appendix B. Examples Appendix B. Examples
XXX Examples missing
XXX Most likely include examples for sha1WithRSAEncryption and dsa-
with-sha256 or something like that. I do not think we need all
possible signature examples.
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. 27 change blocks. 
53 lines changed or deleted 161 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/