GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7292

Table of Contents

Internet Engineering Task Force (IETF) K. Moriarty, Ed. Request for Comments: 7292 EMC Category: Informational M. Nystrom ISSN: 2070-1721 Microsoft Corporation

                                                          S. Parkinson
                                                              A. Rusch
                                                              M. Scott
                                                                   RSA
                                                             July 2014
        PKCS #12: Personal Information Exchange Syntax v1.1

Abstract

 PKCS #12 v1.1 describes a transfer syntax for personal identity
 information, including private keys, certificates, miscellaneous
 secrets, and extensions.  Machines, applications, browsers, Internet
 kiosks, and so on, that support this standard will allow a user to
 import, export, and exercise a single set of personal identity
 information.  This standard supports direct transfer of personal
 information under several privacy and integrity modes.
 This document represents a republication of PKCS #12 v1.1 from RSA
 Laboratories' Public Key Cryptography Standard (PKCS) series.  By
 publishing this RFC, change control is transferred to the IETF.

IESG Note

 The IESG thanks RSA Laboratories for transferring change control to
 the IETF.  Enhancements to this specification that preserve backward
 compatibility are expected in an upcoming IETF Standards Track
 document.

Moriarty, et al. Informational [Page 1] RFC 7292 PKCS12 July 2014

Status of This Memo

 This document is not an Internet Standards Track specification; it is
 published for informational purposes.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Not all documents
 approved by the IESG are a candidate for any level of Internet
 Standard; see Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc7292.

Copyright Notice

 Copyright (c) 2014 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.

Moriarty, et al. Informational [Page 2] RFC 7292 PKCS12 July 2014

Table of Contents

 1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
   1.1.  Changes from PKCS #12 Version 1 . . . . . . . . . . . . .   4
 2.  Definitions and Notation  . . . . . . . . . . . . . . . . . .   5
 3.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   7
   3.1.  Exchange Modes  . . . . . . . . . . . . . . . . . . . . .   7
   3.2.  Mode Choice Policies  . . . . . . . . . . . . . . . . . .   8
   3.3.  Trusted Public Keys . . . . . . . . . . . . . . . . . . .   8
   3.4.  The AuthenticatedSafe . . . . . . . . . . . . . . . . . .   9
 4.  PFX PDU Syntax  . . . . . . . . . . . . . . . . . . . . . . .  10
   4.1.  The AuthenticatedSafe Type  . . . . . . . . . . . . . . .  11
   4.2.  The SafeBag Type  . . . . . . . . . . . . . . . . . . . .  12
     4.2.1.  The KeyBag Type . . . . . . . . . . . . . . . . . . .  13
     4.2.2.  The PKCS8ShroudedKeyBag Type  . . . . . . . . . . . .  13
     4.2.3.  The CertBag Type  . . . . . . . . . . . . . . . . . .  13
     4.2.4.  The CRLBag Type . . . . . . . . . . . . . . . . . . .  14
     4.2.5.  The SecretBag Type  . . . . . . . . . . . . . . . . .  14
     4.2.6.  The SafeContents Type . . . . . . . . . . . . . . . .  14
 5.  Using PFX PDUs  . . . . . . . . . . . . . . . . . . . . . . .  15
   5.1.  Creating PFX PDUs . . . . . . . . . . . . . . . . . . . .  15
   5.2.  Importing Keys, etc., from a PFX PDU  . . . . . . . . . .  16
 6.  Security Considerations . . . . . . . . . . . . . . . . . . .  16
 7.  Normative References  . . . . . . . . . . . . . . . . . . . .  17
 Appendix A.  Message Authentication Codes (MACs)  . . . . . . . .  19
 Appendix B.  Deriving Keys and IVs from Passwords and Salt  . . .  19
   B.1.  Password Formatting . . . . . . . . . . . . . . . . . . .  19
   B.2.  General Method  . . . . . . . . . . . . . . . . . . . . .  20
   B.3.  More on the ID Byte . . . . . . . . . . . . . . . . . . .  22
   B.4.  Keys for Password Integrity Mode  . . . . . . . . . . . .  22
 Appendix C.  Keys and IVs for Password Privacy Mode . . . . . . .  22
 Appendix D.  ASN.1 Module . . . . . . . . . . . . . . . . . . . .  24
 Appendix E.  Intellectual Property Considerations . . . . . . . .  28
 Appendix F.  Acknowledgments  . . . . . . . . . . . . . . . . . .  28
 Appendix G.  About PKCS . . . . . . . . . . . . . . . . . . . . .  28

Moriarty, et al. Informational [Page 3] RFC 7292 PKCS12 July 2014

1. Introduction

 This document represents a republication of PKCS #12 v1.1 from RSA
 Laboratories' Public Key Cryptography Standard (PKCS) series.  By
 publishing this RFC, change control is transferred to the IETF.  RSA
 and its parent company EMC reserve the right to continue publishing
 and distributing PKCS #12 v1.1 and its predecessors.
 The body of this document, except for the Security Considerations
 section, is taken directly from the PKCS #12 v1.1 specification.  The
 list of references and the in-line cites have been updated or added
 where appropriate to cite the most current documents in addition to
 those current at the original publication of PKCS #12 v1.1.
 This standard describes a transfer syntax for personal identity
 information, including private keys, certificates, miscellaneous
 secrets, and extensions.  Machines, applications, browsers, Internet
 kiosks, and so on, that support this standard will allow a user to
 import, export, and exercise a single set of personal identity
 information.
 This standard supports direct transfer of personal information under
 several privacy and integrity modes.  The most secure of the privacy
 and integrity modes require the source and destination platforms to
 have trusted public/private key pairs usable for digital signatures
 and encryption, respectively.  The standard also supports lower-
 security, password-based privacy and integrity modes for those cases
 where trusted public/private key pairs are not available.
 This standard should be amenable to both software and hardware
 implementations.  Hardware implementations offer physical security in
 tamper-resistant tokens such as smart cards and Personal Computer
 Memory Card International Association (PCMCIA) devices.
 This standard can be viewed as building on PKCS #8 [15] [24] by
 including essential but ancillary identity information along with
 private keys and by instituting higher security through public-key
 privacy and integrity modes.

1.1. Changes from PKCS #12 Version 1

 This document transfers PKCS #12 [16] into the IETF and includes some
 minor changes from the authors for this submission.
 o  Addition of hash algorithms.
 o  Incorporation of Technical Corrigendum #1, which makes some minor
    corrections to the ASN.1 syntax.

Moriarty, et al. Informational [Page 4] RFC 7292 PKCS12 July 2014

 o  Removed (from the ASN.1 syntax) 1024 as an example of the
    iteration count.
 o  Addition of a recommendation that the technique in Appendix B no
    longer be used for a specific mode (password privacy mode) and
    that techniques from PKCS#5 v2.1 be used instead.
 o  Addition of comments and minor corrections to the ASN.1 module in
    Appendix C.
 o  Removal of the export regulations discussion in the former
    Appendix D.
 o  Replacement of RSA with EMC in the "Intellectual Property
    Considerations".
 o  Many changes and additions to the references.
 o  A reference was added to NIST SP 800-132 for its recommendations
    on selection of the iteration count value for password integrity
    (part of dictionary-attack resistance).
 o  Comment included on acronym expansion of PFX: The acronym is
    sometimes expanded as Personal Information Exchange.
 o  In Appendix B, the phrase "no longer recommended" was changed to
    "not recommended" in the following sentence to address a question
    and make it clear the method was not recommended: "Note that this
    method for password privacy mode is no longer recommended."

2. Definitions and Notation

 AlgorithmIdentifier:  An ASN.1 type that identifies an algorithm (by
    an object identifier) and any associated parameters.  This type is
    defined in [8].
 ASN.1:  Abstract Syntax Notation One, as defined in [2], [3], [4],
    and [5].
 Attribute:  An ASN.1 type that identifies an attribute type (by an
    object identifier) and an associated attribute value.  The ASN.1
    type Attribute is defined in [7].
 Certificate:  A digitally signed data unit binding a public key to
    identity information.  A specific format for identity certificates
    is defined in [8].  Another format is described in [17].

Moriarty, et al. Informational [Page 5] RFC 7292 PKCS12 July 2014

 Certificate Revocation List (CRL):  A digitally signed list of
    certificates that should no longer be honored, having been revoked
    by the issuers or a higher authority.  One format for CRLs is
    defined in [8].
 ContentInfo:  An ASN.1 type used to hold data that may have been
    cryptographically protected.  This type is defined in [21] and
    [14].
 DER:  Distinguished Encoding Rules, as defined in [6].
 Destination platform:  The ultimate, final target platform for the
    personal information originating from the source platform.  Even
    though certain information may be transported from the destination
    platform to the source platform, the ultimate target for personal
    information is always called the destination platform.
 DigestInfo:  An ASN.1 type used to hold a message digest.  This type
    is defined in [21] and [14].
 Encryption Key Pair (DestEncK):  A public/private key pair used for
    the public-key privacy mode of this standard.  The public half is
    called PDestEncK (TPDestEncK when emphasizing that the public key
    is "trusted"), and the private half is called VDestEncK.
 Export time:  The time that a user reads personal information from a
    source platform and transforms the information into an
    interoperable, secure Protocol Data Unit (PDU).
 Import time:  The time that a user writes personal information from a
    Safe PDU to a destination platform.
 Message Authentication Code (MAC):  A type of collision-resistant,
    "unpredictable" function of a message and a secret key.  MACs are
    used for data authentication and are akin to secret-key digital
    signatures in many respects.
 Object Identifier:  A sequence of integers that uniquely identifies
    an associated data object in a global name space administrated by
    a hierarchy of naming authorities.  This is a primitive data type
    in ASN.1.
 PFX:  The top-level exchange PDU defined in this standard.  The
    acronym is sometimes expanded as Personal Information Exchange.

Moriarty, et al. Informational [Page 6] RFC 7292 PKCS12 July 2014

 Platform:  A combination of machine, operating system, and
    applications software within which the user exercises personal
    identity.  An application, in this context, is software that uses
    personal information.  Two platforms differ if their machine types
    differ or if their applications software differs.  There is at
    least one platform per user in multi-user systems.
 Protocol Data Unit (PDU):  A sequence of bits in machine-independent
    format constituting a message in a protocol.
 Shrouding:  Encryption as applied to private keys, possibly in
    concert with a policy that prevents the plaintext of the key from
    ever being visible beyond a certain, well-defined interface.
 Signature Key Pair (SrcSigK):  A platform-specific signature key pair
    used for the public-key integrity mode of this standard.  The
    public half is called PSrcSigK (TPSrcSigK when emphasizing that
    the public key is "trusted"), and the private half is called
    VSrcSigK.
 Source platform:  The origin platform of the personal information
    ultimately intended for the destination platform.  Even though
    certain information may be transported from the destination
    platform to the source platform, the platform that is the origin
    of personal information is always called the source platform.

3. Overview

3.1. Exchange Modes

 There are four combinations of privacy modes and integrity modes.
 The privacy modes use encryption to protect personal information from
 exposure, and the integrity modes protect personal information from
 tampering.  Without protection from tampering, an adversary could
 conceivably substitute invalid information for the user's personal
 information without the user being aware of the substitution.
 The following are the privacy modes:
 o  Public-key privacy mode: Personal information is enveloped on the
    source platform using a trusted encryption public key of a known
    destination platform (see Section 3.3).  The envelope is opened
    with the corresponding private key.

Moriarty, et al. Informational [Page 7] RFC 7292 PKCS12 July 2014

 o  Password privacy mode: Personal information is encrypted with a
    symmetric key derived from a user name and a privacy password, as
    in [22] and [13].  If password integrity mode is used as well, the
    privacy password and the integrity password may or may not be the
    same.
 The following are the integrity modes:
 o  Public-key integrity mode: Integrity is guaranteed through a
    digital signature on the contents of the PFX PDU, which is
    produced using the source platform's private signature key.  The
    signature is verified on the destination platform by using the
    corresponding public key (see Section 3.4).
 o  Password integrity mode: Integrity is guaranteed through a Message
    Authentication Code (MAC) derived from a secret integrity
    password.  If password privacy mode is used as well, the privacy
    password and the integrity password may or may not be the same.

3.2. Mode Choice Policies

 All combinations of the privacy and integrity modes are permitted in
 this standard.  Of course, good security policy suggests that certain
 practices be avoided, e.g., it can be unwise to transport private
 keys without physical protection when using password privacy mode or
 when using public-key privacy mode with weak symmetric encryption.
 In general, the public-key modes for both privacy and integrity are
 preferable to the password modes (from a security viewpoint).
 However, it is not always possible to use the public-key modes.  For
 example, it may not be known at export time what the destination
 platform is; if this is the case, then the use of the public-key
 privacy mode is precluded.

3.3. Trusted Public Keys

 Asymmetric key pairs may be used in this standard in two ways:
 public-key privacy mode and public-key integrity mode.  For public-
 key privacy mode, an encryption key pair is required; for public-key
 integrity mode, a signature key pair is required.
 It may be appropriate for the keys discussed in this section to be
 platform-specific keys dedicated solely for the purpose of
 transporting a user's personal information.  Whether or not that is
 the case, though, the keys discussed here should not be confused with
 the user's personal keys that the user wishes to transport from one
 platform to another.  (These latter keys are stored within the PDU.)

Moriarty, et al. Informational [Page 8] RFC 7292 PKCS12 July 2014

 For public-key privacy mode, the private key from the encryption key
 pair is kept on the destination platform, where it is ultimately used
 to open a private envelope.  The corresponding trusted public key is
 called TPDestEncK.
 For public-key integrity mode, the private key from the signature
 pair is kept on the source platform, where it is used to sign
 personal information.  The corresponding trusted public key is called
 TPSrcSigK.
 For both uses of public/private key pairs, the public key from the
 key pair must be transported to the other platform such that it is
 trusted to have originated at the correct platform.  Judging whether
 or not a public key is trusted in this sense must ultimately be left
 to the user.  There are a variety of methods for ensuring that a
 public key is trusted.
 The processes of imbuing keys with trust and of verifying
 trustworthiness of keys are not discussed further in this document.
 Whenever asymmetric keys are discussed in what follows, the public
 keys are assumed to be trusted.

3.4. The AuthenticatedSafe

 Each compliant platform shall be able to import and export
 AuthenticatedSafe PDUs wrapped in PFX PDUs.
 For integrity, the AuthenticatedSafe is either signed (if public-key
 integrity mode is used) or MACed (if password integrity mode is used)
 to produce a PFX PDU.  If the AuthenticatedSafe is signed, then it is
 accompanied by a digital signature, which was produced on the source
 platform with a private signature key, VSrcSigK, corresponding to a
 trusted public signature key, TPSrcSigK.  TPSrcSigK must accompany
 the PFX to the destination platform, where the user can verify the
 trust in the key and can verify the signature on the
 AuthenticatedSafe.  If the AuthenticatedSafe is MACed, then it is
 accompanied by a MAC computed from a secret integrity password, salt
 bits, an iteration count, and the contents of the AuthenticatedSafe.
 The AuthenticatedSafe itself consists of a sequence of ContentInfo
 values, some of which may consist of plaintext (data), and others
 that may either be enveloped (if public-key privacy mode is used) or
 encrypted (if password privacy mode is used).  If the contents are
 enveloped, then they are encrypted with a symmetric cipher under a
 freshly generated key, which is in turn encrypted with RSA asymmetric
 encryption.  The RSA public key used to encrypt the symmetric key is
 called TPDestEncK and corresponds to an RSA private key, VDestEncK,
 on the destination platform.  TPDestEncK needs to be trusted by the

Moriarty, et al. Informational [Page 9] RFC 7292 PKCS12 July 2014

 user when it is used at export time.  If the contents are encrypted,
 then they are encrypted with a symmetric cipher under a key derived
 from a secret privacy password, salt bits, and an iteration counter.
 Each ContentInfo contains an arbitrary collection of private keys,
 PKCS #8-shrouded private keys, certificates, CRLs, or opaque data
 objects, at the user's discretion, stored in values of type
 SafeContents.
 The raison d'etre for the unencrypted option is that some governments
 restrict certain uses of cryptography.  Having several parts in an
 AuthenticatedSafe keeps implementers' options open.  For example, it
 may be the case that strong cryptography can be used to make PKCS
 #8-shrouded keys, but then these shrouded keys should not be further
 encrypted, because super-encryption can limit a product's
 exportability.  The multi-part AuthenticatedSafe design permits this
 possibility.
 Around the AuthenticatedSafe is the integrity-mode wrapper, which
 protects the entire contents of the AuthenticatedSafe (including
 unencrypted parts, if they are present).  This is the reverse of the
 wrapping order in many protocols, in which privacy is the outermost
 protection.  This latter, more-common wrapping order avoids
 signatures on encrypted data, which are undesirable under certain
 circumstances; however, these circumstances do not apply to this
 document, and it is therefore preferable to protect the integrity of
 as much information as possible.

4. PFX PDU Syntax

 This format corresponds to the data model presented above, with
 wrappers for privacy and integrity.  This section makes free
 reference to PKCS #7 [14] [21] and assumes the reader is familiar
 with terms defined in that document.
 All modes of direct exchange use the same PDU format.  ASN.1 and BER-
 encoding ensure platform independence.
 This standard has one ASN.1 export: PFX.  This is the outer integrity
 wrapper.  Instances of PFX contain:
 1.  A version indicator.  The version shall be v3 for this version of
     this document.
 2.  A PKCS #7 ContentInfo, whose contentType is signedData in public-
     key integrity mode and data in password integrity mode.

Moriarty, et al. Informational [Page 10] RFC 7292 PKCS12 July 2014

 3.  An optional instance of MacData, present only in password
     integrity.  This object, if present, contains a PKCS #7
     DigestInfo, which holds the MAC value, a macSalt, and an
     iterationCount.  As described in Appendix B, the MAC key is
     derived from the password, the macSalt, and the iterationCount;
     as described in Section 5, the MAC is computed from the authSafe
     value and the MAC key via HMAC [11] [20].  The password and the
     MAC key are not actually present anywhere in the PFX.  The salt
     and (to a certain extent) the iteration count thwarts dictionary
     attacks against the integrity password.  See NIST Special
     Publication 800-132 [12] about how to choose a reasonable value
     for the iteration count.
 PFX ::= SEQUENCE {
     version     INTEGER {v3(3)}(v3,...),
     authSafe    ContentInfo,
     macData     MacData OPTIONAL
 }
 MacData ::= SEQUENCE {
     mac         DigestInfo,
     macSalt     OCTET STRING,
     iterations  INTEGER DEFAULT 1
     -- Note: The default is for historical reasons and its
     --       use is deprecated.
 }

4.1. The AuthenticatedSafe Type

 As mentioned, the contentType field of authSafe shall be of type data
 or signedData.  The content field of the authSafe shall, either
 directly (data case) or indirectly (signedData case), contain a BER-
 encoded value of type AuthenticatedSafe.
 AuthenticatedSafe ::= SEQUENCE OF ContentInfo
     -- Data if unencrypted
     -- EncryptedData if password-encrypted
     -- EnvelopedData if public key-encrypted
 An AuthenticatedSafe contains a sequence of ContentInfo values.  The
 content field of these ContentInfo values contains either plaintext,
 encrypted, or enveloped data.  In the case of encrypted or enveloped
 data, the plaintext of the data holds the BER-encoding of an instance
 of SafeContents.  Section 5.1 of this document describes the
 construction of values of type AuthenticatedSafe in more detail.

Moriarty, et al. Informational [Page 11] RFC 7292 PKCS12 July 2014

4.2. The SafeBag Type

 The SafeContents type is made up of SafeBags.  Each SafeBag holds one
 piece of information -- a key, a certificate, etc. -- which is
 identified by an object identifier.

SafeContents ::= SEQUENCE OF SafeBag

SafeBag ::= SEQUENCE {

   bagId          BAG-TYPE.&id ({PKCS12BagSet})
   bagValue       [0] EXPLICIT BAG-TYPE.&Type({PKCS12BagSet}{@bagId}),
   bagAttributes  SET OF PKCS12Attribute OPTIONAL

}

PKCS12Attribute ::= SEQUENCE {

   attrId      ATTRIBUTE.&id ({PKCS12AttrSet}),
   attrValues  SET OF ATTRIBUTE.&Type ({PKCS12AttrSet}{@attrId})

} – This type is compatible with the X.500 type 'Attribute'

PKCS12AttrSet ATTRIBUTE ::= {

   friendlyName | -- from PKCS #9 [23]
   localKeyId,    -- from PKCS #9
   ... -- Other attributes are allowed

}

 The optional bagAttributes field allows users to assign nicknames and
 identifiers to keys, etc., and permits visual tools to display
 meaningful strings of some sort to the user.
 Six types of SafeBags are defined in this version of this document:
 bagtypes OBJECT IDENTIFIER ::= {pkcs-12 10 1}
 BAG-TYPE ::= TYPE-IDENTIFIER
 keyBag BAG-TYPE ::=
     {KeyBag IDENTIFIED BY {bagtypes 1}}
 pkcs8ShroudedKeyBag BAG-TYPE ::=
     {PKCS8ShroudedKeyBag IDENTIFIED BY {bagtypes 2}}
 certBag BAG-TYPE ::=
     {CertBag IDENTIFIED BY {bagtypes 3}}
 crlBag BAG-TYPE ::=
     {CRLBag IDENTIFIED BY {bagtypes 4}}
 secretBag BAG-TYPE ::=
     {SecretBag IDENTIFIED BY {bagtypes 5}}
 safeContentsBag BAG-TYPE ::=
     {SafeContents IDENTIFIED BY {bagtypes 6}}

Moriarty, et al. Informational [Page 12] RFC 7292 PKCS12 July 2014

 PKCS12BagSet BAG-TYPE ::= {
     keyBag |
     pkcs8ShroudedKeyBag |
     certBag |
     crlBag |
     secretBag |
     safeContentsBag,
     ... -- For future extensions
 }
 As new bag types become recognized in future versions of this
 standard, the PKCS12BagSet may be extended.

4.2.1. The KeyBag Type

 A KeyBag is a PKCS #8 PrivateKeyInfo.  Note that a KeyBag contains
 only one private key.
 KeyBag ::= PrivateKeyInfo

4.2.2. The PKCS8ShroudedKeyBag Type

 A PKCS8ShroudedKeyBag holds a private key, which has been shrouded in
 accordance with PKCS #8.  Note that a PKCS8ShroudedKeyBag holds only
 one shrouded private key.
 PKCS8ShroudedKeyBag ::= EncryptedPrivateKeyInfo

4.2.3. The CertBag Type

 A CertBag contains a certificate of a certain type.  Object
 identifiers are used to distinguish between different certificate
 types.
 CertBag ::= SEQUENCE {
     certId      BAG-TYPE.&id   ({CertTypes}),
     certValue   [0] EXPLICIT BAG-TYPE.&Type ({CertTypes}{@certId})
 }
 x509Certificate BAG-TYPE ::=
     {OCTET STRING IDENTIFIED BY {certTypes 1}}
     -- DER-encoded X.509 certificate stored in OCTET STRING
 sdsiCertificate BAG-TYPE ::=
     {IA5String IDENTIFIED BY {certTypes 2}}
     -- Base64-encoded SDSI certificate stored in IA5String
 CertTypes BAG-TYPE ::= {
     x509Certificate |

Moriarty, et al. Informational [Page 13] RFC 7292 PKCS12 July 2014

     sdsiCertificate,
     ... -- For future extensions
 }

4.2.4. The CRLBag Type

 A CRLBag contains a Certificate Revocation List (CRL) of a certain
 type.  Object identifiers are used to distinguish between different
 CRL types.
 CRLBag ::= SEQUENCE {
     crlId      BAG-TYPE.&id  ({CRLTypes}),
     crlValue  [0] EXPLICIT BAG-TYPE.&Type ({CRLTypes}{@crlId})
 }
 x509CRL BAG-TYPE ::=
     {OCTET STRING IDENTIFIED BY {crlTypes 1}}
     -- DER-encoded X.509 CRL stored in OCTET STRING
 CRLTypes BAG-TYPE ::= {
     x509CRL,
     ... -- For future extensions
 }

4.2.5. The SecretBag Type

 Each of the user's miscellaneous personal secrets is contained in an
 instance of SecretBag, which holds an object identifier-dependent
 value.  Note that a SecretBag contains only one secret.
 SecretBag ::= SEQUENCE {
     secretTypeId   BAG-TYPE.&id ({SecretTypes}),
     secretValue    [0] EXPLICIT BAG-TYPE.&Type ({SecretTypes}
                        {@secretTypeId})
 }
 SecretTypes BAG-TYPE ::= {
     ... -- For future extensions
 }
 Implementers can add values to this set at their own discretion.

4.2.6. The SafeContents Type

 The sixth type of bag that can be held in a SafeBag is a
 SafeContents.  This recursive structure allows for arbitrary nesting
 of multiple KeyBags, PKCS8ShroudedKeyBags, CertBags, CRLBags, and
 SecretBags within the top-level SafeContents.

Moriarty, et al. Informational [Page 14] RFC 7292 PKCS12 July 2014

5. Using PFX PDUs

 This section describes the creation and usage of PFX PDUs.

5.1. Creating PFX PDUs

 The steps for creating PFX PDUs are as follows.
 1.  It is somewhat clear from the ASN.1 how to make a number of
     instances of SafeContents, each containing a number of (possibly
     nested) instances of SafeBag.  Let us assume, therefore, a number
     of instances SC_1, SC_2,..., SC_n of SafeContents.  Note that
     there can be a more or less arbitrary number of instances of
     SafeContents in a PFX PDU.  As will be seen in step 2, each
     instance can be encrypted (or not) separately.
 2.  For each SCI, depending on the chosen encryption option,
     A.  If SC_i is not to be encrypted, make a ContentInfo CI_i
         holding content type Data.  The contents of the Data OCTET
         STRING shall be a BER-encoding of SC_i (including tag,
         length, and value octets).
     B.  If SC_i is to be encrypted with a password, make a
         ContentInfo CI_i of type EncryptedData.  The
         encryptedContentInfo field of CI_i has its contentType field
         set to data and its encryptedContent field set to the
         encryption of the BER-encoding of SC_i (note that the tag and
         length octets shall be present).
     C.  If SC_i is to be encrypted with a public key, make a
         ContentInfo CI_i of type EnvelopedData in essentially the
         same fashion as the EncryptedData ContentInfo was made in B.
 3.  Make an instance of AuthenticatedSafe by stringing together the
     CI_i's in a SEQUENCE.
 4.  Make a ContentInfo T holding content type Data.  The contents of
     the Data OCTET STRING shall be a BER-encoding of the
     AuthenticatedSafe value (including tag, length, and value
     octets).
 5.  For integrity protection,
     A.  If the PFX PDU is to be authenticated with a digital
         signature, make a ContentInfo C of type SignedData.  The
         contentInfo field of the SignedData in C has T in it.  C is
         the ContentInfo in the top-level PFX structure.

Moriarty, et al. Informational [Page 15] RFC 7292 PKCS12 July 2014

     B.  If the PFX PDU is to be authenticated with HMAC, then an HMAC
         with SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224,
         or SHA-512/256 is computed on the contents of the Data in T
         (i.e., excluding the OCTET STRING tag and length bytes).
         This is exactly what would be initially digested in step 5A
         if public-key authentication were being used.

5.2. Importing Keys, etc., from a PFX PDU

 Importation from a PFX is accomplished essentially by reversing the
 procedure for creating a PFX.  In general, when an application
 imports keys, etc., from a PFX, it should ignore any object
 identifiers that it is not familiar with.  At times, it may be
 appropriate to alert the user to the presence of such object
 identifiers.
 Special care may be taken by the application when importing an item
 in the PFX would require overwriting an item that already exists
 locally.  The behavior of the application when such an item is
 encountered may depend on what the item is (i.e., it may be that a
 PKCS #8-shrouded private key and a CRL should be treated differently
 here).  Appropriate behavior may be to ask the user what action
 should be taken for this item.

6. Security Considerations

 When using passwords in privacy or integrity mode, it needs to be
 considered that password-based cryptography is generally limited in
 the security that it can provide, particularly for methods such as
 those defined in this document where off-line password search is
 possible.  While the use of salt and iteration count can increase the
 complexity of attack, it is essential that passwords are selected
 well and that relevant guidelines (e.g., NIST SP 800-61-1) are taken
 into account.  It is also important that passwords be protected well
 if stored.
 When choosing a salt value in password privacy or integrity mode, the
 recommendations in Section 4 of PKCS #5 2.1 [13] [22] should be taken
 into account.  Ideally, the salt is as long as the output of the hash
 function being used and consists of randomly generated data.

Moriarty, et al. Informational [Page 16] RFC 7292 PKCS12 July 2014

7. Normative References

 [1]   Dobbertin, H., "The status of MD5 after a recent attack.",
       CryptoBytes Vol. 2, #2, 1996.
 [2]   ISO/IEC, "Information technology -- Abstract Syntax Notation
       One (ASN.1) -- Specification of basic notation", ISO/IEC
       8824-1:2008, 2008.
 [3]   ISO/IEC, "Information technology -- Abstract Syntax Notation
       One (ASN.1) -- Information object specification", ISO/IEC
       8824-2:2008, 2008.
 [4]   ISO/IEC, "Information technology -- Abstract Syntax Notation
       One (ASN.1) -- Constraint specification", ISO/IEC 88247-3:2008,
       2008.
 [5]   ISO/IEC, "Information technology -- Abstract Syntax Notation
       One (ASN.1) -- Parameterization of ASN.1 specifications",
       ISO/IEC 8824-4:2008, 2008.
 [6]   ISO/IEC, "Information Technology - ASN.1 Encoding Rules:
       Specification of Basic Encoding Rules (BER), Canonical Encoding
       Rules (CER), and Distinguished Encoding Rules", ISO/IEC
       8825-1:2008, 2008.
 [7]   ISO/IEC, "Information technology -- Open Systems
       Interconnection -- The Directory: Models", ISO/IEC 9594-2:1997,
       1997.
 [8]   ISO/IEC, "Information technology -- Open Systems
       Interconnection -- The Directory: Authentication Framework",
       ISO/IEC 9594-8:1997, 1997.
 [9]   Microsoft, "PFX: Personal Exchange Syntax and Protocol
       Standard", ISO/IEC Version 0.020, January 1997.
 [10]  National Institute of Standards and Technology (NIST), "Secure
       Hash Standard", FIPS Publication 180-4, March 2012.
 [11]  National Institute of Standards and Technology (NIST), "The
       Keyed-Hash Message Authentication Code (HMAC)", FIPS
       Publication 198-1, July 2008.
 [12]  National Institute of Standards and Technology (NIST), "The
       Recommendation for Password-Based Key Derivation, Part 1:
       Storage Applications", NIST Special Publication 800-132,
       December 2010.

Moriarty, et al. Informational [Page 17] RFC 7292 PKCS12 July 2014

 [13]  RSA Laboratories, "PKCS #5: Password-Based Encryption
       Standard", PKCS Version 2.1, October 2012.
 [14]  RSA Laboratories, "PKCS #7: Cryptographic Message Syntax
       Standard", PKCS Version 1.5, November 1993.
 [15]  RSA Laboratories, "PKCS #8: Private-Key Information Syntax
       Standard", PKCS Version 1.2, November 1993.
 [16]  RSA Laboratories, "PKCS #12: Personal Information Exchange
       Syntax", PKCS Version 1.1, December 2012.
 [17]  Rivest, R. and B. Lampson, "SDSI - A Simple Distributed
       Security Infrastructure", 1996,
       <http://people.csail.mit.edu/rivest/sdsi10.html>.
 [18]  Turner, S. and L. Chen, "MD2 to Historic Status", RFC 6149,
       March 2011.
 [19]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
       1992.
 [20]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
       Hashing for Message Authentication", RFC 2104, February 1997.
 [21]  Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version
       1.5", RFC 2315, March 1998.
 [22]  Kaliski, B., "PKCS #5: Password-Based Cryptography
       Specification Version 2.0", RFC 2898, September 2000.
 [23]  Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object Classes
       and Attribute Types Version 2.0", RFC 2985, November 2000.
 [24]  Turner, S., "Asymmetric Key Packages", RFC 5958, August 2010.
 [25]  Turner, S. and L. Chen, "Updated Security Considerations for
       the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151,
       March 2011.

Moriarty, et al. Informational [Page 18] RFC 7292 PKCS12 July 2014

Appendix A. Message Authentication Codes (MACs)

 A MAC is a special type of function of a message (data bits) and an
 integrity key.  It can be computed or checked only by someone
 possessing both the message and the integrity key.  Its security
 follows from the secrecy of the integrity key.  In this standard,
 MACing is used in password integrity mode.
 This document uses a particular type of MAC called HMAC [11] [20],
 which can be constructed from any of a variety of hash functions.
 Note that the specifications in [20] and [11] differ somewhat from
 the specification in [9].  The hash function HMAC is based on is
 identified in the MacData, which holds the MAC; for this version of
 this standard, the hash function can be one of the following: SHA-1,
 SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, or SHA-512/256 [10].
 As indicated in Appendix B.4, this structure implies that the same
 hash algorithm must be used to derive the MAC key itself in password
 integrity mode and that the MAC key has either 160, 224, 256, 384, or
 512 bits.
 When password integrity mode is used to secure a PFX PDU, an HMAC
 with SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, or
 SHA-512/256 is computed on the BER-encoding of the contents of the
 content field of the authSafe field in the PFX PDU (see Section 5.1).

Appendix B. Deriving Keys and IVs from Passwords and Salt

 Note that this method for password privacy mode is not recommended
 and is deprecated for new usage.  The procedures and algorithms
 defined in PKCS #5 v2.1 [13] [22] should be used instead.
 Specifically, PBES2 should be used as encryption scheme, with PBKDF2
 as the key derivation function.
 The method presented here is still used to generate the key in
 password integrity mode.
 We present here a general method for using a hash function to produce
 various types of pseudorandom bits from a password and a string of
 salt bits.  This method is used for password privacy mode and
 password integrity mode in the present standard.

B.1. Password Formatting

 The underlying password-based encryption methods in PKCS #5 v2.1 view
 passwords (and salt) as being simple byte strings.  The underlying
 password-based encryption methods and the underlying password-based
 authentication methods in this version of this document are similar.

Moriarty, et al. Informational [Page 19] RFC 7292 PKCS12 July 2014

 What's left unspecified in the above paragraph is precisely where the
 byte string representing a password comes from.  (This is not an
 issue with salt strings, since they are supplied as a password-based
 encryption (or authentication) parameter.)  PKCS #5 v2.1 says: "[...]
 a password is considered to be an octet string of arbitrary length
 whose interpretation as a text string is unspecified.  In the
 interest of interoperability, however, it is recommended that
 applications follow some common text encoding rules.  ASCII and UTF-8
 are two possibilities."
 In this specification, however, all passwords are created from
 BMPStrings with a NULL terminator.  This means that each character in
 the original BMPString is encoded in 2 bytes in big-endian format
 (most-significant byte first).  There are no Unicode byte order
 marks.  The 2 bytes produced from the last character in the BMPString
 are followed by 2 additional bytes with the value 0x00.
 To illustrate with a simple example, if a user enters the 6-character
 password "Beavis", the string that PKCS #12 implementations should
 treat as the password is the following string of 14 bytes:
 0x00 0x42 0x00 0x65 0x00 0x61 0x00 0x76 0x00 0x69 0x00 0x73 0x00 0x00

B.2. General Method

 Let H be a hash function built around a compression function f:
    Z_2^u x Z_2^v -> Z_2^u
 (that is, H has a chaining variable and output of length u bits, and
 the message input to the compression function of H is v bits).  The
 values for u and v are as follows:
         HASH FUNCTION     VALUE u        VALUE v
           MD2, MD5          128            512
             SHA-1           160            512
            SHA-224          224            512
            SHA-256          256            512
            SHA-384          384            1024
            SHA-512          512            1024
          SHA-512/224        224            1024
          SHA-512/256        256            1024

Moriarty, et al. Informational [Page 20] RFC 7292 PKCS12 July 2014

 Furthermore, let r be the iteration count.
 We assume here that u and v are both multiples of 8, as are the
 lengths of the password and salt strings (which we denote by p and s,
 respectively) and the number n of pseudorandom bits required.  In
 addition, u and v are of course non-zero.
 For information on security considerations for MD5 [19], see [25] and
 [1], and on those for MD2, see [18].
 The following procedure can be used to produce pseudorandom bits for
 a particular "purpose" that is identified by a byte called "ID".  The
 meaning of this ID byte will be discussed later.
 1.  Construct a string, D (the "diversifier"), by concatenating v/8
     copies of ID.
 2.  Concatenate copies of the salt together to create a string S of
     length v(ceiling(s/v)) bits (the final copy of the salt may be
     truncated to create S).  Note that if the salt is the empty
     string, then so is S.
 3.  Concatenate copies of the password together to create a string P
     of length v(ceiling(p/v)) bits (the final copy of the password
     may be truncated to create P).  Note that if the password is the
     empty string, then so is P.
 4.  Set I=S||P to be the concatenation of S and P.
 5.  Set c=ceiling(n/u).
 6.  For i=1, 2, ..., c, do the following:
     A.  Set A2=H^r(D||I). (i.e., the r-th hash of D||1,
         H(H(H(... H(D||I))))
     B.  Concatenate copies of Ai to create a string B of length v
         bits (the final copy of Ai may be truncated to create B).
     C.  Treating I as a concatenation I_0, I_1, ..., I_(k-1) of v-bit
         blocks, where k=ceiling(s/v)+ceiling(p/v), modify I by
         setting I_j=(I_j+B+1) mod 2^v for each j.
 7.  Concatenate A_1, A_2, ..., A_c together to form a pseudorandom
     bit string, A.
 8.  Use the first n bits of A as the output of this entire process.

Moriarty, et al. Informational [Page 21] RFC 7292 PKCS12 July 2014

 If the above process is being used to generate a DES key, the process
 should be used to create 64 random bits, and the key's parity bits
 should be set after the 64 bits have been produced.  Similar concerns
 hold for 2-key and 3-key triple-DES keys, for CDMF keys, and for any
 similar keys with parity bits "built into them".

B.3. More on the ID Byte

 This standard specifies 3 different values for the ID byte mentioned
 above:
 1.  If ID=1, then the pseudorandom bits being produced are to be used
     as key material for performing encryption or decryption.
 2.  If ID=2, then the pseudorandom bits being produced are to be used
     as an IV (Initial Value) for encryption or decryption.
 3.  If ID=3, then the pseudorandom bits being produced are to be used
     as an integrity key for MACing.

B.4. Keys for Password Integrity Mode

 When password integrity mode is used to protect a PFX PDU, a password
 and salt are used to derive a MAC key.  As with password privacy
 mode, the password is a Unicode string, and the salt is a byte
 string.  No particular lengths are prescribed in this standard for
 either the password or the salt, but the general advice about
 passwords and salt that is given in Appendix C applies here, as well.
 The hash function used to derive MAC keys is whatever hash function
 is going to be used for MACing.  The MAC keys that are derived have
 the same length as the hash function's output.  In this version of
 this standard, SHA-1, SHA-224, SHA-256, SHA384, SHA-512, SHA-512/224,
 or SHA/512/256 can be used to perform MACing, and so the MAC keys can
 be 160, 224, 256, 384, or 512 bits.  See Appendix A for more
 information on MACing.

Appendix C. Keys and IVs for Password Privacy Mode

 As stated at the start of Appendix B, use of this method for password
 privacy mode is not recommended; this specification of keys and IVs
 for password privacy mode is retained for backwards compatibility
 with PKCS #12 v1.0 only.
 When password privacy mode is used to encrypt a PFX PDU, a password
 (typically entered by the user), a salt and an iteration parameter
 are used to derive a key (and an IV, if necessary).  The password is

Moriarty, et al. Informational [Page 22] RFC 7292 PKCS12 July 2014

 a Unicode string, and as such, each character in it is represented by
 2 bytes.  The salt is a byte string and so can be represented
 directly as a sequence of bytes.
 This standard does not prescribe a length for the password.  As
 usual, however, too short a password might compromise privacy.  A
 particular application might well require a user-entered privacy
 password for creating a PFX PDU to have a password exceeding some
 specific length.
 This standard does not prescribe a length for the salt either.
 Ideally, the salt is as long as the output of the hash function being
 used and consists of completely random bits.
 The iteration count is recommended to be 1024 or more.  (See [22] and
 [13] for more information.)
 The PBES1 encryption scheme defined in PKCS #5 provides a number of
 algorithm identifiers for deriving keys and IVs; here, we specify a
 few more, all of which use the procedure detailed in Appendices B.2
 and B.3 to construct keys (and IVs, where needed).  As is implied by
 their names, all of the object identifiers below use the hash
 function SHA-1.

pkcs-12PbeIds OBJECT IDENTIFIER ::= {pkcs-12 1} pbeWithSHAAnd128BitRC4 OBJECT IDENTIFIER ::= {pkcs-12PbeIds 1} pbeWithSHAAnd40BitRC4 OBJECT IDENTIFIER ::= {pkcs-12PbeIds 2} pbeWithSHAAnd3-KeyTripleDES-CBC OBJECT IDENTIFIER ::= {pkcs-12PbeIds 3} pbeWithSHAAnd2-KeyTripleDES-CBC OBJECT IDENTIFIER ::= {pkcs-12PbeIds 4} pbeWithSHAAnd128BitRC2-CBC OBJECT IDENTIFIER ::= {pkcs-12PbeIds 5} pbewithSHAAnd40BitRC2-CBC OBJECT IDENTIFIER ::= {pkcs-12PbeIds 6}

 Each of the six PBE object identifiers above has the following ASN.1
 type for parameters:
 pkcs-12PbeParams ::= SEQUENCE {
     salt        OCTET STRING,
     iterations  INTEGER
 }
 The pkcs-12PbeParams holds the salt that is used to generate the key
 (and IV, if necessary) and the number of iterations to carry out.
 Note that the first two algorithm identifiers above (the algorithm
 identifiers for RC4) only derive keys; it is unnecessary to derive an
 IV for RC4.

Moriarty, et al. Informational [Page 23] RFC 7292 PKCS12 July 2014

 This section is here for two reasons: first, to enable backwards
 compatibility as described in the first paragraph of this section;
 second, because it is still used in password integrity mode.  In
 order to not use it in password integrity mode, the ASN.1 definitions
 require updates.  This document recommends that future definitions of
 the PFX structure replace the existing MacData object, optionally
 present in password integrity mode, with a new object definition that
 holds a MAC based on PKCS#5 [13] [22] PBMAC1 message authentication
 scheme.  This change would simplify the requirements for key
 derivation functions used across all parts of the PFX structure.

Appendix D. ASN.1 Module

 This appendix documents all ASN.1 types, values, and object sets
 defined in this specification.  It does so by providing an ASN.1
 module called PKCS-12.

PKCS-12 {

   iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-12(12)
   modules(0) pkcs-12(1)}

– PKCS #12 v1.1 ASN.1 Module – Revised October 27, 2012

– This module has been checked for conformance with the ASN.1 standard – by the OSS ASN.1 Tools

DEFINITIONS IMPLICIT TAGS ::=

BEGIN

– EXPORTS ALL – All types and values defined in this module are exported for use – in other ASN.1 modules.

IMPORTS

informationFramework

   FROM UsefulDefinitions {joint-iso-itu-t(2) ds(5) module(1)
                           usefulDefinitions(0) 3}

ATTRIBUTE

   FROM InformationFramework informationFramework

ContentInfo, DigestInfo

   FROM PKCS-7 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
                pkcs-7(7) modules(0) pkcs-7(1)}

Moriarty, et al. Informational [Page 24] RFC 7292 PKCS12 July 2014

PrivateKeyInfo, EncryptedPrivateKeyInfo

   FROM PKCS-8 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
                pkcs-8(8) modules(1) pkcs-8(1)}

pkcs-9, friendlyName, localKeyId, certTypes, crlTypes

   FROM PKCS-9 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
                pkcs-9(9) modules(0) pkcs-9(1)};

– Object identifiers –

rsadsi OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)

                              rsadsi(113549)}

pkcs OBJECT IDENTIFIER ::= {rsadsi pkcs(1)} pkcs-12 OBJECT IDENTIFIER ::= {pkcs 12} pkcs-12PbeIds OBJECT IDENTIFIER ::= {pkcs-12 1} pbeWithSHAAnd128BitRC4 OBJECT IDENTIFIER ::= {pkcs-12PbeIds 1} pbeWithSHAAnd40BitRC4 OBJECT IDENTIFIER ::= {pkcs-12PbeIds 2} pbeWithSHAAnd3-KeyTripleDES-CBC OBJECT IDENTIFIER ::= {pkcs-12PbeIds 3} pbeWithSHAAnd2-KeyTripleDES-CBC OBJECT IDENTIFIER ::= {pkcs-12PbeIds 4} pbeWithSHAAnd128BitRC2-CBC OBJECT IDENTIFIER ::= {pkcs-12PbeIds 5} pbewithSHAAnd40BitRC2-CBC OBJECT IDENTIFIER ::= {pkcs-12PbeIds 6}

bagtypes OBJECT IDENTIFIER ::= {pkcs-12 10 1}

– The PFX PDU –

PFX ::= SEQUENCE {

   version    INTEGER {v3(3)}(v3,...),
   authSafe   ContentInfo,
   macData    MacData OPTIONAL

}

MacData ::= SEQUENCE {

   mac        DigestInfo,
   macSalt    OCTET STRING,
   iterations INTEGER DEFAULT 1
   -- Note: The default is for historical reasons and its use is
   -- deprecated.

}

Moriarty, et al. Informational [Page 25] RFC 7292 PKCS12 July 2014

AuthenticatedSafe ::= SEQUENCE OF ContentInfo

  1. - Data if unencrypted
  2. - EncryptedData if password-encrypted
  3. - EnvelopedData if public key-encrypted

SafeContents ::= SEQUENCE OF SafeBag

SafeBag ::= SEQUENCE {

   bagId         BAG-TYPE.&id ({PKCS12BagSet}),
   bagValue      [0] EXPLICIT BAG-TYPE.&Type({PKCS12BagSet}{@bagId}),
   bagAttributes SET OF PKCS12Attribute OPTIONAL

}

– Bag types –

keyBag BAG-TYPE ::=

   {KeyBag              IDENTIFIED BY {bagtypes 1}}

pkcs8ShroudedKeyBag BAG-TYPE ::=

   {PKCS8ShroudedKeyBag IDENTIFIED BY {bagtypes 2}}

certBag BAG-TYPE ::=

   {CertBag             IDENTIFIED BY {bagtypes 3}}

crlBag BAG-TYPE ::=

   {CRLBag              IDENTIFIED BY {bagtypes 4}}

secretBag BAG-TYPE ::=

   {SecretBag           IDENTIFIED BY {bagtypes 5}}

safeContentsBag BAG-TYPE ::=

   {SafeContents        IDENTIFIED BY {bagtypes 6}}

PKCS12BagSet BAG-TYPE ::= {

   keyBag |
   pkcs8ShroudedKeyBag |
   certBag |
   crlBag |
   secretBag |
   safeContentsBag,
   ... -- For future extensions

}

BAG-TYPE ::= TYPE-IDENTIFIER

– KeyBag KeyBag ::= PrivateKeyInfo

– Shrouded KeyBag PKCS8ShroudedKeyBag ::= EncryptedPrivateKeyInfo

Moriarty, et al. Informational [Page 26] RFC 7292 PKCS12 July 2014

– CertBag CertBag ::= SEQUENCE {

   certId    BAG-TYPE.&id   ({CertTypes}),
   certValue [0] EXPLICIT BAG-TYPE.&Type ({CertTypes}{@certId})

}

x509Certificate BAG-TYPE ::=

   {OCTET STRING IDENTIFIED BY {certTypes 1}}
   -- DER-encoded X.509 certificate stored in OCTET STRING

sdsiCertificate BAG-TYPE ::=

   {IA5String IDENTIFIED BY {certTypes 2}}
   -- Base64-encoded SDSI certificate stored in IA5String

CertTypes BAG-TYPE ::= {

   x509Certificate |
   sdsiCertificate,
   ... -- For future extensions

}

– CRLBag CRLBag ::= SEQUENCE {

   crlId     BAG-TYPE.&id ({CRLTypes}),
   crltValue [0] EXPLICIT BAG-TYPE.&Type ({CRLTypes}{@crlId})

}

x509CRL BAG-TYPE ::=

   {OCTET STRING IDENTIFIED BY {crlTypes 1}}
   -- DER-encoded X.509 CRL stored in OCTET STRING

CRLTypes BAG-TYPE ::= {

   x509CRL,
   ... -- For future extensions

}

– Secret Bag SecretBag ::= SEQUENCE {

   secretTypeId  BAG-TYPE.&id ({SecretTypes}),
   secretValue   [0] EXPLICIT BAG-TYPE.&Type ({SecretTypes}
                                              {@secretTypeId})

}

SecretTypes BAG-TYPE ::= {

   ... -- For future extensions

}

– Attributes –

Moriarty, et al. Informational [Page 27] RFC 7292 PKCS12 July 2014

PKCS12Attribute ::= SEQUENCE {

   attrId      ATTRIBUTE.&id ({PKCS12AttrSet}),
   attrValues  SET OF ATTRIBUTE.&Type ({PKCS12AttrSet}{@attrId})

} – This type is compatible with the X.500 type 'Attribute'

PKCS12AttrSet ATTRIBUTE ::= {

   friendlyName |
   localKeyId,
   ... -- Other attributes are allowed

}

END

Appendix E. Intellectual Property Considerations

 EMC Corporation makes no patent claims on the general constructions
 described in this document, although specific underlying techniques
 may be covered.
 RC2 and RC4 are trademarks of EMC Corporation.
 EMC Corporation makes no representations regarding intellectual
 property claims by other parties.  Such determination is the
 responsibility of the user.

Appendix F. Acknowledgments

 Many thanks to Dan Simon of Microsoft Corporation and Jim Spring of
 Netscape Communications Corporation for their assistance in preparing
 early drafts of this document.  Especial thanks to Brian Beckman of
 Microsoft Corporation for writing the specification that this
 document is based on.

Appendix G. About PKCS

 The Public-Key Cryptography Standards are specifications produced by
 RSA Laboratories in cooperation with secure systems developers
 worldwide for the purpose of accelerating the deployment of public-
 key cryptography.  First published in 1991 as a result of meetings
 with a small group of early adopters of public-key technology, the
 PKCS documents have become widely referenced and implemented.
 Contributions from the PKCS series have become part of many formal
 and de facto standards, including ANSI X9 documents, PKIX, SET, S/
 MIME, and SSL.
 Further development of PKCS occurs through the IETF.  Suggestions for
 improvement are welcome.

Moriarty, et al. Informational [Page 28] RFC 7292 PKCS12 July 2014

Authors' Addresses

 Kathleen M. Moriarty (editor)
 EMC Corporation
 176 South Street
 Hopkinton, MA
 United States
 EMail: Kathleen.Moriarty@emc.com
 Magnus Nystrom
 Microsoft Corporation
 1 Microsoft Way
 Redmond, WA  98052
 United States
 EMail: mnystrom@microsoft.com
 Sean Parkinson
 RSA Security Inc.
 345 Queen Street
 Brisbane, QLD, 4000
 Australia
 EMail: Sean.Parkinson@rsa.com
 Andreas Rusch
 RSA Security Inc.
 345 Queen Street
 Brisbane, QLD, 4000
 Australia
 EMail: Andreas.Rusch@rsa.com
 Michael Scott
 RSA Security Inc.
 345 Queen Street
 Brisbane, QLD, 4000
 Australia
 EMail: Michael2.Scott@rsa.com

Moriarty, et al. Informational [Page 29]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7292.txt · Last modified: 2014/07/29 22:09 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki