doc: Add RFC documents

1 files changed, 1627 insertions, 0 deletions

diff --git a/doc/rfc/rfc7292.txt b/doc/rfc/rfc7292.txt
new file mode 100644
index 0000000..92ba37d
--- /dev/null
+++ b/doc/rfc/rfc7292.txt
@@ -0,0 +1,1627 @@
+
+
+
+
+
+
+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
+     -- Data if unencrypted
+     -- EncryptedData if password-encrypted
+     -- 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]
+