<pre>Internet Engineering Task Force (IETF)                         S. Turner
Request for Comments: 6031                                          IECA
Category: Standards Track                                     R. Housley
ISSN: 2070-1721                                           Vigil Security
                                                           December 2010


 <span class="h1">Cryptographic Message Syntax (CMS) Symmetric Key Package Content Type</span>

Abstract

   This document defines the symmetric key format content type.  It is
   transport independent.  The Cryptographic Message Syntax (CMS) can be
   used to digitally sign, digest, authenticate, or encrypt this content
   type.

Status of This Memo

   This is an Internet Standards Track document.

   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).  Further information on
   Internet Standards is available in <a href="./rfc5741#section-2">Section&nbsp;2 of RFC 5741</a>.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   <a href="http://www.rfc-editor.org/info/rfc6031">http://www.rfc-editor.org/info/rfc6031</a>.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) 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.







<span class="grey">Turner &amp; Housley             Standards Track                    [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc6031">RFC 6031</a>         CMS Symmetric Key Package Content Type    December 2010</span>


Table of Contents

   <a href="#section-1">1</a>. Introduction...................................................<a href="#page-3">3</a>
      <a href="#section-1.1">1.1</a>. Requirements Terminology..................................<a href="#page-3">3</a>
      <a href="#section-1.2">1.2</a>. ASN.1 Syntax Notation.....................................<a href="#page-3">3</a>
   <a href="#section-2">2</a>. Symmetric Key Package Content Type.............................<a href="#page-3">3</a>
   <a href="#section-3">3</a>. PSKC Attributes................................................<a href="#page-4">4</a>
      <a href="#section-3.1">3.1</a>. PSKC Key Package Attributes...............................<a href="#page-5">5</a>
         <a href="#section-3.1.1">3.1.1</a>. Device Information Attributes........................<a href="#page-5">5</a>
         <a href="#section-3.1.2">3.1.2</a>. Cryptographic Module Information Attributes..........<a href="#page-8">8</a>
      <a href="#section-3.2">3.2</a>. PSKC Key Attributes.......................................<a href="#page-8">8</a>
         <a href="#section-3.2.1">3.2.1</a>. Key Identifier.......................................<a href="#page-8">8</a>
         <a href="#section-3.2.2">3.2.2</a>. Algorithm............................................<a href="#page-9">9</a>
         <a href="#section-3.2.3">3.2.3</a>. Issuer...............................................<a href="#page-9">9</a>
         <a href="#section-3.2.4">3.2.4</a>. Key Profile Identifier...............................<a href="#page-9">9</a>
         <a href="#section-3.2.5">3.2.5</a>. Key Reference Identifier.............................<a href="#page-9">9</a>
         <a href="#section-3.2.6">3.2.6</a>. Friendly Name.......................................<a href="#page-10">10</a>
         <a href="#section-3.2.7">3.2.7</a>. Algorithm Parameters................................<a href="#page-10">10</a>
         <a href="#section-3.2.8">3.2.8</a>. Counter.............................................<a href="#page-12">12</a>
         <a href="#section-3.2.9">3.2.9</a>. Time................................................<a href="#page-13">13</a>
         <a href="#section-3.2.10">3.2.10</a>. Time Interval......................................<a href="#page-13">13</a>
         <a href="#section-3.2.11">3.2.11</a>. Time Drift.........................................<a href="#page-13">13</a>
         <a href="#section-3.2.12">3.2.12</a>. Value MAC..........................................<a href="#page-13">13</a>
         <a href="#section-3.2.13">3.2.13</a>. Key User Id........................................<a href="#page-14">14</a>
      <a href="#section-3.3">3.3</a>. Key Policy Attributes....................................<a href="#page-14">14</a>
         <a href="#section-3.3.1">3.3.1</a>. Key Start Date......................................<a href="#page-14">14</a>
         <a href="#section-3.3.2">3.3.2</a>. Key Expiry Date.....................................<a href="#page-15">15</a>
         <a href="#section-3.3.3">3.3.3</a>. Number of Transactions..............................<a href="#page-15">15</a>
         <a href="#section-3.3.4">3.3.4</a>. Key Usage...........................................<a href="#page-15">15</a>
         <a href="#section-3.3.5">3.3.5</a>. PIN Policy..........................................<a href="#page-16">16</a>
   <a href="#section-4">4</a>. Key Encoding..................................................<a href="#page-18">18</a>
      <a href="#section-4.1">4.1</a>. AES Key Encoding.........................................<a href="#page-18">18</a>
      <a href="#section-4.2">4.2</a>. Triple-DES Key Encoding..................................<a href="#page-18">18</a>
   <a href="#section-5">5</a>. Security Considerations.......................................<a href="#page-19">19</a>
   <a href="#section-6">6</a>. IANA Considerations...........................................<a href="#page-19">19</a>
   <a href="#section-7">7</a>. References....................................................<a href="#page-19">19</a>
      <a href="#section-7.1">7.1</a>. Normative References.....................................<a href="#page-19">19</a>
      <a href="#section-7.2">7.2</a>. Informative References...................................<a href="#page-21">21</a>
   <a href="#appendix-A">Appendix A</a>. ASN.1 Module.........................................<a href="#page-22">22</a>
      <a href="#appendix-A.1">A.1</a>. Symmetric Key Package ASN.1 Module.......................<a href="#page-22">22</a>
      <a href="#appendix-A.2">A.2</a>. PSKC ASN.1 Module........................................<a href="#page-23">23</a>










<span class="grey">Turner &amp; Housley             Standards Track                    [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc6031">RFC 6031</a>         CMS Symmetric Key Package Content Type    December 2010</span>


<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Introduction</span>

   This document defines the symmetric key format content type.  It is
   transport independent.  The Cryptographic Message Syntax (CMS)
   [<a href="./rfc5652" title="&quot;Cryptographic Message Syntax (CMS)&quot;">RFC5652</a>] can be used to digitally sign, digest, authenticate, or
   encrypt this content type.

   The use cases that motivated the attributes in this work are
   elaborated in [<a href="./rfc6030" title="&quot;Portable Symmetric Key Container (PSKC)&quot;">RFC6030</a>].  They are omitted to avoid duplication.

   This document also includes ASN.1 definitions of the Extensible
   Markup Language (XML) element and attributes defined in [<a href="./rfc6030" title="&quot;Portable Symmetric Key Container (PSKC)&quot;">RFC6030</a>].

<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>.  Requirements Terminology</span>

   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 [<a href="./rfc2119" title="&quot;Key words for use in RFCs to Indicate Requirement Levels&quot;">RFC2119</a>].

<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>.  ASN.1 Syntax Notation</span>

   The key package is defined using the ASN.1 in [<a href="#ref-X.680">X.680</a>], [<a href="#ref-X.681">X.681</a>],
   [<a href="#ref-X.682">X.682</a>], and [<a href="#ref-X.683">X.683</a>].

<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  Symmetric Key Package Content Type</span>

   The symmetric key package content type is used to transfer one or
   more plaintext symmetric keys from one party to another.  A symmetric
   key package MAY be encapsulated in one or more CMS protecting content
   types.  This content type MUST be Distinguished Encoding Rules (DER)
   encoded [<a href="#ref-X.690">X.690</a>].

   The symmetric key package content type has the following syntax:

     ct-symmetric-key-package CONTENT-TYPE ::=
         { TYPE SymmetricKeyPackage IDENTIFIED BY id-ct-KP-sKeyPackage }

     id-ct-KP-sKeyPackage OBJECT IDENTIFIER ::=
        { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
          smime(16) ct(1) 25 }

     SymmetricKeyPackage ::= SEQUENCE {
       version           KeyPkgVersion DEFAULT v1,
       sKeyPkgAttrs  [0] SEQUENCE SIZE (1..MAX) OF Attribute
                                      {{ SKeyPkgAttributes }} OPTIONAL,
       sKeys             SymmetricKeys,
       ... }




<span class="grey">Turner &amp; Housley             Standards Track                    [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc6031">RFC 6031</a>         CMS Symmetric Key Package Content Type    December 2010</span>


     SymmetricKeys ::= SEQUENCE SIZE (1..MAX) OF OneSymmetricKey

     OneSymmetricKey ::= SEQUENCE {
       sKeyAttrs  SEQUENCE SIZE (1..MAX) OF Attribute
                                      {{ SKeyAttributes }}  OPTIONAL,
       sKey       OCTET STRING OPTIONAL }
       ( WITH COMPONENTS { ..., sKeyAttrs PRESENT } |
         WITH COMPONENTS { ..., sKey PRESENT } )

     KeyPkgVersion ::= INTEGER  { v1(1) } ( v1, ... )

   The SymmetricKeyPackage fields are used as follows:

   - version identifies the version of the symmetric key package content
     structure.  For this version of the specification, the default
     value, v1, MUST be used.

   - sKeyPkgAttrs optionally provides attributes that apply to all of
     the symmetric keys in the package.  The SKeyPkgAttributes
     information object set restricts the attributes allowed in
     sKeyPkgAttrs.  If an attribute appears here, then it MUST NOT also
     be included in sKeyAttrs.

   - sKeys contains a sequence of OneSymmetricKey values.  This
     structure is discussed below.

   The OneSymmetricKey fields are used as follows:

   - sKeyAttrs optionally provides attributes that apply to one
     symmetric key.  The SKeyAttributes information object set restricts
     the attributes permitted in sKeyAttrs.  If an attribute appears
     here, then it MUST NOT also be included in sKeyPkgAttrs.

   - sKey optionally contains the key value encoded as an OCTET STRING.

   The OneSymmetricKey field MUST include sKeyAttrs, sKey, or sKeyAttrs
   and sKey.

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  PSKC Attributes</span>

   The following attributes are defined to assist those using the
   symmetric key package defined in this document as part of a Dynamic
   Symmetric Key Provision Protocol (DSKPP) [<a href="./rfc6063" title="&quot;Dynamic Symmetric Key Provisioning Protocol (DSKPP)&quot;">RFC6063</a>] with Portable
   Symmetric Key Container (PSKC) attributes.  [<a href="./rfc6030" title="&quot;Portable Symmetric Key Container (PSKC)&quot;">RFC6030</a>] should be
   consulted for the definitive attribute descriptions.  The attributes
   fall into three categories.  The first category includes attributes
   that apply to a key package, and these attributes will generally
   appear in sKeyPkgAttrs.  The second category includes attributes that



<span class="grey">Turner &amp; Housley             Standards Track                    [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc6031">RFC 6031</a>         CMS Symmetric Key Package Content Type    December 2010</span>


   apply to a particular key, and these attributes will generally appear
   in sKeyAttrs.  The third category includes attributes that apply to a
   key policy.  Of the attributes defined, only the Key Identifier
   (<a href="#section-3.2.1">Section 3.2.1</a>) and Algorithm (<a href="#section-3.2.2">Section 3.2.2</a>) key attributes MUST be
   included.  All other attributes are OPTIONAL.

   Like PSKC, the Symmetric Key Content Type supports extensibility.
   Primarily, this is accomplished through the definition and inclusion
   of new attributes, but in some instances in which the attribute
   contains more than one type, the ASN.1 "..." extensibility mechanism
   is employed.

   A straightforward approach to conversion from XML types to ASN.1 is
   employed.  The &lt;xs:string&gt; type converts to UTF8String; the XML
   &lt;xs:dateTime&gt; type converts to GeneralizedTime; and the XML integer
   types convert to INTEGER or BinaryTime [<a href="./rfc6019" title="&quot;BinaryTime: An Alternate Format for Representing Date and Time in ASN.1&quot;">RFC6019</a>].

<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>.  PSKC Key Package Attributes</span>

   PSKC key package attributes apply to an entire key package.  These
   attributes can be categorized by two different attribute collections:
   device information and cryptographic module attributes.  All of these
   key package attributes are OPTIONAL.

<span class="h4"><a class="selflink" id="section-3.1.1" href="#section-3.1.1">3.1.1</a>.  Device Information Attributes</span>

   Device Information attributes, when taken together, MUST uniquely
   identify a device to which the Symmetric Key Package is provisioned.

<span class="h5"><a class="selflink" id="section-3.1.1.1" href="#section-3.1.1.1">3.1.1.1</a>.  Manufacturer</span>

   The Manufacturer attribute indicates the manufacturer of the device.
   Values for Manufacturer MUST be taken from either [<a href="#ref-OATHMAN" title="&quot;List of OATH Manufacturer Prefixes (omp)&quot;">OATHMAN</a>] prefixes
   (i.e., the left column) or from the IANA Private Enterprise Number
   Registry [<a href="#ref-IANAPENREG" title="&quot;Private Enterprise Numbers&quot;">IANAPENREG</a>], using the Organization value.  When the value
   is taken from [<a href="#ref-OATHMAN" title="&quot;List of OATH Manufacturer Prefixes (omp)&quot;">OATHMAN</a>] "oath." MUST be prepended to the value (e.g.,
   "oath.&lt;values from [<a href="#ref-OATHMAN" title="&quot;List of OATH Manufacturer Prefixes (omp)&quot;">OATHMAN</a>]&gt;").  When the value is taken from
   [<a href="#ref-IANAPENREG" title="&quot;Private Enterprise Numbers&quot;">IANAPENREG</a>], "iana." MUST be prepended to the value (e.g.,
   "iana.&lt;Organization value from [<a href="#ref-IANAPENREG" title="&quot;Private Enterprise Numbers&quot;">IANAPENREG</a>]&gt;").  The attribute
   definition is as follows:

   at-pskc-manufacturer ATTRIBUTE ::= {
     TYPE UTF8String IDENTIFIED BY id-pskc-manufacturer }

   id-pskc-manufacturer OBJECT IDENTIFIER ::= { id-pskc 1 }






<span class="grey">Turner &amp; Housley             Standards Track                    [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc6031">RFC 6031</a>         CMS Symmetric Key Package Content Type    December 2010</span>


<span class="h5"><a class="selflink" id="section-3.1.1.2" href="#section-3.1.1.2">3.1.1.2</a>.  Serial Number</span>

   The Serial Number attribute indicates the serial number of the
   device.  The attribute definition is as follows:

   at-pskc-serialNo ATTRIBUTE ::= {
     TYPE UTF8String IDENTIFIED BY id-pskc-serialNo }

   id-pskc-serialNo OBJECT IDENTIFIER ::= { id-pskc 2 }

<span class="h5"><a class="selflink" id="section-3.1.1.3" href="#section-3.1.1.3">3.1.1.3</a>.  Model</span>

   The Model attribute indicates the model of the device.  The attribute
   definition is as follows:

   at-pskc-model ATTRIBUTE ::= {
     TYPE UTF8String IDENTIFIED BY id-pskc-model }

   id-pskc-model OBJECT IDENTIFIER ::= { id-pskc 3 }

<span class="h5"><a class="selflink" id="section-3.1.1.4" href="#section-3.1.1.4">3.1.1.4</a>.  Issue Number</span>

   The Issue Number attribute contains an issue number to distinguish
   between two devices with the same serial number.  The attribute
   definition is as follows:

   at-pskc-issueNo ATTRIBUTE ::= {
     TYPE UTF8String IDENTIFIED BY id-pskc-issueNo }

   id-pskc-issueNo OBJECT IDENTIFIER ::= { id-pskc 4 }

<span class="h5"><a class="selflink" id="section-3.1.1.5" href="#section-3.1.1.5">3.1.1.5</a>.  Device Binding</span>

   The Device Binding attribute provides an opaque identifier that
   allows keys to be bound to the device or to a class of devices.

   When loading keys into a device, the attribute's value MUST be
   checked against information provided to the user via out-of-band
   mechanisms.  The implementation then ensures that the correct device
   or class of device is being used with respect to the provisioned key.

   at-pskc-deviceBinding ATTRIBUTE ::= {
     TYPE UTF8String IDENTIFIED BY id-pskc-deviceBinding }

   id-pskc-deviceBinding OBJECT IDENTIFIER ::= { id-pskc 5 }






<span class="grey">Turner &amp; Housley             Standards Track                    [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc6031">RFC 6031</a>         CMS Symmetric Key Package Content Type    December 2010</span>


<span class="h5"><a class="selflink" id="section-3.1.1.6" href="#section-3.1.1.6">3.1.1.6</a>.  Device Start Date</span>

   When included in sKeyPkgAttrs, the Device Start Date attribute
   indicates the start date for a device.  The date MUST be represented
   in a form that matches the dateTime production in "canonical
   representation" [<a href="#ref-XMLSCHEMA" title="&quot;XML Schema Part 2: Datatypes Second Edition&quot;">XMLSCHEMA</a>].  Implementations SHOULD NOT rely on time
   resolution finer than milliseconds and MUST NOT generate time
   instants that specify leap seconds.  Keys that are on the device
   SHOULD only be used when the current date is on or after the device
   start date.  The attribute definition is as follows:

   at-pskc-deviceStartDate ATTRIBUTE ::= {
     TYPE GeneralizedTime IDENTIFIED BY id-pskc-deviceStartDate }

   id-pskc-deviceStartDate OBJECT IDENTIFIER ::= { id-pskc 6 }

   Note that usage enforcement of the keys with respect to the dates MAY
   only happen on the validation server as some devices, such as smart
   cards, do not have an internal clock.  Systems thus SHOULD NOT rely
   upon the device to enforce key usage date restrictions.

<span class="h5"><a class="selflink" id="section-3.1.1.7" href="#section-3.1.1.7">3.1.1.7</a>.  Device Expiry Date</span>

   When included in sKeyPkgAttrs, the Device Expiry Date attribute
   indicates the expiry date for a device.  The date MUST be represented
   in a form that matches the dateTime production in "canonical
   representation" [<a href="#ref-XMLSCHEMA" title="&quot;XML Schema Part 2: Datatypes Second Edition&quot;">XMLSCHEMA</a>].  Implementations SHOULD NOT rely on time
   resolution finer than milliseconds and MUST NOT generate time
   instants that specify leap seconds.  Keys that are on the device
   SHOULD only be used when the current date is before the device expiry
   date.  The attribute definition is as follows:

   at-pskc-deviceExpiryDate ATTRIBUTE ::= {
     TYPE GeneralizedTime IDENTIFIED BY id-pskc-deviceExpiryDate }

   id-pskc-deviceExpiryDate OBJECT IDENTIFIER ::= { id-pskc 7 } Note
   that usage enforcement of the keys with respect to the dates MAY only
   happen on the validation server as some devices, such as smart cards,
   do not have an internal clock.  Systems thus SHOULD NOT rely upon the
   device to enforce key usage date restrictions.

<span class="h5"><a class="selflink" id="section-3.1.1.8" href="#section-3.1.1.8">3.1.1.8</a>.  Device User Id</span>

   The Device User Id attribute indicates the user with whom the device
   is associated using a distinguished name, as defined in [<a href="./rfc4514" title="&quot;Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names&quot;">RFC4514</a>].
   For example: UID=jsmith,DC=example,DC=net.  The attribute definition
   is as follows:




<span class="grey">Turner &amp; Housley             Standards Track                    [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc6031">RFC 6031</a>         CMS Symmetric Key Package Content Type    December 2010</span>


   at-pskc-deviceUserId ATTRIBUTE ::= {
     TYPE UTF8String IDENTIFIED BY id-pskc-deviceUserId }

   id-pskc-deviceUserId OBJECT IDENTIFIER ::= { id-pskc 26 }

   As specified in [<a href="./rfc6030" title="&quot;Portable Symmetric Key Container (PSKC)&quot;">RFC6030</a>], there are no semantics associated with
   this element, i.e., there are no checks enforcing that only a
   specific user can use this device.  As such, this element is for
   informational purposes only.

<span class="h4"><a class="selflink" id="section-3.1.2" href="#section-3.1.2">3.1.2</a>.  Cryptographic Module Information Attributes</span>

   Cryptographic Module attributes uniquely identify a cryptographic
   module.  This is useful when the device contains more than one
   cryptographic module.  At this time, only one attribute is defined.

<span class="h5"><a class="selflink" id="section-3.1.2.1" href="#section-3.1.2.1">3.1.2.1</a>.  Cryptographic Module Identifier</span>

   When included in sKeyPkgAttrs, the Cryptographic Module Identifier
   attribute uniquely identifies the cryptographic module to which the
   key is being or was provisioned.  The attribute definition is as
   follows:

   at-pskc-moduleId ATTRIBUTE ::= {
     TYPE UTF8String IDENTIFIED BY id-pskc-moduleId }

   id-pskc-moduleId OBJECT IDENTIFIER ::= { id-pskc 8 }

<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>.  PSKC Key Attributes</span>

   PSKC key attributes apply to a specific key.  As noted earlier, the
   Key Identifier (<a href="#section-3.2.1">Section 3.2.1</a>) and Algorithm (<a href="#section-3.2.2">Section 3.2.2</a>) key
   attributes are REQUIRED.  All other attributes are OPTIONAL.

<span class="h4"><a class="selflink" id="section-3.2.1" href="#section-3.2.1">3.2.1</a>.  Key Identifier</span>

   When included in sKeyAttrs, the Key Identifier attribute identifies
   the key in the context of key provisioning exchanges between two
   parties.  This means that if PSKC is used in multiple interactions
   between a sending and receiving party, using different containers
   referencing the same keys, the KeyId MUST use the same KeyId values
   (e.g., after initial provisioning, if a system wants to update key
   metadata values in the other system, the KeyId value of the key where
   the metadata is to be updates MUST be the same as the original KeyId
   value provisioned).  The attribute definition is as follows:






<span class="grey">Turner &amp; Housley             Standards Track                    [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc6031">RFC 6031</a>         CMS Symmetric Key Package Content Type    December 2010</span>


   at-pskc-keyId ATTRIBUTE ::= {
     TYPE UTF8String IDENTIFIED BY id-pskc-keyId }

   id-pskc-keyId OBJECT IDENTIFIER ::= { id-pskc 9 }

<span class="h4"><a class="selflink" id="section-3.2.2" href="#section-3.2.2">3.2.2</a>.  Algorithm</span>

   The Algorithm attribute uniquely identifies the PSKC algorithm
   profile.  [<a href="./rfc6030" title="&quot;Portable Symmetric Key Container (PSKC)&quot;">RFC6030</a>] defines two algorithm profiles "HOTP" and "PIN".
   The attribute definition is as follows:

   at-pskc-algorithm ATTRIBUTE ::= {
     TYPE UTF8String IDENTIFIED BY id-pskc-algorithm }

   id-pskc-algorithm OBJECT IDENTIFIER ::= { id-pskc 10 }

<span class="h4"><a class="selflink" id="section-3.2.3" href="#section-3.2.3">3.2.3</a>.  Issuer</span>

   The Issuer attribute names the entity that issued the key.  The
   attribute definition is as follows:

   at-pskc-issuer ATTRIBUTE ::= {
     TYPE UTF8String IDENTIFIED BY id-pskc-issuer }

   id-pskc-issuer OBJECT IDENTIFIER ::= { id-pskc 11 }

<span class="h4"><a class="selflink" id="section-3.2.4" href="#section-3.2.4">3.2.4</a>.  Key Profile Identifier</span>

   The Key Profile Identifier attribute carries a unique identifier used
   between the sending and receiving parties to establish a set of key
   attribute values that are not transmitted within the container but
   are agreed upon between the two parties out of band.  This attribute
   will then represent the unique reference to a set of key attribute
   values.

   at-pskc-keyProfileId ATTRIBUTE ::= {
     TYPE UTF8String IDENTIFIED BY id-pskc-keyProfileId }

   id-pskc-keyProfileId OBJECT IDENTIFIER ::= { id-pskc 12 }

<span class="h4"><a class="selflink" id="section-3.2.5" href="#section-3.2.5">3.2.5</a>.  Key Reference Identifier</span>

   The Key Reference attribute refers to an external key to be used with
   a key derivation scheme and no specific key value (secret) is
   transported; only the reference to the external master key is used
   (e.g., the PKCS #11 key label).





<span class="grey">Turner &amp; Housley             Standards Track                    [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc6031">RFC 6031</a>         CMS Symmetric Key Package Content Type    December 2010</span>


   at-pskc-keyReference ATTRIBUTE ::= {
     TYPE UTF8String IDENTIFIED BY id-pskc-keyReference }

   id-pskc-keyReference OBJECT IDENTIFIER ::= { id-pskc 13 }

<span class="h4"><a class="selflink" id="section-3.2.6" href="#section-3.2.6">3.2.6</a>.  Friendly Name</span>

   The Friendly Name attribute contains a human-readable name for the
   secret key.  The attribute definition is as follows:

   at-pskc-friendlyName ATTRIBUTE ::= {
     TYPE FriendlyName IDENTIFIED BY id-pskc-friendlyName }

   id-pskc-friendlyName OBJECT IDENTIFIER ::= { id-pskc 14 }

   The Friendly Name attribute has the following syntax:

   FriendlyName ::= SEQUENCE {
     friendlyName        UTF8String,
     friendlyNameLangTag UTF8String OPTIONAL }

   The text is encoded in UTF-8 [<a href="./rfc3629" title="&quot;UTF-8, a transformation format of ISO 10646&quot;">RFC3629</a>], which accommodates most of
   the world's writing systems.  The friendlyNameLangTag field
   identifies the language used to express the friendlyName.  When the
   friendlyNameLangTag field is absent, English, whose associated
   language tag is "en", is used.  The value of the friendlyNameLangTag
   field MUST be a language tag, as described in [<a href="./rfc5646" title="&quot;Tags for Identifying Languages&quot;">RFC5646</a>].

<span class="h4"><a class="selflink" id="section-3.2.7" href="#section-3.2.7">3.2.7</a>.  Algorithm Parameters</span>

   The Algorithm Parameters attribute contains parameters that influence
   the result of the algorithmic computation, for example, response
   truncation and format in One-Time Password (OTP) and
   Challenge/Response (CR) algorithms.

   at-pskc-algorithmParameters ATTRIBUTE ::= {
     TYPE PSKCAlgorithmParameters
     IDENTIFIED BY id-pskc-algorithmParams }

   id-pskc-algorithmParams OBJECT IDENTIFIER ::= { id-pskc 15 }

   The Algorithm Parameters attribute has the following syntax:

   PSKCAlgorithmParameters ::= CHOICE {
     suite                UTF8String,
     challengeFormat  [0] ChallengeFormat,
     responseFormat   [1] ResponseFormat,
     ... }



<span class="grey">Turner &amp; Housley             Standards Track                   [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc6031">RFC 6031</a>         CMS Symmetric Key Package Content Type    December 2010</span>


   ChallengeFormat ::= SEQUENCE {
     encoding    Encoding,
     checkDigit  BOOLEAN DEFAULT FALSE,
     min         INTEGER (0..MAX),
     max         INTEGER (0..MAX),
     ... }

   Encoding ::= UTF8STRING ("DECIMAL" | "HEXADECIMAL" |
                "ALPHANUMERIC" |"BASE64" |"BINARY")

   ResponseFormat ::= SEQUENCE {
     encoding     Encoding,
     length       INTEGER (0..MAX),
     checkDigit   BOOLEAN DEFAULT FALSE,
     ... }

   The fields in PSKCAlgorithmParameters have the following meanings:

   o Suite defines additional characteristics of the algorithm used,
     which are algorithm specific.  For example, in an HMAC-based
     (Hashed Message Authentication Code) OTP algorithm it could
     designate the strength of the hash algorithm used (SHA1, SHA256,
     etc.).  Please refer to the algorithm profile specification
     [<a href="./rfc6030" title="&quot;Portable Symmetric Key Container (PSKC)&quot;">RFC6030</a>] for the exact semantics of the value for each algorithm
     profile.

   o ChallengeFormat defines the characteristics of the challenge in a
     CR usage scenario, whereby the following fields are defined:

      o encoding specifies the encoding of the challenge accepted by the
        device and MUST be one of the following values: DECIMAL,
        HEXADECIMAL, ALPHANUMERIC, BASE64, or BINARY.  The BASE64
        encoding is done as in <a href="./rfc4648#section-4">Section&nbsp;4 of [RFC4648]</a>.

      o checkDigit indicates whether a device needs to check the
        appended Luhn check digit, as defined in [<a href="#ref-ISOIEC7812" title="&quot;ISO/IEC 7812-1:2006 Identification cards -- Identification of issuers -- Part 1: Numbering system&quot;">ISOIEC7812</a>], contained
        in a challenge.  The checkDigit MUST NOT be present if the
        encoding value is anything other than 'DECIMAL'.  A value of
        TRUE indicates that the device will check the appended Luhn
        check digit in a provided challenge.  A value of FALSE indicates
        that the device will not check the appended Luhn check digit in
        the challenge.









<span class="grey">Turner &amp; Housley             Standards Track                   [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc6031">RFC 6031</a>         CMS Symmetric Key Package Content Type    December 2010</span>


      o min defines the minimum size of the challenge accepted by the
        device for CR mode.  If encoding is 'DECIMAL', 'HEXADECIMAL', or
        'ALPHANUMERIC', this value indicates the minimum number of
        digits/characters.  If encoding is 'BASE64' or 'BINARY', this
        value indicates the minimum number of bytes of the unencoded
        value.

      o max defines the maximum size of the challenge accepted by the
        device for CR mode.  If encoding is 'DECIMAL', 'HEXADECIMAL', or
        'ALPHANUMERIC', this value indicates the maximum number of
        digits/characters.  If the encoding is 'BASE64' or 'BINARY',
        this value indicates the maximum number of bytes of the
        unencoded value.

   o ResponseFormat defines the characteristics of the result of a
     computation and defines the format of the OTP or the response to a
     challenge.  For cases where the key is a personal identification
     number (PIN) value, this element contains the format of the PIN
     itself (e.g., DECIMAL, length 4 for a 4 digit PIN).  The following
     fields are defined:

      o encoding specifies the encoding of the response generated by the
        device and MUST be one of the following values: DECIMAL,
        HEXADECIMAL, ALPHANUMERIC, BASE64, or BINARY.  BASE64 is defined
        as in <a href="./rfc4648#section-4">Section&nbsp;4 of [RFC4648]</a>.

      o length defines the length of the response generated by the
        device.  If encoding is 'DECIMAL', 'HEXADECIMAL', or
        'ALPHANUMERIC', this value indicates the number of
        digits/characters.  If encoding is 'BASE64' or 'BINARY', this
        value indicates the number of bytes of the unencoded value.

      o checkDigit indicates whether the device needs to append a Luhn
        check digit, as defined in [<a href="#ref-ISOIEC7812" title="&quot;ISO/IEC 7812-1:2006 Identification cards -- Identification of issuers -- Part 1: Numbering system&quot;">ISOIEC7812</a>], to the response.  This
        is only valid if the encoding attribute is 'DECIMAL'.  If the
        value is TRUE, then the device will append a Luhn check digit to
        the response.  If the value is FALSE, then the device will not
        append a Luhn check digit to the response.

<span class="h4"><a class="selflink" id="section-3.2.8" href="#section-3.2.8">3.2.8</a>.  Counter</span>

   The Counter attribute contains the event counter for event-based OTP
   algorithms.  The attribute definition is as follows:

   at-pskc-counter ATTRIBUTE ::= {
     TYPE INTEGER(0..MAX) IDENTIFIED BY id-pskc-counter }

   id-pskc-counter OBJECT IDENTIFIER ::= { id-pskc 16 }



<span class="grey">Turner &amp; Housley             Standards Track                   [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc6031">RFC 6031</a>         CMS Symmetric Key Package Content Type    December 2010</span>


<span class="h4"><a class="selflink" id="section-3.2.9" href="#section-3.2.9">3.2.9</a>.  Time</span>

   The Time attribute conveys the time for time-based OTP algorithms.
   If the Time Interval attribute is included, then this element carries
   the number of time intervals passed for a specific start point.  If
   the time interval is used, then this element carries the number of
   time intervals passed from a specific start point, normally it is
   algorithm dependent.  It uses the BinaryTime syntax from [<a href="./rfc6019" title="&quot;BinaryTime: An Alternate Format for Representing Date and Time in ASN.1&quot;">RFC6019</a>].
   The attribute definition is as follows:

   at-pskc-time ATTRIBUTE ::= {
     TYPE BinaryTime IDENTIFIED BY id-pskc-time }

   id-pskc-time OBJECT IDENTIFIER ::= { id-pskc 17 }

<span class="h4"><a class="selflink" id="section-3.2.10" href="#section-3.2.10">3.2.10</a>.  Time Interval</span>

   The Time Interval attribute conveys the time interval value for time-
   based OTP algorithms in seconds (e.g., a value of 30 for this would
   indicate a time interval of 30 seconds).  It is an integer.  The
   attribute definition is as follows:

   at-pskc-timeInterval ATTRIBUTE ::= {
     TYPE INTEGER (0..MAX) IDENTIFIED BY id-pskc-timeInterval }

   id-pskc-timeInterval OBJECT IDENTIFIER ::= { id-pskc 18 }

<span class="h4"><a class="selflink" id="section-3.2.11" href="#section-3.2.11">3.2.11</a>.  Time Drift</span>

   The Time Drift attribute contains the device clock drift value for
   time-based OTP algorithms.  It is an integer, either positive or
   negative, that indicates the number of time intervals that a
   validation server has established that the device clock drifted after
   the last successful authentication.  The attribute definition is as
   follows:

   at-pskc-timeDrift ATTRIBUTE ::= {
     TYPE INTEGER (0..MAX) IDENTIFIED BY id-pskc-timeDrift }

   id-pskc-timeDrift OBJECT IDENTIFIER ::= { id-pskc 19 }

<span class="h4"><a class="selflink" id="section-3.2.12" href="#section-3.2.12">3.2.12</a>.  Value MAC</span>

   The Value MAC attribute is a Message Authentication Code (MAC)
   generated from the encrypted value in the case that the encryption
   algorithm does not support integrity checks (e.g., AES-CBC does not
   provide integrity while AES Key Wrap with a message length indicator
   (MLI) does).  The attribute definition is as follows:



<span class="grey">Turner &amp; Housley             Standards Track                   [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc6031">RFC 6031</a>         CMS Symmetric Key Package Content Type    December 2010</span>


   at-pskc-valueMAC ATTRIBUTE ::= {
     TYPE ValueMac IDENTIFIED BY id-pskc-valueMAC }

   id-pskc-valueMAC OBJECT IDENTIFIER ::= { id-pskc 20 }

   ValueMac ::= SEQUENCE {
     macAlgorithm UTF8String,
     mac          UTF8String }

   The fields in ValueMac have the following meanings:

   o macAlgorithm identifies the MAC algorithm used to generate the
     value placed in digest.

   o mac is the base64-encoded, as specified in <a href="./rfc4648#section-4">Section&nbsp;4 of [RFC4648]</a>,
     mac value.

<span class="h4"><a class="selflink" id="section-3.2.13" href="#section-3.2.13">3.2.13</a>.  Key User Id</span>

   The Key User Id attribute indicates the user with whom the key is
   associated using a distinguished name, as defined in [<a href="./rfc4514" title="&quot;Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names&quot;">RFC4514</a>].  For
   example, UID=jsmith,DC=example,DC=net.  The attribute definition is
   as follows:

   at-pskc-keyUserId ATTRIBUTE ::= {
     TYPE UTF8String IDENTIFIED BY id-pskc-keyUserId }

   id-pskc-keyUserId OBJECT IDENTIFIER ::= { id-pskc 27 }

   As specified in [<a href="./rfc6030" title="&quot;Portable Symmetric Key Container (PSKC)&quot;">RFC6030</a>], there are no semantics associated with
   this element, i.e., there are no checks enforcing that only a
   specific user can use this key.  As such, this element is for
   informational purposes only.

<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>.  Key Policy Attributes</span>

   Key policy attributes indicate a policy that can be attached to a
   key.  These attributes are defined in the subsections that follow.

<span class="h4"><a class="selflink" id="section-3.3.1" href="#section-3.3.1">3.3.1</a>.  Key Start Date</span>

   When included in sKeyAttrs, the Key Start Date attribute indicates
   the start of the key's validity period.  The date MUST be represented
   in a form that matches the dateTime production in "canonical
   representation" [<a href="#ref-XMLSCHEMA" title="&quot;XML Schema Part 2: Datatypes Second Edition&quot;">XMLSCHEMA</a>].  Implementations SHOULD NOT rely on time
   resolution finer than milliseconds and MUST NOT generate time
   instants that specify leap seconds.  The attribute definition is as
   follows:



<span class="grey">Turner &amp; Housley             Standards Track                   [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc6031">RFC 6031</a>         CMS Symmetric Key Package Content Type    December 2010</span>


   at-pskc-keyStartDate ATTRIBUTE ::= {
       TYPE GeneralizedTime IDENTIFIED BY id-pskc-keyStartDate }

   id-pskc-keyStartDate OBJECT IDENTIFIER ::= { id-pskc 21 }

<span class="h4"><a class="selflink" id="section-3.3.2" href="#section-3.3.2">3.3.2</a>.  Key Expiry Date</span>

   When included in sKeyAttrs, the Key Expiry Date attribute indicates
   the end of the key's validity period.  The date MUST be represented
   in a form that matches the dateTime production in "canonical
   representation" [<a href="#ref-XMLSCHEMA" title="&quot;XML Schema Part 2: Datatypes Second Edition&quot;">XMLSCHEMA</a>].  Implementations SHOULD NOT rely on time
   resolution finer than milliseconds and MUST NOT generate time
   instants that specify leap seconds.  The attribute definition is as
   follows:

   at-pskc-keyExpiryDate ATTRIBUTE ::= {
     TYPE GeneralizedTime IDENTIFIED BY id-pskc-keyExpiryDate }

   id-pskc-keyExpiryDate OBJECT IDENTIFIER ::= { id-pskc 22 }

<span class="h4"><a class="selflink" id="section-3.3.3" href="#section-3.3.3">3.3.3</a>.  Number of Transactions</span>

   The Number of Transactions attribute indicates the maximum number of
   times a key carried within the package can be used.  When this
   element is omitted, there is no restriction regarding the number of
   times a key can be used.  The attribute definition is as follows:

   at-pskc-noOfTransactions ATTRIBUTE ::= {
     TYPE INTEGER (0..MAX) IDENTIFIED BY id-pskc-noOfTransactions }

   id-pskc-noOfTransactions OBJECT IDENTIFIER ::= { id-pskc 23 }

<span class="h4"><a class="selflink" id="section-3.3.4" href="#section-3.3.4">3.3.4</a>.  Key Usage</span>

   The Key Usage attribute constrains the intended usage of the key.
   The recipient MUST enforce the key usage.  The attribute definition
   is as follows:

   at-pskc-keyUsage ATTRIBUTE ::= {
     TYPE PSKCKeyUsages IDENTIFIED BY id-pskc-keyUsages }

   id-pskc-keyUsages OBJECT IDENTIFIER ::= { id-pskc 24 }

   PSKCKeyUsages ::= SEQUENCE OF PSKCKeyUsage

   PSKCKeyUsage ::= UTF8String ("OTP" | "CR" | "Encrypt" |
                    "Integrity" | "Verify" | "Unlock" | "Decrypt" |
                    "KeyWrap" | "Unwrap" | "Derive" | "Generate")



<span class="grey">Turner &amp; Housley             Standards Track                   [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc6031">RFC 6031</a>         CMS Symmetric Key Package Content Type    December 2010</span>


   The fields in PSKCKeyUsage have the following meanings:

   o OTP:  The key MUST only be used for OTP generation.

   o CR:  The key MUST only be used for Challenge/Response purposes.

   o Encrypt:  The key MUST only be used for data encryption purposes.

   o Integrity:  The key MUST only be used to generate a keyed message
     digest for data integrity or authentication purposes.

   o Verify:  The key MUST only be used to verify a keyed message digest
     for data integrity or authentication purposes (is the converse of
     Integrity).

   o Unlock:  The key MUST only be used for an inverse
     Challenge/Response in the case in which a user has locked the
     device by entering an incorrect PIN too many times (for devices
     with PIN-input capability).

   o Decrypt:  The key MUST only be used for data decryption purposes.

   o KeyWrap:  The key MUST only be used for key wrap purposes.

   o Unwrap:  The key MUST only be used for key unwrap purposes.

   o Derive:  The key MUST only be used with a key derivation function
     to derive a new key (see also Section 8.2.4 of [<a href="#ref-NIST800-57" title="&quot;NIST Special Publication 800-57, Recommendation for Key Management - Part 1: General (Revised)&quot;">NIST800-57</a>]).

   o Generate:  The key MUST only be used to generate a new key based on
     a random number and the previous value of the key (see also <a href="#section-8.1.5.2.1">Section</a>
     <a href="#section-8.1.5.2.1">8.1.5.2.1</a> of [<a href="#ref-NIST800-57" title="&quot;NIST Special Publication 800-57, Recommendation for Key Management - Part 1: General (Revised)&quot;">NIST800-57</a>]).

<span class="h4"><a class="selflink" id="section-3.3.5" href="#section-3.3.5">3.3.5</a>.  PIN Policy</span>

   The PIN Policy attribute allows policy about the PIN usage to be
   associated with the key.  The attribute definition is as follows:

   at-pskc-pinPolicy ATTRIBUTE ::= {
     TYPE PINPolicy IDENTIFIED BY id-pskc-pinPolicy }

   id-pskc-pinPolicy OBJECT IDENTIFIER ::= { id-pskc 25 }









<span class="grey">Turner &amp; Housley             Standards Track                   [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc6031">RFC 6031</a>         CMS Symmetric Key Package Content Type    December 2010</span>


   PINPolicy ::= SEQUENCE {
     pinKeyId          [0] UTF8String OPTIONAL,
     pinUsageMode      [1] PINUsageMode,
     maxFailedAttempts [2] INTEGER (0..MAX) OPTIONAL,
     minLength         [3] INTEGER (0..MAX) OPTIONAL,
     maxLength         [4] INTEGER (0..MAX) OPTIONAL,
     pinEncoding       [5] Encoding OPTIONAL }

   PINUsageMode ::= UTF8String ("Local" | "Prepend" | "Append" |
                    "Algorithmic")

   The fields in PIN Policy have the following meanings:

   o pinKeyId uniquely identifies the key held within this container
     that contains the value of the PIN that protects the key.

      o pinUsageMode indicates the way the PIN is used during the usage
        of the key.  The following values are defined in [<a href="./rfc6030" title="&quot;Portable Symmetric Key Container (PSKC)&quot;">RFC6030</a>]:
        Local, Prepend, Append, and Algorithmic.

   o maxFailedAttempts indicates the maximum number of times the PIN may
     be entered incorrectly before it MUST NOT be possible to use the
     key anymore (reasonable values are in the positive integer range of
     at least 2 and no more than 10).

   o minLength indicates the minimum length of a PIN that can be set to
     protect the associated key.  It MUST NOT be possible to set a PIN
     shorter than this value.  If pinEncoding is 'DECIMAL',
     'HEXADECIMAL', or 'ALPHANUMERIC', this value indicates the number
     of digits/ characters.  If pinEncoding is 'BASE64' or 'BINARY',
     this value indicates the number of bytes of the unencoded value.

   o maxLength indicates the maximum length of a PIN that can be set to
     protect this key.  It MUST NOT be possible to set a PIN longer than
     this value.  If pinEncoding is 'DECIMAL', 'HEXADECIMAL', or
     'ALPHANUMERIC', this value indicates the number of
     digits/characters.  If the pinEncoding is 'BASE64' or 'BINARY',
     this value indicates the number of bytes of the unencoded value.

   o pinEncoding is based on Encoding, which is defined in <a href="#section-3.2.7">Section</a>
     <a href="#section-3.2.7">3.2.7</a>, and specifies encoding of the PIN and MUST be one of the
     following values: DECIMAL, HEXADECIMAL, ALPHANUMERIC, BASE64, or
     BINARY.

   If pinUsageMode is set to "Local", then the device MUST enforce the
   restriction indicated in maxFailedAttempts, minLength, maxLength, and
   pinEncoding; otherwise, it MUST be enforced on the server side.




<span class="grey">Turner &amp; Housley             Standards Track                   [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc6031">RFC 6031</a>         CMS Symmetric Key Package Content Type    December 2010</span>


<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  Key Encoding</span>

   Two parties receiving the same key as an sKey OCTET STRING must make
   use of the key in exactly the same way in order to interoperate.  To
   ensure that this occurs, it is necessary to define a correspondence
   between the abstract syntax of sKey and the notation in the standard
   algorithm description that defines how the key is used.  The next
   sections establish that correspondence for the AES algorithm
   [<a href="#ref-FIPS197" title="&quot;FIPS Pub 197: Advanced Encryption Standard (AES)&quot;">FIPS197</a>] and the Triple Data Encryption Algorithm (TDEA or Triple
   DES) [<a href="#ref-SP800-67" title="&quot;NIST Special Publication 800-67 Version 1.1: Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher&quot;">SP800-67</a>].

<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>.  AES Key Encoding</span>

   [<a href="#ref-FIPS197" title="&quot;FIPS Pub 197: Advanced Encryption Standard (AES)&quot;">FIPS197</a>], Section 5.2, titled "Key Expansion", uses the input key as
   an array of bytes indexed starting at 0.  The first octet of sKey
   SHALL become the key byte in the AES, labeled index 0 in [<a href="#ref-FIPS197" title="&quot;FIPS Pub 197: Advanced Encryption Standard (AES)&quot;">FIPS197</a>];
   the succeeding octets of sKey SHALL become key bytes in AES, in
   increasing index order.

   Proper parsing and key load of the contents of sKey for AES SHALL be
   determined by using the following sKey OCTET STRING to generate and
   match the key expansion test vectors in [<a href="#ref-FIPS197" title="&quot;FIPS Pub 197: Advanced Encryption Standard (AES)&quot;">FIPS197</a>], <a href="#appendix-A">Appendix A</a>, for
   AES Cipher Key: 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c

     Tag Length Value
     04  16     2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c

<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>.  Triple-DES Key Encoding</span>

   A Triple-DES key consists of three keys for the cryptographic engine
   (Key1, Key2, and Key3) that are each 64 bits (56 key bits and 8
   parity bits); the three keys are also collectively referred to as a
   key bundle [<a href="#ref-SP800-67" title="&quot;NIST Special Publication 800-67 Version 1.1: Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher&quot;">SP800-67</a>].  A key bundle may employ either two or three
   independent keys.  When only two independent keys are employed
   (called two-key Triple DES), the same value is used for Key1 and
   Key3.

   Each key in a Triple-DES key bundle is expanded into a key schedule
   according to a procedure defined in [<a href="#ref-SP800-67" title="&quot;NIST Special Publication 800-67 Version 1.1: Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher&quot;">SP800-67</a>], <a href="#appendix-A">Appendix A</a>.  That
   procedure numbers the bits in the key from 1 to 64, with number 1
   being the leftmost, or most significant bit (MSB).  The first octet
   of sKey SHALL be bits 1 through 8 of Key1 with bit 1 being the MSB.
   The second octet of sKey SHALL be bits 9 through 16 of Key1, and so
   forth, so that the trailing octet of sKey SHALL be bits 57 through 64
   of Key3 (or Key2 for two-key Triple DES).






<span class="grey">Turner &amp; Housley             Standards Track                   [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc6031">RFC 6031</a>         CMS Symmetric Key Package Content Type    December 2010</span>


   Proper parsing and key load of the contents of sKey for Triple DES
   SHALL be determined by using the following sKey OCTET STRING to
   generate and match the key expansion test vectors in [<a href="#ref-SP800-67" title="&quot;NIST Special Publication 800-67 Version 1.1: Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher&quot;">SP800-67</a>],
   <a href="#appendix-B">Appendix B</a>, for the key bundle:

   Key1 = 0123456789ABCDEF

   Key2 = 23456789ABCDEF01

   Key3 = 456789ABCDEF0123

     Tag Length Value
     04  24     0123456789ABCDEF 23456789ABCDEF01 456789ABCDEF0123

<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  Security Considerations</span>

   Implementers of this protocol are strongly encouraged to consider
   generally accepted principles of secure key management when
   integrating this capability within an overall security architecture.

   The symmetric key package contents are not protected.  This content
   type can be combined with a security protocol to protect the contents
   of the package.  One possibility is to include this content type in
   place of a PSKC package in [<a href="./rfc6063" title="&quot;Dynamic Symmetric Key Provisioning Protocol (DSKPP)&quot;">RFC6063</a>] exchanges.  In this case, the
   algorithm requirements are found in those documents.  Another
   possibility is to encapsulate this content type in a CMS [<a href="./rfc5652" title="&quot;Cryptographic Message Syntax (CMS)&quot;">RFC5652</a>]
   protecting content type.

<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  IANA Considerations</span>

   This document makes use of object identifiers to identify a CMS
   content type (Appendix A.1), the ASN.1 version of the PSKC attributes
   (Appendix A.2), and the ASN.1 modules found in <a href="#appendix-A.1">Appendix A.1</a> and A.2.

   All OIDs are registered in an arc delegated by RSADSI to the SMIME
   Working Group.

<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>.  References</span>

<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>.  Normative References</span>

   [<a id="ref-FIPS197">FIPS197</a>]    National Institute of Standards.  "FIPS Pub 197:
                Advanced Encryption Standard (AES)", 26 November 2001.

   [<a id="ref-IANAPENREG">IANAPENREG</a>] IANA, "Private Enterprise Numbers",
                &lt;<a href="http://www.iana.org">http://www.iana.org</a>&gt;.





<span class="grey">Turner &amp; Housley             Standards Track                   [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc6031">RFC 6031</a>         CMS Symmetric Key Package Content Type    December 2010</span>


   [<a id="ref-ISOIEC7812">ISOIEC7812</a>] ISO, "ISO/IEC 7812-1:2006 Identification cards --
                Identification of issuers -- Part 1: Numbering system",
                October 2006, &lt;<a href="http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=39698">http://www.iso.org/iso/iso_catalogue/</a>
                <a href="http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=39698">catalogue_tc/catalogue_detail.htm?csnumber=39698</a>&gt;.

   [<a id="ref-OATHMAN">OATHMAN</a>]    OATH, "List of OATH Manufacturer Prefixes (omp)", April
                2009, &lt;<a href="http://www.openauthentication.org/oath-id/prefixes">http://www.openauthentication.org/</a>
                <a href="http://www.openauthentication.org/oath-id/prefixes">oath-id/prefixes</a>&gt;.

   [<a id="ref-RFC2119">RFC2119</a>]    Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.

   [<a id="ref-RFC3629">RFC3629</a>]    Yergeau, F., "UTF-8, a transformation format of ISO
                10646", STD 63, <a href="./rfc3629">RFC 3629</a>, November 2003.

   [<a id="ref-RFC4514">RFC4514</a>]    Zeilenga, K., Ed., "Lightweight Directory Access
                Protocol (LDAP): String Representation of Distinguished
                Names", <a href="./rfc4514">RFC 4514</a>, June 2006.

   [<a id="ref-RFC4648">RFC4648</a>]    Josefsson, S., "The Base16, Base32, and Base64 Data
                Encodings", <a href="./rfc4648">RFC 4648</a>, October 2006.

   [<a id="ref-RFC5646">RFC5646</a>]    Phillips, A., Ed., and M. Davis, Ed., "Tags for
                Identifying Languages", <a href="https://www.rfc-editor.org/bcp/bcp47">BCP 47</a>, <a href="./rfc5646">RFC 5646</a>, September
                2009.

   [<a id="ref-RFC5911">RFC5911</a>]    Hoffman, P. and J. Schaad, "New ASN.1 Modules for
                Cryptographic Message Syntax (CMS) and S/MIME", <a href="./rfc5911">RFC</a>
                <a href="./rfc5911">5911</a>, June 2010.

   [<a id="ref-RFC5912">RFC5912</a>]    Hoffman, P. and J. Schaad, "New ASN.1 Modules for the
                Public Key Infrastructure Using X.509 (PKIX)", <a href="./rfc5912">RFC 5912</a>,
                June 2010.

   [<a id="ref-RFC6019">RFC6019</a>]    Housley, R., "BinaryTime: An Alternate Format for
                Representing Date and Time in ASN.1", <a href="./rfc6019">RFC 6019</a>,
                September 2010.

   [<a id="ref-RFC6030">RFC6030</a>]    Hoyer, P., Pei, M., and S. Machani, "Portable Symmetric
                Key Container (PSKC)", <a href="./rfc6030">RFC 6030</a>, October 2010.

   [<a id="ref-SP800-67">SP800-67</a>]   National Institute of Standards and Technology, "NIST
                Special Publication 800-67 Version 1.1: Recommendation
                for the Triple Data Encryption Algorithm (TDEA) Block
                Cipher", NIST Special Publication 800-67, May 2008.






<span class="grey">Turner &amp; Housley             Standards Track                   [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc6031">RFC 6031</a>         CMS Symmetric Key Package Content Type    December 2010</span>


   [<a id="ref-X.680">X.680</a>]      ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-
                1:2002.  Information Technology - Abstract Syntax
                Notation One.

   [<a id="ref-X.681">X.681</a>]      ITU-T Recommendation X.681 (2002) | ISO/IEC 8824-
                2:2002.  Information Technology - Abstract Syntax
                Notation One: Information Object Specification.

   [<a id="ref-X.682">X.682</a>]      ITU-T Recommendation X.682 (2002) | ISO/IEC 8824-
                3:2002.  Information Technology - Abstract Syntax
                Notation One: Constraint Specification.

   [<a id="ref-X.683">X.683</a>]      ITU-T Recommendation X.683 (2002) | ISO/IEC 8824-
                4:2002.  Information Technology - Abstract Syntax
                Notation One: Parameterization of ASN.1 Specifications.

   [<a id="ref-X.690">X.690</a>]      ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-
                1:2002.  Information Technology - ASN.1 encoding rules:
                Specification of Basic Encoding Rules (BER), Canonical
                Encoding Rules (CER) and Distinguished Encoding Rules
                (DER).

   [<a id="ref-XMLSCHEMA">XMLSCHEMA</a>]  Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes
                Second Edition", World Wide Web Consortium
                Recommendation REC-xmlschema-2-20041082, October 2004,
                &lt;<a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028">http://www.w3.org/TR/2004/REC-xmlschema-2-20041028</a>&gt;.

<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>.  Informative References</span>

   [<a id="ref-NIST800-57">NIST800-57</a>] National Institute of Standards and Technology, "NIST
                Special Publication 800-57, Recommendation for Key
                Management - Part 1: General (Revised)", NIST Special
                Publication 800-57, March 2007.

   [<a id="ref-RFC5652">RFC5652</a>]    Housley, R., "Cryptographic Message Syntax (CMS)", STD
                70, <a href="./rfc5652">RFC 5652</a>, September 2009.

   [<a id="ref-RFC6063">RFC6063</a>]    Doherty, A., Pei, M., Machani, S., and M. Nystrom,
                "Dynamic Symmetric Key Provisioning Protocol (DSKPP)",
                <a href="./rfc6063">RFC 6063</a>, December 2010.











<span class="grey">Turner &amp; Housley             Standards Track                   [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc6031">RFC 6031</a>         CMS Symmetric Key Package Content Type    December 2010</span>


<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>.  ASN.1 Module</span>

   This appendix provides the normative ASN.1 definitions for the
   structures described in this specification using ASN.1 as defined in
   [<a href="#ref-X.680">X.680</a>], [<a href="#ref-X.681">X.681</a>], [<a href="#ref-X.682">X.682</a>], and [<a href="#ref-X.683">X.683</a>].

<span class="h3"><a class="selflink" id="appendix-A.1" href="#appendix-A.1">A.1</a>.  Symmetric Key Package ASN.1 Module</span>

   SymmetricKeyPackageModulev1
     { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
       smime(16) modules(0) id-mod-symmetricKeyPkgV1(33) }

   DEFINITIONS IMPLICIT TAGS ::=

   BEGIN

   -- EXPORTS ALL

   IMPORTS

   -- From New PKIX ASN.1 [<a href="./rfc5912" title="&quot;New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)&quot;">RFC5912</a>]

   ATTRIBUTE
     FROM PKIX-CommonTypes-2009
      { iso(1) identified-organization(3) dod(6) internet(1)
        security(5) mechanisms(5) pkix(7) id-mod(0)
        id-mod-pkixCommon-02(57) }

   -- From New SMIME ASN.1 [<a href="./rfc5911" title="&quot;New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME&quot;">RFC5911</a>]

   CONTENT-TYPE, Attribute{}
     FROM CryptographicMessageSyntax-2009
       { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
         smime(16) modules(0) id-mod-cms-2004-02(41) }

   ;

    ContentSet CONTENT-TYPE ::= {
       ct-symmetric-key-package,
       ... -- Expect additional content types --
     }

     ct-symmetric-key-package CONTENT-TYPE ::=
       { TYPE SymmetricKeyPackage IDENTIFIED BY id-ct-KP-sKeyPackage }

     id-ct-KP-sKeyPackage OBJECT IDENTIFIER ::=
       { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
         smime(16) ct(1) 25 }



<span class="grey">Turner &amp; Housley             Standards Track                   [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc6031">RFC 6031</a>         CMS Symmetric Key Package Content Type    December 2010</span>


     SymmetricKeyPackage ::= SEQUENCE {
       version           KeyPkgVersion DEFAULT v1,
       sKeyPkgAttrs  [0] SEQUENCE SIZE (1..MAX) OF Attribute
                                      {{ SKeyPkgAttributes }} OPTIONAL,
       sKeys             SymmetricKeys,
       ... }

     SymmetricKeys ::= SEQUENCE SIZE (1..MAX) OF OneSymmetricKey

     OneSymmetricKey ::= SEQUENCE {
       sKeyAttrs  SEQUENCE SIZE (1..MAX) OF Attribute
                                         {{ SKeyAttributes }} OPTIONAL,
       sKey       OCTET STRING OPTIONAL }
       ( WITH COMPONENTS { ..., sKeyAttrs PRESENT } |
         WITH COMPONENTS { ..., sKey PRESENT } )

     KeyPkgVersion ::= INTEGER  { v1(1) } ( v1, ... )

     SKeyPkgAttributes ATTRIBUTE ::= { ... }

     SKeyAttributes ATTRIBUTE ::= { ... }

   END

<span class="h3"><a class="selflink" id="appendix-A.2" href="#appendix-A.2">A.2</a>.  PSKC ASN.1 Module</span>

   PSKCAttributesModule
     { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
       smime(16) modules(0) id-mod-pskcAttributesModule(53) }

   DEFINITIONS IMPLICIT TAGS ::=

   BEGIN

   -- EXPORTS ALL

   IMPORTS

   -- From New PKIX ASN.1 [<a href="./rfc5912" title="&quot;New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)&quot;">RFC5912</a>]

   ATTRIBUTE
     FROM PKIX-CommonTypes-2009
      { iso(1) identified-organization(3) dod(6) internet(1)
        security(5) mechanisms(5) pkix(7) id-mod(0)
        id-mod-pkixCommon-02(57) }






<span class="grey">Turner &amp; Housley             Standards Track                   [Page 23]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-24" ></span>
<span class="grey"><a href="./rfc6031">RFC 6031</a>         CMS Symmetric Key Package Content Type    December 2010</span>


   -- From BinaryTime [<a href="./rfc6019" title="&quot;BinaryTime: An Alternate Format for Representing Date and Time in ASN.1&quot;">RFC6019</a>]

   BinaryTime
     FROM BinarySigningTimeModule
       { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
         smime(16) modules(0) id-mod-binarySigningTime(27) }

   -- From New SMIME ASN.1 [<a href="./rfc5911" title="&quot;New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME&quot;">RFC5911</a>]

   id-smime
     FROM SecureMimeMessageV3dot1-2009
       { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
         smime(16) modules(0) id-mod-msg-v3dot1-02(39) }

   ;

   --
   -- PSKC Attributes OIDs are taken from the SMIME Arc.
   --

   id-pskc OBJECT IDENTIFIER ::= { id-smime 12 }

   --
   -- Merge SKeyPKGAttributes to the set of attributes for sKeyPkgAttrs
   --

   SKeyPkgAttributes ATTRIBUTE ::= {
     at-pskc-manufacturer | at-pskc-serialNo | at-pskc-model |
     at-pskc-issueNo | at-pskc-deviceBinding |
     at-pskc-deviceStartDate | at-pskc-deviceExpiryDate |
     at-pskc-moduleId | at-pskc-deviceUserId, ... }

   --
   -- Merge SKeyAttributes to the set of attributes for sKeyAttrs
   --

   SKeyAttributes ATTRIBUTE ::= {
     at-pskc-keyId | at-pskc-algorithm | at-pskc-issuer |
     at-pskc-keyProfileId | at-pskc-keyReference |
     at-pskc-friendlyName | at-pskc-algorithmParameters |
     at-pskc-counter | at-pskc-time | at-pskc-timeInterval |
     at-pskc-timeDrift | at-pskc-valueMAC | at-pskc-keyUserId  |
     at-pskc-keyStartDate | at-pskc-keyExpiryDate |
     at-pskc-numberOfTransactions | at-pskc-keyUsage |
     at-pskc-pinPolicy, ... }

   at-pskc-manufacturer ATTRIBUTE ::= {
     TYPE UTF8String IDENTIFIED BY id-pskc-manufacturer }



<span class="grey">Turner &amp; Housley             Standards Track                   [Page 24]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-25" ></span>
<span class="grey"><a href="./rfc6031">RFC 6031</a>         CMS Symmetric Key Package Content Type    December 2010</span>


   id-pskc-manufacturer OBJECT IDENTIFIER ::= { id-pskc 1 }

   at-pskc-serialNo ATTRIBUTE ::= {
     TYPE UTF8String IDENTIFIED BY id-pskc-serialNo }

   id-pskc-serialNo OBJECT IDENTIFIER ::= { id-pskc 2 }

   at-pskc-model ATTRIBUTE ::= {
     TYPE UTF8String IDENTIFIED BY id-pskc-model }

   id-pskc-model OBJECT IDENTIFIER ::= { id-pskc 3 }

   at-pskc-issueNo ATTRIBUTE ::= {
     TYPE UTF8String IDENTIFIED BY id-pskc-issueNo }

   id-pskc-issueNo OBJECT IDENTIFIER ::= { id-pskc 4 }

   at-pskc-deviceBinding ATTRIBUTE ::= {
     TYPE UTF8String IDENTIFIED BY id-pskc-deviceBinding }

   id-pskc-deviceBinding OBJECT IDENTIFIER ::= { id-pskc 5 }

   at-pskc-deviceStartDate ATTRIBUTE ::= {
     TYPE GeneralizedTime IDENTIFIED BY id-pskc-deviceStartDate }

   id-pskc-deviceStartDate OBJECT IDENTIFIER ::= { id-pskc 6 }

   at-pskc-deviceExpiryDate ATTRIBUTE ::= {
     TYPE GeneralizedTime IDENTIFIED BY id-pskc-deviceExpiryDate }

   id-pskc-deviceExpiryDate OBJECT IDENTIFIER ::= { id-pskc 7 }

   at-pskc-moduleId ATTRIBUTE ::= {
     TYPE UTF8String IDENTIFIED BY id-pskc-moduleId }

   id-pskc-moduleId OBJECT IDENTIFIER ::= { id-pskc 8 }

   at-pskc-deviceUserId ATTRIBUTE ::= {
     TYPE UTF8String IDENTIFIED BY id-pskc-deviceUserId }

   id-pskc-deviceUserId OBJECT IDENTIFIER ::= { id-pskc 26 }

   at-pskc-keyId ATTRIBUTE ::= {
     TYPE UTF8String IDENTIFIED BY id-pskc-keyId }

   id-pskc-keyId OBJECT IDENTIFIER ::= { id-pskc 9 }





<span class="grey">Turner &amp; Housley             Standards Track                   [Page 25]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-26" ></span>
<span class="grey"><a href="./rfc6031">RFC 6031</a>         CMS Symmetric Key Package Content Type    December 2010</span>


   at-pskc-algorithm ATTRIBUTE ::= {
     TYPE UTF8String IDENTIFIED BY id-pskc-algorithm }

   id-pskc-algorithm OBJECT IDENTIFIER ::= { id-pskc 10 }

   at-pskc-issuer ATTRIBUTE ::= {
     TYPE UTF8String IDENTIFIED BY id-pskc-issuer }

   id-pskc-issuer OBJECT IDENTIFIER ::= { id-pskc 11 }

   at-pskc-keyProfileId ATTRIBUTE ::= {
     TYPE UTF8String IDENTIFIED BY id-pskc-keyProfileId }

   id-pskc-keyProfileId OBJECT IDENTIFIER ::= { id-pskc 12 }

   at-pskc-keyReference ATTRIBUTE ::= {
     TYPE UTF8String IDENTIFIED BY id-pskc-keyReference }

   id-pskc-keyReference OBJECT IDENTIFIER ::= { id-pskc 13 }

   at-pskc-friendlyName ATTRIBUTE ::= {
     TYPE FriendlyName IDENTIFIED BY id-pskc-friendlyName }

   id-pskc-friendlyName OBJECT IDENTIFIER ::= { id-pskc 14 }

   FriendlyName ::= SEQUENCE {
     friendlyName        UTF8String,
     friendlyNameLangTag UTF8String OPTIONAL }

   at-pskc-algorithmParameters ATTRIBUTE ::= {
     TYPE PSKCAlgorithmParameters
     IDENTIFIED BY id-pskc-algorithmParameters }

   id-pskc-algorithmParameters OBJECT IDENTIFIER ::= { id-pskc 15 }

   PSKCAlgorithmParameters ::= CHOICE {
     suite                UTF8String,
     challengeFormat  [0] ChallengeFormat,
     responseFormat   [1] ResponseFormat,
     ... }

   ChallengeFormat ::= SEQUENCE {
     encoding    Encoding,
     checkDigit  BOOLEAN DEFAULT FALSE,
     min         INTEGER (0..MAX),
     max         INTEGER (0..MAX),
     ... }




<span class="grey">Turner &amp; Housley             Standards Track                   [Page 26]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-27" ></span>
<span class="grey"><a href="./rfc6031">RFC 6031</a>         CMS Symmetric Key Package Content Type    December 2010</span>


   Encoding ::= UTF8String ("DECIMAL" | "HEXADECIMAL" |
                "ALPHANUMERIC" | "BASE64" | "BINARY" )

   ResponseFormat ::= SEQUENCE {
     encoding     Encoding,
     length       INTEGER (0..MAX),
     checkDigit   BOOLEAN DEFAULT FALSE,
     ... }

   at-pskc-counter ATTRIBUTE ::= {
     TYPE INTEGER (0..MAX) IDENTIFIED BY id-pskc-counter }

   id-pskc-counter OBJECT IDENTIFIER ::= { id-pskc 16 }

   at-pskc-time ATTRIBUTE ::= {
     TYPE BinaryTime IDENTIFIED BY id-pskc-time }

   id-pskc-time OBJECT IDENTIFIER ::= { id-pskc 17 }

   at-pskc-timeInterval ATTRIBUTE ::= {
     TYPE INTEGER (0..MAX) IDENTIFIED BY id-pskc-timeInterval }

   id-pskc-timeInterval OBJECT IDENTIFIER ::= { id-pskc 18 }

   at-pskc-timeDrift ATTRIBUTE ::= {
     TYPE INTEGER (0..MAX) IDENTIFIED BY id-pskc-timeDrift }

   id-pskc-timeDrift OBJECT IDENTIFIER ::= { id-pskc 19 }

   at-pskc-valueMAC ATTRIBUTE ::= {
     TYPE ValueMac IDENTIFIED BY id-pskc-valueMAC }

   id-pskc-valueMAC OBJECT IDENTIFIER ::= { id-pskc 20 }

   ValueMac ::= SEQUENCE {
     macAlgorithm UTF8String,
     mac          UTF8String }

   at-pskc-keyUserId ATTRIBUTE ::= {
     TYPE UTF8String IDENTIFIED BY id-pskc-keyUserId }

   id-pskc-keyUserId OBJECT IDENTIFIER ::= { id-pskc 27 }

   at-pskc-keyStartDate ATTRIBUTE ::= {
     TYPE GeneralizedTime IDENTIFIED BY id-pskc-keyStartDate }

   id-pskc-keyStartDate OBJECT IDENTIFIER ::= { id-pskc 21 }




<span class="grey">Turner &amp; Housley             Standards Track                   [Page 27]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-28" ></span>
<span class="grey"><a href="./rfc6031">RFC 6031</a>         CMS Symmetric Key Package Content Type    December 2010</span>


   at-pskc-keyExpiryDate ATTRIBUTE ::= {
     TYPE GeneralizedTime IDENTIFIED BY id-pskc-keyExpiryDate }

   id-pskc-keyExpiryDate OBJECT IDENTIFIER ::= { id-pskc 22 }

   at-pskc-numberOfTransactions ATTRIBUTE ::= {
     TYPE INTEGER (0..MAX) IDENTIFIED BY id-pskc-numberOfTransactions }

   id-pskc-numberOfTransactions OBJECT IDENTIFIER ::= { id-pskc 23 }

   at-pskc-keyUsage ATTRIBUTE ::= {
     TYPE PSKCKeyUsages IDENTIFIED BY id-pskc-keyUsages }

   id-pskc-keyUsages OBJECT IDENTIFIER ::= { id-pskc 24 }

   PSKCKeyUsages ::= SEQUENCE OF PSKCKeyUsage

   PSKCKeyUsage ::= UTF8String ("OTP" | "CR" | "Encrypt" |
                    "Integrity" | "Verify" | "Unlock" | "Decrypt" |
                    "KeyWrap" | "Unwrap" | "Derive" | "Generate")

   at-pskc-pinPolicy ATTRIBUTE ::= {
     TYPE PINPolicy IDENTIFIED BY id-pskc-pinPolicy }

   id-pskc-pinPolicy OBJECT IDENTIFIER ::= { id-pskc 25 }

   PINPolicy ::= SEQUENCE {
     pinKeyId          [0] UTF8String OPTIONAL,
     pinUsageMode      [1] PINUsageMode,
     maxFailedAttempts [2] INTEGER (0..MAX) OPTIONAL,
     minLength         [3] INTEGER (0..MAX) OPTIONAL,
     maxLength         [4] INTEGER (0..MAX) OPTIONAL,
     pinEncoding       [5] Encoding OPTIONAL }

   PINUsageMode ::= UTF8String ("Local" | "Prepend" | "Append"|
                    "Algorithmic")

   END













<span class="grey">Turner &amp; Housley             Standards Track                   [Page 28]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-29" ></span>
<span class="grey"><a href="./rfc6031">RFC 6031</a>         CMS Symmetric Key Package Content Type    December 2010</span>


Authors' Addresses

   Sean Turner
   IECA, Inc.
   3057 Nutley Street, Suite 106
   Fairfax, VA 22031
   USA

   EMail: turners@ieca.com


   Russell Housley
   Vigil Security, LLC
   918 Spring Knoll Drive
   Herndon, VA 20170
   USA

   EMail: housley@vigilsec.com

































Turner &amp; Housley             Standards Track                   [Page 29]
</pre>