From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6664.txt | 1067 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1067 insertions(+) create mode 100644 doc/rfc/rfc6664.txt (limited to 'doc/rfc/rfc6664.txt') diff --git a/doc/rfc/rfc6664.txt b/doc/rfc/rfc6664.txt new file mode 100644 index 0000000..76391b8 --- /dev/null +++ b/doc/rfc/rfc6664.txt @@ -0,0 +1,1067 @@ + + + + + + +Internet Engineering Task Force (IETF) J. Schaad +Request for Comments: 6664 Soaring Hawk Consulting +Category: Informational July 2012 +ISSN: 2070-1721 + + + S/MIME Capabilities for Public Key Definitions + +Abstract + + This document defines a set of Secure/Multipurpose Internet Mail + Extensions (S/MIME) Capability types for ASN.1 encoding for the + current set of public keys defined by the PKIX working group. This + facilitates the ability for a requester to specify information on the + public keys and signature algorithms to be used in responses. + "Online Certificate Status Protocol Algorithm Agility" (RFC 6277) + details an example of where this is used. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6664. + +Copyright Notice + + Copyright (c) 2012 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + +Schaad Informational [Page 1] + +RFC 6664 S/MIME Capabilities for Public Keys July 2012 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 1.1. ASN.1 Notation . . . . . . . . . . . . . . . . . . . . . . 3 + 1.2. Requirements Terminology . . . . . . . . . . . . . . . . . 4 + 2. RSA Public Keys . . . . . . . . . . . . . . . . . . . . . . . 4 + 2.1. Generic RSA Public Keys . . . . . . . . . . . . . . . . . 4 + 2.2. RSASSA-PSS Signature Public Keys . . . . . . . . . . . . . 5 + 2.3. RSAES-OAEP Key Transport Public Keys . . . . . . . . . . . 6 + 3. Diffie-Hellman Keys . . . . . . . . . . . . . . . . . . . . . 7 + 3.1. DSA Signature Public Key . . . . . . . . . . . . . . . . . 7 + 3.2. DH Key Agreement Keys . . . . . . . . . . . . . . . . . . 8 + 4. Elliptic Curve Keys . . . . . . . . . . . . . . . . . . . . . 8 + 4.1. Generic Elliptic Curve Keys . . . . . . . . . . . . . . . 9 + 4.2. Elliptic Curve DH Keys . . . . . . . . . . . . . . . . . . 10 + 4.3. Elliptic Curve MQV Keys . . . . . . . . . . . . . . . . . 10 + 5. RSASSA-PSS Signature Algorithm Capability . . . . . . . . . . 10 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 + 7.2. Informative References . . . . . . . . . . . . . . . . . . 13 + Appendix A. 2008 ASN.1 Module . . . . . . . . . . . . . . . . . . 15 + Appendix B. 1988 ASN.1 Module . . . . . . . . . . . . . . . . . . 18 + Appendix C. Future Work . . . . . . . . . . . . . . . . . . . . . 19 + +1. Introduction + + In the process of dealing with the Online Certificate Status Protocol + (OCSP) agility issues in [RFC6277], it was noted that we really + wanted to describe information to be used in selecting a public key, + but we did not have any way of doing so. This document fills that + hole by defining a set of Secure/Multipurpose Internet Mail + Extensions (S/MIME) Capability types for a small set of public key + representations. + + S/MIME capabilities were originally defined in [SMIMEv3-MSG] as a way + for the sender of an S/MIME message to tell the recipient of the + message the set of encryption algorithms that were supported by the + sender's system. In the beginning, the focus was primarily on + communicating the set of encryption algorithms that were supported by + the sender. Over time, it was expanded to allow for an S/MIME client + to state that it supported new features such as the compression data + type and binary encoded contents. The structure was defined so that + parameters can be passed in as part of the capability to allow for + subsets of algorithms to be used. This was used for the RC2 + encryption algorithm, although only two values out of the set of + values were ever used. The goal of restricting the set of values is + to allow a client to use a simple binary comparison in order to check + + + +Schaad Informational [Page 2] + +RFC 6664 S/MIME Capabilities for Public Keys July 2012 + + + for equality. The client should never need to decode the capability + and do an element-by-element comparison. Historically, this has not + been a problem as the vast majority of S/MIME capabilities consist of + just the algorithm identifier for the algorithm. + + Many people are under the impression that only a single data + structure can be assigned to an object identifier, but this is not + the case. As an example, the OID rsaEncryption is used in multiple + locations for different data. It represents a public key, a key + transport algorithm (in S/MIME), and was originally used in the + Public-Key Cryptography Standards (PKCS) #7 specification as a + signature value identifier (this has since been changed by the S/MIME + specifications). One of the implications is that when mapping an + object identifier to a data type structure, the location in the ASN.1 + structure needs to be taken into consideration as well. + +1.1. ASN.1 Notation + + The main body of the text is written using snippets of ASN.1 that are + extracted from the ASN.1 2008 module in Appendix A. ASN.1 2008 is + used in this document because it directly represents the metadata + that is not representable in the 1988 version of ASN.1 but instead is + part of the text. In keeping with the current policy of the PKIX + working group, the 1988 module along with the text is the normative + module. In the event of a conflict between the content of the two + modules, the 1988 module is authoritative. + + When reading this document, it is assumed that you will have a degree + of familiarity with the basic object module that is presented in + Section 3 of RFC 5912 [RFC5912]. We use the SMIME-CAPS object in + this document; it associates two fields together in a single object. + + SMIME-CAPS ::= CLASS { + &id OBJECT IDENTIFIER UNIQUE, + &Type OPTIONAL + } + WITH SYNTAX { [TYPE &Type] IDENTIFIED BY &id } + + These fields are: + + &id contains an object identifier. When placed in an object set, + this element is tagged so that no two elements can be placed in + the set that have the same value in the &id field. Note that this + is not a restriction saying that only a single object can exist + with a single object identifier. + + + + + + +Schaad Informational [Page 3] + +RFC 6664 S/MIME Capabilities for Public Keys July 2012 + + + &Type optionally contains an ASN.1 type identifier. If the field + &Type is not defined, then the optional parameters field of the + AlgorithmIdentifier type would be omitted. + + The class also has a specialized syntax for how to define an object + in this class. The all uppercase words TYPE IDENTIFIER and BY are + syntactic sugar to make it easier to read. The square brackets + define optional pieces of the syntax. + + The ASN.1 syntax permits any field in an object to be referenced in + another location. This means that if an object called foo has a + field named &value, the value can be directly referenced as foo.& + value. This means that any updates to values or types are + automatically propagated, and we do not need to replicate the data. + +1.2. Requirements Terminology + + When capitalized, the key words "MUST", "MUST NOT", "REQUIRED", + "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", + and "OPTIONAL" in this document are to be interpreted as described in + [RFC2119]. + +2. RSA Public Keys + + There are currently three different public key object identifiers for + RSA public keys. These are RSA, RSA Encryption Scheme - Optimal + Asymmetric Encryption Padding (RSAES-OAEP), and RSA Signature Scheme + with Appendix - Probabilistic Signature Scheme (RSASSA-PSS). + +2.1. Generic RSA Public Keys + + Almost all RSA keys that are contained in certificates today use the + generic RSA public key format and identifier. This allows for the + public key to be used both for key transport and for signature + validation (assuming it is compatible with the bits in the key usage + extension). The only reason for using one of the more specific + public key identifiers is if the user wants to restrict the usage of + the RSA public key to a specific algorithm. + + For the generic RSA public key, the S/MIME capability that is + advertised is a request for a specific key size to be used. This + would normally be used for dealing with a request on the key to be + used for a signature that the client would then verify. In general, + the user would provide a specific key when a key transport algorithm + is being considered. + + + + + + +Schaad Informational [Page 4] + +RFC 6664 S/MIME Capabilities for Public Keys July 2012 + + + The ASN.1 that is used for the generic RSA public key is defined as + below: + + scap-pk-rsa SMIME-CAPS ::= { + TYPE RSAKeyCapabilities + IDENTIFIED BY pk-rsa.&id + } + + RSAKeyCapabilities ::= SEQUENCE { + minKeySize RSAKeySize, + maxKeySize RSAKeySize OPTIONAL + } + + RSAKeySize ::= INTEGER (1024 | 2048 | 3072 | 4096 | 7680 | + 8192 | 15360, ...) + + + In the above ASN.1, we have defined the following: + + scap-pk-rsa is a new SMIME-CAPS object. This object associates the + existing object identifier (rsaEncryption) used for the public key + in certificates (defined in [RFC3279] and [RFC5912]) with a new + type defined in this document. + + RSAKeyCapabilities carries the set of desired capabilities for an + RSA key. The fields of this type are: + + minKeySize contains the minimum length of the RSA modulus to be + used. This field SHOULD NOT contain a value less than 1024. + + maxKeySize contains the maximum length of the RSA modules that + should be used. If this field is absent, then no maximum + length is requested/expected. This value is normally selected + so as not to cause the current code to run unacceptably long + when processing signatures. + + RSAKeySize provides a set of suggested values to be used. The + values 1024, 2048, 3072, 7680, and 15360 are from the NIST guide + on signature sizes [NIST-SIZES] while the others are common powers + of two that are used. The list is not closed, and other values + can be used. + +2.2. RSASSA-PSS Signature Public Keys + + While one will use the generic RSA public key identifier in a + certificate most of the time, the RSASSA-PSS identifier can be used + if the owner of the key desires to restrict the usage of the key to + just this algorithm. This algorithm does have the ability to place a + + + +Schaad Informational [Page 5] + +RFC 6664 S/MIME Capabilities for Public Keys July 2012 + + + set of algorithm parameters in the public key info structure, but + they have not been included in this location as the same information + should be carried in the signature S/MIME capabilities instead. + + The ASN.1 that is used for the RSASSA-PSS public key is defined + below: + + scap-pk-rsaSSA-PSS SMIME-CAPS ::= { + TYPE RSAKeyCapabilities + IDENTIFIED BY pk-rsaSSA-PSS.&id + } + + In the above ASN.1, we have defined the following: + + scap-pk-rsaSSA-PSS is a new SMIME-CAPS object. This object + associates the existing object identifier (id-RSASSA-PSS) used for + the public key certificates (defined in [RFC4055] and [RFC5912]) + with type RSAKeyCapabilities. + +2.3. RSAES-OAEP Key Transport Public Keys + + While one will use the generic RSA public key identifier in a + certificate most of the time, the RSAES-OAEP identifier can be used + if the owner of the key desires to restrict the usage of the key to + just this algorithm. This algorithm does have the ability to place a + set of algorithm parameters in the public key info structure, but + they have not been included in this location as the same information + should be carried in the key transport S/MIME capabilities instead. + + The ASN.1 that is used for the RSAES-OAEP public key is defined + below: + + scap-pk-rsaES-OAEP SMIME-CAPS ::= { + TYPE RSAKeyCapabilities + IDENTIFIED BY pk-rsaES-OAEP.&id + } + + In the above ASN.1, we have defined the following: + + scap-pk-rsaES-OAEP is a new SMIME-CAPS object. This object + associates the existing object identifier (id-RSAES-OAEP) used for + the public key certificates (defined in [RFC4055] and [RFC5912]) + with type RSAKeyCapabilities. + + + + + + + + +Schaad Informational [Page 6] + +RFC 6664 S/MIME Capabilities for Public Keys July 2012 + + +3. Diffie-Hellman Keys + + There are currently two Diffie-Hellman (DH) public key object + identifiers. These are DH key agreement and Digital Signature + Standard (DSA). + +3.1. DSA Signature Public Key + + This public key type is used for the validation of DSA signatures. + + The ASN.1 that is used for DSA keys is defined below: + + scap-pk-dsa SMIME-CAPS ::= { + TYPE DSAKeyCapabilities + IDENTIFIED BY pk-dsa.&id + } + + DSAKeyCapabilities ::= CHOICE { + keySizes [0] SEQUENCE { + minKeySize DSAKeySize, + maxKeySize DSAKeySize OPTIONAL, + maxSizeP [1] INTEGER OPTIONAL, + maxSizeQ [2] INTEGER OPTIONAL, + maxSizeG [3] INTEGER OPTIONAL + }, + keyParams [1] pk-dsa.&Params + } + + DSAKeySize ::= INTEGER (1024 | 2048 | 3072 | 7680 | 15360 ) + + In the above ASN.1, we have defined the following: + + scap-pk-dsa is a new SMIME-CAPS object. This object associates the + existing object identifier (id-dsa) used for the public key in + certificates (defined in [RFC3279] and [RFC5912]) with a new type + defined here, DSAKeyCapabilities. + + DSAKeyCapabilities carries the desired set of capabilities for the + DSA key. The fields of this type are: + + keySizes is used when only a key size is needed to be specified + and not a specific group. It is expected that this would be + the most commonly used of the two options. In key sizes, the + fields are used as follows: + + minKeySize contains the minimum length of the DSA modulus to + be used. + + + + +Schaad Informational [Page 7] + +RFC 6664 S/MIME Capabilities for Public Keys July 2012 + + + maxKeySize contains the maximum length of the DSA modules that + should be used. If this field is absent, then no maximum + length is requested/expected. + + maxSizeP contains the maximum length of the value p that + should be used. If this field is absent, then no maximum + length is imposed. + + maxSizeQ contains the maximum length of the value q that + should be used. If this field is absent, then no maximum + length is imposed. + + maxSizeG contains the maximum length of the value g that + should be used. If this field is absent, then no maximum + length is imposed. + + keyParams contains the exact set of DSA for the key used to sign + the message. This field is provided for completeness and to + match the fields for Elliptic Curve; however, it is expected + that usage of this field will be extremely rare. + +3.2. DH Key Agreement Keys + + This public key type is used with the DH key agreement algorithm. + + The ASN.1 that is used for DH keys is defined below: + + scap-pk-dh SMIME-CAPS ::= { + TYPE DSAKeyCapabilities + IDENTIFIED BY pk-dh.&id + } + + In the above ASN.1, we have defined the following: + + scap-pk-dh is a new SMIME-CAPS object. This object associates the + existing object identifier (dhpublicnumber) used for the public + key algorithm in the certificates (defined in [RFC3279] and + [RFC5912]) with a new type defined above, DSAKeyCapabilities. + +4. Elliptic Curve Keys + + There are currently three Elliptic Curve Cryptography (ECC) public + key object identifiers. These are EC, EC-DH, and Elliptic Curve + Menezes-Qu-Vanstone (EC-MQV). + + + + + + + +Schaad Informational [Page 8] + +RFC 6664 S/MIME Capabilities for Public Keys July 2012 + + +4.1. Generic Elliptic Curve Keys + + Almost all ECC keys that are contained in certificates today use the + generic ECC public key format and identifier. This allows for the + public key to be used both for key agreement and for signature + validation (assuming the appropriate bits are in the certificate). + The only reason for using one of the more specific public key + identifier is if the user wants to restrict the usage of the ECC + public key to a specific algorithm. + + For the generic ECC public key, the S/MIME capability that is + advertised is a request for a specific group to be used. + + The ASN.1 that is used for the generic ECC public key is defined + below: + + scap-pk-ec SMIME-CAPS ::= { + TYPE EC-SMimeCaps + IDENTIFIED BY pk-ec.&id + } + + EC-SMimeCaps ::= SEQUENCE (SIZE (1..MAX)) OF ECParameters + + In the above ASN.1, we have defined the following: + + scap-pk-ec is a new SMIME-CAPS object. This object associates the + existing object identifier (id-ecPublicKey) used for the public + key algorithm in the certificates (defined in [RFC5480] and + [RFC5912]) with the new type EC-SMimeCaps. + + EC-SMimeCaps carries a sequence of at least one ECParameters + structure. This allows for multiple curves to be requested in a + single capability request. A maximum/minimum style of specifying + sizes is not provided as much greater care is required in + selecting a specific curve than is needed to create the parameters + for a DSA/DH key. As specified in [RFC5480], for PKIX-compliant + certificates, only the namedCurve choice of ECParameters is + expected to be used. + + + + + + + + + + + + + +Schaad Informational [Page 9] + +RFC 6664 S/MIME Capabilities for Public Keys July 2012 + + +4.2. Elliptic Curve DH Keys + + This public key type is used with the Elliptic Curve Diffie-Hellman + key agreement algorithm. + + The ASN.1 that is used for EC-DH keys is defined below: + + scap-pk-ecDH SMIME-CAPS ::= { + TYPE EC-SMimeCaps + IDENTIFIED BY pk-ecDH.&id + } + + In the above ASN.1, we have defined the following: + + scap-pk-ecDH is a new SMIME-CAPS object. This object associates the + existing object identifier (id-ecDH) used for the public key + algorithm in the certificate (defined in [RFC5480] and [RFC5912]) + with the same type structure used for public keys. + +4.3. Elliptic Curve MQV Keys + + This public key type is used with the Elliptic Curve MQV key + agreement algorithm. + + The ASN.1 that is used for EC-MQV keys is defined below: + + scap-pk-ecMQV SMIME-CAPS ::= { + TYPE EC-SMimeCaps + IDENTIFIED BY pk-ecMQV.&id + } + + In the above ASN.1, we have defined the following: + + scap-pk-ecMQV is a new SMIME-CAPS object. This object associates + the existing object identifier (id-ecMQV) used for the public key + algorithm in the certificate (defined in [RFC5480] and [RFC5912]) + with the same type structure used for public keys. + +5. RSASSA-PSS Signature Algorithm Capability + + This document defines a new SMIMECapability for the RSASSA-PSS + signature algorithm. One already exists in [RFC4055] where the + parameters field is not used. + + When the S/MIME group defined an S/MIME capability for the RSASSA-PSS + signature algorithm, it was done in the context of how S/MIME defines + and uses S/MIME capabilities. When placed in an S/MIME message + [SMIME-MSG] or in a certificate [RFC4262], it is always placed in a + + + +Schaad Informational [Page 10] + +RFC 6664 S/MIME Capabilities for Public Keys July 2012 + + + sequence of capabilities. This means that one could place the + identifier for RSASSA-PSS in the sequence along with the identifier + for MD5, SHA-1, and SHA-256. The assumption was then made that one + could compute the matrix of all answers, and the publisher would + support all elements in the matrix. This has the possibility that + the publisher could accidentally publish a point in the matrix that + is not supported. + + In this situation, there is only a single item that is published. + This means that we need to publish all of the associated information + along with the identifier for the signature algorithm in a single + entity. For this reason, we now define a new parameter type to be + used as the SMIMECapability type, which contains a hash identifier + and a mask identifier. The ASN.1 used for this is as follows: + + scap-sa-rsaSSA-PSS SMIME-CAPS ::= { + TYPE RsaSsa-Pss-sig-caps + IDENTIFIED BY sa-rsaSSA-PSS.&id + } + + RsaSsa-Pss-sig-caps ::= SEQUENCE { + hashAlg SMIMECapability{{ MaskAlgorithmSet }}, + maskAlg SMIMECapability{{ ... }} OPTIONAL, + trailerField INTEGER DEFAULT 1 + } + + scap-mf-mgf1 SMIME-CAPS ::= { + TYPE SMIMECapability{{ ... }} + IDENTIFIED BY id-mgf1 + } + + MaskAlgorithmSet SMIME-CAPS ::= {scap-mf-mgf1, ...} + + In the above ASN.1, we have defined the following: + + scap-sa-rsaSSA-PSS is a new SMIME-CAPS object. This object + associates the existing object identifier (id-RSASSA-PSS) used for + the signature algorithm (defined in [RFC4055] and [RFC5912]) with + the new type RsaSsa-Pss-sig-caps. + + RsaSsa-Pss-sig-caps carries the desired set of capabilities for the + RSASSA-PSS signature algorithm. The fields of this type are: + + hashAlg contains the S/MIME capability for the hash algorithm we + are declaring we support with the RSASSA-PSS signature + algorithm. + + + + + +Schaad Informational [Page 11] + +RFC 6664 S/MIME Capabilities for Public Keys July 2012 + + + maskAlg contains the S/MIME capability for the mask algorithm we + are declaring we support with the RSASSA-PSS signature + algorithm. + + trailerField specifies which trailer field algorithm is being + supported. This MUST be the value 1. + + NOTE: In at least one iteration of the design, we used a sequence of + hash identifiers and a sequence of masking functions and again made + the assumption that the entire matrix would be supported. This has + been removed at this point since the original intent of S/MIME + capabilities is that one should be able to do a binary comparison of + the DER encoding of the field and determine a specific capability was + published. We could return to using the sequence if we wanted to + lose the ability to do a binary compare but needed to shorten the + encodings. This does not currently appear to be an issue at this + point. + +6. Security Considerations + + This document provides new fields that can be placed in an S/MIME + capabilities sequence. There are number of considerations that need + to be taken into account when doing this. + + As mentioned above, we have defined data structures to be associated + with object identifiers in cases where an association already exists. + When either encoding or decoding structures, care needs to be taken + that the association used is one appropriate for the location in the + surrounding ASN.1 structure. This means that one needs to make sure + that only public keys are placed in public key locations, signatures + are placed in signature locations, and S/MIME capabilities are placed + in SMIMECapability locations. Failure to do so will create decode + errors at best and can cause incorrect behavior at worst. + + The more specific the information that is provided in an S/MIME + Capabilities field, the better the end results are going to be. + Specifying a signature algorithm means that there are no questions + for the receiver that the signature algorithm is supported. + Signature algorithms can be implied by specifying both public key + algorithms and hash algorithms together. If the list includes RSA + v1.5, EC-DSA, SHA-1, and SHA-256, the implication is that all four + values in the cross section are supported by the sender. If the + sender does not support EC-DSA with SHA-1, this would lead to a + situation where the recipient uses a signature algorithm that the + sender does not support. Omitting SHA-1 from the list may lead to + the problem where both entities support RSA v1.5 with SHA-1 as their + only common algorithm, but this is no longer discoverable by the + recipient. + + + +Schaad Informational [Page 12] + +RFC 6664 S/MIME Capabilities for Public Keys July 2012 + + + As a general rule, providing more information about the algorithms + that are supported is preferable. The more choices that are provided + the recipient, the greater the likelihood that a common algorithm + with good security can be used by both parties. However, one should + avoid being exhaustive in providing the list of algorithms to the + recipient. The greater the number of algorithms that are passed, the + more difficult it is for a recipient to make intelligent decisions + about which algorithm to use. This is a more significant problem + when there are more than two entities involved in the "negotiation" + of a common algorithm to be used (such as sending an encrypted S/MIME + message where a common content encryption algorithm is needed). The + larger the set of algorithms and the more recipients involved, the + more memory and processing time will be needed in order to complete + the decision-making process. + + The S/MIME capabilities are defined so that the order of algorithms + in the sequence is meant to encode a preference order by the sender + of the sequence. Many entities will ignore the order preference when + making a decision either by using their own preferred order or using + a random decision from a matrix. + +7. References + +7.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and + Identifiers for the Internet X.509 Public Key + Infrastructure Certificate and Certificate Revocation + List (CRL) Profile", RFC 3279, April 2002. + + [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional + Algorithms and Identifiers for RSA Cryptography for + use in the Internet X.509 Public Key Infrastructure + Certificate and Certificate Revocation List (CRL) + Profile", RFC 4055, June 2005. + + [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. + Polk, "Elliptic Curve Cryptography Subject Public Key + Information", RFC 5480, March 2009. + +7.2. Informative References + + [NIST-SIZES] Barker, E., Barker, W., Burr, W., Polk, W., and M. + Smid, "Recommendation for Key Management -- Part 1: + General", NIST Special Publication 800-57, March 2007. + + + +Schaad Informational [Page 13] + +RFC 6664 S/MIME Capabilities for Public Keys July 2012 + + + [RFC4262] Santesson, S., "X.509 Certificate Extension for + Secure/Multipurpose Internet Mail Extensions (S/MIME) + Capabilities", RFC 4262, December 2005. + + [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the + Public Key Infrastructure Using X.509 (PKIX)", + RFC 5912, June 2010. + + [RFC6277] Santesson, S. and P. Hallam-Baker, "Online Certificate + Status Protocol Algorithm Agility", RFC 6277, + June 2011. + + [SMIME-MSG] Ramsdell, B. and S. Turner, "Secure/Multipurpose + Internet Mail Extensions (S/MIME) Version 3.2 Message + Specification", RFC 5751, January 2010. + + [SMIMEv3-MSG] Ramsdell, B., "S/MIME Version 3 Message + Specification", RFC 2633, June 1999. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Schaad Informational [Page 14] + +RFC 6664 S/MIME Capabilities for Public Keys July 2012 + + +Appendix A. 2008 ASN.1 Module + + This appendix contains a module compatible with the work done to + update the PKIX ASN.1 modules to recent versions of the ASN.1 + specifications [RFC5912]. This appendix is to be considered + informational per the current direction of the PKIX working group. + + PUBLIC-KEY-SMIME-CAPABILITIES + { iso(1) identified-organization(3) dod(6) internet(1) + security(5) mechanisms(5) pkix(7) id-mod(0) + id-mod-pubKeySMIMECaps-08(78) } + DEFINITIONS ::= + BEGIN + IMPORTS + SMIME-CAPS, PUBLIC-KEY, SMIMECapability + FROM AlgorithmInformation-2009 + { iso(1) identified-organization(3) dod(6) internet(1) + security(5) mechanisms(5) pkix(7) id-mod(0) + id-mod-algorithmInformation-02(58)} + + pk-rsa, pk-dsa, pk-dh, pk-ec, pk-ecDH, pk-ecMQV, ECParameters + FROM PKIXAlgs-2009 + { iso(1) identified-organization(3) dod(6) internet(1) + security(5) mechanisms(5) pkix(7) id-mod(0) + id-mod-pkix1-algorithms2008-02(56) } + + pk-rsaSSA-PSS, pk-rsaES-OAEP, sa-rsaSSA-PSS, + HashAlgorithms, id-mgf1 + FROM PKIX1-PSS-OAEP-Algorithms-2009 + { iso(1) identified-organization(3) dod(6) internet(1) + security(5) mechanisms(5) pkix(7) id-mod(0) + id-mod-pkix1-rsa-pkalgs-02(54)} + ; + + -- + -- Define a set containing all of the S/MIME capabilities defined + -- by this document. + -- + + SMimeCaps SMIME-CAPS ::= { + PubKeys-SMimeCaps | + scap-sa-rsaSSA-PSS + } + + PubKeys-SMimeCaps SMIME-CAPS ::= { + scap-pk-rsa | scap-pk-rsaSSA-PSS | + scap-pk-dsa | + scap-pk-ec | scap-pk-ecDH | scap-pk-ecMQV + + + +Schaad Informational [Page 15] + +RFC 6664 S/MIME Capabilities for Public Keys July 2012 + + + } + + -- + -- We defined RSA keys from the modules in RFC 3279 and RFC 4055. + -- + + scap-pk-rsa SMIME-CAPS ::= { + TYPE RSAKeyCapabilities + IDENTIFIED BY pk-rsa.&id + } + + RSAKeyCapabilities ::= SEQUENCE { + minKeySize RSAKeySize, + maxKeySize RSAKeySize OPTIONAL + } + + RSAKeySize ::= INTEGER (1024 | 2048 | 3072 | 4096 | 7680 | + 8192 | 15360, ...) + + + scap-pk-rsaES-OAEP SMIME-CAPS ::= { + TYPE RSAKeyCapabilities + IDENTIFIED BY pk-rsaES-OAEP.&id + } + + scap-pk-rsaSSA-PSS SMIME-CAPS ::= { + TYPE RSAKeyCapabilities + IDENTIFIED BY pk-rsaSSA-PSS.&id + } + + scap-sa-rsaSSA-PSS SMIME-CAPS ::= { + TYPE RsaSsa-Pss-sig-caps + IDENTIFIED BY sa-rsaSSA-PSS.&id + } + + RsaSsa-Pss-sig-caps ::= SEQUENCE { + hashAlg SMIMECapability{{ MaskAlgorithmSet }}, + maskAlg SMIMECapability{{ ... }} OPTIONAL, + trailerField INTEGER DEFAULT 1 + } + + scap-mf-mgf1 SMIME-CAPS ::= { + TYPE SMIMECapability{{ ... }} + IDENTIFIED BY id-mgf1 + } + + MaskAlgorithmSet SMIME-CAPS ::= {scap-mf-mgf1, ...} + + + + +Schaad Informational [Page 16] + +RFC 6664 S/MIME Capabilities for Public Keys July 2012 + + + -- + -- We define DH/DSA keys from the module in RFC 3279. + -- + + scap-pk-dsa SMIME-CAPS ::= { + TYPE DSAKeyCapabilities + IDENTIFIED BY pk-dsa.&id + } + + DSAKeyCapabilities ::= CHOICE { + keySizes [0] SEQUENCE { + minKeySize DSAKeySize, + maxKeySize DSAKeySize OPTIONAL, + maxSizeP [1] INTEGER OPTIONAL, + maxSizeQ [2] INTEGER OPTIONAL, + maxSizeG [3] INTEGER OPTIONAL + }, + keyParams [1] pk-dsa.&Params + } + + DSAKeySize ::= INTEGER (1024 | 2048 | 3072 | 7680 | 15360 ) + + scap-pk-dh SMIME-CAPS ::= { + TYPE DSAKeyCapabilities + IDENTIFIED BY pk-dh.&id + } + + -- + -- We define Elliptic Curve keys from the module in RFC 3279. + -- + + scap-pk-ec SMIME-CAPS ::= { + TYPE EC-SMimeCaps + IDENTIFIED BY pk-ec.&id + } + + EC-SMimeCaps ::= SEQUENCE (SIZE (1..MAX)) OF ECParameters + + scap-pk-ecDH SMIME-CAPS ::= { + TYPE EC-SMimeCaps + IDENTIFIED BY pk-ecDH.&id + } + + scap-pk-ecMQV SMIME-CAPS ::= { + TYPE EC-SMimeCaps + IDENTIFIED BY pk-ecMQV.&id + } + + + + +Schaad Informational [Page 17] + +RFC 6664 S/MIME Capabilities for Public Keys July 2012 + + + END + +Appendix B. 1988 ASN.1 Module + + This appendix contains the normative ASN.1 module for this document. + + PUBLIC-KEY-SMIME-CAPABILITIES-88 + { iso(1) identified-organization(3) dod(6) internet(1) + security(5) mechanisms(5) pkix(7) id-mod(0) + id-mod-pubKeySMIMECaps-88(77) } + DEFINITIONS ::= + BEGIN + IMPORTS + + ECParameters + FROM PKIX1Algorithms2008 + { iso(1) identified-organization(3) dod(6) + internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) + 45 } + + id-mgf1 + FROM PKIX1-PSS-OAEP-Algorithms + { iso(1) identified-organization(3) dod(6) + internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) + id-mod-pkix1-rsa-pkalgs(33) } + + AlgorithmIdentifier + FROM PKIX1Explicit88 + { iso(1) identified-organization(3) dod(6) internet(1) + security(5) mechanisms(5) pkix(7) id-mod(0) + id-pkix1-explicit(18) } + + ; + + -- + -- We define RSA keys from the modules in RFC 3279 and RFC 4055. + -- + + RSAKeyCapabilities ::= SEQUENCE { + minKeySize RSAKeySize, + maxKeySize RSAKeySize OPTIONAL + } + + RSAKeySize ::= INTEGER (1024 | 2048 | 3072 | 4096 | 7680 | + 8192 | 15360, ...) + + + RsaSsa-Pss-sig-caps ::= SEQUENCE { + + + +Schaad Informational [Page 18] + +RFC 6664 S/MIME Capabilities for Public Keys July 2012 + + + hashAlg AlgorithmIdentifier, + maskAlg AlgorithmIdentifier OPTIONAL, + trailerField INTEGER DEFAULT 1 + } + + -- + -- We define DH/DSA keys from the module in RFC 3279. + -- + + DSAKeyCapabilities ::= CHOICE { + keySizes [0] SEQUENCE { + minKeySize DSAKeySize, + maxKeySize DSAKeySize OPTIONAL, + maxSizeP [1] INTEGER OPTIONAL, + maxSizeQ [2] INTEGER OPTIONAL, + maxSizeG [3] INTEGER OPTIONAL + }, + keyParams [1] pk-dsa.&Params + } + + DSAKeySize ::= INTEGER (1024 | 2048 | 3072 | 7680 | 15360 ) + + -- + -- We define Elliptic Curve keys from the module in RFC 3279. + -- + + EC-SMimeCaps ::= SEQUENCE (SIZE (1..MAX)) OF ECParameters + + END + +Appendix C. Future Work + + A future revision of [RFC5912] should be done at some point to expand + the definition of the PUBLIC-KEY class and allow for an + SMIMECapability to be included in the class definition. This would + encourage people to think about this as an issue when defining new + public key structures in the future. + +Author's Address + + Jim Schaad + Soaring Hawk Consulting + + EMail: ietf@augustcellars.com + + + + + + + +Schaad Informational [Page 19] + -- cgit v1.2.3