idnits 2.17.1 draft-kivinen-ipsecme-signature-auth-04.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 (December 9, 2013) is 3784 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 December 9, 2013 5 Updates: RFC 5996 (if approved) 6 Intended status: Standards Track 7 Expires: June 12, 2014 9 Signature Authentication in IKEv2 10 draft-kivinen-ipsecme-signature-auth-04.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 June 12, 2014. 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. Selecting Public Key Algorithm . . . . . . . . . . . . . . . . 7 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 64 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 65 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 66 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 68 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 69 Appendix A. Commonly used ASN.1 objects . . . . . . . . . . . . . 11 70 A.1. PKCS#1 1.5 RSA Encryption . . . . . . . . . . . . . . . . 11 71 A.1.1. sha1WithRSAEncryption . . . . . . . . . . . . . . . . 11 72 A.1.2. sha256WithRSAEncryption . . . . . . . . . . . . . . . 12 73 A.1.3. sha384WithRSAEncryption . . . . . . . . . . . . . . . 12 74 A.1.4. sha512WithRSAEncryption . . . . . . . . . . . . . . . 12 75 A.2. DSA . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 76 A.2.1. dsa-with-sha1 . . . . . . . . . . . . . . . . . . . . 12 77 A.2.2. dsa-with-sha256 . . . . . . . . . . . . . . . . . . . 13 78 A.3. ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 A.3.1. ecdsa-with-sha1 . . . . . . . . . . . . . . . . . . . 13 80 A.3.2. ecdsa-with-sha256 . . . . . . . . . . . . . . . . . . 13 81 A.3.3. ecdsa-with-sha384 . . . . . . . . . . . . . . . . . . 14 82 A.3.4. ecdsa-with-sha512 . . . . . . . . . . . . . . . . . . 14 83 A.4. RSASSA-PSS . . . . . . . . . . . . . . . . . . . . . . . . 14 84 A.4.1. RSASSA-PSS with empty parameters . . . . . . . . . . . 14 85 A.4.2. RSASSA-PSS with default parameters . . . . . . . . . . 15 86 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 15 87 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 89 1. Introduction 91 This document adds new IKEv2 ([RFC5996]) authentication method to 92 support all kinds of signature methods. The current signature based 93 authentication methods in the IKEv2 are per algorithm, i.e. there is 94 one for RSA Digital signatures, one for DSS Digital Signatures (using 95 SHA-1) and three for different ECDSA curves each tied to exactly one 96 hash algorithm. This design starts to be cumbersome when more ECDSA 97 groups are added, as each of them would require new authentication 98 method and as with ECDSA there is no way to extract the hash 99 algorithm from the signature, each ECDSA algorithm would need to come 100 with fixed hash algorithm tied to it. 102 With the SHA-3 definitions coming out, it is seen that it might be 103 possible that in the future the signature methods are used with SHA-3 104 also, not only SHA-2. This means new mechanism for negotiating the 105 hash algorithm for the signature algorithms is needed. 107 The RSA Digital Signatures format in the IKEv2 is specified to use 108 RSASSA-PKCS1-v1_5, but there has been some discussions that newer 109 padding methods should be preferred instead of PKCS #1 version 1.5 110 (See section 5 of [RFC4055]). The DSS Digital Signatures format in 111 the IKEv2 is specified to always use SHA-1, which limits the security 112 of that, meaning there is no point of using long keys with it. 114 This documents specifies two things, one is one new authentication 115 method, which includes the enough information inside the 116 Authentication payload data that the signature hash algorithm can be 117 extracted from there (see Section 3). The another thing is to add 118 indication of supported signature hash algorithms by the peer (see 119 Section 4). This allows peer to know which hash algorithms are 120 supported by the other end and use one of them (provided one is 121 allowed by policy). There is no need to actually negotiate one 122 common hash algorithm, as different hash algorithms can be used in 123 different directions if needed. 125 The new digital signature method needs to be flexible enough to 126 include all current signature methods (RSA, DSA, ECDSA, RSASSA-PSS, 127 etc), and also allow adding new things in the future (ECGDSA, ElGamal 128 etc). For this the signature algorithm is specified in the same way 129 as the PKIX ([RFC5280]) specifies the signature of the Certificate, 130 i.e. there is simple ASN.1 object before the actual signature data. 131 This ASN.1 object contains the OID specifying the algorithm, and 132 associated parameters to it. In normal case the IKEv2 133 implementations supports fixed amount of signature methods, with 134 commonly used parameters, so it is acceptable for the implementation 135 to just treat this ASN.1 object as binary blob which is compared 136 against the known values, or the implementation can parse the ASN.1 137 and extract information from there. 139 2. Terminology 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in [RFC2119]. 145 3. Authentication Payload 147 This document specifies new "Digital Signature" authentication 148 method. This method can be used with any types of signatures. As 149 the authentication methods are not negotiated in the IKEv2, the peer 150 is only allowed to use this authentication method if the 151 SIGNATURE_HASH_ALGORITHMS Notify Payload has been sent and received. 153 In this newly defined authentication method, the Authentication Data 154 field inside the Authentication Payload does not include only the 155 signature value, but instead the signature value is prefixed with the 156 ASN.1 object containing the algorithm used to generate the signature. 157 The ASN.1 object contains the algorithm identification OID, and this 158 OID identifies both the signature algorithm and the hash used when 159 calculating the signature. In addition to the OID there is optional 160 parameters which might be needed for algorithms like RSASSA-PSS. 162 To make implementations easier, the ASN.1 object is prefixed by the 163 8-bit length field. This length field allows simple implementations 164 to be able to know the length of the ASN.1 without the need to parse 165 it, so they can use it as binary blob which is compared against the 166 known signature algorithm ASN.1 objects, i.e. they do not need to be 167 able to parse or generate ASN.1 objects. See Appendix A for commonly 168 used ASN.1 objects. 170 The ASN.1 used here are the same ASN.1 which is used in the 171 AlgorithmIdentifier of the PKIX (Section 4.1.1.2 of [RFC5280]) 172 encoded using distinguished encoding rules (DER) [CCITT.X690.2002]. 173 The algorithm OID inside the ASN.1 specifies the signature algorithm 174 and the hash function, which are needed for signature verification. 175 The EC curve is always known by the peer because it needs to have the 176 certificate or the public key of the other end before it can do 177 signature verification and public key specifies the curve. 179 Currently only the RSASSA-PSS uses the parameters, for all others the 180 parameters is either NULL or missing. Note, that for some algorithms 181 there is two possible ASN.1 encoding possible, one with parameters 182 being NULL and others where the whole parameters is omitted. This is 183 because some of those algorithms are specified that way. When 184 encoding the ASN.1 implementations should use the preferred way, i.e. 185 if the algorithm specification says "preferredPresent" then parameter 186 object needs to be there (i.e. it will be NULL if no parameters is 187 specified), and if it says "preferredAbsent", then the whole 188 parameters object is missing. 190 The Authentication payload is defined in IKEv2 as follows: 192 1 2 3 193 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 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | Next Payload |C| RESERVED | Payload Length | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | Auth Method | RESERVED | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | | 200 ~ Authentication Data ~ 201 | | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 Figure 1: Authentication Payload Format. 206 o Auth Method (1 octet) - Specifies the method of authentication 207 used. 209 Mechanism Value 210 ----------------------------------------------------------------- 211 Digital Signature 212 Computed as specified in Section 2.15 of RFC5996 using a 213 private key associated with the public key sent in certificate 214 payload, and using one of the hash algorithms sent by the other 215 end in the SIGNATURE_HASH_ALGORITHMS notify payload. If both 216 ends send and receive SIGNATURE_HASH_ALGORITHMS and signature 217 authentication is to be used, then this method MUST be used. 218 The Authentication Data field has bit different format than in 219 other Authentication methods (see below). 221 o Authentication Data (variable length) - see Section 2.15 of 222 RFC5996. For "Digital Signature" format the Authentication data 223 contains special format as follows: 225 1 2 3 226 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 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | ASN.1 Length | AlgorithmIdentifier ASN.1 object | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | | 231 ~ AlgorithmIdentifier ASN.1 object continuing ~ 232 | | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | | 235 ~ Signature Value ~ 236 | | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 Figure 2: Authentication Data Format. 241 Where the ASN.1 Length is the length of the ASN.1 encoded 242 AlgorithmIdentifier object, and after that is the actual 243 AlgorithmIdentifier ASN.1 object, followed by the actual signature 244 value. There is no padding between ASN.1 object and signature 245 value. For the hash truncation the method of X9.62 ([X9.62]) MUST 246 be used. 248 4. Hash Algorithm Notification 250 The supported hash algorithms that can be used for the signature 251 algorithms are now indicated with new SIGNATURE_HASH_ALGORITHMS 252 Notification Payload sent inside the IKE_SA_INIT exchange. This 253 notification also indicates the support of the new signature 254 algorithm method, i.e. sending this notification tells that new 255 "Digital Signature" authentication method is supported and that 256 following hash functions are supported by sending peer. Both ends 257 sends their list of supported hash-algorithms and when calculating 258 signature a peer MUST pick one algorithm sent by the other peer. 259 Note, that different algorithms can be used in different directions. 260 The algorithm OID matching selected hash algorithm (and signature 261 algorithm) used when calculating the signature is sent inside the 262 Authentication Data field of the Authentication Payload. 264 1 2 3 265 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 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Next Payload |C| RESERVED | Payload Length | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | Protocol ID | SPI Size | Notify Message Type | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | | 272 ~ Security Parameter Index (SPI) ~ 273 | | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | | 276 ~ Notification Data ~ 277 | | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 Figure 3: Notify Payload Format. 282 Protocol ID is 0, SPI Size 0, and Notify Message Type . The Notification Data value contains list of 16-bit 284 hash algorithm identifiers from the newly created Hash Algorithm 285 Identifiers for the IKEv2 IANA registry. 287 5. Selecting Public Key Algorithm 289 This specification does not provide a way for the peers to indicate 290 the public / private key pair types they have. I.e. how can the 291 responder select public / private key pair type that the initiator 292 supports. There is already several ways this information can be 293 found in common cases. 295 One of the ways to find out which key the initiator wants the 296 responder to use is to indicate that in the IDr payload of the 297 IKE_AUTH request of the initiator. I.e initiator indicates that it 298 wants the responder to use certain public / private key pair by 299 sending IDr which indicates that information. This means the 300 responder needs to have different identities configured and each of 301 those identities needs to be tied up to certain public / private key 302 (or key type). 304 Another way to get this information is from the Certificate Request 305 payload sent by the initiator. For example if the initiator 306 indicates in his Certificate Request payload that it trust CA which 307 is signed by the ECDSA key, that will also indicate it can be process 308 ECDSA signatures, thus responder can safely use ECDSA keys when 309 authenticating himself. 311 Responder can also check the key type used by the initiator, and use 312 same key type than the initiator used. This does not work in case 313 the initiator is using shared secret or EAP authentication, as in 314 that case it is not using public key. If initiator is using public 315 key authentication himself this is most likely the best way for the 316 responder to find the type the initiator supports. 318 In case the initiator uses a public key type that the responder will 319 not support, the responder will reply with AUTHENTICATION_FAILED 320 error. If initiator has multiple different keys it can try different 321 key (and perhaps different key type) until it finds key that the 322 other end accepts. Initiator can also use the Certificate Request 323 payload sent by the responder to help deciding which public key 324 should be tried. In normal case if initiator has multiple public 325 keys, there is configuration that will select one of those for each 326 connection, so the proper key is know by configuration. 328 6. Security Considerations 330 The "Recommendations for Key Management" ([NIST800-57]) table 2 331 combined with table 3 gives recommendations for how to select 332 suitable hash functions for the signature. 334 This new digital signature method does not tie the EC curve to the 335 specific hash function, which was done in the old IKEv2 ECDSA 336 methods. This means it is possible to use 512-bit EC curve with 337 SHA1, i.e. this allows mixing different security levels. This means 338 that the security of the authentication method is the security of the 339 weakest of components (signature algorithm, hash algorithm, curve). 340 This might make the security analysis of the system bit more complex. 341 Note, that this kind of mixing of the security can be disallowed by 342 the policy. 344 The hash algorithm registry does not include MD5 as supported hash 345 algorithm, as it is not considered safe enough for signature use 346 ([WY05]). 348 The current IKEv2 uses RSASSA-PKCS1-v1_5, which do have some problems 349 ([KA08], [ME01]) and does not allow using newer padding methods like 350 RSASSA-PSS. This new method allows using other padding methods. 352 The current IKEv2 only allows using normal DSA with SHA-1, which 353 means the security of the regular DSA is limited to the security of 354 SHA-1. This new methods allows using longer keys and longer hashes 355 with DSA. 357 7. IANA Considerations 359 This document creates new IANA registry for IKEv2 Hash Algorithms. 360 Changes and additions to this registry is by expert review. 362 The initial values of this registry is: 364 Hash Algorithm Value 365 -------------- ----- 366 RESERVED 0 367 SHA1 1 368 SHA2-256 2 369 SHA2-384 3 370 SHA2-512 4 372 MD5 is not included to the hash algorithm list as it is not 373 considered safe enough for signature hash uses. 375 Values 5-1023 are reserved to IANA. Values 1024-65535 are for 376 private use among mutually consenting parties. 378 This specification also allocates one new IKEv2 Notify Message Types 379 - Status Types value for the SIGNATURE_HASH_ALGORITHMS, and adds new 380 value "Digital Signature" to the IKEv2 Authentication Method 381 registry. 383 8. Acknowledgements 385 Most of this work was based on the work done in the IPsecME design 386 team for the ECDSA. The design team members were: Dan Harking, 387 Johannes Merkle, Tero Kivinen, David McGrew, and Yoav Nir. 389 9. References 391 9.1. Normative References 393 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 394 Requirement Levels", BCP 14, RFC 2119, March 1997. 396 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 397 Housley, R., and W. Polk, "Internet X.509 Public Key 398 Infrastructure Certificate and Certificate Revocation List 399 (CRL) Profile", RFC 5280, May 2008. 401 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 402 "Internet Key Exchange Protocol Version 2 (IKEv2)", 403 RFC 5996, September 2010. 405 9.2. Informative References 407 [CCITT.X690.2002] 408 International Telephone and Telegraph Consultative 409 Committee, "ASN.1 encoding rules: Specification of basic 410 encoding Rules (BER), Canonical encoding rules (CER) and 411 Distinguished encoding rules (DER)", CCITT Recommendation 412 X.690, July 2002. 414 [KA08] Kuehn, U., Pyshkin, A., Tews, E., and R. Weinmann, 415 "Variants of Bleichenbacher's Low-Exponent Attack on 416 PKCS#1 RSA Signatures", Proc. Sicherheit 2008 pp.97-109. 418 [ME01] Menezes, A., "Evaluation of Security Level of 419 Cryptography: RSA-OAEP, RSA-PSS, RSA Signature", 420 December 2001. 422 [NIST800-57] 423 Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid, 424 "Recommendations for Key Management", NIST SP 800-57, 425 March 2007. 427 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 428 Identifiers for the Internet X.509 Public Key 429 Infrastructure Certificate and Certificate Revocation List 430 (CRL) Profile", RFC 3279, April 2002. 432 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 433 Algorithms and Identifiers for RSA Cryptography for use in 434 the Internet X.509 Public Key Infrastructure Certificate 435 and Certificate Revocation List (CRL) Profile", RFC 4055, 436 June 2005. 438 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 439 "Elliptic Curve Cryptography Subject Public Key 440 Information", RFC 5480, March 2009. 442 [RFC5758] Dang, Q., Santesson, S., Moriarty, K., Brown, D., and T. 443 Polk, "Internet X.509 Public Key Infrastructure: 444 Additional Algorithms and Identifiers for DSA and ECDSA", 445 RFC 5758, January 2010. 447 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 448 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 449 June 2010. 451 [WY05] Wang, X. and H. Yu, "How to break MD5 and other hash 452 functions", Proceedings of EuroCrypt 2005, Lecture Notes 453 in Computer Science Vol. 3494, 2005. 455 [X9.62] American National Standards Institute, "Public Key 456 Cryptography for the Financial Services Industry: The 457 Elliptic Curve Digital Signature Algorithm (ECDSA)", 458 ANSI X9.62, November 2005. 460 Appendix A. Commonly used ASN.1 objects 462 This section lists commonly used ASN.1 objects in binary form. This 463 section is not-normative, and these values should only be used as 464 examples, i.e. if this and the actual specification of the algorithm 465 ASN.1 object is different the actual format specified in the actual 466 specification needs to be used. These values are taken from the New 467 ASN.1 Modules for the Public Key Infrastructure Using X.509 468 ([RFC5912]). 470 A.1. PKCS#1 1.5 RSA Encryption 472 These algorithm identifiers here include several different ASN.1 473 objects with different hash algorithms. In this document we only 474 include the commonly used ones i.e. the one using SHA-1, or SHA-2 as 475 hash function. Some of those other algorithms (MD2, MD5) specified 476 for this are not safe enough to be used as signature hash algorithm, 477 and some are omitted as there is no hash algorithm specified in the 478 our IANA registry for them. Note, that there is no parameters in any 479 of these, but all specified here needs to have NULL parameters 480 present in the ASN.1. 482 See Algorithms and Identifiers for PKIX Profile ([RFC3279]) and 483 Additional Algorithms and Identifiers for RSA Cryptography for PKIX 484 Profile ([RFC4055]) for more information. 486 A.1.1. sha1WithRSAEncryption 488 sha1WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) 489 us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 } 491 Parameters are required, and they must be NULL. 493 Name = sha1WithRSAEncryption, oid = 1.2.840.113549.1.1.5 494 Length = 17 495 0000: 300f 300d 0609 2a86 4886 f70d 0101 0505 496 0010: 00 498 A.1.2. sha256WithRSAEncryption 500 sha256WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 11 } 502 Parameters are required, and they must be NULL. 504 Name = sha256WithRSAEncryption, oid = 1.2.840.113549.1.1.11 505 Length = 17 506 0000: 300f 300d 0609 2a86 4886 f70d 0101 0b05 507 0010: 00 509 A.1.3. sha384WithRSAEncryption 511 sha384WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 12 } 513 Parameters are required, and they must be NULL. 515 Name = sha384WithRSAEncryption, oid = 1.2.840.113549.1.1.12 516 Length = 17 517 0000: 300f 300d 0609 2a86 4886 f70d 0101 0c05 518 0010: 00 520 A.1.4. sha512WithRSAEncryption 522 sha512WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 13 } 524 Parameters are required, and they must be NULL. 526 Name = sha512WithRSAEncryption, oid = 1.2.840.113549.1.1.13 527 Length = 17 528 0000: 300f 300d 0609 2a86 4886 f70d 0101 0d05 529 0010: 00 531 A.2. DSA 533 With different DSA algorithms the parameters are always omitted. 534 Again we omit dsa-with-sha224 as there is no hash algorithm in our 535 IANA registry for it. 537 See Algorithms and Identifiers for PKIX Profile ([RFC3279]) and PKIX 538 Additional Algorithms and Identifiers for DSA and ECDSA ([RFC5758] 539 for more information. 541 A.2.1. dsa-with-sha1 543 dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 544 x9-57(10040) x9algorithm(4) 3 } 545 Parameters are absent. 547 Name = dsa-with-sha1, oid = 1.2.840.10040.4.3 548 Length = 13 549 0000: 300b 3009 0607 2a86 48ce 3804 03 551 A.2.2. dsa-with-sha256 553 dsa-with-sha256 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) 554 country(16) us(840) organization(1) gov(101) csor(3) algorithms(4) 555 id-dsa-with-sha2(3) 2 } 557 Parameters are absent. 559 Name = dsa-with-sha256, oid = 2.16.840.1.101.3.4.3.2 560 Length = 15 561 0000: 300d 300b 0609 6086 4801 6503 0403 02 563 A.3. ECDSA 565 With different ECDSA algorithms the parameters are always omitted. 566 Again we omit ecdsa-with-sha224 as there is no hash algorithm in our 567 IANA registry for it. 569 See Elliptic Curve Cryptography Subject Public Key Information 570 ([RFC5480]), Algorithms and Identifiers for PKIX Profile ([RFC3279]) 571 and PKIX Additional Algorithms and Identifiers for DSA and ECDSA 572 ([RFC5758] for more information. 574 A.3.1. ecdsa-with-sha1 576 ecdsa-with-SHA1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 577 ansi-X9-62(10045) signatures(4) 1 } 579 Parameters are absent. 581 Name = ecdsa-with-sha1, oid = 1.2.840.10045.4.1 582 Length = 13 583 0000: 300b 3009 0607 2a86 48ce 3d04 01 585 A.3.2. ecdsa-with-sha256 587 ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 588 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 2 } 590 Parameters are absent. 592 Name = ecdsa-with-sha256, oid = 1.2.840.10045.4.3.2 593 Length = 14 594 0000: 300c 300a 0608 2a86 48ce 3d04 0302 596 A.3.3. ecdsa-with-sha384 598 ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 599 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 3 } 601 Parameters are absent. 603 Name = ecdsa-with-sha384, oid = 1.2.840.10045.4.3.3 604 Length = 14 605 0000: 300c 300a 0608 2a86 48ce 3d04 0303 607 A.3.4. ecdsa-with-sha512 609 ecdsa-with-SHA512 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 610 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 4 } 612 Parameters are absent. 614 Name = ecdsa-with-sha512, oid = 1.2.840.10045.4.3.4 615 Length = 14 616 0000: 300c 300a 0608 2a86 48ce 3d04 0304 618 A.4. RSASSA-PSS 620 With the RSASSA-PSS the algorithm object identifier is always id- 621 RSASSA-PSS, but the hash function is taken from the parameters, and 622 it is required. See [RFC4055] for more information. 624 A.4.1. RSASSA-PSS with empty parameters 626 id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 } 628 Parameters are empty, but the ASN.1 part of the sequence must be 629 there. This means default parameters are used (same as the next 630 example). 632 Name = RSASSA-PSS with empty parameters, oid = 1.2.840.113549.1.1.10 633 Length = 17 634 0000: 300f 300d 0609 2a86 4886 f70d 0101 0a30 635 0010: 00 637 A.4.2. RSASSA-PSS with default parameters 639 id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 } 641 Here the parameters are present, and contains the default parameters, 642 i.e. SHA-1, mgf1SHA1, saltlength of 20, trailerfield of 1. 644 0000 : SEQUENCE 645 0002 : SEQUENCE 646 0004 : OBJECT IDENTIFIER RSASSA-PSS (1.2.840.113549.1.1.10) 647 000f : SEQUENCE 648 0011 : CONTEXT 0 649 0013 : OBJECT IDENTIFIER Sha-1 (1.3.14.3.2.26) 650 001a : NULL 651 001c : CONTEXT 1 652 001e : OBJECT IDENTIFIER id-mgf1 ( 1.2.840.113549.1.1.8) 653 0029 : SEQUENCE 654 002b : OBJECT IDENTIFIER Sha-1 (1.3.14.3.2.26) 655 0032 : NULL 656 0034 : CONTEXT 2 (1 bytes) 657 0036 : INTEGER 20 (0x14) 658 0037 : CONTEXT 3 (1 bytes) 659 0039 : INTEGER 01 (0x01) 661 Name = RSASSA-PSS with default parameters, 662 oid = 1.2.840.113549.1.1.10 663 Length = 58 664 0000: 3038 3036 0609 2a86 4886 f70d 0101 0a30 665 0010: 29a0 0906 052b 0e03 021a 0500 a116 0609 666 0020: 2a86 4886 f70d 0101 0830 0906 052b 0e03 667 0030: 021a 0500 8201 1483 0101 669 Appendix B. Examples 671 XXX Examples missing 673 XXX Most likely include examples for sha1WithRSAEncryption and dsa- 674 with-sha256 or something like that. I do not think we need all 675 possible signature examples. 677 Author's Address 679 Tero Kivinen 680 INSIDE Secure 681 Eerikinkatu 28 682 HELSINKI FI-00180 683 FI 685 Email: kivinen@iki.fi