idnits 2.17.1 draft-turner-asymmetrickeyformat-01.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 464. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 475. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 482. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 488. 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 (30 October 2008) is 5650 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 389 -- Looks like a reference, but probably isn't: '1' on line 390 ** Obsolete normative reference: RFC 3852 (Obsoleted by RFC 5652) -- Obsolete informational reference (is this intentional?): RFC 3447 (Obsoleted by RFC 8017) -- Obsolete informational reference (is this intentional?): RFC 5208 (Obsoleted by RFC 5958) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 11 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 30 October 2008 3 Intended Status: Standard Track 4 Obsoletes: RFC 5208 (once approved) 5 Expires: 30 April 2009 7 Asymmetric Key Packages 8 draft-turner-asymmetrickeyformat-01.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 30 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.....................................5 57 4. Protecting the AsymmetricKeyPackage............................5 58 5. Other Considerations...........................................6 59 6. Security Considerations........................................6 60 7. IANA Considerations............................................7 61 8. References.....................................................7 62 8.1. Normative References......................................7 63 8.2. Non-Normative References..................................7 64 APPENDIX A: ASN.1 Module..........................................9 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 PKCS#8 v1.2 [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 CMS Content Type 103 The asymmetric key package CMS content type is used to transfer one 104 or 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 attributes [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's is an INTEGER ECDSA's is an 139 -- INTEGER, and RSA is as per [RFC3447]. 141 PublicKey ::= OCTET STRING 142 -- Content varies based on type of key. The 143 -- algorithm identifier dictates the format of 144 -- the key. DSA is an INTEGER, ECDSA is an OCTET 145 -- STRING, and RSA is a sequence of two INTEGERs 146 -- [PKI-ALG]. 148 Attributes ::= Set of Attribute 150 The AsymmetricKeyPackage contains one or more OneAsymmetricKey 151 elements. The syntax of OneAsymmetricKey accommodates a version 152 number, an indication of the algorithm to be used with the private 153 key, a private key, and optionally keying material attributes (e.g., 154 certificates) and a public key. In general, either the public key or 155 the certificate will be present. In very rare cases will both the 156 public key and the certificate be present as this includes two copies 157 of the public key. The fields in OneAsymmetricKey are used as 158 follows: 160 - version identifies version of the asymmetric key package content 161 structure. For this version of the specification, version MUST be 162 v1 if the publicKey field is absent and it MUST be set to v2 if the 163 publicKey field is present. 165 - privateKeyAlgorithm identifies the private key algorithm and 166 optionally contains parameters associated with the asymmetric key. 167 The algorithm is identified by an OID and the parameters format 168 depends on the OID. The value placed in 169 privateKeyAlgorithmIdentifier is the value an originator would 170 apply to indicate which algorithm was used. 172 - privateKey is an OCTET STRING whose contents is the DER encoded 173 private key. The interpretation of the contents is defined in the 174 registration of the private-key algorithm. 176 - attributes is optional. It contains information corresponding to 177 the public key (e.g., certificates). The attributes field uses the 178 class ATTRIBUTE which is restricted by the SupportedAttributes 179 parameterized type. SupportedAttributes is an open ended set in 180 this document. Others documents can constrain these values. 181 Attributes from [RFC2985] MAY be supported. 183 - publicKey is optional. When present, it contains the public key 184 encoded as an OCTET STRING. The structure within the octet string, 185 if any, depends on the privateKeyAlgorithm. 187 3. Encrypted Private Key Info 189 This section gives the syntax for encrypted private-key information, 190 which is used with [P12]. 192 Encrypted private-key information shall have ASN.1 type 193 EncryptedPrivateKeyInfo: 195 EncryptedPrivateKeyInfo ::= SEQUENCE { 196 encryptionAlgorithm EncryptionAlgorithmIdentifier, 197 encryptedData EncryptedData } 199 EncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 200 { { KeyEncryptionAlgorithms } } 202 EncryptedData ::= OCTET STRING 204 The EncAsymmetricKeyPackage contains one or more 205 EncryptedPrivateKeyInfo elements. The fields in 206 EncryptedPrivateKeyInfo are used as follows: 208 - encryptionAlgorithm identifies the algorithm under which the 209 private-key information is encrypted. Implementations MUST support 210 the TBD algorithm. 212 - encryptedData is the result of encrypting the private-key 213 information (i.e., the PrivateKeyInfo). 215 The encryption process involves the following two steps: 217 1. The private-key information is BER encoded, yielding an octet 218 string. 220 2. The result of step 1 is encrypted with the secret key to give an 221 octet string, the result of the encryption process. 223 4. Protecting the AsymmetricKeyPackage 225 CMS [RFC3852] and [RFC5083] protecting content types can be used to 226 provide security to the AsymmetricKeyPackage: 228 - SignedData can be used to apply a digital signature to the 229 AsymmetricKeyPackage. 231 - EncryptedData can be used to encrypt the AsymmetricKeyPackage to 232 provide confidentiality but does not distribute the content 233 encryption keys. 235 - EnvelopedData can be used to encrypt the AsymmetricKeyPackage with 236 simple symmetric encryption, where the sender and the receiver 237 already share the necessary encryption key. 239 - AuthenticatedData can be used to protect the AsymmetricKeyPackage 240 with message authentication codes, where key management information 241 is handled in a manner similar to EnvelopedData. 243 - AuthEnvelopedData can be used to protect the AsymmetricKeypackage 244 with algorithms that support authenticated encryption, where key 245 management information is handled in a manner similar to 246 EnvelopedData. 248 5. Other Considerations 250 This document defines the syntax and the semantics for content types 251 that exchange asymmetric keys. There are two other standards for 252 transporting asymmetric private keys: 254 - Personal Information Exchange (PFX) or more commonly referred to as 255 P12 [P12], is a transfer syntax for personal identity information, 256 including private keys, certificates, miscellaneous secrets, and 257 extensions. Both PrivateKeyInfo and EncryptedPrivateKeyInfo can be 258 carried in a P12 message. 260 - Microsoft's Exchange Security format, which is a proprietary 261 format. 263 When locally storing private keys, the file format is either a DER 264 encoded file with the file extension .p12 or a PEM encoded file with 265 the file extension .pem. 267 When the private key is a character string, the OCTET STRING contains 268 an embedded UTF8String. 270 6. Security Considerations 272 Protection of the private-key information is vital to public-key 273 cryptography. Disclosure of the private-key material to another 274 entity can lead to masquerades. The encryption algorithm used in the 275 encryption process must be as 'strong' as the key it is protecting. 277 The asymmetric key package contents are not protected. This content 278 type can be combined with a security protocol to protect the contents 279 of the package. 281 The encrypted asymmetric key package contents are protected; as noted 282 above the encryption algorithm must be as 'strong' as the key it is 283 protecting. 285 7. IANA Considerations 287 None: All identifiers are already registered. Please remove this 288 section prior to publication as an RFC. 290 8. References 292 8.1. Normative References 294 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 295 Requirement Levels", BCP 14, RFC 2119, March 1997. 297 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", RFC3852, 298 July 2004. 300 [X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002. 301 Information Technology - Abstract Syntax Notation One. 303 [X.681] ITU-T Recommendation X.681 (2002) | ISO/IEC 8824-2:2002. 304 Information Technology - Abstract Syntax Notation One: Information 305 Object Specification. 307 [X.682] ITU-T Recommendation X.682 (2002) | ISO/IEC 8824-3:2002. 308 Information Technology - Abstract Syntax Notation One: Constraint 309 Specification. 311 [X.683] ITU-T Recommendation X.683 (2002) | ISO/IEC 8824-4:2002. 312 Information Technology - Abstract Syntax Notation One: 313 Parameterization of ASN.1 Specifications. 315 [X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002. 316 Information Technology - ASN.1 encoding rules: Specification of Basic 317 Encoding Rules (BER), Canonical Encoding Rules (CER) and 318 Distinguished Encoding Rules (DER). 320 8.2. Non-Normative References 322 [P12] RSA Laboratories, "PKCS #12 v1.0: Personal Information Exchange 323 Syntax", June 1999. 325 [RFC2985] Nystrom, M., and B. Kaliski, "PKCS #9: Selected Object 326 Classes and Attribute Types Version 2.0", RFC 2985, November 2000. 328 [RFC3447] Jonsson, J., and B. Kaliski, " Public-Key Cryptography 329 Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", 330 RFC 3447, February 2003. 332 [RFC5208] Kaliski, B., "PKCS #8: Private Key Information Syntax 333 Standard Version 1.2", RFC 5208, May 2008. 335 [RFC5083] Housley, R., "Cryptographic Message Syntax (CMS) 336 Authenticated-Enveloped-Data Content Type", RFC 5083, November 2007. 338 [PKI-ALG] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 339 "Elliptic Curve Cryptography Subject Public Key Information", draft- 340 ietf-pkix-ecc-subpubkeyinfo, work-in-progress. 342 APPENDIX A: ASN.1 Module 344 This annex provides the normative ASN.1 definitions for the 345 structures described in this specification using ASN.1 as defined in 346 [X.680] through [X.683]. 348 AsymmetricKeyPackageModulev1 { tbd } 350 DEFINITIONS IMPLICIT TAGS ::= 352 BEGIN 354 -- EXPORTS ALL 356 IMPORTS NOTHING 358 Attribute{}, ATTRIBUTE, AlgorithmIdentifier{} 359 FROM PKIX-CommonTypes 360 { iso(1) identified-organization(3) dod(6) internet(1) 361 security(5) mechanisms(5) pkix(7) id-mod(0) 362 id-mod-pkixCommon(43) } 364 id-aes128-wrap, id-aes192-wrap, id-aes1256-wrap 365 FROM CMSAesRsaesOaep 366 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 367 pkcs-9(9) smime(16) modules(0) id-mod-cms-aes(19) } 369 ; 371 PKCS7-CONTENT-TYPE ::= TYPE-IDENTIFIER 373 KeyPackageContentTypes PKCS7-CONTENT-TYPE ::= { 374 asymmetric-key-package | 375 ... -- Expect additional content types -- 376 } 378 asymmetric-key-package PKCS7-CONTENT-TYPE ::= 379 { AsymmetricKeyPackage IDENTIFIED BY id-ct-KP-aKeyPackage } 381 id-ct-KP-aKeyPackage OBJECT IDENTIFIER ::= 382 { TBD } 384 AsymmetricKeyPackage ::= SEQUENCE SIZE (1..MAX) OF OneAsymmetricKey 385 OneAsymmetricKey ::= SEQUENCE { 386 version Version, 387 privateKeyAlgorithm PrivateKeyAlgorithmIdentifier, 388 privateKey PrivateKey, -- DER encoded 389 attributes [0] Attributes OPTIONAL, 390 publicKey [1] PublicKey OPTIONAL } 392 PrivateKeyInfo ::= OneAsymmetricKey 394 Version ::= INTEGER {v1(0), v2(1)} (v1, v2,...) 396 PrivateKeyAlgorithmIdentifier ::= AlgorithmIdentifier 397 { { PrivateKeyAlgorithms } } 399 PrivateKey ::= OCTET STRING -- Content varies based on type of key 400 -- DSA is INTEGER, ECDSA is ECPublicKey 402 PublicKey ::= OCTET STRING 404 Attributes ::= Set of Attribute { { SupportAttributes } } 406 SupportedAttributes ATTRIBUTE :: { 407 ... -- For local profiles 408 } 410 EncryptedPrivateKeyInfo ::= SEQUENCE { 411 encryptionAlgorithm EncryptionAlgorithmIdentifier, 412 encryptedData EncryptedData } 414 EncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 415 { { KeyEncryptionAlgorithms } } 417 EncryptedData ::= OCTET STRING -- Encrypted PrivateKeyInfo 419 PrivateKeyAlgorithms ALGORITHM-IDENTIFIER ::= { 420 ... -- Extensible 421 } 423 KeyEncryptionAlgorithms ALGORITHM-IDENTIFIER ::= { 424 id-aes128-wrap | 425 id-aes192-wrap | 426 id-aes256-wrap, 427 ... -- Extensible 428 } 430 END 432 Acknowledgements 434 Many thanks go out to the Burt Kaliski and Jim Randall at RSA. 435 Without the prior version of the document, this one wouldn't exist. 437 We'd also like to thank Pasi Eronen and Russ Housley. 439 Author's Address 441 Sean Turner 443 IECA, Inc. 444 3057 Nutley Street, Suite 106 445 Fairfax, VA 22031 446 USA 448 Email: turners@ieca.com 450 Full Copyright Statement 452 Copyright (C) The IETF Trust (2008). 454 This document is subject to the rights, licenses and restrictions 455 contained in BCP 78, and except as set forth therein, the authors 456 retain all their rights. 458 This document and the information contained herein are provided on an 459 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 460 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 461 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 462 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 463 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 464 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 466 Intellectual Property 468 The IETF takes no position regarding the validity or scope of any 469 Intellectual Property Rights or other rights that might be claimed to 470 pertain to the implementation or use of the technology described in 471 this document or the extent to which any license under such rights 472 might or might not be available; nor does it represent that it has 473 made any independent effort to identify any such rights. Information 474 on the procedures with respect to rights in RFC documents can be 475 found in BCP 78 and BCP 79. 477 Copies of IPR disclosures made to the IETF Secretariat and any 478 assurances of licenses to be made available, or the result of an 479 attempt made to obtain a general license or permission for the use of 480 such proprietary rights by implementers or users of this 481 specification can be obtained from the IETF on-line IPR repository at 482 http://www.ietf.org/ipr. 484 The IETF invites any interested party to bring to its attention any 485 copyrights, patents or patent applications, or other proprietary 486 rights that may cover technology that may be required to implement 487 this standard. Please address the information to the IETF at ietf- 488 ipr@ietf.org. 490 Acknowledgment 492 Funding for the RFC Editor function is provided by the IETF 493 Administrative Support Activity (IASA).