One document matched: draft-schaad-smime-algorithm-attribute-05.xml
<?xml version="1.0" encoding="UTF-8"?><?rfc linefile="1:algorithm.xml"?>
<!-- automatically generated by xml2rfc v1.35 on 2011-01-25T01:13:16Z -->
<?xml-stylesheet type="text/xsl" href="../rfc2629xslt/rfc2629.xslt"?>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<!-- xml2rfc-processed-entity RFC2119 -->
<!-- xml2rfc-processed-entity RFC2634 -->
<!-- xml2rfc-processed-entity RFC3370 -->
<!-- xml2rfc-processed-entity RFC3447 -->
<!-- xml2rfc-processed-entity RFC4056 -->
<!-- xml2rfc-processed-entity RFC5035 -->
<!-- xml2rfc-processed-entity RFC5280 -->
<!-- xml2rfc-processed-entity RFC5652 -->
<!-- xml2rfc-processed-entity RFC5912 -->
<!-- xml2rfc-processed-entity schaad-hash -->
<!-- xml2rfc-processed-entity algorithm-asn -->
<rfc ipr="trust200902" docName="draft-schaad-smime-algorithm-attribute-05" category="std">
<front>
<title abbrev="CMS Algorithm Attribute">Cryptographic Messages Syntax (CMS) Algorithm Identifier Protection Attribute</title>
<author initials="J." surname="Schaad" fullname="Jim Schaad">
<organization>Soaring Hawk Consulting</organization>
<address>
<email>ietf@augustcellars.com</email>
</address>
</author>
<date/>
<abstract>
<t>The Cryptographic Message Syntax (CMS) unlike X.509/PKIX certificates, are venerable to algorithm substitution attacks. In an algorithm substitution attack, the attacker changes either the algorithm being used or parameters of the algorithm in order to change the result of a signature verification process. In X.509 certificates, the signature algorithm is protected because it is duplicated in the TBSCertificate.signature field with the proviso that the validater is to compare both fields as part of the signature validation process. This document defines a new attribute that contains a copy of the relevant algorithm identifiers so that they are protected by the signature or authentication process.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>The Cryptographic Message Syntax (CMS) <xref target="CMS"/> unlike X.509/PKIX certificates <xref target="RFC5280"/>, are venerable to algorithm substitution attacks. In an algorithm substitution attack, the attacker changes either the algorithm being used or parameters of the algorithm in order to change the result of a signature verification process. In X.509 certificates, the signature algorithm is protected because it is duplicated in the TBSCertificate.signature field with the proviso that the validater is to compare both fields as part of the signature validation process. This document defines a new attribute that contains a copy of the relevant algorithm identifiers so that they are protected by the signature or authentication process.</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 signer. As an example, if the creator of the message used SHA-1 as the digest algorithm to hash the message content then the attacker looks for a different hash algorithm that produces a result that is the same length, but with which it is easier to find collisions. Examples of other algorithms that produce a hash value of the same length would be SHA-0 or RIPEMD-160. Similar attacks can be mounted against parameterized algorithm identifiers. When looking at some of the proposed randomized hashing functions, such as that in <xref target="RANDOM-HASH"/>, the associated security proofs assume that the parameters are solely under the control of the originator and not subject to selection by the attacker.</t>
<t>Some algorithms have been internally designed to be more resistant to this type of attack. Thus an RSA PKCS #1 v.15 signature <xref target="RFC3447"/> cannot have the associated hash algorithm changed because it is encoded as part of the signature. DSA was originally defined so that it would only work with SHA-1 as a hash algorithm, thus by knowing the public key from the certificate, a validator can be assured that the hash algorithm can not be changed. There is a convention, undocumented as far as I can tell, that the same hash algorithm should be used for both the content digest and the signature digest. There are cases, such as third party signers that are only given a content digest, where such a convention cannot be enforced.</t>
<t>As with all attacks, the attack is going to be desirable on items that are both long term and high value. One would expect that these attacks are more likely to be made on older documents as the algorithms being used when the message was signed would be more likely to have degraded over time. Countersigning, the classic method of protecting a signature does not provide any additional protection against an algorithm substitution attack because countersignatures sign just the signature, but the algorithm substitution attacks leave the signature value alone while changing the algorithms being used.</t>
<t>Using the SignerInfo structure from CMS, let's take a more detailed look at each of the fields in the structure and discuss what fields are and are not protected by the signature. I have included a copy of the ASN.1 here for convenience. A similar analysis of the AuthenticatedData structure is left to the reader, but it can be done in much the same way.</t>
<figure>
<artwork>
SignerInfo ::= SEQUENCE {
version CMSVersion,
sid SignerIdentifier,
digestAlgorithm DigestAlgorithmIdentifier,
signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
signatureAlgorithm SignatureAlgorithmIdentifier,
signature SignatureValue,
unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }
</artwork>
</figure>
<t>
<list style="hanging">
<t hangText="version">is not protected by the signature. As many implementations of CMS today ignore the value of this field that is not a problem. If the value is increased, then no changes in the processing are expected. If the value is decreased, implementations that respect the structure would fail to decode, but an erroneous signature validation would not be completed successfully.</t>
<t hangText="sid">can be protected using either version of the signing certificate authenticated attribute. SigningCertificateV2 is defined in <xref target="RFC5035"/>. SigningCertificate is defined in <xref target="ESS-BASE"/>. In addition to allowing for the protection of the signer identifier, the specific certificate is protected by including a hash of the certificate to be used for validation.</t>
<t hangText="digestAlgorithm">the digest algorithm used has been implicitly protected by the fact that CMS has only defined one digest algorithm for each hash value length. (The algorithm RIPEM-160 was never standardized). There is also an unwritten convention that the same digest algorithm should be used both here and for the signature algorithm. If newer digest algorithms are defined so that there are multiple algorithms for a given hash length (it is expected that the SHA-3 project will do so), or that parameters are defined for a specific algorithm, much of the implicit protection will be lost.</t>
<t hangText="signedAttributes">are directly protected by the signature when they are present. The DER encoding of this value is what is hashed for the signature computation.</t>
<t hangText="signatureAlgorithm">has been protected by implication in the past.
The use of an RSA public key implied that the RSA v 1.5 signature algorithm was being used. The hash algorithm and this fact could be checked by the internal padding defined. This is no longer true with the addition of the RSA-PSS signature algorithms.
The use of a DSA public key implied the SHA-1 hash algorithm as that was the only possible hash algorithm and the DSA was the public signature algorithm. This is still somewhat true as there is an implicit tie between the length of the DSA public key and the length of the hash algorithm to be used, but this is known by convention and there is no explicit enforcement for this.
</t>
<t hangText="signature">is not directly protected by any other value unless a counter signature is present. However this represents the cryptographically computed value that protects the rest of the signature information.</t>
<t hangText="unsignedAttrs">is not protected by the signature value. It is also explicitly designed that they not to be protected by the signature value.</t>
</list></t>
<t>As can be seen above, the digestAlgorithm and signatureAlgorithm fields have been indirectly rather than explicitly protected in the past. With new algorithms that have been or are being defined this will no longer be the case. This document defines and describes a new attribute that will explicitly protect these fields along with the macAlgorithm field of the AuthenticatedData structure.</t>
<section title="Notation">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <xref target="RFC2119"/>.</t>
</section>
</section>
<section title="Attribute Structure">
<t>The following defines the algorithm protection attribute:</t>
<t>The algorithm-protection attribute has the ASN.1 type CMSAlgorithmProtection:</t>
<figure>
<artwork>
aa-cmsAlgorithmProtection ATTRIBUTE ::= {
TYPE CMSAlgorithmProtection
IDENTIFIED BY { id-aa-CMSAlgorithmProtection }
}
</artwork></figure>
<t>The following object identifier identifies the algorithm-protection attribute:</t>
<figure>
<artwork>
id-aa-CMSAlgorithmProtection OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 52 }
</artwork>
</figure>
<t>The algorithm-protection attribute uses the following ASN.1 type:</t>
<figure><artwork>
CMSAlgorithmProtection ::= SEQUENCE {
digestAlgorithm DigestAlgorithmIdentifier,
signatureAlgorithm [1] SignatureAlgorithmIdentifier OPTIONAL,
macAlgorithm [2] MessageAuthenticationCodeAlgorithm
OPTIONAL
}
(WITH COMPONENTS { signatureAlgorithm PRESENT,
macAlgorithm ABSENT } |
WITH COMPONENTS { signatureAlgorithm ABSENT,
macAlgorithm PRESENT })
</artwork>
</figure>
<t>The fields are defined as follows:</t>
<t>
<list style="hanging">
<t hangText="digestAlgorithm">contains a copy of the SignerInfo.digestAlgorithm field or the AuthenticatedData.digestAlgorithm field including any parameters associated with it.</t>
<t hangText="signatureAlgorithm">contains a copy of the signature algorithm identifier and any parameters associated with it (SignerInfo.signatureAlgorithm). This field is only populated if the attribute is placed in a SignerInfo.signedAttrs sequence.</t>
<t hangText="macAlgorithm">contains a copy of the message authentication code algorithm identifier and any parameters associated with it (AuthenticatedData.macAlgorithm). This field is only populated if the attribute is placed in an AuthenticatedData.authAttrs sequence.</t>
</list></t>
<t>Exactly one of signatureAlgorithm and macAlgorithm SHALL be present.</t>
<t>An algorithm-protection attribute MUST have a single attribute value, even though the syntax is defined as a SET OF AttributeValue. There MUST NOT be zero or multiple instances of AttributeValue present.</t>
<t>The algorithm-protection attribute MUST be a signed attribute or an authenticated attribute; it MUST NOT be an unsigned attribute, an unauthenticated attribute or an unprotected attribute.</t>
<t>The SignedAttributes and AuthAttributes syntax are each defined as a SET of Attributes. The SignedAttributes in a signerInfo MUST include only one instance of the algorithm protection attribute. Similarly, the AuthAttributes in an AuthenticatedData MUST include only one instance of the algorithm protection attribute.</t>
</section>
<section title="Verification Process">
<t>
While the exact verification steps depends on the structure that is being validated, there are some common rules that are to be followed when comparing the two algorithm structures:
<list style="symbols">
<t>A field with a default value MUST compare as being the same independent of whether the value is defaulted or is explicitly provided.</t>
<t>It is implementation dependent if, for some algorithms, the absence of a parameter and the presence of a NULL parameter are compared as being equivalent. This behavior SHOULD NOT be expected. This is an issue because some implementations will omit a NULL element, while other will encode a NULL element for some digest algorithms such as SHA-1 (see the comments in section 2.1 of <xref target="RFC3370"/>). The issue is even worse because the NULL is absent in some cases (<xref target="RFC3370"/>), but is required in other cases (for example see <xref target="RFC4056"/>).
</t>
</list>
</t>
<section title="Signed Data Verification Changes">
<t>If a CMS validator supports this attribute, the following additional verification steps MUST be performed:</t>
<t>1. The SignerInfo.digestAlgorithm field MUST be compared to the digestAlgorithm field in the attribute. If the fields are not the same (modulo encoding) then signature validation MUST fail.</t>
<t>2. The SignerInfo.signatureAlgorithm field MUST be compared to the signatureAlgorithm field in the attribute. If the fields are not the same (modulo encoding) then the signature validation MUST fail.</t>
</section>
<section title="Authenticated Data Verification Changes">
<t>If a CMS validator supports this attribute, the following additional verification steps MUST be performed:</t>
<t>1. The AuthenticatedData.digestAlgorithm field MUST be compared to the digestAlgorithm field in the attribute. If the fields are not same (modulo encoding) then authentication MUST fail.</t>
<t>2. The AuthenticatedData.macAlgorithm field MUST be compared to the macAlgorithm field in the attribute. If the fields are not the same (modulo encoding) then the authentication MUST fail.</t>
</section>
</section>
<section title="IANA Considerations"><t>There are no IANA considerations. All identifiers are assigned out of the S/MIME OID arc.</t>
</section>
<section title="Security Considerations">
<t>This document is designed to address the security issue of algorithm substitutions of the algorithms used by the validator. At this time there is no known method to exploit this type of attack. If the attack could be successful, then either a weaker algorithm could be substituted for a stronger algorithm or the parameters could be modified by an attacker to change the behavior of the hashing algorithm used. (One example would be changing the initial parameter value for <xref target="XOR-HASH"/>.)</t>
<t>The attribute defined in this document is to be placed in a location that is protected by the signature or message authentication code. This attribute does not provide any additional security if placed in an un-signed or un-authenticated location.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc linefile="1:bibxml/reference.RFC.2119.xml"?>
<reference anchor='RFC2119'>
<front>
<title abbrev='RFC Key Words'>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='Scott Bradner'>
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street></postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email></address></author>
<date year='1997' month='March' />
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>
In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their document:
<list>
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119.
</t></list></t>
<t>
Note that the force of these words is modified by the requirement
level of the document in which they are used.
</t></abstract></front>
<seriesInfo name='BCP' value='14' />
<seriesInfo name='RFC' value='2119' />
<format type='TXT' octets='4723' target='http://www.rfc-editor.org/rfc/rfc2119.txt' />
<format type='HTML' octets='17491' target='http://xml.resource.org/public/rfc/html/rfc2119.html' />
<format type='XML' octets='5777' target='http://xml.resource.org/public/rfc/xml/rfc2119.xml' />
</reference>
<?rfc linefile="157:algorithm.xml"?>
<?rfc linefile="1:bibxml/reference.RFC.2634.xml"?>
<reference anchor='ESS-BASE'>
<front>
<title>Enhanced Security Services for S/MIME</title>
<author initials='P.' surname='Hoffman' fullname='Paul Hoffman'>
<organization>Internet Mail Consortium</organization>
<address>
<postal>
<street>127 Segre Place</street>
<city>Santa Cruz</city>
<region>CA</region>
<code>95060</code>
<country>US</country></postal>
<email>phoffman@imc.org</email></address></author>
<date year='1999' month='June' /></front>
<seriesInfo name='RFC' value='2634' />
<format type='TXT' octets='131153' target='http://www.rfc-editor.org/rfc/rfc2634.txt' />
</reference>
<?rfc linefile="158:algorithm.xml"?>
<?rfc linefile="1:bibxml/reference.RFC.5035.xml"?>
<reference anchor='RFC5035'>
<front>
<title>Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agility</title>
<author initials='J.' surname='Schaad' fullname='J. Schaad'>
<organization /></author>
<date year='2007' month='August' />
<abstract>
<t>In the original Enhanced Security Services for S/MIME document (RFC 2634), a structure for cryptographically linking the certificate to be used in validation with the signature was introduced; this structure was hardwired to use SHA-1. This document allows for the structure to have algorithm agility and defines a new attribute for this purpose. [STANDARDS TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='5035' />
<format type='TXT' octets='32674' target='http://www.rfc-editor.org/rfc/rfc5035.txt' />
</reference>
<?rfc linefile="159:algorithm.xml"?>
<?rfc linefile="1:bibxml/reference.RFC.5652.xml"?>
<reference anchor='CMS'>
<front>
<title>Cryptographic Message Syntax (CMS)</title>
<author initials='R.' surname='Housley' fullname='R. Housley'>
<organization /></author>
<date year='2009' month='September' />
<abstract>
<t>This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='5652' />
<format type='TXT' octets='126813' target='http://www.rfc-editor.org/rfc/rfc5652.txt' />
</reference>
<?rfc linefile="160:algorithm.xml"?>
<?rfc linefile="1:bibxml/reference.RFC.5912.xml"?>
<reference anchor='RFC5912'>
<front>
<title>New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)</title>
<author initials='P.' surname='Hoffman' fullname='P. Hoffman'>
<organization /></author>
<author initials='J.' surname='Schaad' fullname='J. Schaad'>
<organization /></author>
<date year='2010' month='June' />
<abstract>
<t>The Public Key Infrastructure using X.509 (PKIX) certificate format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes.</t></abstract></front>
<seriesInfo name='RFC' value='5912' />
<format type='TXT' octets='216154' target='http://www.rfc-editor.org/rfc/rfc5912.txt' />
</reference>
<?rfc linefile="161:algorithm.xml"?>
<reference anchor="ASN.1-2008">
<front>
<title>ITU-T Recommendations X.680, X.681, X.682, and X.683</title>
<author><organization>ITU-T</organization></author>
<date year="2008"/>
</front>
</reference>
</references>
<references title="Informational References">
<?rfc linefile="1:bibxml/reference.RFC.3370.xml"?>
<reference anchor='RFC3370'>
<front>
<title>Cryptographic Message Syntax (CMS) Algorithms</title>
<author initials='R.' surname='Housley' fullname='R. Housley'>
<organization /></author>
<date year='2002' month='August' /></front>
<seriesInfo name='RFC' value='3370' />
<format type='TXT' octets='51001' target='http://www.rfc-editor.org/rfc/rfc3370.txt' />
</reference>
<?rfc linefile="173:algorithm.xml"?>
<?rfc linefile="1:bibxml/reference.RFC.3447.xml"?>
<reference anchor='RFC3447'>
<front>
<title>Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1</title>
<author initials='J.' surname='Jonsson' fullname='J. Jonsson'>
<organization /></author>
<author initials='B.' surname='Kaliski' fullname='B. Kaliski'>
<organization /></author>
<date year='2003' month='February' />
<abstract>
<t>This memo represents a republication of PKCS #1 v2.1 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document is taken directly from the PKCS #1 v2.1 document, with certain corrections made during the publication process. This memo provides information for the Internet community.</t></abstract></front>
<seriesInfo name='RFC' value='3447' />
<format type='TXT' octets='143173' target='http://www.rfc-editor.org/rfc/rfc3447.txt' />
</reference>
<?rfc linefile="174:algorithm.xml"?>
<?rfc linefile="1:bibxml/reference.RFC.4056.xml"?>
<reference anchor='RFC4056'>
<front>
<title>Use of the RSASSA-PSS Signature Algorithm in Cryptographic Message Syntax (CMS)</title>
<author initials='J.' surname='Schaad' fullname='J. Schaad'>
<organization /></author>
<date year='2005' month='June' />
<abstract>
<t>This document specifies the conventions for using the RSASSA-PSS (RSA Probabilistic Signature Scheme) digital signature algorithm with the Cryptographic Message Syntax (CMS). [STANDARDS TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='4056' />
<format type='TXT' octets='11514' target='http://www.rfc-editor.org/rfc/rfc4056.txt' />
</reference>
<?rfc linefile="175:algorithm.xml"?>
<?rfc linefile="1:bibxml/reference.RFC.5280.xml"?>
<reference anchor='RFC5280'>
<front>
<title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
<author initials='D.' surname='Cooper' fullname='D. Cooper'>
<organization /></author>
<author initials='S.' surname='Santesson' fullname='S. Santesson'>
<organization /></author>
<author initials='S.' surname='Farrell' fullname='S. Farrell'>
<organization /></author>
<author initials='S.' surname='Boeyen' fullname='S. Boeyen'>
<organization /></author>
<author initials='R.' surname='Housley' fullname='R. Housley'>
<organization /></author>
<author initials='W.' surname='Polk' fullname='W. Polk'>
<organization /></author>
<date year='2008' month='May' />
<abstract>
<t>This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='5280' />
<format type='TXT' octets='352580' target='http://www.rfc-editor.org/rfc/rfc5280.txt' />
</reference>
<?rfc linefile="176:algorithm.xml"?>
<?rfc linefile="1:bibxml3/reference.I-D.draft-schaad-smime-hash-experiment-01.xml"?>
<reference anchor="XOR-HASH">
<front>
<title>Experiment: Hash functions with parameters in CMS and S/MIME</title>
<author initials='J' surname='Schaad' fullname='Jim Schaad'>
<organization />
</author>
<date month='January' day='24' year='2011' />
<abstract><t>New hash algorithms are being developed and these algorithms may include parameters. CMS has not currently defined any hash algorithms with parameters, but anecdotic evidence suggests that defining one could cause major problems. In this document we define just such an algorithm and describe how to use it so that we can run experiments to find out how bad including hash parameters will be.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-schaad-smime-hash-experiment-06' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-schaad-smime-hash-experiment-06.txt' />
</reference>
<?rfc linefile="177:algorithm.xml"?>
<reference anchor="RANDOM-HASH">
<front>
<title>Randomized Hashing: Secure Digital Signatures without Collision Resistance</title>
<author initials='S.' surname="Halevi"/>
<author initials='H.' surname="Krawczyk"/>
</front>
<seriesInfo name="IETF" value='74'/>
<format type='html' target='http://www.ietf.org/proceedings/74/slides/saag-4/saag-4_files/frame.htm'/>
</reference>
</references>
<section title="2008 ASN.1 Module">
<t>The ASN.1 module defined uses the 2008 ASN.1 definitions found in <xref target="ASN.1-2008"/>. This module contains the ASN.1 module which contains the required defintions for the types and values defined in this document. The module uses the ATTRIBUTE class defined in <xref target="RFC5912"/>.</t>
<?rfc linefile="1:ForDraft/algorithm.incl"?><figure><artwork>
CMSAlgorithmProtectionAttribute
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0)
id-mod-cms-algorithmProtect(52) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
-- Cryptographic Message Syntax (CMS) [CMS]
DigestAlgorithmIdentifier, MessageAuthenticationCodeAlgorithm,
SignatureAlgorithmIdentifier
FROM CryptographicMessageSyntax-2009
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-2004-02(41) }
-- Common PKIX structures [RFC5912]
ATTRIBUTE
FROM PKIX-CommonTypes-2009
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkixCommon-02(57)};
--
-- The CMS Algorithm Protection attribute is a Signed Attribute or
-- an Authenticated Attribute.
--
-- Add this attribute to SignedAttributesSet in [CMS]
-- Add this attribute to AuthAttributeSet in [CMS]
--
aa-cmsAlgorithmProtection ATTRIBUTE ::= {
TYPE CMSAlgorithmProtection
IDENTIFIED BY { id-aa-cmsAlgorithmProtect }
}
id-aa-cmsAlgorithmProtect OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs9(9) 52 }
CMSAlgorithmProtection ::= SEQUENCE {
digestAlgorithm DigestAlgorithmIdentifier,
signatureAlgorithm [1] SignatureAlgorithmIdentifier OPTIONAL,
macAlgorithm [2] MessageAuthenticationCodeAlgorithm
OPTIONAL
}
(WITH COMPONENTS { signatureAlgorithm PRESENT,
macAlgorithm ABSENT } |
WITH COMPONENTS { signatureAlgorithm ABSENT,
macAlgorithm PRESENT })
END
</artwork></figure>
<?rfc linefile="191:algorithm.xml"?>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 01:51:26 |