< draft-turner-asymmetrickeyformat-03.txt   draft-turner-asymmetrickeyformat-04.txt >
Network Working Group Sean Turner, IECA Network Working Group Sean Turner, IECA
Internet Draft February 1, 2009 Internet Draft March 8, 2009
Intended Status: Standard Track Intended Status: Standard Track
Obsoletes: RFC 5208 (once approved) Obsoletes: 5208 (once approved)
Expires: August 1, 2010 Expires: September 8, 2010
Asymmetric Key Packages Asymmetric Key Packages
draft-turner-asymmetrickeyformat-03.txt draft-turner-asymmetrickeyformat-04.txt
Abstract Abstract
This document defines the syntax for private key information and a This document defines the syntax for private key information and a
content type for it. Private-key information includes a private key content type for it. Private-key information includes a private key
for a specified public-key algorithm and a set of attributes. The for a specified public-key algorithm and a set of attributes. The
Cryptographic Message Syntax (CMS), as defined in RFC 3852, can be Cryptographic Message Syntax (CMS), as defined in RFC 5652, can be
used to digitally sign, digest, authenticate, or encrypt the used to digitally sign, digest, authenticate, or encrypt the
asymmetric key format content type. This document obsoletes RFC asymmetric key format content type. This document obsoletes RFC
5208. 5208.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
skipping to change at page 2, line 7 skipping to change at page 2, line 7
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on August 1, 2010. This Internet-Draft will expire on September 8, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 37 skipping to change at page 3, line 37
specification [RFC5208] did not specify a particular encoding rule specification [RFC5208] did not specify a particular encoding rule
set, but generators SHOULD use DER [X.690] and receivers SHOULD be set, but generators SHOULD use DER [X.690] and receivers SHOULD be
prepared to handle BER [X.690] and DER [X.690]. prepared to handle BER [X.690] and DER [X.690].
The asymmetric key package content type has the following syntax: The asymmetric key package content type has the following syntax:
ct-asymmetric-key-package CONTENT-TYPE ::= ct-asymmetric-key-package CONTENT-TYPE ::=
{ AsymmetricKeyPackage IDENTIFIED BY id-ct-KP-aKeyPackage } { AsymmetricKeyPackage IDENTIFIED BY id-ct-KP-aKeyPackage }
id-ct-KP-aKeyPackage OBJECT IDENTIFIER ::= id-ct-KP-aKeyPackage OBJECT IDENTIFIER ::=
{ TBD } { joint-iso-itu-t(2) country(16) us(840) organization(1)
gov(101) dod(2) infosec(1) formats(2)
key-package-content-types(78) 5
}
AsymmetricKeyPackage ::= SEQUENCE SIZE (1..MAX) OF OneAsymmetricKey AsymmetricKeyPackage ::= SEQUENCE SIZE (1..MAX) OF OneAsymmetricKey
OneAsymmetricKey ::= SEQUENCE { OneAsymmetricKey ::= SEQUENCE {
version Version, version Version,
privateKeyAlgorithm PrivateKeyAlgorithmIdentifier, privateKeyAlgorithm PrivateKeyAlgorithmIdentifier,
privateKey PrivateKey, privateKey PrivateKey,
attributes [0] Attributes OPTIONAL, attributes [0] Attributes OPTIONAL,
..., ...,
[[2: publicKey [1] PublicKey OPTIONAL ]], [[2: publicKey [1] PublicKey OPTIONAL ]],
skipping to change at page 3, line 50 skipping to change at page 4, line 4
OneAsymmetricKey ::= SEQUENCE { OneAsymmetricKey ::= SEQUENCE {
version Version, version Version,
privateKeyAlgorithm PrivateKeyAlgorithmIdentifier, privateKeyAlgorithm PrivateKeyAlgorithmIdentifier,
privateKey PrivateKey, privateKey PrivateKey,
attributes [0] Attributes OPTIONAL, attributes [0] Attributes OPTIONAL,
..., ...,
[[2: publicKey [1] PublicKey OPTIONAL ]], [[2: publicKey [1] PublicKey OPTIONAL ]],
... ...
} }
PrivateKeyInfo ::= OneAsymmetricKey PrivateKeyInfo ::= OneAsymmetricKey
-- PrivateKeyInfo is used by [P12]. If any items tagged as version -- PrivateKeyInfo is used by [P12]. If any items tagged as version
-- 2 are used, the version must be v2, else the version should be -- 2 are used, the version must be v2, else the version should be
-- v1. When v1, PrivateKeyInfo is the same as it was in [RFC5208]. -- v1. When v1, PrivateKeyInfo is the same as it was in [RFC5208].
Version ::= INTEGER { v1(0), v2(1) } (v1, ..., v2) Version ::= INTEGER { v1(0), v2(1) } (v1, ..., v2, ... )
PrivateKeyAlgorithmIdentifier ::= AlgorithmIdentifier PrivateKeyAlgorithmIdentifier ::= AlgorithmIdentifier
{ PUBLIC-KEY, { PUBLIC-KEY,
{ PrivateKeyAlgorithms } } { PrivateKeyAlgorithms } }
PrivateKey ::= OCTET STRING PrivateKey ::= OCTET STRING
-- Content varies based on type of key. The -- Content varies based on type of key. The
-- algorithm identifier dictates the format of -- algorithm identifier dictates the format of
-- the key. -- the key.
PublicKey ::= BIT STRING PublicKey ::= BIT STRING
-- Content varies based on type of key. The -- Content varies based on type of key. The
-- algorithm identifier dictates the format of -- algorithm identifier dictates the format of
-- the key. -- the key.
Attributes ::= SET OF Attribute { { OneAsymmetricKeyAttributes } } Attributes ::= SET OF Attribute { { OneAsymmetricKeyAttributes } }
The AsymmetricKeyPackage contains one or more OneAsymmetricKey The AsymmetricKeyPackage contains one or more OneAsymmetricKey
elements. elements.
The syntax of OneAsymmetricKey accommodates a version number, an The syntax of OneAsymmetricKey accommodates a version number, an
indication of the asymmetric algorithm to be used with the private indication of the asymmetric algorithm to be used with the private
key, a private key, optional keying material attributes (e.g., key, a private key, optional keying material attributes (e.g.,
userCertificate from [X.520]), and an optional public key. In userCertificate from [X.520]), and an optional public key. In
general, either the public key or the certificate will be present. general, either the public key or the certificate will be present.
In very rare cases will both the public key and the certificate be In very rare cases will both the public key and the certificate be
present as this includes two copies of the public key. present as this includes two copies of the public key.
OneAsymmetricKey is a renamed extension of the PrivateKeyInfo syntax OneAsymmetricKey is a renamed extension of the PrivateKeyInfo syntax
defined in [RFC5208]. The new name better reflects the ability to defined in [RFC5208]. The new name better reflects the ability to
carry both private and public key components. Backwards carry both private and public key components. Backwards
compatibility with the original PrivateKeyInfo is preserved via compatibility with the original PrivateKeyInfo is preserved via
version number. The fields in OneAsymmetricKey are used as follows: version number. The fields in OneAsymmetricKey are used as follows:
- version identifies the version of OneAsymmetricKey. If publicKey - version identifies the version of OneAsymmetricKey. If publicKey
is present, then version is set v2 else version is set to v1. is present, then version is set to v2 else version is set to v1.
- privateKeyAlgorithm identifies the private-key algorithm and - privateKeyAlgorithm identifies the private-key algorithm and
optionally contains parameters associated with the asymmetric key. optionally contains parameters associated with the asymmetric key.
The algorithm is identified by an object identifier (OID) and the The algorithm is identified by an object identifier (OID) and the
format of the parameters depends on the OID, but the format of the parameters depends on the OID, but the
PrivateKeyAlgorithms information object set restricts the PrivateKeyAlgorithms information object set restricts the
permissible OIDs. The value placed in privateKeyAlgorithmIdentifier permissible OIDs. The value placed in privateKeyAlgorithmIdentifier
is the value an originator would apply to indicate which algorithm is the value an originator would apply to indicate which algorithm
is to be used with the private key. is to be used with the private key.
- privateKey is an OCTET STRING whose contents are the value of the - privateKey is an OCTET STRING that contains the value of the
private key. The interpretation of the contents is defined in the private key. The interpretation of the content is defined in the
registration of the private-key algorithm. For example, a DSA key registration of the private-key algorithm. For example, a DSA key
is an INTEGER, an RSA key is represented as RSAPrivateKey as is an INTEGER, an RSA key is represented as RSAPrivateKey as
defined in [RFC3447], and an ECC key is represented as ECPrivateKey defined in [RFC3447], and an ECC key is represented as ECPrivateKey
as defined in [RFCTBD4]. as defined in [RFCTBD4].
- attributes is OPTIONAL. It contains information corresponding to - attributes is OPTIONAL. It contains information corresponding to
the public key (e.g., certificates). The attributes field uses the the public key (e.g., certificates). The attributes field uses the
class ATTRIBUTE which is restricted by the class ATTRIBUTE which is restricted by the
OneAsymmetricKeyAttributes information object set. OneAsymmetricKeyAttributes information object set.
OneAsymmetricKeyAttributes is an open ended set in this document. OneAsymmetricKeyAttributes is an open ended set in this document.
skipping to change at page 5, line 49 skipping to change at page 5, line 51
EncryptionAlgorithmIdentifier ::= AlgorithmIdentifier EncryptionAlgorithmIdentifier ::= AlgorithmIdentifier
{ CONTENT-ENCRYPTION, { CONTENT-ENCRYPTION,
{ KeyEncryptionAlgorithms } } { KeyEncryptionAlgorithms } }
EncryptedData ::= OCTET STRING EncryptedData ::= OCTET STRING
The fields in EncryptedPrivateKeyInfo are used as follows: The fields in EncryptedPrivateKeyInfo are used as follows:
- encryptionAlgorithm identifies the algorithm under which the - encryptionAlgorithm identifies the algorithm under which the
private-key information is encrypted. Implementations MUST support private-key information is encrypted.
the TBD algorithm.
- encryptedData is the result of encrypting the private-key - encryptedData is the result of encrypting the private-key
information (i.e., the PrivateKeyInfo). information (i.e., the PrivateKeyInfo).
The encryption process involves the following two steps: The encryption process involves the following two steps:
1. The private-key information is encoded, yielding an octet string. 1. The private-key information is encoded, yielding an octet string.
Generators SHOULD use DER [X.690] and receivers SHOULD be Generators SHOULD use DER [X.690] and receivers SHOULD be
prepared to handle BER [X.690] and DER [X.690] prepared to handle BER [X.690] and DER [X.690]
skipping to change at page 6, line 49 skipping to change at page 6, line 52
5. Other Private-Key Format Considerations 5. Other Private-Key Format Considerations
This document defines the syntax and the semantics for a content type This document defines the syntax and the semantics for a content type
that exchanges asymmetric private keys. There are two other formats that exchanges asymmetric private keys. There are two other formats
that have been used for the transport of asymmetric private keys: that have been used for the transport of asymmetric private keys:
- Personal Information Exchange (PFX) Syntax Standard [P12], which is - Personal Information Exchange (PFX) Syntax Standard [P12], which is
more commonly referred to as PKCS #12 or simply P12, is a transfer more commonly referred to as PKCS #12 or simply P12, is a transfer
syntax for personal identity information, including private keys, syntax for personal identity information, including private keys,
certificates, miscellaneous secrets, and extensions. certificates, miscellaneous secrets, and extensions.
OneAsymmetricKey, PrivateKeyInfo, and EncryptedPrivateKeyInfo OneAsymmetricKey, PrivateKeyInfo, and EncryptedPrivateKeyInfo can
[RFC5208] can be carried in a P12 message. The private key be carried in a P12 message. The private key information,
information, OneAsymmetricKey and PrivateKeyInfo, are carried in OneAsymmetricKey and PrivateKeyInfo, are carried in the P12 keyBag
the P12 keyBag BAG-TYPE. EncryptedPrivateKeyInfo is carried in the BAG-TYPE. EncryptedPrivateKeyInfo is carried in the P12
P12 pkcs8ShroudedKeyBag BAG-TYPE. In current implementations, the pkcs8ShroudedKeyBag BAG-TYPE. In current implementations, the file
file extensions .pfx and .p12 can be used interchangeably. extensions .pfx and .p12 can be used interchangeably.
- Microsoft's private key proprietary transfer syntax. The .pvk file - Microsoft's private key proprietary transfer syntax. The .pvk file
extension is used for local storage. extension is used for local storage.
The .pvk and .p12/.pfx formats are not interchangeable; however, The .pvk and .p12/.pfx formats are not interchangeable; however,
conversion tools exist to convert from one format to another. conversion tools exist to convert from one format to another.
[RFCTBD3] defines the appication/pkcs8 media type and .p8 file
extension.
To extract the private key information from the AsymmetricKeyPackage, To extract the private key information from the AsymmetricKeyPackage,
the encapsulating layers need to be removed. At a minimum, the outer the encapsulating layers need to be removed. At a minimum, the outer
ContentInfo [RFC5652] layer needs to be removed. If the ContentInfo [RFC5652] layer needs to be removed. If the
AsymmetricKeyPackage is encapsulated in a SignedData [RFC5652], then AsymmetricKeyPackage is encapsulated in a SignedData [RFC5652], then
the SignedData and EncapsulatedContentInfo layers [RFC5652] also need the SignedData and EncapsulatedContentInfo layers [RFC5652] also need
to be removed. The same is true for EnvelopedData, EncryptedData, and to be removed. The same is true for EnvelopedData, EncryptedData, and
AuthenticatedData all from [RFC5652] as well as AuthEnvelopedData AuthenticatedData all from [RFC5652] as well as AuthEnvelopedData
from [RFC5083]. Once all the outer layers are removed, there are as from [RFC5083]. Once all the outer layers are removed, there are as
many sets of private key information as there are OneAsymmetricKey many sets of private key information as there are OneAsymmetricKey
structures. OneAsymmetricKey and PrivateKeyInfo are the same structures. OneAsymmetricKey and PrivateKeyInfo are the same
skipping to change at page 7, line 47 skipping to change at page 7, line 46
-----END ENCRYPTED PRIVATE KEY----- -----END ENCRYPTED PRIVATE KEY-----
or the Base64 encoding [RFC4648] of the DER encoded PrivateKeyInfo or the Base64 encoding [RFC4648] of the DER encoded PrivateKeyInfo
sandwiched between: sandwiched between:
-----BEGIN PRIVATE KEY----- -----BEGIN PRIVATE KEY-----
-----END PRIVATE KEY----- -----END PRIVATE KEY-----
6. Security Considerations 6. Security Considerations
The security considerations in [RFC5208] also apply to this document. Protection of the private-key information is vital to public-key
cryptography. Disclosure of the private-key material to another
entity can lead to masquerades. The encryption algorithm used in the
encryption process must be as 'strong' as the key it is protecting.
The asymmetric key package contents are not protected. This content The asymmetric key package contents are not protected. This content
type can be combined with a security protocol to protect the contents type can be combined with a security protocol to protect the contents
of the package. of the package.
7. IANA Considerations 7. IANA Considerations
None: All identifiers are already registered. Please remove this This specification defines a new media type that IANA is requested to
section prior to publication as an RFC. add to the registry at:
http://www.iana.org/assignments/media-types/application
7.1. Registration of media type application/pkcs8
To: ietf-types@iana.org
Subject: Registration of media type application/pkcs8
Type name: application
Subtype name: pkcs8
Required parameters: None
Optional parameters: None
Encoding considerations: binary
Security considerations: Carries a cryptographic private key
Interoperability considerations:
The PKCS#8 object inside this MIME type MUST be DER-encoded
PrivateKeyInfo.
Published specification: --THIS SPECIFICATION--
/** RFC EDITOR: Replace "--THIS SPECIFICATION--" with the RFC #
assigned to this document. **/
Applications which use this media type:
Any MIME-compliant transport
Additional information:
Magic number(s): None
File extension(s): .p8
Macintosh File Type Code(s):
Person & email address to contact for further information:
Sean Turner <turners@ieca.com>
Restrictions on usage: none
Author:
Sean Turner <turners@ieca.com>
Intended usage: COMMON
Change controller:
The IESG <iesg@ietf.org>
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006. Encodings", RFC 4648, October 2006.
[RFC5208] Kaliski, B., "PKCS #8: Private Key Information Syntax
Standard Version 1.2", RFC 5208, May 2008.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", RFC [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", RFC
5652, September 2009. 5652, September 2009.
[RFCTBD1] Schaad, J., and P. Hoffman, "New ASN.1 Modules for PKIX", [RFCTBD1] Schaad, J., and P. Hoffman, "New ASN.1 Modules for PKIX",
draft-ietf-pkix-new-asn1-07.txt, work-in-progress. draft-ietf-pkix-new-asn1-08, work-in-progress.
/** /**
RFC Editor: Please replace "RFCTBD1" with "RFC####" where #### is the RFC Editor: Please replace "TBD1" with the RFC number being assigned
number of the published RFC. Please do this in both the references to the draft. Please do this in both the references and the text.
and the text.
**/ **/
[RFCTBD2] Schaad, J., and P. Hoffman, "New ASN.1 Modules for [RFCTBD2] Schaad, J., and P. Hoffman, "New ASN.1 Modules for
SMIME", draft-ietf-smime-new-asn1-07.txt, work-in- SMIME", draft-ietf-smime-new-asn1-07, work-in-progress.
progress.
/**
RFC Editor: Please replace "RFCTBD2" with "RFC####" where #### is the
number of the published RFC. Please do this in both the references
and the text.
**/
[RFCTBD3] Jennings C., and J. Fischl "Certificate Management
Service for The Session Initiation Protocol (SIP)",
draft-ietf-sip-certs-09.txt, work-in-progress.
/** /**
RFC Editor: Please replace "RFCTBD3" with "RFC####" where #### is the RFC Editor: Please replace "TBD2" with the RFC number being assigned
number of the published RFC. Please do this in both the references to the draft. Please do this in both the references and the text.
and the text.
**/ **/
[X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002. [X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002.
Information Technology - Abstract Syntax Notation One. Information Technology - Abstract Syntax Notation One.
[X.681] ITU-T Recommendation X.681 (2002) | ISO/IEC 8824-2:2002. [X.681] ITU-T Recommendation X.681 (2002) | ISO/IEC 8824-2:2002.
Information Technology - Abstract Syntax Notation One: Information Technology - Abstract Syntax Notation One:
Information Object Specification. Information Object Specification.
[X.682] ITU-T Recommendation X.682 (2002) | ISO/IEC 8824-3:2002. [X.682] ITU-T Recommendation X.682 (2002) | ISO/IEC 8824-3:2002.
skipping to change at page 9, line 49 skipping to change at page 10, line 40
November 2000. November 2000.
[RFC3447] Jonsson, J., and B. Kaliski, "Public-Key Cryptography [RFC3447] Jonsson, J., and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, February 2003. Version 2.1", RFC 3447, February 2003.
[RFC5083] Housley, R., "Cryptographic Message Syntax (CMS) [RFC5083] Housley, R., "Cryptographic Message Syntax (CMS)
Authenticated-Enveloped-Data Content Type", RFC 5083, Authenticated-Enveloped-Data Content Type", RFC 5083,
November 2007. November 2007.
[RFC5208] Kaliski, B., "PKCS #8: Private Key Information Syntax
Standard Version 1.2", RFC 5208, May 2008.
[X.520] ITU-T Recommendation X.520 (2005) | ISO/IEC 9594-6:2005, [X.520] ITU-T Recommendation X.520 (2005) | ISO/IEC 9594-6:2005,
Information technology - Open Systems Interconnection - Information technology - Open Systems Interconnection -
The Directory: Selected attribute types. The Directory: Selected attribute types.
[RFCTBD4] Turner, S., and D. Brown, "EC Private Key Info [RFCTBD4] Turner, S., and D. Brown, "EC Private Key Info
Structure", draft-turner-ecprivatekey-03.txt, work-in- Structure", draft-turner-ecprivatekey-04, work-in-
progress. progress.
/** /**
RFC Editor: Please replace "RFCTBD4" with "RFC####" where #### is the RFC Editor: Please replace "TBD4" with the RFC number being assigned
number of the published RFC. Please do this in both the references to the draft. Please do this in both the references and the text.
and the text.
**/ **/
APPENDIX A: ASN.1 Module APPENDIX A: ASN.1 Module
This annex provides the normative ASN.1 definitions for the This annex provides the normative ASN.1 definitions for the
structures described in this specification using ASN.1 as defined in structures described in this specification using ASN.1 as defined in
[X.680] through [X.683]. [X.680] through [X.683].
AsymmetricKeyPackageModuleV1 AsymmetricKeyPackageModuleV1
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
skipping to change at page 12, line 8 skipping to change at page 13, line 8
; ;
KeyPackageContentTypes CONTENT-TYPE ::= { KeyPackageContentTypes CONTENT-TYPE ::= {
ct-asymmetric-key-package, ct-asymmetric-key-package,
... -- Expect additional content types -- ... -- Expect additional content types --
} }
ct-asymmetric-key-package CONTENT-TYPE ::= ct-asymmetric-key-package CONTENT-TYPE ::=
{ AsymmetricKeyPackage IDENTIFIED BY id-ct-KP-aKeyPackage } { AsymmetricKeyPackage IDENTIFIED BY id-ct-KP-aKeyPackage }
id-ct-KP-aKeyPackage OBJECT IDENTIFIER ::= id-ct-KP-aKeyPackage OBJECT IDENTIFIER ::=
{ TBD } { joint-iso-itu-t(2) country(16) us(840) organization(1)
gov(101) dod(2) infosec(1) formats(2)
key-package-content-types(78) 5
}
AsymmetricKeyPackage ::= SEQUENCE SIZE (1..MAX) OF OneAsymmetricKey AsymmetricKeyPackage ::= SEQUENCE SIZE (1..MAX) OF OneAsymmetricKey
OneAsymmetricKey ::= SEQUENCE { OneAsymmetricKey ::= SEQUENCE {
version Version, version Version,
privateKeyAlgorithm PrivateKeyAlgorithmIdentifier, privateKeyAlgorithm PrivateKeyAlgorithmIdentifier,
privateKey PrivateKey, privateKey PrivateKey,
attributes [0] Attributes OPTIONAL, attributes [0] Attributes OPTIONAL,
..., ...,
[[2: publicKey [1] PublicKey OPTIONAL ]], [[2: publicKey [1] PublicKey OPTIONAL ]],
... ...
} }
PrivateKeyInfo ::= OneAsymmetricKey PrivateKeyInfo ::= OneAsymmetricKey
-- PrivateKeyInfo is used by [P12]. If any items tagged as version -- PrivateKeyInfo is used by [P12]. If any items tagged as version
-- 2 are used, the version must be v2, else the version should be -- 2 are used, the version must be v2, else the version should be
-- v1. When v1, PrivateKeyInfo is the same as it was in [RFC5208]. -- v1. When v1, PrivateKeyInfo is the same as it was in [RFC5208].
Version ::= INTEGER {v1(0), v2(1)} (v1, ..., v2) Version ::= INTEGER {v1(0), v2(1)} (v1, ..., v2, ...)
PrivateKeyAlgorithmIdentifier ::= AlgorithmIdentifier PrivateKeyAlgorithmIdentifier ::= AlgorithmIdentifier
{ PUBLIC-KEY, { PUBLIC-KEY,
{ PrivateKeyAlgorithms } } { PrivateKeyAlgorithms } }
PrivateKey ::= OCTET STRING PrivateKey ::= OCTET STRING
-- Content varies based on type of key. The -- Content varies based on type of key. The
-- algorithm identifier dictates the format of -- algorithm identifier dictates the format of
-- the key. -- the key.
skipping to change at page 13, line 51 skipping to change at page 15, line 10
... -- Extensible ... -- Extensible
} }
END END
Acknowledgements Acknowledgements
Many thanks go out to the Burt Kaliski and Jim Randall at RSA. Many thanks go out to the Burt Kaliski and Jim Randall at RSA.
Without the prior version of the document, this one wouldn't exist. Without the prior version of the document, this one wouldn't exist.
I'd also like to thank Pasi Eronen, Russ Housley, Jim Schaad, and I'd also like to thank Pasi Eronen, Alfred Hoenes, Russ Housley, Jim
Carl Wallace. Schaad, and Carl Wallace.
Author's Address Author's Address
Sean Turner Sean Turner
IECA, Inc. IECA, Inc.
3057 Nutley Street, Suite 106 3057 Nutley Street, Suite 106
Fairfax, VA 22031 Fairfax, VA 22031
USA USA
Email: turners@ieca.com Email: turners@ieca.com
 End of changes. 28 change blocks. 
59 lines changed or deleted 106 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/