Internet DRAFT - draft-ietf-pkix-pubkey-caps

draft-ietf-pkix-pubkey-caps






Network Working Group                                          J. Schaad
Internet-Draft                                   Soaring Hawk Consulting
Intended status: Informational                              May 15, 2012
Expires: November 16, 2012


             S/MIME Capabilities for Public Key Definitions
                     draft-ietf-pkix-pubkey-caps-07

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.  An
   example of where this is used is is detailed in Online Certificate
   Status Protocol Algorithm Agility (RFC 6277).

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on November 16, 2012.

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



Schaad                  Expires November 16, 2012               [Page 1]

Internet-Draft                 PubKey Caps                      May 2012


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  ASN.1 Notation . . . . . . . . . . . . . . . . . . . . . .  3
     1.2.  Requirements Terminology . . . . . . . . . . . . . . . . .  4
   2.  RSA Public Keys  . . . . . . . . . . . . . . . . . . . . . . .  5
     2.1.  Generic RSA Public Keys  . . . . . . . . . . . . . . . . .  5
     2.2.  RSASSA-PSS Signature Public Keys . . . . . . . . . . . . .  6
     2.3.  RSAES-OAEP Key Transport Public Keys . . . . . . . . . . .  6
   3.  Diffie-Hellman Keys  . . . . . . . . . . . . . . . . . . . . .  8
     3.1.  DSA Signature Public Key . . . . . . . . . . . . . . . . .  8
     3.2.  DH Key Agreement Keys  . . . . . . . . . . . . . . . . . .  9
   4.  Elliptical Curve Keys  . . . . . . . . . . . . . . . . . . . . 10
     4.1.  Generic Elliptical Curve Keys  . . . . . . . . . . . . . . 10
     4.2.  Elliptical Curve DH Keys . . . . . . . . . . . . . . . . . 11
     4.3.  Elliptical Curve MQV Keys  . . . . . . . . . . . . . . . . 11
   5.  RSASSA-PSS Signature Algorithm Capability  . . . . . . . . . . 12
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 17
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 17
   Appendix A.  2008 ASN.1 Module . . . . . . . . . . . . . . . . . . 18
   Appendix B.  1988 ASN.1 Module . . . . . . . . . . . . . . . . . . 22
   Appendix C.  Future Work . . . . . . . . . . . . . . . . . . . . . 24
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25





















Schaad                  Expires November 16, 2012               [Page 2]

Internet-Draft                 PubKey Caps                      May 2012


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 where 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 object of restricting the set of values
   is that a client can use a simple binary comparison in order to check
   for equality.  The client should never need to decode the capability
   and do an element by element comparison.  Historically this has been
   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 identifer, 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 algoritm (in S/MIME), and was originally used in the PKCS#7
   specfication 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 the document because it directly represents the meta-data
   which 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 and the text is the normative module.
   In the event of a conflict between the contents of the two modules,



Schaad                  Expires November 16, 2012               [Page 3]

Internet-Draft                 PubKey Caps                      May 2012


   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 which says that only a single object can
      exist with a single object identifier.

   &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 upper case words TYPE IDENTIFIER and BY are
   syntactic sugar to make it easier to read.  The square brackets
   define optional pieces of the syntax.

   One of the things that can be done is to reference the fields of an
   object while defining other objects.  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 we automatically get any
   updates to values or types and we do not need to do any replication
   of 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].








Schaad                  Expires November 16, 2012               [Page 4]

Internet-Draft                 PubKey Caps                      May 2012


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 - Probablistic 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 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.

   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-CAP 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.




Schaad                  Expires November 16, 2012               [Page 5]

Internet-Draft                 PubKey Caps                      May 2012


   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 most of the time one will use the generic RSA public key
   identifier in a certificate, 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 set
   of algorithm parameters in the public key info structure, 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-CAP 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 most of the time one will use the generic RSA public key
   identifier in a certificate, the RSAES-OAEP identifier can be used if
   the owner of the key desires to restrict the usage of the key to just



Schaad                  Expires November 16, 2012               [Page 6]

Internet-Draft                 PubKey Caps                      May 2012


   this algorithm.  This algorithm does have the ability to place a set
   of algorithm parameters in the public key info structure, 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-CAP 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                  Expires November 16, 2012               [Page 7]

Internet-Draft                 PubKey Caps                      May 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-CAP 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:







Schaad                  Expires November 16, 2012               [Page 8]

Internet-Draft                 PubKey Caps                      May 2012


         minKeySize  contains the minimum length of the DSA modulus to
            be used.

         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 lenght 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 Elliptical Curve, however it is expected
         that usage of this field is 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-CAP object.  This object associates the
      existing object identifier (id-dh) used for the public key
      algorithm in the certificates (defined in [RFC3279] and [RFC5912])
      with a new type defined above, DSAKeyCapabilities.










Schaad                  Expires November 16, 2012               [Page 9]

Internet-Draft                 PubKey Caps                      May 2012


4.  Elliptical Curve Keys

   There are currently three Elliptical Curve Cryptography (ECC) public
   key object identifiers.  These are EC, EC-DH and Elliptical Curve
   Menezes-Qu-Vanstone (EC-MQV).

4.1.  Generic Elliptical 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 as
   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-CAP 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 can
      expected to be used.







Schaad                  Expires November 16, 2012              [Page 10]

Internet-Draft                 PubKey Caps                      May 2012


4.2.  Elliptical Curve DH Keys

   This public key type is used with the Elliptical 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-ec-dh  is a new SMIME-CAP 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.  Elliptical Curve MQV Keys

   This public key type is used with the Elliptical 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-ec-MQV  is a new SMIME-CAP object.  This object associates the
      existing object identifier (id-eqMQV) used for the public key
      algorithm in the certificate (defined in [RFC5480] and [RFC5912])
      with the same type structure used for public keys.














Schaad                  Expires November 16, 2012              [Page 11]

Internet-Draft                 PubKey Caps                      May 2012


5.  RSASSA-PSS Signature Algorithm Capability

   This document defines a new S/MIME Capability for the RSASSA-PSS
   signature algorithm.  There already exists one in [RFC4055] where the
   parameters field is not used.

   When the S/MIME group defined a 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
   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 accidently 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 S/MIME capability 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:







Schaad                  Expires November 16, 2012              [Page 12]

Internet-Draft                 PubKey Caps                      May 2012


   scap-sa-rsaSSA-PSS  is a new SMIME-CAP 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.

      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 the 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 back 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.






















Schaad                  Expires November 16, 2012              [Page 13]

Internet-Draft                 PubKey Caps                      May 2012


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 place in public key locations, signatures
   are placed in signature locations and S/MIME capabilities are placed
   in S/MIME Capability locations.  Failure to do so at best will create
   decode errors and at worst can cause incorrect behavior.

   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.

   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.  One should avoid
   being exhaustive in providing the list of algorithms to the recipient
   however.  The greater the number of algorithms that are passed the
   more difficult it is for a recipient to make intellegent decisions
   about which algorithm to be used.  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 is defined so that the order of algorithms in
   the sequence is meant to encode a preference order by the sender of



Schaad                  Expires November 16, 2012              [Page 14]

Internet-Draft                 PubKey Caps                      May 2012


   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.
















































Schaad                  Expires November 16, 2012              [Page 15]

Internet-Draft                 PubKey Caps                      May 2012


7.  IANA Considerations

   This document has no IANA considerations.
















































Schaad                  Expires November 16, 2012              [Page 16]

Internet-Draft                 PubKey Caps                      May 2012


8.  References

8.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.

8.2.  Informative References

   [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.

   [RFC4262]  Santesson, S., "X.509 Certificate Extension for Secure/
              Multipurpose Internet Mail Extensions (S/MIME)
              Capabilities", RFC 4262, December 2005.

   [SMIMEv3-MSG]
              Ramsdell, B., "S/MIME Version 3 Message Specification",
              RFC 2633, June 1999.

   [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                  Expires November 16, 2012              [Page 17]

Internet-Draft                 PubKey Caps                      May 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 capabilties 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                  Expires November 16, 2012              [Page 18]

Internet-Draft                 PubKey Caps                      May 2012


      }

      --
      --  We defined RSA keys from the modules RFC3279 and RFC4055
      --

      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                  Expires November 16, 2012              [Page 19]

Internet-Draft                 PubKey Caps                      May 2012


      --
      --  we define DH/DSA keys from the module RFC3279
      --

      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 Eliptical Curve keys from the module RFC3279
      --

      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                  Expires November 16, 2012              [Page 20]

Internet-Draft                 PubKey Caps                      May 2012


   END


















































Schaad                  Expires November 16, 2012              [Page 21]

Internet-Draft                 PubKey Caps                      May 2012


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 defined RSA keys from the modules RFC3279 and RFC4055
      --

      RSAKeyCapabilities ::= SEQUENCE {
         minKeySize        RSAKeySize,
         maxKeySize        RSAKeySize OPTIONAL
      }

      RSAKeySize ::= INTEGER (1024 | 2048 | 3072 | 4096 | 7680 |
                              8192 | 15360, ...)


      RsaSsa-Pss-sig-caps ::= SEQUENCE {
         hashAlg  AlgorithmIdentifier,
         maskAlg  AlgorithmIdentifier OPTIONAL,



Schaad                  Expires November 16, 2012              [Page 22]

Internet-Draft                 PubKey Caps                      May 2012


         trailerField INTEGER DEFAULT 1
      }

      --
      --  we define DH/DSA keys from the module RFC3279
      --

      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 Eliptical Curve keys from the module RFC3279
      --

      EC-SMimeCaps ::= SEQUENCE (SIZE (1..MAX)) OF ECParameters

   END
























Schaad                  Expires November 16, 2012              [Page 23]

Internet-Draft                 PubKey Caps                      May 2012


Appendix C.  Future Work

   A future revision of [RFC5912] should be done at some point which
   expands the definition of the PUBLIC-KEY class and allows for an
   S/MIME Capability 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.












































Schaad                  Expires November 16, 2012              [Page 24]

Internet-Draft                 PubKey Caps                      May 2012


Author's Address

   Jim Schaad
   Soaring Hawk Consulting

   Email: ietf@augustcellars.com













































Schaad                  Expires November 16, 2012              [Page 25]