rfc9579xml2.original.xml | rfc9579.xml | |||
---|---|---|---|---|
<?xml version="1.0" encoding="US-ASCII"?> | <?xml version='1.0' encoding='utf-8'?> | |||
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ | ||||
<!ENTITY RFC2104 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen | ||||
ce.RFC.2104.xml"> | ||||
<!ENTITY RFC2119 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen | ||||
ce.RFC.2119.xml"> | ||||
<!ENTITY RFC6194 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen | ||||
ce.RFC.6194.xml"> | ||||
<!ENTITY RFC7292 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen | ||||
ce.RFC.7292.xml"> | ||||
<!ENTITY RFC7914 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen | ||||
ce.RFC.7914.xml"> | ||||
<!ENTITY RFC8018 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen | ||||
ce.RFC.8018.xml"> | ||||
<!ENTITY RFC8174 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen | ||||
ce.RFC.8174.xml"> | ||||
<!DOCTYPE rfc [ | ||||
<!ENTITY nbsp " "> | ||||
<!ENTITY zwsp "​"> | ||||
<!ENTITY nbhy "‑"> | ||||
<!ENTITY wj "⁠"> | ||||
]> | ]> | |||
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> | ||||
<?rfc strict="yes" ?> | <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" docName="draft-i | |||
<?rfc toc="yes"?> | etf-lamps-pkcs12-pbmac1-08" number="9579" ipr="trust200902" updates="7292, 8018" | |||
<?rfc tocdepth="4"?> | obsoletes="" submissionType="IETF" xml:lang="en" consensus="true" tocInclude="t | |||
<?rfc symrefs="yes"?> | rue" tocDepth="4" symRefs="true" sortRefs="true" version="3"> | |||
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] --> | ||||
<?rfc sortrefs="yes" ?> | <!-- [rfced] *AD, please review the change from "pbkc12-pbamc1-2023" to | |||
<!-- control vertical white space | "id-pkcs12-pbmac1-2023" in Appendix B and let us know if you | |||
(using these PIs as follows is recommended by the RFC Editor) --> | approve. This change was made after version -08 was approved. IANA has | |||
<?rfc compact="yes" ?> | already updated the registry (see https://www.iana.org/assignments/smi-numbers). | |||
<!-- do not start each main section on a new page --> | ||||
<?rfc subcompact="no" ?> | You can view the change in this diff file: | |||
<!-- keep one blank line between list items --> | https://www.rfc-editor.org/authors/rfc9579-diff.html | |||
<!-- end of list of popular I-D processing instructions --> | --> | |||
<rfc category="info" docName="draft-ietf-lamps-pkcs12-pbmac1-08" ipr="trust20090 | ||||
2" | ||||
updates="7292, 8018"> | ||||
<!-- ***** FRONT MATTER ***** --> | ||||
-> | ||||
<front> | <front> | |||
<title abbrev="PBMAC1 in PKCS#12">Use of Password Based Message | <title abbrev="PBMAC1 in PKCS #12">Use of Password-Based Message | |||
Authentication Code 1 (PBMAC1) in PKCS #12 Syntax</title> | Authentication Code 1 (PBMAC1) in PKCS #12 Syntax</title> | |||
<seriesInfo name="RFC" value="9579"/> | ||||
<author fullname="Hubert Kario" initials="H." role="editor" | <author fullname="Hubert Kario" initials="H." role="editor" surname="Kario"> | |||
surname="Kario"> | ||||
<organization>Red Hat, Inc.</organization> | <organization>Red Hat, Inc.</organization> | |||
<address> | <address> | |||
<postal> | <postal> | |||
<street>Purkynova 115</street> | <street>Purkynova 115</street> | |||
<city>Brno</city> | <city>Brno</city> | |||
<region></region> | ||||
<code>61200</code> | <code>61200</code> | |||
<country>Czech Republic</country> | <country>Czech Republic</country> | |||
</postal> | </postal> | |||
<phone></phone> | ||||
<email>hkario@redhat.com</email> | <email>hkario@redhat.com</email> | |||
</address> | </address> | |||
</author> | </author> | |||
<date month="May" year="2024"/> | ||||
<date day="22" month="February" year="2024" /> | <area>SEC</area> | |||
<workgroup>lamps</workgroup> | ||||
<area>General</area> | ||||
<workgroup>Internet Engineering Task Force</workgroup> | ||||
<keyword>pbmac1, pkcs12, pbkdf2</keyword> | <keyword>pbmac1</keyword> | |||
<keyword>pkcs12</keyword> | ||||
<keyword>pbkdf2</keyword> | ||||
<abstract> | <abstract> | |||
<t>This document specifies additions and amendments to | <t>This document specifies additions and amendments to | |||
RFCs 7292 and 8018. It defines a way to use | RFCs 7292 and 8018. It defines a way to use | |||
the Password Based Message Authentication Code 1, defined | the Password-Based Message Authentication Code 1 (PBMAC1), defined | |||
in RFC 8018, inside the PKCS #12 | in RFC 8018, inside the PKCS #12 | |||
syntax. The purpose of this specification is to permit use of more | syntax. The purpose of this specification is to permit the use of mo re | |||
modern Password-Based Key Derivation Functions (PBKDFs) | modern Password-Based Key Derivation Functions (PBKDFs) | |||
and allow for regulatory compliance. | and allow for regulatory compliance. | |||
</t> | </t> | |||
</abstract> | </abstract> | |||
</front> | </front> | |||
<middle> | <middle> | |||
<section title="Introduction"> | <section numbered="true" toc="default"> | |||
<t>The <xref target="RFC7292">PKCS #12</xref> format is widely used | <name>Introduction</name> | |||
for interoperable transfer of certificate, key, and other | ||||
<!--[rfced] Will it be clear to readers what "the original specification" | ||||
refers to in the second sentence below (first sentence included for | ||||
context)? Does "the original specification" refer to RFC 7292? If so, | ||||
please note that we do not see "PBKDF1" in RFC 7292, though we do see | ||||
"PBKDF2". We see "PBKDF1" in RFC 8018. Please review and let us know if | ||||
any updates are needed. | ||||
Original: | ||||
The PKCS #12 [RFC7292] format is widely used for interoperable | ||||
transfer of certificate, key, and other miscellaneous secrets between | ||||
machines, applications, browsers, etc. Unfortunately, the original | ||||
specification mandates the use of a specific password based key | ||||
derivation function, the PBKDF1, allowing only for change of the | ||||
underlying message digest function. | ||||
--> | ||||
<t>The PKCS #12 format <xref target="RFC7292" format="default"/> is widely used | ||||
for the interoperable transfer of certificate, key, and other | ||||
miscellaneous secrets between machines, applications, browsers, etc. | miscellaneous secrets between machines, applications, browsers, etc. | |||
Unfortunately, the original specification mandates the use | Unfortunately, the original specification mandates the use | |||
of a specific password based key derivation function, the PBKDF1, | of a specific password-based key derivation function, the PBKDF1, | |||
allowing only for change of the underlying message digest function.</t> | that only allows for change of the underlying message digest function.</ | |||
t> | ||||
</section> | </section> | |||
<section numbered="true" toc="default"> | ||||
<name>Rationale</name> | ||||
<section title="Rationale"> | <t>Due to security concerns with PBKDF1 and the much higher | |||
<t>Due to security concerns with PBKDF1 and much higher extensibility | extensibility of PBMAC1 <xref target="RFC8018" format="default"/>, we | |||
of PBMAC1 <xref target="RFC8018"/>, we propose the use of PBMAC1 | propose the use of PBMAC1 for integrity protection of PKCS #12 | |||
for integrity protection | structures. The new syntax is designed to allow legacy applications to | |||
of PKCS #12 structures. The new syntax is designed to allow legacy | still be able to decrypt the key material, even if they are unable to | |||
applications to still be able to decrypt the key material, even if they | interpret the new integrity protection, provided that they can ignore | |||
are unable to interpret the new integrity protection, provided that | failures in Message Authentication Code (MAC) verification. This change | |||
they can ignore failures in MAC verification. | allows for the use of PBKDF2 <xref target="RFC8018" format="default"/> | |||
This change allows for use of PBKDF2 <xref target="RFC8018"/> | or scrypt PBKDFs <xref target="RFC7914" format="default"/> for | |||
or scrypt <xref target="RFC7914"/> | derivation of MAC keys and future extensibility. Use of the extensible | |||
KDFs for derivation of MAC keys and future extensibility. | PBMAC1 mechanism also allows for greater flexibility and alignment with | |||
Use of the extensible PBMAC1 mechanism also allows for greater | different government regulations, for example, in environments where | |||
flexibility and alignment to different government regulations, | PBKDF2 is the only allowed password-based key derivation function. | |||
for example, in environments where PBKDF2 is the only allowed | </t> | |||
password-based key derivation function. | ||||
</t> | <t>As the recommended methods for key protection require both encryption | |||
<t>As recommended methods for key protection require both encryption | and integrity protection, we decided to amend the PKCS #12 format | |||
and integrity protection, we've decided to amend the PKCS #12 format | ||||
to support different key derivation functions rather than extending the | to support different key derivation functions rather than extending the | |||
PKCS #5 by a new field allowing integrity protection. | PKCS #5 format by a new field that allows integrity protection. | |||
</t> | ||||
<t>We included an ASN.1 module <xref target="x680" | ||||
format="default"/> <xref target="x681" format="default"/> <xref | ||||
target="x682" format="default"/> <xref target="x683" format="default"/> | ||||
<xref target="x690" format="default"/> that can be combined with the | ||||
ASN.1 module in <xref target="RFC8018" format="default"/> to incorporate | ||||
additional MAC algorithms.</t> | ||||
</section> | ||||
<section numbered="true" toc="default"> | ||||
<name>Requirements Language</name> | ||||
<t> | ||||
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", | ||||
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14> | ||||
", | ||||
"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", | ||||
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", | ||||
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to | ||||
be | ||||
interpreted as described in BCP 14 <xref target="RFC2119"/> <xref | ||||
target="RFC8174"/> when, and only when, they appear in all capitals, as | ||||
shown here. | ||||
</t> | </t> | |||
<t>We have included an ASN.1 module <xref target="x680"/> | ||||
<xref target="x681"/><xref target="x682"/><xref target="x683"/> | ||||
<xref target="x690"/> that | ||||
can be combined with the ASN.1 module in <xref target="RFC8018"/> to | ||||
incorporate additional MAC algorithms.</t> | ||||
</section> | </section> | |||
<section title="Requirements Language"> | <section numbered="true" toc="default"> | |||
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | <name>Embedding PBMAC1 in PKCS #12</name> | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", | ||||
and "OPTIONAL" in this document are to be interpreted as described in | ||||
<xref target="RFC2119">BCP 14</xref><xref target="RFC8174"/> when, and | ||||
only when, they appear in all capitabls, as shown here.</t> | ||||
</section> | ||||
<!-- This PI places the pagebreak correctly (before the section title) in th | <!-- [rfced] Because the following list updates item #3 in Section 4 of RFC | |||
e text output. --> | 7292, would it be helpful to use a different numbering scheme here | |||
(perhaps bullets or a, b, c, d)? | ||||
<?rfc needLines="8" ?> | Original: | |||
1. the id-PBMAC1 object identifier is permitted as a valid type for | ||||
the DigestAlgorithmIdentifier inside the DigestInfo object. If | ||||
the algorithm field of the DigestAlgorithmIdentifier is id- | ||||
PBMAC1, then the parameters field MUST be present and have the | ||||
value consistent with PBMAC1-params | ||||
<section title="Embedding PBMAC1 in PKCS #12"> | 2. if the PBMAC1 algorithm is used, the digest value of the | |||
<t>The MacData structure in the PFX object, as described in | DigestInfo object MUST be the result of the PBMAC1 calculation | |||
<xref target="RFC7292">bullet #3 in section 4 of RFC 7292</xref>, | over the authSafe field using the PBMAC1-params parameters | |||
is updated to include this additional PBMAC1-specific guidance: | ||||
<list style="numbers"> | 3. if the PBMAC1 algorithm is used, the macSalt value MUST be | |||
<t>the id-PBMAC1 object identifier is permitted as a valid type | ignored, for backwards compatibility it SHOULD NOT be empty | |||
for the DigestAlgorithmIdentifier inside the DigestInfo object. | ||||
If the algorithm field of the DigestAlgorithmIdentifier is | 4. if the PBMAC1 algorithm is used, the iterations value MUST be | |||
id-PBMAC1, then the parameters field MUST be present and have | ignored, for backwards compatibility it SHOULD have a non-zero | |||
the value consistent with PBMAC1-params</t> | positive value | |||
<t>if the PBMAC1 algorithm is used, the digest value of the | --> | |||
DigestInfo object MUST be the result of the PBMAC1 calculation | ||||
over the authSafe field using the PBMAC1-params parameters</t> | <!--[rfced] We have a couple of questions about the sentence below: | |||
<t>if the PBMAC1 algorithm is used, the macSalt value MUST be | ||||
ignored, for backwards compatibility it SHOULD NOT be empty</t> | a) Is "over" correct in the phrase "the PBMAC1 calculation over the authSafe | |||
<t>if the PBMAC1 algorithm is used, the iterations value MUST be | field"? Or should "over" be updated to "of" or something else? | |||
ignored, for backwards compatibility it SHOULD have a non-zero | ||||
positive value</t> | b) Should "the PBMAC1-params parameters" be updated to "PBMAC1-params"? Or is | |||
</list> | the current okay? | |||
</t> | ||||
Original: | ||||
2. if the PBMAC1 algorithm is used, the digest value of the | ||||
DigestInfo object MUST be the result of the PBMAC1 calculation | ||||
over the authSafe field using the PBMAC1-params parameters | ||||
Perhaps | ||||
2. If the PBMAC1 algorithm is used, the digest value of the | ||||
DigestInfo object MUST be the result of the PBMAC1 calculation | ||||
of the authSafe field using PBMAC1-params. | ||||
--> | ||||
<t>The MacData structure in the Personal Information Exchange (PFX) | ||||
object, as described in item #3 in <xref target="RFC7292" | ||||
sectionFormat="of" section="4"/>, is updated to include the following PBMA | ||||
C1-specific | ||||
guidance: | ||||
</t> | ||||
<ol spacing="normal" type="1"> | ||||
<li> | ||||
The id-PBMAC1 object identifier is permitted as a valid type for the | ||||
DigestAlgorithmIdentifier inside the DigestInfo object. If the | ||||
algorithm field of the DigestAlgorithmIdentifier is id-PBMAC1, then | ||||
the parameters field <bcp14>MUST</bcp14> be present and have a | ||||
value consistent with PBMAC1-params. | ||||
</li> | ||||
<li> | ||||
If the PBMAC1 algorithm is used, the digest value of the DigestInfo | ||||
object <bcp14>MUST</bcp14> be the result of the PBMAC1 calculation | ||||
over the authSafe field using the PBMAC1-params parameters. | ||||
</li> | ||||
<li> | ||||
If the PBMAC1 algorithm is used, the macSalt value | ||||
<bcp14>MUST</bcp14> be ignored. For backwards compatibility, it | ||||
<bcp14>SHOULD NOT</bcp14> be empty. | ||||
</li> | ||||
<li> | ||||
If the PBMAC1 algorithm is used, the iterations value | ||||
<bcp14>MUST</bcp14> be ignored. For backwards compatibility, it | ||||
<bcp14>SHOULD</bcp14> have a non-zero positive value. | ||||
</li> | ||||
</ol> | ||||
</section> | </section> | |||
<section numbered="true" toc="default"> | ||||
<name>Recommended Parameters</name> | ||||
<section title="Recommended parameters"> | <!-- [rfced] We have a few questions about these sentences in Section 5: | |||
<t>To provide interoperability between different implementations, | ||||
all implementations of this specification MUST support the PBKDF2 | a) Please review "the PBKDF2 key derivation function" (first sentence), "the | |||
key derivation function paired with SHA-256 HMAC | PBKDF2" (second sentence), and "PBKDF2 KDF" (third sentence). Should these be | |||
<xref target="SHA2"/> | updated to simply "PBKDF2" or otherwise be made consistent?? | |||
<xref target="RFC2104"/> | ||||
for both integrity | b) In the first sentence, should "integrity check" be updated to "integrity | |||
check and as the PBKDF2 pseudorandom function (PRF). It's RECOMMENDED | protection"? Also, how may we update "for both integrity check and as the | |||
for implementations to support other SHA-2 based HMACs. | PBKDF2 pseudorandom function (PRF)" to create parallel structure? | |||
Implementations MAY use other hash functions, like the SHA-3 family | ||||
of hash functions <xref target="SHA3">SHA-3</xref>. | c) In the second and third sentences, please confirm that "keyLen field" is | |||
Implementations MAY use other KDF methods, like the scrypt PBKDF | correct. We ask because we see "keyLength field" in Appendix B (and in RFCs | |||
<xref target="RFC7914"/>. | 7914 and 8018). | |||
</t> | ||||
<t>The length of the key generated by the used KDF MUST be encoded | d) In the third sentence, is "PBKDF2-params" singular or plural? Should "with | |||
explicitly in the parameters field and SHOULD be the same size as the | PBKDF2-params that omit the keyLen field" be updated to "with a PBKDF2-params | |||
HMAC function output size. That means that PBMAC1-params specifying | that omits the keyLen field"? | |||
SHA-256 HMAC should also include KDF parameters that generate 32 octet | ||||
long key. In particular, when using the PBKDF2, the implementations | Original: | |||
MUST include the keyLen field in the encoded PBKDF2-params. | To provide interoperability between different implementations, all | |||
Implementations MUST NOT accept PBKDF2 KDF with PBKDF2-params that | implementations of this specification MUST support the PBKDF2 key | |||
derivation function paired with SHA-256 HMAC [SHA2] [RFC2104] for | ||||
both integrity check and as the PBKDF2 pseudorandom function (PRF). | ||||
... | ||||
In particular, when using the PBKDF2, the | ||||
implementations MUST include the keyLen field in the encoded | ||||
PBKDF2-params. | ||||
... | ||||
Implementations MUST NOT accept PBKDF2 KDF with | ||||
PBKDF2-params that omit the keyLen field. | ||||
Perhaps: | ||||
To provide interoperability between different implementations, all | ||||
implementations of this specification MUST support PBKDF2 | ||||
paired with SHA-256 HMAC [SHA2] [RFC2104] both | ||||
for integrity protection and as the PBKDF2 pseudorandom function (PRF). | ||||
... | ||||
In particular, when using PBKDF2, | ||||
implementations MUST include the keyLength field in the encoded | ||||
PBKDF2-params. | ||||
... | ||||
Implementations MUST NOT accept PBKDF2 with a | ||||
PBKDF2-params that omits the keyLength field. | ||||
--> | ||||
<t>To provide interoperability between different implementations, all | ||||
implementations of this specification <bcp14>MUST</bcp14> support the PBKD | ||||
F2 key derivation function | ||||
paired with SHA-256 HMAC <xref target="SHA2" format="default"/> <xref | ||||
target="RFC2104" format="default"/> for both integrity check and as the | ||||
PBKDF2 pseudorandom function (PRF). It's <bcp14>RECOMMENDED</bcp14> for | ||||
implementations to support other SHA-2-based HMACs. Implementations | ||||
<bcp14>MAY</bcp14> use other hash functions, like the SHA-3 family of | ||||
hash functions <xref target="SHA3" format="default"/>. Implementations | ||||
<bcp14>MAY</bcp14> use other KDF methods, like the scrypt PBKDF <xref | ||||
target="RFC7914" format="default"/>. | ||||
</t> | ||||
<t>The length of the key generated by the used KDF <bcp14>MUST</bcp14> be | ||||
encoded | ||||
explicitly in the parameters field and <bcp14>SHOULD</bcp14> be the same | ||||
size as the | ||||
HMAC function output size. This means that PBMAC1-params specifying | ||||
SHA-256 HMAC should also include KDF parameters that generate a 32-octet | ||||
key. In particular, when using the PBKDF2, implementations | ||||
<bcp14>MUST</bcp14> include the keyLen field in the encoded PBKDF2-param | ||||
s. | ||||
Implementations <bcp14>MUST NOT</bcp14> accept PBKDF2 KDF with PBKDF2-pa | ||||
rams that | ||||
omit the keyLen field. | omit the keyLen field. | |||
</t> | </t> | |||
</section> | </section> | |||
<section numbered="true" toc="default"> | ||||
<section title="Password encoding"> | <name>Password Encoding</name> | |||
<t>As documented in <xref target="RFC7292">Appendix B.1 of RFC | <t>As documented in <xref target="RFC7292" sectionFormat="of" | |||
7292</xref> handling of password encoding in the underlying standards | section="B.1"/>, the handling of password encoding in the underlying | |||
is underspecified. However, just as with PBES1 and PBES2 when used in | standards is underspecified. However, just as with | |||
the context of PKCS#12 objects, all passwords used with PBMAC1 MUST | PBES1 and PBES2 when used in the context of | |||
be created from BMPStrings with a NULL terminator. | PKCS #12 objects, all passwords used with PBMAC1 <bcp14>MUST</bcp14> be | |||
</t> | created from BMPStrings with a NULL terminator. | |||
</t> | ||||
</section> | </section> | |||
<section numbered="true" toc="default"> | ||||
<name>Deprecated Algorithms</name> | ||||
<section title="Deprecated Algorithms"> | <!--[rfced] Please confirm that "practical" is the correct word choice here | |||
<t>While attacks against SHA-1 HMACs are not considered practical | (we do not see this word in RFC 6194). Also, we see "SHA-1" and | |||
<xref target="RFC6194"/> to limit the number of algorithms needed | "HMAC-SHA-1" in RFC 6194, but this sentence uses "SHA-1 HMACs". Is this | |||
for interoperatbility, implementations of this specification | okay? Last, may we update as follows to include a semicolon to improve | |||
SHOULD NOT use PBKDF2 with the SHA-1 HMAC. Additionally | readability? | |||
the implementation MUST NOT use any other message digest functions | ||||
with output of 160 bits or smaller.</t> | ||||
</section> | ||||
<!-- Possibly a 'Contributors' section ... --> | Original: | |||
While attacks against SHA-1 HMACs are not considered practical | ||||
[RFC6194] to limit the number of algorithms needed for | ||||
interoperatbility, implementations of this specification SHOULD NOT | ||||
use PBKDF2 with the SHA-1 HMAC. | ||||
<section anchor="IANA" title="IANA Considerations"> | Perhaps: | |||
<t>IANA is requested to assign an object identifier from the | Attacks against SHA-1 HMACs are not considered practical | |||
SMI Security for S/MIME Module Identifier registry for the | [RFC6194]; to limit the number of algorithms needed for | |||
ASN.1 module found in Appendix B.</t> | interoperability, implementations of this specification SHOULD NOT | |||
use PBKDF2 with the SHA-1 HMAC. | ||||
--> | ||||
<t>While attacks against SHA-1 HMACs are not considered practical | ||||
<xref target="RFC6194" format="default"/> to limit the number of alg | ||||
orithms needed | ||||
for interoperability, implementations of this specification | ||||
<bcp14>SHOULD NOT</bcp14> use PBKDF2 with the SHA-1 HMAC. In additio | ||||
n, | ||||
implementations <bcp14>MUST NOT</bcp14> use any other message digest | ||||
functions | ||||
with an output of 160 bits or less.</t> | ||||
</section> | </section> | |||
<section anchor="Security" title="Security Considerations"> | <section anchor="IANA" numbered="true" toc="default"> | |||
<t>Except for use of different key derivation functions, this document | <name>IANA Considerations</name> | |||
<t>IANA has registered the following object identifier in the | ||||
"SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)" r | ||||
egistry. See <xref target="asn1-module"/> for the ASN.1 module. </t> | ||||
<table anchor="iana-table"> | ||||
<name></name> | ||||
<thead> | ||||
<tr> | ||||
<th>Decimal</th> | ||||
<th>Description</th> | ||||
<th>Reference</th> | ||||
</tr> | ||||
</thead> | ||||
<tbody> | ||||
<tr> | ||||
<td>76</td> | ||||
<td>id-pkcs12-pbmac1-2023</td> | ||||
<td>RFC 9579</td> | ||||
</tr> | ||||
</tbody> | ||||
</table> | ||||
</section> | ||||
<section anchor="Security" numbered="true" toc="default"> | ||||
<name>Security Considerations</name> | ||||
<t>Except for the use of different key derivation functions, this document | ||||
doesn't change how the integrity protection on PKCS #12 objects is | doesn't change how the integrity protection on PKCS #12 objects is | |||
computed; therefore all the original security considerations from | computed; therefore, all the security considerations from | |||
<xref target="RFC7292">RFC 7292</xref> apply. | <xref target="RFC7292" format="default"/> apply. | |||
</t> | </t> | |||
<t>Use of PBMAC1 and PBKDF2 is unchanged from <xref target="RFC8018"> | <t>Use of PBMAC1 and PBKDF2 is unchanged from <xref target="RFC8018" | |||
RFC 8018</xref>; therefore all the original security considerations | format="default"/>; therefore, all the security considerations from | |||
apply. | <xref target="RFC8018" format="default"/> apply. | |||
</t> | </t> | |||
<t>The KDFs generally don't have a lower limit for the generated | <t>The KDFs generally don't have a lower limit for the generated | |||
key size, allowing specifying very small key sizes (of 1 octet), which | key size, allowing the specification of very small key sizes (of 1 octet), which | |||
can facilitate brute-force attacks on the HMAC. | can facilitate brute-force attacks on the HMAC. | |||
Since the KDF parameters are not cryptographically protected and | Since the KDF parameters are not cryptographically protected and | |||
HMACs accept arbitrary key sizes, | HMACs accept arbitrary key sizes, | |||
implementations MAY refuse to process KDF parameters that specify small | implementations <bcp14>MAY</bcp14> refuse to process KDF parameters that s | |||
key output sizes or weak parameters. It's RECOMMENDED to reject any KDF | pecify small | |||
parameters that specify key lengths below 20 octets. | key output sizes or weak parameters. It's <bcp14>RECOMMENDED</bcp14> to re | |||
ject any KDF | ||||
parameters that specify key lengths less than 20 octets. | ||||
</t> | </t> | |||
</section> | </section> | |||
</middle> | </middle> | |||
<!-- *****BACK MATTER ***** --> | ||||
<back> | <back> | |||
<!-- References split into informative and normative --> | ||||
<references title="Normative References"> | <references> | |||
&RFC2104; | <name>References</name> | |||
<references> | ||||
&RFC2119; | <name>Normative References</name> | |||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2 | ||||
&RFC6194; | 104.xml"/> | |||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2 | ||||
&RFC7292; | 119.xml"/> | |||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6 | ||||
&RFC8018; | 194.xml"/> | |||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7 | ||||
&RFC8174; | 292.xml"/> | |||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 | ||||
018.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 | ||||
174.xml"/> | ||||
<reference anchor="x680" | <reference anchor="x680" target="https://www.itu.int/rec/T-REC-X.680"> | |||
target="https://www.itu.int/rec/T-REC-X.680"> | <front> | |||
<front> | <title>Information technology - Abstract Syntax | |||
<title>Information Technology - Abstract Syntax | ||||
Notation One (ASN.1): Specification of | Notation One (ASN.1): Specification of | |||
basic notation</title> | basic notation</title> | |||
<author> | <author> | |||
<organization>ITU-T | <organization>ITU-T | |||
</organization> | </organization> | |||
</author> | </author> | |||
<date month="February" year="2021"/> | <date month="February" year="2021"/> | |||
</front> | </front> | |||
<seriesInfo name="ITU-T Recommendation" value="X.680"/> | <seriesInfo name="ITU-T Recommendation" value="X.680"/> | |||
<seriesInfo name="ISO/IEC" value="8824-1:2021"/> | <seriesInfo name="ISO/IEC" value="8824-1:2021" /> | |||
</reference> | </reference> | |||
<reference anchor="x681" | <reference anchor="x681" target="https://www.itu.int/rec/T-REC-X.681"> | |||
target="https://www.itu.int/rec/T-REC-X.681"> | <front> | |||
<front> | <title>Information technology - Abstract Syntax | |||
<title>Information Technology - Abstract Syntax | ||||
Notation One (ASN.1): Information object | Notation One (ASN.1): Information object | |||
specification</title> | specification</title> | |||
<author> | <author> | |||
<organization>ITU-T | <organization>ITU-T | |||
</organization> | </organization> | |||
</author> | </author> | |||
<date month="February" year="2021"/> | <date month="February" year="2021"/> | |||
</front> | </front> | |||
<seriesInfo name="ITU-T Recommendation" value="X.681"/> | <seriesInfo name="ITU-T Recommendation" value="X.681"/> | |||
<seriesInfo name="ISO/IEC" value="8824-2:2021"/> | <seriesInfo name="ISO/IEC" value="8824-2:2021" /> | |||
</reference> | </reference> | |||
<reference anchor="x682" | <reference anchor="x682" target="https://www.itu.int/rec/T-REC-X.682"> | |||
target="https://www.itu.int/rec/T-REC-X.682"> | <front> | |||
<front> | <title>Information technology - Abstract Syntax | |||
<title>Information Technology - Abstract Syntax | ||||
Notation One (ASN.1): Constraint specification</title> | Notation One (ASN.1): Constraint specification</title> | |||
<author> | <author> | |||
<organization>ITU-T | <organization>ITU-T | |||
</organization> | </organization> | |||
</author> | </author> | |||
<date month="February" year="2021"/> | <date month="February" year="2021"/> | |||
</front> | </front> | |||
<seriesInfo name="ITU-T Recommendation" value="X.682"/> | <seriesInfo name="ITU-T Recommendation" value="X.682"/> | |||
<seriesInfo name="ISO/IEC" value="8824-3:2021"/> | <seriesInfo name="ISO/IEC" value="8824-3:2021" /> | |||
</reference> | </reference> | |||
<reference anchor="x683" | <reference anchor="x683" target="https://www.itu.int/rec/T-REC-X.683"> | |||
target="https://www.itu.int/rec/T-REC-X.683"> | <front> <title>Information technology - Abstract Syntax Notation One | |||
<front> | (ASN.1): Parameterization of ASN.1 specifications</title> | |||
<title>Information Technology - Abstract Syntax | <author> | |||
Notation One (ASN.1): Parameterization of ASN.1 | ||||
specifications</title> | ||||
<author> | ||||
<organization>ITU-T | <organization>ITU-T | |||
</organization> | </organization> | |||
</author> | </author> | |||
<date month="February" year="2021"/> | <date month="February" year="2021"/> | |||
</front> | </front> | |||
<seriesInfo name="ITU-T Recommendation" value="X.683"/> | <seriesInfo name="ITU-T Recommendation" value="X.683"/> | |||
<seriesInfo name="ISO/IEC" value="8824-4:2021"/> | <seriesInfo name="ISO/IEC" value="8824-4:2021" /> | |||
</reference> | </reference> | |||
<reference anchor="x690" | <reference anchor="x690" target="https://www.itu.int/rec/T-REC-X.690"> | |||
target="https://www.itu.int/rec/T-REC-X.690"> | <front> | |||
<front> | <title>Information technology - ASN.1 encoding rules: Specification | |||
<title>Information Technology - ASN.1 encoding rules: | of Basic Encoding Rules (BER), | |||
Specification of Basic Encoding Rules (BER), | Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)</ | |||
Canonical Encoding Rules (CER) and | title> | |||
Distinguished Encoding Rules (DER)</title> | <author> | |||
<author> | ||||
<organization>ITU-T | <organization>ITU-T | |||
</organization> | </organization> | |||
</author> | </author> | |||
<date month="February" year="2021"/> | <date month="February" year="2021"/> | |||
</front> | </front> | |||
<seriesInfo name="ITU-T Recommendation" value="X.690"/> | <seriesInfo name="ITU-T Recommendation" value="X.690"/> | |||
<seriesInfo name="ISO/IEC" value="8825-1:2021"/> | <seriesInfo name="ISO/IEC" value="8825-1:2021" /> | |||
</reference> | </reference> | |||
<reference anchor="SHA2" | <reference anchor="SHA2" target="https://nvlpubs.nist.gov/nistpubs/FIPS/ | |||
target="https://doi.org/10.6028/NIST.FIPS.180-4 "> | NIST.FIPS.180-4.pdf"> | |||
<front> | <front> | |||
<title>Secure Hash Standard (SHS)</title> | <title>Secure Hash Standard (SHS)</title> | |||
<author> | <author> | |||
<organization>National Institute of Standards and Technology | <organization>National Institute of Standards and Technology (NIST | |||
) | ||||
</organization> | </organization> | |||
</author> | </author> | |||
<date month="August" year="2015"/> | <date month="August" year="2015"/> | |||
</front> | </front> | |||
</reference> | <seriesInfo name="FIPS PUB" value="180-4"/> | |||
<seriesInfo name="DOI" value="10.6028/NIST.FIPS.180-4"/> | ||||
</references> | </reference> | |||
</references> | ||||
<references title="Informative References"> | ||||
&RFC7914; | <references> | |||
<name>Informative References</name> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7 | ||||
914.xml"/> | ||||
<reference anchor="SHA3" | <reference anchor="SHA3" target="https://nvlpubs.nist.gov/nistpubs/FIPS/ | |||
target="https://doi.org/10.6028/NIST.FIPS.202"> | NIST.FIPS.202.pdf"> | |||
<front> | <front> | |||
<title>SHA-3 Standard: Permutation-Based Hash and Extendable-Output | <title>SHA-3 Standard: Permutation-Based Hash and Extendable-Output | |||
Functions</title> | Functions</title> | |||
<author> | <author> | |||
<organization>National Institute of Standards and Technology | <organization>National Institute of Standards and Technology (NIST | |||
) | ||||
</organization> | </organization> | |||
</author> | </author> | |||
<date month="August" year="2015"/> | <date month="August" year="2015"/> | |||
</front> | </front> | |||
</reference> | <seriesInfo name="FIPS PUB" value="202"/> | |||
<seriesInfo name="DOI" value="10.6028/NIST.FIPS.202"/> | ||||
</reference> | ||||
</references> | ||||
</references> | </references> | |||
<section anchor="test-vectors" title="Test Vectors"> | <section anchor="test-vectors" numbered="true" toc="default"> | |||
<name>Test Vectors</name> | ||||
<t>All test vectors use "1234" as the password for both encryption | <t>All test vectors use "1234" as the password for both encryption | |||
and integrity protection.</t> | and integrity protection.</t> | |||
<section title="Valid PKCS#12 file with SHA-256 HMAC and PRF"> | <section numbered="true" toc="default"> | |||
<t>The following base64 encoded PKCS#12 file MUST be readable by | <name>Valid PKCS #12 File with SHA-256 HMAC and PRF</name> | |||
<t>The following base64-encoded PKCS #12 file <bcp14>MUST</bcp14> be rea | ||||
dable by | ||||
implementations following this RFC. | implementations following this RFC. | |||
<artwork> | </t> | |||
<sourcecode type="test-vectors"><![CDATA[ | ||||
MIIKigIBAzCCCgUGCSqGSIb3DQEHAaCCCfYEggnyMIIJ7jCCBGIGCSqGSIb3DQEH | MIIKigIBAzCCCgUGCSqGSIb3DQEHAaCCCfYEggnyMIIJ7jCCBGIGCSqGSIb3DQEH | |||
BqCCBFMwggRPAgEAMIIESAYJKoZIhvcNAQcBMFcGCSqGSIb3DQEFDTBKMCkGCSqG | BqCCBFMwggRPAgEAMIIESAYJKoZIhvcNAQcBMFcGCSqGSIb3DQEFDTBKMCkGCSqG | |||
SIb3DQEFDDAcBAg9pxXxY2yscwICCAAwDAYIKoZIhvcNAgkFADAdBglghkgBZQME | SIb3DQEFDDAcBAg9pxXxY2yscwICCAAwDAYIKoZIhvcNAgkFADAdBglghkgBZQME | |||
ASoEEK7yYaFQDi1pYwWzm9F/fs+AggPgFIT2XapyaFgDppdvLkdvaF3HXw+zjzKb | ASoEEK7yYaFQDi1pYwWzm9F/fs+AggPgFIT2XapyaFgDppdvLkdvaF3HXw+zjzKb | |||
7xFC76DtVPhVTWVHD+kIss+jsj+XyvMwY0aCuAhAG/Dig+vzWomnsqB5ssw5/kTb | 7xFC76DtVPhVTWVHD+kIss+jsj+XyvMwY0aCuAhAG/Dig+vzWomnsqB5ssw5/kTb | |||
+TMQ5PXLkNeoBmB6ArKeGc/QmCBQvQG/a6b+nXSWmxNpP+71772dmWmB8gcSJ0kF | +TMQ5PXLkNeoBmB6ArKeGc/QmCBQvQG/a6b+nXSWmxNpP+71772dmWmB8gcSJ0kF | |||
Fj75NrIbmNiDMCb71Q8gOzBMFf6BpXf/3xWAJtxyic+tSNETfOJa8zTZb0+lV0w9 | Fj75NrIbmNiDMCb71Q8gOzBMFf6BpXf/3xWAJtxyic+tSNETfOJa8zTZb0+lV0w9 | |||
5eUmDrPUpuxEVbb0KJtIc63gRkcfrPtDd6Ii4Zzbzj2Evr4/S4hnrQBsiryVzJWy | 5eUmDrPUpuxEVbb0KJtIc63gRkcfrPtDd6Ii4Zzbzj2Evr4/S4hnrQBsiryVzJWy | |||
IEjaD0y6+DmG0JwMgRuGi1wBoGowi37GMrDCOyOZWC4n5wHLtYyhR6JaElxbrhxP | IEjaD0y6+DmG0JwMgRuGi1wBoGowi37GMrDCOyOZWC4n5wHLtYyhR6JaElxbrhxP | |||
H46z2USLKmZoF+YgEQgYcSBXMgP0t36+XQocFWYi2N5niy02TnctwF430FYsQlhJ | H46z2USLKmZoF+YgEQgYcSBXMgP0t36+XQocFWYi2N5niy02TnctwF430FYsQlhJ | |||
skipping to change at line 418 ¶ | skipping to change at line 546 ¶ | |||
qniZjKzSZepxlZq+J792u8vtMnuzzChxu0Bf3PhIXcJNcVhwUtr0yKe/N+NvC0tm | qniZjKzSZepxlZq+J792u8vtMnuzzChxu0Bf3PhIXcJNcVhwUtr0yKe/N+NvC0tm | |||
p8wyik/BlndxN9eKbdTOi2wIi64h2QG8nOk66wQ/PSIJYwZl6eDNEQSzH/1mGCfU | p8wyik/BlndxN9eKbdTOi2wIi64h2QG8nOk66wQ/PSIJYwZl6eDNEQSzH/1mGCfU | |||
QnUT17UC/p+Qgenf6Auap2GWlvsJrB7u/pytz65rtjt/ouo6Ih6EwWqwVVpGXZD0 | QnUT17UC/p+Qgenf6Auap2GWlvsJrB7u/pytz65rtjt/ouo6Ih6EwWqwVVpGXZD0 | |||
7gVWH0Ke/Vr6aPGNvkLcmftPuDZsn9jiig3guhdeyRVf10Ox369kKWcG75q77hxE | 7gVWH0Ke/Vr6aPGNvkLcmftPuDZsn9jiig3guhdeyRVf10Ox369kKWcG75q77hxE | |||
IzSzDyUlBNbnom9SIjut3r+qVYmWONatC6q/4D0I42Lnjd3dEyZx7jmH3g/S2ASM | IzSzDyUlBNbnom9SIjut3r+qVYmWONatC6q/4D0I42Lnjd3dEyZx7jmH3g/S2ASM | |||
FzWr9pvXc61dsYOkdZ4PYa9XPUZxXFagZsoS3F1sU799+IJVU0tC0MExJTAjBgkq | FzWr9pvXc61dsYOkdZ4PYa9XPUZxXFagZsoS3F1sU799+IJVU0tC0MExJTAjBgkq | |||
hkiG9w0BCRUxFgQUwWO5DorvVWYF3BWUmAw0rUEajScwfDBtMEkGCSqGSIb3DQEF | hkiG9w0BCRUxFgQUwWO5DorvVWYF3BWUmAw0rUEajScwfDBtMEkGCSqGSIb3DQEF | |||
DjA8MCwGCSqGSIb3DQEFDDAfBAhvRzw4sC4xcwICCAACASAwDAYIKoZIhvcNAgkF | DjA8MCwGCSqGSIb3DQEFDDAfBAhvRzw4sC4xcwICCAACASAwDAYIKoZIhvcNAgkF | |||
ADAMBggqhkiG9w0CCQUABCB6pW2FOdcCNj87zS64NUXG36K5aXDnFHctIk5Bf4kG | ADAMBggqhkiG9w0CCQUABCB6pW2FOdcCNj87zS64NUXG36K5aXDnFHctIk5Bf4kG | |||
3QQITk9UIFVTRUQCAQE= | 3QQITk9UIFVTRUQCAQE= | |||
</artwork></t> | ]]></sourcecode> | |||
</section> | </section> | |||
<section title="Valid PKCS#12 file with SHA-256 HMAC and SHA-512 PRF"> | <section numbered="true" toc="default"> | |||
<t>The following base64 encoded PKCS#12 file SHOULD be readable by | <name>Valid PKCS #12 File with SHA-256 HMAC and SHA-512 PRF</name> | |||
<t>The following base64-encoded PKCS #12 file <bcp14>SHOULD</bcp14> be r | ||||
eadable by | ||||
implementations following this RFC. | implementations following this RFC. | |||
<artwork> | </t> | |||
<sourcecode type="test-vectors"><![CDATA[ | ||||
MIIKigIBAzCCCgUGCSqGSIb3DQEHAaCCCfYEggnyMIIJ7jCCBGIGCSqGSIb3DQEH | MIIKigIBAzCCCgUGCSqGSIb3DQEHAaCCCfYEggnyMIIJ7jCCBGIGCSqGSIb3DQEH | |||
BqCCBFMwggRPAgEAMIIESAYJKoZIhvcNAQcBMFcGCSqGSIb3DQEFDTBKMCkGCSqG | BqCCBFMwggRPAgEAMIIESAYJKoZIhvcNAQcBMFcGCSqGSIb3DQEFDTBKMCkGCSqG | |||
SIb3DQEFDDAcBAi4j6UBBY2iOgICCAAwDAYIKoZIhvcNAgkFADAdBglghkgBZQME | SIb3DQEFDDAcBAi4j6UBBY2iOgICCAAwDAYIKoZIhvcNAgkFADAdBglghkgBZQME | |||
ASoEEFpHSS5zrk/9pkDo1JRbtE6AggPgtbMLGoFd5KLpVXMdcxLrT129L7/vCr0B | ASoEEFpHSS5zrk/9pkDo1JRbtE6AggPgtbMLGoFd5KLpVXMdcxLrT129L7/vCr0B | |||
0I2tnhPPA7aFtRjjuGbwooCMQwxw9qzuCX1eH4xK2LUw6Gbd2H47WimSOWJMaiUb | 0I2tnhPPA7aFtRjjuGbwooCMQwxw9qzuCX1eH4xK2LUw6Gbd2H47WimSOWJMaiUb | |||
wy4alIWELYufe74kXPmKPCyH92lN1hqu8s0EGhIl7nBhWbFzow1+qpIc9/lpujJo | wy4alIWELYufe74kXPmKPCyH92lN1hqu8s0EGhIl7nBhWbFzow1+qpIc9/lpujJo | |||
wodSY+pNBD8oBeoU1m6DgOjgc62apL7m0nwavDUqEt7HAqtTBxKxu/3lpb1q8nbl | wodSY+pNBD8oBeoU1m6DgOjgc62apL7m0nwavDUqEt7HAqtTBxKxu/3lpb1q8nbl | |||
XLTqROax5feXErf+GQAqs24hUJIPg3O1eCMDVzH0h5pgZyRN9ZSIP0HC1i+d1lnb | XLTqROax5feXErf+GQAqs24hUJIPg3O1eCMDVzH0h5pgZyRN9ZSIP0HC1i+d1lnb | |||
JwHyrAhZv8GMdAVKaXHETbq8zTpxT3UE/LmH1gyZGOG2B21D2dvNDKa712sHOS/t | JwHyrAhZv8GMdAVKaXHETbq8zTpxT3UE/LmH1gyZGOG2B21D2dvNDKa712sHOS/t | |||
3XkFngHDLx+a9pVftt6p7Nh6jqI581tb7fyc7HBV9VUc/+xGgPgHZouaZw+I3PUz | 3XkFngHDLx+a9pVftt6p7Nh6jqI581tb7fyc7HBV9VUc/+xGgPgHZouaZw+I3PUz | |||
skipping to change at line 481 ¶ | skipping to change at line 611 ¶ | |||
clYKzNwmgwbdtmVAXmQxLuhmEpXfstIzkBrNJzChzb2onNSfa+r5L6XEHNHl7wCw | clYKzNwmgwbdtmVAXmQxLuhmEpXfstIzkBrNJzChzb2onNSfa+r5L6XEHNHl7wCw | |||
TuuV/JWldNuYXLfVfuv3msfSjSWkv6aRtRWIvmOv0Qba2o05LlwFMd1PzKM5uN4D | TuuV/JWldNuYXLfVfuv3msfSjSWkv6aRtRWIvmOv0Qba2o05LlwFMd1PzKM5uN4D | |||
DYtsS9A6yQOXEsvUkWcLOJnCs8SkJRdXhJTxdmzeBqM1JttKwLbgGMbpjbxlg3ns | DYtsS9A6yQOXEsvUkWcLOJnCs8SkJRdXhJTxdmzeBqM1JttKwLbgGMbpjbxlg3ns | |||
N+Z+sEFox+2ZWOglgnBHj0mCZOiAC8wqUu+sxsLT4WndaPWKVqoRQChvDaZaNOaN | N+Z+sEFox+2ZWOglgnBHj0mCZOiAC8wqUu+sxsLT4WndaPWKVqoRQChvDaZaNOaN | |||
qHciF9HPUcfZow+fH8TnSHneiQcDe6XcMhSaQ2MtpY8/jrgNKguZt22yH9gw/VpT | qHciF9HPUcfZow+fH8TnSHneiQcDe6XcMhSaQ2MtpY8/jrgNKguZt22yH9gw/VpT | |||
3/QOB7FBgKFIEbvUaf3nVjFIlryIheg+LeiBd2isoMNNXaBwcg2YXukxJTAjBgkq | 3/QOB7FBgKFIEbvUaf3nVjFIlryIheg+LeiBd2isoMNNXaBwcg2YXukxJTAjBgkq | |||
hkiG9w0BCRUxFgQUwWO5DorvVWYF3BWUmAw0rUEajScwfDBtMEkGCSqGSIb3DQEF | hkiG9w0BCRUxFgQUwWO5DorvVWYF3BWUmAw0rUEajScwfDBtMEkGCSqGSIb3DQEF | |||
DjA8MCwGCSqGSIb3DQEFDDAfBAgUr2yP+/DBrgICCAACASAwDAYIKoZIhvcNAgsF | DjA8MCwGCSqGSIb3DQEFDDAfBAgUr2yP+/DBrgICCAACASAwDAYIKoZIhvcNAgsF | |||
ADAMBggqhkiG9w0CCQUABCA5zFL93jw8ItGlcbHKhqkNwbgpp6layuOuxSju4/Vd | ADAMBggqhkiG9w0CCQUABCA5zFL93jw8ItGlcbHKhqkNwbgpp6layuOuxSju4/Vd | |||
6QQITk9UIFVTRUQCAQE= | 6QQITk9UIFVTRUQCAQE= | |||
</artwork></t> | ]]></sourcecode> | |||
</section> | </section> | |||
<section title="Valid PKCS#12 file with SHA-512 HMAC and PRF"> | <section numbered="true" toc="default"> | |||
<t>The following base64 encoded PKCS#12 file SHOULD be readable by | <name>Valid PKCS #12 File with SHA-512 HMAC and PRF</name> | |||
<t>The following base64-encoded PKCS #12 file <bcp14>SHOULD</bcp14> be r | ||||
eadable by | ||||
implementations following this RFC. | implementations following this RFC. | |||
<artwork> | </t> | |||
<sourcecode type="test-vectors"><![CDATA[ | ||||
MIIKrAIBAzCCCgUGCSqGSIb3DQEHAaCCCfYEggnyMIIJ7jCCBGIGCSqGSIb3DQEH | MIIKrAIBAzCCCgUGCSqGSIb3DQEHAaCCCfYEggnyMIIJ7jCCBGIGCSqGSIb3DQEH | |||
BqCCBFMwggRPAgEAMIIESAYJKoZIhvcNAQcBMFcGCSqGSIb3DQEFDTBKMCkGCSqG | BqCCBFMwggRPAgEAMIIESAYJKoZIhvcNAQcBMFcGCSqGSIb3DQEFDTBKMCkGCSqG | |||
SIb3DQEFDDAcBAisrqL8obSBaQICCAAwDAYIKoZIhvcNAgkFADAdBglghkgBZQME | SIb3DQEFDDAcBAisrqL8obSBaQICCAAwDAYIKoZIhvcNAgkFADAdBglghkgBZQME | |||
ASoEECjXYYca0pwsgn1Imb9WqFGAggPgT7RcF5YzEJANZU9G3tSdpCHnyWatTlhm | ASoEECjXYYca0pwsgn1Imb9WqFGAggPgT7RcF5YzEJANZU9G3tSdpCHnyWatTlhm | |||
iCEcBGgwI5gz0+GoX+JCojgYY4g+KxeqznyCu+6GeD00T4Em7SWme9nzAfBFzng0 | iCEcBGgwI5gz0+GoX+JCojgYY4g+KxeqznyCu+6GeD00T4Em7SWme9nzAfBFzng0 | |||
3lYCSnahSEKfgHerbzAtq9kgXkclPVk0Liy92/buf0Mqotjjs/5o78AqP86Pwbj8 | 3lYCSnahSEKfgHerbzAtq9kgXkclPVk0Liy92/buf0Mqotjjs/5o78AqP86Pwbj8 | |||
xYNuXOU1ivO0JiW2c2HefKYvUvMYlOh99LCoZPLHPkaaZ4scAwDjFeTICU8oowVk | xYNuXOU1ivO0JiW2c2HefKYvUvMYlOh99LCoZPLHPkaaZ4scAwDjFeTICU8oowVk | |||
LKvslrg1pHbfmXHMFJ4yqub37hRtj2CoJNy4+UA2hBYlBi9WnuAJIsjv0qS3kpLe | LKvslrg1pHbfmXHMFJ4yqub37hRtj2CoJNy4+UA2hBYlBi9WnuAJIsjv0qS3kpLe | |||
4+J2DGe31GNG8pD01XD0l69OlailK1ykh4ap2u0KeD2z357+trCFbpWMMXQcSUCO | 4+J2DGe31GNG8pD01XD0l69OlailK1ykh4ap2u0KeD2z357+trCFbpWMMXQcSUCO | |||
OcVjxYqgv/l1++9huOHoPSt224x4wZfJ7cO2zbAAx/K2CPhdvi4CBaDHADsRq/c8 | OcVjxYqgv/l1++9huOHoPSt224x4wZfJ7cO2zbAAx/K2CPhdvi4CBaDHADsRq/c8 | |||
skipping to change at line 544 ¶ | skipping to change at line 676 ¶ | |||
nRwtjpevqAnIuK6K3Y02LY4FXTNQpC37Xb04bmdIQAcE0MaoP4/hY87aS82PQ68g | nRwtjpevqAnIuK6K3Y02LY4FXTNQpC37Xb04bmdIQAcE0MaoP4/hY87aS82PQ68g | |||
3bI79uKo4we2g+WaEJlEzQ7147ZzV2wbDq89W69x1MWTfaDwlEtd4UaacYchAv7B | 3bI79uKo4we2g+WaEJlEzQ7147ZzV2wbDq89W69x1MWTfaDwlEtd4UaacYchAv7B | |||
TVaaVFiRAUywWaHGePpZG2WV1feH/zd+temxWR9qMFgBZySg1jipBPVciwl0LqlW | TVaaVFiRAUywWaHGePpZG2WV1feH/zd+temxWR9qMFgBZySg1jipBPVciwl0LqlW | |||
s/raIBYmLmAaMMgM3759UkNVznDoFHrY4z2EADXp0RHHVzJS1x+yYvp/9I+AcW55 | s/raIBYmLmAaMMgM3759UkNVznDoFHrY4z2EADXp0RHHVzJS1x+yYvp/9I+AcW55 | |||
oN0UP/3uQ6eyz/ix22sovQwhMJ8rmgR6CfyRPKmXu1RPK3puNv7mbFTfTXpYN2vX | oN0UP/3uQ6eyz/ix22sovQwhMJ8rmgR6CfyRPKmXu1RPK3puNv7mbFTfTXpYN2vX | |||
vhEZReXY8hJF/9o4G3UrJ1F0MgUHMCG86cw1z0bhPSaXVoufOnx/fRoxJTAjBgkq | vhEZReXY8hJF/9o4G3UrJ1F0MgUHMCG86cw1z0bhPSaXVoufOnx/fRoxJTAjBgkq | |||
hkiG9w0BCRUxFgQUwWO5DorvVWYF3BWUmAw0rUEajScwgZ0wgY0wSQYJKoZIhvcN | hkiG9w0BCRUxFgQUwWO5DorvVWYF3BWUmAw0rUEajScwgZ0wgY0wSQYJKoZIhvcN | |||
AQUOMDwwLAYJKoZIhvcNAQUMMB8ECFDaXOUaOcUPAgIIAAIBQDAMBggqhkiG9w0C | AQUOMDwwLAYJKoZIhvcNAQUMMB8ECFDaXOUaOcUPAgIIAAIBQDAMBggqhkiG9w0C | |||
CwUAMAwGCCqGSIb3DQILBQAEQHIAM8C9OAsHUCj9CmOJioqf7YwD4O/b3UiZ3Wqo | CwUAMAwGCCqGSIb3DQILBQAEQHIAM8C9OAsHUCj9CmOJioqf7YwD4O/b3UiZ3Wqo | |||
F6OmQIRDc68SdkZJ6024l4nWlnhTE7a4lb2Tru4k3NOTa1oECE5PVCBVU0VEAgEB | F6OmQIRDc68SdkZJ6024l4nWlnhTE7a4lb2Tru4k3NOTa1oECE5PVCBVU0VEAgEB | |||
</artwork> | ]]></sourcecode> | |||
</t> | ||||
</section> | </section> | |||
<section title="Invalid PKCS#12 file with incorrect iteration count"> | <section numbered="true" toc="default"> | |||
<t>The following base64 encoded PKCS#12 file MUST NOT be readable | <name>Invalid PKCS #12 File with Incorrect Iteration Count</name> | |||
<t>The following base64-encoded PKCS #12 file <bcp14>MUST NOT</bcp14> be | ||||
readable | ||||
by an implementation following this RFC when it is verifying | by an implementation following this RFC when it is verifying | |||
itegrity protection. | integrity protection. | |||
<artwork> | </t> | |||
<sourcecode type="test-vectors"><![CDATA[ | ||||
MIIKiwIBAzCCCgUGCSqGSIb3DQEHAaCCCfYEggnyMIIJ7jCCBGIGCSqGSIb3DQEH | MIIKiwIBAzCCCgUGCSqGSIb3DQEHAaCCCfYEggnyMIIJ7jCCBGIGCSqGSIb3DQEH | |||
BqCCBFMwggRPAgEAMIIESAYJKoZIhvcNAQcBMFcGCSqGSIb3DQEFDTBKMCkGCSqG | BqCCBFMwggRPAgEAMIIESAYJKoZIhvcNAQcBMFcGCSqGSIb3DQEFDTBKMCkGCSqG | |||
SIb3DQEFDDAcBAg9pxXxY2yscwICCAAwDAYIKoZIhvcNAgkFADAdBglghkgBZQME | SIb3DQEFDDAcBAg9pxXxY2yscwICCAAwDAYIKoZIhvcNAgkFADAdBglghkgBZQME | |||
ASoEEK7yYaFQDi1pYwWzm9F/fs+AggPgFIT2XapyaFgDppdvLkdvaF3HXw+zjzKb | ASoEEK7yYaFQDi1pYwWzm9F/fs+AggPgFIT2XapyaFgDppdvLkdvaF3HXw+zjzKb | |||
7xFC76DtVPhVTWVHD+kIss+jsj+XyvMwY0aCuAhAG/Dig+vzWomnsqB5ssw5/kTb | 7xFC76DtVPhVTWVHD+kIss+jsj+XyvMwY0aCuAhAG/Dig+vzWomnsqB5ssw5/kTb | |||
+TMQ5PXLkNeoBmB6ArKeGc/QmCBQvQG/a6b+nXSWmxNpP+71772dmWmB8gcSJ0kF | +TMQ5PXLkNeoBmB6ArKeGc/QmCBQvQG/a6b+nXSWmxNpP+71772dmWmB8gcSJ0kF | |||
Fj75NrIbmNiDMCb71Q8gOzBMFf6BpXf/3xWAJtxyic+tSNETfOJa8zTZb0+lV0w9 | Fj75NrIbmNiDMCb71Q8gOzBMFf6BpXf/3xWAJtxyic+tSNETfOJa8zTZb0+lV0w9 | |||
5eUmDrPUpuxEVbb0KJtIc63gRkcfrPtDd6Ii4Zzbzj2Evr4/S4hnrQBsiryVzJWy | 5eUmDrPUpuxEVbb0KJtIc63gRkcfrPtDd6Ii4Zzbzj2Evr4/S4hnrQBsiryVzJWy | |||
IEjaD0y6+DmG0JwMgRuGi1wBoGowi37GMrDCOyOZWC4n5wHLtYyhR6JaElxbrhxP | IEjaD0y6+DmG0JwMgRuGi1wBoGowi37GMrDCOyOZWC4n5wHLtYyhR6JaElxbrhxP | |||
H46z2USLKmZoF+YgEQgYcSBXMgP0t36+XQocFWYi2N5niy02TnctwF430FYsQlhJ | H46z2USLKmZoF+YgEQgYcSBXMgP0t36+XQocFWYi2N5niy02TnctwF430FYsQlhJ | |||
skipping to change at line 609 ¶ | skipping to change at line 742 ¶ | |||
qniZjKzSZepxlZq+J792u8vtMnuzzChxu0Bf3PhIXcJNcVhwUtr0yKe/N+NvC0tm | qniZjKzSZepxlZq+J792u8vtMnuzzChxu0Bf3PhIXcJNcVhwUtr0yKe/N+NvC0tm | |||
p8wyik/BlndxN9eKbdTOi2wIi64h2QG8nOk66wQ/PSIJYwZl6eDNEQSzH/1mGCfU | p8wyik/BlndxN9eKbdTOi2wIi64h2QG8nOk66wQ/PSIJYwZl6eDNEQSzH/1mGCfU | |||
QnUT17UC/p+Qgenf6Auap2GWlvsJrB7u/pytz65rtjt/ouo6Ih6EwWqwVVpGXZD0 | QnUT17UC/p+Qgenf6Auap2GWlvsJrB7u/pytz65rtjt/ouo6Ih6EwWqwVVpGXZD0 | |||
7gVWH0Ke/Vr6aPGNvkLcmftPuDZsn9jiig3guhdeyRVf10Ox369kKWcG75q77hxE | 7gVWH0Ke/Vr6aPGNvkLcmftPuDZsn9jiig3guhdeyRVf10Ox369kKWcG75q77hxE | |||
IzSzDyUlBNbnom9SIjut3r+qVYmWONatC6q/4D0I42Lnjd3dEyZx7jmH3g/S2ASM | IzSzDyUlBNbnom9SIjut3r+qVYmWONatC6q/4D0I42Lnjd3dEyZx7jmH3g/S2ASM | |||
FzWr9pvXc61dsYOkdZ4PYa9XPUZxXFagZsoS3F1sU799+IJVU0tC0MExJTAjBgkq | FzWr9pvXc61dsYOkdZ4PYa9XPUZxXFagZsoS3F1sU799+IJVU0tC0MExJTAjBgkq | |||
hkiG9w0BCRUxFgQUwWO5DorvVWYF3BWUmAw0rUEajScwfTBtMEkGCSqGSIb3DQEF | hkiG9w0BCRUxFgQUwWO5DorvVWYF3BWUmAw0rUEajScwfTBtMEkGCSqGSIb3DQEF | |||
DjA8MCwGCSqGSIb3DQEFDDAfBAhvRzw4sC4xcwICCAECASAwDAYIKoZIhvcNAgkF | DjA8MCwGCSqGSIb3DQEFDDAfBAhvRzw4sC4xcwICCAECASAwDAYIKoZIhvcNAgkF | |||
ADAMBggqhkiG9w0CCQUABCB6pW2FOdcCNj87zS64NUXG36K5aXDnFHctIk5Bf4kG | ADAMBggqhkiG9w0CCQUABCB6pW2FOdcCNj87zS64NUXG36K5aXDnFHctIk5Bf4kG | |||
3QQITk9UIFVTRUQCAggA | 3QQITk9UIFVTRUQCAggA | |||
</artwork> | ]]></sourcecode> | |||
</t> | ||||
</section> | </section> | |||
<section title="Invalid PKCS#12 file with incorrect salt"> | <section numbered="true" toc="default"> | |||
<t>The following base64 encoded PKCS#12 file MUST NOT be readable | <name>Invalid PKCS #12 File with Incorrect Salt</name> | |||
<t>The following base64-encoded PKCS #12 file <bcp14>MUST NOT</bcp14> be | ||||
readable | ||||
by an implementation following this RFC when it is verifying | by an implementation following this RFC when it is verifying | |||
itegrity protection. | integrity protection. | |||
<artwork> | </t> | |||
<sourcecode type="test-vectors"><![CDATA[ | ||||
MIIKigIBAzCCCgUGCSqGSIb3DQEHAaCCCfYEggnyMIIJ7jCCBGIGCSqGSIb3DQEH | MIIKigIBAzCCCgUGCSqGSIb3DQEHAaCCCfYEggnyMIIJ7jCCBGIGCSqGSIb3DQEH | |||
BqCCBFMwggRPAgEAMIIESAYJKoZIhvcNAQcBMFcGCSqGSIb3DQEFDTBKMCkGCSqG | BqCCBFMwggRPAgEAMIIESAYJKoZIhvcNAQcBMFcGCSqGSIb3DQEFDTBKMCkGCSqG | |||
SIb3DQEFDDAcBAg9pxXxY2yscwICCAAwDAYIKoZIhvcNAgkFADAdBglghkgBZQME | SIb3DQEFDDAcBAg9pxXxY2yscwICCAAwDAYIKoZIhvcNAgkFADAdBglghkgBZQME | |||
ASoEEK7yYaFQDi1pYwWzm9F/fs+AggPgFIT2XapyaFgDppdvLkdvaF3HXw+zjzKb | ASoEEK7yYaFQDi1pYwWzm9F/fs+AggPgFIT2XapyaFgDppdvLkdvaF3HXw+zjzKb | |||
7xFC76DtVPhVTWVHD+kIss+jsj+XyvMwY0aCuAhAG/Dig+vzWomnsqB5ssw5/kTb | 7xFC76DtVPhVTWVHD+kIss+jsj+XyvMwY0aCuAhAG/Dig+vzWomnsqB5ssw5/kTb | |||
+TMQ5PXLkNeoBmB6ArKeGc/QmCBQvQG/a6b+nXSWmxNpP+71772dmWmB8gcSJ0kF | +TMQ5PXLkNeoBmB6ArKeGc/QmCBQvQG/a6b+nXSWmxNpP+71772dmWmB8gcSJ0kF | |||
Fj75NrIbmNiDMCb71Q8gOzBMFf6BpXf/3xWAJtxyic+tSNETfOJa8zTZb0+lV0w9 | Fj75NrIbmNiDMCb71Q8gOzBMFf6BpXf/3xWAJtxyic+tSNETfOJa8zTZb0+lV0w9 | |||
5eUmDrPUpuxEVbb0KJtIc63gRkcfrPtDd6Ii4Zzbzj2Evr4/S4hnrQBsiryVzJWy | 5eUmDrPUpuxEVbb0KJtIc63gRkcfrPtDd6Ii4Zzbzj2Evr4/S4hnrQBsiryVzJWy | |||
IEjaD0y6+DmG0JwMgRuGi1wBoGowi37GMrDCOyOZWC4n5wHLtYyhR6JaElxbrhxP | IEjaD0y6+DmG0JwMgRuGi1wBoGowi37GMrDCOyOZWC4n5wHLtYyhR6JaElxbrhxP | |||
H46z2USLKmZoF+YgEQgYcSBXMgP0t36+XQocFWYi2N5niy02TnctwF430FYsQlhJ | H46z2USLKmZoF+YgEQgYcSBXMgP0t36+XQocFWYi2N5niy02TnctwF430FYsQlhJ | |||
skipping to change at line 674 ¶ | skipping to change at line 808 ¶ | |||
qniZjKzSZepxlZq+J792u8vtMnuzzChxu0Bf3PhIXcJNcVhwUtr0yKe/N+NvC0tm | qniZjKzSZepxlZq+J792u8vtMnuzzChxu0Bf3PhIXcJNcVhwUtr0yKe/N+NvC0tm | |||
p8wyik/BlndxN9eKbdTOi2wIi64h2QG8nOk66wQ/PSIJYwZl6eDNEQSzH/1mGCfU | p8wyik/BlndxN9eKbdTOi2wIi64h2QG8nOk66wQ/PSIJYwZl6eDNEQSzH/1mGCfU | |||
QnUT17UC/p+Qgenf6Auap2GWlvsJrB7u/pytz65rtjt/ouo6Ih6EwWqwVVpGXZD0 | QnUT17UC/p+Qgenf6Auap2GWlvsJrB7u/pytz65rtjt/ouo6Ih6EwWqwVVpGXZD0 | |||
7gVWH0Ke/Vr6aPGNvkLcmftPuDZsn9jiig3guhdeyRVf10Ox369kKWcG75q77hxE | 7gVWH0Ke/Vr6aPGNvkLcmftPuDZsn9jiig3guhdeyRVf10Ox369kKWcG75q77hxE | |||
IzSzDyUlBNbnom9SIjut3r+qVYmWONatC6q/4D0I42Lnjd3dEyZx7jmH3g/S2ASM | IzSzDyUlBNbnom9SIjut3r+qVYmWONatC6q/4D0I42Lnjd3dEyZx7jmH3g/S2ASM | |||
FzWr9pvXc61dsYOkdZ4PYa9XPUZxXFagZsoS3F1sU799+IJVU0tC0MExJTAjBgkq | FzWr9pvXc61dsYOkdZ4PYa9XPUZxXFagZsoS3F1sU799+IJVU0tC0MExJTAjBgkq | |||
hkiG9w0BCRUxFgQUwWO5DorvVWYF3BWUmAw0rUEajScwfDBtMEkGCSqGSIb3DQEF | hkiG9w0BCRUxFgQUwWO5DorvVWYF3BWUmAw0rUEajScwfDBtMEkGCSqGSIb3DQEF | |||
DjA8MCwGCSqGSIb3DQEFDDAfBAhOT1QgVVNFRAICCAACASAwDAYIKoZIhvcNAgkF | DjA8MCwGCSqGSIb3DQEFDDAfBAhOT1QgVVNFRAICCAACASAwDAYIKoZIhvcNAgkF | |||
ADAMBggqhkiG9w0CCQUABCB6pW2FOdcCNj87zS64NUXG36K5aXDnFHctIk5Bf4kG | ADAMBggqhkiG9w0CCQUABCB6pW2FOdcCNj87zS64NUXG36K5aXDnFHctIk5Bf4kG | |||
3QQIb0c8OLAuMXMCAQE= | 3QQIb0c8OLAuMXMCAQE= | |||
</artwork> | ]]></sourcecode> | |||
</t> | </section> | |||
</section> | <section numbered="true" toc="default"> | |||
<section title="Invalid PKCS#12 file with missing key length"> | <name>Invalid PKCS #12 File with Missing Key Length</name> | |||
<t>The following base64 encoded PKCS#12 file MUST NOT be readable | <t>The following base64-encoded PKCS #12 file <bcp14>MUST NOT</bcp14> be | |||
readable | ||||
by an implementation following this RFC when it is verifying | by an implementation following this RFC when it is verifying | |||
itegrity protection. | integrity protection. | |||
<artwork> | </t> | |||
<sourcecode type="test-vectors"><![CDATA[ | ||||
MIIKiAIBAzCCCgUGCSqGSIb3DQEHAaCCCfYEggnyMIIJ7jCCBGIGCSqGSIb3DQEH | MIIKiAIBAzCCCgUGCSqGSIb3DQEHAaCCCfYEggnyMIIJ7jCCBGIGCSqGSIb3DQEH | |||
BqCCBFMwggRPAgEAMIIESAYJKoZIhvcNAQcBMFcGCSqGSIb3DQEFDTBKMCkGCSqG | BqCCBFMwggRPAgEAMIIESAYJKoZIhvcNAQcBMFcGCSqGSIb3DQEFDTBKMCkGCSqG | |||
SIb3DQEFDDAcBAg9pxXxY2yscwICCAAwDAYIKoZIhvcNAgkFADAdBglghkgBZQME | SIb3DQEFDDAcBAg9pxXxY2yscwICCAAwDAYIKoZIhvcNAgkFADAdBglghkgBZQME | |||
ASoEEK7yYaFQDi1pYwWzm9F/fs+AggPgFIT2XapyaFgDppdvLkdvaF3HXw+zjzKb | ASoEEK7yYaFQDi1pYwWzm9F/fs+AggPgFIT2XapyaFgDppdvLkdvaF3HXw+zjzKb | |||
7xFC76DtVPhVTWVHD+kIss+jsj+XyvMwY0aCuAhAG/Dig+vzWomnsqB5ssw5/kTb | 7xFC76DtVPhVTWVHD+kIss+jsj+XyvMwY0aCuAhAG/Dig+vzWomnsqB5ssw5/kTb | |||
+TMQ5PXLkNeoBmB6ArKeGc/QmCBQvQG/a6b+nXSWmxNpP+71772dmWmB8gcSJ0kF | +TMQ5PXLkNeoBmB6ArKeGc/QmCBQvQG/a6b+nXSWmxNpP+71772dmWmB8gcSJ0kF | |||
Fj75NrIbmNiDMCb71Q8gOzBMFf6BpXf/3xWAJtxyic+tSNETfOJa8zTZb0+lV0w9 | Fj75NrIbmNiDMCb71Q8gOzBMFf6BpXf/3xWAJtxyic+tSNETfOJa8zTZb0+lV0w9 | |||
5eUmDrPUpuxEVbb0KJtIc63gRkcfrPtDd6Ii4Zzbzj2Evr4/S4hnrQBsiryVzJWy | 5eUmDrPUpuxEVbb0KJtIc63gRkcfrPtDd6Ii4Zzbzj2Evr4/S4hnrQBsiryVzJWy | |||
IEjaD0y6+DmG0JwMgRuGi1wBoGowi37GMrDCOyOZWC4n5wHLtYyhR6JaElxbrhxP | IEjaD0y6+DmG0JwMgRuGi1wBoGowi37GMrDCOyOZWC4n5wHLtYyhR6JaElxbrhxP | |||
H46z2USLKmZoF+YgEQgYcSBXMgP0t36+XQocFWYi2N5niy02TnctwF430FYsQlhJ | H46z2USLKmZoF+YgEQgYcSBXMgP0t36+XQocFWYi2N5niy02TnctwF430FYsQlhJ | |||
skipping to change at line 739 ¶ | skipping to change at line 874 ¶ | |||
qniZjKzSZepxlZq+J792u8vtMnuzzChxu0Bf3PhIXcJNcVhwUtr0yKe/N+NvC0tm | qniZjKzSZepxlZq+J792u8vtMnuzzChxu0Bf3PhIXcJNcVhwUtr0yKe/N+NvC0tm | |||
p8wyik/BlndxN9eKbdTOi2wIi64h2QG8nOk66wQ/PSIJYwZl6eDNEQSzH/1mGCfU | p8wyik/BlndxN9eKbdTOi2wIi64h2QG8nOk66wQ/PSIJYwZl6eDNEQSzH/1mGCfU | |||
QnUT17UC/p+Qgenf6Auap2GWlvsJrB7u/pytz65rtjt/ouo6Ih6EwWqwVVpGXZD0 | QnUT17UC/p+Qgenf6Auap2GWlvsJrB7u/pytz65rtjt/ouo6Ih6EwWqwVVpGXZD0 | |||
7gVWH0Ke/Vr6aPGNvkLcmftPuDZsn9jiig3guhdeyRVf10Ox369kKWcG75q77hxE | 7gVWH0Ke/Vr6aPGNvkLcmftPuDZsn9jiig3guhdeyRVf10Ox369kKWcG75q77hxE | |||
IzSzDyUlBNbnom9SIjut3r+qVYmWONatC6q/4D0I42Lnjd3dEyZx7jmH3g/S2ASM | IzSzDyUlBNbnom9SIjut3r+qVYmWONatC6q/4D0I42Lnjd3dEyZx7jmH3g/S2ASM | |||
FzWr9pvXc61dsYOkdZ4PYa9XPUZxXFagZsoS3F1sU799+IJVU0tC0MExJTAjBgkq | FzWr9pvXc61dsYOkdZ4PYa9XPUZxXFagZsoS3F1sU799+IJVU0tC0MExJTAjBgkq | |||
hkiG9w0BCRUxFgQUwWO5DorvVWYF3BWUmAw0rUEajScwejBqMEYGCSqGSIb3DQEF | hkiG9w0BCRUxFgQUwWO5DorvVWYF3BWUmAw0rUEajScwejBqMEYGCSqGSIb3DQEF | |||
DjA5MCkGCSqGSIb3DQEFDDAcBAhvRzw4sC4xcwICCAAwDAYIKoZIhvcNAgkFADAM | DjA5MCkGCSqGSIb3DQEFDDAcBAhvRzw4sC4xcwICCAAwDAYIKoZIhvcNAgkFADAM | |||
BggqhkiG9w0CCQUABCB6pW2FOdcCNj87zS64NUXG36K5aXDnFHctIk5Bf4kG3QQI | BggqhkiG9w0CCQUABCB6pW2FOdcCNj87zS64NUXG36K5aXDnFHctIk5Bf4kG3QQI | |||
b0c8OLAuMXMCAggA | b0c8OLAuMXMCAggA | |||
</artwork> | ]]></sourcecode> | |||
</t> | </section> | |||
</section> | ||||
</section> | </section> | |||
<section anchor="asn1-module" numbered="true" toc="default"> | ||||
<name>ASN.1 Module</name> | ||||
<t>This appendix documents ASN.1 <xref target="x680" | ||||
format="default"/> <xref target="x681" format="default"/> <xref | ||||
target="x682" format="default"/> <xref target="x683" | ||||
format="default"/> <xref target="x690" format="default"/> types, values, | ||||
and object sets for this specification. It does so by providing an | ||||
ASN.1 module called PKCS12-PBMAC1-2023.</t> | ||||
<section anchor="asn1-module" title="ASN.1 Module"> | <!--[rfced] We have a few question about the text below: | |||
<t>Note to RFC Editor: please change the TBD value below with the value | ||||
assigned by IANA</t> | a) We believe that "Appendix D" here should be updated to "Appendix C". Please | |||
<t>This appendix documents ASN.1 <xref target="x680"/> | confirm. | |||
<xref target="x681"/><xref target="x682"/><xref target="x683"/> | ||||
<xref target="x690"/> types, values, and object sets for | b) Is "PKCS-12" correct? We do not see "PKCS-12" in this document or in | |||
this specification. It does so by providing an ASN.1 module | RFC 8018. | |||
called PKCS12-PBMAC1-2023.</t> | ||||
<t>Combine this module with the PKCS-12 ASN.1 module found in Appendix | c) Will readers understand "by replacing the PBKDF2-PRFs class found therein"? | |||
D of <xref target="RFC8018"/> to add SHA-2 based HMACs by | ||||
replacing the PBKDF2-PRFs class found therein.</t> | Original: | |||
<artwork> | Combine this module with the PKCS-12 ASN.1 module found in Appendix D | |||
of [RFC8018] to add SHA-2 based HMACs by replacing the PBKDF2-PRFs | ||||
class found therein. | ||||
Perhaps: | ||||
This module can be combined with the ASN.1 module found in | ||||
Appendix C of [RFC8018] to add SHA-2-based HMACs by replacing the | ||||
PBKDF2-PRFs class in this module with those in [RFC8018]. | ||||
Or: | ||||
To add SHA-2-based HMACs, this module can be combined with the ASN.1 | ||||
module found in Appendix C of [RFC8018] by replacing the | ||||
PBKDF2-PRFs class in [RFC8018] with those in this module. | ||||
--> | ||||
<!-- [rfced] Please review these two sentences (one from Section 2 and the | ||||
other from Appendix B), and let us know if any updates needed. We | ||||
ask because Section 2 says "to incorporate additional MAC algorithms" | ||||
and Appendix B says "to add SHA-2 based HMACs". Also, would it be helpful | ||||
to add "See Appendix B" to the text in Section 2? | ||||
Section 2: | ||||
We have included an ASN.1 module [x680] [x681][x682][x683] [x690] | ||||
that can be combined with the ASN.1 module in [RFC8018] to | ||||
incorporate additional MAC algorithms. | ||||
Appendix B: | ||||
Combine this module with the PKCS-12 ASN.1 module found in Appendix D | ||||
of [RFC8018] to add SHA-2 based HMACs by replacing the PBKDF2-PRFs | ||||
class found therein. | ||||
--> | ||||
<t>Combine this module with the PKCS-12 ASN.1 module found in <xref | ||||
target="RFC8018" sectionFormat="of" section="D"/> to add SHA-2-based | ||||
HMACs by replacing the PBKDF2-PRFs class found therein.</t> | ||||
<sourcecode type="asn.1"><![CDATA[ | ||||
PKCS12-PBMAC1-2023 | PKCS12-PBMAC1-2023 | |||
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) | { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) | |||
smime(16) id-mod(0) pbkc12-pbamc1-2023(TBD) } | smime(16) id-mod(0) id-pkcs12-pbmac1-2023(76) } | |||
DEFINITIONS EXPLICIT TAGS ::= | DEFINITIONS EXPLICIT TAGS ::= | |||
BEGIN | BEGIN | |||
IMPORTS | IMPORTS | |||
AlgorithmIdentifier, ALGORITHM-IDENTIFIER, rsadsi | AlgorithmIdentifier, ALGORITHM-IDENTIFIER, rsadsi | |||
FROM PKCS5v2-1 -- From [RFC8018] | FROM PKCS5v2-1 -- From [RFC8018] | |||
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-5(5) | { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-5(5) | |||
modules(16) pkcs5v2-1(2) } | modules(16) pkcs5v2-1(2) } | |||
skipping to change at line 859 ¶ | skipping to change at line 1037 ¶ | |||
otherSource AlgorithmIdentifier {{PBKDF2-SaltSources}} | otherSource AlgorithmIdentifier {{PBKDF2-SaltSources}} | |||
}, | }, | |||
iterationCount INTEGER (1..MAX), | iterationCount INTEGER (1..MAX), | |||
keyLength INTEGER (1..MAX) OPTIONAL, | keyLength INTEGER (1..MAX) OPTIONAL, | |||
prf AlgorithmIdentifier {{PBKDF2-PRFs}} DEFAULT algid-hmacWithSHA1 | prf AlgorithmIdentifier {{PBKDF2-PRFs}} DEFAULT algid-hmacWithSHA1 | |||
} | } | |||
PBKDF2-SaltSources ALGORITHM-IDENTIFIER ::= { ... } | PBKDF2-SaltSources ALGORITHM-IDENTIFIER ::= { ... } | |||
END | END | |||
</artwork> | ]]></sourcecode> | |||
</section> | </section> | |||
</back> | </back> | |||
<!--[rfced] We have the following questions about the terminology used in this | ||||
document. | ||||
a) We see the following terms in the document: | ||||
Original: | ||||
SHA-1 HMAC | ||||
SHA-256 HMAC | ||||
SHA-512 HMAC | ||||
SHA-512 PRF | ||||
SHA-256 HMAC and PRF | ||||
SHA-256 HMAC and SHA-512 PRF | ||||
SHA-512 HMAC and PRF | ||||
We don't see this particular phrasing in published RFCs. Are these okay as is, | ||||
or are any updates needed? | ||||
Here are some examples of what we see in published RFCs. Note that the form | ||||
with hyphens (e.g., HMAC-SHA-256) appears in RFCS 6194, 7914, and 8018 (all | ||||
cited in this document). | ||||
HMAC-SHA-1 | ||||
HMAC-SHA-2 | ||||
HMAC-SHA-256 | ||||
HMAC with SHA-1 | ||||
HMAC with SHA-256 | ||||
HMAC with SHA-512 | ||||
HMAC SHA-1 | ||||
HMAC SHA-256 | ||||
HMAC SHA-512 | ||||
PRF with SHA-256 | ||||
b) We updated instances of "SHA-2 based HMAC" to "SHA-2-based HMAC" (hyphen | ||||
before "based"). Should these be further updated per the question above? | ||||
c) We note inconsistencies in the terms listed below. We chose the form on the | ||||
right. Please let us know any objections. | ||||
PKCS#12 vs. PKCS #12 | ||||
Note: "PKCS #12" is used in RFCs 7292 and 8018 (and other published RFCs). | ||||
scrypt KDF vs. scrypt PBKDF | ||||
Note: "scrypt PBKDF" is used in RFC 7914. | ||||
--> | ||||
<!--[rfced] FYI - We have added expansions for abbreviations upon first use | ||||
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each | ||||
expansion in the document carefully to ensure correctness. | ||||
Message Authentication Code (MAC) | ||||
Personal Information Exchange (PFX) | ||||
--> | ||||
<!--[rfced] We have updated <artwork> to <sourcecode type="test-vectors"> | ||||
and <sourcecode type="asn.1"> in Appendices A and B, respectively. Please | ||||
review and confirm that the "type" attribute of these sourcecode elements have | ||||
been set correctly. | ||||
The current list of preferred values for "type" is available at | ||||
https://www.rfc-editor.org/materials/sourcecode-types.txt. If the current | ||||
list does not contain an applicable type, feel free to suggest additions | ||||
for consideration. Note that it is also acceptable to leave the "type" | ||||
attribute not set. | ||||
--> | ||||
<!--[rfced] Please review the "Inclusive Language" portion of the online | ||||
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> | ||||
and let us know if any changes are needed. | ||||
Note that our script did not flag any words in particular, but this should | ||||
still be reviewed as a best practice. | ||||
--> | ||||
</rfc> | </rfc> | |||
End of changes. 87 change blocks. | ||||
322 lines changed or deleted | 605 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |