draft-ietf-keyprov-symmetrickeyformat-10.txt   draft-ietf-keyprov-symmetrickeyformat-11.txt 
KEYPROV Working Group Sean Turner KEYPROV Working Group Sean Turner
Internet Draft IECA Internet Draft IECA
Intended Status: Standards Track Russ Housley Intended Status: Standards Track Russ Housley
Expires: February 4, 2010 Vigil Security Expires: February 9, 2010 Vigil Security
August 4, 2010 August 9, 2010
Symmetric Key Package Content Type Symmetric Key Package Content Type
draft-ietf-keyprov-symmetrickeyformat-10.txt draft-ietf-keyprov-symmetrickeyformat-11.txt
Abstract Abstract
This document defines the symmetric key format content type. It is This document defines the symmetric key format content type. It is
transport independent. The Cryptographic Message Syntax can be used transport independent. The Cryptographic Message Syntax can be used
to digitally sign, digest, authenticate, or encrypt this content to digitally sign, digest, authenticate, or encrypt this content
type. type.
Status of this Memo Status of this Memo
skipping to change at page 1, line 39 skipping to change at page 1, line 39
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on February 4, 2010. This Internet-Draft will expire on February 9, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 25 skipping to change at page 2, line 25
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................3
1.1. Requirements Terminology..................................3 1.1. Requirements Terminology..................................3
1.2. ASN.1 Syntax Notation.....................................3 1.2. ASN.1 Syntax Notation.....................................3
2. Symmetric Key Package Content Type.............................3 2. Symmetric Key Package Content Type.............................3
3. PSKC Attributes................................................5 3. PSKC Attributes................................................5
3.1. PSKC Key Package Attributes...............................5 3.1. PSKC Key Package Attributes...............................5
3.1.1. Device Information Attributes........................5 3.1.1. Device Information Attributes........................5
3.1.2. Cryptographic Module Information Attributes..........8 3.1.2. Cryptographic Module Information Attributes..........8
3.2. PSKC Key Attributes.......................................9 3.2. PSKC Key Attributes.......................................8
3.2.1. Key Identifier.......................................9 3.2.1. Key Identifier.......................................9
3.2.2. Algorithm............................................9 3.2.2. Algorithm............................................9
3.2.3. Issuer...............................................9 3.2.3. Issuer...............................................9
3.2.4. Key Profile Identifier..............................10 3.2.4. Key Profile Identifier...............................9
3.2.5. Key Reference Identifier............................10 3.2.5. Key Reference Identifier............................10
3.2.6. Friendly Name.......................................10 3.2.6. Friendly Name.......................................10
3.2.7. Algorithm Parameters................................11 3.2.7. Algorithm Parameters................................10
3.2.8. Counter.............................................13 3.2.8. Counter.............................................13
3.2.9. Time................................................13 3.2.9. Time................................................13
3.2.10. Time Interval......................................13 3.2.10. Time Interval......................................13
3.2.11. Time Drift.........................................14 3.2.11. Time Drift.........................................13
3.2.12. Value MAC..........................................14 3.2.12. Value MAC..........................................14
3.2.13. Key User Id........................................14 3.2.13. Key User Id........................................14
3.3. Key Policy Attributes....................................15 3.3. Key Policy Attributes....................................15
3.3.1. Key Start Date......................................15 3.3.1. Key Start Date......................................15
3.3.2. Key Expiry Date.....................................15 3.3.2. Key Expiry Date.....................................15
3.3.3. Number of Transactions..............................16 3.3.3. Number of Transactions..............................15
3.3.4. Key Usage...........................................16 3.3.4. Key Usage...........................................16
3.3.5. PIN Policy..........................................17 3.3.5. PIN Policy..........................................17
4. Key Encoding..................................................18 4. Key Encoding..................................................18
4.1. AES Key Encoding.........................................18 4.1. AES Key Encoding.........................................18
4.2. Triple DES Key Encoding..................................19 4.2. Triple DES Key Encoding..................................18
5. Security Considerations.......................................19 5. Security Considerations.......................................19
6. IANA Considerations...........................................20 6. IANA Considerations...........................................19
7. References....................................................20 7. References....................................................20
7.1. Normative References.....................................20 7.1. Normative References.....................................20
7.2. Informative References...................................22 7.2. Informative References...................................22
APPENDIX A: ASN.1 Module.........................................22 APPENDIX A: ASN.1 Module.........................................22
A.1. Symmetric Key Package ASN.1 Module.......................22 A.1. Symmetric Key Package ASN.1 Module.......................22
A.2. PSKC ASN.1 Module........................................24 A.2. PSKC ASN.1 Module........................................24
1. Introduction 1. Introduction
This document defines the symmetric key format content type. It is This document defines the symmetric key format content type. It is
skipping to change at page 7, line 18 skipping to change at page 7, line 18
or class of device is being used with respect to the provisioned key. or class of device is being used with respect to the provisioned key.
at-pskc-deviceBinding ATTRIBUTE ::= { at-pskc-deviceBinding ATTRIBUTE ::= {
TYPE UTF8String IDENTIFIED BY id-pskc-deviceBinding } TYPE UTF8String IDENTIFIED BY id-pskc-deviceBinding }
id-pskc-deviceBinding OBJECT IDENTIFIER ::= { id-pskc 5 } id-pskc-deviceBinding OBJECT IDENTIFIER ::= { id-pskc 5 }
3.1.1.6. Device Start Date 3.1.1.6. Device Start Date
When included in sKeyPkgAttrs, the Device Start Date attribute When included in sKeyPkgAttrs, the Device Start Date attribute
indicates the start date for a device. The date MUST be represented indicates the start date for a device. The date MUST be represented
in a form that matches the dateTime production from [XMLSCHEMA]. The in a form that matches the dateTime production in "canonical
date MUST be expressed in canonical form with no time zone component. representation" [XMLSCHEMA]. Implementations SHOULD NOT rely on time
Implementations SHOULD NOT rely on time resolution finer than resolution finer than milliseconds and MUST NOT generate time
milliseconds and MUST NOT generate time instants that specify leap instants that specify leap seconds. Keys that are on the device
seconds. Keys that are on the device SHOULD only be used when the SHOULD only be used when the current date is on or after the device
current date is on or after the device start date. The attribute start date. The attribute definition is as follows:
definition is as follows:
at-pskc-deviceStartDate ATTRIBUTE ::= { at-pskc-deviceStartDate ATTRIBUTE ::= {
TYPE GeneralizedTime IDENTIFIED BY id-pskc-deviceStartDate } TYPE GeneralizedTime IDENTIFIED BY id-pskc-deviceStartDate }
id-pskc-deviceStartDate OBJECT IDENTIFIER ::= { id-pskc 6 } id-pskc-deviceStartDate OBJECT IDENTIFIER ::= { id-pskc 6 }
Note that usage enforcement of the keys with respect to the dates MAY 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 only happen on the validation server as some devices such as smart
cards do not have an internal clock. Systems thus SHOULD NOT rely cards do not have an internal clock. Systems thus SHOULD NOT rely
upon the device to enforce key usage date restrictions. upon the device to enforce key usage date restrictions.
3.1.1.7. Device Expiry Date 3.1.1.7. Device Expiry Date
When included in sKeyPkgAttrs, the Device Expiry Date attribute When included in sKeyPkgAttrs, the Device Expiry Date attribute
indicates the expiry date for a device. The date MUST be represented indicates the expiry date for a device. The date MUST be represented
in a form that matches the dateTime production from [XMLSCHEMA]. The in a form that matches the dateTime production in "canonical
date MUST be expressed in canonical form with no time zone component. representation" [XMLSCHEMA]. Implementations SHOULD NOT rely on time
Implementations SHOULD NOT rely on time resolution finer than resolution finer than milliseconds and MUST NOT generate time
milliseconds and MUST NOT generate time instants that specify leap instants that specify leap seconds. Keys that are on the device
seconds. Keys that are on the device SHOULD only be used when the SHOULD only be used when the current date is before the device expiry
current date is before the device expiry date. The attribute date. The attribute definition is as follows:
definition is as follows:
at-pskc-deviceExpiryDate ATTRIBUTE ::= { at-pskc-deviceExpiryDate ATTRIBUTE ::= {
TYPE GeneralizedTime IDENTIFIED BY id-pskc-deviceExpiryDate } TYPE GeneralizedTime IDENTIFIED BY id-pskc-deviceExpiryDate }
id-pskc-deviceExpiryDate OBJECT IDENTIFIER ::= { id-pskc 7 } id-pskc-deviceExpiryDate OBJECT IDENTIFIER ::= { id-pskc 7 }
Note that usage enforcement of the keys with respect to the dates MAY 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 only happen on the validation server as some devices such as smart
cards do not have an internal clock. Systems thus SHOULD NOT rely cards do not have an internal clock. Systems thus SHOULD NOT rely
upon the device to enforce key usage date restrictions. upon the device to enforce key usage date restrictions.
3.1.1.8. Device User Id 3.1.1.8. Device User Id
The Device User Id attribute indicates the user with whom the device The Device User Id attribute indicates the user with whom the device
is associated with using a distinguished name, as defined in is associated with using a distinguished name, as defined in
[RFC4514]. For example: UID=jsmith,DC=example,DC=net. The attribute [RFC4514]. For example: UID=jsmith,DC=example,DC=net. The attribute
skipping to change at page 15, line 23 skipping to change at page 15, line 13
purposes only. purposes only.
3.3. Key Policy Attributes 3.3. Key Policy Attributes
Key policy attributes indicate a policy that can be attached to a Key policy attributes indicate a policy that can be attached to a
key. These attributes are defined in the subsections that follow. key. These attributes are defined in the subsections that follow.
3.3.1. Key Start Date 3.3.1. Key Start Date
When included in sKeyAttrs, the Key Start Date attribute indicates When included in sKeyAttrs, the Key Start Date attribute indicates
the start of the key's validity period. The date MUST be represented the start of the key's validity period. The date MUST be represented
in a form that matches the dateTime production from [XMLSCHEMA]. The in a form that matches the dateTime production in "canonical
date MUST be expressed in canonical form with no time zone component. representation" [XMLSCHEMA]. Implementations SHOULD NOT rely on time
Implementations SHOULD NOT rely on time resolution finer than resolution finer than milliseconds and MUST NOT generate time
milliseconds and MUST NOT generate time instants that specify leap instants that specify leap seconds. The attribute definition is as
seconds. The attribute definition is as follows: follows:
at-pskc-keyStartDate ATTRIBUTE ::= { at-pskc-keyStartDate ATTRIBUTE ::= {
TYPE GeneralizedTime IDENTIFIED BY id-pskc-keyStartDate } TYPE GeneralizedTime IDENTIFIED BY id-pskc-keyStartDate }
id-pskc-keyStartDate OBJECT IDENTIFIER ::= { id-pskc 21 } id-pskc-keyStartDate OBJECT IDENTIFIER ::= { id-pskc 21 }
3.3.2. Key Expiry Date 3.3.2. Key Expiry Date
When included in sKeyAttrs, the Key Expiry Date attribute indicates When included in sKeyAttrs, the Key Expiry Date attribute indicates
the end of the key's validity period. The date MUST be represented the end of the key's validity period. The date MUST be represented
in a form that matches the dateTime production from [XMLSCHEMA]. The in a form that matches the dateTime production in "canonical
date MUST be expressed in canonical form with no time zone component. representation" [XMLSCHEMA]. Implementations SHOULD NOT rely on time
Implementations SHOULD NOT rely on time resolution finer than resolution finer than milliseconds and MUST NOT generate time
milliseconds and MUST NOT generate time instants that specify leap instants that specify leap seconds. The attribute definition is as
seconds. The attribute definition is as follows: follows:
at-pskc-keyExpiryDate ATTRIBUTE ::= { at-pskc-keyExpiryDate ATTRIBUTE ::= {
TYPE GeneralizedTime IDENTIFIED BY id-pskc-keyExpiryDate } TYPE GeneralizedTime IDENTIFIED BY id-pskc-keyExpiryDate }
id-pskc-keyExpiryDate OBJECT IDENTIFIER ::= { id-pskc 22 } id-pskc-keyExpiryDate OBJECT IDENTIFIER ::= { id-pskc 22 }
3.3.3. Number of Transactions 3.3.3. Number of Transactions
The Number of Transactions attribute indicates the maximum number of The Number of Transactions attribute indicates the maximum number of
times a key carried within the package can be used. When this times a key carried within the package can be used. When this
 End of changes. 15 change blocks. 
38 lines changed or deleted 35 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/