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 "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]> ]>
<?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 ***** -->
-&gt;
<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&nbsp;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.