idnits 2.17.1 draft-turner-asymmetrickeyformat-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 and authors Copyright Line does not match the current year -- 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 (February 1, 2009) is 5557 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 551 -- Looks like a reference, but probably isn't: '1' on line 553 ** 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') ** Downref: Normative reference to an Informational draft: draft-ietf-smime-new-asn1 (ref. 'RFCTBD2') == 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-03 Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 6 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 February 1, 2009 3 Intended Status: Standard Track 4 Obsoletes: RFC 5208 (once approved) 5 Expires: August 1, 2010 7 Asymmetric Key Packages 8 draft-turner-asymmetrickeyformat-03.txt 10 Abstract 12 This document defines the syntax for private key information and a 13 content type for it. Private-key information includes a private key 14 for a specified public-key algorithm and a set of attributes. The 15 Cryptographic Message Syntax (CMS), as defined in RFC 3852, can be 16 used to digitally sign, digest, authenticate, or encrypt the 17 asymmetric key format content type. This document obsoletes RFC 18 5208. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. This document may contain material 24 from IETF Documents or IETF Contributions published or made publicly 25 available before November 10, 2008. The person(s) controlling the 26 copyright in some of this material may not have granted the IETF 27 Trust the right to allow modifications of such material outside the 28 IETF Standards Process. Without obtaining an adequate license from 29 the person(s) controlling the copyright in such materials, this 30 document may not be modified outside the IETF Standards Process, and 31 derivative works of it may not be created outside the IETF Standards 32 Process, except to format it for publication as an RFC or to 33 translate it into languages other than English. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF), its areas, and its working groups. Note that 37 other groups may also distribute working documents as Internet- 38 Drafts. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 The list of current Internet-Drafts can be accessed at 46 http://www.ietf.org/ietf/1id-abstracts.txt 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html 50 This Internet-Draft will expire on August 1, 2010. 52 Copyright Notice 54 Copyright (c) 2010 IETF Trust and the persons identified as the 55 document authors. All rights reserved. 57 This document is subject to BCP 78 and the IETF Trust's Legal 58 Provisions Relating to IETF Documents 59 (http://trustee.ietf.org/license-info) in effect on the date of 60 publication of this document. Please review these documents 61 carefully, as they describe your rights and restrictions with respect 62 to this document. Code Components extracted from this document must 63 include Simplified BSD License text as described in Section 4.e of 64 the Trust Legal Provisions and are provided without warranty as 65 described in the Simplified BSD License. 67 1. Introduction 69 This document defines the syntax for private key information and a 70 Cryptographic Message Syntax (CMS) [RFC5652] content type for it. 71 Private-key information includes a private key for a specified 72 public-key algorithm and a set of attributes. The CMS can be used to 73 digitally sign, digest, authenticate, or encrypt the asymmetric key 74 format content 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. Summary of Updates to RFC 5208 89 The following summarizes the updates to [RFC5208]: 91 - Changed the name "PrivateKeyInfo" to "OneAsymmetricKey". This 92 reflects the addition of the public key field to allow both parts 93 of the asymmetric key to be conveyed separately. Not all 94 algorithms will use both fields; however, the publicKey field was 95 added for completeness. 97 - Defined Asymmetric Key Package CMS content type. 99 - Removed redundant IMPLICIT from attributes. 101 - Added publicKey to OneAsymmetricKey and updated the version number. 103 - Added that PKCS#9 attributes may be supported. 105 - Added discussion of compatibility with other private-key formats. 107 - Added requirements for encoding rule set. 109 - Changed imports from PKCS#5 to [RFCTBD1] and [RFCTBD2]. 111 - Replaced ALGORITHM-IDENTIFIER with ALGORITHM from [RFCTBD1]. 113 2. Asymmetric Key Package CMS Content Type 115 The asymmetric key package CMS content type is used to transfer one 116 or more plaintext asymmetric keys from one party to another. An 117 asymmetric key package MAY be encapsulated in one or more CMS 118 protecting content types (see Section 4). Earlier versions of this 119 specification [RFC5208] did not specify a particular encoding rule 120 set, but generators SHOULD use DER [X.690] and receivers SHOULD be 121 prepared to handle BER [X.690] and DER [X.690]. 123 The asymmetric key package content type has the following syntax: 125 ct-asymmetric-key-package CONTENT-TYPE ::= 126 { AsymmetricKeyPackage IDENTIFIED BY id-ct-KP-aKeyPackage } 128 id-ct-KP-aKeyPackage OBJECT IDENTIFIER ::= 129 { TBD } 131 AsymmetricKeyPackage ::= SEQUENCE SIZE (1..MAX) OF OneAsymmetricKey 133 OneAsymmetricKey ::= SEQUENCE { 134 version Version, 135 privateKeyAlgorithm PrivateKeyAlgorithmIdentifier, 136 privateKey PrivateKey, 137 attributes [0] Attributes OPTIONAL, 138 ..., 139 [[2: publicKey [1] PublicKey OPTIONAL ]], 140 ... 141 } 143 PrivateKeyInfo ::= OneAsymmetricKey 144 -- PrivateKeyInfo is used by [P12]. If any items tagged as version 145 -- 2 are used, the version must be v2, else the version should be 146 -- v1. When v1, PrivateKeyInfo is the same as it was in [RFC5208]. 148 Version ::= INTEGER { v1(0), v2(1) } (v1, ..., v2) 150 PrivateKeyAlgorithmIdentifier ::= AlgorithmIdentifier 151 { PUBLIC-KEY, 152 { PrivateKeyAlgorithms } } 154 PrivateKey ::= OCTET STRING 155 -- Content varies based on type of key. The 156 -- algorithm identifier dictates the format of 157 -- the key. 159 PublicKey ::= BIT STRING 160 -- Content varies based on type of key. The 161 -- algorithm identifier dictates the format of 162 -- the key. 164 Attributes ::= SET OF Attribute { { OneAsymmetricKeyAttributes } } 166 The AsymmetricKeyPackage contains one or more OneAsymmetricKey 167 elements. 169 The syntax of OneAsymmetricKey accommodates a version number, an 170 indication of the asymmetric algorithm to be used with the private 171 key, a private key, optional keying material attributes (e.g., 172 userCertificate from [X.520]), and an optional public key. In 173 general, either the public key or the certificate will be present. 174 In very rare cases will both the public key and the certificate be 175 present as this includes two copies of the public key. 176 OneAsymmetricKey is a renamed extension of the PrivateKeyInfo syntax 177 defined in [RFC5208]. The new name better reflects the ability to 178 carry both private and public key components. Backwards 179 compatibility with the original PrivateKeyInfo is preserved via 180 version number. The fields in OneAsymmetricKey are used as follows: 182 - version identifies the version of OneAsymmetricKey. If publicKey 183 is present, then version is set v2 else version is set to v1. 185 - privateKeyAlgorithm identifies the private-key algorithm and 186 optionally contains parameters associated with the asymmetric key. 187 The algorithm is identified by an object identifier (OID) and the 188 format of the parameters depends on the OID, but the 189 PrivateKeyAlgorithms information object set restricts the 190 permissible OIDs. The value placed in privateKeyAlgorithmIdentifier 191 is the value an originator would apply to indicate which algorithm 192 is to be used with the private key. 194 - privateKey is an OCTET STRING whose contents are the value of the 195 private key. The interpretation of the contents is defined in the 196 registration of the private-key algorithm. For example, a DSA key 197 is an INTEGER, an RSA key is represented as RSAPrivateKey as 198 defined in [RFC3447], and an ECC key is represented as ECPrivateKey 199 as defined in [RFCTBD4]. 201 - attributes is OPTIONAL. It contains information corresponding to 202 the public key (e.g., certificates). The attributes field uses the 203 class ATTRIBUTE which is restricted by the 204 OneAsymmetricKeyAttributes information object set. 205 OneAsymmetricKeyAttributes is an open ended set in this document. 206 Others documents can constrain these values. Attributes from 207 [RFC2985] MAY be supported. 209 - publicKey is OPTIONAL. When present, it contains the public key 210 encoded in a BIT STRING. The structure within the bit string, if 211 any, depends on the privateKeyAlgorithm. For example, a DSA key is 212 an INTEGER. Note that RSA public keys are included in RSAPrivateKey 213 (i.e., n and e are present), as per [RFC3447], and ECC public keys 214 are included in ECPrivateKey (i.e., in the publicKey field), as per 215 [RFCTBD4]. 217 3. Encrypted Private Key Info 219 This section gives the syntax for encrypted private-key information, 220 which is used with [P12]. 222 Encrypted private-key information shall have ASN.1 type 223 EncryptedPrivateKeyInfo: 225 EncryptedPrivateKeyInfo ::= SEQUENCE { 226 encryptionAlgorithm EncryptionAlgorithmIdentifier, 227 encryptedData EncryptedData } 229 EncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 230 { CONTENT-ENCRYPTION, 231 { KeyEncryptionAlgorithms } } 233 EncryptedData ::= OCTET STRING 235 The fields in EncryptedPrivateKeyInfo are used as follows: 237 - encryptionAlgorithm identifies the algorithm under which the 238 private-key information is encrypted. Implementations MUST support 239 the TBD algorithm. 241 - encryptedData is the result of encrypting the private-key 242 information (i.e., the PrivateKeyInfo). 244 The encryption process involves the following two steps: 246 1. The private-key information is encoded, yielding an octet string. 247 Generators SHOULD use DER [X.690] and receivers SHOULD be 248 prepared to handle BER [X.690] and DER [X.690] 250 2. The result of step 1 is encrypted with the secret key to give an 251 octet string, the result of the encryption process. 253 4. Protecting the AsymmetricKeyPackage 255 CMS protecting content types, [RFC5652] and [RFC5083], can be used to 256 provide security to the AsymmetricKeyPackage: 258 - SignedData can be used to apply a digital signature to the 259 AsymmetricKeyPackage. 261 - EncryptedData can be used to encrypt the AsymmetricKeyPackage with 262 simple symmetric encryption, where the sender and the receiver 263 already share the necessary encryption key. 265 - EnvelopedData can be used to encrypt the AsymmetricKeyPackage with 266 symmetric encryption, where the sender and the receiver do not 267 share the necessary encryption key. 269 - AuthenticatedData can be used to protect the AsymmetricKeyPackage 270 with message authentication codes, where key management information 271 is handled in a manner similar to EnvelopedData. 273 - AuthEnvelopedData can be used to protect the AsymmetricKeyPackage 274 with algorithms that support authenticated encryption, where key 275 management information is handled in a manner similar to 276 EnvelopedData. 278 5. Other Private-Key Format Considerations 280 This document defines the syntax and the semantics for a content type 281 that exchanges asymmetric private keys. There are two other formats 282 that have been used for the transport of asymmetric private keys: 284 - Personal Information Exchange (PFX) Syntax Standard [P12], which is 285 more commonly referred to as PKCS #12 or simply P12, is a transfer 286 syntax for personal identity information, including private keys, 287 certificates, miscellaneous secrets, and extensions. 288 OneAsymmetricKey, PrivateKeyInfo, and EncryptedPrivateKeyInfo 289 [RFC5208] can be carried in a P12 message. The private key 290 information, OneAsymmetricKey and PrivateKeyInfo, are carried in 291 the P12 keyBag BAG-TYPE. EncryptedPrivateKeyInfo is carried in the 292 P12 pkcs8ShroudedKeyBag BAG-TYPE. In current implementations, the 293 file extensions .pfx and .p12 can be used interchangeably. 295 - Microsoft's private key proprietary transfer syntax. The .pvk file 296 extension is used for local storage. 298 The .pvk and .p12/.pfx formats are not interchangeable; however, 299 conversion tools exist to convert from one format to another. 301 [RFCTBD3] defines the appication/pkcs8 media type and .p8 file 302 extension. 304 To extract the private key information from the AsymmetricKeyPackage, 305 the encapsulating layers need to be removed. At a minimum, the outer 306 ContentInfo [RFC5652] layer needs to be removed. If the 307 AsymmetricKeyPackage is encapsulated in a SignedData [RFC5652], then 308 the SignedData and EncapsulatedContentInfo layers [RFC5652] also need 309 to be removed. The same is true for EnvelopedData, EncryptedData, and 310 AuthenticatedData all from [RFC5652] as well as AuthEnvelopedData 311 from [RFC5083]. Once all the outer layers are removed, there are as 312 many sets of private key information as there are OneAsymmetricKey 313 structures. OneAsymmetricKey and PrivateKeyInfo are the same 314 structure; therefore, either can be saved as a .p8 file or copied in 315 to the P12 KeyBag BAG-TYPE. Removing encapsulating security layers 316 will invalidate any signature and may expose the key to unauthorized 317 disclosure. 319 .p8 files are sometimes PEM encoded. When .p8 files are PEM encoded 320 they use the .pem file extension. PEM encoding is either the Base64 321 encoding [RFC4648] of the DER encoded EncryptedPrivateKeyInfo 322 sandwiched between: 324 -----BEGIN ENCRYPTED PRIVATE KEY----- 325 -----END ENCRYPTED PRIVATE KEY----- 327 or the Base64 encoding [RFC4648] of the DER encoded PrivateKeyInfo 328 sandwiched between: 330 -----BEGIN PRIVATE KEY----- 331 -----END PRIVATE KEY----- 333 6. Security Considerations 335 The security considerations in [RFC5208] also apply to this document. 337 The asymmetric key package contents are not protected. This content 338 type can be combined with a security protocol to protect the contents 339 of the package. 341 7. IANA Considerations 343 None: All identifiers are already registered. Please remove this 344 section prior to publication as an RFC. 346 8. References 348 8.1. Normative References 350 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 351 Requirement Levels", BCP 14, RFC 2119, March 1997. 353 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 354 Encodings", RFC 4648, October 2006. 356 [RFC5208] Kaliski, B., "PKCS #8: Private Key Information Syntax 357 Standard Version 1.2", RFC 5208, May 2008. 359 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 360 5652, September 2009. 362 [RFCTBD1] Schaad, J., and P. Hoffman, "New ASN.1 Modules for PKIX", 363 draft-ietf-pkix-new-asn1-07.txt, work-in-progress. 365 /** 366 RFC Editor: Please replace "RFCTBD1" with "RFC####" where #### is the 367 number of the published RFC. Please do this in both the references 368 and the text. 369 **/ 371 [RFCTBD2] Schaad, J., and P. Hoffman, "New ASN.1 Modules for 372 SMIME", draft-ietf-smime-new-asn1-07.txt, work-in- 373 progress. 375 /** 376 RFC Editor: Please replace "RFCTBD2" with "RFC####" where #### is the 377 number of the published RFC. Please do this in both the references 378 and the text. 379 **/ 381 [RFCTBD3] Jennings C., and J. Fischl "Certificate Management 382 Service for The Session Initiation Protocol (SIP)", 383 draft-ietf-sip-certs-09.txt, work-in-progress. 385 /** 386 RFC Editor: Please replace "RFCTBD3" with "RFC####" where #### is the 387 number of the published RFC. Please do this in both the references 388 and the text. 389 **/ 391 [X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002. 392 Information Technology - Abstract Syntax Notation One. 394 [X.681] ITU-T Recommendation X.681 (2002) | ISO/IEC 8824-2:2002. 395 Information Technology - Abstract Syntax Notation One: 396 Information Object Specification. 398 [X.682] ITU-T Recommendation X.682 (2002) | ISO/IEC 8824-3:2002. 399 Information Technology - Abstract Syntax Notation One: 400 Constraint Specification. 402 [X.683] ITU-T Recommendation X.683 (2002) | ISO/IEC 8824-4:2002. 403 Information Technology - Abstract Syntax Notation One: 404 Parameterization of ASN.1 Specifications. 406 [X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002. 407 Information Technology - ASN.1 encoding rules: 408 Specification of Basic Encoding Rules (BER), Canonical 409 Encoding Rules (CER) and Distinguished Encoding Rules 410 (DER). 412 8.2. Informative References 414 [P12] RSA Laboratories, "PKCS #12 v1.0: Personal Information 415 Exchange Syntax", June 1999. 417 [RFC2985] Nystrom, M., and B. Kaliski, "PKCS #9: Selected Object 418 Classes and Attribute Types Version 2.0", RFC 2985, 419 November 2000. 421 [RFC3447] Jonsson, J., and B. Kaliski, "Public-Key Cryptography 422 Standards (PKCS) #1: RSA Cryptography Specifications 423 Version 2.1", RFC 3447, February 2003. 425 [RFC5083] Housley, R., "Cryptographic Message Syntax (CMS) 426 Authenticated-Enveloped-Data Content Type", RFC 5083, 427 November 2007. 429 [X.520] ITU-T Recommendation X.520 (2005) | ISO/IEC 9594-6:2005, 430 Information technology - Open Systems Interconnection - 431 The Directory: Selected attribute types. 433 [RFCTBD4] Turner, S., and D. Brown, "EC Private Key Info 434 Structure", draft-turner-ecprivatekey-03.txt, work-in- 435 progress. 437 /** 438 RFC Editor: Please replace "RFCTBD4" with "RFC####" where #### is the 439 number of the published RFC. Please do this in both the references 440 and the text. 441 **/ 443 APPENDIX A: ASN.1 Module 445 This annex provides the normative ASN.1 definitions for the 446 structures described in this specification using ASN.1 as defined in 447 [X.680] through [X.683]. 449 AsymmetricKeyPackageModuleV1 450 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 451 smime(16) modules(0) id-mod-asymmetricKeyPkgV1(50) } 453 DEFINITIONS IMPLICIT TAGS ::= 455 BEGIN 457 -- EXPORTS ALL 459 IMPORTS 461 -- FROM New SMIME ASN.1 [RFCTBD2] 463 CONTENT-TYPE 464 FROM CryptographicMessageSyntax-2009 465 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 466 smime(16) modules(0) cms-2004-02(41) } 468 -- From New PKIX ASN.1 [RFCTBD1] 470 Attribute{}, ATTRIBUTE 471 FROM PKIX-CommonTypes-2009 472 { iso(1) identified-organization(3) dod(6) internet(1) 473 security(5) mechanisms(5) pkix(7) id-mod(0) 474 id-mod-pkixCommon-02(57) } 476 -- From New PKIX ASN.1 [RFCTBD1] 478 AlgorithmIdentifier{}, ALGORITHM, PUBLIC-KEY, CONTENT-ENCRYPTION 479 FROM AlgorithmInformation-2009 480 { iso(1) identified-organization(3) dod(6) internet(1) 481 security(5) mechanisms(5) pkix(7) id-mod(0) 482 id-mod-algorithmInformation-02(58) } 484 ; 486 KeyPackageContentTypes CONTENT-TYPE ::= { 487 ct-asymmetric-key-package, 488 ... -- Expect additional content types -- 489 } 490 ct-asymmetric-key-package CONTENT-TYPE ::= 491 { AsymmetricKeyPackage IDENTIFIED BY id-ct-KP-aKeyPackage } 493 id-ct-KP-aKeyPackage OBJECT IDENTIFIER ::= 494 { TBD } 496 AsymmetricKeyPackage ::= SEQUENCE SIZE (1..MAX) OF OneAsymmetricKey 498 OneAsymmetricKey ::= SEQUENCE { 499 version Version, 500 privateKeyAlgorithm PrivateKeyAlgorithmIdentifier, 501 privateKey PrivateKey, 502 attributes [0] Attributes OPTIONAL, 503 ..., 504 [[2: publicKey [1] PublicKey OPTIONAL ]], 505 ... 506 } 508 PrivateKeyInfo ::= OneAsymmetricKey 510 -- PrivateKeyInfo is used by [P12]. If any items tagged as version 511 -- 2 are used, the version must be v2, else the version should be 512 -- v1. When v1, PrivateKeyInfo is the same as it was in [RFC5208]. 514 Version ::= INTEGER {v1(0), v2(1)} (v1, ..., v2) 516 PrivateKeyAlgorithmIdentifier ::= AlgorithmIdentifier 517 { PUBLIC-KEY, 518 { PrivateKeyAlgorithms } } 520 PrivateKey ::= OCTET STRING 521 -- Content varies based on type of key. The 522 -- algorithm identifier dictates the format of 523 -- the key. 525 PublicKey ::= BIT STRING 526 -- Content varies based on type of key. The 527 -- algorithm identifier dictates the format of 528 -- the key. 530 Attributes ::= SET OF Attribute { { OneAsymmetricKeyAttributes } } 532 OneAsymmetricKeyAttributes ATTRIBUTE ::= { 533 ... -- For local profiles 534 } 536 -- An alternate representation that makes full use of ASN.1 537 -- constraints follows. Also note that PUBLIC-KEY needs to be 538 -- imported from the new PKIX ASN.1 Algorithm Information module 539 -- and PrivateKeyAlgorithms needs to be commented out. 541 -- OneAsymmetricKey ::= SEQUENCE { 542 -- version Version, 543 -- privateKeyAlgorithm SEQUENCE { 544 -- algorithm PUBLIC-KEY.&id({PublicKeySet}), 545 -- parameters PUBLIC-KEY.&Params({PublicKeySet} 546 -- {@algorithmIdentifier.algorithm}) 547 -- OPTIONAL} 548 -- privateKey OCTET STRING (CONTAINING 549 -- PUBLIC-KEY.&PrivateKey({PublicKeySet} 550 -- {@KeyValue.algorithm})), 551 -- attributes [0] Attributes OPTIONAL, 552 -- ..., 553 -- [[2: publicKey [1] BIT STRING (CONTAINING 554 -- PUBLIC-KEY.&Params({PublicKeySet} 555 -- {privateKeyAlgorithm.algorithm}) 556 -- OPTIONAL, 557 -- ... 558 -- } 560 EncryptedPrivateKeyInfo ::= SEQUENCE { 561 encryptionAlgorithm EncryptionAlgorithmIdentifier, 562 encryptedData EncryptedData } 564 EncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 565 { CONTENT-ENCRYPTION, 566 { KeyEncryptionAlgorithms } } 568 EncryptedData ::= OCTET STRING -- Encrypted PrivateKeyInfo 570 PrivateKeyAlgorithms ALGORITHM ::= { 571 ... -- Extensible 572 } 574 KeyEncryptionAlgorithms ALGORITHM ::= { 575 ... -- Extensible 576 } 578 END 580 Acknowledgements 582 Many thanks go out to the Burt Kaliski and Jim Randall at RSA. 583 Without the prior version of the document, this one wouldn't exist. 585 I'd also like to thank Pasi Eronen, Russ Housley, Jim Schaad, and 586 Carl Wallace. 588 Author's Address 590 Sean Turner 591 IECA, Inc. 592 3057 Nutley Street, Suite 106 593 Fairfax, VA 22031 594 USA 596 Email: turners@ieca.com