rfc9045xml2.original.xml   rfc9045.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version='1.0' encoding='utf-8'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.4.2 -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.2119.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.8174.xml">
<!ENTITY RFC8018 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.8018.xml">
<!ENTITY RFC4211 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.4211.xml">
<!ENTITY I-D.ietf-lamps-cms-aes-gmac-alg SYSTEM "https://xml2rfc.tools.ietf.org/
public/rfc/bibxml3/reference.I-D.ietf-lamps-cms-aes-gmac-alg.xml">
<!ENTITY RFC4231 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.4231.xml">
<!ENTITY RFC6194 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.6194.xml">
]>
<?rfc toc="yes"?> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<rfc ipr="pre5378Trust200902" docName="draft-ietf-lamps-crmf-update-algs-07" cat egory="std" consensus="true" updates="4211"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="pre5378Trust200902" docName ="draft-ietf-lamps-crmf-update-algs-07" category="std" consensus="true" updates= "4211" obsoletes="" submissionType="IETF" xml:lang="en" tocInclude="true" sortRe fs="true" symRefs="true" version="3" number="9045">
<front> <front>
<title abbrev="CRMF Algorithm Requirements Update">Algorithm Requirements Up date to the Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)</title> <title abbrev="CRMF Algorithm Requirements Update">Algorithm Requirements Up date to the Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)</title>
<seriesInfo name="RFC" value="9045"/>
<author initials="R." surname="Housley" fullname="Russ Housley"> <author initials="R." surname="Housley" fullname="Russ Housley">
<organization abbrev="Vigil Security">Vigil Security, LLC</organization> <organization abbrev="Vigil Security">Vigil Security, LLC</organization>
<address> <address>
<postal> <postal>
<street>516 Dranesville Road</street> <street>516 Dranesville Road</street>
<city>Herndon, VA</city> <city>Herndon</city>
<region>VA</region>
<code>20170</code> <code>20170</code>
<country>US</country> <country>United States of America</country>
</postal> </postal>
<email>housley@vigilsec.com</email> <email>housley@vigilsec.com</email>
</address> </address>
</author> </author>
<date year="2021" month="June"/>
<date year="2021" month="April" day="08"/>
<area>Security</area> <area>Security</area>
<keyword>Internet-Draft</keyword> <keyword>Authentication</keyword>
<keyword>Message Authentication Code</keyword>
<keyword>Password-Based Message Authentication Code</keyword>
<abstract> <abstract>
<t>This document updates the cryptographic algorithm requirements for the
<t>This document updates the cryptographic algorithm requirements for the
Password-Based Message Authentication Code in the Internet X.509 Public Password-Based Message Authentication Code in the Internet X.509 Public
Key Infrastructure Certificate Request Message Format (CRMF) specified in Key Infrastructure Certificate Request Message Format (CRMF) specified in
RFC 4211.</t> RFC 4211.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="intro" numbered="true" toc="default">
<section anchor="intro"><name>Introduction</name> <name>Introduction</name>
<t>This document updates the cryptographic algorithm requirements for the <t>This document updates the cryptographic algorithm requirements for the
Password-Based Message Authentication Code (MAC) in the Internet X.509 Password-Based Message Authentication Code (MAC) in the Internet X.509
Public Key Infrastructure Certificate Request Message Format (CRMF) Public Key Infrastructure Certificate Request Message Format (CRMF)
<xref target="RFC4211"/>. The algorithms specified in <xref target="RFC4211"/> were appropriate in <xref target="RFC4211" format="default"/>. The algorithms specified in <xref ta rget="RFC4211" format="default"/> were appropriate in
2005; however, these algorithms are no longer considered the best 2005; however, these algorithms are no longer considered the best
choices:</t> choices:
<t><list style="symbols">
<t>HMAC-SHA1 <xref target="HMAC"/><xref target="SHS"/> is not broken yet, but
there are much stronger alternatives <xref target="RFC6194"/>.</t>
<t>DES-MAC <xref target="PKCS11"/> provides 56 bits of security, which is no l
onger considered secure <xref target="WITHDRAW"/>.</t>
<t>Triple-DES-MAC <xref target="PKCS11"/> provides 112 bits of security, which
is now deprecated <xref target="TRANSIT"/>.</t>
</list></t>
<t>This update specifies algorithms that are more appropriate today.</t>
<t>CRMF is defined using Abstract Syntax Notation One (ASN.1) <xref target="X680
"/>.</t>
</section>
<section anchor="terms"><name>Terminology</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", </t>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and <ul spacing="normal">
"OPTIONAL" in this document are to be interpreted as described in <li>HMAC-SHA1 <xref target="HMAC" format="default"/> <xref target="SHS"
BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, th format="default"/> is not broken yet, but there are much stronger alternatives <
ey appear in xref target="RFC6194" format="default"/>.</li>
all capitals, as shown here.</t> <li>DES-MAC <xref target="PKCS11" format="default"/> provides 56 bits of
security, which is no longer considered secure <xref target="WITHDRAW" format="
default"/>.</li>
<li>Triple-DES-MAC <xref target="PKCS11" format="default"/> provides 112
bits of security, which is now deprecated <xref target="TRANSIT" format="defaul
t"/>.</li>
</ul>
<t>This update specifies algorithms that are more appropriate today.</t>
<t>CRMF is defined using Abstract Syntax Notation One (ASN.1) <xref target
="X680" format="default"/>.</t>
</section>
<section anchor="terms" numbered="true" toc="default">
<name>Terminology</name>
</section> <t>
<section anchor="signature-key-pop"><name>Signature Key POP</name> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</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>
</section>
<section anchor="signature-key-pop" numbered="true" toc="default">
<name>Signature Key POP</name>
<t>Section 4.1 of <xref target="RFC4211"/> specifies the Proof-of-Possession (PO P) <t><xref target="RFC4211" sectionFormat="of" section="4.1"/> specifies the proof -of-possession (POP)
processing. This section is updated to explicitly allow the use processing. This section is updated to explicitly allow the use
of the PBMAC1 algorithm presented in Section 7.1 of <xref target="RFC8018"/>.</t of the PBMAC1 algorithm presented in <xref target="RFC8018" sectionFormat="of" s
> ection="7.1"/>.</t>
<t>OLD:</t>
<t>OLD:</t> <blockquote>
algId identifies the algorithm used to compute the MAC value. All
<t><list style='empty'> implementations <bcp14>MUST</bcp14> support id-PasswordBasedMAC. The details
on
<t>algId identifies the algorithm used to compute the MAC value. All this algorithm are presented in section <xref target="RFC4211" sectionFormat=
implementations MUST support id-PasswordBasedMAC. The details on "bare" section="4.4"/>.
this algorithm are presented in section 4.4</t> </blockquote>
</list></t> <t>NEW:</t>
<blockquote>
<t>NEW:</t> algId identifies the algorithm used to compute the MAC value. All
implementations <bcp14>MUST</bcp14> support id-PasswordBasedMAC as presented
<t><list style='empty'> in
<xref target="RFC4211" sectionFormat="of" section="4.4"/>. Implementations <
<t>algId identifies the algorithm used to compute the MAC value. All bcp14>MAY</bcp14> also support
implementations MUST support id-PasswordBasedMAC as presented in PBMAC1 as presented in <xref target="RFC8018" sectionFormat="of" section="7.1
Section 4.4 of <xref target="RFC4211"></xref>. Implementations MAY also supp "/>.
ort </blockquote>
PBMAC1 as presented in Section 7.1 of <xref target="RFC8018"></xref>.</t> </section>
</list></t> <section anchor="password-based-message-authentication-code" numbered="true"
toc="default">
</section> <name>Password-Based Message Authentication Code</name>
<section anchor="password-based-message-authentication-code"><name>Password-Base
d Message Authentication Code</name>
<t>Section 4.4 of <xref target="RFC4211"/> specifies a Password-Based MAC that r elies on <t><xref target="RFC4211" sectionFormat="of" section="4.4"/> specifies a Passwor d-Based MAC that relies on
a one-way function to compute a symmetric key from the password and a MAC a one-way function to compute a symmetric key from the password and a MAC
algorithm. This section specifies algorithm requirements for the one-way algorithm. This section specifies algorithm requirements for the one-way
function and the MAC algorithm.</t> function and the MAC algorithm.</t>
<section anchor="introduction-paragraph" numbered="true" toc="default">
<name>Introduction Paragraph</name>
<section anchor="introduction-paragraph"><name>Introduction Paragraph</name> <t>Add guidance about limiting the use of the password as follows:</t>
<t>OLD:</t>
<t>Add guidance about limiting the use of the password.</t> <blockquote>
This MAC algorithm was designed to take a shared secret (a password)
<t>OLD:</t>
<t><list style='empty'>
<t>This MAC algorithm was designed to take a shared secret (a password)
and use it to compute a check value over a piece of information. The and use it to compute a check value over a piece of information. The
assumption is that, without the password, the correct check value assumption is that, without the password, the correct check value
cannot be computed. The algorithm computes the one-way function cannot be computed. The algorithm computes the one-way function
multiple times in order to slow down any dictionary attacks against multiple times in order to slow down any dictionary attacks against
the password value.</t> the password value.
</list></t> </blockquote>
<t>NEW:</t>
<t>NEW:</t> <blockquote>
This MAC algorithm was designed to take a shared secret (a password)
<t><list style='empty'>
<t>This MAC algorithm was designed to take a shared secret (a password)
and use it to compute a check value over a piece of information. The and use it to compute a check value over a piece of information. The
assumption is that, without the password, the correct check value assumption is that, without the password, the correct check value
cannot be computed. The algorithm computes the one-way function cannot be computed. The algorithm computes the one-way function
multiple times in order to slow down any dictionary attacks against multiple times in order to slow down any dictionary attacks against
the password value. The password used to compute this MAC SHOULD NOT the password value. The password used to compute this MAC <bcp14>SHOULD NOT<
be used for any other purpose.</t> /bcp14>
</list></t> be used for any other purpose.
</blockquote>
</section> </section>
<section anchor="one-way-function"><name>One-Way Function</name> <section anchor="one-way-function" numbered="true" toc="default">
<name>One-Way Function</name>
<t>Change the paragraph describing the "owf" as follows:</t> <t>Change the paragraph describing the "owf" as follows:</t>
<t>OLD:</t>
<blockquote>
owf identifies the algorithm and associated parameters used to
compute the key used in the MAC process. All implementations <bcp14>MUST</bc
p14>
support SHA-1.
</blockquote>
<t>NEW:</t>
<blockquote>
owf identifies the algorithm and associated parameters used to
compute the key used in the MAC process. All implementations <bcp14>MUST</bc
p14>
support SHA-256 <xref target="SHS" format="default"/>.
</blockquote>
</section>
<section anchor="iteration-count" numbered="true" toc="default">
<name>Iteration Count</name>
<t>OLD:</t> <t>Update the guidance on appropriate iteration count values as follows:</t>
<t>OLD:</t>
<t><list style='empty'> <blockquote>
iterationCount identifies the number of times the hash is applied
<t>owf identifies the algorithm and associated parameters used to during the key computation process. The iterationCount <bcp14>MUST</bcp14> b
compute the key used in the MAC process. All implementations MUST e a
support SHA-1.</t>
</list></t>
<t>NEW:</t>
<t><list style='empty'>
<t>owf identifies the algorithm and associated parameters used to
compute the key used in the MAC process. All implementations MUST
support SHA-256 <xref target="SHS"></xref>.</t>
</list></t>
</section>
<section anchor="iteration-count"><name>Iteration Count</name>
<t>Update the guidance on appropriate iteration count values.</t>
<t>OLD:</t>
<t><list style='empty'>
<t>iterationCount identifies the number of times the hash is applied
during the key computation process. The iterationCount MUST be a
minimum of 100. Many people suggest using values as high as 1000 minimum of 100. Many people suggest using values as high as 1000
iterations as the minimum value. The trade off here is between iterations as the minimum value. The trade off here is between
protection of the password from attacks and the time spent by the protection of the password from attacks and the time spent by the
server processing all of the different iterations in deriving server processing all of the different iterations in deriving
passwords. Hashing is generally considered a cheap operation but passwords. Hashing is generally considered a cheap operation but
this may not be true with all hash functions in the future.</t> this may not be true with all hash functions in the future.
</list></t> </blockquote>
<t>NEW:</t>
<t>NEW:</t> <blockquote>
iterationCount identifies the number of times the hash is applied
<t><list style='empty'> during the key computation process. The iterationCount <bcp14>MUST</bcp14> b
e a
<t>iterationCount identifies the number of times the hash is applied minimum of 100; however, the iterationCount <bcp14>SHOULD</bcp14> be as large
during the key computation process. The iterationCount MUST be a as
minimum of 100; however, the iterationCount SHOULD be as large as
server performance will allow, typically at least 10,000 server performance will allow, typically at least 10,000
<xref target="DIGALM"/>. There is a trade off between protection of the <xref target="DIGALM" format="default"/>. There is a trade-off between prote ction of the
password from attacks and the time spent by the server processing password from attacks and the time spent by the server processing
the iterations. As part of that tradeoff, an iteration count the iterations. As part of that trade-off, an iteration count
smaller than 10,000 can be used when automated generation produces smaller than 10,000 can be used when automated generation produces
shared secrets with high entropy.</t> shared secrets with high entropy.
</list></t> </blockquote>
</section>
</section> <section anchor="mac-algorithm" numbered="true" toc="default">
<section anchor="mac-algorithm"><name>MAC Algorithm</name> <name>MAC Algorithm</name>
<t>Change the paragraph describing the "mac" as follows:</t> <t>Change the paragraph describing the "mac" as follows:</t>
<t>OLD:</t>
<t>OLD:</t> <blockquote>
mac identifies the algorithm and associated parameters of the MAC
<t><list style='empty'> function to be used. All implementations <bcp14>MUST</bcp14> support HMAC-SH
A1
<t>mac identifies the algorithm and associated parameters of the MAC <xref target="HMAC"/>. All implementations <bcp14>SHOULD</bcp14> support DES
function to be used. All implementations MUST support HMAC-SHA1 -MAC and Triple-DES-MAC <xref target="PKCS11"/>.
[HMAC]. All implementations SHOULD support DES-MAC and Triple- </blockquote>
DES-MAC [PKCS11].</t> <t>NEW:</t>
</list></t> <blockquote>
mac identifies the algorithm and associated parameters of the MAC
<t>NEW:</t> function to be used. All implementations <bcp14>MUST</bcp14> support HMAC-SH
A256
<t><list style='empty'> <xref target="HMAC"/>. All implementations <bcp14>SHOULD</bcp14> support AES
-GMAC <xref target="AES"/> <xref target="GMAC"/>
<t>mac identifies the algorithm and associated parameters of the MAC with a 128-bit key.
function to be used. All implementations MUST support HMAC-SHA256 </blockquote>
[HMAC]. All implementations SHOULD support AES-GMAC [AES][GMAC] <t>For convenience, the identifiers for these two algorithms are
with a 128-bit key.</t>
</list></t>
<t>For convenience, the identifiers for these two algorithms are
repeated here.</t> repeated here.</t>
<t>The ASN.1 algorithm identifier for HMAC-SHA256 is defined in <xref ta
<t>The ASN.1 algorithm identifier for HMAC-SHA256 is defined in <xref target="RF rget="RFC4231" format="default"/>:</t>
C4231"/>:</t> <sourcecode name="" type="asn.1"><![CDATA[
<figure><artwork><![CDATA[
id-hmacWithSHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-hmacWithSHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) digestAlgorithm(2) 9 } us(840) rsadsi(113549) digestAlgorithm(2) 9 }
]]></artwork></figure> ]]></sourcecode>
<t>When this object identifier is used in the ASN.1 algorithm identifier
<t>When this object identifier is used in the ASN.1 algorithm identifier, the , the
parameters SHOULD be present. When present, the parameters MUST contain a parameters <bcp14>SHOULD</bcp14> be present. When present, the parameters <bcp1
type of NULL as specified in <xref target="RFC4231"/>.</t> 4>MUST</bcp14> contain a
type of NULL as specified in <xref target="RFC4231" format="default"/>.</t>
<t>The ASN.1 algorithm identifier for AES-GMAC <xref target="AES"/><xref target= <t>The ASN.1 algorithm identifier for AES-GMAC <xref target="AES" format
"GMAC"/> with a 128-bit ="default"/> <xref target="GMAC" format="default"/> with a 128-bit
key is defined in <xref target="I-D.ietf-lamps-cms-aes-gmac-alg"/>:</t> key is defined in <xref target="RFC9044" format="default"/>:</t>
<figure><artwork><![CDATA[ <sourcecode name="" type="asn.1"><![CDATA[
id-aes128-GMAC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) id-aes128-GMAC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3) country(16) us(840) organization(1) gov(101) csor(3)
nistAlgorithm(4) aes(1) 9 } nistAlgorithm(4) aes(1) 9 }
]]></artwork></figure> ]]></sourcecode>
<t>When this object identifier is used in the ASN.1 algorithm identifier
<t>When this object identifier is used in the ASN.1 algorithm identifier, the , the
parameters MUST be present, and the parameters MUST contain the parameters <bcp14>MUST</bcp14> be present, and the parameters <bcp14>MUST</bcp14
> contain the
GMACParameters structure as follows:</t> GMACParameters structure as follows:</t>
<sourcecode name="" type="asn.1"><![CDATA[
<figure><artwork><![CDATA[
GMACParameters ::= SEQUENCE { GMACParameters ::= SEQUENCE {
nonce OCTET STRING, nonce OCTET STRING,
length MACLength DEFAULT 12 } length MACLength DEFAULT 12 }
MACLength ::= INTEGER (12 | 13 | 14 | 15 | 16) MACLength ::= INTEGER (12 | 13 | 14 | 15 | 16)
]]></artwork></figure> ]]></sourcecode>
<t>The GMACParameters nonce parameter is the GMAC initialization vector.
<t>The GMACParameters nonce parameter is the GMAC initialization vector. The The
nonce may have any number of bits between 8 and (2^64)-1, but it MUST be a nonce may have any number of bits between 8 and (2^64)-1, but it <bcp14>MUST</bc
p14> be a
multiple of 8 bits. Within the scope of any GMAC key, the nonce value multiple of 8 bits. Within the scope of any GMAC key, the nonce value
MUST be unique. A nonce value of 12 octets can be processed more <bcp14>MUST</bcp14> be unique. A nonce value of 12 octets can be processed more
efficiently, so that length for the nonce value is RECOMMENDED.</t> efficiently, so that length for the nonce value is <bcp14>RECOMMENDED</bcp14>.</
t>
<t>The GMACParameters length parameter field tells the size of the <t>The GMACParameters length parameter field tells the size of the
message authentication code in octets. GMAC supports lengths between message authentication code in octets. GMAC supports lengths between
12 and 16 octets, inclusive. However, for use with CRMF, the maximum 12 and 16 octets, inclusive. However, for use with CRMF, the maximum
length of 16 octets MUST be used.</t> length of 16 octets <bcp14>MUST</bcp14> be used.</t>
</section>
</section> </section>
</section> <section anchor="iana-considerations" numbered="true" toc="default">
<section anchor="iana-considerations"><name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This document makes no requests of the IANA.</t>
</section> <t>This document has no IANA actions.</t>
<section anchor="security-considerations"><name>Security Considerations</name> </section>
<section anchor="security-considerations" numbered="true" toc="default">
<name>Security Considerations</name>
<t>The security of the password-based MAC relies on the number of times the <t>The security of the Password-Based MAC relies on the number of times the
hash function is applied as well as the entropy of the shared secret (the hash function is applied as well as the entropy of the shared secret (the
password). Hardware support for hash calculation is available at very low password). Hardware support for hash calculation is available at very low
cost <xref target="PHS"/>, which reduces the protection provided by a high itera tionCount cost <xref target="PHS" format="default"/>, which reduces the protection provide d by a high iterationCount
value. Therefore, the entropy of the password is crucial for the security of value. Therefore, the entropy of the password is crucial for the security of
the password-based MAC function. In 2010, researchers showed that about half the Password-Based MAC function. In 2010, researchers showed that about half
of the real-world passwords in a leaked corpus can be broken with less than of the real-world passwords in a leaked corpus can be broken with less than
150 million trials, indicating a median entropy of only 27 bits <xref target="DM R"/>. Higher 150 million trials, indicating a median entropy of only 27 bits <xref target="DM R" format="default"/>. Higher
entropy can be achieved by using randomly generated strings. For example, entropy can be achieved by using randomly generated strings. For example,
assuming an alphabet of 60 characters a randomly chosen password with 10 charact ers assuming an alphabet of 60 characters, a randomly chosen password with 10 charac ters
offers 59 bits of entropy, and 20 characters offers 118 bits of entropy. Using offers 59 bits of entropy, and 20 characters offers 118 bits of entropy. Using
a one-time password also increases the security of the MAC, assuming that the a one-time password also increases the security of the MAC, assuming that the
integrity-protected transaction will complete before the attacker is able to integrity-protected transaction will complete before the attacker is able to
learn the password with an offline attack.</t> learn the password with an offline attack.</t>
<t>Please see <xref target="RFC8018" format="default"/> for security consi
<t>Please see <xref target="RFC8018"/> for security considerations related to PB derations related to PBMAC1.</t>
MAC1.</t> <t>Please see <xref target="HMAC" format="default"/> and <xref target="SHS
" format="default"/> for security considerations related to HMAC-SHA256.</t>
<t>Please see <xref target="HMAC"/> and <xref target="SHS"/> for security consid <t>Please see <xref target="AES" format="default"/> and <xref target="GMAC
erations related to HMAC-SHA256.</t> " format="default"/> for security considerations related to AES-GMAC.</t>
<t>Cryptographic algorithms age; they become weaker with time. As new
<t>Please see <xref target="AES"/> and <xref target="GMAC"/> for security consid
erations related to AES-GMAC.</t>
<t>Cryptographic algorithms age; they become weaker with time. As new
cryptanalysis techniques are developed and computing capabilities cryptanalysis techniques are developed and computing capabilities
improve, the work required to break a particular cryptographic improve, the work required to break a particular cryptographic
algorithm will reduce, making an attack on the algorithm more algorithm will reduce, making an attack on the algorithm more
feasible for more attackers. While it is unknown how cryptoanalytic feasible for more attackers. While it is unknown how cryptanalytic
attacks will evolve, it is certain that they will get better. It is attacks will evolve, it is certain that they will get better. It is
unknown how much better they will become or when the advances will unknown how much better they will become or when the advances will
happen. For this reason, the algorithm requirements for CRMF are happen. For this reason, the algorithm requirements for CRMF are
updated by this specification.</t> updated by this specification.</t>
<t>When a Password-Based MAC is used, implementations must protect the
<t>When a Password-Based MAC is used, implementations must protect the
password and the MAC key. Compromise of either the password or the MAC password and the MAC key. Compromise of either the password or the MAC
key may result in the ability of an attacker to undermine authentication.</t> key may result in the ability of an attacker to undermine authentication.</t>
</section>
</middle>
<back>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8018.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4211.xml"/>
</section> <reference anchor="RFC9044" target="https://www.rfc-editor.org/info/rfc90
<section anchor="acknowledgements"><name>Acknowledgements</name> 44">
<front>
<title>Using the AES-GMAC Algorithm with the Cryptographic Message Syntax (CMS)<
/title>
<author initials='R.' surname='Housley' fullname='Russ Housley'>
<organization/>
</author>
<date month='May' year='2021'/>
</front>
<seriesInfo name="RFC" value="9044"/>
<seriesInfo name="DOI" value="10.17487/RFC9044"/>
</reference>
<t>Many thanks to <reference anchor="AES">
Hans Aschauer, <front>
Hendrik Brockhaus, <title>Advanced Encryption Standard (AES)</title>
Quynh Dang, <author>
Roman Danyliw, <organization>National Institute of Standards and Technology</orga
Lars Eggert, nization>
Tomas Gustavsson, </author>
Jonathan Hammell, <date year="2001" month="November"/>
Tim Hollebeek, </front>
Ben Kaduk, <seriesInfo name="FIPS PUB" value="197"/>
Erik Kline, <seriesInfo name="DOI" value="10.6028/NIST.FIPS.197"/>
Lijun Liao, </reference>
Mike Ounsworth,
Francesca Palombini,
Tim Polk,
Ines Robles,
Mike StJohns, and
Sean Turner
for their careful review and improvements.</t>
</section> <reference anchor="GMAC">
<front>
<title>Recommendation for Block Cipher Modes of Operation: Galois/Co
unter Mode (GCM) and GMAC</title>
<author surname="Dworkin" initials="M."/>
<date year="2007" month="November"/>
</front>
<seriesInfo name="NIST Special Publication" value="800-38D"/>
<seriesInfo name="DOI" value="10.6028/NIST.SP.800-38D"/>
</reference>
</middle> <reference anchor='HMAC' target='https://www.rfc-editor.org/info/rfc2104'>
<front>
<title>HMAC: Keyed-Hashing for Message Authentication</title>
<author initials='H.' surname='Krawczyk' fullname='H. Krawczyk'><organization />
</author>
<author initials='M.' surname='Bellare' fullname='M. Bellare'><organization /></
author>
<author initials='R.' surname='Canetti' fullname='R. Canetti'><organization /></
author>
<date year='1997' month='February' />
</front>
<seriesInfo name='RFC' value='2104'/>
<seriesInfo name='DOI' value='10.17487/RFC2104'/>
</reference>
<back> <reference anchor="SHS">
<front>
<title>Secure Hash Standard (SHS)</title>
<author>
<organization>National Institute of Standards and Technology</orga
nization>
</author>
<date year="2015" month="August"/>
</front>
<seriesInfo name="FIPS PUB" value="180-4"/>
<seriesInfo name="DOI" value="10.6028/NIST.FIPS.180-4"/>
</reference>
<references title='Normative References'> <reference anchor="X680">
<front>
<title>Information technology -- Abstract Syntax Notation One (ASN.1
): Specification of basic notation</title>
<author>
<organization>ITU-T</organization>
</author>
<date year="2015" month="August"/>
</front>
<seriesInfo name="ITU-T Recommendation" value="X.680"/>
</reference>
</references>
&RFC2119; <references>
&RFC8174; <name>Informative References</name>
&RFC8018; <reference anchor="DMR">
&RFC4211; <front>
&I-D.ietf-lamps-cms-aes-gmac-alg; <title>Password Strength: An Empirical Analysis</title>
<reference anchor="AES" > <author initials="M." surname="Dell'Amico">
<front> <organization/>
<title>Advanced encryption standard (AES)</title> </author>
<author > <author initials="P." surname="Michiardi">
<organization>National Institute of Standards and Technology</organization <organization/>
> </author>
</author> <author initials="Y." surname="Roudier">
<date year="2001" month="November"/> <organization/>
</front> </author>
<seriesInfo name="DOI" value="10.6028/nist.fips.197"/> <date year="2010" month="March"/>
</reference> </front>
<reference anchor="GMAC" > <seriesInfo name="DOI" value="10.1109/INFCOM.2010.5461951"/>
<front> </reference>
<title>Recommendation for block cipher modes of operation: Galois Counter Mo
de (GCM) and GMAC</title>
<author >
<organization>National Institute of Standards and Technology</organization
>
</author>
<date year="2007"/>
</front>
<seriesInfo name="DOI" value="10.6028/nist.sp.800-38d"/>
</reference>
<reference anchor="HMAC" >
<front>
<title>HMAC: Keyed-Hashing for Message Authentication</title>
<author initials="H." surname="Krawczyk">
<organization></organization>
</author>
<author initials="M." surname="Bellare">
<organization></organization>
</author>
<author initials="R." surname="Canetti">
<organization></organization>
</author>
<date year="1997" month="February"/>
</front>
<seriesInfo name="RFC" value="2104"/>
<seriesInfo name="DOI" value="10.17487/RFC2104"/>
</reference>
<reference anchor="SHS" >
<front>
<title>Secure Hash Standard</title>
<author >
<organization>National Institute of Standards and Technology</organization
>
</author>
<date year="2015" month="July"/>
</front>
<seriesInfo name="DOI" value="10.6028/nist.fips.180-4"/>
</reference>
<reference anchor="X680" >
<front>
<title>Information technology -- Abstract Syntax Notation One (ASN.1): Speci
fication of basic notation</title>
<author >
<organization>ITU-T</organization>
</author>
<date year="2015"/>
</front>
<seriesInfo name="Recommendation" value="X.680"/>
</reference>
</references> <reference anchor="DIGALM">
<front>
<title>Digital Identity Guidelines: Authentication and Lifecycle Man
agement</title>
<author>
<organization>National Institute of Standards and Technology</orga
nization>
</author>
<date year="2017" month="June"/>
</front>
<seriesInfo name="NIST Special Publication" value="800-63B"/>
<seriesInfo name="DOI" value="10.6028/NIST.SP.800-63B"/>
<references title='Informative References'> </reference>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4231.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6194.xml"/>
<reference anchor="PHS">
<front>
<title>Energy Efficient Bitcoin Mining to Maximize the Mining Profit
: Using Data from 119 Bitcoin Mining Hardware Setups</title>
<author initials="A." surname="Pathirana" fullname="Amila Pathirana"
>
<organization/>
</author>
<author initials="M." surname="Halgamuge" fullname="Malka Halgamuge"
>
<organization/>
</author>
<author initials="A." surname="Syed" fullname="Ali Syed">
<organization/>
</author>
<date year="2019" month="November"/>
</front>
<refcontent>International Conference on Advances in Business Managemen
t and Information Technology, pp. 1-14</refcontent>
</reference>
<reference anchor="DMR" > <reference anchor="PKCS11">
<front> <front>
<title>Password Strength: An Empirical Analysis</title> <title>PKCS #11 v2.11: Cryptographic Token Interface Standard</title
<author initials="M." surname="Dell'Amico"> >
<organization></organization> <author>
</author> <organization>RSA Laboratories</organization>
<author initials="P." surname="Michiardi"> </author>
<organization></organization> <date year="2001" month="November"/>
</author> </front>
<author initials="Y." surname="Roudier"> </reference>
<organization></organization>
</author> <reference anchor="TRANSIT">
<date year="2010" month="March"/> <front>
</front> <title>Transitioning the Use of Cryptographic Algorithms and Key Len
<seriesInfo name="DOI" value="10.1109/INFCOM.2010.5461951"/> gths</title>
</reference> <author>
<reference anchor="DIGALM" > <organization>National Institute of Standards and Technology</orga
<front> nization>
<title>Digital identity guidelines: authentication and lifecycle management< </author>
/title> <date year="2019" month="March"/>
<author > </front>
<organization>National Institute of Standards and Technology</organization <seriesInfo name="NIST Special Publication" value="800-131Ar2"/>
> <seriesInfo name="DOI" value="10.6028/NIST.SP.800-131Ar2"/>
</author> </reference>
<date year="2017" month="June"/>
</front>
<seriesInfo name="DOI" value="10.6028/nist.sp.800-63b"/>
</reference>
&RFC4231;
&RFC6194;
<reference anchor="PHS" >
<front>
<title>Energy efficient bitcoin mining to maximize the mining profit: Using
data from 119 bitcoin mining hardware setups</title>
<author initials="A." surname="Pathirana" fullname="Amila Pathirana">
<organization></organization>
</author>
<author initials="M." surname="Halgamuge" fullname="Malka Halgamuge">
<organization></organization>
</author>
<author initials="A." surname="Syed" fullname="Ali Syed">
<organization></organization>
</author>
<date year="2019" month="November"/>
</front>
<seriesInfo name="International Conference on Advances in Business Management
and Information Technology," value="pp 1-14"/>
</reference>
<reference anchor="PKCS11" >
<front>
<title>The Public-Key Cryptography Standards - PKCS #11 v2.11: Cryptographi
c Token Interface Standard</title>
<author >
<organization>RSA Laboratories</organization>
</author>
<date year="2001" month="June"/>
</front>
</reference>
<reference anchor="TRANSIT" >
<front>
<title>Transitioning the use of cryptographic algorithms and key lengths</ti
tle>
<author >
<organization>National Institute of Standards and Technology</organization
>
</author>
<date year="2019" month="March"/>
</front>
<seriesInfo name="NIST SP" value="800-131Ar2"/>
</reference>
<reference anchor="WITHDRAW" >
<front>
<title>NIST Withdraws Outdated Data Encryption Standard</title>
<author >
<organization>National Institute of Standards and Technology</organization
>
</author>
<date year="2005" month="June" day="02"/>
</front>
</reference>
<reference anchor="WITHDRAW" target="https://www.nist.gov/news-events/ne
ws/2005/06/nist-withdraws-outdated-data-encryption-standard">
<front>
<title>NIST Withdraws Outdated Data Encryption Standard</title>
<author>
<organization>National Institute of Standards and Technology</orga
nization>
</author>
<date year="2005" month="June"/>
</front>
</reference>
</references>
</references> </references>
<section anchor="acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>Many thanks to
<contact fullname="Hans Aschauer"/>,
<contact fullname="Hendrik Brockhaus"/>,
<contact fullname="Quynh Dang"/>,
<contact fullname="Roman Danyliw"/>,
<contact fullname="Lars Eggert"/>,
<contact fullname="Tomas Gustavsson"/>,
<contact fullname="Jonathan Hammell"/>,
<contact fullname="Tim Hollebeek"/>,
<contact fullname="Ben Kaduk"/>,
<contact fullname="Erik Kline"/>,
<contact fullname="Lijun Liao"/>,
<contact fullname="Mike Ounsworth"/>,
<contact fullname="Francesca Palombini"/>,
<contact fullname="Tim Polk"/>,
<contact fullname="Ines Robles"/>,
<contact fullname="Mike StJohns"/>, and
<contact fullname="Sean Turner"/>
for their careful review and improvements.</t>
</section>
</back> </back>
<!-- ##markdown-source:
H4sIABwUb2AAA+1abXPbRpL+jl8xJVfdSVsEQ8iSLCl1V0dLtMVYbxHp9aZs
39UQGJIT4W0xABVG6/z2fbpnAII05XXuzrf5cKldiyRmevq9n+6B7/teqctY
nYp+PMsKXc4Tcaf+WulCJSotjXibR7JUosxEOVdimJaqSFUp/tI97J2I22oS
61C8UUs8mRbSlEUVllWhxJkqSj3VIe0lesqU4koZI2dKvMqKRJZi9+zu6tWe
JyeTQi1OBX37MhNelIWpTMBrVMhp6WtVTv1YJrnxwyKZ+hWv8mU8M37vhUdf
TsV+bz/wewd+79gjZkB+eSpMGXl2tTkVB/tB4IVZalRqKnyHDMrTeXEq8kId
Pn9xPC4qU+73eie9fU8WSp6KkQorsLn07tXyISui00Yx/jmx5nmmlGn0XzLO
UvCQZl6uT8X7Mgs7wmRFWaipwadlQh8+ep6synlWnHrC9wT+0ynYuOuKi6wy
sVryb1bwu8qYtZ+zYnYq/qxnOm6Y6ojLyzN+WKt2/Tk/gqWUKk/FYXAkwHKq
zELHMWyVyYgXhFh5Ki4gVJSlHfHnvv01i1inwYue+16lJWn07Yi/q0Tq+FTM
LYf/saCDjQq7YZZ4Xsp21wsFQcXdqzPo/cR9PA5eHNQfe8Gx+0iWoY9D/7zb
NnZifKmMP0tkSNamJf3B6NTKXKtSNOq5xqFZKmMYycDZK7hkNhUjspAsIiPw
V4xVOE+zOJtZ9biY2OlHC5mGKhIqDYtlTnSEcRvFLg7d2+H1ta/1Ah/OxApW
hVZGp9Os5mXnejga74Doq+HtSAQnL3aeWHh+MzwVQa971Ns//i7VpuxOdW66
2IEFr6/6Z99A0n93ZO4UTIWgi5iSmGaFmMRZeA9/yOeqEAkcwBDRLFcFr6kZ
eA1n10ackUdg4RUWit3XZ1d7fCqx3dLUDlT1pPyNoka34rjX858fR1+vKpN3
3R4suWiUtSEmP6C8pSL/Qpq5Tmcsa52i+tAtMg/lL4i4Rd2+++uC9aIr3hTy
Ifx1eb99wVVXvFRxjPSx/Tmi/QxRWJbaa6kpODl54SPrbBceEQKfC3oHbWXs
QBsIpuMX33GE9Q5IdaOLbxIdnFGUIAU2G9bjITikTPxV8XDc8w9+b0TQHiz5
y9Fx70n5huO3/nibD6Bi2YQEPy8bAYXvi/4E6VGGpRgt01L+Iq6z0i67SeHT
/dF1N9irzxjlKrSFjhZAcxNpUBJTt2VDG09Zci3qTlFdIZGnawZtxjy/utsm
5IYj7cDTzuFp/9pPdJjtPLHotiuudDjXMJh+as1PXVSDKtKq2NmmvltpDNU+
WL5Q6ayc1wz1UzFIcl1AJzG+yHhptFnXQ8/vPX/KK4aDwUAMr1/dnN1c7XCm
CHritshCpSKEqflHPhIEvZPvsB/bu7S3e3hwFJwcUlY+H77uX159w+x5jnpX
goCOKHmUSzGr8DHWKK/1SXItszDNWE9VuAxRfROZIvsQ5lnXF5LA0Vcmy6Pn
k9+dLLGnLrjPA1d7oTOuyLfbU8fKWSwwgbfFEj5RzjXQhFx3pX73syeb+69k
fC+RSeKZTKqZWt8Pl9588tn5sUa0quizg5sfN0w1SFWBaFdTxK6GwsVEl2Gm
U5HolKoBAG8if9GJ/lUx8nU/50U21WWthbeGfoOZpJgWWSIAaDbpzOE6D0j7
sEdZ5RtxcPIFtGARZe2SZ1k6VYizED6ZCgdLDKQULytD/mWgwtp52Kva6W3l
tR1ylTwXwCmcbW/fnI0syNoaEnejvriUkwylPiMOt2lyDO3YRsCnRuCMcFI2
K2Q+X7aCpzYYHSieBYFY7CNUT0V7PfLmOLtXqUXTUwlhawKbKIvjYXzXvx4N
x98goMdwVaNpN/sCJKwMbw7XuJV1u2JpoRsQMefCz+z8dL6j+BWjW7ILxWLw
POgX+2Sad8Pxxfld/903EI/PfAfG0Ug9GHFTlcRqJM7JkwcrqLtd+6jpR4RK
PB+1Urpa6XnjOeAfWrSKXdC1V6y7J5QminaPR/ALi726rvgvpQFL2xEZ4gHw
Et7/ZFPq/U+aUmFsVcf5OvWQDblJ7FqJEx1FsfK8Zzi3yCLQJoYen2n6+umf
oYddoNm97drw/jda9MdH14x9+tS18d5y/LaqRGuleEC+EjJHxswLTYdAleQ9
36M9fFALVXSIX7NGjBJlmgm0zTP0ENSUo34WoE2STcChF84zHVI59f5kYbw/
uugHOJg+f/r0+Aisi8NhAkAwMSk4nyxV2RGTqiQyxBT+n1ThnLpge5KMXbJd
wFQsBNU/iMvHnA9GPqjjgU2XoA+pFppaocMjyvjcEpmmAX+AfeeWhy2yGAub
Hx/rCK/PGRc6j5X/peOCYP/L5z2ISOWFCjmeHx9diuQT2DGtPzZWM23tl3PY
nJWTbZiuzCK5BAke0pB7qymKTiQqLoBfg5fBC8F0ZuTZWBUojxZvPz6D6hPD
gaM4hZLXGwDZtwA2HftXXN/w57vBj2+Hd4Nz+gy7X142H+wKD19u3l665/Rp
tROA8GpwfW4341ex8dNV/yf8QcLzdm5ux8Ob6/7ljg2qdjyTeoANJuTOYByq
JkVLUokJCz2xKePl2e2/pBOTfx8cWHeiWQfsyJ9p2EHxgTjm81DR46X7Cgdd
kuaVLIiOjGMRypxApenQKQaxkwryYtLjSM/gtORMFN+3N7eeh56MVX/QDchH
2gG5sjlFEyB1NvXxv9vMGIQ9bdoFiT0vJ7BtyLIc7ZDeOKKN/0SkA/VLjtSC
igKO4xie5+qkh3P5hJfw4qCV56AsAx3aVFEz+qLFKM1+2ENuLs8R4YwwsH0Y
OUTdML+iWRnLDBqonCogPaXgWci4UuC/H8dERSeILDIgOybAEjmVqfI8K0oQ
9+tsy8kW+12ei1QpdYxo40aOPWF1NLnCmkim0f2B510P3v1zRSB3abNHNFbe
cUBKf++c4yNOGW6S7/8EHk1WH0Hba4uaL5ryvbPkR3LRry9jbd89eNp3pdgk
CVE5cxXotBTbSuIf5T/IpZhWqaXZ0q+kyWuiSnSonG8YupPS87qlpaCURNhr
rLQZClsS6NY6XnPiNZwQ8drEK/JQ1TqguJWFZKjgef0o4k6SMD8AV4ZCFqMz
KTewaVuE9RhiztfOEw82ZSGBWOcr5T1rBv2KLVFIbGJXNgT32JHTiA/T5bo+
w7kK762/imxB9VTkWoXMlV71ITaomJAxVZLXOYWshyIGvjJbo5tTOxY3ZQUq
Wtk+hoiEMuUar2pOok10Uj8wbUs0PkE0kiouqegCGSe2n8KpEADiGUppEaVb
mS5FpHmPLJDsylKG9zD8TKLLLG1maHmPjdu1DPD/Bvi/N4Blpfnx8yzrTLLC
CURoouxKCl86NiPIKPKqyDPDNfcZQI3/DlK8qqXwzuYSGM/x4KK2xgN1jO5k
D9MdypzTjGolAdhWgOLh0/WBs5ExWai58tIRyF6qMLVMbItW8aCkxo9cS0BS
uqJuy8nWWkJU6nICSOUH6y78R2RxH+j7PQD/R5s+S3clYS8hPK++uwT9Jn1S
Am73JM0evsqyrmPWs2ezhsluKiGtkgk8hPIvezD9NqeJOGGFHAjJzp8iQHXn
CiS71YU9eSU3OezGaVzl4ZQ8OKOZUlIldFjQ62HDFblorjIKIFPNZtTDWUxu
BSGHm+vZnP5iR29NHH5az7aIbDtuAOgjSh9TBpskzESVD0px0ILj0tXBjbpj
i2kToK7UkWaoYtKYbcndrZ2FUKZaoU1CkTW9SE953lW22YWvIDXoBdYyF+5M
0lx9iQM+ZyrFjjhetnsuTpEyX11bUTvYYLoE4ewyGd3+ciZkbtiQdboytbNO
K8Lc6+HxR3WS9W57c6PLfbTViFgWM/rQNo4quHhQ5DxoKISBPkgtcxrvE/IH
FlESbhf0Os7BHh/toL2eFlj3kS2Xcq70uR+1zfqVrvS5H9X1YOU5lFIMZaXS
ngOmmRnwQh3YZhZgBSQQj+oQcruTjepdUx+oXaOhXJZwxrNOV1sKGM7OSteq
ubF+xfGoCOrlS85blPuaFx++spokMny6muDhfydVu9BzN7Vt5OyE/kJmbtJy
M5IhGh/e09cPH5/Y6Lyv3lrPPXhuaUchRKT++cN7Ow758HE98v4I0qIQ/X55
+xDstZUMHz98/PD+Ne8mSjYDiWD/2J8A7CEbQOhXGc+RFirVdBPgIroWvWh6
DgDE8iHbmKt5hcoVK8FOD3AIT1x4PNPS2Ioek2tJ2B78rGZ9z9Ge8Vja++23
3zgTRv4cNqHxstt38/KHwdlYDM8H1+Phq+HgTpye/pt4BL1sN9gTiaLk6E+y
aLm7v+cm3JXZPT7o7YnCyMjo3SB4fnhwsoe6QDWuiRasFyfiEx/tvaOQ5Hye
TX4muNoSRZs1uPG00KxUr+UnqxTpel4Yl09yXztNpLoN7CAwUwlwioyMVMkw
/Prt5SVPcLbMS0mHXe9rzNH4zOMjPtK88zXPPTcchl5M+sxc/+A1GjJjy4Z4
RMT4sKcM+HOm09KHGX1dVn65sp57L2g3ONprLJkVM5nqXzkWyOyzbLEb9PAh
NFmx+7zeSheTK/se7AkwQsu/sZnrEtpYtS44T1mW9pNyblfPV7P1tczsdLqx
mDQ4Gvz4dnB9NhCPtfAZVVr3383ZeDAWo/Hd8Pp1xy2w10tuAQhe2u/ng1f9
t5djmB9a8tYe0TnD6/HgNay2i+d/E8Fz+ueA/jmkf472rGLJ/TaYtPw0KrC9
ol0FHetSy9hZVCxgiqxwHabdR7BqLheKG6kVBOL5dQ0BjlnRu/v/eXSw5wd2
Sq/biKZpELHzmPdSAMKczsYmzGyA0SHMGHzfBqXlwrarNcEq1X+1U7X2YwZL
+yILSyrTrs47RAF3onm411wVx0t6i8/CCGePetjTJgldtSbM3a36ddtXCoZv
xvA7FcdW04bunx02StzsbOMVgtBdhVnmu9bR6iJTH7GC7xCTNB4cuQ0d7A1j
NA0L0spFDRZJIpo0cF6hsb9VKd+JV4nnGCe11YQam3HxpPux/nWfLq4Zg9sS
uHk7lsh7xbckhb2Aasoy7eUJt7vj2EJHNRcgm02IP2kGg81M8CkY7q1B/BYe
pxh+UAR5rSUcYqvP2pjT2GziJjXcj9TX/q7Ykz75KMDmsIplc9pC6lhO4N/w
Jmh+KZA1vDADon58vKW7rPp6B8cRrLSSroCzuxqKCA5LCy7XQb7XausKBT4c
cNgQqIHdYCpEHkNoN27dUrT3hKJrDdIkOeV3fDqCUqks0HgV9uKC7/HoiolH
mHMZT+urgkLJ2AfFOFp1deTTkpqLe+wLsyKvmsh013rsmzG9+0Ao3QsOe2h+
4phhHNr7mH074jih7hJAI9Ig0BKcb172X9iUhL7l6o6blgtoURVevdCdKsO5
RnCwpm2TXSCSsgQkHPwnhyiphaMwJLSmfpGEATsez9uYCwgV53OJcCQGjtBV
wJNkyOlAriiG88wQyKitwrIG7dXQ3ZQ2HZ40N4KOYVu89tdIu8VBcLy5uuve
Y3FTc26wVpNwugFAgoCBjPO9zaiD9Tuikc82V4gGuh6b0TrfOStZn16rkNZv
uZ2kDjdG4oN6yTEteOeOzxYbDowyQ7qRRbruphbwUOM4pRes3DbkjFvqR4lN
1b5UYl9uWA/XsgllifpSy15xbJKxl8us1vqG+SvptfDzJlEGcI6mQ3FfSbRG
gXQj++QLKTP1vb1OnNDbhcjkFEmF1RsZ2TbFqUK2IRrSvaln34WkImmv4yO4
fIwSa29F7EiCDB3KXE50DAyAVhedDtKQSywwz319F8LsTuA99zSSRgOuKfkV
669CeK2pOHmFzXQdqg51yLBx6zS+Ws6FeQqdanIU0p69unYuxFBhrmMemBM2
TO9Tvj/NHhwHLHVJLLg5AzOgFllM0thdoSoc4rOuvbSLZooGRiWii3IerfTa
9PkFA/u8tcnZAow+WBgLZuuXuWgBylGeq9SlD0a5FHqZvRr+0l0TX81Tn1ff
0PJ4RDcNh0ULXYeft96iOfTc+axxTSqUIxfGol3q1i6zqEkVKNTkC4m2d1JK
8/x8LXJdUaHOm9oUQomoFIB5NWy3frW0oG6VD+BJVRrxqwObIIigQj8k5ccq
si/BASPwdJRKA+yKzd4Fsg98HlmxAsTxLlQaFfpevATOu8dvpuP9WC1ToGmZ
zjreXZbgdHxexvqh411KpM/BbAZn6HhjPDPiNdQiF4as4/2QpZJnRRcySQAb
sEYngFNxrCZK3Xe8l9D6GxlV+DigU99Q1gJZ/XOViksts453pe+VuKlSUlM5
73ivCnaMkIwVZ8kEiNuSvc1ikBmmcJq7DJ5v3N5R+UM2T419i2GkwM24KlCZ
PFfINQIPLjKtKMYWWj2w/VzwstLcO04TaNz7O3sfMqMdNAAA
</rfc> </rfc>
 End of changes. 63 change blocks. 
526 lines changed or deleted 400 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/