One document matched: draft-schaad-smime-hash-experiment-06.xml
<?xml version="1.0" encoding="UTF-8"?><?rfc linefile="1:schaad-hash.xml"?>
<!-- automatically generated by xml2rfc v1.35 on 2011-01-25T01:13:14Z -->
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<!-- xml2rfc-processed-entity RFC2119 -->
<!-- xml2rfc-processed-entity RFC2231 -->
<!-- xml2rfc-processed-entity rfc4134 -->
<!-- xml2rfc-processed-entity rfc5652 -->
<!-- xml2rfc-processed-entity rfc1321 -->
<!-- xml2rfc-processed-entity rfc5911 -->
<!-- xml2rfc-processed-entity rfc5912 -->
<!-- xml2rfc-processed-entity md5-asn -->
<!-- xml2rfc-processed-entity smime -->
<?rfc linefile="1:bibxml/smime.xml"?> <!-- xml2rfc-processed-entity ESS-BASE -->
<!-- xml2rfc-processed-entity CMS -->
<!-- xml2rfc-processed-entity CMS-ASN -->
<!-- xml2rfc-processed-entity CMS-AED -->
<!-- xml2rfc-processed-entity SMIME-MSG -->
<!-- xml2rfc-processed-entity AED-RANT -->
<!-- xml2rfc-processed-entity XOR-HASH -->
<!-- xml2rfc-processed-entity SMIMEv3-MSG -->
<!-- xml2rfc-processed-entity SMIME-MSG -->
<?rfc linefile="13:schaad-hash.xml"?>
<rfc ipr="trust200902" docName="draft-schaad-smime-hash-experiment-06" category="exp">
<front>
<title abbrev="CMS Parameterized Hash">Experiment: Hash functions with parameters in CMS and S/MIME</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>New hash algorithms are being developed and these algorithms may include parameters. CMS has not currently defined any hash algorithms with parameters, but anecdotal 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>
<middle>
<section title="Introduction">
<t>At the present time, all hash algorithms that are used in Cryptographic Message Syntax (CMS) implementations are defined as having no parameters. Anecdotal evidence suggests that if a hash algorithm is defined that does require the presence of parameters there may be extensive problems. This document presents the details needed to run an experiment so that we can find out just how bad the situation really is and, if we need to, either make drastic changes in implementations or make sure that any hash algorithms chosen do not have parameters.</t>
<t>In CMS data structures, hash algorithms currently exist in the following locations:
<list style="symbols">
<t>SignerInfo.digestAlgorithm -- holds the digest algorithm used to compute the hash value over the content.</t>
<t>DigestedData.digestAlgorithm -- holds the digest algorithm used to compute the hash value over the content</t>
<t>AuthenticatedData.digestAlgorithm -- holds the digest algorithm used to compute the hash value over the content</t>
<t>SignedData.digestAlgorithms -- an optional location to place information about the set of digest algorithms used in computing the hash value over the content.</t>
<t>multipart/signed micalg - Holds a textual indicator of the hash algorithm for multipart signed MIME messages.</t>
</list>
</t>
<t>The first three locations hold the identification of a single hash, and would hold the parameters for that hash. These fields are mandatory to be filled in.</t>
<t>The ASN.1 defined for the types DigestedData and AuthenticatedData are defined by placing the digest algorithm before the encapsulated data. This means that the hash algorithm (including the parameters) is fully defined before the hash function would start hashing the encapsulated data.</t>
<t>In the ASN.1 defined for the SignedData type, the value of SignerInfo.digestAlgorithm is not seen until the content has been processed. This is the reason for the existence of the SignedData.digestAlgorithms field, so that the set of all digest algorithms used can be seen prior to the content being processed. It is not currently a mandatory to fill in this field, and the signature validation process is supposed to succeed even if this field is absent. (RFC 5652 says signature validation MAY fail if the digest algorithm is absent.)</t>
<t>For the case of detached content, the ASN.1 structures need to be processed before processing the detached content in order to obtain the parameters of the hash function. The MIME multipart/signature content type attempts to avoid this problem by defining a micalg field which contains the set of hash algorithms (with parameters) so that the hash functions can be setup prior to processing the content.</t>
<t>When processing multipart/signed messages two paths exists:
<list style="numbers">
<t>Process the message content before the ASN.1. The steps involved are:
<list style="symbols">
<t>Get a set of hash functions by looking at the micalg parameter and potentially add a set of generic algorithms</t>
<t>Create a hasher for each of those algorithms</t>
<t>Hash the message content (the first part of the multipart)</t>
<t>Process the ASN.1 and have a potential failure point if a hash algorithm is required which was not computed.</t>
</list></t>
<t>Process the message content after the ASN.1. The steps involved are:
<list style="symbols">
<t>Save the message content for later processing</t>
<t>Parse the ASN.1 and build a list of hash functions based on it's content</t>
<t>Create a hasher for each of those algorithms</t>
<t>Hash the saved message content</t>
<t>Perform the signature validation.</t>
</list>
</t>
</list></t>
<t>The first path allows for single pass processing, but has the potential that a fallback path needs to be added in some cases. The second path does not need a fallback path, but does not allow for single pass processing.</t>
<t>The fallback path above may also be needed for the encapsulated content case. Since it is optional to place hash algorithms in the SignedData.digestAlgorithms field, the content will be completely parsed before the set of hash algorithms used in the various SignerInfo structures are determined. It may be that we need to require population of the SignedData.digestAlgorithms field if we adopt a parameterized hash field.</t>
<t>In this document a new hash function is created that is based on the XOR operator and on MD5. MD5 was deliberately used as the basis of this digest algorithm since it is known to be insecure and I do not want to make any statements that the hash algorithm designed here is in any way secure. This hash function MUST NOT be released as shipping code, it is designed only for use in experimentation. An example of a parameterized hash algorithm that might be standardized is a scheme developed by Shai Halevi and others <xref target="Random-Hash"/>.</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="XOR-MD5 Digest Algorithm">
<t>The XOR-MD5 digest algorithm has been designed to use two existing operators, XOR and the MD5 hash algorithm <xref target="MD5"/>. The hash algorithm works as follows:
<list style="numbers">
<t>A random XOR string consisting of exactly 64 bytes is created.</t>
<t>The input content is broken up into 64 byte blocks. The last block may be less that 64 bytes.</t>
<t>Each block is XOR-ed with the random string. The last block uses the same number of bits from the random string as it contains.</t>
<t>The resulting string is run through the MD5 hash function.</t>
</list>
</t>
<t>The length of the XOR string was designed to match the barrel size of the MD5 hash function.</t>
</section>
<section title="ASN.1 Encoding">
<t>The following ASN.1 is used to define the algorithm:</t>
<figure>
<artwork>
mda-xor-md5-EXPERIMENT DIGEST-ALGORITHM ::= {
IDENTIFIER id-alg-MD5-XOR-EXPERIMENT
PARAMS TYPE MD5-XOR-EXPERIMENT ARE required
}
id-alg-MD5-XOR-EXPERIMENT OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) id-alg(3) 13
}
MD5-XOR-EXPERIMENT ::= OCTET STRING (SIZE(64))
</artwork>
</figure>
<t>The octet string holds the value of the random XOR string.</t>
</section>
<section title="CMS ASN.1 Handling">
<t>The algorithm is added to the DigestAlgorithmSet in <xref target="CMS"/>.</t>
<t>When this algorithm is used in a signed message, it is REQUIRED that the algorithm be placed in the SignedData.digestAlgorithms sequence. The algorithm MUST appear in the sequence at least once for each unique set of parameters. The algorithm SHOULD NOT appear multiple times with the same set of parameters.</t>
</section>
<section title="MIME handling">
<t>This section defines the string that appears in the micalg parameter.</t>
<t>The algorithm is identified by the string xor-md5. The parameters for the algorithm are the hex encoded DER ASN.1 encoding. The parameters and the identifier string are separated by a colon. One of the issues that needs to be addressed is the fact this this will generate very long data values for parameters. These will be too long for many systems to deal with. The issue of how to deal with this has been addressed by creating a method to fragment values in <xref target="RFC2231"/>.
An example content-type string that has been fragmented is:</t>
<figure>
<artwork>
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg*0="sha1, xor-md5:04400102030405060708090a0b0c0d0e0f0011";
micalg*1="12131415161718191a1b1c1d1e1f102122232425262728292a2b";
micalg*2="2c2d2e2f203132333435363738";
micalg*3="393a3b3c3d3e3f30"; boundary=boundar42
</artwork>
</figure>
<t>Arguments could be made that the string should be base64 encoded rather than hex encoding the string. The advantage is that the resulting encoding is shorter. This could be significant if there are a substantial number of parameters and of a substantial size. Even with the above example we needed to break the encoding across multiple lines. The downside would be the requirement that the micalg parameter always be quoted.</t>
<t>It may be reasonable to require that whitespace be inserted only on encoding boundaries, but it seems to be overly restrictive.</t>
</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>The algorithm XOR-MD5 is not designed for general purpose use. The hash algorithm included here is designed for running this experiment and nothing more.</t>
<t>This document makes no representation that XOR-MD5 is a secure digest algorithm. I believe that the algorithm is no more secure than MD5, and I consider MD5 to be a broken hash algorithm for many purposes.</t>
<t>One known issue with the algorithm as present is the fact that the xor pattern is always 64 bytes long, even if the data is shorter. This means that there is a section of the data than can be manipulated without changing the hash. In a real algorithm this should either be truncated or forced to a known value.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc linefile="1:bibxml/reference.RFC.1321.xml"?>
<reference anchor='MD5'>
<front>
<title abbrev='MD5 Message-Digest Algorithm'>The MD5 Message-Digest Algorithm</title>
<author initials='R.' surname='Rivest' fullname='Ronald L. Rivest'>
<organization>Massachusetts Institute of Technology, (MIT) Laboratory for Computer Science</organization>
<address>
<postal>
<street>545 Technology Square</street>
<street>NE43-324</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139-1986</code>
<country>US</country></postal>
<phone>+1 617 253 5880</phone>
<email>rivest@theory.lcs.mit.edu</email></address></author>
<date year='1992' month='April' /></front>
<seriesInfo name='RFC' value='1321' />
<format type='TXT' octets='35222' target='http://www.rfc-editor.org/rfc/rfc1321.txt' />
</reference>
<?rfc linefile="132:schaad-hash.xml"?>
<?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="133:schaad-hash.xml"?>
<?rfc linefile="1:bibxml/reference.RFC.2231.xml"?>
<reference anchor='RFC2231'>
<front>
<title abbrev='MIME Value and Encoded Word Extensions'>MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations</title>
<author initials='N.' surname='Freed' fullname='Ned Freed'>
<organization abbrev='Innosoft'>Innosoft International, Inc.</organization>
<address>
<postal>
<street>1050 Lakes Drive</street>
<street>West Covina</street>
<street>CA 91790</street>
<country>USA</country></postal>
<phone>+1 626 919 3600</phone>
<facsimile>+1 626 919 3614</facsimile>
<email>ned.freed@innosoft.com</email></address></author>
<author initials='K.' surname='Moore' fullname='Keith Moore'>
<organization>University of Tennessee</organization>
<address>
<postal>
<street>Computer Science Dept.</street>
<street>107 Ayres Hall</street>
<street>Knoxville</street>
<street>TN 37996-1301</street>
<country>USA</country></postal>
<email>moore@cs.utk.edu</email></address></author>
<date year='1997' month='November' />
<area>Applications</area>
<keyword>MIME</keyword>
<keyword>character encoding</keyword>
<keyword>media type</keyword>
<keyword>multipurpose internet mail extensions</keyword></front>
<seriesInfo name='RFC' value='2231' />
<format type='TXT' octets='19280' target='http://www.rfc-editor.org/rfc/rfc2231.txt' />
<format type='HTML' octets='32801' target='http://xml.resource.org/public/rfc/html/rfc2231.html' />
<format type='XML' octets='28825' target='http://xml.resource.org/public/rfc/xml/rfc2231.xml' />
</reference>
<?rfc linefile="134:schaad-hash.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="135:schaad-hash.xml"?>
<?rfc linefile="1:bibxml/reference.RFC.5751.xml"?>
<reference anchor="SMIME-MSG">
<front>
<title>Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification</title>
<author initials='B.' surname='Ramsdell' fullname='B. Ramsdell'>
<organization /></author>
<author initials='S.' surname='Turner' fullname='S. Turner'>
<organization /></author>
<date year='2010' month='January' />
<abstract>
<t>This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 3.2. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 3851. [STANDARDS TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='5751' />
<format type='TXT' octets='98638' target='http://www.rfc-editor.org/rfc/rfc5751.txt' />
</reference>
<?rfc linefile="136:schaad-hash.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">
&rfc1847;
<?rfc linefile="1:bibxml/reference.RFC.4134.xml"?>
<reference anchor='SMIME-EXAMPLES'>
<front>
<title>Examples of S/MIME Messages</title>
<author initials='P.' surname='Hoffman' fullname='P. Hoffman'>
<organization /></author>
<date year='2005' month='July' />
<abstract>
<t>This document gives examples of message bodies formatted using S/MIME. Specifically, it has examples of Cryptographic Message Syntax (CMS) objects and S/MIME messages (including the MIME formatting). It includes examples of many common CMS formats. The purpose of this document is to help increase interoperability for S/MIME and other protocols that rely on CMS. This memo provides information for the Internet community.</t></abstract></front>
<seriesInfo name='RFC' value='4134' />
<format type='TXT' octets='325865' target='http://www.rfc-editor.org/rfc/rfc4134.txt' />
</reference>
<?rfc linefile="147:schaad-hash.xml"?>
<?rfc linefile="1:bibxml/reference.RFC.5911.xml"?>
<reference anchor="CMS-ASN">
<front>
<title>New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME</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 Cryptographic Message Syntax (CMS) 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='5911' />
<format type='TXT' octets='101576' target='http://www.rfc-editor.org/rfc/rfc5911.txt' />
</reference>
<?rfc linefile="148:schaad-hash.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="149:schaad-hash.xml"?>
<reference anchor="Random-Hash">
<front>
<title>Implementing the Halevi-Krawczyk Randomized Hashing Scheme</title>
<author initials="S." surname="Halevi"/>
<author initials="W." surname="Shao"/>
<author initials="H." surname="Krawczyk"/>
<author initials="D." surname="Boneh"/>
<author initials="M." surname="McIntosh"/>
</front>
<format type="pdf" target="http://webee.technion.ac.il/~hugo/rhash/implementation.pdf"/>
</reference>
</references>
<section title="Examples">
<t>Provided here are a set of simple S/MIME messages <xref target="SMIME-MSG"/> that are provided for testing. The content used is the same as that found in Section 2.1 of <xref target="SMIME-EXAMPLES"/>. The certificates and key pairs found in <xref target="SMIME-EXAMPLES"/> are also used here.</t>
<t>The perl script in Appendix A of <xref target="SMIME-EXAMPLES"/> can be used to extract the binary examples from this file. The mime examples can be extracted with a standard text editor.</t>
<t>Note: The examples presented here have not been independently verified. I was unable to use the Microsoft APIs because of the new cryptographic hash algorithm. However, for the purposes of this experiment I believe that the form of the messages, which can be verified visually as correct, is more important than the question of the message validating.</t>
<t>NOTE FOR RFC EDITOR: The | character needs to be in column #1 in order for the extraction script to work. I would suggest that all of the examples below (inside of the artwork) start in column #1.</t>
<section title="Encapsulated Signed Data Example">
<t>
This section contains a detached signed data example. The content was hashed with the md5-xor algorithm defined in this document. The signature is performed using RSA with MD5. The signature is wrapped as an embedded signed mime message.
</t>
<figure>
<artwork>
MIME-Version: 1.0
To: BobRSA@example.com
From: AliceDss@example.com
Subject: MD5-XOR example message
Message-Id: <34567809323489fd.esc@example.com>
Date: Wed, 16 Dec 2010 23:13:00 -0500
Content-Type: application/pkcs7-mime; smime-type=signed-data;
name=smime.p7m;
micalg*0="xor-md5: 0440010203405060708090a0b0c0d0e0f10";
micalg*1="111213415161718191a1b1c1d1e1f20212223425262728292a2b2c";
micalg*2="2d2e2f30313233435363738393a3b3c3d3e3f40"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m
MIIEqAYJKoZIhvcNAQcCoIIEmTCCBJUCAQExUTBPBgsqhkiG9w0BCRADDQRAAQIDBAUGBw
gJCgsMDQ4PEBESEwQVFhcYGRobHB0eHyAhIiMEJSYnKCkqKywtLi8wMTIzBDU2Nzg5Ojs8
PT4/QDArBgkqhkiG9w0BBwGgHgQcVGhpcyBpcyBzb21lIHNhbXBsZSBjb250ZW50LqCCAi
swggInMIIBkKADAgECAhBGNGvHgABWvBHTbi7NXXHQMA0GCSqGSIb3DQEBBQUAMBIxEDAO
BgNVBAMTB0NhcmxSU0EwHhcNOTkwOTE5MDEwOTAyWhcNMzkxMjMxMjM1OTU5WjARMQ8wDQ
YDVQQDEwZCb2JSU0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKnhZ5g/OdVf8qCT
QV6meYmFyDVdmpFb+x0B2hlwJhcPvaUi0DWFbXqYZhRBXM+3twg7CcmRuBlpN235ZR572a
kzJKN/O7uvRgGGNjQyywcDWVL8hYsxBLjMGAgUSOZPHPtdYMTgXB9T039T2GkB8QX4enDR
voPGXzjPHCyqaqfrAgMBAAGjfzB9MAwGA1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQDAgUgMB
8GA1UdIwQYMBaAFOngkCeseCB6mtNM8kI3TiKunji7MB0GA1UdDgQWBBTo9Lhn2LOWpCrz
Eaop05Vahha0JDAdBgNVHREEFjAUgRJCb2JSU0FAZXhhbXBsZS5jb20wDQYJKoZIhvcNAQ
EFBQADgYEAe45mxfEQPxAgTIhxq3tAayEz+kqV3p0OW2uUIQXA8uF+Ks2ck4iH+4u3fn1B
YeHk1m354gRVYUW8ZCdEwKG9WXnZHWQ8IdZFsF1oM5LqrPFX5YF9mOY1kaM53nf06Bw7Kd
x/UQeX8zbwUArdm962XjgRK/tX6oltrcmI2I/PK9MxggHfMIIB2wIBATAmMBIxEDAOBgNV
BAMTB0NhcmxSU0ECEEY0a8eAAFa8EdNuLs1dcdAwTwYLKoZIhvcNAQkQAw0EQAECAwQFBg
cICQoLDA0ODxAREhMEFRYXGBkaGxwdHh8gISIjBCUmJygpKissLS4vMDEyMwQ1Njc4OTo7
PD0+P0CggcowGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMD
kxMjEwMjMyNTAwWjAfBgkqhkiG9w0BCQQxEgQQlmmuYRtXnoPqECtrSd3A+TBvBgkqhkiG
9w0BCTQxYjBgME8GCyqGSIb3DQEJEAMNBEABAgMEBQYHCAkKCwwNDg8QERITBBUWFxgZGh
scHR4fICEiIwQlJicoKSorLC0uLzAxMjMENTY3ODk6Ozw9Pj9AoQ0GCSqGSIb3DQEBBAUA
MA0GCSqGSIb3DQEBBAUABIGAClMpfG4IL1yAdRxWdvYKbtuFz1XKnFqo9ui7V5PndjlDut
yib02knY7UtGNhg6oVEkiZHxYh/iLuoLOHSFA1P4ZacTYrEKChF4K18dsqvlFip1vn8BG/
ysFUDfbx5VcTG2Md0/NHV+qj5ihqM+Pye6Urp+5jbqVgpZOXSLfP+pI=
|>sd.bin
|MIIEqAYJKoZIhvcNAQcCoIIEmTCCBJUCAQExUTBPBgsqhkiG9w0BCRADDQRAAQIDBAUGBw
|gJCgsMDQ4PEBESEwQVFhcYGRobHB0eHyAhIiMEJSYnKCkqKywtLi8wMTIzBDU2Nzg5Ojs8
|PT4/QDArBgkqhkiG9w0BBwGgHgQcVGhpcyBpcyBzb21lIHNhbXBsZSBjb250ZW50LqCCAi
|swggInMIIBkKADAgECAhBGNGvHgABWvBHTbi7NXXHQMA0GCSqGSIb3DQEBBQUAMBIxEDAO
|BgNVBAMTB0NhcmxSU0EwHhcNOTkwOTE5MDEwOTAyWhcNMzkxMjMxMjM1OTU5WjARMQ8wDQ
|YDVQQDEwZCb2JSU0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKnhZ5g/OdVf8qCT
|QV6meYmFyDVdmpFb+x0B2hlwJhcPvaUi0DWFbXqYZhRBXM+3twg7CcmRuBlpN235ZR572a
|kzJKN/O7uvRgGGNjQyywcDWVL8hYsxBLjMGAgUSOZPHPtdYMTgXB9T039T2GkB8QX4enDR
|voPGXzjPHCyqaqfrAgMBAAGjfzB9MAwGA1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQDAgUgMB
|8GA1UdIwQYMBaAFOngkCeseCB6mtNM8kI3TiKunji7MB0GA1UdDgQWBBTo9Lhn2LOWpCrz
|Eaop05Vahha0JDAdBgNVHREEFjAUgRJCb2JSU0FAZXhhbXBsZS5jb20wDQYJKoZIhvcNAQ
|EFBQADgYEAe45mxfEQPxAgTIhxq3tAayEz+kqV3p0OW2uUIQXA8uF+Ks2ck4iH+4u3fn1B
|YeHk1m354gRVYUW8ZCdEwKG9WXnZHWQ8IdZFsF1oM5LqrPFX5YF9mOY1kaM53nf06Bw7Kd
|x/UQeX8zbwUArdm962XjgRK/tX6oltrcmI2I/PK9MxggHfMIIB2wIBATAmMBIxEDAOBgNV
|BAMTB0NhcmxSU0ECEEY0a8eAAFa8EdNuLs1dcdAwTwYLKoZIhvcNAQkQAw0EQAECAwQFBg
|cICQoLDA0ODxAREhMEFRYXGBkaGxwdHh8gISIjBCUmJygpKissLS4vMDEyMwQ1Njc4OTo7
|PD0+P0CggcowGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMD
|kxMjEwMjMyNTAwWjAfBgkqhkiG9w0BCQQxEgQQlmmuYRtXnoPqECtrSd3A+TBvBgkqhkiG
|9w0BCTQxYjBgME8GCyqGSIb3DQEJEAMNBEABAgMEBQYHCAkKCwwNDg8QERITBBUWFxgZGh
|scHR4fICEiIwQlJicoKSorLC0uLzAxMjMENTY3ODk6Ozw9Pj9AoQ0GCSqGSIb3DQEBBAUA
|MA0GCSqGSIb3DQEBBAUABIGAClMpfG4IL1yAdRxWdvYKbtuFz1XKnFqo9ui7V5PndjlDut
|yib02knY7UtGNhg6oVEkiZHxYh/iLuoLOHSFA1P4ZacTYrEKChF4K18dsqvlFip1vn8BG/
|ysFUDfbx5VcTG2Md0/NHV+qj5ihqM+Pye6Urp+5jbqVgpZOXSLfP+pI=
|<sd.bin
</artwork>
</figure>
</section>
<section title="Multipart Signed Message">
<t>
This section contains a detached signed data example. The content was hashed with the md5-xor algorithm defined in this document. The signature is performed using RSA with MD5. The signature is wrapped as a detached signed mime message.
</t>
<figure>
<artwork>
MIME-Version: 1.0
To: User2@example.com
From: BobRSA@example.com
Subject: MD5-XOR signing example
Message-Id: <091218002550300.249@example.com>
Date: Fri, 18 Dec 2010 00:25:21 -0300
Content-Type: multipart/signed;
micalg*0="xor-md5: 0440010203405060708090a0b0c0d0e0f10";
micalg*1="111213415161718191a1b1c1d1e1f20212223425262728292a2b2c2d2e";
micalg*2="2f30313233435363738393a3b3c3d3e3f40";
boundary="----=_NextBoundry____Fri,_18_Dec_2009_00:25:21";
protocol="application/pkcs7-signature"
This is a multi-part message in MIME format.
------=_NextBoundry____Fri,_18_Dec_2009_00:25:21
This is some sample content.
------=_NextBoundry____Fri,_18_Dec_2009_00:25:21
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s
MIIEiAYJKoZIhvcNAQcCoIIEeTCCBHUCAQExUTBPBgsqhkiG9w0BCRADDQRAAQIDBAUGBw
gJCgsMDQ4PEBESEwQVFhcYGRobHB0eHyAhIiMEJSYnKCkqKywtLi8wMTIzBDU2Nzg5Ojs8
PT4/QDALBgkqhkiG9w0BBwGgggIrMIICJzCCAZCgAwIBAgIQRjRrx4AAVrwR024uzV1x0D
ANBgkqhkiG9w0BAQUFADASMRAwDgYDVQQDEwdDYXJsUlNBMB4XDTk5MDkxOTAxMDkwMloX
DTM5MTIzMTIzNTk1OVowETEPMA0GA1UEAxMGQm9iUlNBMIGfMA0GCSqGSIb3DQEBAQUAA4
GNADCBiQKBgQCp4WeYPznVX/Kgk0FepnmJhcg1XZqRW/sdAdoZcCYXD72lItA1hW16mGYU
QVzPt7cIOwnJkbgZaTdt+WUee9mpMySjfzu7r0YBhjY0MssHA1lS/IWLMQS4zBgIFEjmTx
z7XWDE4FwfU9N/U9hpAfEF+Hpw0b6Dxl84zxwsqmqn6wIDAQABo38wfTAMBgNVHRMBAf8E
AjAAMA4GA1UdDwEB/wQEAwIFIDAfBgNVHSMEGDAWgBTp4JAnrHggeprTTPJCN04irp44uz
AdBgNVHQ4EFgQU6PS4Z9izlqQq8xGqKdOVWoYWtCQwHQYDVR0RBBYwFIESQm9iUlNBQGV4
YW1wbGUuY29tMA0GCSqGSIb3DQEBBQUAA4GBAHuOZsXxED8QIEyIcat7QGshM/pKld6dDl
trlCEFwPLhfirNnJOIh/uLt359QWHh5NZt+eIEVWFFvGQnRMChvVl52R1kPCHWRbBdaDOS
6qzxV+WBfZjmNZGjOd539OgcOyncf1EHl/M28FAK3Zvetl44ESv7V+qJba3JiNiPzyvTMY
IB3zCCAdsCAQEwJjASMRAwDgYDVQQDEwdDYXJsUlNBAhBGNGvHgABWvBHTbi7NXXHQME8G
CyqGSIb3DQEJEAMNBEABAgMEBQYHCAkKCwwNDg8QERITBBUWFxgZGhscHR4fICEiIwQlJi
coKSorLC0uLzAxMjMENTY3ODk6Ozw9Pj9AoIHKMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTIxMDIzMjUwMFowHwYJKoZIhvcNAQkEMRIEEJZprm
EbV56D6hAra0ndwPkwbwYJKoZIhvcNAQk0MWIwYDBPBgsqhkiG9w0BCRADDQRAAQIDBAUG
BwgJCgsMDQ4PEBESEwQVFhcYGRobHB0eHyAhIiMEJSYnKCkqKywtLi8wMTIzBDU2Nzg5Oj
s8PT4/QKENBgkqhkiG9w0BAQQFADANBgkqhkiG9w0BAQQFAASBgEDMeyAkXMYqg/wW2B3P
i8HWwGnZVA/4muJJ7+dEPacv3bRqE7n4dP0vXIYR7TJ1eRJk9uB/wry2fRPcnG3Y/Rn0Jy
CqXsb+dXXfwOGK/rvLvJOloXUCy4+HxQk6eaYIBrjiVIUgZjpZXGJcZg2xq5yH1e4aw5Ov
fQlfQXPiKp1l
------=_NextBoundry____Fri,_18_Dec_2009_00:25:21--
</artwork>
</figure>
</section>
<section title="Authenticated Data Example">
<t>This section contains an authenticated data example. The content was hashed with the md5-xor algorithm defined in this document. The authentication was done with the HMAC-SHA1 algorithm. The key is transported using RSA encryption to BobRSASignByCarl certificate.</t>
<figure>
<artwork>
MIME-Version: 1.0
To: BobRSA@example.com
From: AliceDss@example.com
Subject: MD5-XOR example message
Message-Id: <34567809323489fd.esc@example.com>
Date: Wed, 16 Dec 2010 23:13:00 -0500
Content-Type: application/pkcs7-mime; smime-type=authenticated-data;
name=smime.p7m;
micalg*0="xor-md5: 0440010203405060708090a0b0c0d0e0f10";
micalg*1="111213415161718191a1b1c1d1e1f20212223425262728292a2b2c2d2e";
micalg*2="2f30313233435363738393a3b3c3d3e3f40"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m
MIICRQYLKoZIhvcNAQkQAQKgggI0MIICMAIBADGBwDCBvQIBADAmMBIxEDAOBgNVBAMMB0
NhcmxSU0ECEEY0a8eAAFa8EdNuLs1dcdAwDQYJKoZIhvcNAQEBBQAEgYCH70EpEikY7deb
859YJRAWfFondQv1D4NFltw6C1ceheWnlAU0C2WEXr3LUBXZp1/PSte29FnJxu5bXCTn1g
elMm6zNlZNWNd0KadVBcaxi1n8L52tVM5sWFGJPO5cStOyAka2ucuZM6iAnCSkn1Ju7fgU
5j2g3bZ/IM8nHTcygjAKBggrBgEFBQgBAqFPBgsqhkiG9w0BCRADDQRAAQIDBAUGBwgJCg
sMDQ4PEBESEwQVFhcYGRobHB0eHyAhIiMEJSYnKCkqKywtLi8wMTIzBDU2Nzg5Ojs8PT4/
QDArBgkqhkiG9w0BBwGgHgQcVGhpcyBpcyBzb21lIHNhbXBsZSBjb250ZW50LqKBxzAYBg
kqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTEyMTAyMzI1MDBa
MB8GCSqGSIb3DQEJBDESBBCWaa5hG1eeg+oQK2tJ3cD5MGwGCSqGSIb3DQEJNDFfMF0wTw
YLKoZIhvcNAQkQAw0EQAECAwQFBgcICQoLDA0ODxAREhMEFRYXGBkaGxwdHh8gISIjBCUm
JygpKissLS4vMDEyMwQ1Njc4OTo7PD0+P0CiCgYIKwYBBQUIAQIEFLjUxQ9PJFzFnWraxb
EIbVbg2xql
|>ad.bin
|MIICRQYLKoZIhvcNAQkQAQKgggI0MIICMAIBADGBwDCBvQIBADAmMBIxEDAOBgNVBAMMB0
|NhcmxSU0ECEEY0a8eAAFa8EdNuLs1dcdAwDQYJKoZIhvcNAQEBBQAEgYCH70EpEikY7deb
|859YJRAWfFondQv1D4NFltw6C1ceheWnlAU0C2WEXr3LUBXZp1/PSte29FnJxu5bXCTn1g
|elMm6zNlZNWNd0KadVBcaxi1n8L52tVM5sWFGJPO5cStOyAka2ucuZM6iAnCSkn1Ju7fgU
|5j2g3bZ/IM8nHTcygjAKBggrBgEFBQgBAqFPBgsqhkiG9w0BCRADDQRAAQIDBAUGBwgJCg
|sMDQ4PEBESEwQVFhcYGRobHB0eHyAhIiMEJSYnKCkqKywtLi8wMTIzBDU2Nzg5Ojs8PT4/
|QDArBgkqhkiG9w0BBwGgHgQcVGhpcyBpcyBzb21lIHNhbXBsZSBjb250ZW50LqKBxzAYBg
|kqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTEyMTAyMzI1MDBa
|MB8GCSqGSIb3DQEJBDESBBCWaa5hG1eeg+oQK2tJ3cD5MGwGCSqGSIb3DQEJNDFfMF0wTw
|YLKoZIhvcNAQkQAw0EQAECAwQFBgcICQoLDA0ODxAREhMEFRYXGBkaGxwdHh8gISIjBCUm
|JygpKissLS4vMDEyMwQ1Njc4OTo7PD0+P0CiCgYIKwYBBQUIAQIEFLjUxQ9PJFzFnWraxb
|EIbVbg2xql
|<ad.bin
</artwork>
</figure>
</section>
</section>
<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 class defined in <xref target="CMS-ASN"/> and <xref target="RFC5912"/>.</t>
<?rfc linefile="1:ForDraft/md5.incl"?><figure><artwork>
MD5-HASH-EXPERIMENT
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0)
id-mod-MD5-XOR-EXPERIMENT(999) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
-- Cryptographic Message Syntax (CMS) [CMS]
DigestAlgorithmIdentifier, MessageAuthenticationCodeAlgorithm,
SignatureAlgorithmIdentifier, DIGEST-ALGORITHM
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)};
mda-xor-md5-EXPERIMENT DIGEST-ALGORITHM ::= {
IDENTIFIER id-alg-MD5-XOR-EXPERIMENT
PARAMS TYPE MD5-XOR-EXPERIMENT ARE required
}
id-alg-MD5-XOR-EXPERIMENT OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) id-alg(3) 13
}
MD5-XOR-EXPERIMENT ::= OCTET STRING (SIZE(64))
END
</artwork></figure>
<?rfc linefile="347:schaad-hash.xml"?>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 03:06:20 |