tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 6030

 
 
 

Portable Symmetric Key Container (PSKC)

Part 3 of 3, p. 38 to 58
Prev RFC Part

 


prevText      Top      Up      ToC       Page 38 
11.  XML Schema

   This section defines the XML schema for PSKC.

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
     xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc"
     xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
     xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
     targetNamespace="urn:ietf:params:xml:ns:keyprov:pskc"
     elementFormDefault="qualified"
     attributeFormDefault="unqualified">
     <xs:import namespace="http://www.w3.org/2000/09/xmldsig#"
          schemaLocation=
"http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/
          xmldsig-core-schema.xsd"/>
     <xs:import namespace="http://www.w3.org/2001/04/xmlenc#"
          schemaLocation=
"http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/xenc-schema.xsd"/>
     <xs:import namespace="http://www.w3.org/XML/1998/namespace"/>
     <xs:complexType name="KeyContainerType">
          <xs:sequence>
               <xs:element name="EncryptionKey"
                    type="ds:KeyInfoType" minOccurs="0"/>
               <xs:element name="MACMethod"
                    type="pskc:MACMethodType" minOccurs="0"/>
               <xs:element name="KeyPackage"
                    type="pskc:KeyPackageType" maxOccurs="unbounded"/>
               <xs:element name="Signature"
                    type="ds:SignatureType" minOccurs="0"/>
               <xs:element name="Extensions"
                    type="pskc:ExtensionsType"
                    minOccurs="0" maxOccurs="unbounded"/>
          </xs:sequence>
          <xs:attribute name="Version"
               type="pskc:VersionType" use="required"/>
          <xs:attribute name="Id"
               type="xs:ID" use="optional"/>
     </xs:complexType>
     <xs:simpleType name="VersionType" final="restriction">
          <xs:restriction base="xs:string">
               <xs:pattern value="\d{1,2}\.\d{1,3}"/>
          </xs:restriction>

Top      Up      ToC       Page 39 
     </xs:simpleType>
     <xs:complexType name="KeyType">
          <xs:sequence>
               <xs:element name="Issuer"
                    type="xs:string" minOccurs="0"/>
               <xs:element name="AlgorithmParameters"
                    type="pskc:AlgorithmParametersType"
                    minOccurs="0"/>
               <xs:element name="KeyProfileId"
                    type="xs:string" minOccurs="0"/>
               <xs:element name="KeyReference"
                    type="xs:string" minOccurs="0"/>
               <xs:element name="FriendlyName"
                    type="xs:string" minOccurs="0"/>
               <xs:element name="Data"
                    type="pskc:KeyDataType" minOccurs="0"/>
               <xs:element name="UserId"
                    type="xs:string" minOccurs="0"/>
               <xs:element name="Policy"
                    type="pskc:PolicyType" minOccurs="0"/>
               <xs:element name="Extensions"
                    type="pskc:ExtensionsType" minOccurs="0"
                    maxOccurs="unbounded"/>
          </xs:sequence>
          <xs:attribute name="Id"
               type="xs:string" use="required"/>
          <xs:attribute name="Algorithm"
               type="pskc:KeyAlgorithmType" use="optional"/>
     </xs:complexType>
     <xs:complexType name="PolicyType">
          <xs:sequence>
               <xs:element name="StartDate"
                    type="xs:dateTime" minOccurs="0"/>
               <xs:element name="ExpiryDate"
                    type="xs:dateTime" minOccurs="0"/>
               <xs:element name="PINPolicy"
                    type="pskc:PINPolicyType" minOccurs="0"/>
               <xs:element name="KeyUsage"
                    type="pskc:KeyUsageType"
                    minOccurs="0" maxOccurs="unbounded"/>
               <xs:element name="NumberOfTransactions"
                    type="xs:nonNegativeInteger" minOccurs="0"/>
               <xs:any namespace="##other"
                    minOccurs="0" maxOccurs="unbounded"/>
          </xs:sequence>
     </xs:complexType>
     <xs:complexType name="KeyDataType">
          <xs:sequence>

Top      Up      ToC       Page 40 
               <xs:element name="Secret"
                    type="pskc:binaryDataType" minOccurs="0"/>
               <xs:element name="Counter"
                    type="pskc:longDataType" minOccurs="0"/>
               <xs:element name="Time"
                    type="pskc:intDataType" minOccurs="0"/>
               <xs:element name="TimeInterval"
                    type="pskc:intDataType" minOccurs="0"/>
               <xs:element name="TimeDrift"
                    type="pskc:intDataType" minOccurs="0"/>
               <xs:any namespace="##other"
                    processContents="lax"
                    minOccurs="0" maxOccurs="unbounded"/>
          </xs:sequence>
     </xs:complexType>
     <xs:complexType name="binaryDataType">
          <xs:sequence>
               <xs:choice>
                    <xs:element name="PlainValue"
                         type="xs:base64Binary"/>
                    <xs:element name="EncryptedValue"
                         type="xenc:EncryptedDataType"/>
               </xs:choice>
               <xs:element name="ValueMAC"
                    type="xs:base64Binary" minOccurs="0"/>
          </xs:sequence>
     </xs:complexType>
     <xs:complexType name="intDataType">
          <xs:sequence>
               <xs:choice>
                    <xs:element name="PlainValue" type="xs:int"/>
                    <xs:element name="EncryptedValue"
                         type="xenc:EncryptedDataType"/>
               </xs:choice>
               <xs:element name="ValueMAC"
                    type="xs:base64Binary" minOccurs="0"/>
          </xs:sequence>
     </xs:complexType>
     <xs:complexType name="stringDataType">
          <xs:sequence>
               <xs:choice>
                    <xs:element name="PlainValue" type="xs:string"/>
                    <xs:element name="EncryptedValue"
                         type="xenc:EncryptedDataType"/>
               </xs:choice>
               <xs:element name="ValueMAC"
                    type="xs:base64Binary" minOccurs="0"/>
          </xs:sequence>

Top      Up      ToC       Page 41 
     </xs:complexType>
     <xs:complexType name="longDataType">
          <xs:sequence>
               <xs:choice>
                    <xs:element name="PlainValue" type="xs:long"/>
                    <xs:element name="EncryptedValue"
                         type="xenc:EncryptedDataType"/>
               </xs:choice>
               <xs:element name="ValueMAC"
                    type="xs:base64Binary" minOccurs="0"/>
          </xs:sequence>
     </xs:complexType>
     <xs:complexType name="PINPolicyType">
          <xs:attribute name="PINKeyId"
               type="xs:string" use="optional"/>
          <xs:attribute name="PINUsageMode"
               type="pskc:PINUsageModeType"/>
          <xs:attribute name="MaxFailedAttempts"
               type="xs:unsignedInt" use="optional"/>
          <xs:attribute name="MinLength"
               type="xs:unsignedInt" use="optional"/>
          <xs:attribute name="MaxLength"
               type="xs:unsignedInt" use="optional"/>
          <xs:attribute name="PINEncoding"
               type="pskc:ValueFormatType" use="optional"/>
          <xs:anyAttribute namespace="##other"/>
     </xs:complexType>
     <xs:simpleType name="PINUsageModeType">
          <xs:restriction base="xs:string">
               <xs:enumeration value="Local"/>
               <xs:enumeration value="Prepend"/>
               <xs:enumeration value="Append"/>
               <xs:enumeration value="Algorithmic"/>
          </xs:restriction>
     </xs:simpleType>
     <xs:simpleType name="KeyUsageType">
          <xs:restriction base="xs:string">
               <xs:enumeration value="OTP"/>
               <xs:enumeration value="CR"/>
               <xs:enumeration value="Encrypt"/>
               <xs:enumeration value="Integrity"/>
               <xs:enumeration value="Verify"/>
               <xs:enumeration value="Unlock"/>
               <xs:enumeration value="Decrypt"/>
               <xs:enumeration value="KeyWrap"/>
               <xs:enumeration value="Unwrap"/>
               <xs:enumeration value="Derive"/>
               <xs:enumeration value="Generate"/>

Top      Up      ToC       Page 42 
          </xs:restriction>
     </xs:simpleType>
     <xs:complexType name="DeviceInfoType">
          <xs:sequence>
               <xs:element name="Manufacturer"
                    type="xs:string" minOccurs="0"/>
               <xs:element name="SerialNo"
                    type="xs:string" minOccurs="0"/>
               <xs:element name="Model"
                    type="xs:string" minOccurs="0"/>
               <xs:element name="IssueNo"
                    type="xs:string" minOccurs="0"/>
               <xs:element name="DeviceBinding"
                    type="xs:string" minOccurs="0"/>
               <xs:element name="StartDate"
                    type="xs:dateTime" minOccurs="0"/>
               <xs:element name="ExpiryDate"
                    type="xs:dateTime" minOccurs="0"/>
               <xs:element name="UserId"
                    type="xs:string" minOccurs="0"/>
               <xs:element name="Extensions"
                    type="pskc:ExtensionsType" minOccurs="0"
                    maxOccurs="unbounded"/>
          </xs:sequence>
     </xs:complexType>
     <xs:complexType name="CryptoModuleInfoType">
          <xs:sequence>
               <xs:element name="Id" type="xs:string"/>
               <xs:element name="Extensions"
                    type="pskc:ExtensionsType" minOccurs="0"
                    maxOccurs="unbounded"/>
          </xs:sequence>
     </xs:complexType>
     <xs:complexType name="KeyPackageType">
          <xs:sequence>
               <xs:element name="DeviceInfo"
                    type="pskc:DeviceInfoType" minOccurs="0"/>
               <xs:element name="CryptoModuleInfo"
                    type="pskc:CryptoModuleInfoType" minOccurs="0"/>
               <xs:element name="Key"
                    type="pskc:KeyType" minOccurs="0"/>
               <xs:element name="Extensions"
                    type="pskc:ExtensionsType" minOccurs="0"
                    maxOccurs="unbounded"/>
          </xs:sequence>
     </xs:complexType>
     <xs:complexType name="AlgorithmParametersType">
          <xs:choice>

Top      Up      ToC       Page 43 
               <xs:element name="Suite" type="xs:string" minOccurs="0"/>
               <xs:element name="ChallengeFormat" minOccurs="0">
                    <xs:complexType>
                         <xs:attribute name="Encoding"
                              type="pskc:ValueFormatType"
                                                      use="required"/>
                         <xs:attribute name="Min"
                              type="xs:unsignedInt" use="required"/>
                         <xs:attribute name="Max"
                              type="xs:unsignedInt" use="required"/>
                         <xs:attribute name="CheckDigits"
                              type="xs:boolean" default="false"/>
                    </xs:complexType>
               </xs:element>
               <xs:element name="ResponseFormat" minOccurs="0">
                    <xs:complexType>
                         <xs:attribute name="Encoding"
                              type="pskc:ValueFormatType"
                                                      use="required"/>
                         <xs:attribute name="Length"
                              type="xs:unsignedInt" use="required"/>
                         <xs:attribute name="CheckDigits"
                              type="xs:boolean" default="false"/>
                    </xs:complexType>
               </xs:element>
               <xs:element name="Extensions"
                    type="pskc:ExtensionsType" minOccurs="0"
                    maxOccurs="unbounded"/>
          </xs:choice>
     </xs:complexType>
     <xs:complexType name="ExtensionsType">
          <xs:sequence>
               <xs:any namespace="##other"
                    processContents="lax" maxOccurs="unbounded"/>
          </xs:sequence>
          <xs:attribute name="definition"
               type="xs:anyURI" use="optional"/>
     </xs:complexType>
     <xs:simpleType name="KeyAlgorithmType">
          <xs:restriction base="xs:anyURI"/>
     </xs:simpleType>
     <xs:simpleType name="ValueFormatType">
          <xs:restriction base="xs:string">
               <xs:enumeration value="DECIMAL"/>
               <xs:enumeration value="HEXADECIMAL"/>
               <xs:enumeration value="ALPHANUMERIC"/>
               <xs:enumeration value="BASE64"/>
               <xs:enumeration value="BINARY"/>

Top      Up      ToC       Page 44 
          </xs:restriction>
     </xs:simpleType>
     <xs:complexType name="MACMethodType">
           <xs:sequence>
                  <xs:choice>
                        <xs:element name="MACKey"
              type="xenc:EncryptedDataType" minOccurs="0"/>
                        <xs:element name="MACKeyReference"
                                type="xs:string" minOccurs="0"/>
                        </xs:choice>
                        <xs:any namespace="##other"
           processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
       </xs:sequence>
       <xs:attribute name="Algorithm" type="xs:anyURI" use="required"/>
        </xs:complexType>
     <xs:element name="KeyContainer"
          type="pskc:KeyContainerType"/>
</xs:schema>

12.  IANA Considerations

12.1.  Content-Type Registration for 'application/pskc+xml'

   This specification contains the registration of a new media type
   according to the procedures of RFC 4288 [RFC4288] and guidelines in
   RFC 3023 [RFC3023].

   MIME media type name:  application

   MIME subtype name:  pskc+xml

   Required parameters:  There is no required parameter.

   Optional parameters:  charset

      Indicates the character encoding of enclosed XML.

   Encoding considerations:  Uses XML, which can employ 8-bit
      characters, depending on the character encoding used.  See RFC
      3023 [RFC3023], Section 3.2.

   Security considerations:  Please refer to Section 13 of RFC 6030.

   Interoperability considerations:  None

Top      Up      ToC       Page 45 
   Published specification:  RFC 6030.

   Applications which use this media type:  This media type is being
      used as a symmetric key container format for transport and
      provisioning of symmetric keys (One-Time Password (OTP) shared
      secrets or symmetric cryptographic keys) to different types of
      strong authentication devices.  As such, it is used for key
      provisioning systems.

   Additional information:

      Magic Number:  None

      File Extension:  .pskcxml

      Macintosh file type code:  'TEXT'

   Personal and email address to contact for further information:
      Philip Hoyer, Philip.Hoyer@actividentity.com

   Intended usage:  LIMITED USE

   Restrictions on usage:  None

   Author:  This specification is a work item of the IETF KEYPROV
      working group, with mailing list address <keyprov@ietf.org>.

   Change controller:  The IESG <iesg@ietf.org>

12.2.  XML Schema Registration

   This section registers an XML schema as per the guidelines in
   [RFC3688].

   URI:  urn:ietf:params:xml:schema:keyprov:pskc

   Registrant Contact:  IETF KEYPROV Working Group, Philip Hoyer
      (Philip.Hoyer@actividentity.com).

   XML Schema:  The XML schema to be registered is contained in
      Section 11.  Its first line is

   <?xml version="1.0" encoding="UTF-8"?>

   and its last line is

   </xs:schema>

Top      Up      ToC       Page 46 
12.3.  URN Sub-Namespace Registration

   This section registers a new XML namespace,
   "urn:ietf:params:xml:ns:keyprov:pskc", per the guidelines in
   [RFC3688].

   URI:  urn:ietf:params:xml:ns:keyprov:pskc

   Registrant Contact:  IETF KEYPROV Working Group, Philip Hoyer
      (Philip.Hoyer@actividentity.com).

   XML:

   BEGIN
   <?xml version="1.0"?>
   <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
     "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
   <html xmlns="http://www.w3.org/1999/xhtml">
   <head>
     <meta http-equiv="content-type"
           content="text/html;charset=iso-8859-1"/>
     <title>PSKC Namespace</title>
   </head>
   <body>
     <h1>Namespace for PSKC</h1>
     <h2>urn:ietf:params:xml:ns:keyprov:pskc</h2>
   <p>See <a href="http://www.rfc-editor.org/rfc/rfc6030.txt">
    RFC 6030</a>.</p>
   </body>
   </html>
   END

12.4.  PSKC Algorithm Profile Registry

   IANA has created a registry for PSKC algorithm profiles in accordance
   with the principles set out in RFC 5226 [RFC5226].

   As part of this registry, IANA maintains the following information:

   Common Name:  The name by which the PSKC algorithm profile is
      generally referred.

   Class:  The type of PSKC algorithm profile registry entry being
      created, such as encryption, Message Authentication Code (MAC),
      One-Time Password (OTP), Digest.

Top      Up      ToC       Page 47 
   URI:  The URI to be used to identify the profile.

   Identifier Definition:  IANA will add a pointer to the specification
      containing information about the PSKC algorithm profile
      registration.

   Algorithm Definition:  A reference to the stable document in which
      the algorithm being used with the PSKC is defined.

   Registrant Contact:  Contact information about the party submitting
      the registration request.

   Deprecated:  TRUE if this entry has been deprecated based on expert
      approval and SHOULD not be used in any new implementations.
      Otherwise, FALSE.

   PSKC Profiling:  Information about PSKC XML elements and attributes
      being used (or not) with this specific profile of PSKC.

   PSKC algorithm profile identifier registrations are to be subject to
   Specification Required as per RFC 5226 [RFC5226].  Updates can be
   provided based on expert approval only.  Based on expert approval, it
   is possible to mark entries as "deprecated".  A designated expert
   will be appointed by the IESG.

   IANA has added two initial values to the registry based on the
   algorithm profiles described in Section 10.

12.5.  PSKC Version Registry

   IANA has created a registry for PSKC version numbers.  The registry
   has the following structure:

     PSKC Version              | Specification
   +---------------------------+----------------
   | 1.0                       | RFC 6030

   Standards action is required to define new versions of PSKC.  It is
   not envisioned to deprecate, delete, or modify existing PSKC
   versions.

12.6.  Key Usage Registry

   IANA has created a registry for key usage.  A description of the
   <KeyUsage> element can be found in Section 5.

Top      Up      ToC       Page 48 
   As part of this registry IANA will maintain the following
   information:

    Key Usage:  The identifier of the Key Usage.

   Specification:  IANA will add a pointer to the specification
      containing information about the semantics of a new Key Usage
      registration.

   Deprecated:  TRUE if this entry has been deprecated based on expert
      approval and SHOULD not be used in any new implementations.
      Otherwise, FALSE.

   IANA has added these initial values to the registry:

     Key Usage     | Specification                | Deprecated
   +---------------+------------------------------+-----------
   | OTP           | [Section 5 of this document] | FALSE
   | CR            | [Section 5 of this document] | FALSE
   | Encrypt       | [Section 5 of this document] | FALSE
   | Integrity     | [Section 5 of this document] | FALSE
   | Verify        | [Section 5 of this document] | FALSE
   | Unlock        | [Section 5 of this document] | FALSE
   | Decrypt       | [Section 5 of this document] | FALSE
   | KeyWrap       | [Section 5 of this document] | FALSE
   | Unwrap        | [Section 5 of this document] | FALSE
   | Derive        | [Section 5 of this document] | FALSE
   | Generate      | [Section 5 of this document] | FALSE
   +---------------+------------------------------+-----------

   Key Usage Registry registrations are to be subject to Specification
   Required as per RFC 5226 [RFC5226].  Expert Review is required to
   define new Key Usage values.  Updates can be provided based on expert
   approval only.  Based on expert approval, it is possible to mark
   entries as "deprecated".  A designated expert will be appointed by
   the IESG.

13.  Security Considerations

   The portable symmetric key container (PSKC) carries sensitive
   information (e.g., cryptographic keys) and may be transported across
   the boundaries of one secure perimeter to another.  For example, a
   container residing within the secure perimeter of a back-end
   provisioning server in a secure room may be transported across the
   Internet to an end-user device attached to a personal computer.  This
   means that special care MUST be taken to ensure the confidentiality,
   integrity, and authenticity of the information contained within.

Top      Up      ToC       Page 49 
13.1.  PSKC Confidentiality

   By design, the container allows two main approaches to guaranteeing
   the confidentiality of the information it contains while transported.

   First, the container key data payload may be encrypted.

   In this case, no transport layer security is required.  However,
   standard security best practices apply when selecting the strength of
   the cryptographic algorithm for key data payload encryption.  A
   symmetric cryptographic cipher SHOULD be used -- the longer the
   cryptographic key, the stronger the protection.  Please see
   Section 6.1 for recommendations of key data payload protection using
   symmetric cryptographic ciphers.  In cases where the exchange of key
   encryption keys between the sender and the receiver is not possible,
   asymmetric encryption of the key data payload may be employed, see
   Section 6.3.  Similar to symmetric key cryptography, the stronger the
   asymmetric key, the more secure the protection.

   If the key data payload is encrypted with a method that uses one of
   the password-based encryption methods (PBE methods) detailed in
   Section 6.2, the key data payload may be subjected to password
   dictionary attacks to break the encryption password and recover the
   information.  Standard security best practices for selection of
   strong encryption passwords apply.

   Additionally, it is strongly RECOMMENDED that practical
   implementations use PBESalt and PBEIterationCount when PBE encryption
   is used.  A different PBESalt value per PSKC SHOULD be used for best
   protection.

   The second approach to protecting the confidentiality of the key data
   is based on using lower-layer security mechanisms (e.g., [TLS],
   [IPsec]).  The secure connection established between the source
   secure perimeter (the provisioning server from the example above) and
   the target perimeter (the device attached to the end-user computer)
   utilizes encryption to protect the messages that travel across that
   connection.  No key data payload encryption is required in this mode.
   Secure connections that encrypt and digest each message provide an
   extra measure of security.

   Because of the fact that the plaintext PSKC is protected only by the
   transport layer security, practical implementation MUST ensure
   protection against man-in-the-middle attacks.  Authenticating the
   secure channel endpoints is critically important for eliminating
   intruders that may compromise the confidentiality of the PSKC.

Top      Up      ToC       Page 50 
13.2.  PSKC Integrity

   The PSKC provides means to guarantee the integrity of the information
   it contains through the use of digital signatures.  It is RECOMMENDED
   that for best security practices, the digital signature of the
   container encompasses the entire PSKC.  This provides assurances for
   the integrity of all attributes.  It also allows verification of the
   integrity of a given PSKC even after the container is delivered
   through the communication channel to the target perimeter and channel
   message integrity check is no longer possible.

13.3.  PSKC Authenticity

   The digital signature of the PSKC is the primary way of showing its
   authenticity.  The recipient of the container SHOULD use the public
   key associated with the signature to assert the authenticity of the
   sender by tracing it back to a pre-loaded public key or certificate.
   Note that the digital signature of the PSKC can be checked even after
   the container has been delivered through the secure channel of
   communication.

   Authenticity guarantee may be provided by [TLS] or [IPsec].  However,
   no authenticity verification is possible once the container is
   delivered at the recipient end.  Since the TLS endpoints could differ
   from the key provisioning endpoints, this solution is weaker than the
   previous solution that relies on a digital signature of the PSKC.

14.  Contributors

   We would like Hannes Tschofenig for his text contributions to this
   document.

15.  Acknowledgements

   The authors of this document would like to thank the following people
   for their feedback: Apostol Vassilev, Shuh Chang, Jon Martinson,
   Siddhart Bajaj, Stu Vaeth, Kevin Lewis, Philip Hallam-Baker, Andrea
   Doherty, Magnus Nystrom, Tim Moses, Anders Rundgren, Sean Turner, and
   especially Robert Philpott.

   We would like to thank Sean Turner for his review in January 2009.
   We would also like to thank Anders Rundgren for triggering the
   discussion regarding to the selection of encryption algorithms
   (KW-AES-128 vs. AES-128-CBC) and his input on the keyed message
   digest computation.

Top      Up      ToC       Page 51 
   This work is based on earlier work by the members of OATH (Initiative
   for Open AuTHentication), see [OATH], to specify a format that can be
   freely distributed to the technical community.

16.  References

16.1.  Normative References

   [FIPS197]  National Institute of Standards, "FIPS Pub 197: Advanced
              Encryption Standard (AES)", November 2001.

   [HOTP]     M'Raihi, D., Bellare, M., Hoornaert, F., Naccache, D., and
              O. Ranen, "HOTP: An HMAC-Based One-Time Password
              Algorithm", RFC 4226, December 2005.

   [IANAPENREG]
              IANA, "Private Enterprise Numbers", <http://www.iana.org>.

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

   [OATHMAN]  OATH, "List of OATH Manufacturer Prefixes (omp)",
              April 2009,
              <http://www.openauthentication.org/oath-id/prefixes/>.

   [PKCS5]    RSA Laboratories, "PKCS #5: Password-Based Cryptography
              Standard", Version 2.0, March 1999,
              <http://www.rsasecurity.com/rsalabs/pkcs/>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3023]  Murata, M., St. Laurent, S., and D. Kohn, "XML Media
              Types", RFC 3023, January 2001.

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              January 2004.

   [RFC4288]  Freed, N. and J. Klensin, "Media Type Specifications and
              Registration Procedures", BCP 13, RFC 4288, December 2005.

   [RFC4514]  Zeilenga, K., "Lightweight Directory Access Protocol
              (LDAP): String Representation of Distinguished Names",
              RFC 4514, June 2006.

Top      Up      ToC       Page 52 
   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 4648, October 2006.

   [RFC5646]  Phillips, A. and M. Davis, "Tags for Identifying
              Languages", BCP 47, RFC 5646, September 2009.

   [RFC5649]  Housley, R. and M. Dworkin, "Advanced Encryption Standard
              (AES) Key Wrap with Padding Algorithm", RFC 5649,
              September 2009.

   [SP800-67]
              National Institute of Standards, "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.

   [W3C.REC-xmlschema-2-20041028]
              Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes
              Second Edition", World Wide Web Consortium
              Recommendation REC-xmlschema-2-20041028, October 2004,
              <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.

   [XMLDSIG]  Solo, D., Reagle, J., and D. Eastlake, "XML-Signature
              Syntax and Processing", World Wide Web Consortium
              FirstEdition REC-xmldsig-core-20020212, February 2002,
              <http://www.w3.org/TR/2002/REC-xmldsig-core-20020212>.

   [XMLENC]   Eastlake, D., "XML Encryption Syntax and Processing.",
              W3C Recommendation, December 2002,
              <http://www.w3.org/TR/xmlenc-core/>.

   [XMLENC11]
              Reagle, J. and D. Eastlake, "XML Encryption Syntax and
              Processing Version 1.1", World Wide Web Consortium WD WD-
              xmlenc-core1-20090730, July 2009,
              <http://www.w3.org/TR/2009/WD-xmlenc-core1-20090730>.

16.2.  Informative References

   [CAP]      MasterCard International, "Chip Authentication Program
              Functional Architecture", September 2004.

   [IPsec]    Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.

Top      Up      ToC       Page 53 
   [NIST800-57]
              Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid,
              "NIST Special Publication 800-57, Recommendation for Key
              Management Part 1: General (Revised)", NIST Special
              Publication 800-57, March 2007.

   [OATH]     "Initiative for Open AuTHentication",
              <http://www.openauthentication.org>.

   [PSKC-ALGORITHM-PROFILES]
              Hoyer, P., Pei, M., Machani, S., and A. Doherty,
              "Additional Portable Symmetric Key Container (PSKC)
              Algorithm Profiles", Work in Progress, May 2010.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, January 2005.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [TLS]      Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.

   [XMLNS]    Hollander, D., Bray, T., and A. Layman, "Namespaces in
              XML", World Wide Web Consortium FirstEdition REC-xml-
              names-19990114, January 1999,
              <http://www.w3.org/TR/1999/REC-xml-names-19990114>.

Top      Up      ToC       Page 54 
Appendix A.  Use Cases

   This section describes a comprehensive list of use cases that
   inspired the development of this specification.  These requirements
   were used to derive the primary requirement that drove the design.
   These requirements are covered in the next section.

   These use cases also help in understanding the applicability of this
   specification to real-world situations.

A.1.  Online Use Cases

   This section describes the use cases related to provisioning the keys
   using an online provisioning protocol.

A.1.1.  Transport of Keys from Server to Cryptographic Module

   For example, a mobile device user wants to obtain a symmetric key for
   use with a cryptographic module on the device.  The cryptographic
   module from vendor A initiates the provisioning process against a
   provisioning system from vendor B using a standards-based
   provisioning protocol.  The provisioning entity delivers one or more
   keys in a standard format that can be processed by the mobile device.

   For example, in a variation of the above, instead of the user's
   mobile phone, a key is provisioned in the user's soft token
   application on a laptop using a network-based online protocol.  As
   before, the provisioning system delivers a key in a standard format
   that can be processed by the soft token on the PC.

   For example, the end user or the key issuer wants to update or
   configure an existing key in the cryptographic module and requests a
   replacement key container.  The container may or may not include a
   new key and may include new or updated key attributes such as a new
   counter value in HOTP key case, a modified response format or length,
   a new friendly name, etc.

A.1.2.  Transport of Keys from Cryptographic Module to Cryptographic
        Module

   For example, a user wants to transport a key from one cryptographic
   module to another.  There may be two cryptographic modules, one on a
   computer and one on a mobile phone, and the user wants to transport a
   key from the computer to the mobile phone.  The user can export the
   key and related data in a standard format for input into the other
   cryptographic module.

Top      Up      ToC       Page 55 
A.1.3.  Transport of Keys from Cryptographic Module to Server

   For example, a user wants to activate and use a new key and related
   data against a validation system that is not aware of this key.  This
   key may be embedded in the cryptographic module (e.g., a Secure
   Digital (SD) card, USB drive) that the user has purchased at the
   local electronics retailer.  Along with the cryptographic module, the
   user may get the key on a CD or a floppy in a standard format.  The
   user can now upload via a secure online channel or import this key
   and related data into the new validation system and start using the
   key.

A.1.4.  Server-to-Server Bulk Import/Export of Keys

   From time to time, a key management system may be required to import
   or export keys in bulk from one entity to another.

   For example, instead of importing keys from a manufacturer using a
   file, a validation server may download the keys using an online
   protocol.  The keys can be downloaded in a standard format that can
   be processed by a validation system.

   For example, in a variation of the above, an Over-The-Air (OTA) key
   provisioning gateway that provisions keys to mobile phones may obtain
   key material from a key issuer using an online protocol.  The keys
   are delivered in a standard format that can be processed by the key
   provisioning gateway and subsequently sent to the mobile phone of the
   end user.

A.2.  Offline Use Cases

   This section describes the use cases relating to offline transport of
   keys from one system to another, using some form of export and import
   model.

A.2.1.  Server-to-Server Bulk Import/Export of Keys

   For example, cryptographic modules, such as OTP authentication
   tokens, may have their symmetric keys initialized during the
   manufacturing process in bulk, requiring copies of the keys and
   algorithm data to be loaded into the authentication system through a
   file on portable media.  The manufacturer provides the keys and
   related data in the form of a file containing records in standard
   format, typically on a CD.  Note that the token manufacturer and the
   vendor for the validation system may be the same or different.  Some
   crypto modules will allow local PIN management (the device will have
   a PIN pad); hence, random initial PINs set at manufacturing should be
   transmitted together with the respective keys they protect.

Top      Up      ToC       Page 56 
   For example, an enterprise wants to port keys and related data from
   an existing validation system A into a different validation system B.
   The existing validation system provides the enterprise with a
   functionality that enables export of keys and related data (e.g., for
   OTP authentication tokens) in a standard format.  Since the OTP
   tokens are in the standard format, the enterprise can import the
   token records into the new validation system B and start using the
   existing tokens.  Note that the vendors for the two validation
   systems may be the same or different.

Appendix B.  Requirements

   This section outlines the most relevant requirements that are the
   basis of this work.  Several of the requirements were derived from
   use cases described above.

   R1:   The format MUST support the transport of multiple types of
         symmetric keys and related attributes for algorithms including
         HOTP, other OTP, Challenge/Response, etc.

   R2:   The format MUST handle the symmetric key itself as well of
         attributes that are typically associated with symmetric keys.
         Some of these attributes may be

         *  Unique Key Identifier

         *  Issuer information

         *  Algorithm ID

         *  Algorithm mode

         *  Issuer Name

         *  Key friendly name

         *  Event counter value (moving factor for OTP algorithms)

         *  Time value

   R3:   The format SHOULD support both offline and online scenarios.
         That is, it should be serializable to a file as well as it
         should be possible to use this format in online provisioning
         protocols.

   R4:   The format SHOULD allow bulk representation of symmetric keys.

Top      Up      ToC       Page 57 
   R5:   The format SHOULD allow bulk representation of PINs related to
         specific keys.

   R6:   The format SHOULD be portable to various platforms.
         Furthermore, it SHOULD be computationally efficient to process.

   R7:   The format MUST provide an appropriate level of security in
         terms of data encryption and data integrity.

   R8:   For online scenarios, the format SHOULD NOT rely on transport
         layer security (e.g., Secure Socket Layer/Transport Layer
         Security (SSL/TLS)) for core security requirements.

   R9:   The format SHOULD be extensible.  It SHOULD enable extension
         points allowing vendors to specify additional attributes in the
         future.

   R10:  The format SHOULD allow for distribution of key derivation data
         without the actual symmetric key itself.  This is to support
         symmetric key management schemes that rely on key derivation
         algorithms based on a pre-placed master key.  The key
         derivation data typically consists of a reference to the key,
         rather than the key value itself.

   R11:  The format SHOULD allow for additional life cycle management
         operations such as counter resynchronization.  Such processes
         require confidentiality between client and server, thus could
         use a common secure container format, without the transfer of
         key material.

   R12:  The format MUST support the use of pre-shared symmetric keys to
         ensure confidentiality of sensitive data elements.

   R13:  The format MUST support a password-based encryption (PBE)
         [PKCS5] scheme to ensure security of sensitive data elements.
         This is a widely used method for various provisioning
         scenarios.

   R14:  The format SHOULD support asymmetric encryption algorithms such
         as RSA to ensure end-to-end security of sensitive data
         elements.  This is to support scenarios where a pre-set shared
         key encryption key is difficult to use.

Top      Up      ToC       Page 58 
Authors' Addresses

   Philip Hoyer
   ActivIdentity, Inc.
   117 Waterloo Road
   London, SE1  8UL
   UK

   Phone: +44 (0) 20 7960 0220
   EMail: phoyer@actividentity.com


   Mingliang Pei
   VeriSign, Inc.
   487 E. Middlefield Road
   Mountain View, CA  94043
   USA

   Phone: +1 650 426 5173
   EMail: mpei@verisign.com


   Salah Machani
   Diversinet, Inc.
   2225 Sheppard Avenue East
   Suite 1801
   Toronto, Ontario  M2J 5C2
   Canada

   Phone: +1 416 756 2324 Ext. 321
   EMail: smachani@diversinet.com