summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6664.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6664.txt')
-rw-r--r--doc/rfc/rfc6664.txt1067
1 files changed, 1067 insertions, 0 deletions
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]
+