draft-ietf-keyprov-symmetrickeyformat-09.txt   draft-ietf-keyprov-symmetrickeyformat-10.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: January 10, 2010 Vigil Security Expires: February 4, 2010 Vigil Security
June 10, 2010 August 4, 2010
Symmetric Key Package Content Type Symmetric Key Package Content Type
draft-ietf-keyprov-symmetrickeyformat-09.txt draft-ietf-keyprov-symmetrickeyformat-10.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 January 6, 2010. This Internet-Draft will expire on February 4, 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.......................................8 3.2. PSKC Key Attributes.......................................9
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...............................9 3.2.4. Key Profile Identifier..............................10
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................................10 3.2.7. Algorithm Parameters................................11
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.........................................13 3.2.11. Time Drift.........................................14
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..............................15 3.3.3. Number of Transactions..............................16
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..................................18 4.2. Triple DES Key Encoding..................................19
5. Security Considerations.......................................19 5. Security Considerations.......................................19
6. IANA Considerations...........................................19 6. IANA Considerations...........................................20
7. References....................................................20 7. References....................................................20
7.1. Normative References.....................................20 7.1. Normative References.....................................20
7.2. Informative References...................................21 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
transport independent. The Cryptographic Message Syntax (CMS) transport independent. The Cryptographic Message Syntax (CMS)
[RFC5652] can be used to digitally sign, digest, authenticate, or [RFC5652] can be used to digitally sign, digest, authenticate, or
encrypt this content type. encrypt this content type.
skipping to change at page 5, line 50 skipping to change at page 5, line 50
key package attributes are OPTIONAL. key package attributes are OPTIONAL.
3.1.1. Device Information Attributes 3.1.1. Device Information Attributes
Device Information attributes when taken together MUST uniquely Device Information attributes when taken together MUST uniquely
identify a device to which the Symmetric Key Package is provisioned. identify a device to which the Symmetric Key Package is provisioned.
3.1.1.1. Manufacturer 3.1.1.1. Manufacturer
The Manufacturer attribute indicates the manufacturer of the device. The Manufacturer attribute indicates the manufacturer of the device.
Values for Manufacturer SHOULD be taken from either [OATHMAN] Values for Manufacturer MUST be taken from either [OATHMAN] prefixes
prefixes (i.e., the left column) or they SHOULD be taken from IANA (i.e., the left column) or from IANA Private Enterprise Number
Private Enterprise Number Registry [IANAPENREG], using the Registry [IANAPENREG], using the Organisation value. When the value
Organisation value. The attribute definition is as follows: is taken from [OATHMAN] "oath." MUST be prepended to the value (e.g.,
"oath.<values from [OATHMAN]>"). When the value is taken from
[IANAPENREG] "iana." MUST be prepended to the value (e.g.,
"iana.<ORganisation value from [IANAPENREG]>"). The attribute
definition is as follows:
at-pskc-manufacturer ATTRIBUTE ::= { at-pskc-manufacturer ATTRIBUTE ::= {
TYPE UTF8String IDENTIFIED BY id-pskc-manufacturer } TYPE UTF8String IDENTIFIED BY id-pskc-manufacturer }
id-pskc-manufacturer OBJECT IDENTIFIER ::= { id-pskc 1 } id-pskc-manufacturer OBJECT IDENTIFIER ::= { id-pskc 1 }
3.1.1.2. Serial Number 3.1.1.2. Serial Number
The Serial Number attribute indicates the serial number of the The Serial Number attribute indicates the serial number of the
device. The attribute definition is as follows: device. The attribute definition is as follows:
skipping to change at page 7, line 14 skipping to change at page 7, line 19
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 [PSKC]. The date in a form that matches the dateTime production from [XMLSCHEMA]. The
MUST be expressed in UTC form with no time zone component. date MUST be expressed in canonical form with no time zone component.
Implementations SHOULD NOT rely on time resolution finer than Implementations SHOULD NOT rely on time resolution finer than
milliseconds and MUST NOT generate time instants that specify leap milliseconds and MUST NOT generate time instants that specify leap
seconds. Keys that are on the device SHOULD only be used when the 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 current date is on or after the device 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 }
skipping to change at page 7, line 37 skipping to change at page 7, line 42
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 from [XMLSCHEMA]. The
date MUST be expressed in UTC form with no time zone component. date MUST be expressed in canonical form with no time zone component.
Implementations SHOULD NOT rely on time resolution finer than Implementations SHOULD NOT rely on time resolution finer than
milliseconds and MUST NOT generate time instants that specify leap milliseconds and MUST NOT generate time instants that specify leap
seconds. Keys that are on the device SHOULD only be used when the seconds. Keys that are on the device SHOULD only be used when the
current date is before the device expiry date. The attribute current date is before the device expiry 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 }
skipping to change at page 15, line 15 skipping to change at page 15, line 25
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 from [XMLSCHEMA]. The
date MUST be expressed in UTC form with no time zone component. date MUST be expressed in canonical form with no time zone component.
Implementations SHOULD NOT rely on time resolution finer than Implementations SHOULD NOT rely on time resolution finer than
milliseconds and MUST NOT generate time instants that specify leap milliseconds and MUST NOT generate time instants that specify leap
seconds. The attribute definition is as follows: seconds. The attribute definition is as 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 from [XMLSCHEMA]. The
date MUST be expressed in UTC form with no time zone component. date MUST be expressed in canonical form with no time zone component.
Implementations SHOULD NOT rely on time resolution finer than Implementations SHOULD NOT rely on time resolution finer than
milliseconds and MUST NOT generate time instants that specify leap milliseconds and MUST NOT generate time instants that specify leap
seconds. The attribute definition is as follows: seconds. The attribute definition is as 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
skipping to change at page 21, line 20 skipping to change at page 21, line 34
http://www.openauthentication.org/oath-id/prefixes/ http://www.openauthentication.org/oath-id/prefixes/
[PSKC] Hoyer, P., Pei, M., and S. Machani, "Portable Symmetric [PSKC] Hoyer, P., Pei, M., and S. Machani, "Portable Symmetric
Key Container (PSKC), draft-ietf-keyprov-pskc-07.txt, Key Container (PSKC), draft-ietf-keyprov-pskc-07.txt,
work-in-progress. work-in-progress.
//** RFC EDITOR: Please replace [PSKC] with [RFCXXXX] where XXXX is //** RFC EDITOR: Please replace [PSKC] with [RFCXXXX] where XXXX is
the draft-ietf-keyprov-pskc's RFC #. Make the replacements here and the draft-ietf-keyprov-pskc's RFC #. Make the replacements here and
elsewhere in the document. **// elsewhere in the document. **//
[SP800-67] 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.
[X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824- [X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-
1:2002. Information Technology - Abstract Syntax 1:2002. Information Technology - Abstract Syntax
Notation One. Notation One.
[X.681] ITU-T Recommendation X.681 (2002) | ISO/IEC 8824- [X.681] ITU-T Recommendation X.681 (2002) | ISO/IEC 8824-
2:2002. Information Technology - Abstract Syntax 2:2002. Information Technology - Abstract Syntax
Notation One: Information Object Specification. Notation One: Information Object Specification.
[X.682] ITU-T Recommendation X.682 (2002) | ISO/IEC 8824- [X.682] ITU-T Recommendation X.682 (2002) | ISO/IEC 8824-
3:2002. Information Technology - Abstract Syntax 3:2002. Information Technology - Abstract Syntax
skipping to change at page 21, line 42 skipping to change at page 22, line 15
[X.683] ITU-T Recommendation X.683 (2002) | ISO/IEC 8824- [X.683] ITU-T Recommendation X.683 (2002) | ISO/IEC 8824-
4:2002. Information Technology - Abstract Syntax 4:2002. Information Technology - Abstract Syntax
Notation One: Parameterization of ASN.1 Specifications. Notation One: Parameterization of ASN.1 Specifications.
[X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825- [X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-
1:2002. Information Technology - ASN.1 encoding rules: 1:2002. Information Technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules Encoding Rules (CER) and Distinguished Encoding Rules
(DER). (DER).
[SP800-67] National Institute of Standards and Technology, "NIST [XMLSCHEMA] Biron, P., and A. Malhotra, "XML Schema Part 2:
Special Publication 800-67 Version 1.1: Recommendation Datatypes Second Edition",
for the Triple Data Encryption Algorithm (TDEA) Block http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/,
Cipher", NIST Special Publication 800-67, May 2008. 2004.
7.2. Informative References 7.2. Informative References
[DSKPP] Doherty, A., Pei, M., Machani, S., and M. Nystrom, [DSKPP] Doherty, A., Pei, M., Machani, S., and M. Nystrom,
"Dynamic Symmetric Key Provisioning Protocol", Internet "Dynamic Symmetric Key Provisioning Protocol", Internet
Draft Informational, URL: http://www.ietf.org/internet- Draft Informational, URL: http://www.ietf.org/internet-
drafts/draft-ietf-keyprov-dskpp-10.txt, work in drafts/draft-ietf-keyprov-dskpp-10.txt, work in
progress. progress.
//** RFC EDITOR: Please replace [DSKPP] with [RFCXXXX] where XXXX is //** RFC EDITOR: Please replace [DSKPP] with [RFCXXXX] where XXXX is
 End of changes. 18 change blocks. 
25 lines changed or deleted 34 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/