One document matched: draft-kivinen-ipsecme-signature-auth-04.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc4055 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4055.xml'>
<!ENTITY rfc3279 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3279.xml'>
<!ENTITY rfc5280 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5280.xml'>
<!ENTITY rfc5480 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5480.xml'>
<!ENTITY rfc5758 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5758.xml'>
<!ENTITY rfc5996 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5996.xml'>
<!ENTITY rfc5912 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5912.xml'>
<!ENTITY x690 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml2/reference.CCITT.X690.2002.xml'>
]>
<rfc category='std' ipr='trust200902' updates='RFC 5996'
docName='draft-kivinen-ipsecme-signature-auth-04.txt'>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc='yes' ?>
<?rfc symrefs='yes' ?>
<?rfc sortrefs='yes'?>
<?rfc iprnotified='no' ?>
<?rfc compact='yes' ?>
<?rfc strict='yes' ?>
<front>
<title>Signature Authentication in IKEv2</title>
<author initials='T.' surname='Kivinen' fullname='Tero Kivinen'>
<organization>INSIDE Secure</organization>
<address>
<postal>
<street>Eerikinkatu 28</street>
<code>FI-00180</code>
<city>HELSINKI</city>
<country>FI</country>
</postal>
<email>kivinen@iki.fi</email>
</address>
</author>
<date month='December' year='2013' />
<area>Security</area>
<workgroup>IP Security Maintenance and Extensions
(ipsecme)</workgroup>
<abstract>
<t>The Internet Key Exchange Version 2 (IKEv2) protocol has
limited support for the Elliptic Curve Digital Signature Algorithm
(ECDSA). The current version only includes support for three
Elliptic Curve groups, and there is fixed hash algorithm tied to
each curve. This document generalizes the IKEv2 signature support
so it can support any signature method supported by the PKIX and
also adds signature hash algorithm negotiation. This is generic
mechanism, and is not limited to ECDSA, but can also be used with
other signature algorithms.</t>
</abstract>
</front>
<middle>
<section title='Introduction'>
<t>This document adds new IKEv2 (<xref target='RFC5996'/>)
authentication method to support all kinds of signature methods.
The current signature based authentication methods in the IKEv2
are per algorithm, i.e. there is one for RSA Digital signatures,
one for DSS Digital Signatures (using SHA-1) and three for
different ECDSA curves each tied to exactly one hash algorithm.
This design starts to be cumbersome when more ECDSA groups are
added, as each of them would require new authentication method and
as with ECDSA there is no way to extract the hash algorithm from
the signature, each ECDSA algorithm would need to come with fixed
hash algorithm tied to it.</t>
<t>With the SHA-3 definitions coming out, it is seen that it
might be possible that in the future the signature methods are
used with SHA-3 also, not only SHA-2. This means new mechanism
for negotiating the hash algorithm for the signature algorithms
is needed.</t>
<t>The RSA Digital Signatures format in the IKEv2 is specified to
use RSASSA-PKCS1-v1_5, but there has been some discussions that
newer padding methods should be preferred instead of PKCS #1
version 1.5 (See section 5 of <xref target="RFC4055"/>). The DSS
Digital Signatures format in 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.</t>
<t>This documents specifies two things, one is one new
authentication method, which includes the enough information
inside the Authentication payload data that the signature hash
algorithm can be extracted from there (see <xref
target="authpayload"/>). The another thing is to add indication
of supported signature hash algorithms by the peer (see <xref
target="notify"/>). This allows peer to know which hash
algorithms are supported by the other end and use one of them
(provided one is allowed by policy). There is no need to actually
negotiate one common hash algorithm, as different hash algorithms
can be used in different directions if needed.</t>
<t>The new digital signature method needs to be flexible enough to
include all current signature methods (RSA, DSA, ECDSA,
RSASSA-PSS, etc), and also allow adding new things in the future
(ECGDSA, ElGamal etc). For this the signature algorithm is
specified in the same way as the PKIX (<xref target="RFC5280"/>)
specifies the signature of the Certificate, i.e. there is simple
ASN.1 object before the actual signature data. This ASN.1 object
contains the OID specifying the algorithm, and associated
parameters to it. In normal case the IKEv2 implementations
supports fixed amount of signature methods, with commonly used
parameters, so it is acceptable for the implementation to just
treat this ASN.1 object as binary blob which is compared against
the known values, or the implementation can parse the ASN.1 and
extract information from there.</t>
</section>
<section anchor="terminology" title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
<xref target='RFC2119'/>.</t>
</section>
<section title="Authentication Payload" anchor="authpayload">
<t>This document specifies new "Digital Signature" authentication
method. This method can be used with any types of signatures. As
the authentication methods are not negotiated in the IKEv2, the
peer is only allowed to use this authentication method if the
SIGNATURE_HASH_ALGORITHMS Notify Payload has been sent and
received.</t>
<t>In this newly defined authentication method, the Authentication
Data field inside the Authentication Payload does not include only
the signature value, but instead the signature value is prefixed
with the ASN.1 object containing the algorithm used to generate
the signature. The ASN.1 object contains the algorithm
identification OID, and this OID identifies both the signature
algorithm and the hash used when calculating the signature. In
addition to the OID there is optional parameters which might be
needed for algorithms like RSASSA-PSS.</t>
<t>To make implementations easier, the ASN.1 object is prefixed by
the 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 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 able to parse or generate ASN.1 objects.
See <xref target='asn1objects'/> for commonly used ASN.1
objects.</t>
<t>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 <xref
target="RFC5280"/>) encoded using distinguished encoding rules
(DER) <xref target="CCITT.X690.2002" />. The algorithm OID inside
the ASN.1 specifies the signature algorithm 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 signature
verification and public key specifies the curve.</t>
<t>Currently only the RSASSA-PSS uses the parameters, for all
others the parameters is either NULL or missing. Note, that for
some algorithms there is two possible ASN.1 encoding possible, one
with parameters being NULL and others where the whole parameters
is omitted. This is because some of those algorithms are specified
that way. When encoding the ASN.1 implementations should use the
preferred way, i.e. if the algorithm specification says
"preferredPresent" then parameter object needs to be there (i.e.
it will be NULL if no parameters is specified), and if it says
"preferredAbsent", then the whole parameters object is missing.</t>
<t>The Authentication payload is defined in IKEv2 as follows:</t>
<figure anchor="payload" title="Authentication Payload Format." ><artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Method | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Authentication Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
<t><list style='symbols'>
<t>Auth Method (1 octet) - Specifies the method of
authentication used.
<figure><artwork><![CDATA[
Mechanism Value
-----------------------------------------------------------------
Digital Signature <TBD>
Computed as specified in Section 2.15 of RFC5996 using a
private key associated with the public key sent in certificate
payload, and using one of the hash algorithms sent by the other
end in the SIGNATURE_HASH_ALGORITHMS notify payload. If both
ends send and receive SIGNATURE_HASH_ALGORITHMS and signature
authentication is to be used, then this method MUST be used.
The Authentication Data field has bit different format than in
other Authentication methods (see below).
]]></artwork></figure></t>
<t>Authentication Data (variable length) - see Section 2.15 of
RFC5996. For "Digital Signature" format the Authentication data
contains special format as follows:
<figure anchor="authdata" title="Authentication Data Format." ><artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASN.1 Length | AlgorithmIdentifier ASN.1 object |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ AlgorithmIdentifier ASN.1 object continuing ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Signature Value ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
Where the ASN.1 Length is the length of the ASN.1 encoded
AlgorithmIdentifier object, and after that is the actual
AlgorithmIdentifier ASN.1 object, followed by the actual signature
value. There is no padding between ASN.1 object and signature
value.
For the hash truncation the method of X9.62 (<xref
target="X9.62"/>) MUST be used.</t>
</list></t>
</section>
<section title="Hash Algorithm Notification" anchor="notify">
<t>The supported hash algorithms that can be used for the
signature algorithms are now indicated with new
SIGNATURE_HASH_ALGORITHMS Notification Payload sent inside the
IKE_SA_INIT exchange. This notification also indicates the
support of the new signature algorithm method, i.e. sending this
notification tells that new "Digital Signature" authentication
method is supported and that following hash functions are
supported by sending peer. Both ends sends their list of
supported hash-algorithms and when calculating signature a peer
MUST pick one algorithm sent by the other peer. Note, that
different algorithms can be used in different directions. The
algorithm OID matching selected hash algorithm (and signature
algorithm) used when calculating the signature is sent inside the
Authentication Data field of the Authentication Payload.</t>
<figure anchor="notifypayload" title="Notify Payload Format." ><artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol ID | SPI Size | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Security Parameter Index (SPI) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Notification Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
<t>Protocol ID is 0, SPI Size 0, and Notify Message Type <TBD
from status types>. The Notification Data value contains list
of 16-bit hash algorithm identifiers from the newly created Hash
Algorithm Identifiers for the IKEv2 IANA registry.</t>
</section>
<section title='Selecting Public Key Algorithm'>
<t>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.</t>
<t>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).</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section title='Security Considerations'>
<t>The "Recommendations for Key Management" (<xref
target='NIST800-57'/>) table 2 combined with table 3 gives
recommendations for how to select suitable hash functions for the
signature.</t>
<t>This new digital signature method does not tie the EC curve to
the specific hash function, which was done in the old IKEv2 ECDSA
methods. This means it is possible to use 512-bit EC curve with
SHA1, i.e. this allows mixing different security levels. This
means that the security of the authentication method is the
security of the weakest of components (signature algorithm, hash
algorithm, curve). This might make the security analysis of the
system bit more complex. Note, that this kind of mixing of the
security can be disallowed by the policy.</t>
<t>The hash algorithm registry does not include MD5 as supported
hash algorithm, as it is not considered safe enough for signature
use (<xref target='WY05'/>).</t>
<t>The current IKEv2 uses RSASSA-PKCS1-v1_5, which do have some
problems (<xref target='KA08'/>, <xref target="ME01"/>) and does
not allow using newer padding methods like RSASSA-PSS. This new
method allows using other padding methods.</t>
<t>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 SHA-1. This new methods allows using longer keys and
longer hashes with DSA.</t>
</section>
<section title='IANA Considerations' anchor='iana'>
<t>This document creates new IANA registry for IKEv2 Hash
Algorithms. Changes and additions to this registry is by expert
review.</t>
<t>The initial values of this registry is:</t>
<figure><artwork><![CDATA[
Hash Algorithm Value
-------------- -----
RESERVED 0
SHA1 1
SHA2-256 2
SHA2-384 3
SHA2-512 4
]]></artwork></figure>
<t>MD5 is not included to the hash algorithm list as it is not
considered safe enough for signature hash uses.</t>
<t>Values 5-1023 are reserved to IANA. Values 1024-65535 are for
private use among mutually consenting parties.</t>
<t>This specification also allocates one new IKEv2 Notify Message
Types - Status Types value for the SIGNATURE_HASH_ALGORITHMS, and
adds new value "Digital Signature" to the IKEv2 Authentication
Method registry. </t>
</section>
<section title='Acknowledgements'>
<t>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, Johannes Merkle, Tero Kivinen, David McGrew, and Yoav
Nir.</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc5280;
&rfc5996;
</references>
<references title='Informative References'>
&rfc3279;
&rfc4055;
&rfc5480;
&rfc5758;
&rfc5912;
<reference anchor='WY05'>
<front>
<title>How to break MD5 and other hash functions</title>
<author initials='X.' surname='Wang'><organization/></author>
<author initials='H.' surname='Yu'><organization/></author>
<date year='2005'/>
</front>
<seriesInfo name='Proceedings of EuroCrypt 2005, Lecture Notes in Computer Science' value='Vol. 3494'/>
</reference>
<reference anchor='KA08'>
<front>
<title>Variants of Bleichenbacher's Low-Exponent Attack on PKCS#1 RSA Signatures</title>
<author initials='U.' surname='Kühn'><organization/></author>
<author initials='A.' surname='Pyshkin'><organization/></author>
<author initials='E.' surname='Tews'><organization/></author>
<author initials='R.' surname='Weinmann'><organization/></author>
</front>
<seriesInfo name='Proc. Sicherheit 2008' value='pp.97-109'/>
</reference>
<reference anchor="NIST800-57">
<front>
<title>Recommendations for Key Management</title>
<author initials="E." surname="Barker"><organization/></author>
<author initials="W." surname="Barker"><organization/></author>
<author initials="W." surname="Burr"><organization/></author>
<author initials="W." surname="Polk"><organization/></author>
<author initials="M." surname="Smid"><organization/></author>
<date month="March" year="2007"/>
</front>
<seriesInfo name="NIST SP" value="800-57"/>
</reference>
<reference anchor="X9.62">
<front>
<title>Public Key Cryptography for the Financial
Services Industry: The Elliptic Curve Digital Signature
Algorithm (ECDSA)</title>
<author>
<organization>American National Standards
Institute</organization>
</author>
<date month="November" year="2005"/>
</front>
<seriesInfo name="ANSI" value="X9.62"/>
</reference>
&x690;
<reference anchor="ME01">
<front>
<title>Evaluation of Security Level of Cryptography: RSA-OAEP,
RSA-PSS, RSA Signature</title>
<author initials="A." surname="Menezes">
<organization>University of Waterloo</organization></author>
<date month="December" year="2001"/>
</front>
</reference>
</references>
<section title='Commonly used ASN.1 objects' anchor='asn1objects'>
<t>This section lists commonly used ASN.1 objects in binary form.
This section is not-normative, and these values should only be
used as examples, i.e. if this and the actual specification of the
algorithm ASN.1 object is different the actual format specified in
the actual specification needs to be used. These values are taken
from the New ASN.1 Modules for the Public Key Infrastructure Using
X.509 (<xref target='RFC5912' />).</t>
<section title='PKCS#1 1.5 RSA Encryption'>
<t>These algorithm identifiers here include several different
ASN.1 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 hash function. Some of those other algorithms (MD2,
MD5) specified for this are not safe enough to be used as
signature hash algorithm, and some are omitted as there is no
hash algorithm specified in the our IANA registry for them.
Note, that there is no parameters in any of these, but all
specified here needs to have NULL parameters present in the
ASN.1.</t>
<t>See Algorithms and Identifiers for PKIX Profile (<xref
target='RFC3279'/>) and Additional Algorithms and Identifiers for
RSA Cryptography for PKIX Profile (<xref target='RFC4055'/>) for
more information.</t>
<section title='sha1WithRSAEncryption'>
<t>sha1WithRSAEncryption OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-1(1) 5 }</t>
<t>Parameters are required, and they must be NULL.</t>
<figure><artwork><![CDATA[
Name = sha1WithRSAEncryption, oid = 1.2.840.113549.1.1.5
Length = 17
0000: 300f 300d 0609 2a86 4886 f70d 0101 0505
0010: 00
]]></artwork></figure>
</section>
<section title='sha256WithRSAEncryption'>
<t>sha256WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 11 }</t>
<t>Parameters are required, and they must be NULL.</t>
<figure><artwork><![CDATA[
Name = sha256WithRSAEncryption, oid = 1.2.840.113549.1.1.11
Length = 17
0000: 300f 300d 0609 2a86 4886 f70d 0101 0b05
0010: 00
]]></artwork></figure>
</section>
<section title='sha384WithRSAEncryption'>
<t>sha384WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 12 }</t>
<t>Parameters are required, and they must be NULL.</t>
<figure><artwork><![CDATA[
Name = sha384WithRSAEncryption, oid = 1.2.840.113549.1.1.12
Length = 17
0000: 300f 300d 0609 2a86 4886 f70d 0101 0c05
0010: 00
]]></artwork></figure>
</section>
<section title='sha512WithRSAEncryption'>
<t>sha512WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 13 }</t>
<t>Parameters are required, and they must be NULL.</t>
<figure><artwork><![CDATA[
Name = sha512WithRSAEncryption, oid = 1.2.840.113549.1.1.13
Length = 17
0000: 300f 300d 0609 2a86 4886 f70d 0101 0d05
0010: 00
]]></artwork></figure>
</section>
</section>
<section title='DSA'>
<t>With different DSA algorithms the parameters are always
omitted. Again we omit dsa-with-sha224 as there is no hash
algorithm in our IANA registry for it.</t>
<t>See Algorithms and Identifiers for PKIX Profile (<xref
target='RFC3279'/>) and PKIX Additional Algorithms and
Identifiers for DSA and ECDSA (<xref target='RFC5758'/> for more
information.</t>
<section title='dsa-with-sha1'>
<t>dsa-with-sha1 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) x9-57(10040) x9algorithm(4) 3 }</t>
<t>Parameters are absent.</t>
<figure><artwork><![CDATA[
Name = dsa-with-sha1, oid = 1.2.840.10040.4.3
Length = 13
0000: 300b 3009 0607 2a86 48ce 3804 03
]]></artwork></figure>
</section>
<section title='dsa-with-sha256'>
<t>dsa-with-sha256 OBJECT IDENTIFIER ::= {
joint-iso-ccitt(2) country(16) us(840) organization(1) gov(101)
csor(3) algorithms(4) id-dsa-with-sha2(3) 2 }</t>
<t>Parameters are absent.</t>
<figure><artwork><![CDATA[
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
]]></artwork></figure>
</section>
</section>
<section title='ECDSA'>
<t>With different ECDSA algorithms the parameters are always
omitted. Again we omit ecdsa-with-sha224 as there is no hash
algorithm in our IANA registry for it.</t>
<t>See Elliptic Curve Cryptography Subject Public Key
Information (<xref target='RFC5480'/>), Algorithms and
Identifiers for PKIX Profile (<xref target='RFC3279'/>) and PKIX
Additional Algorithms and Identifiers for DSA and ECDSA (<xref
target='RFC5758'/> for more information.</t>
<section title='ecdsa-with-sha1'>
<t>ecdsa-with-SHA1 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-X9-62(10045)
signatures(4) 1 }</t>
<t>Parameters are absent.</t>
<figure><artwork><![CDATA[
Name = ecdsa-with-sha1, oid = 1.2.840.10045.4.1
Length = 13
0000: 300b 3009 0607 2a86 48ce 3d04 01
]]></artwork></figure>
</section>
<section title='ecdsa-with-sha256'>
<t>ecdsa-with-SHA256 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4)
ecdsa-with-SHA2(3) 2 }</t>
<t>Parameters are absent.</t>
<figure><artwork><![CDATA[
Name = ecdsa-with-sha256, oid = 1.2.840.10045.4.3.2
Length = 14
0000: 300c 300a 0608 2a86 48ce 3d04 0302
]]></artwork></figure>
</section>
<section title='ecdsa-with-sha384'>
<t>ecdsa-with-SHA384 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4)
ecdsa-with-SHA2(3) 3 }</t>
<t>Parameters are absent.</t>
<figure><artwork><![CDATA[
Name = ecdsa-with-sha384, oid = 1.2.840.10045.4.3.3
Length = 14
0000: 300c 300a 0608 2a86 48ce 3d04 0303
]]></artwork></figure>
</section>
<section title='ecdsa-with-sha512'>
<t>ecdsa-with-SHA512 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4)
ecdsa-with-SHA2(3) 4 }</t>
<t>Parameters are absent.</t>
<figure><artwork><![CDATA[
Name = ecdsa-with-sha512, oid = 1.2.840.10045.4.3.4
Length = 14
0000: 300c 300a 0608 2a86 48ce 3d04 0304
]]></artwork></figure>
</section>
</section>
<section title='RSASSA-PSS'>
<t>With the RSASSA-PSS the algorithm object identifier is always
id-RSASSA-PSS, but the hash function is taken from the
parameters, and it is required. See <xref target="RFC4055"/> for
more information.</t>
<section title='RSASSA-PSS with empty parameters'>
<t>id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 }</t>
<t>Parameters are empty, but the ASN.1 part of the sequence
must be there. This means default parameters are used (same as
the next example).</t>
<figure><artwork><![CDATA[
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
]]></artwork></figure>
</section>
<section title='RSASSA-PSS with default parameters'>
<t>id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 }</t>
<t>Here the parameters are present, and contains the default
parameters, i.e. SHA-1, mgf1SHA1, saltlength of 20,
trailerfield of 1.</t>
<figure><artwork><![CDATA[
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)
]]></artwork></figure>
<figure><artwork><![CDATA[
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
]]></artwork></figure>
</section>
</section>
</section>
<section title='Examples'>
<t>XXX Examples missing</t>
<t>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. </t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 03:01:58 |