idnits 2.17.1 draft-turner-asymmetrickeyformat-00.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 447. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 458. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 465. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 471. 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 : ---------------------------------------------------------------------------- == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. 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 (20 October 2008) is 5638 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 369 -- Looks like a reference, but probably isn't: '1' on line 370 ** Obsolete normative reference: RFC 3852 (Obsoleted by RFC 5652) -- Obsolete informational reference (is this intentional?): RFC 5208 (Obsoleted by RFC 5958) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Sean Turner, IECA 2 Internet Draft 20 October 2008 3 Intended Status: Standard Track 4 Obsoletes: RFC 5208 (once approved) 5 Expires: 20 April 2009 7 Asymmetric Key Packages 8 draft-turner-asymmetrickeyformat-00.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 This Internet-Draft will expire on 20 April 2009. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 This document defines the syntax for private key information and a 42 content type for it. Private-key information includes a private key 43 for some public-key algorithm and a set of attributes. The document 44 also describes a syntax for encrypted private keys. The 45 Cryptographic Message Syntax, as defined in RFC 3852, can be used to 46 digitally sign, digest, authenticate, or encrypt the asymmetric key 47 format content type. This document obsoletes RFC 5208. 49 Table of Contents 51 1. Introduction...................................................2 52 1.1. Requirements Terminology..................................2 53 1.2. ASN.1 Syntax Notation.....................................2 54 1.3. Changes since RFC 5208....................................2 55 2. Asymmetric Key Package Content Type............................3 56 3. Encrypted Private Key Info.....................................4 57 4. Protecting the AsymmetricKeyPackage............................5 58 5. Other Considerations...........................................5 59 6. Security Considerations........................................6 60 7. IANA Considerations............................................6 61 8. References.....................................................6 62 8.1. Normative References......................................6 63 8.2. Non-Normative References..................................7 64 APPENDIX A: ASN.1 Module..........................................8 66 1. Introduction 68 This document defines the syntax for private key information and a 69 content type for it. Private-key information includes a private key 70 for some public-key algorithm and a set of attributes. The document 71 also describes a syntax for encrypted private keys. The 72 Cryptographic Message Syntax [RFC3852] can be used to digitally sign, 73 digest, authenticate, or encrypt the asymmetric key format content 74 type. This document obsoletes [RFC5208]. 76 1.1. Requirements Terminology 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 80 document are to be interpreted as described in [RFC2119]. 82 1.2. ASN.1 Syntax Notation 84 The key package is defined using ASN.1 [X.680], [X.681], [X.682], and 85 [X.683]. 87 1.3. Changes since RFC 5208 89 The following are the changes since [RFC5208]: 91 - Defined Asymmetric Key Package CMS content type. 93 - Removed IMPLICIT from aKeyAttrs to align text with module. 95 - Added public key to OneAsymmetricKey and added new version number. 97 - Added that PKCS#9 attributes MAY be supported. 99 - Added Other Considerations section. 101 2. Asymmetric Key Package Content Type 103 The asymmetric key package content type is used to transfer one or 104 more plaintext asymmetric keys from one party to another. An 105 asymmetric key package MAY be encapsulated in one or more CMS 106 protecting content types (see Section 4). This content type MUST be 107 DER encoded [X.690]. 109 The asymmetric key package content type has the following syntax: 111 PKCS7-CONTENT-TYPE ::= TYPE-IDENTIFIER 113 asymmetric-key-package PKCS7-CONTENT-TYPE ::= 114 { AsymmetricKeyPackage IDENTIFIED BY id-ct-KP-aKeyPackage } 116 id-ct-KP-aKeyPackage OBJECT IDENTIFIER ::= | 117 { TBD } 119 AsymmetricKeyPackage ::= SEQUENCE SIZE (1..MAX) OF OneAsymmetricKey 121 OneAsymmetricKey ::= SEQUENCE { 122 version Version, 123 privateKeyAlgorithm PrivateKeyAlgorithmIdentifier, 124 privateKey PrivateKey, -- DER encoded 125 aKeyAttrs [0] Attributes OPTIONAL, 126 publicKey [1] PublicKey OPTIONAL } 128 PrivateKeyInfo ::= OneAsymmetricKey -- Used in [P12] 130 Version ::= INTEGER { v1(0), v2(1) } (v1, v2,...) 132 PrivateKeyAlgorithmIdentifier ::= AlgorithmIdentifier 133 { { PrivateKeyAlgorithms } } 135 PrivateKey ::= OCTET STRING 136 -- Content varies based on type of key. The 137 -- algorithm identifier dictates the format of 138 -- the key. DSA is INTEGER, ECDSA is INTEGER 140 PublicKey ::= OCTET STRING 141 -- Content varies based on type of key. The 142 -- algorithm identifier dictates the format of 143 -- the key. DSA is INTEGER, ECDSA is OCTET STRING 145 Attributes ::= Set of Attribute 147 The AsymmetricKeyPackage contains one or more OneAsymmetricKey 148 elements. The syntax accommodates keying material attributes (e.g., 149 certificates), a private key, an optional public key and optional 150 asymmetric algorithm parameters. In general, either the public key 151 or the certificate will be present. In very rare cases will both the 152 public key and the certificate be present as this includes two copies 153 of the public key. The fields in OneAsymmetricKey are used as 154 follows: 156 - version identifies version of the asymmetric key package content 157 structure. For this version of the specification, version MUST be 158 v1 if the publicKey field is absent and it MUST be set to v2 if the 159 publicKey field is present. 161 - privateKeyAlgorithm identifies the private key algorithm and 162 optionally contains parameters associated with the asymmetric key. 163 The algorithm is identified by an OID and the parameters format 164 depends on the OID. The value placed in 165 privateKeyAlgorithmIdentifier is the value an originator would 166 apply to indicate which algorithm was used. 168 - privateKey is an OCTET STRING whose contents are the DER encoded 169 private key. The interpretation of the contents is defined in the 170 registration of the private-key algorithm. 172 - attributes is optional. It contains information corresponding to 173 the public key (e.g., certificates). The attributes field uses the 174 class ATTRIBUTE which is restricted by the SupportedAttributes 175 parameterized type. SupportedAttributes is an open ended set in 176 this document. Others documents can constrain these values. 177 Attributes from [RFC2985] MAY be supported. 179 - publicKey is optional. When present, it contains the public key 180 encoded as an OCTET STRING. The structure within the octet string, 181 if any, depends on the privateKeyAlgorithm. 183 3. Encrypted Private Key Info 185 This section gives the syntax for encrypted private-key information, 186 which is used with the [P12]. 188 Encrypted private-key information shall have ASN.1 type 189 EncryptedPrivateKeyInfo: 191 EncryptedPrivateKeyInfo ::= SEQUENCE { 192 encryptionAlgorithm EncryptionAlgorithmIdentifier, 193 encryptedData EncryptedData } 195 EncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 196 { { KeyEncryptionAlgorithms } } 198 EncryptedData ::= OCTET STRING 200 The EncAsymmetricKeyPackage contains one or more 201 EncryptedPrivateKeyInfo elements. The fields in 202 EncryptedPrivateKeyInfo are used as follows: 204 - encryptionAlgorithm identifies the algorithm under which the 205 private-key information is encrypted. Implementations MUST the TBD 206 algorithm. 208 - encryptedData is the result of encrypting the private-key 209 information (i.e., the PrivateKeyInfo). 211 The encryption process involves the following two steps: 213 1. The private-key information is BER encoded, yielding an octet 214 string. 216 2. The result of step 1 is encrypted with the secret key to give an 217 octet string, the result of the encryption process. 219 4. Protecting the AsymmetricKeyPackage 221 CMS [RFC3852] protecting content types can be used to provide 222 security to the AsymmetricKeyPackage: 224 - SignedData can be used to apply a digital signature to the 225 AsymmetricKeyPackage. 227 - EncryptedData can be used to encrypt the AsymmetricKeyPackage 228 encapsulate the AsymmetricKeyPackage to provide confidentiality but 229 does not distribute the content encryption keys. 231 - EnvelopedData can be used to encrypt the AsymmetricKeyPackage with 232 simple symmetric encryption, where the sender and the receiver 233 already share the necessary encryption key 235 - AuthenticatedData can be used to protect the AsymmetricKeyPackage 236 with message authentication codes, where key management information 237 is handled in a manner similar to EnvelopedData. 239 5. Other Considerations 241 This document defines the syntax and the semantics for content types 242 that exchange asymmetric keys. There are two other standards for 243 transporting asymmetric private keys: 245 - Personal Information Exchange (PFX) or more commonly referred to as 246 P12 [P12], is a transfer syntax for personal identity information, 247 including private keys, certificates, miscellaneous secrets, and 248 extensions. Both PrivateKeyInfo and EncryptedPrivateKeyInfo can be 249 carried in a P12 message. 251 - Microsoft's Exchange Security format, which is a proprietary 252 format. 254 When locally storing private keys, the file format is either a DER 255 encoded file with the file extension .p12 or a PEM encoded file with 256 the file extension .pem. 258 When the private key is a character string, the OCTET STRING contains 259 an embedded UTF8String. 261 6. Security Considerations 263 Protection of the private-key information is vital to public-key 264 cryptography. Disclosure of the private-key material to another 265 entity can lead to masquerades. The encryption algorithm used in the 266 encryption process must be as 'strong' as the key it is protecting. 268 The asymmetric key package contents are not protected. This content 269 type can be combined with a security protocol to protect the contents 270 of the package. 272 The encrypted asymmetric key package contents are protected; as noted 273 above the encryption algorithm must be as 'strong' as the key it is 274 protecting. 276 7. IANA Considerations 278 None: All identifiers are already registered. Please remove this 279 section prior to publication as an RFC. 281 8. References 283 8.1. Normative References 285 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 286 Requirement Levels", BCP 14, RFC 2119, March 1997. 288 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", RFC3852, 289 July 2004. 291 [X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002. 292 Information Technology - Abstract Syntax Notation One. 294 [X.681] ITU-T Recommendation X.681 (2002) | ISO/IEC 8824-2:2002. 295 Information Technology - Abstract Syntax Notation One: Information 296 Object Specification. 298 [X.682] ITU-T Recommendation X.682 (2002) | ISO/IEC 8824-3:2002. 299 Information Technology - Abstract Syntax Notation One: Constraint 300 Specification. 302 [X.683] ITU-T Recommendation X.683 (2002) | ISO/IEC 8824-4:2002. 303 Information Technology - Abstract Syntax Notation One: 304 Parameterization of ASN.1 Specifications. 306 [X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002. 307 Information Technology - ASN.1 encoding rules: Specification of Basic 308 Encoding Rules (BER), Canonical Encoding Rules (CER) and 309 Distinguished Encoding Rules (DER). 311 8.2. Non-Normative References 313 [P12] RSA Laboratories, "PKCS #12 v1.0: Personal Information Exchange 314 Syntax", June 1999. 316 [RFC2985] Nystrom, M., and B. Kaliski, "PKCS #9: Selected Object 317 Classes and Attribute Types Version 2.0", RFC 2985, November 2000. 319 [RFC5208] Kaliski, B., "PKCS #8: Private Key Information Syntax 320 Standard Version 1.2", RFC 5208, May 2008. 322 APPENDIX A: ASN.1 Module 324 This annex provides the normative ASN.1 definitions for the 325 structures described in this specification using ASN.1 as defined in 326 [X.680] through [X.683]. 328 AsymmetricKeyPackageModulev1 { tbd } 330 DEFINITIONS IMPLICIT TAGS ::= 332 BEGIN 334 -- EXPORTS ALL 336 IMPORTS NOTHING 338 Attribute{}, ATTRIBUTE, AlgorithmIdentifier{} 339 FROM PKIX-CommonTypes 340 { iso(1) identified-organization(3) dod(6) internet(1) 341 security(5) mechanisms(5) pkix(7) id-mod(0) 342 id-mod-pkixCommon(43) } 344 id-aes128-wrap, id-aes192-wrap, id-aes1256-wrap 345 FROM CMSAesRsaesOaep 346 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 347 pkcs-9(9) smime(16) modules(0) id-mod-cms-aes(19) } 349 ; 351 PKCS7-CONTENT-TYPE ::= TYPE-IDENTIFIER 353 KeyPackageContentTypes PKCS7-CONTENT-TYPE ::= { 354 asymmetric-key-package | 355 ... -- Expect additional content types -- 356 } 358 asymmetric-key-package PKCS7-CONTENT-TYPE ::= 359 { AsymmetricKeyPackage IDENTIFIED BY id-ct-KP-aKeyPackage } 361 id-ct-KP-aKeyPackage OBJECT IDENTIFIER ::= 362 { TBD } 364 AsymmetricKeyPackage ::= SEQUENCE SIZE (1..MAX) OF OneAsymmetricKey 365 OneAsymmetricKey ::= SEQUENCE { 366 version Version, 367 privateKeyAlgorithm PrivateKeyAlgorithmIdentifier, 368 privateKey PrivateKey, -- DER encoded 369 aKeyAttrs [0] Attributes OPTIONAL, 370 publicKey [1] PublicKey OPTIONAL } 372 PrivateKeyInfo ::= OneAsymmetricKey 374 Version ::= INTEGER {v1(0), v2(1)} (v1, v2,...) 376 PrivateKeyAlgorithmIdentifier ::= AlgorithmIdentifier 377 { { PrivateKeyAlgorithms } } 379 PrivateKey ::= OCTET STRING -- Content varies based on type of key 380 -- DSA is INTEGER, ECDSA is ECPublicKey 382 PublicKey ::= OCTET STRING 384 Attributes ::= Set of Attribute { { SupportAttributes } } 386 SupportedAttributes ATTRIBUTE :: { 387 ... -- For local profiles 388 } 390 EncAsymmetricKeyPackage ::= SEQUENCE SIZE (1..MAX) OF 391 EncryptedPrivateKeyInfo 393 EncryptedPrivateKeyInfo ::= SEQUENCE { 394 encryptionAlgorithm EncryptionAlgorithmIdentifier, 395 encryptedData EncryptedData } 397 EncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 398 { { KeyEncryptionAlgorithms } } 400 EncryptedData ::= OCTET STRING -- Encrypted PrivateKeyInfo 402 PrivateKeyAlgorithms ALGORITHM-IDENTIFIER ::= { 403 ... -- Extensible 404 } 406 KeyEncryptionAlgorithms ALGORITHM-IDENTIFIER ::= { 407 id-aes128-wrap | 408 id-aes192-wrap | 409 id-aes256-wrap, 410 ... -- Extensible 411 } 413 END 415 Acknowledgements 417 Many thanks go out to the Burt Kaliski and Jim Randall at RSA. 418 Without the prior version of the document, this one wouldn't exist. 420 We'd also like to thank Pasi Eronen and Russ Housley. 422 Author's Address 424 Sean Turner 426 IECA, Inc. 427 3057 Nutley Street, Suite 106 428 Fairfax, VA 22031 429 USA 431 Email: turners@ieca.com 433 Full Copyright Statement 435 Copyright (C) The IETF Trust (2008). 437 This document is subject to the rights, licenses and restrictions 438 contained in BCP 78, and except as set forth therein, the authors 439 retain all their rights. 441 This document and the information contained herein are provided on an 442 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 443 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 444 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 445 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 446 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 447 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 449 Intellectual Property 451 The IETF takes no position regarding the validity or scope of any 452 Intellectual Property Rights or other rights that might be claimed to 453 pertain to the implementation or use of the technology described in 454 this document or the extent to which any license under such rights 455 might or might not be available; nor does it represent that it has 456 made any independent effort to identify any such rights. Information 457 on the procedures with respect to rights in RFC documents can be 458 found in BCP 78 and BCP 79. 460 Copies of IPR disclosures made to the IETF Secretariat and any 461 assurances of licenses to be made available, or the result of an 462 attempt made to obtain a general license or permission for the use of 463 such proprietary rights by implementers or users of this 464 specification can be obtained from the IETF on-line IPR repository at 465 http://www.ietf.org/ipr. 467 The IETF invites any interested party to bring to its attention any 468 copyrights, patents or patent applications, or other proprietary 469 rights that may cover technology that may be required to implement 470 this standard. Please address the information to the IETF at ietf- 471 ipr@ietf.org. 473 Acknowledgment 475 Funding for the RFC Editor function is provided by the IETF 476 Administrative Support Activity (IASA).