idnits 2.17.1 draft-ietf-keyprov-symmetrickeyformat-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 415. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 426. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 433. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 439. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 14, 2008) is 5764 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 319 -- Obsolete informational reference (is this intentional?): RFC 3852 (Obsoleted by RFC 5652) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 KEYPROV Working Group Sean Turner, IECA 2 Internet Draft Russ Housley, Vigil Security 3 Intended Status: Standard Track July 14, 2008 4 Expires: January 14, 2009 6 Symmetric Key Package Content Type 7 draft-ietf-keyprov-symmetrickeyformat-03.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This Internet-Draft will expire on January 14, 2008. 34 Copyright Notice 36 Copyright (C) The IETF Trust (2008). 38 Abstract 40 This document defines the symmetric key format content type. It is 41 transport independent. The Cryptographic Message Syntax can be used 42 to digitally sign, digest, authenticate, or encrypt this content 43 type. 45 Table of Contents 47 1. Introduction...................................................2 48 1.1. Requirements Terminology..................................2 49 1.2. ASN.1 Syntax Notation.....................................2 50 2. Use Cases......................................................3 51 2.1. Online Use Cases..........................................3 52 2.1.1. Transport of Keys from Server to Cryptomodule........3 53 2.1.2. Transport of Keys from Cryptomodule to Cryptomodule..3 54 2.1.3. Transport of Keys from Cryptomodule to Server........3 55 2.1.4. Server to Server Bulk Import/Export of Keys..........4 56 2.2. Offline Use Cases.........................................4 57 2.2.1. Server to Server Bulk Import/Export of Keys..........4 58 3. Symmetric Key Package Content Type.............................5 59 4. Security Considerations........................................6 60 5. IANA Considerations............................................6 61 6. References.....................................................6 62 6.1. Normative References......................................6 63 6.2. Non-Normative References..................................7 64 APPENDIX A: ASN.1 Module..........................................8 66 1. Introduction 68 This document defines the symmetric key format content type. It is 69 transport independent. The Cryptographic Message Syntax [RFC3852] can 70 be used to digitally sign, digest, authenticate, or encrypt this 71 content type. 73 1.1. Requirements Terminology 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 77 document are to be interpreted as described in [RFC2119]. 79 1.2. ASN.1 Syntax Notation 81 The key package is defined using the ASN.1 [X.680, X.681, X.682, 82 X.683]. 84 2. Use Cases 86 These use cases help in understanding the applicability of this 87 specification to real world situations. 89 2.1. Online Use Cases 91 This section describes the use cases related to provisioning the keys 92 using an online provisioning protocol such as [DSKPP]. 94 2.1.1. Transport of Keys from Server to Cryptomodule 96 For example, a mobile device user wants to obtain a symmetric key for 97 use with a cryptomodule on the device. The cryptomodule client from 98 vendor A initiates the provisioning process against a provisioning 99 system from vendor B using a standards-based provisioning protocol 100 such as [DSKPP]. The provisioning entity delivers one or more keys 101 in a standard format that can be processed by the mobile device. 103 For example, in a variation of the above, instead of the user's 104 mobile phone, a key is provisioned in the user's soft token 105 application on a laptop using a network-based online protocol. As 106 before, the provisioning system delivers a key in a standard format 107 that can be processed by the soft token on the PC. 109 For example, the end-user or the key issuer wants to update or 110 configure an existing key in the cryptomodule and requests a 111 replacement key container. The container may or may not include a 112 new key and may include new or updated key attributes such as a new 113 counter value in HOTP key case, a modified response format or length, 114 a new friendly name, etc. 116 2.1.2. Transport of Keys from Cryptomodule to Cryptomodule 118 For example, a user wants to transport a key from one cryptomodule to 119 another. There may be two cryptographic modules, one on a computer 120 one on a mobile phone, and the user wants to transport a key from the 121 computer to the mobile phone. The user can export the key and 122 related data in a standard format for input into the other 123 cryptomodule. 125 2.1.3. Transport of Keys from Cryptomodule to Server 127 For example, a user wants to activate and use a new key and related 128 data against a validation system that is not aware of this key. This 129 key may be embedded in the cryptomodule (e.g., SD card, USB drive) 130 that the user has purchased at the local electronics retailer. Along 131 with the cryptomodule, the user may get the key on a CD or a floppy 132 in a standard format. The user can now upload via a secure online 133 channel or import this key and related data into the new validation 134 system and start using the key. 136 2.1.4. Server to Server Bulk Import/Export of Keys 138 From time to time, a key management system may be required to import 139 or export keys in bulk from one entity to another. 141 For example, instead of importing keys from a manufacturer using a 142 file, a validation server may download the keys using an online 143 protocol. The keys can be downloaded in a standard format that can 144 be processed by a validation system. 146 For example, in a variation of the above, an OTA key provisioning 147 gateway that provisions keys to mobile phones may obtain key material 148 from a key issuer using an online protocol. The keys are delivered 149 in a standard format that can be processed by the key provisioning 150 gateway and subsequently sent to the end-user's mobile phone. 152 2.2. Offline Use Cases 154 This section describes the use cases relating to offline transport of 155 keys from one system to another, using some form of export and import 156 model. 158 2.2.1. Server to Server Bulk Import/Export of Keys 160 For example, cryptomodules such as OTP authentication tokens, may 161 have their symmetric keys initialized during the manufacturing 162 process in bulk, requiring copies of the keys and algorithm data to 163 be loaded into the authentication system through a file on portable 164 media. The manufacturer provides the keys and related data in the 165 form of a file containing records in standard format, typically on a 166 CD. Note that the token manufacturer and the vendor for the 167 validation system may be the same or different. Some crypto modules 168 will allow local PIN management (the device will have a PIN pad) 169 hence random initial PINs set at manufacturing should be transmitted 170 together with the respective keys they protect. 172 For example, an enterprise wants to port keys and related data from 173 an existing validation system A into a different validation system B. 174 The existing validation system provides the enterprise with a 175 functionality that enables export of keys and related data (e.g., for 176 OTP authentication tokens) in a standard format. Since the OTP 177 tokens are in the standard format, the enterprise can import the 178 token records into the new validation system B and start using the 179 existing tokens. Note that the vendors for the two validation 180 systems may be the same or different. 182 3. Symmetric Key Package Content Type 184 The symmetric key package content type is used to transfer one or 185 more plaintext symmetric keys from one party to another. A symmetric 186 key package MAY be encapsulated in one or more CMS protecting content 187 types. This content type must be DER encoded [X.690]. 189 The symmetric key package content type has the following syntax: 191 PKCS7-CONTENT-TYPE ::= TYPE-IDENTIFIER 193 symmetric-key-package PKCS7-CONTENT-TYPE ::= 194 { SymmetricKeyPackage IDENTIFIED BY id-ct-KP-sKeyPackage } 196 id-ct-KP-sKeyPackage OBJECT IDENTIFIER ::= | 197 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 198 smime(16) ct(1) 25 } 200 SymmetricKeyPackage ::= SEQUENCE { 201 version KeyPkgVersion DEFAULT v1, 202 sKeyPkgAtts [0] SEQUENCE SIZE (1..MAX) OF Attribute OPTIONAL, 203 sKeys SymmetricKeys } 205 SymmetricKeys ::= SEQUENCE SIZE (1..MAX) OF OneSymmetricKey 207 OneSymmetricKey ::= SEQUENCE { 208 sKeyAttrs SEQUENCE SIZE (1..MAX) OF Attribute OPTIONAL, 209 sKey OCTET STRING OPTIONAL 210 -- MUST contain sKeyAttrs, sKey, or sKeyAttrs and sKey 211 } 213 KeyPkgVersion ::= INTEGER { v1(1), ... } 215 The SymmetricKeyPackage fields are used as follows: 217 - version identifies version of the symmetric key package content 218 structure. For this version of the specification, the default 219 value, v1, MUST be used. 221 - sKeyPkgAttrs optionally provides attributes that apply to all of 222 the symmetric keys in the package. If an attribute appears here it 223 MUST NOT also be included in sKeyAttrs. 225 - sKeys contains a sequence of OneSymmetricKey values. This 226 structure is discussed below. 228 The OneSymmetricKey fields are used as follows: 230 - sKeyAttrs optionally provides attributes that apply to one 231 symmetric key. If an attribute appears here it MUST NOT also be 232 included in sKeyPkgAttrs. 234 - sKey optionally contains the key value encoded as an OCTET STRING. 236 The OneSymmetricKey field MUST include either sKeyAttrs, sKey, or 237 sKeyAttrs and sKey. 239 4. Security Considerations 241 The symmetric key package contents are not protected. This content 242 type can be combined with a security protocol to protect the contents 243 of the package. 245 5. IANA Considerations 247 None: All identifiers are already registered. Please remove this 248 section prior to publication as an RFC. 250 6. References 252 6.1. Normative References 254 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 255 Requirement Levels", BCP 14, RFC 2119, March 1997. 257 [X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002. 258 Information Technology - Abstract Syntax Notation One. 260 [X.681] ITU-T Recommendation X.681 (2002) | ISO/IEC 8824-2:2002. 261 Information Technology - Abstract Syntax Notation One: Information 262 Object Specification. 264 [X.682] ITU-T Recommendation X.682 (2002) | ISO/IEC 8824-3:2002. 265 Information Technology - Abstract Syntax Notation One: Constraint 266 Specification. 268 [X.683] ITU-T Recommendation X.683 (2002) | ISO/IEC 8824-4:2002. 269 Information Technology - Abstract Syntax Notation One: 270 Parameterization of ASN.1 Specifications. 272 [X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002. 273 Information Technology - ASN.1 encoding rules: Specification of Basic 274 Encoding Rules (BER), Canonical Encoding Rules (CER) and 275 Distinguished Encoding Rules (DER). 277 6.2. Non-Normative References 279 [DSKPP] Doherty, A., Pei, M., Machani, S., and M. Nystrom, "Dynamic 280 Symmetric Key Provisioning Protocol (DSKPP)", work-in-progress. 282 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", RFC3852, 283 July 2004. 285 APPENDIX A: ASN.1 Module 287 This appendix provides the normative ASN.1 definitions for the 288 structures described in this specification using ASN.1 as defined in 289 [X.680] through [X.683]. 291 SymmetricKeyPackageModulev1 292 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 293 smime(16) modules(0) 33 } 295 DEFINITIONS IMPLICIT TAGS ::= 297 BEGIN 299 -- EXPORTS ALL 301 -- IMPORTS NOTHING 303 PKCS7-CONTENT-TYPE ::= TYPE-IDENTIFIER 305 KeyPackageContentTypes PKCS7-CONTENT-TYPE ::= { 306 symmetric-key-package | 307 ... -- Expect additional content types -- 308 } 310 symmetric-key-package PKCS7-CONTENT-TYPE ::= 311 { SymmetricKeyPackage IDENTIFIED BY id-ct-KP-sKeyPackage } 313 id-ct-KP-sKeyPackage OBJECT IDENTIFIER ::= 314 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 315 smime(16) ct(1) 25 } 317 SymmetricKeyPackage ::= SEQUENCE { 318 version KeyPkgVersion DEFAULT v1, 319 sKeyPkgAttrs [0] SEQUENCE SIZE (1..MAX) OF Attribute OPTIONAL, 320 sKeys SymmetricKeys } 322 SymmetricKeys ::= SEQUENCE SIZE (1..MAX) OF OneSymmetricKey 324 OneSymmetricKey ::= SEQUENCE { 325 sKeyAttrs SEQUENCE SIZE (1..MAX) OF Attribute OPTIONAL, 326 sKey OCTET STRING OPTIONAL 327 -- MUST contain sKeyAttrs, sKey, or sKeyAttrs and sKey 328 } 330 KeyPkgVersion ::= INTEGER { v1(1), ... } 331 Attribute ::= SEQUENCE { 332 type ATTRIBUTE.&id ({SupportedAttributes}), 333 values SET SIZE (1..MAX) OF ATTRIBUTE.&Type 334 ({SupportedAttributes}{@type}) } 336 SupportedAttributes ATTRIBUTE ::= { ... } 338 ATTRIBUTE ::= CLASS { 339 &derivation ATTRIBUTE OPTIONAL, 340 &Type OPTIONAL, 341 -- either &Type or &derivation required 342 &equality-match MATCHING-RULE OPTIONAL, 343 &ordering-match MATCHING-RULE OPTIONAL, 344 &substrings-match MATCHING-RULE OPTIONAL, 345 &single-valued BOOLEAN DEFAULT FALSE, 346 &collective BOOLEAN DEFAULT FALSE, 347 -- operational extensions 348 &no-user-modification BOOLEAN DEFAULT FALSE, 349 &usage AttributeUsage DEFAULT userApplications, 350 &id OBJECT IDENTIFIER UNIQUE } 351 WITH SYNTAX { 352 [ SUBTYPE OF &derivation ] 353 [ WITH SYNTAX &Type ] 354 [ EQUALITY MATCHING RULE &equality-match ] 355 [ ORDERING MATCHING RULE &ordering-match ] 356 [ SUBSTRINGS MATCHING RULE &substrings-match ] 357 [ SINGLE VALUE &single-valued ] 358 [ COLLECTIVE &collective ] 359 [ NO USER MODIFICATION &no-user-modification ] 360 [ USAGE &usage ] 361 ID &id } 363 MATCHING-RULE ::= CLASS { 364 &AssertionType OPTIONAL, 365 &id OBJECT IDENTIFIER UNIQUE } 366 WITH SYNTAX { 367 [ SYNTAX &AssertionType ] 368 ID &id } 370 AttributeType ::= ATTRIBUTE.&id 372 AttributeValue ::= ATTRIBUTE.&Type 373 AttributeUsage ::= ENUMERATED { 374 userApplications (0), 375 directoryOperation (1), 376 distributedOperation (2), 377 dSAOperation (3) } 379 END 381 Author's Address 383 Sean Turner 385 IECA, Inc. 386 3057 Nutley Street, Suite 106 387 Fairfax, VA 22031 388 USA 390 Email: turners@ieca.com 392 Russ Housley 394 Vigil Security, LLC 395 918 Spring Knoll Drive 396 Herndon, VA 20170 397 USA 399 EMail: housley@vigilsec.com 401 Full Copyright Statement 403 Copyright (C) The IETF Trust (2008). 405 This document is subject to the rights, licenses and restrictions 406 contained in BCP 78, and except as set forth therein, the authors 407 retain all their rights. 409 This document and the information contained herein are provided on an 410 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 411 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 412 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 413 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 414 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 415 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 417 Intellectual Property 419 The IETF takes no position regarding the validity or scope of any 420 Intellectual Property Rights or other rights that might be claimed to 421 pertain to the implementation or use of the technology described in 422 this document or the extent to which any license under such rights 423 might or might not be available; nor does it represent that it has 424 made any independent effort to identify any such rights. Information 425 on the procedures with respect to rights in RFC documents can be 426 found in BCP 78 and BCP 79. 428 Copies of IPR disclosures made to the IETF Secretariat and any 429 assurances of licenses to be made available, or the result of an 430 attempt made to obtain a general license or permission for the use of 431 such proprietary rights by implementers or users of this 432 specification can be obtained from the IETF on-line IPR repository at 433 http://www.ietf.org/ipr. 435 The IETF invites any interested party to bring to its attention any 436 copyrights, patents or patent applications, or other proprietary 437 rights that may cover technology that may be required to implement 438 this standard. Please address the information to the IETF at 439 ietf-ipr@ietf.org. 441 Acknowledgment 443 Funding for the RFC Editor function is provided by the IETF 444 Administrative Support Activity (IASA).