|
水平有限，排版不会，欢迎扔砖~~
摘要：
PKCS # 12 v1.1描述了个人身份信息的传输语法,包括私钥、证书、杂项秘密和扩展信息。机器、应用程序、浏览器、Internet kiosk等,支持这个标准的用户将允许导入、导出和操作一组个人身份信息。这个标准支持在几个隐私和诚信模式下直接传输个人信息。
本文档代表了RSA实验室公钥加密标准(PKCS)系列中PKCS # 12 v1.1的再发布版。变更控制将通过发布该RFC转移到IETF。
IESG（Internet Engineering Steering Group）互联网工程指导小组 备注
IESG感谢RSA实验室将变更控制转移到IETF。在即将发布的IETF标准跟踪文档中，有望对该规范进行的增强而保留向后兼容性。
备忘录状态
本文档不是Internet标准跟踪规范;它的出版是为了提供信息。
本文档是IETF (Internet Engineering Task Force)的产品。它代表了IETF工作组的共识。它已接受公众审查，并已获互联网工程指导小组(IESG)批准出版。并非所有经IESG批准的文件都适用于任何级别的互联网标准;参见RFC 5741第2节。
有关此文档的当前状态、勘误表以及如何对其提供反馈信息，可在以下网址获得
http://www.rfc-editor.org/info/rfc7292。
Table of contents目录
1 Introduction 介绍
1.1. Changes from PKCS #12 Version 1 PKCS #12对V1的变化
2 Definitions and Notation 定义和符号
3. Overview 概述
3.1. Exchange Modes 交换模式
3.2. Mode Choice Policies 模式选择政策
3.3. Trusted Public Keys 可信公钥
3.4. The AuthenticatedSafe 经过身份验证的安全
4. PFX PDU Syntax PFX 数据单元语法
4.1. The AuthenticatedSafe Type (AuthenticatedSafe形式)
4.2. The SafeBag Type SafeBag 形式
4.2.1. The KeyBag Type KeyBag 类型
4.2.2. The PKCS8ShroudedKeyBag Type PKCS8ShroudedKeyBag 类型
4.2.3. The CertBag Type CertBag 类型
4.2.4. The CRLBag Type CRLBag 类型
4.2.5. The SecretBag Type SecretBag 类型
4.2.6. The SafeContents Type SafeContents 类型
5. Using PFX PDUs 使用 PFX PDUs
5.1. Creating PFX PDUs 创建PFX PDU
5.2. Importing Keys, etc., from a PFX PDU 从PFX PDU导入密钥等
6. Security Considerations 安全注意事项
1 Introduction 介绍
本文档是RSA实验室公钥密码标准(PKCS)系列的PKCS #12 v1.1的再版。通过发布这个RFC，变更控制被转移到IETF。RSA及其母公司EMC保留继续出版和发行PKCS #12 v1.1及其前身的权利。
除了安全考虑部分之外，本文档的正文直接取自PKCS #12 v1.1规范。
在PKCS #12 v1.1最初发布的文档之外，引用列表和内嵌引用已经更新或添加为最新的引用文件。
该标准描述了个人身份信息的传输语法，包括私钥、证书、其他秘密和扩展信息。支持该标准的机器、应用程序、浏览器、Internet kiosx等将允许用户导入、导出和使用一组个人身份信息。
该标准支持在几种隐私和完整性模式下直接传输个人信息。最安全的隐私和完整性模式要求源平台和目标平台拥有可分别用于数字签名和加密的可信公钥/私钥对。该标准还支持低安全性、基于口令的隐私和完整性模式，用于无法使用可信公钥/私钥对的情况。
这个标准应该同时适用于软件和硬件实现。硬件实现通过防篡改令牌(如智能卡和国际个人计算机存储卡协会(PCMCIA)设备)提供物理安全性。
该标准可以看作是在PKCS#8[15][24]基础上构建的，它包括必要但辅助的身份信息和私钥，并通过公开密钥隐私和完整性模式建立更高的安全性。
1.1. Changes from PKCS #12 Version 1 PKCS #12对V1的变化
本文档将PKCS #12[16]转移到IETF中，并包含了作者为本次提交所做的一些小更改。
? 添加哈希算法。
? 合并技术勘误#1，对ASN.1语法作了一些小修正。
? 从ASN.1语法中删除1024作为迭代计数的例子。
? 增加了一项建议，即附录B中的技术不再用于特定模式(口令保密模式)，而是使用PKCS#5 v2.1中的技术。
? 对附录C中的ASN.1模块增加评论和小修改。
? 撤销前附录D内有关出口规定的讨论。
? 在“知识产权注意事项”中将RSA替换为EMC。
? 对参考资料进行了许多修改和补充。
? NIST SP 800-132增加了一项参考，以推荐为口令完整性(字典攻击抵抗的一部分)选择迭代计数值。
? NIST SP 800-132增加了一项参考，推荐选择迭代计数值为保护口令完整性(字典攻击抵抗的一部分)。
? 对PFX首字母缩略词扩展的评论:首字母缩略词有时被扩展为“个人信息交换”。
? 在附录B中，以下句子中的“no longer recommended(不再推荐)”改为“not recommended(不推荐)”，以解决一个问题，并明确表示不推荐该方法:“注意，这种口令保密模式不再推荐。”
2 Definitions and Notation 定义和符号
AlgorithmIdentifier 算法标识符:
ASN.1类型，通过对象标识符标识算法和任何相关参数。该类型在[8]中定义。
ASN.1：抽象语法表示法一，在[2]，[3]，[4]，[5]中定义。
Attribute 属性：一种ASN.1类型，用于标识一个属性类型(通过对象标识符)和一个相
关的属性值。ASN.1类型属性在[7]中定义。
Certificate证书:将公钥绑定到身份信息的数字签名数据单元。身份证书的特定格式在[8]中定义。另一种格式在[17]中描述了。
证书撤销列表(CRL):已被发行者或更高权限撤销的证书的数字签名列表。crl的一种格式在[8]中定义。
ContentInfo 内容信息: ASN.1类型，用于保存可能被加密保护的数据。该类型在[21]和[14]中定义。
DER:区分的编码规则，如[6]中定义的。
Destination platform目标平台:来自源平台的个人信息的最终目标平台。尽管某些信息可能会从目标平台传输到源平台，但个人信息的最终目标总是被称为目标平台。
DigestInfo 消息摘要：一种ASN.1类型，用于保存消息摘要。该类型在[21]和[14]中定义。
加密密钥对(DestEncK):用于本标准的公钥保密模式的公钥/私钥对。公共的一半称为PDestEncK(当强调公钥是“可信的”时称为TPDestEncK)，私有的一半称为VDestEncK。
Export time导出时间:用户从源平台读取个人信息并将信息转换为可互操作的安全协议数据单元(PDU)的时间。
Import time 导入时间:用户从安全PDU向目的平台写入个人信息的时间。
消息验证码(MAC):消息和密钥的一种抗碰撞、“不可预知”的功能。mac用于数据认证，在许多方面类似于密钥数字签名。
Object Identifier对象标识符:在由命名机构层次结构管理的全局名称空间中唯一标识关联数据对象的整数序列。这是ASN.1中的基本数据类型。
PFX:本标准定义的顶层交换PDU。这个首字母缩写有时被扩展为“个人信息交换”。
Platform平台:一种机器、操作系统和应用软件的组合，用户在其中使用个人身份。在此文档上下文中，应用程序是使用个人信息的软件。如果它们的机器类型不同，或者它们的应用程序软件不同，那么两个平台就不同。在多用户系统中，每个用户至少有一个平台。
协议数据单元(PDU):在协议中组成消息的一个与机器无关的数据位序列。
Shrouding覆盖:应用于私钥的加密，可能与防止密钥明文在特定的、定义良好的接口之外可见的策略协调一致。
签名密钥对(SrcSigK):特定于平台的签名密钥对，用于此标准的公钥完整性模式。公共的一半称为PSrcSigK(当强调公钥是“受信任的”时称为TPSrcSigK)，私有的一半称为VSrcSigK。
Source platform 源平台:最终用于目标平台的个人信息的源平台。尽管某些信息可能会从目标平台传输到源平台，但作为个人信息来源的平台通常被称为源平台。
3. Overview 概述
3.1. Exchange Modes 交换模式
有四种隐私模式和完整性模式的组合。隐私模式通过加密方式保护个人信息不被泄露，完整性模式通过加密方式保护个人信息不被篡改。如果没有防止篡改的保护，对手可以在用户不知道替换的情况下，用无效的信息替换用户的个人信息。
隐私模式如下:
? 公钥保密模式:使用已知目标平台的可信加密公钥将个人信息封装在源平台上(见第3.3节)。信封用相应的私钥打开。
? 口令保密模式:使用由用户名和保密口令派生的对称密钥对个人信息进行加密，如[22]和[13]。如果同时使用口令完整性模式，隐私口令和完整性口令可能相同，也可能不相同。
3.2. Mode Choice Policies 模式选择政策
本标准允许隐私和完整性模式的所有组合。当然，好的安全策略建议避免使用某些做法，例如，当使用口令保密模式或使用弱对称加密的公开密钥保密模式时，在没有物理保护的情况下传输私钥可能是不明智的。
通常，对于隐私和完整性而言，公开密钥模式比口令模式更可取(从安全的角度来看)。但是，并不总是可以使用公钥模式。例如，在导出时可能不知道目标平台是什么;如果是这种情况，则禁止使用公钥隐私模式。
3.3. Trusted Public Keys 可信公钥
在此标准中，可以以两种方式使用非对称密钥对:公钥隐私模式和公钥完整性模式。对于公钥保密模式，需要一个加密密钥对;对于公钥完整性模式，需要一个签名密钥对。
本节中讨论的密钥可能适合于于平台的特定密钥，专门用于传输用户的个人信息。但是，无论是否如此，这里讨论的密钥都不应与用户希望从一个平台传输到另一个平台的用户个人密钥混淆。(这些密钥存储在PDU中。)
对于公钥隐私模式，来自加密密钥对的私钥保存在目标平台上，最终用于打开一个私有信封。相应的可信公钥称为TPDestEncK。
对于公钥完整性模式，来自签名对的私钥保存在源平台上，用于签署个人信息。相应的可信公钥称为TPSrcsig。
对于公钥/私钥对的两种使用，必须将来自密钥对的公钥传输到另一个平台，这样才能相信它来自正确的平台。在这种意义上，判断公钥是否可信最终必须留给用户。有多种方法可以确保公钥是可信的。
可信的密钥注入流程的和验证密钥的可信任性的过程在本文中不作进一步讨论。在下面讨论非对称密钥时，都假定公钥是可信的。
3.4. The AuthenticatedSafe 经过身份验证的安全
每个符合要求的平台应能够导入和导出封装在PFX 中的安全pdu。
对于完整性，AuthenticatedSafe要么经过签名(如果使用公钥完整性模式)，要么通过MACed(如果使用密码完整性模式)来生成PFX PDU。如果对AuthenticatedSafe进行了签名，则伴随着数字签名，数字签名是在源平台上使用私有签名密钥VSrcSigK生成的，对应于可信的公共签名密钥TPSrcSigK。TPSrcSigK必须伴随PFX到达目的地平台，在那里用户可以验证密钥中的信任，也可以验证AuthenticatedSafe上的签名。如果AuthenticatedSafe是MACed，那么它会伴随着一个MAC，该MAC由一个秘密完整性口令、SALT、迭代计数和AuthenticatedSafe的内容计算而来。
AuthenticatedSafe本身由一系列的ContentInfo值组成，其中一些可能由明文(数据)组成，其他的可能是封装的(如果使用公钥隐私模式)或加密的(如果使用口令隐私模式)。如果内容被封装，则使用对称密码和新生成的密钥对其进行加密，然后使用RSA非对称加密加密。用于加密对称密钥的RSA公钥称为TPDestEncK，对应于目标平台上的RSA私钥VDestEncK。当在导出时使用TPDestEncK时，需要用户信任它。如果对内容进行了加密，则使用对称密码对其进行加密，密钥来自一个秘密保密口令、SALT和迭代计数器。
每个ContentInfo包含一个任意的私钥集合，pkcs# 8-shrouded 私钥, 证书, CRLs, 或者不透明的数据对象，由用户决定，存储在类型为SafeContents的值中。
不加密的选择存在的理由是，一些政府限制加密技术的某些用途。AuthenticatedSafe中有几个部分可以让实现者的选项保持开放。例如，可能会出现这样的情况:可以使用强加密技术来制作PKCS #8受控密钥，但是这些受控密钥不应该被进一步加密，因为超级加密会限制产品的可导出性。多部分的AuthenticatedSafe设计允许这种可能性。
AuthenticatedSafe周围是完整性模式包装器，它保护AuthenticatedSafe的全部内容(包括未加密的部分，如果存在的话)。这与许多协议的包装顺序相反，在这些协议中，隐私是最外层的保护。后者是更常见的包装顺序，可以避免加密数据上的签名，这在某些情况下是不可取的;但是，这些情况不适用于本文件，因此最好尽可能多地保护信息的完整性。
4. PFX PDU Syntax PFX 数据单元语法
这种格式对应于上面介绍的数据模型，使用了保护隐私和完整性的包装器。本节参考PKCS#7[14][21]，并假设读者熟悉该文档中定义的术语。
所有直连交换模式使用相同的PDU格式。ASN.1和BER编码保证了平台独立性。
本标准有一个ASN.1的PFX输出实例 ,这是一个外部完整性包装器。实例包含:
1．一个版本的指标。本文档的这个版本应该是v3版本。
2．PKCS#7内容信息，其内容类型是公钥完整性模式下的signedData，数据是口令完整性模式下的。
3．MacData的可选实例，仅以口令完整性的形式出现。这个对象，如果存在，包含一个PKCS#7DigestInfo，它包含MAC值，一个macSalt和一个iterationCount。如附录B所述，MAC密钥是由口令、macSalt和iterationCount派生出来的;如第5节所述，MAC由authSafe值和MAC key通过HMAC[11][20]计算。口令和MAC密钥实际上并不存在于PFX中的任何地方。salt和(在一定程度上)迭代计数可以阻止字典对完整性密码的攻击。请参阅NIST专业出版物800-132[12]，了解如何为迭代计数选择一个合理的值。
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 (AuthenticatedSafe形式)
如所述，authSafe的contentType字段应该是类型data或signedData。authSafe的内容字段应该直接(数据情况)或间接(signedData情况)包含一个BER编码的类型AuthenticatedSafe值。
AuthenticatedSafe ::= SEQUENCE OF ContentInfo
– Data if unencrypted
– EncryptedData if password-encrypted
– EnvelopedData if public key-encrypted
AuthenticatedSafe包含一个ContentInfo值序列。这些ContentInfo值的内容字段包含明文、加密或封装的数据。在加密或封装数据的情况下，数据的明文保存一个SafeContents实例的BER编码。本文档的5.1节更详细地描述了AuthenticatedSafe类型值的构造。
4.2. The SafeBag Type SafeBag 形式
SafeContents类型由SafeBags组成。每个SafeBag保存一条信息——密钥、证书等——由一个对象标识符标识。
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
}
可选的bagAttributes字段允许用户为密钥分配昵称和标识符等，并允许可视化工具向用户显示某种有意义的字符串。
本文档定义了六种SafeBag:
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}}
PKCS12BagSet BAG-TYPE ::= {
keyBag |
pkcs8ShroudedKeyBag |
certBag |
crlBag |
secretBag |
safeContentsBag,
… – For future extensions
}
随着新的包类型在本标准的未来版本中得到认可，PKCS12BagSet可能会得到扩展。
4.2.1. The KeyBag Type KeyBag 类型
一个KeyBag是pkcs# 8 PrivateKeyInfo。请注意，一个KeyBag只包含一个私钥。
KeyBag ::= PrivateKeyInfo
4.2.2. The PKCS8ShroudedKeyBag Type PKCS8ShroudedKeyBag 类型
pkcs8shrouded dedkeybag持有一个私钥，该私钥已按照pkcs# 8被隐藏。请注意，PKCS8ShroudedKeyBag只持有一个被遮蔽的私钥。
4.2.3. The CertBag Type CertBag 类型
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
}
4.2.4. The CRLBag Type CRLBag 类型
CRLBag包含某种类型的证书吊销列表(Certificate Revocation List, CRL)。对象标识符用于区分不同的CRL类型。
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 SecretBag 类型
每个用户的各种个人秘密都包含在SecretBag的一个实例中，该实例包含一个依赖于对象标识符的值。请注意，SecretBag只包含一个秘密。
SecretBag ::= SEQUENCE {
secretTypeId BAG-TYPE.&id ({SecretTypes}),
secretValue [0] EXPLICIT BAG-TYPE.&Type ({SecretTypes}
{@secretTypeId})
}
SecretTypes BAG-TYPE ::= {
… – For future extensions
}
实现者可以自行决定向该集合添加值。
4.2.6. The SafeContents Type SafeContents 类型
第六种可以放在SafeBag里的袋子是SafeBag。这种递归结构允许在顶层安全内容中任意嵌套多个KeyBags, PKCS8ShroudedKeyBags, CertBags, CRLBags和SecretBags。
5. Using PFX PDUs 使用 PFX PDUs
本章介绍PFX pdu的创建和使用方法。
5.1. Creating PFX PDUs 创建PFX PDU
1。从ASN.1中可以清楚地看出，如何创建多个SafeContents实例，每个实例包含多个(可能嵌套的)SafeBag实例。因此，让我们假设一些实例SC_1, SC_2，…， SC_n的安全内容。注意PFX PDU中可以有或多或少任意数量的SafeContents实例。如第2步所示，每个实例都可以单独加密(或不加密)。
2。对于每个SCI，取决于选择的加密选项，
A.如果SC_i不被加密，让一个ContentInfo CI_i保存内容类型Data。数据OCTET STRING的内容应该是SC_i的ber编码(包括标记、长度和值字节)。
B.如果SC_i要用密码加密，将ContentInfo CI_i设置为EncryptedData类型。CI_i的encryptedContentInfo字段将其contentType字段设置为data，并将其encryptedContent字段设置为SC_i的ber编码的加密(注意标签和长度字节必须存在)。
C.如果SC_i要用公钥加密，则创建一个类型为enveleddata的ContentInfo CI_i，其方式与B中创建的EncryptedData ContentInfo的方式基本相同。
3。通过将CI_i的序列串在一起，创建一个AuthenticatedSafe的实例。
4。创建一个包含内容类型Data的ContentInfo T。数据OCTET STRING的内容应该是AuthenticatedSafe值的ber编码(包括标签、长度和值字节)。
5. For integrity protection,
A.如果PFX PDU要用数字签名进行认证，则创建一个类型为SignedData的ContentInfo C。C语言中SignedData的contentInfo字段中有T。C是顶级PFX结构中的ContentInfo。
B.如果PFX PDU要用HMAC进行认证，则根据T格式的Data(即不包括OCTET STRING标签和长度字节)的内容，计算具有SHA-1、SHA-224、SHA-256、SHA-384、SHA-512、SHA-512/224或SHA-512/256的HMAC。如果使用公钥身份验证，这正是步骤5A中最初要消化的内容。
5.2. Importing Keys, etc., from a PFX PDU 从PFX PDU导入密钥等
从PFX输入基本上是通过反向创建PFX的过程来完成的。通常，当应用程序从PFX导入键等时，它应该忽略它不熟悉的任何对象标识符。有时，提醒用户存在这样的对象标识符可能是合适的。
当应用程序在PFX中导入项目时，可能需要覆盖本地已经存在的项目时，需要特别注意。当遇到这样一个项时，应用程序的行为可能取决于该项是什么(例如，这里可能应该区别对待PKCS #8-shrouded私钥和CRL)。适当的行为可能是询问用户应该对这个项目采取什么行动。
6. Security Considerations 安全注意事项
当在隐私或完整性模式下使用密码时，需要考虑到基于密码的密码学所能提供的安全性通常是有限的，特别是对于像本文档中定义的那些可以进行脱机密码搜索的方法。虽然salt和迭代计数的使用会增加攻击的复杂性，但密码的选择和相关指导原则(如NIST SP 800-61-1)的考虑是至关重要的。同样重要的是，在存储密码时，保护好密码。
当在密码隐私或完整性模式下选择salt值时，应该考虑PKCS #5 2.1[13][22]第4节中的建议。理想情况下，salt与所使用的哈希函数的输出一样长，并且由随机生成的数据组成。
|