idnits 2.17.1 draft-turner-asymmetrickeyformat-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5208, updated by this document, for RFC5378 checks: 2008-04-16) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (20 October 2009) is 5273 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 425 -- Looks like a reference, but probably isn't: '1' on line 426 ** Obsolete normative reference: RFC 5208 (Obsoleted by RFC 5958) == Outdated reference: A later version (-08) exists of draft-ietf-pkix-new-asn1-07 ** Downref: Normative reference to an Informational draft: draft-ietf-pkix-new-asn1 (ref. 'RFCTBD1') == Outdated reference: A later version (-15) exists of draft-ietf-sip-certs-09 -- Obsolete informational reference (is this intentional?): RFC 3447 (Obsoleted by RFC 8017) == Outdated reference: A later version (-04) exists of draft-turner-ecprivatekey-00 Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 5 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 2009 3 Intended Status: Standard Track 4 Updates: RFC 5208 (once approved) 5 Expires: 20 April 2010 7 Asymmetric Key Packages 8 draft-turner-asymmetrickeyformat-02.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. This document may contain material 14 from IETF Documents or IETF Contributions published or made publicly 15 available before November 10, 2008. The person(s) controlling the 16 copyright in some of this material may not have granted the IETF 17 Trust the right to allow modifications of such material outside the 18 IETF Standards Process. Without obtaining an adequate license from 19 the person(s) controlling the copyright in such materials, this 20 document may not be modified outside the IETF Standards Process, and 21 derivative works of it may not be created outside the IETF Standards 22 Process, except to format it for publication as an RFC or to 23 translate it into languages other than English. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html 41 This Internet-Draft will expire on 20 April 2010. 43 Copyright Notice 45 Copyright (c) 2009 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents in effect on the date of 50 publication of this document (http://trustee.ietf.org/license-info). 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. 54 Abstract 56 This document defines the syntax for private key information and a 57 content type for it. Private-key information includes a private key 58 for a specified public-key algorithm and a set of attributes. The 59 Cryptographic Message Syntax (CMS), as defined in RFC 3852, can be 60 used to digitally sign, digest, authenticate, or encrypt the 61 asymmetric key format content type. This document updates RFC 5208. 63 1. Introduction 65 This document defines the syntax for private key information and a 66 Cryptographic Message Syntax (CMS) [RFC5652] content type for it. 67 Private-key information includes a private key for a specified 68 public-key algorithm and a set of attributes. The CMS can be used to 69 digitally sign, digest, authenticate, or encrypt the asymmetric key 70 format content type. This document updates PKCS#8 v1.2 [RFC5208] 71 sections 5 and 7, and it adds two new sections; the first covers 72 protecting the Asymmetric Key Content Type, and the second discusses 73 compatibility with other private-key formats. 75 1.1. Requirements Terminology 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 79 document are to be interpreted as described in [RFC2119]. 81 1.2. ASN.1 Syntax Notation 83 The key package is defined using ASN.1 [X.680], [X.681], [X.682], and 84 [X.683]. 86 1.3. Summary of Updates to RFC 5208 88 The following summarizes the updates to [RFC5208]: 90 - Changed the name "PrivateKeyInfo" to "OneAsymmetricKey". This 91 reflects the addition of the public key field to allow both parts 92 of the asymmetric key to be conveyed separately. Not all 93 algorithms will use both fields; however, the publicKey field was 94 added for completeness. 96 - Defined Asymmetric Key Package CMS content type. 98 - Removed redundant IMPLICIT from attributes. 100 - Added publicKey to OneAsymmetricKey and updated the version number. 102 - Added that PKCS#9 attributes may be supported. 104 - Added discussion of compatibility with other private-key formats. 106 - Added requirements for encoding rule set. 108 - Changed imports from PKCS#5 to [RFCTBD3]. 110 2. Asymmetric Key Package CMS Content Type 112 This section updates section 5 of [RFC5208]. 114 The asymmetric key package CMS content type is used to transfer one 115 or more plaintext asymmetric keys from one party to another. An 116 asymmetric key package MAY be encapsulated in one or more CMS 117 protecting content types (see Section 4). Earlier versions of this 118 specification [RFC5208] did not specify a particular encoding rule 119 set, but generators SHOULD use DER [X.690] and receivers SHOULD be 120 prepared to handle BER [X.690] and DER [X.690]. 122 The asymmetric key package content type has the following syntax: 124 PKCS7-CONTENT-TYPE ::= TYPE-IDENTIFIER 126 asymmetric-key-package PKCS7-CONTENT-TYPE ::= 127 { AsymmetricKeyPackage IDENTIFIED BY id-ct-KP-aKeyPackage } 129 id-ct-KP-aKeyPackage OBJECT IDENTIFIER ::= 130 { TBD } 132 AsymmetricKeyPackage ::= SEQUENCE SIZE (1..MAX) OF OneAsymmetricKey 134 OneAsymmetricKey ::= SEQUENCE { 135 version Version, 136 privateKeyAlgorithm PrivateKeyAlgorithmIdentifier, 137 privateKey PrivateKey, 138 attributes [0] Attributes OPTIONAL, 139 publicKey [1] PublicKey OPTIONAL 140 } 142 PrivateKeyInfo ::= OneAsymmetricKey 144 -- PrivateKeyInfo is used by [P12]. If version is set to 1, 145 -- publicKey MUST be absent. When v1, PrivateKeyInfo is the same 146 -- as it was in [RFC5208]. 148 Version ::= INTEGER { v1(0), v2(1) } (v1, v2,...) 150 PrivateKeyAlgorithmIdentifier ::= AlgorithmIdentifier 151 { { PrivateKeyAlgorithms } } 153 PrivateKey ::= OCTET STRING 154 -- Content varies based on type of key. The 155 -- algorithm identifier dictates the format of 156 -- the key. 158 PublicKey ::= BIT STRING 159 -- Content varies based on type of key. The 160 -- algorithm identifier dictates the format of 161 -- the key. 163 Attributes ::= Set of Attribute 165 The AsymmetricKeyPackage contains one or more OneAsymmetricKey 166 elements. 168 The syntax of OneAsymmetricKey accommodates a version number, an 169 indication of the asymmetric algorithm to be used with the private 170 key, a private key, optional keying material attributes (e.g., 171 userCertificate from [X.520]), and an optional public key. In 172 general, either the public key or the certificate will be present. 173 In very rare cases will both the public key and the certificate be 174 present as this includes two copies of the public key. 175 OneAsymmetricKey is a renamed extension of the PrivateKeyInfo syntax 176 defined in [RFC5208]. The new name better reflects the ability to 177 carry both private and public key components. Backwards 178 compatibility with the original PrivateKeyInfo is preserved via 179 version number. The fields in OneAsymmetricKey are used as follows: 181 - version identifies the version of OneAsymmetricKey. If publicKey 182 is present, then version is set 2 else version is set to 1. 184 - privateKeyAlgorithm identifies the private-key algorithm and 185 optionally contains parameters associated with the asymmetric key. 186 The algorithm is identified by an object identifier (OID) and the 187 format of the parameters depends on the OID. The value placed in 188 privateKeyAlgorithmIdentifier is the value an originator would 189 apply to indicate which algorithm is to be used with the private 190 key. 192 - privateKey is an OCTET STRING whose contents are the value of the 193 private key. The interpretation of the contents is defined in the 194 registration of the private-key algorithm. For example, a DSA key 195 is an INTEGER, an RSA key is represented as RSAPrivateKey as 196 defined in [RFC3447], and an ECC key is represented as ECPrivateKey 197 as defined in [RFCTBD2]. 199 - attributes is optional. It contains information corresponding to 200 the public key (e.g., certificates). The attributes field uses the 201 class ATTRIBUTE which is restricted by the SupportedAttributes 202 parameterized type. SupportedAttributes is an open ended set in 203 this document. Others documents can constrain these values. 204 Attributes from [RFC2985] MAY be supported. 206 - publicKey is optional. When present, it contains the public key 207 encoded as an OCTET STRING. The structure within the octet string, 208 if any, depends on the privateKeyAlgorithm. For example, a DSA key 209 is an INTEGER. Other documents may define additional private key 210 formats. Note that RSA public keys are included in RSAPrivateKey 211 (i.e., n and e are present), as per [RFC3447], and ECC public keys 212 are included in ECPrivateKey (i.e., in the publicKey field), as per 213 [RFCTBD2]. 215 3. Protecting the AsymmetricKeyPackage 217 CMS protecting content types, [RFC5652] and [RFC5083], can be used to 218 provide security to the AsymmetricKeyPackage: 220 - SignedData can be used to apply a digital signature to the 221 AsymmetricKeyPackage. 223 - EncryptedData can be used to encrypt the AsymmetricKeyPackage to 224 provide confidentiality but does not distribute the content 225 encryption keys. 227 - EnvelopedData can be used to encrypt the AsymmetricKeyPackage with 228 simple symmetric encryption, where the sender and the receiver 229 already share the necessary encryption key. 231 - AuthenticatedData can be used to protect the AsymmetricKeyPackage 232 with message authentication codes, where key management information 233 is handled in a manner similar to EnvelopedData. 235 - AuthEnvelopedData can be used to protect the AsymmetricKeyPackage 236 with algorithms that support authenticated encryption, where key 237 management information is handled in a manner similar to 238 EnvelopedData. 240 4. Other Private-Key Format Considerations 242 This document defines the syntax and the semantics for a content type 243 that exchanges asymmetric private keys. There are two other formats 244 that have been used for the transport of asymmetric private keys: 246 - Personal Information Exchange (PFX) Syntax Standard [P12], which is 247 more commonly referred to as PKCS #12 or simply P12, is a transfer 248 syntax for personal identity information, including private keys, 249 certificates, miscellaneous secrets, and extensions. 250 OneAsymmetricKey, PrivateKeyInfo, and EncryptedPrivateKeyInfo 251 [RFC5208] can be carried in a P12 message. The private key 252 information, OneAsymmetricKey and PrivateKeyInfo, are carried in 253 the P12 keyBag BAG-TYPE. EncryptedPrivateKeyInfo is carried in the 254 P12 pkcs8ShroudedKeyBag BAG-TYPE. In current implementations, the 255 file extensions .pfx and .p12 can be used interchangeably. 257 - Microsoft's private key proprietary transfer syntax. The .pvk file 258 extension is used for local storage. 260 The .pvk and .p12/.pfx formats are not interchangeable; however, 261 conversion tools exist to convert from one format to another. 263 [RFCTBD3] defines the appication/pkcs8 media type and .p8 file 264 extension. 266 To extract the private key information from the AsymmetricKeyPackage, 267 the encapsulating layers need to be removed. At a minimum, the outer 268 ContentInfo [RFC5652] layer needs to be removed. If the 269 AsymmetricKeyPackage is encapsulated in a SignedData [RFC5652], then 270 the SignedData and EncapsulatedContentInfo layers [RFC5652] also need 271 to be removed. The same is true for EnvelopedData, EncryptedData, and 272 AuthenticatedData all from [RFC5652] as well as AuthEnvelopedData 273 from [RFC5083]. Once all the outer layers are removed, there are as 274 many sets of private key information as there are OneAsymmetricKey 275 structures. OneAsymmetricKey and PrivateKeyInfo are the same 276 structure; therefore, either can be saved as a .p8 file or copied in 277 to the P12 KeyBack BAG-TYPE. Removing encapsulating security layers 278 will invalidate any signature and may expose the key to unauthorized 279 disclosure. 281 .p8 files are sometimes PEM encoded. When .p8 files are PEM encoded 282 they use the .pem file extension. PEM encoding is the Base64 283 encoding [RFC2045] of either the DER encoded EncryptedPrivateKeyInfo 284 sandwiched between: 286 -----BEGIN ENCRYPTED PRIVATE KEY----- 287 -----END ENCRYPTED PRIVATE KEY----- 289 or the PrivateKeyInfo or the OneAsymmetricKey sandwiched between: 291 -----BEGIN PRIVATE KEY----- 292 -----END PRIVATE KEY----- 294 5. Security Considerations 296 The security considerations in [RFC5208] also apply to this document. 298 The asymmetric key package contents are not protected. This content 299 type can be combined with a security protocol to protect the contents 300 of the package. 302 6. IANA Considerations 304 None: All identifiers are already registered. Please remove this 305 section prior to publication as an RFC. 307 7. References 309 7.1. Normative References 311 [RFC2045] Freed, .N, and N. Borenstein, "Multipurpose Internet Mail 312 Extensions (MIME) Part One: Format of Internet Message 313 Bodies", RFC 2045, November 1996. 315 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 316 Requirement Levels", BCP 14, RFC 2119, March 1997. 318 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 319 5652, September 2009. 321 [RFC5208] Kaliski, B., "PKCS #8: Private Key Information Syntax 322 Standard Version 1.2", RFC 5208, May 2008. 324 [RFCTBD1] Schaad, J., and P. Hoffman, "New ASN.1 Modules for PKIX", 325 draft-ietf-pkix-new-asn1-07.txt, work-in-progress. 327 [RFCTBD3] Jennings C., and J. Fischl "Certificate Management 328 Service for The Session Initiation Protocol (SIP)", 329 draft-ietf-sip-certs-09.txt, work-in-progress. 331 [X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002. 332 Information Technology - Abstract Syntax Notation One. 334 [X.681] ITU-T Recommendation X.681 (2002) | ISO/IEC 8824-2:2002. 335 Information Technology - Abstract Syntax Notation One: 336 Information Object Specification. 338 [X.682] ITU-T Recommendation X.682 (2002) | ISO/IEC 8824-3:2002. 339 Information Technology - Abstract Syntax Notation One: 340 Constraint Specification. 342 [X.683] ITU-T Recommendation X.683 (2002) | ISO/IEC 8824-4:2002. 343 Information Technology - Abstract Syntax Notation One: 344 Parameterization of ASN.1 Specifications. 346 [X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002. 347 Information Technology - ASN.1 encoding rules: 348 Specification of Basic Encoding Rules (BER), Canonical 349 Encoding Rules (CER) and Distinguished Encoding Rules 350 (DER). 352 7.2. Non-Normative References 354 [P12] RSA Laboratories, "PKCS #12 v1.0: Personal Information 355 Exchange Syntax", June 1999. 357 [RFC2985] Nystrom, M., and B. Kaliski, "PKCS #9: Selected Object 358 Classes and Attribute Types Version 2.0", RFC 2985, 359 November 2000. 361 [RFC3447] Jonsson, J., and B. Kaliski, "Public-Key Cryptography 362 Standards (PKCS) #1: RSA Cryptography Specifications 363 Version 2.1", RFC 3447, February 2003. 365 [RFC5083] Housley, R., "Cryptographic Message Syntax (CMS) 366 Authenticated-Enveloped-Data Content Type", RFC 5083, 367 November 2007. 369 [X.520] ITU-T Recommendation X.520 (2005) | ISO/IEC 9594-6:2005, 370 Information technology - Open Systems Interconnection - 371 The Directory: Selected attribute types. 373 [RFCTBD2] Turner, S., and D. Brown, "EC Private Key Info 374 Structure", draft-turner-ecprivatekey-00.txt, work-in- 375 progress. 377 APPENDIX A: ASN.1 Module 379 This annex provides the normative ASN.1 definitions for the 380 structures described in this specification using ASN.1 as defined in 381 [X.680] through [X.683]. 383 AsymmetricKeyPackageModulev1 { tbd } 385 DEFINITIONS IMPLICIT TAGS ::= 387 BEGIN 389 -- EXPORTS ALL 390 IMPORTS NOTHING 392 Attribute{}, ATTRIBUTE 393 FROM PKIX-CommonTypes-2009 -- FROM [RFCTBD1] 394 { iso(1) identified-organization(3) dod(6) internet(1) 395 security(5) mechanisms(5) pkix(7) id-mod(0) 396 id-mod-pkixCommon-02(57) } 398 AlgorithmIdentifier{} 399 FROM AlgorithmInformation-2009 -- FROM [RFCTBD1] 400 { iso(1) identified-organization(3) dod(6) internet(1) 401 security(5) mechanisms(5) pkix(7) id-mod(0) 402 id-mod-algorithmInformation-02(58) } 404 ; 406 PKCS7-CONTENT-TYPE ::= TYPE-IDENTIFIER 408 KeyPackageContentTypes PKCS7-CONTENT-TYPE ::= { 409 asymmetric-key-package, 410 ... -- Expect additional content types -- 411 } 413 asymmetric-key-package PKCS7-CONTENT-TYPE ::= 414 { AsymmetricKeyPackage IDENTIFIED BY id-ct-KP-aKeyPackage } 416 id-ct-KP-aKeyPackage OBJECT IDENTIFIER ::= 417 { TBD } 419 AsymmetricKeyPackage ::= SEQUENCE SIZE (1..MAX) OF OneAsymmetricKey 421 OneAsymmetricKey ::= SEQUENCE { 422 version Version, 423 privateKeyAlgorithm PrivateKeyAlgorithmIdentifier, 424 privateKey PrivateKey, 425 attributes [0] Attributes OPTIONAL, 426 publicKey [1] PublicKey OPTIONAL 427 } 429 PrivateKeyInfo ::= OneAsymmetricKey 431 -- PrivateKeyInfo is used by [P12]. If version is set to 1, 432 -- publicKey MUST be absent. When v1, PrivateKeyInfo is the same 433 -- as it was in [RFC5208]. 435 Version ::= INTEGER {v1(0), v2(1)} (v1, v2,...) 437 PrivateKeyAlgorithmIdentifier ::= AlgorithmIdentifier 438 { { PrivateKeyAlgorithms } } 439 PrivateKey ::= OCTET STRING 440 -- Content varies based on type of key. The 441 -- algorithm identifier dictates the format of 442 -- the key. 444 PublicKey ::= BIT STRING 445 -- Content varies based on type of key. The 446 -- algorithm identifier dictates the format of 447 -- the key. 449 Attributes ::= Set of Attribute { { SupportedAttributes } } 451 SupportedAttributes ATTRIBUTE :: { 452 ... -- For local profiles 453 } 455 EncryptedPrivateKeyInfo ::= SEQUENCE { 456 encryptionAlgorithm EncryptionAlgorithmIdentifier, 457 encryptedData EncryptedData } 459 EncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 460 { { KeyEncryptionAlgorithms } } 462 EncryptedData ::= OCTET STRING -- Encrypted PrivateKeyInfo 464 PrivateKeyAlgorithms ALGORITHM-IDENTIFIER ::= { 465 ... -- Extensible 466 } 468 KeyEncryptionAlgorithms ALGORITHM-IDENTIFIER ::= { 469 ... -- Extensible 470 } 472 END 474 Acknowledgements 476 Many thanks go out to the Burt Kaliski and Jim Randall at RSA. 477 Without the prior version of the document, this one wouldn't exist. 479 We'd also like to thank Pasi Eronen, Russ Housley, and Carl Wallace. 481 Author's Address 483 Sean Turner 484 IECA, Inc. 485 3057 Nutley Street, Suite 106 486 Fairfax, VA 22031 487 USA 489 Email: turners@ieca.com