doc: Add RFC documents

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]
+