idnits 2.17.1 draft-ietf-pkix-pubkey-caps-07.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 142 has weird spacing: '... &id contai...' == Line 148 has weird spacing: '... &Type optio...' == Line 213 has weird spacing: '...-pk-rsa is a ...' == Line 218 has weird spacing: '...ilities carri...' == Line 221 has weird spacing: '...KeySize conta...' == (16 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (May 15, 2012) is 4326 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 836 -- Looks like a reference, but probably isn't: '1' on line 843 -- Looks like a reference, but probably isn't: '2' on line 840 -- Looks like a reference, but probably isn't: '3' on line 841 -- Obsolete informational reference (is this intentional?): RFC 6277 (Obsoleted by RFC 6960) -- Obsolete informational reference (is this intentional?): RFC 5751 (ref. 'SMIME-MSG') (Obsoleted by RFC 8551) -- Obsolete informational reference (is this intentional?): RFC 2633 (ref. 'SMIMEv3-MSG') (Obsoleted by RFC 3851) Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Schaad 3 Internet-Draft Soaring Hawk Consulting 4 Intended status: Informational May 15, 2012 5 Expires: November 16, 2012 7 S/MIME Capabilities for Public Key Definitions 8 draft-ietf-pkix-pubkey-caps-07 10 Abstract 12 This document defines a set of Secure/Multipurpose Internet Mail 13 Extensions (S/MIME) Capability types for ASN.1 encoding for the 14 current set of public keys defined by the PKIX working group. This 15 facilitates the ability for a requester to specify information on the 16 public keys and signature algorithms to be used in responses. An 17 example of where this is used is is detailed in Online Certificate 18 Status Protocol Algorithm Agility (RFC 6277). 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on November 16, 2012. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. ASN.1 Notation . . . . . . . . . . . . . . . . . . . . . . 3 56 1.2. Requirements Terminology . . . . . . . . . . . . . . . . . 4 57 2. RSA Public Keys . . . . . . . . . . . . . . . . . . . . . . . 5 58 2.1. Generic RSA Public Keys . . . . . . . . . . . . . . . . . 5 59 2.2. RSASSA-PSS Signature Public Keys . . . . . . . . . . . . . 6 60 2.3. RSAES-OAEP Key Transport Public Keys . . . . . . . . . . . 6 61 3. Diffie-Hellman Keys . . . . . . . . . . . . . . . . . . . . . 8 62 3.1. DSA Signature Public Key . . . . . . . . . . . . . . . . . 8 63 3.2. DH Key Agreement Keys . . . . . . . . . . . . . . . . . . 9 64 4. Elliptical Curve Keys . . . . . . . . . . . . . . . . . . . . 10 65 4.1. Generic Elliptical Curve Keys . . . . . . . . . . . . . . 10 66 4.2. Elliptical Curve DH Keys . . . . . . . . . . . . . . . . . 11 67 4.3. Elliptical Curve MQV Keys . . . . . . . . . . . . . . . . 11 68 5. RSASSA-PSS Signature Algorithm Capability . . . . . . . . . . 12 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 72 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 73 8.2. Informative References . . . . . . . . . . . . . . . . . . 17 74 Appendix A. 2008 ASN.1 Module . . . . . . . . . . . . . . . . . . 18 75 Appendix B. 1988 ASN.1 Module . . . . . . . . . . . . . . . . . . 22 76 Appendix C. Future Work . . . . . . . . . . . . . . . . . . . . . 24 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25 79 1. Introduction 81 In the process of dealing with the Online Certificate Status Protocol 82 (OCSP) agility issues in [RFC6277] it was noted that we really wanted 83 to describe information to be used in selecting a public key, but we 84 did not have any way of doing so. This document fills that hole by 85 defining a set of Secure/Multipurpose Internet Mail Extensions 86 (S/MIME) Capability types for a small set of public key 87 representations. 89 S/MIME Capabilities where originally defined in [SMIMEv3-MSG] as a 90 way for the sender of an S/MIME message to tell the recipient of the 91 message the set of encryption algorithms that were supported by the 92 sender's system. In the beginning, the focus was primarily on 93 communicating the set of encryption algorithms that were supported by 94 the sender. Over time it was expanded to allow for an S/MIME client 95 to state that it supported new features such as the compression data 96 type and binary encoded contents. The structure was defined so that 97 parameters can be passed in as part of the capability to allow for 98 subsets of algorithms to be used. This was used for the RC2 99 encryption algorithm, although only two values out of the set of 100 values were ever used. The object of restricting the set of values 101 is that a client can use a simple binary comparison in order to check 102 for equality. The client should never need to decode the capability 103 and do an element by element comparison. Historically this has been 104 not been a problem as the vast majority of S/MIME capabilities 105 consist of just the algorithm identifier for the algorithm. 107 Many people are under the impression that only a single data 108 structure can be assigned to an object identifer, this is not the 109 case. As an example the OID rsaEncryption is used in multiple 110 locations for different data. It represents a public key, a key 111 transport algoritm (in S/MIME), and was originally used in the PKCS#7 112 specfication as a signature value identifier (this has since been 113 changed by the S/MIME specifications). One of the implications is 114 that when mapping an object identifier to a data type structure, the 115 location in the ASN.1 structure needs to be taken into consideration 116 as well. 118 1.1. ASN.1 Notation 120 The main body of the text is written using snippets of ASN.1 that are 121 extracted from the ASN.1 2008 module in Appendix A. ASN.1 2008 is 122 used in the document because it directly represents the meta-data 123 which is not representable in the 1988 version of ASN.1 but instead 124 is part of the text. In keeping with the current policy of the PKIX 125 working group, the 1988 module and the text is the normative module. 126 In the event of a conflict between the contents of the two modules, 127 the 1988 module is authoritative. 129 When reading this document, it is assumed that you will have a degree 130 of familiarity with the basic object module that is presented in 131 section 3 of RFC 5912 ([RFC5912]). We use the SMIME-CAPS object in 132 this document, it associates two fields together in a single object. 134 SMIME-CAPS ::= CLASS { 135 &id OBJECT IDENTIFIER UNIQUE, 136 &Type OPTIONAL 137 } 138 WITH SYNTAX { [TYPE &Type] IDENTIFIED BY &id } 140 These fields are: 142 &id contains an object identifier. When placed in an object set, 143 this element is tagged so that no two elements can be placed in 144 the set that have the same value in the &id field. Note that this 145 is not a restriction which says that only a single object can 146 exist with a single object identifier. 148 &Type optionally contains an ASN.1 type identifier. If the field 149 &Type is not defined then the optional parameters field of the 150 AlgorithmIdentifier type would be omitted. 152 The class also has a specialized syntax for how to define an object 153 in this class. The all upper case words TYPE IDENTIFIER and BY are 154 syntactic sugar to make it easier to read. The square brackets 155 define optional pieces of the syntax. 157 One of the things that can be done is to reference the fields of an 158 object while defining other objects. This means that if an object 159 called foo has a field named &value, the value can be directly 160 referenced as foo.&value. This means that we automatically get any 161 updates to values or types and we do not need to do any replication 162 of the data. 164 1.2. Requirements Terminology 166 When capitalized the key words "MUST", "MUST NOT", "REQUIRED", 167 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 168 and "OPTIONAL" in this document are to be interpreted as described in 169 [RFC2119]. 171 2. RSA Public Keys 173 There are currently three different public key object identifiers for 174 RSA public keys. These are RSA, RSA Encryption Scheme - Optimal 175 Asymmetric Encryption Padding (RSAES-OAEP) and RSA Signature Scheme 176 with Appendix - Probablistic Signature Scheme (RSASSA-PSS). 178 2.1. Generic RSA Public Keys 180 Almost all RSA keys that are contained in certificates today use the 181 generic RSA public key format and identifier. This allows for the 182 public key to be used both for key transport and for signature 183 validation (assuming it is compatible with the bits in the key usage 184 extension). The only reason for using one of more specific public 185 key identifiers is if the user wants to restrict the usage of the RSA 186 public key to a specific algorithm. 188 For the generic RSA public key, the S/MIME capability that is 189 advertised is a request for a specific key size to be used. This 190 would normally be used for dealing with a request on the key to be 191 used for a signature that the client would then verify. In general 192 the user would provide a specific key when a key transport algorithm 193 is being considered. 195 The ASN.1 that is used for the generic RSA public key is defined as 196 below: 198 scap-pk-rsa SMIME-CAPS ::= { 199 TYPE RSAKeyCapabilities 200 IDENTIFIED BY pk-rsa.&id 201 } 203 RSAKeyCapabilities ::= SEQUENCE { 204 minKeySize RSAKeySize, 205 maxKeySize RSAKeySize OPTIONAL 206 } 208 RSAKeySize ::= INTEGER (1024 | 2048 | 3072 | 4096 | 7680 | 209 8192 | 15360, ...) 211 In the above ASN.1 we have defined the following: 213 scap-pk-rsa is a new SMIME-CAP object. This object associates the 214 existing object identifier (rsaEncryption) used for the public key 215 in certificates (defined in [RFC3279] and [RFC5912]) with a new 216 type defined in this document. 218 RSAKeyCapabilities carries the set of desired capabilities for an 219 RSA key. The fields of this type are: 221 minKeySize contains the minimum length of the RSA modulus to be 222 used. This field SHOULD NOT contain a value less than 1024. 224 maxKeySize contains the maximum length of the RSA modules that 225 should be used. If this field is absent then no maximum length 226 is requested/expected. This value is normally selected so as 227 not to cause the current code to run unacceptably long when 228 processing signatures. 230 RSAKeySize provides a set of suggested values to be used. The 231 values 1024, 2048, 3072, 7680 and 15360 are from the NIST guide on 232 signature sizes [NIST-SIZES] while the others are common powers of 233 two that are used. The list is not closed and other values can be 234 used. 236 2.2. RSASSA-PSS Signature Public Keys 238 While most of the time one will use the generic RSA public key 239 identifier in a certificate, the RSASSA-PSS identifier can be used if 240 the owner of the key desires to restrict the usage of the key to just 241 this algorithm. This algorithm does have the ability to place a set 242 of algorithm parameters in the public key info structure, they have 243 not been included in this location as the same information should be 244 carried in the signature S/MIME capabilities instead. 246 The ASN.1 that is used for the RSASSA-PSS public key is defined 247 below: 249 scap-pk-rsaSSA-PSS SMIME-CAPS ::= { 250 TYPE RSAKeyCapabilities 251 IDENTIFIED BY pk-rsaSSA-PSS.&id 252 } 254 In the above ASN.1 we have defined the following: 256 scap-pk-rsaSSA-PSS is a new SMIME-CAP object. This object 257 associates the existing object identifier (id-RSASSA-PSS) used for 258 the public key certificates (defined in [RFC4055] and [RFC5912]) 259 with type RSAKeyCapabilities. 261 2.3. RSAES-OAEP Key Transport Public Keys 263 While most of the time one will use the generic RSA public key 264 identifier in a certificate, the RSAES-OAEP identifier can be used if 265 the owner of the key desires to restrict the usage of the key to just 266 this algorithm. This algorithm does have the ability to place a set 267 of algorithm parameters in the public key info structure, they have 268 not been included in this location as the same information should be 269 carried in the key transport S/MIME capabilities instead. 271 The ASN.1 that is used for the RSAES-OAEP public key is defined 272 below: 274 scap-pk-rsaES-OAEP SMIME-CAPS ::= { 275 TYPE RSAKeyCapabilities 276 IDENTIFIED BY pk-rsaES-OAEP.&id 277 } 279 In the above ASN.1 we have defined the following: 281 scap-pk-rsaES-OAEP is a new SMIME-CAP object. This object 282 associates the existing object identifier (id-RSAES-OAEP) used for 283 the public key certificates (defined in [RFC4055] and [RFC5912]) 284 with type RSAKeyCapabilities. 286 3. Diffie-Hellman Keys 288 There are currently two Diffie-Hellman (DH) public key object 289 identifiers. These are DH key agreement and Digital Signature 290 Standard (DSA). 292 3.1. DSA Signature Public Key 294 This public key type is used for the validation of DSA signatures. 296 The ASN.1 that is used for DSA keys is defined below: 298 scap-pk-dsa SMIME-CAPS ::= { 299 TYPE DSAKeyCapabilities 300 IDENTIFIED BY pk-dsa.&id 301 } 303 DSAKeyCapabilities ::= CHOICE { 304 keySizes [0] SEQUENCE { 305 minKeySize DSAKeySize, 306 maxKeySize DSAKeySize OPTIONAL, 307 maxSizeP [1] INTEGER OPTIONAL, 308 maxSizeQ [2] INTEGER OPTIONAL, 309 maxSizeG [3] INTEGER OPTIONAL 310 }, 311 keyParams [1] pk-dsa.&Params 312 } 314 DSAKeySize ::= INTEGER (1024 | 2048 | 3072 | 7680 | 15360 ) 316 In the above ASN.1 we have defined the following: 318 scap-pk-dsa is a new SMIME-CAP object. This object associates the 319 existing object identifier (id-dsa) used for the public key in 320 certificates (defined in [RFC3279] and [RFC5912]) with a new type 321 defined here, DSAKeyCapabilities. 323 DSAKeyCapabilities carries the desired set of capabilities for the 324 DSA key. The fields of this type are: 326 keySizes is used when only a key size is needed to be specified 327 and not a specific group. It is expected that this would be 328 the most commonly used of the two options. In key sizes the 329 fields are used as follows: 331 minKeySize contains the minimum length of the DSA modulus to 332 be used. 334 maxKeySize contains the maximum length of the DSA modules that 335 should be used. If this field is absent then no maximum 336 length is requested/expected. 338 maxSizeP contains the maximum length of the value p that 339 should be used. If this field is absent then no maximum 340 length is imposed. 342 maxSizeQ contains the maximum length of the value q that 343 should be used. If this field is absent then no maximum 344 length is imposed. 346 maxSizeG contains the maximum lenght of the value g that 347 should be used. If this field is absent then no maximum 348 length is imposed. 350 keyParams contains the exact set of DSA for the key used to sign 351 the message. This field is provided for completeness and to 352 match the fields for Elliptical Curve, however it is expected 353 that usage of this field is extremely rare. 355 3.2. DH Key Agreement Keys 357 This public key type is used with the DH key agreement algorithm. 359 The ASN.1 that is used for DH keys is defined below: 361 scap-pk-dh SMIME-CAPS ::= { 362 TYPE DSAKeyCapabilities 363 IDENTIFIED BY pk-dh.&id 364 } 366 In the above ASN.1 we have defined the following: 368 scap-pk-dh is a new SMIME-CAP object. This object associates the 369 existing object identifier (id-dh) used for the public key 370 algorithm in the certificates (defined in [RFC3279] and [RFC5912]) 371 with a new type defined above, DSAKeyCapabilities. 373 4. Elliptical Curve Keys 375 There are currently three Elliptical Curve Cryptography (ECC) public 376 key object identifiers. These are EC, EC-DH and Elliptical Curve 377 Menezes-Qu-Vanstone (EC-MQV). 379 4.1. Generic Elliptical Curve Keys 381 Almost all ECC keys that are contained in certificates today use the 382 generic ECC public key format and identifier. This allows for the 383 public key to be used both for key agreement and for signature 384 validation (assuming the appropriate bits are in the certificate). 385 The only reason for using one of the more specific public key 386 identifier is if the user wants to restrict the usage of the ECC 387 public key to a specific algorithm. 389 For the generic ECC public key, the S/MIME capability that is 390 advertised is a request for a specific group to be used. 392 The ASN.1 that is used for the generic ECC public key is defined as 393 below: 395 scap-pk-ec SMIME-CAPS ::= { 396 TYPE EC-SMimeCaps 397 IDENTIFIED BY pk-ec.&id 398 } 400 EC-SMimeCaps ::= SEQUENCE (SIZE (1..MAX)) OF ECParameters 402 In the above ASN.1 we have defined the following: 404 scap-pk-ec is a new SMIME-CAP object. This object associates the 405 existing object identifier (id-ecPublicKey) used for the public 406 key algorithm in the certificates (defined in [RFC5480] and 407 [RFC5912]) with the new type EC-SMimeCaps. 409 EC-SMimeCaps carries a sequence of at least one ECParameters 410 structure. This allows for multiple curves to be requested in a 411 single capability request. A maximum/minimum style of specifying 412 sizes is not provided as much greater care is required in 413 selecting a specific curve than is needed to create the parameters 414 for a DSA/DH key. As specified in [RFC5480], for PKIX compliant 415 certificates only the namedCurve choice of ECParameters can 416 expected to be used. 418 4.2. Elliptical Curve DH Keys 420 This public key type is used with the Elliptical Curve Diffie-Hellman 421 key agreement algorithm. 423 The ASN.1 that is used for EC-DH keys is defined below: 425 scap-pk-ecDH SMIME-CAPS ::= { 426 TYPE EC-SMimeCaps 427 IDENTIFIED BY pk-ecDH.&id 428 } 430 In the above ASN.1 we have defined the following: 432 scap-ec-dh is a new SMIME-CAP object. This object associates the 433 existing object identifier (id-ecDH) used for the public key 434 algorithm in the certificate (defined in [RFC5480] and [RFC5912]) 435 with the same type structure used for public keys. 437 4.3. Elliptical Curve MQV Keys 439 This public key type is used with the Elliptical Curve MQV key 440 agreement algorithm. 442 The ASN.1 that is used for EC-MQV keys is defined below: 444 scap-pk-ecMQV SMIME-CAPS ::= { 445 TYPE EC-SMimeCaps 446 IDENTIFIED BY pk-ecMQV.&id 447 } 449 In the above ASN.1 we have defined the following: 451 scap-ec-MQV is a new SMIME-CAP object. This object associates the 452 existing object identifier (id-eqMQV) used for the public key 453 algorithm in the certificate (defined in [RFC5480] and [RFC5912]) 454 with the same type structure used for public keys. 456 5. RSASSA-PSS Signature Algorithm Capability 458 This document defines a new S/MIME Capability for the RSASSA-PSS 459 signature algorithm. There already exists one in [RFC4055] where the 460 parameters field is not used. 462 When the S/MIME group defined a S/MIME Capability for the RSASSA-PSS 463 signature algorithm, it was done in the context of how S/MIME defines 464 and uses S/MIME Capabilities. When placed in an S/MIME message 465 [SMIME-MSG] or in a certificate [RFC4262] it is always placed in a 466 sequence of capabilities. This means that one could place the 467 identifier for RSASSA-PSS in the sequence along with the identifier 468 for MD5, SHA-1 and SHA-256. The assumption was then made that one 469 could compute the matrix of all answers and the publisher would 470 support all elements in the matrix. This has the possibility that 471 the publisher could accidently publish a point in the matrix that is 472 not supported. 474 In this situation, there is only a single item that is published. 475 This means that we need to publish all of the associated information 476 along with the identifier for the signature algorithm in a single 477 entity. For this reason we now define a new parameter type to be 478 used as the S/MIME capability type which contains a hash identifier 479 and a mask identifier. The ASN.1 used for this is as follows: 481 scap-sa-rsaSSA-PSS SMIME-CAPS ::= { 482 TYPE RsaSsa-Pss-sig-caps 483 IDENTIFIED BY sa-rsaSSA-PSS.&id 484 } 486 RsaSsa-Pss-sig-caps ::= SEQUENCE { 487 hashAlg SMIMECapability{{ MaskAlgorithmSet }}, 488 maskAlg SMIMECapability{{ ... }} OPTIONAL, 489 trailerField INTEGER DEFAULT 1 490 } 492 scap-mf-mgf1 SMIME-CAPS ::= { 493 TYPE SMIMECapability{{ ... }} 494 IDENTIFIED BY id-mgf1 495 } 497 MaskAlgorithmSet SMIME-CAPS ::= {scap-mf-mgf1, ...} 499 In the above ASN.1 we have defined the following: 501 scap-sa-rsaSSA-PSS is a new SMIME-CAP object. This object 502 associates the existing object identifier (id-RSASSA-PSS) used for 503 the signature algorithm (defined in [RFC4055] and [RFC5912]) with 504 the new type RsaSsa-Pss-sig-caps. 506 RsaSsa-Pss-sig-caps carries the desired set of capabilities for the 507 RSASSA-PSS signature algorithm. The fields of this type are: 509 hashAlg contains the S/MIME capability for the hash algorithm we 510 are declaring we support with the RSASSA-PSS signature 511 algorithm. 513 maskAlg contains the S/MIME capability for the mask algorithm we 514 are declaring we support with the RSASSA-PSS signature 515 algorithm. 517 trailerField specifies which trailer field algorithm is being 518 supported. This MUST be the value 1. 520 NOTE: In at least one iteration of the design we used a sequence of 521 hash identifiers and a sequence of masking functions and again made 522 the assumption that the entire the matrix would be supported. This 523 has been removed at this point since the original intent of S/MIME 524 capabilities is that one should be able to do a binary comparison of 525 the DER encoding of the field and determine a specific capability was 526 published. We could return back to using the sequence if we wanted 527 to lose the ability to do a binary compare but needed to shorten the 528 encodings. This does not currently appear to be an issue at this 529 point. 531 6. Security Considerations 533 This document provides new fields that can be placed in an S/MIME 534 capabilities sequence. There are number of considerations that need 535 to be taken into account when doing this. 537 As mentioned above, we have defined data structures to be associated 538 with Object Identifiers in cases where an association already exists. 539 When either encoding or decoding structures, care needs to be taken 540 that the association used is one appropriate for the location in the 541 surrounding ASN.1 structure. This means that one needs to make sure 542 that only public keys are place in public key locations, signatures 543 are placed in signature locations and S/MIME capabilities are placed 544 in S/MIME Capability locations. Failure to do so at best will create 545 decode errors and at worst can cause incorrect behavior. 547 The more specific the information that is provided in an S/MIME 548 Capabilities field, the better the end results are going to be. 549 Specifying a signature algorithm means that there are no questions 550 for the receiver that the signature algorithm is supported. 551 Signature algorithms can be implied by specifying both public key 552 algorithms and hash algorithms together. If the list includes RSA 553 v1.5, EC-DSA, SHA-1 and SHA-256, the implication is that all four 554 values in the cross section are supported by the sender. If the 555 sender does not support EC-DSA with SHA-1, this would lead to a 556 situation where the recipient uses a signature algorithm that the 557 sender does not support. Omitting SHA-1 from the list may lead to 558 the problem where both entities support RSA v1.5 with SHA-1 as their 559 only common algorithm, but this is no longer discoverable by the 560 recipient. 562 As a general rule, providing more information about the algorithms 563 that are supported is preferable. The more choices that are provided 564 the recipient, the greater the likelihood that a common algorithm 565 with good security can be used by both parties. One should avoid 566 being exhaustive in providing the list of algorithms to the recipient 567 however. The greater the number of algorithms that are passed the 568 more difficult it is for a recipient to make intellegent decisions 569 about which algorithm to be used. This is a more significant problem 570 when there are more than two entities involved in the "negotiation" 571 of a common algorithm to be used (such as sending an encrypted S/MIME 572 message where a common content encryption algorithm is needed). The 573 larger the set of algorithms and the more recipients involved, the 574 more memory and processing time will be needed in order to complete 575 the decision making process. 577 The S/MIME capabilities is defined so that the order of algorithms in 578 the sequence is meant to encode a preference order by the sender of 579 the sequence. Many entities will ignore the order preference when 580 making a decision either by using their own preferred order or using 581 a random decision from a matrix. 583 7. IANA Considerations 585 This document has no IANA considerations. 587 8. References 589 8.1. Normative References 591 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 592 Requirement Levels", BCP 14, RFC 2119, March 1997. 594 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 595 Identifiers for the Internet X.509 Public Key 596 Infrastructure Certificate and Certificate Revocation List 597 (CRL) Profile", RFC 3279, April 2002. 599 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 600 Algorithms and Identifiers for RSA Cryptography for use in 601 the Internet X.509 Public Key Infrastructure Certificate 602 and Certificate Revocation List (CRL) Profile", RFC 4055, 603 June 2005. 605 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 606 "Elliptic Curve Cryptography Subject Public Key 607 Information", RFC 5480, March 2009. 609 8.2. Informative References 611 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 612 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 613 June 2010. 615 [RFC6277] Santesson, S. and P. Hallam-Baker, "Online Certificate 616 Status Protocol Algorithm Agility", RFC 6277, June 2011. 618 [SMIME-MSG] 619 Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 620 Mail Extensions (S/MIME) Version 3.2 Message 621 Specification", RFC 5751, January 2010. 623 [RFC4262] Santesson, S., "X.509 Certificate Extension for Secure/ 624 Multipurpose Internet Mail Extensions (S/MIME) 625 Capabilities", RFC 4262, December 2005. 627 [SMIMEv3-MSG] 628 Ramsdell, B., "S/MIME Version 3 Message Specification", 629 RFC 2633, June 1999. 631 [NIST-SIZES] 632 Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid, 633 "Recommendation for Key Management -- Part 1: General", 634 NIST Special Publication 800-57, March 2007. 636 Appendix A. 2008 ASN.1 Module 638 This appendix contains a module compatible with the work done to 639 update the PKIX ASN.1 modules to recent versions of the ASN.1 640 specifications [RFC5912]. This appendix is to be considered 641 informational per the current direction of the PKIX working group. 643 PUBLIC-KEY-SMIME-CAPABILITIES 644 { iso(1) identified-organization(3) dod(6) internet(1) 645 security(5) mechanisms(5) pkix(7) id-mod(0) 646 id-mod-pubKeySMIMECaps-08(78) } 647 DEFINITIONS ::= 648 BEGIN 649 IMPORTS 650 SMIME-CAPS, PUBLIC-KEY, SMIMECapability 651 FROM AlgorithmInformation-2009 652 { iso(1) identified-organization(3) dod(6) internet(1) 653 security(5) mechanisms(5) pkix(7) id-mod(0) 654 id-mod-algorithmInformation-02(58)} 656 pk-rsa, pk-dsa, pk-dh, pk-ec, pk-ecDH, pk-ecMQV, ECParameters 657 FROM PKIXAlgs-2009 658 { iso(1) identified-organization(3) dod(6) internet(1) 659 security(5) mechanisms(5) pkix(7) id-mod(0) 660 id-mod-pkix1-algorithms2008-02(56) } 662 pk-rsaSSA-PSS, pk-rsaES-OAEP, sa-rsaSSA-PSS, 663 HashAlgorithms, id-mgf1 664 FROM PKIX1-PSS-OAEP-Algorithms-2009 665 { iso(1) identified-organization(3) dod(6) internet(1) 666 security(5) mechanisms(5) pkix(7) id-mod(0) 667 id-mod-pkix1-rsa-pkalgs-02(54)} 668 ; 670 -- 671 -- Define a set containing all of the S/MIME capabilties defined 672 -- by this document 673 -- 675 SMimeCaps SMIME-CAPS ::= { 676 PubKeys-SMimeCaps | 677 scap-sa-rsaSSA-PSS 678 } 680 PubKeys-SMimeCaps SMIME-CAPS ::= { 681 scap-pk-rsa | scap-pk-rsaSSA-PSS | 682 scap-pk-dsa | 683 scap-pk-ec | scap-pk-ecDH | scap-pk-ecMQV 685 } 687 -- 688 -- We defined RSA keys from the modules RFC3279 and RFC4055 689 -- 691 scap-pk-rsa SMIME-CAPS ::= { 692 TYPE RSAKeyCapabilities 693 IDENTIFIED BY pk-rsa.&id 694 } 696 RSAKeyCapabilities ::= SEQUENCE { 697 minKeySize RSAKeySize, 698 maxKeySize RSAKeySize OPTIONAL 699 } 701 RSAKeySize ::= INTEGER (1024 | 2048 | 3072 | 4096 | 7680 | 702 8192 | 15360, ...) 704 scap-pk-rsaES-OAEP SMIME-CAPS ::= { 705 TYPE RSAKeyCapabilities 706 IDENTIFIED BY pk-rsaES-OAEP.&id 707 } 709 scap-pk-rsaSSA-PSS SMIME-CAPS ::= { 710 TYPE RSAKeyCapabilities 711 IDENTIFIED BY pk-rsaSSA-PSS.&id 712 } 714 scap-sa-rsaSSA-PSS SMIME-CAPS ::= { 715 TYPE RsaSsa-Pss-sig-caps 716 IDENTIFIED BY sa-rsaSSA-PSS.&id 717 } 719 RsaSsa-Pss-sig-caps ::= SEQUENCE { 720 hashAlg SMIMECapability{{ MaskAlgorithmSet }}, 721 maskAlg SMIMECapability{{ ... }} OPTIONAL, 722 trailerField INTEGER DEFAULT 1 723 } 725 scap-mf-mgf1 SMIME-CAPS ::= { 726 TYPE SMIMECapability{{ ... }} 727 IDENTIFIED BY id-mgf1 728 } 730 MaskAlgorithmSet SMIME-CAPS ::= {scap-mf-mgf1, ...} 731 -- 732 -- we define DH/DSA keys from the module RFC3279 733 -- 735 scap-pk-dsa SMIME-CAPS ::= { 736 TYPE DSAKeyCapabilities 737 IDENTIFIED BY pk-dsa.&id 738 } 740 DSAKeyCapabilities ::= CHOICE { 741 keySizes [0] SEQUENCE { 742 minKeySize DSAKeySize, 743 maxKeySize DSAKeySize OPTIONAL, 744 maxSizeP [1] INTEGER OPTIONAL, 745 maxSizeQ [2] INTEGER OPTIONAL, 746 maxSizeG [3] INTEGER OPTIONAL 747 }, 748 keyParams [1] pk-dsa.&Params 749 } 751 DSAKeySize ::= INTEGER (1024 | 2048 | 3072 | 7680 | 15360 ) 753 scap-pk-dh SMIME-CAPS ::= { 754 TYPE DSAKeyCapabilities 755 IDENTIFIED BY pk-dh.&id 756 } 758 -- 759 -- we define Eliptical Curve keys from the module RFC3279 760 -- 762 scap-pk-ec SMIME-CAPS ::= { 763 TYPE EC-SMimeCaps 764 IDENTIFIED BY pk-ec.&id 765 } 767 EC-SMimeCaps ::= SEQUENCE (SIZE (1..MAX)) OF ECParameters 769 scap-pk-ecDH SMIME-CAPS ::= { 770 TYPE EC-SMimeCaps 771 IDENTIFIED BY pk-ecDH.&id 772 } 774 scap-pk-ecMQV SMIME-CAPS ::= { 775 TYPE EC-SMimeCaps 776 IDENTIFIED BY pk-ecMQV.&id 777 } 779 END 781 Appendix B. 1988 ASN.1 Module 783 This appendix contains the normative ASN.1 module for this document. 785 PUBLIC-KEY-SMIME-CAPABILITIES-88 786 { iso(1) identified-organization(3) dod(6) internet(1) 787 security(5) mechanisms(5) pkix(7) id-mod(0) 788 id-mod-pubKeySMIMECaps-88(77) } 789 DEFINITIONS ::= 790 BEGIN 791 IMPORTS 793 ECParameters 794 FROM PKIX1Algorithms2008 795 { iso(1) identified-organization(3) dod(6) 796 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 797 45 } 799 id-mgf1 800 FROM PKIX1-PSS-OAEP-Algorithms 801 { iso(1) identified-organization(3) dod(6) 802 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 803 id-mod-pkix1-rsa-pkalgs(33) } 805 AlgorithmIdentifier 806 FROM PKIX1Explicit88 807 { iso(1) identified-organization(3) dod(6) internet(1) 808 security(5) mechanisms(5) pkix(7) id-mod(0) 809 id-pkix1-explicit(18) } 811 ; 813 -- 814 -- We defined RSA keys from the modules RFC3279 and RFC4055 815 -- 817 RSAKeyCapabilities ::= SEQUENCE { 818 minKeySize RSAKeySize, 819 maxKeySize RSAKeySize OPTIONAL 820 } 822 RSAKeySize ::= INTEGER (1024 | 2048 | 3072 | 4096 | 7680 | 823 8192 | 15360, ...) 825 RsaSsa-Pss-sig-caps ::= SEQUENCE { 826 hashAlg AlgorithmIdentifier, 827 maskAlg AlgorithmIdentifier OPTIONAL, 828 trailerField INTEGER DEFAULT 1 829 } 831 -- 832 -- we define DH/DSA keys from the module RFC3279 833 -- 835 DSAKeyCapabilities ::= CHOICE { 836 keySizes [0] SEQUENCE { 837 minKeySize DSAKeySize, 838 maxKeySize DSAKeySize OPTIONAL, 839 maxSizeP [1] INTEGER OPTIONAL, 840 maxSizeQ [2] INTEGER OPTIONAL, 841 maxSizeG [3] INTEGER OPTIONAL 842 }, 843 keyParams [1] pk-dsa.&Params 844 } 846 DSAKeySize ::= INTEGER (1024 | 2048 | 3072 | 7680 | 15360 ) 848 -- 849 -- we define Eliptical Curve keys from the module RFC3279 850 -- 852 EC-SMimeCaps ::= SEQUENCE (SIZE (1..MAX)) OF ECParameters 854 END 856 Appendix C. Future Work 858 A future revision of [RFC5912] should be done at some point which 859 expands the definition of the PUBLIC-KEY class and allows for an 860 S/MIME Capability to be included in the class definition. This would 861 encourage people to think about this as an issue when defining new 862 public key structures in the future. 864 Author's Address 866 Jim Schaad 867 Soaring Hawk Consulting 869 Email: ietf@augustcellars.com