rfc8933xml2.original.xml   rfc8933.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.2.11 -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.2119.xml">
<!ENTITY RFC3161 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.3161.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.8174.xml">
<!ENTITY RFC5652 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.5652.xml">
<!ENTITY RFC6211 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.6211.xml">
<!ENTITY RFC5083 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.5083.xml">
<!ENTITY RFC5280 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.5280.xml">
<!ENTITY RFC6210 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.6210.xml">
<!ENTITY RFC8017 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.8017.xml">
]>
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<rfc ipr="trust200902" docName="draft-ietf-lamps-cms-update-alg-id-protect-05" c ategory="std" updates="5652"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft -ietf-lamps-cms-update-alg-id-protect-05" number="8933" updates="5652" obsoletes ="" submissionType="IETF" category="std" consensus="true" xml:lang="en" tocInclu de="true" sortRefs="true" symRefs="true" version="3">
<front> <front>
<title abbrev="CMS Algorithm Identifier Protection">Update to the Cryptograp hic Message Syntax (CMS) for Algorithm Identifier Protection</title> <title abbrev="CMS Algorithm Identifier Protection">Update to the Cryptograp hic Message Syntax (CMS) for Algorithm Identifier Protection</title>
<seriesInfo name="RFC" value="8933"/>
<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="2020" month="October"/>
<date year="2020" month="August" day="27"/>
<area>Security</area> <area>Security</area>
<workgroup>LAMPS</workgroup>
<keyword>Internet-Draft</keyword> <keyword>digitally sign</keyword>
<keyword>authenticate</keyword>
<keyword>algorithm identifier integrity</keyword>
<abstract> <abstract>
<t>This document updates the Cryptographic Message Syntax (CMS) specified
<t>This document updates the Cryptographic Message Syntax (CMS) specified in RFC in RFC 5652 to ensure that algorithm identifiers in signed-data and authenticate
5652 to ensure that algorithm identifiers in signed-data and authenticated-data d-data content types are adequately protected.</t>
content types are adequately protected.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="intro" numbered="true" toc="default">
<name>Introduction</name>
<t>This document updates the Cryptographic Message Syntax (CMS) <xref targ
et="RFC5652" format="default"/> to ensure that algorithm identifiers in signed-d
ata and authenticated-data content types are adequately protected.</t>
<t>The CMS signed-data content type <xref target="RFC5652" format="default
"/>, unlike X.509 certificates <xref target="RFC5280" format="default"/>, can be
vulnerable to algorithm substitution attacks. In an algorithm substitution att
ack, the attacker changes either the algorithm identifier or the parameters asso
ciated with the algorithm identifier to change the verification process used by
the recipient. The X.509 certificate structure protects the algorithm identifie
r and the associated parameters by signing them.</t>
<t>In an algorithm substitution attack, the attacker looks for a different
algorithm that produces the same result as the algorithm used by the originator
. As an example, if the signer of a message used SHA-256 <xref target="SHS" for
mat="default"/> as the digest algorithm to hash the message content, then the at
tacker looks for a weaker hash algorithm that produces a result that is of the s
ame length. The attacker's goal is to find a different message that results in
the same hash value, which is called a cross-algorithm collision. Today, there
are many hash functions that produce 256-bit results. One of them may be found
to be weak in the future.</t>
<t>Further, when a digest algorithm produces a larger result than is
needed by a digital signature algorithm, the digest value is reduced to
the size needed by the signature algorithm. This can be done both by
truncation and modulo operations, with the simplest being
straightforward truncation. In this situation, the attacker needs to
find a collision with the reduced digest value. As an example, if the
message signer uses SHA-512 <xref target="SHS" format="default"/> as the
digest algorithm and the Elliptic Curve Digital Signature Algorithm (ECDSA
)
with the P-256 curve <xref target="DSS" format="default"/> as the
signature algorithm, then the attacker needs to find a collision with
the first half of the digest.</t>
<t>Similar attacks can be mounted against parameterized algorithm
identifiers.
<section anchor="intro" title="Introduction"> When randomized hash functions are employed, such as the example in <xref target
="RFC6210" format="default"/>, the algorithm identifier parameter includes a ran
<t>This document updates the Cryptographic Message Syntax (CMS) <xref target="RF dom value that can be manipulated by an attacker looking for collisions. Some o
C5652"/> to ensure that algorithm identifiers in signed-data and authenticated-d ther algorithm identifiers include complex parameter structures, and each value
ata content types are adequately protected.</t> provides another opportunity for manipulation by an attacker.</t>
<t>This document makes two updates to CMS to provide protection for the
<t>The CMS signed-data Content Type <xref target="RFC5652"/>, unlike X.509 certi algorithm identifier. First, it mandates a convention followed by many
ficates <xref target="RFC5280"/>, can be vulnerable to algorithm substitution at implementations by requiring the originator to use the same hash
tacks. In an algorithm substitution attack, the attacker changes either the alg algorithm to compute the digest of the message content and the digest of
orithm identifier or the parameters associated with the algorithm identifier to signed attributes. Second, it recommends that the originator include
change the verification process used by the recipient. The X.509 certificate st the CMSAlgorithmProtection attribute <xref target="RFC6211"
ructure protects the algorithm identifier and the associated parameters by signi format="default"/>.</t>
ng them.</t> </section>
<section anchor="terms" numbered="true" toc="default">
<t>In an algorithm substitution attack, the attacker looks for a different algor <name>Terminology</name>
ithm that produces the same result as the algorithm used by the originator. As <t>
an example, if the signer of a message used SHA-256 <xref target="SHS"/> as the The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
digest algorithm to hash the message content, then the attacker looks for a weak IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
er hash algorithm that produces a result that is of the same length. The attack NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
er’s goal is to find a different message that results in the same hash value, wh RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
ich is called a cross-algorithm collision. Today, there are many hash functions "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
that produce 256-bit results. One of them may be found to be weak in the futur be interpreted as
e.</t> described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
<t>Further, when a digest algorithm produces a larger result than is needed by a </t>
digital signature algorithm, the digest value is reduced to the size needed by </section>
the signature algorithm. This can be done both by truncation and modulo operati
ons, with the simplest being straightforward truncation. In this situation, the
attacker needs to find a collision with the reduced digest value. As an exampl
e, if the message signer uses SHA-512 <xref target="SHS"/> as the digest algorit
hm and ECDSA with the P-256 curve <xref target="DSS"/> as the signature algorith
m, then the attacker needs to find a collision with the first half of the digest
.</t>
<t>Similar attacks can be mounted against parameterized algorithm identifiers.
When looking at randomized hash functions, such as the example in <xref target="
RFC6210"/>, the algorithm identifier parameter includes a random value that can
be manipulated by an attacker looking for collisions. Some other algorithm iden
tifiers include complex parameter structures, and each value provides another op
portunity for manipulation by an attacker.</t>
<t>This document makes two updates to CMS to provide protection for the algorith
m identifier. First, it mandates a convention followed by many implementations
by requiring the originator to use the same hash algorithm to compute the digest
of the message content and the digest of signed attributes. Second, it recomme
nds that the originator include the CMSAlgorithmProtection attribute <xref targe
t="RFC6211"/>.</t>
</section>
<section anchor="terms" title="Terminology">
<t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”,
“SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this
document are to be interpreted as described in BCP 14 <xref target="RFC2119"/> <
xref target="RFC8174"/> when, and only when, they appear in all capitals, as sho
wn here.</t>
</section>
<section anchor="required-use-the-same-hash-algorithm" title="Required use the s
ame hash algorithm">
<t>This section updates <xref target="RFC5652"/> to require the originator to us
e the same hash algorithm to compute the digest of the message content and the d
igest of signed attributes.</t>
<section anchor="rfc-5652-section-53" title="RFC 5652, Section 5.3">
<t>Change the paragraph describing the digestAlgorithm as follows:</t>
<t>OLD:</t>
<t><list style='empty'>
<t>digestAlgorithm identifies the message digest algorithm, and any <section anchor="required-use-the-same-hash-algorithm" numbered="true"
toc="default">
<name>Required Use of the Same Hash Algorithm</name>
<t>This section updates <xref target="RFC5652" format="default"/> to requi
re the originator to use the same hash algorithm to compute the digest of the me
ssage content and the digest of signed attributes.</t>
<section anchor="rfc-5652-section-53" numbered="true" toc="default">
<name>RFC 5652, Section 5.3</name>
<t>Change the paragraph describing the digestAlgorithm as follows:</t>
<t>OLD:</t>
<blockquote>
digestAlgorithm identifies the message digest algorithm, and any
associated parameters, used by the signer. The message digest is associated parameters, used by the signer. The message digest is
computed on either the content being signed or the content computed on either the content being signed or the content
together with the signed attributes using the process described in together with the signed attributes using the process described in Section <x
Section 5.4. The message digest algorithm SHOULD be among those ref target="RFC5652" sectionFormat="bare" section="5.4"/>. The message digest a
lgorithm <bcp14>SHOULD</bcp14> be among those
listed in the digestAlgorithms field of the associated SignerData. listed in the digestAlgorithms field of the associated SignerData.
Implementations MAY fail to validate signatures that use a digest Implementations <bcp14>MAY</bcp14> fail to validate signatures that use a dig est
algorithm that is not included in the SignedData digestAlgorithms algorithm that is not included in the SignedData digestAlgorithms
set.</t> set.</blockquote>
</list></t>
<t>NEW:</t>
<t><list style='empty'>
<t>digestAlgorithm identifies the message digest algorithm, and any <t>NEW:</t>
<blockquote>digestAlgorithm identifies the message digest algorithm, a
nd any
associated parameters, used by the signer. The message digest is associated parameters, used by the signer. The message digest is
computed on either the content being signed or the content computed on either the content being signed or the content
together with the signedAttrs using the process described in together with the signedAttrs using the process described in Section <xref ta
Section 5.4. The message digest algorithm SHOULD be among those rget="RFC5652" sectionFormat="bare" section="5.4"/>. The message digest algorit
hm <bcp14>SHOULD</bcp14> be among those
listed in the digestAlgorithms field of the associated SignerData. listed in the digestAlgorithms field of the associated SignerData.
If the signedAttrs field is present in the SignerInfo, then the same If the signedAttrs field is present in the SignerInfo, then the same
digest algorithm MUST be used to compute both the digest of the digest algorithm <bcp14>MUST</bcp14> be used to compute both the digest of th e
SignedData encapContentInfo eContent, which is carried in the SignedData encapContentInfo eContent, which is carried in the
message-digest attribute, and the digest of the DER-encoded message-digest attribute, and the digest of the DER-encoded
signedAttrs, which is passed to the signature algorithm. signedAttrs, which is passed to the signature algorithm.
Implementations MAY fail to validate signatures that use a Implementations <bcp14>MAY</bcp14> fail to validate signatures that use a
digest algorithm that is not included in the SignedData digest algorithm that is not included in the SignedData
digestAlgorithms set.</t> digestAlgorithms set.</blockquote>
</list></t>
</section>
<section anchor="rfc-5652-section-54" title="RFC 5652, Section 5.4">
<t>Add the following paragraph as the second paragraph in Section 5.4:</t>
<t>ADD:</t>
<t><list style='empty'>
<t>When the signedAttrs field is present, the same digest algorithm </section>
MUST be used to compute the digest of the encapContentInfo <section anchor="rfc-5652-section-54" numbered="true" toc="default">
<name>RFC 5652, Section 5.4</name>
<t>Add the following paragraph as the second paragraph in Section <xref
target="RFC5652" sectionFormat="bare" section="5.4"/>.</t>
<t>ADD:</t>
<blockquote>When the signedAttrs field is present, the same digest alg
orithm
<bcp14>MUST</bcp14> be used to compute the digest of the encapContentInfo
eContent OCTET STRING, which is carried in the message-digest eContent OCTET STRING, which is carried in the message-digest
attribute, and the digest of the collection of attributes that attribute and the digest of the collection of attributes that
are signed.</t> are signed.</blockquote>
</list></t> </section>
<section anchor="rfc-5652-section-56" numbered="true" toc="default">
</section> <name>RFC 5652, Section 5.6</name>
<section anchor="rfc-5652-section-56" title="RFC 5652, Section 5.6"> <t>Change the paragraph discussing the signed attributes as follows:</t>
<t>OLD:</t>
<t>Change the paragraph discussing the signed attributes as follows:</t> <blockquote>The recipient <bcp14>MUST NOT</bcp14> rely on any message
digest values computed
<t>OLD:</t>
<t><list style='empty'>
<t>The recipient MUST NOT rely on any message digest values computed
by the originator. If the SignedData signerInfo includes by the originator. If the SignedData signerInfo includes
signedAttributes, then the content message digest MUST be signedAttributes, then the content message digest <bcp14>MUST</bcp14> be
calculated as described in Section 5.4. For the signature to be calculated as described in Section <xref target="RFC5652" sectionFormat="bare
valid, the message digest value calculated by the recipient MUST " section="5.4"/>. For the signature to be
valid, the message digest value calculated by the recipient <bcp14>MUST</bcp1
4>
be the same as the value of the messageDigest attribute included be the same as the value of the messageDigest attribute included
in the signedAttributes of the SignedData signerInfo.</t> in the signedAttributes of the SignedData signerInfo.</blockquote>
</list></t> <t>NEW:</t>
<blockquote>The recipient <bcp14>MUST NOT</bcp14> rely on any message
<t>NEW:</t> digest values computed
<t><list style='empty'>
<t>The recipient MUST NOT rely on any message digest values computed
by the originator. If the SignedData signerInfo includes the by the originator. If the SignedData signerInfo includes the
signedAttrs field, then the content message digest MUST be signedAttrs field, then the content message digest <bcp14>MUST</bcp14> be
calculated as described in Section 5.4, using the same digest calculated as described in Section <xref target="RFC5652" sectionFormat="bare
" section="5.4"/> using the same digest
algorithm to compute the digest of the encapContentInfo eContent algorithm to compute the digest of the encapContentInfo eContent
OCTET STRING and the message-digest attribute. For the signature OCTET STRING and the message-digest attribute. For the signature
to be valid, the message digest value calculated by the recipient to be valid, the message digest value calculated by the recipient
MUST be the same as the value of the messageDigest attribute <bcp14>MUST</bcp14> be the same as the value of the messageDigest attribute
included in the signedAttrs field of the SignedData signerInfo.</t> included in the signedAttrs field of the SignedData signerInfo.</blockquote>
</list></t> </section>
<section anchor="backward-compatibility-considerations" numbered="true" to
</section> c="default">
<section anchor="backward-compatibility-considerations" title="Backward Compatib <name>Backward Compatibility Considerations</name>
ility Considerations"> <t>The new requirement introduced above might lead to incompatibility wi
th an implementation that allowed different digest algorithms to be used to comp
<t>The new requirement introduced above might lead to incompatibility with an im ute the digest of the message content and the digest of signed attributes. The
plementation that allowed different digest algorithms to be used to compute the signatures produced by such an implementation when two different digest algorith
digest of the message content and the digest of signed attributes. The signatur ms are used will be considered invalid by an implementation that follows this sp
es produced by such an implementation when two different digest algorithms are u ecification. However, most, if not all, implementations already require the ori
sed will be considered invalid by an implementation that follows this specificat ginator to use the same digest algorithm for both operations.</t>
ion. However, most, if not all, implementations already require the originator </section>
to use the same digest algorithm for both operations.</t> <section anchor="timestamp-compatibility-considerations" numbered="true" t
oc="default">
</section> <name>Timestamp Compatibility Considerations</name>
<section anchor="timestamp-compatibility-considerations" title="Timestamp Compat <t>The new requirement introduced above might lead to compatibility
ibility Considerations"> issues for timestamping systems when the originator does not wish to
share the message content with the Time Stamping Authority (TSA) <xref
<t>The new requirement introduced above might lead to compatibility issues for t target="RFC3161" format="default"/>. In this situation, the
imestamping systems when the originator does not wish to share the message conte originator sends a TimeStampReq to the TSA that includes a
nt with the Time Stamp Authority (TSA) <xref target="RFC3161"/>. In this situat MessageImprint, which consists of a digest algorithm identifier and a
ion, the originator sends a TimeStampReq to the TSA that includes a MessageImpri digest value. The TSA then uses the originator-provided digest in the Mes
nt, which consists of a digest algorithm identifier and a digest value, then the sageImprint.</t>
TSA uses the originator-provided digest in the MessageImprint.</t> <t>When producing the TimeStampToken, the TSA <bcp14>MUST</bcp14> use th
e same digest algorithm to compute the digest of the encapContentInfo eContent,
<t>When producing the TimeStampToken, the TSA MUST use the same digest algorithm which is an OCTET STRING that contains the TSTInfo, and the message-digest attri
to compute the digest of the encapContentInfo eContent, which is an OCTET STRIN bute within the SignerInfo.</t>
G that contains the TSTInfo, and the message-digest attribute within the SignerI <t>To ensure that TimeStampToken values that were generated before this
nfo.</t> update remain valid, no requirement is placed on a TSA to ensure that the digest
algorithm for the TimeStampToken matches the digest algorithm for the MessageIm
<t>To ensure that TimeStampToken values that were generated before this update r print embedded within the TSTInfo.</t>
emain valid, no requirement is placed on a TSA to ensure that the digest algorit </section>
hm for the TimeStampToken matches the digest algorithm for the MessageImprint em </section>
bedded within the TSTInfo.</t> <section anchor="recommended-inclusion-of-the-cmsalgorithmprotection-attribu
te" numbered="true" toc="default">
</section> <name>Recommended Inclusion of the CMSAlgorithmProtection Attribute</name>
</section> <t>This section updates <xref target="RFC5652" format="default"/> to recom
<section anchor="recommended-inclusion-of-the-cmsalgorithmprotection-attribute" mend that the originator include the CMSAlgorithmProtection attribute <xref targ
title="Recommended inclusion of the CMSAlgorithmProtection attribute"> et="RFC6211" format="default"/> whenever signed attributes or authenticated attr
ibutes are present.</t>
<t>This section updates <xref target="RFC5652"/> to recommend that the originato <section anchor="rfc-5652-section-14" numbered="true" toc="default">
r include the CMSAlgorithmProtection attribute <xref target="RFC6211"/> whenever <name>RFC 5652, Section 14</name>
signed attributes or authenticated attributes are present.</t> <t>Add the following paragraph as the eighth paragraph in Section <xref
target="RFC5652" sectionFormat="bare" section="14"/>:</t>
<section anchor="rfc-5652-section-14" title="RFC 5652, Section 14"> <t>ADD:</t>
<blockquote>While there are no known algorithm substitution attacks to
<t>Add the following paragraph as the eighth paragraph in Section 14:</t> day,
<t>ADD:</t>
<t><list style='empty'>
<t>While there are no known algorithm substitution attacks today,
the inclusion of the algorithm identifiers used by the originator the inclusion of the algorithm identifiers used by the originator
as a signed attribute or an authenticated attribute makes such an as a signed attribute or an authenticated attribute makes such an
attack significantly more difficult. Therefore, the originator attack significantly more difficult. Therefore, the originator
of a signed-data content type that includes signed attributes of a signed-data content type that includes signed attributes
SHOULD include the CMSAlgorithmProtection attribute <xref target="RFC6211"></ xref> as <bcp14>SHOULD</bcp14> include the CMSAlgorithmProtection attribute <xref targ et="RFC6211" format="default"/> as
one of the signed attributes. Likewise, the originator of an one of the signed attributes. Likewise, the originator of an
authenticated-data content type that includes authenticated authenticated-data content type that includes authenticated
attributes SHOULD include the CMSAlgorithmProtection attribute attributes <bcp14>SHOULD</bcp14> include the CMSAlgorithmProtection attribute
<xref target="RFC6211"></xref> as one of the authenticated attributes.</t> <xref target="RFC6211" format="default"/> as one of the authenticated attribu
</list></t> tes.</blockquote>
</section>
</section>
<section anchor="iana-considerations" title="IANA Considerations">
<t>This document makes no requests of the IANA.</t>
</section>
<section anchor="security-considerations" title="Security Considerations">
<t>The security properties of the CMS <xref target="RFC5652"/> signed-data and </section>
</section>
<section anchor="iana-considerations" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>This document has no IANA actions.</t>
</section>
<section anchor="security-considerations" numbered="true" toc="default">
<name>Security Considerations</name>
<t>The security properties of the CMS <xref target="RFC5652" format="defau
lt"/> signed-data and
authenticated-data content types are updated to offer protection for authenticated-data content types are updated to offer protection for
algorithm identifiers, which makes algorithm substitution attacks algorithm identifiers, which makes algorithm substitution attacks
significantly more difficult.</t> significantly more difficult.</t>
<t>For the signed-data content type, the improvements specified in this
<t>For the signed-data content type, the improvements specified in this
document force an attacker to mount a hash algorithm substitution attack document force an attacker to mount a hash algorithm substitution attack
on the overall signature, not just on the message digest of the on the overall signature, not just on the message digest of the
encapContentInfo eContent.</t> encapContentInfo eContent.</t>
<t>Some digital signature algorithms have prevented hash function
<t>Some digital signature algorithms have prevented hash function substitutions substitutions by including a digest algorithm identifier as an input to
by including a digest algorithm identifier as an input to the signature the signature algorithm. As discussed in <xref target="HASHID"
algorithm. As discussed in <xref target="HASHID"/>, such a “firewall” may not b format="default"/>, such a "firewall" may not be effective or even
e effective possible with newer signature algorithms. For example,
or even possible with newer signature algorithms. For example, RSASSA-PKCS1-v1_5 <xref target="RFC8017" format="default"/> protects the
RSASSA-PKCS1-v1_5 <xref target="RFC8017"/> protects the digest algorithm identif digest algorithm identifier, but RSASSA-PSS <xref target="RFC8017"
ier, but format="default"/> does not. Therefore, it remains important that a
RSASSA-PSS <xref target="RFC8017"/> does not. Therefore, it remains important t signer have a way to signal to a recipient which digest algorithms are
hat a allowed to be used in conjunction with the verification of an overall
signer have a way to signal to a recipient which digest algorithms are allowed signature. This signaling can be done as part of the specification of
to be used in conjunction with the verification of an overall signature. This the signature algorithm in an X.509v3 certificate extension <xref
signaling can be done as part of the specification of the signature algorithm, target="RFC5280" format="default"/> or some other means. The Digital
in an X.509v3 certificate extension <xref target="RFC5280"/>, or some other mean Signature Standard (DSS) <xref target="DSS" format="default"/> takes the
s. The first approach by requiring the use of an "approved" one-way hash
Digital Signature Standard (DSS) <xref target="DSS"/> takes the first approach b algorithm.</t>
y requiring <t>For the authenticated-data content type, the improvements specified in
the use of an “approved” one-way hash algorithm.</t>
<t>For the authenticated-data content type, the improvements specified in
this document force an attacker to mount a MAC algorithm substitution this document force an attacker to mount a MAC algorithm substitution
attack, which is difficult because the attacker does not know the attack, which is difficult because the attacker does not know the
authentication key.</t> authentication key.</t>
<t>The CMSAlgorithmProtection attribute <xref target="RFC6211" format="def
<t>The CMSAlgorithmProtection attribute <xref target="RFC6211"/> offers protecti ault"/> offers protection for the algorithm identifiers used in the signed-data
on for the algorithm identifiers used in the signed-data and authenticated-data and authenticated-data content types. However, no protection is provided for th
content types. However, no protection is provided for the algorithm identifiers e algorithm identifiers in the enveloped-data, digested-data, or encrypted-data
in the enveloped-data, digested-data, or encrypted-data content types. Likewis content types. Likewise, the CMSAlgorithmProtection attribute provides no prote
e, The CMSAlgorithmProtection attribute provides no protection for the algorithm ction for the algorithm identifiers used in the authenticated-enveloped-data con
identifiers used in the authenticated-enveloped-data content type defined in <x tent type defined in <xref target="RFC5083" format="default"/>. A mechanism for
ref target="RFC5083"/>. A mechanism for algorithm identifier protection for the algorithm identifier protection for these content types is work for the future.
se content types is work for the future.</t> </t>
</section>
</section>
<section anchor="acknowledgements" title="Acknowledgements">
<t>Many thanks to Jim Schaad and Peter Gutmann; without knowing it, they motivat
ed me to write this document. Thanks to Roman Danyliw, Ben Kaduk, and Peter Yee
for their careful review and editorial suggestions.</t>
</section>
</middle> </middle>
<back> <back>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.3161.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8174.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5652.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6211.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5083.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5280.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6210.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8017.xml"/>
<references title='Normative References'> <reference anchor="SHS">
<front>
&RFC2119; <title>Secure Hash Standard (SHS)</title>
&RFC3161; <author>
&RFC8174; <organization>National Institute of Standards and Technology (NIST
&RFC5652; )</organization>
&RFC6211; </author>
<date year="2015" month="August"/>
</references> </front>
<seriesInfo name="FIPS" value="180-4"/>
<references title='Informative References'> <seriesInfo name="DOI" value="10.6028/NIST.FIPS.180-4"/>
</reference>
&RFC5083; <reference anchor="DSS">
&RFC5280; <front>
&RFC6210; <title>Digital Signature Standard (DSS)</title>
&RFC8017; <author>
<reference anchor="SHS" > <organization>National Institute of Standards and Technology (NIST
<front> )</organization>
<title>Secure Hash Standard</title> </author>
<author > <date year="2013" month="July"/>
<organization>National Institute of Standards and Technology (NIST)</organ </front>
ization> <seriesInfo name="FIPS" value="186-4"/>
</author> <seriesInfo name="DOI" value="10.6028/NIST.FIPS.186-4"/>
<date year="2015" month="August"/> </reference>
</front>
<seriesInfo name="FIPS Publication" value="180-4"/>
</reference>
<reference anchor="DSS" >
<front>
<title>Digital Signature Standard (DSS)</title>
<author >
<organization>National Institute of Standards and Technology (NIST)</organ
ization>
</author>
<date year="2013" month="July"/>
</front>
<seriesInfo name="FIPS Publication" value="186-4"/>
</reference>
<reference anchor="HASHID" >
<front>
<title>On Hash Function Firewalls in Signature Schemes</title>
<author initials="B." surname="Kaliski" fullname="Burton S. Kaliski, Jr.">
<organization></organization>
</author>
<date year="2002" month="February" day="08"/>
</front>
<seriesInfo name="Lecture Notes in Computer Science," value="Volume 2271"/>
<seriesInfo name="DOI" value="10.1007/3-540-45760-7_1"/>
</reference>
<reference anchor="HASHID">
<front>
<title>On Hash Function Firewalls in Signature Schemes</title>
<author initials="B." surname="Kaliski" fullname="Burton S. Kaliski,
Jr.">
<organization/>
</author>
<date year="2002" month="February"/>
</front>
<seriesInfo name="DOI" value="10.1007/3-540-45760-7_1"/>
<seriesInfo name="Lecture Notes in Computer Science," value="Volume
2271"/>
</reference>
</references>
</references> </references>
<section anchor="acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>Many thanks to <contact fullname="Jim Schaad"/> and <contact
fullname="Peter Gutmann"/>; without knowing it, they motivated me to
write this document. Thanks to <contact fullname="Roman Danyliw"/>,
<contact fullname="Ben Kaduk"/>, and <contact fullname="Peter Yee"/> for
their careful review and editorial suggestions.</t>
</section>
</back> </back>
<!-- ##markdown-source:
H4sIAFTFR18AA+Vae2/jNhL/X5+CSIC7LWDl7Owm2brA4bzJbpM2r4u97RVF
UdASbbORRFWU7HUX+e43MyQlSraT7LZFcbhDD6vI4nCev3mQYRgGpSwTMWTv
85iXgpWKlQvBTot1Xqp5wfOFjNiV0JrPBRuvs5J/YC9Or8ZfsJkq2CiZq0KW
i5RdxCIr5UyKgt0WqhRRKVUW8Om0EMshgwVPfhurKOMpcBIXfFaGUpSzMOFp
rsMo1WFF7IU8mYcyDnOzLOwfBfh6yA77h/2w/zo8PAkieAE7rYdMl3Fg1ukh
Ozo+OgwCmRdDVhaVLg/7/S/7hwEvBB+ysYgq4G0d3Iv1ShXxkF1kpSgyUYZn
yE0Q6JJn8c88URnslqkgl0P2Y6miHtOqKAsx0/C0TvHhpyDgVblQxTBgYcDg
fzIDBu4O2LmqdCLW9M7Ieldp3XqtivmQfSfnMqmZ6rHLy1P60amz/Tv9pIEH
UYKYg2MGLGdCL2WSCHaneEwfRPDlkJ2DULHKeuy7kXmrYtLe4KRv/66yEnX3
fkx/i5TLZMgWhsN/LXFjLaKDSKVBkKki5aVcChCU3b07PRwMvrSPLwfHA/v4
enDyyj6iDezjMXw8BHtksw6Ro/7rl+7x8HW/+dw9vgZm8XF8Ph4Sj9aB90gf
gp1zvWBjNBcv4j2jN2cOVqv4mqPT8QQMrYFABa6vZvUyzeBfNhHRIlOJmq/Z
i+uL8eQLIuAcbnAEDmd0LwopNIritth7d3E7ZrfVNJERbbQ3ZIPX/fAV/H42
bvN9BjotgZGxnGe8RAkcF+wFfPvFnyjBy7B/8kkSHJME56Px+cVZS4ibzOj9
XZVRNLN3shArniQanN8XLVqIVOgWG/3DEP97vUVQCpw3B+xbnkh9L+1bEzpv
qqKEjcb1rz32TXGwS5xLgAtk4BqAg3g6VWkOOiuAJSmySPRAwO9UUqWCHR6e
DOy6s5sLkLt/MOj3T/7xMjx6BTY8Ojnuhyc/D4IgDEOISQg9HgFETBZSM0Ax
IJGVzALPc9FU5yJCSIyRN/BywitEY5Fp5Ltc8JLxGkJlDaEkjAYFiziEHTnZ
HbWIHyAW2teRAkQDvsp1DlwB7DEei18r+CBZM4unIj4wQqUyjhMRBPsAg4WK
K2PTj/sS/3z4naJ+/Gih4OHhLxFwgmxCQvJpntrFE1jsM9hjVZbIe8H+c3DU
/5JFokCmIhLXfAYYhZ9FPGNTwZZVkomCTxPKpI04upqaIEU98rLk0b0+YBC6
IM3jn/VIreYZvDVa8GwOmwv4Hv6k37YoDSCCfst5AcFSoha51iqSqC+2gq93
LwXGzS70yRJiaWYxANUYgUlZpYHKdE0fFOC4OYRQCfKgajc0hbmpMtFnzaB3
b47GpR8bbj0ZYEu0mszm+FEKxvx0DSZK3WuqXjiL5WwmCjR8Q4EcMSevtz6t
YXsQU1cJfNfl3VcFvJpLQDpVgC5GCMFMfIASJhE9JmeGFjpdgUjNWWqjg0iM
z0fh4dExeBUkNogMu1Eswdot9hRbINLij46AdX0SNNst7UpwfEXLd8nLnaD0
GqJczRodJCKblwtrZ7fF3zWbK0hD8C3wNpMYnZ5iHY9Ez9CmiK6JEjtLnlSg
pBWAxgIpRZA6BBKKCqV12HAbqQTAHoyLXKiYr0loDHb4f8qztaE3s3lIt8Rj
oOBwKms+gMZNJqyIKSxfYwzPoAaKURZ4RpU5bmcV+jD43DvIPLAnsgvq5ps2
8rSZ8GIOOm+UmqF4mRCxcRtaTflf10myJtTzXYBUhIsLgcRjV6pr+ZvwCDon
65Aio5FiCaegBhRsqgAGcEkB2jIBjuGXAvOJYioHICMd9hrA0BK9GbiZCgxC
TH1yvijBv1ZYsDSUDLiVuKWGcKR3nUBEnn2fqU3bbOdE9VWwM7Scp9kQg6jS
FFVHg8Mnowrlfnt6Nh41e99SOEJJucSMAJVYs3yXqbJPFnAmC+BjwZOZCzTD
GnjZWKYSvMdlC2e5FCt0DI05h+qobNAR3CDenkBBY98jc4gFaDUMRBBYpbSk
HS/QxVQQglZQq2KMAMp2WIZjttsJ3zU3sCRKqtggCm1mHZji0cnCM5lXCaE8
xkLWxi3kFZGr1htKMlaAGYqS365qgTaGVcj6B4+lOg+BlGhwwSOLPBixS0nc
Zoa2ynPo66oMuibioWYVzdfm9aBbD6UAs6C/lWoqI0UVB/xjN3KZEKnN1O48
DgK/QxcBJ0e6mSFHxc4Sv6HlSaJWRoMEgBSiyIiJXnxfQCEkC5s2vTSFHEGc
dMC4lWwiUyf7YaPa8eYKL5e6m69MhYWKKuQUiJD9BHwfkzxQOagUGI0tSnd4
c4YsTb1Wzw+amUFDuXbPwcMD2GN/IopU2s7n4z4YP9UPpvKDDp9hi6/Z3tX7
8WSvZ/5l1zf0fPf23+8v7t6e4TOAx+Vl/eC+GJ/fvL88a56alac3V1dvr8/M
YnjLOq+uRj/sGc/bu7mdXNxcjy73THIB72ncBzOZyT4ShxB5ISjewcGEjkBc
0yO8Ob39WzbV+VeDV0Z47L4BougZe254xvxkNlQZFMHmT1AnuG+eC44qBmMn
EI45piAMC4DrhVplDHMqKvKOPAe2fMRNrP9raxTn9J063/ig+Ks9EGTad/1V
D72ReD46eBkEp03Vi6BBTYxTuosdQ7qZZXFtA1APg+DmErri4J/YO3a/q0Na
tzjvJiJjLYhipLG1Bu61Kk6T62xF1iEqqc222kMX8JsGpzKbx42aVOs3XA2t
nKA1XgXQ0Sjw45Tj2gPfUZFKo+VX21lt7G1jCpyfp4rIKi2QBmSA0nj+FjOA
EaRIYucXnuLGpKAz6PFoNHDRwUYISTbjMkE/g0wgaQZap3eLS+ifrsoju7Rr
Z6znVOngqmaRdo5x5w1uA5pRYJK/fvv9/4nHjMBh/sd8ZbbBvlkJBgdQ1qgM
39bFRTZTXh2IcNYY1uOb8s3U9n0ewFE9voFypJTGlwQU2LkdV+CGTJy67s/r
nopC1gpAAlaHoePFRW9vC2biX2dv70LYSYE/k7M2OvC2yUF3fh+y2XT8vpDb
qrznhdyWgNI25LbD/6sgGMVGEwbP0U+bLOAKfypevPc43GxoQCiPzuoU8H3t
CI94UK/JfF1RkcYuV9m0WNcvcLVzDXZzOnk7YePJ3cX11zv9pOMkhCdP+QmW
5lZ+HGk0SQHNRBQKJ/9O1R/vyrxSR5WuAWMz8ezKvRN/KsVcdQevoAaiHnfd
xRRqAnSNfEhk20jHIoIXjboO/LrhaceLYdVDBQejHQ6soQl/eRLZpqhb9LXB
8Z1F3ybyqGxEGhRYvW2Jw/Q73h7dMR6xQhrwqjLr/2Zxu/o660BKHZUBDfA7
EWBNpx7RZDst/rXGdPi5EcJ/gkV7Xnb0AKFTcXwKBtQAgDR8DKijeVde2OZd
JrvTlPvzvcsHtc/xLuNUbdjfxNcn3Gt//w107jSxwmMgSExTmWCnD+rSUHfZ
uZdpGDOxcr1LalK+ORJBY07VEjjFCRhLBCeEBuZaJKkMwqlfKw0ye9xhOvdm
WtrNAdpq/Gn8/7xufLJo5d7cSYaDdpoDbTBOM0+cbTzGNKI+sbyS0F5OiStS
LBmN3McOUbapxYK6nR6ag7F6qngOGlvi8DVVNBaZUSUAmuxtDD54UoBR1s/t
PDdKDRzMUE3WjELJeSYSlF3yNP/jvaftO1JrRDIaELk9qfheQ30Lal45CPKk
ipUwxdFK4imBgn6eW9m7LlJX6CgQnhyDRCM6f8XNX0zGI3tYh6f5Dw+7R7re
9prGOZxIEsU78aurEIGgLd+a2aA9IYQisZBNDUvuokttzkk2DNM5L+It9PGQ
GTekMXCbydAO4eq5ssWRNi9gaqrgTEw4YK7lmqh7O02hbQjTHnenz4Nur1yD
cGmBuBmlwmc4CbacTEwT8hS+k+03mhecZLYPZNviutRKP63w1GUu8LiTgF6A
mwrjHmYCBH6fAmcuW2SqHQiANgmPTJvJjW+09/aU1I7JTTuwlJfRQuwY7rs1
bfsykUIOju1xqMx8BZrJl51OEmaBw2pb5T5nHvnckZjd4g+dfxIsIEZuKZnx
HNA/Om+V03RAS13Jjlp98LwuSSCkLbZ3SYONJkkmJKI9wgMvuc9wAPn42Tlo
D8/+qCRZiE37bD8a2H5WawYnjG+oi7SV7VKYHfPbNGm7JeDNnFBjxspKqFFT
jArMlRJKIntGXlCsdLETSRDe+RcT/FsNHfDcsC5NCsxM5JN850frOj+BGoiJ
+kx0a81wKe8FJJcN/ol5o4jHb2d0k4D/davr1J8jDlLwJfLF2eX76O8Xo+vR
lhS+ebBjgUzY/IR0cS3ScFfytpYC2v0IGSXH6xFNH4SHQz42dK67BM+67mJA
hsoIhaVZ54wp2BoTLr0Y0R4PuuBRzw4Cv2PYxqZxGKjSIP1SEtDta0+YO4Ja
2cByJFpngiAYnX5CiHROCbZwGyhbGgEQ4hlHXeX2qDr6pcLc25p7dMZuOzMy
ns0qk+B3HdxrYHBJaIqndN1D1ha7OgBAMv5NZ7OPVztUBMgMioiNsVtjX3NC
bscnRrUfP5pLe3h4axCL7c3sFb09uviASoFCXYDnRHgdMwBjIvcsV1pLvNBE
5SLUszaxdEW2LaM7lQ/uxqPxeBTefns6HoTLwc9H9miqPzgBD2/dBHpE5B6D
AK1pjcctIq7WbaMqnSymVBOBr6mi5Jm9zsIDezeArMPZCuTGChmloXkk90YN
Ji629za2cQu85gyUDL7+izNxXVu37k8RQm66pL2cERhG0A38axocJ61FXSm2
GiIfp7s3EgJJd6PoPtbyZetGlvgAjkz5snWJDev35ng9FTyzPWLw1CXV+oZE
ac6+F+5qA8/B0njO7p9CB/g7FstGH3v00VLEe4jVIVqlHd8etjyBhE9ATFC2
8PxRiLkane5AmMDdK6sr8xoFwWgRd21ATbXuybC0IXDxxEAr3It1czHx+YUe
wbx+7l0CXTtqF6Sfc6PSb70z5e9Jw2zbUD2+v91aZEuRQAo02/RsjNV/Iohk
Ed4j3cVIU4E8S2X15Y4238/XVVs3bfbblU0sZjJzkGtvs1PnPIJwwluVUpt+
ZPvtmQ3mtOgkelD2ShX3NfP1pbT9UYTelYh4bhw/CK5wOIpXzqheZt/IFO9f
cx6TwW/pTszXVZnyLPuKAEtVxkURgWRprwqkCtIBFRYpDZhXwLbt81wgEUi4
be4UEGRnsHciVz32BlLItzyu7nverj8I4SSQBR5DiFmVAD4spViZqzmxhIpS
Ynat5ugddviCl5OnmN3/C5s5uji6MgAA
</rfc> </rfc>
 End of changes. 42 change blocks. 
421 lines changed or deleted 293 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/