idnits 2.17.1 draft-kivinen-ipsecme-signature-auth-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC5996, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5996, updated by this document, for RFC5378 checks: 2008-08-26) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 16, 2013) is 4025 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IP Security Maintenance and Extensions T. Kivinen 3 (ipsecme) INSIDE Secure 4 Internet-Draft April 16, 2013 5 Updates: RFC 5996 (if approved) 6 Intended status: Standards Track 7 Expires: October 18, 2013 9 Signature Authentication in IKEv2 10 draft-kivinen-ipsecme-signature-auth-01.txt 12 Abstract 14 The Internet Key Exchange Version 2 (IKEv2) protocol has limited 15 support for the Elliptic Curve Digital Signature Algorithm (ECDSA). 16 The current version only includes support for three Elliptic Curve 17 groups, and there is fixed hash algorithm tied to each curve. This 18 document generalizes the IKEv2 signature support so it can support 19 any signature method supported by the PKIX and also adds signature 20 hash algorithm negotiation. This is generic mechanism, and is not 21 limited to ECDSA, but can also be used with other signature 22 algorithms. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on October 18, 2013. 41 Copyright Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Authentication Payload . . . . . . . . . . . . . . . . . . . . 4 61 4. Hash Algorithm Notification . . . . . . . . . . . . . . . . . 6 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 64 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 67 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 68 Appendix A. Commonly used ASN.1 objects . . . . . . . . . . . . . 10 69 A.1. PKCS#1 1.5 RSA Encryption . . . . . . . . . . . . . . . . 10 70 A.1.1. sha1WithRSAEncryption . . . . . . . . . . . . . . . . 10 71 A.1.2. sha256WithRSAEncryption . . . . . . . . . . . . . . . 10 72 A.1.3. sha384WithRSAEncryption . . . . . . . . . . . . . . . 11 73 A.1.4. sha512WithRSAEncryption . . . . . . . . . . . . . . . 11 74 A.2. DSA . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 A.2.1. dsa-with-sha1 . . . . . . . . . . . . . . . . . . . . 11 76 A.2.2. dsa-with-sha256 . . . . . . . . . . . . . . . . . . . 11 77 A.3. ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 A.3.1. ecdsa-with-sha1 . . . . . . . . . . . . . . . . . . . 12 79 A.3.2. ecdsa-with-sha256 . . . . . . . . . . . . . . . . . . 12 80 A.3.3. ecdsa-with-sha384 . . . . . . . . . . . . . . . . . . 12 81 A.3.4. ecdsa-with-sha512 . . . . . . . . . . . . . . . . . . 12 82 A.4. RSASSA-PSS . . . . . . . . . . . . . . . . . . . . . . . . 13 83 A.4.1. RSASSA-PSS with empty parameters . . . . . . . . . . . 13 84 A.4.2. RSASSA-PSS with default parameters . . . . . . . . . . 13 85 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 13 86 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 88 1. Introduction 90 This document adds new IKEv2 ([RFC5996]) authentication method to 91 support all kinds of signature methods. The current signature based 92 authentication methods in the IKEv2 are per algorithm, i.e. there is 93 one for RSA Digital signatures, one for DSS Digital Signatures (using 94 SHA-1) and three for different ECDSA curves each tied to exactly one 95 hash algorithm. This design starts to be cumbersome when more ECDSA 96 groups are added, as each of them would require new authentication 97 method and as with ECDSA there is no way to extract the hash 98 algorithm from the signature, each ECDSA algorithm would need to come 99 with fixed hash algorithm tied to it. 101 With the SHA-3 definitions coming out, it is seen that it might be 102 possible that in the future the signature methods are used with SHA-3 103 also, not only SHA-2. This means new mechanism for negotiating the 104 hash algorithm for the signature algorithms is needed. 106 The RSA Digital Signatures format in the IKEv2 is specified to use 107 RSASSA-PKCS1-v1_5, but there has been some discussions that newer 108 padding methods should be preferred instead of PKCS #1 version 1.5 109 (See section 5 of [RFC4055]). The DSS Digital Signatures format in 110 the IKEv2 is specified to always use SHA-1, which limits the security 111 of that, meaning there is no point of using long keys with it. 113 This documents specifies two things, one is one new authentication 114 method, which includes the enough information inside the 115 Authentication payload data that the signature hash algorithm can be 116 extracted from there (see Section 3). The another thing is to add 117 indication of supported signature hash algorithms by the peer (see 118 Section 4). This allows peer to know which hash algorithms are 119 supported by the other end and use one of them (provided one is 120 allowed by policy). There is no need to actually negotiate one 121 common hash algorithm, as different hash algorithms can be used in 122 different directions if needed. 124 The new digital signature method needs to be flexible enough to 125 include all current signature methods (RSA, DSA, ECDSA, RSASSA-PSS, 126 etc), and also allow adding new things in the future (ECGDSA, ElGamal 127 etc). For this the signature algorithm is specified in the same way 128 as the PKIX ([RFC5280]) specifies the signature of the Certificate, 129 i.e. there is simple ASN.1 object before the actual signature data. 130 This ASN.1 object contains the OID specifying the algorithm, and 131 associated parameters to it. In normal case the IKEv2 132 implementations supports fixed amount of signature methods, with 133 commonly used parameters, so it is acceptable for the implementation 134 to just treat this ASN.1 object as binary blob which is compared 135 against the known values, or the implementation can parse the ASN.1 136 and extract information from there. 138 2. Terminology 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in [RFC2119]. 144 3. Authentication Payload 146 This document specifies new "Digital Signature" authentication 147 method. This method can be used with any types of signatures. As 148 the authentication methods are not negotiated in the IKEv2, the peer 149 is only allowed to use this authentication method if the 150 SIGNATURE_HASH_ALGORITHMS Notify Payload has been sent and received. 152 In this newly defined authentication method, the Authentication Data 153 field inside the Authentication Payload does not include only the 154 signature value, but instead the signature value is prefixed with the 155 ASN.1 object containing the algorithm used to generate the signature. 156 The ASN.1 object contains the algorithm identification OID, and this 157 OID identifies both the signature algorithm and the hash used when 158 calculating the signature. In addition to the OID there is optional 159 parameters which might be needed for algorithms like RSASSA-PSS. 161 To make implementations easier, the ASN.1 object is prefixed by the 162 8-bit length field. This length field allows simple implementations 163 to be able to know the length of the ASN.1 without the need to parse 164 it, so they can use it as binary blob which is compared against the 165 known signature algorithm ASN.1 objects, i.e. they do not need to be 166 able to parse or generate ASN.1 objects. See Appendix A for commonly 167 used ASN.1 objects. 169 The ASN.1 used here are the same ASN.1 which is used in the 170 AlgorithmIdentifier of the PKIX (Section 4.1.1.2 of [RFC5280]). The 171 algorithm OID inside the ASN.1 specifies the signature algorithm and 172 the hash function, which are needed to signature verification. The 173 EC curve is always known by the peer because it needs to have the 174 certificate or the public key of the other end before it can do 175 signature verification and public key specifies the curve. 177 Currently only the RSASSA-PSS uses the parameters, for all others the 178 parameters is either NULL or missing. Note, that for some algorithms 179 there is two possible ASN.1 encoding possible, one with parameters 180 being NULL and others where the whole parameters is omitted. This is 181 because some of those algorithms are specified that way. When 182 encoding the ASN.1 implementations should use the preferred way, i.e. 183 if the algorithm specification says "preferredPresent" then parameter 184 object needs to be there (i.e. it will be NULL if no parameters is 185 specified), and if it says "preferredAbsent", then the whole 186 parameters object is missing. 188 The Authentication payload is defined in IKEv2 as follows: 190 1 2 3 191 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 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Next Payload |C| RESERVED | Payload Length | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | Auth Method | RESERVED | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | | 198 ~ Authentication Data ~ 199 | | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 Figure 1: Authentication Payload Format. 204 o Auth Method (1 octet) - Specifies the method of authentication 205 used. 207 Mechanism Value 208 ----------------------------------------------------------------- 209 Digital Signature 210 Computed as specified in Section 2.15 of RFC5996 using a 211 private key associated with the public key sent in certificate 212 payload, and using one of the hash algorithms sent by the other 213 end in the SIGNATURE_HASH_ALGORITHMS notify payload. If both 214 ends send and receive SIGNATURE_HASH_ALGORITHMS and signature 215 authentication is to be used, then this method MUST be used. 216 The Authentication Data field has bit different format than in 217 other Authentication methods (see below). 219 o Authentication Data (variable length) - see Section 2.15 of 220 RFC5996. For "Digital Signature" format the Authentication data 221 contains special format as follows: 223 1 2 3 224 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 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | ASN.1 Length | AlgorithmIdentifier ASN.1 object | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | | 229 ~ AlgorithmIdentifier ASN.1 object continuing ~ 230 | | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | | 233 ~ Signature Value ~ 234 | | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 Figure 2: Authentication Data Format. 239 Where the ASN.1 Length is the length of the ASN.1 encoded 240 AlgorithmIdentifier object, and after that is the actual 241 AlgorithmIdentifier ASN.1 object, followed by the actual signature 242 value. There is no padding between ASN.1 object and signature 243 value. For the hash truncation the method of X9.62 ([X9.62]) MUST 244 be used. 246 4. Hash Algorithm Notification 248 The supported hash algorithms that can be used for the signature 249 algorithms are now indicated with new SIGNATURE_HASH_ALGORITHMS 250 Notification Payload sent inside the IKE_SA_INIT exchange. This 251 notification also indicates the support of the new signature 252 algorithm method, i.e. sending this notification tells that new 253 "Digital Signature" authentication method is supported and that 254 following hash functions are supported by sending peer. Both ends 255 sends their list of supported hash-algorithms and when calculating 256 signature a peer MUST pick one algorithm sent by the other peer. 257 Note, that different algorithms can be used in different directions. 258 The algorithm OID matching selected hash algorithm (and signature 259 algorithm) used when calculating the signature is sent inside the 260 Authentication Data field of the Authentication Payload. 262 1 2 3 263 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 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Next Payload |C| RESERVED | Payload Length | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Protocol ID | SPI Size | Notify Message Type | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | | 270 ~ Security Parameter Index (SPI) ~ 271 | | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | | 274 ~ Notification Data ~ 275 | | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 Figure 3: Notify Payload Format. 280 Protocol ID is 0, SPI Size 0, and Notify Message Type . The Notification Data value contains list of 16-bit 282 hash algorithm identifiers from the newly created Hash Algorithm 283 Identifiers for the IKEv2 IANA registry. 285 5. Security Considerations 287 The "Recommendations for Key Management" ([NIST800-57]) table 2 288 combined with table 3 gives recommendations for how to select 289 suitable hash functions for the signature. 291 This new digital signature method does not tie the EC curve to the 292 specific hash function, which was done in the old IKEv2 ECDSA 293 methods. This means it is possible to use 512-bit EC curve with 294 SHA1, i.e. this allows mixing different security levels. This means 295 that the security of the authentication method is the security of the 296 weakest of components (signature algorithm, hash algorithm, curve). 297 This might make the security analysis of the system bit more complex. 298 Note, that this kind of mixing of the security can be disallowed by 299 the policy. 301 The hash algorithm registry does not include MD5 as supported hash 302 algorithm, as it is not considered safe enough for signature use 303 ([WY05]). 305 The current IKEv2 uses RSASSA-PKCS1-v1_5, which do have some problems 306 ([KA08], [ME01]) and does not allow using newer padding methods like 307 RSASSA-PSS. This new method allows using other padding methods. 309 The current IKEv2 only allows using normal DSA with SHA-1, which 310 means the security of the regular DSA is limited to the security of 311 SHA-1. This new methods allows using longer keys and longer hashes 312 with DSA. 314 6. IANA Considerations 316 This document creates new IANA registry for IKEv2 Hash Algorithms. 317 Changes and additions to this registry is by expert review. 319 The initial values of this registry is: 321 Hash Algorithm Value 322 -------------- ----- 323 RESERVED 0 324 SHA1 1 325 SHA2-256 2 326 SHA2-384 3 327 SHA2-512 4 329 MD5 is not included to the hash algorithm list as it is not 330 considered safe enough for signature hash uses. 332 Values 5-1023 are reserved to IANA. Values 1024-65535 are for 333 private use among mutually consenting parties. 335 7. Acknowledgements 337 Most of this work was based on the work done in the IPsecME design 338 team for the ECDSA. The design team members were: Dan Harking, 339 Johannes Merkle, Tero Kivinen, David McGrew, and Yoav Nir. 341 8. References 343 8.1. Normative References 345 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 346 Requirement Levels", BCP 14, RFC 2119, March 1997. 348 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 349 Housley, R., and W. Polk, "Internet X.509 Public Key 350 Infrastructure Certificate and Certificate Revocation List 351 (CRL) Profile", RFC 5280, May 2008. 353 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 354 "Internet Key Exchange Protocol Version 2 (IKEv2)", 355 RFC 5996, September 2010. 357 8.2. Informative References 359 [KA08] Kuehn, U., Pyshkin, A., Tews, E., and R. Weinmann, 360 "Variants of Bleichenbacher's Low-Exponent Attack on 361 PKCS#1 RSA Signatures", Proc. Sicherheit 2008 pp.97-109. 363 [ME01] Menezes, A., "Evaluation of Security Level of 364 Cryptography: RSA-OAEP, RSA-PSS, RSA Signature", 365 December 2001. 367 [NIST800-57] 368 Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid, 369 "Recommendations for Key Management", NIST SP 800-57, 370 March 2007. 372 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 373 Identifiers for the Internet X.509 Public Key 374 Infrastructure Certificate and Certificate Revocation List 375 (CRL) Profile", RFC 3279, April 2002. 377 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 378 Algorithms and Identifiers for RSA Cryptography for use in 379 the Internet X.509 Public Key Infrastructure Certificate 380 and Certificate Revocation List (CRL) Profile", RFC 4055, 381 June 2005. 383 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 384 "Elliptic Curve Cryptography Subject Public Key 385 Information", RFC 5480, March 2009. 387 [RFC5758] Dang, Q., Santesson, S., Moriarty, K., Brown, D., and T. 388 Polk, "Internet X.509 Public Key Infrastructure: 389 Additional Algorithms and Identifiers for DSA and ECDSA", 390 RFC 5758, January 2010. 392 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 393 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 394 June 2010. 396 [WY05] Wang, X. and H. Yu, "How to break MD5 and other hash 397 functions", Proceedings of EuroCrypt 2005, Lecture Notes 398 in Computer Science Vol. 3494, 2005. 400 [X9.62] American National Standards Institute, "Public Key 401 Cryptography for the Financial Services Industry: The 402 Elliptic Curve Digital Signature Algorithm (ECDSA)", 403 ANSI X9.62, November 2005. 405 Appendix A. Commonly used ASN.1 objects 407 This section lists commonly used ASN.1 objects in binary form. This 408 section is not-normative, and these values should only be used as 409 examples, i.e. if this and the actual specification of the algorithm 410 ASN.1 object is different the actual format specified in the actual 411 specification needs to be used. These values are taken form the New 412 ASN.1 Modules for the Public Key Infrastructure Using X.509 413 ([RFC5912]). 415 A.1. PKCS#1 1.5 RSA Encryption 417 These algorithm identifiers here include several different ASN.1 418 objects with different hash algorithms. In this document we only 419 include the commonly used ones i.e. the one using SHA-1, or SHA-2 as 420 hash function. Some of those other algorithms (MD2, MD5) specified 421 for this are not safe enough to be used as signature hash algorithm, 422 and some are omitted as there is no hash algorithm specified in the 423 our IANA registry for them. Note, that there is no parameters in any 424 of these, but all specified here needs to have NULL parameters 425 present in the ASN.1. 427 See Algorithms and Identifiers for PKIX Profile ([RFC3279]) and 428 Additional Algorithms and Identifiers for RSA Cryptography for PKIX 429 Profile ([RFC4055]) for more information. 431 A.1.1. sha1WithRSAEncryption 433 sha1WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) 434 us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 } 436 Parameters are required, and they must be NULL. 438 XXX binary object missing 440 A.1.2. sha256WithRSAEncryption 442 sha256WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 11 } 444 Parameters are required, and they must be NULL. 446 XXX binary object missing 448 A.1.3. sha384WithRSAEncryption 450 sha384WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 12 } 452 Parameters are required, and they must be NULL. 454 XXX binary object missing 456 A.1.4. sha512WithRSAEncryption 458 sha512WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 13 } 460 Parameters are required, and they must be NULL. 462 XXX binary object missing 464 A.2. DSA 466 With different DSA algorithms the parameters are always omitted. 467 Again we omit dsa-with-sha224 as there is no hash algorithm in our 468 IANA registry for it. 470 See Algorithms and Identifiers for PKIX Profile ([RFC3279]) and PKIX 471 Additional Algorithms and Identifiers for DSA and ECDSA ([RFC5758] 472 for more information. 474 A.2.1. dsa-with-sha1 476 dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 477 x9-57(10040) x9algorithm(4) 3 } 479 Parameters are absent. 481 XXX binary object missing 483 A.2.2. dsa-with-sha256 485 dsa-with-sha256 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) 486 country(16) us(840) organization(1) gov(101) csor(3) algorithms(4) 487 id-dsa-with-sha2(3) 2 } 489 Parameters are absent. 491 XXX binary object missing 493 A.3. ECDSA 495 With different ECDSA algorithms the parameters are always omitted. 496 Again we omit ecdsa-with-sha224 as there is no hash algorithm in our 497 IANA registry for it. 499 See Elliptic Curve Cryptography Subject Public Key Information 500 ([RFC5480]), Algorithms and Identifiers for PKIX Profile ([RFC3279]) 501 and PKIX Additional Algorithms and Identifiers for DSA and ECDSA 502 ([RFC5758] for more information. 504 A.3.1. ecdsa-with-sha1 506 ecdsa-with-SHA1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 507 ansi-X9-62(10045) signatures(4) 1 } 509 Parameters are absent. 511 XXX binary object missing 513 A.3.2. ecdsa-with-sha256 515 ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 516 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 2 } 518 Parameters are absent. 520 XXX binary object missing 522 A.3.3. ecdsa-with-sha384 524 ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 525 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 3 } 527 Parameters are absent. 529 XXX binary object missing 531 A.3.4. ecdsa-with-sha512 533 ecdsa-with-SHA512 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 534 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 4 } 536 Parameters are absent. 538 XXX binary object missing 540 A.4. RSASSA-PSS 542 With the RSASSA-PSS the algorithm object identifier is always id- 543 RSASSA-PSS, but the hash function is taken from the parameters, and 544 it is required. See [RFC4055] for more information. 546 A.4.1. RSASSA-PSS with empty parameters 548 id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 } 550 Parameters are empty, but the ASN.1 part of the sequence must be 551 there. This means default parameters are used (same as the next 552 example). 554 XXX binary object missing 556 A.4.2. RSASSA-PSS with default parameters 558 id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 } 560 Here the parameters are present, and contains the default parameters, 561 i.e. SHA-1, mgf1SHA1, saltlength of 20, trailerfield of 1. 563 XXX binary object missing 565 Appendix B. Examples 567 Author's Address 569 Tero Kivinen 570 INSIDE Secure 571 Eerikinkatu 28 572 HELSINKI FI-00180 573 FI 575 Email: kivinen@iki.fi