Network Working Group                                          J. Schaad
Internet-Draft                                   Soaring Hawk Consulting
Intended status: Experimental                                May 5, 2009
Expires: November 6, 2009

      Experiment: Hash functions with parameters in CMS and S/MIME

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on November 6, 2009.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Schaad                  Expires November 6, 2009                [Page 1]

Internet-Draft            CMS Paramertized Hash                 May 2009


   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.

Schaad                  Expires November 6, 2009                [Page 2]

Internet-Draft            CMS Paramertized Hash                 May 2009

1.  Introduction

   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 describes 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.

   In CMS data structures, hash algorithms current exist in the
   following locations:

   - SignerInfo.digestAlgorithm -- holds the digest algorithm actually
   used to compute the hash value over the content.

   - DigestedData.digestAlgorithm -- holds the digest algorithm actually
   used to compute the hash value over the content

   - AuthenticatedData.digestAlgorithm -- holds the digest algorithm
   actually used to compute the hash value over the content

   - SignedData.digestAlgorithms -- an optional location to place
   information about the set of digest algorithms used in computing the
   hash value over the content.

   - multipart/signed micalg - Holds a textual indicator of the hash
   algorithm for multipart signed MIME messages.

   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.

   DigestedData and AthenticatedData are defined such that in the case
   of encapsulated data, these fields are parsed before the content is
   parsed and thus the data is not needed until the parameters have been

   SignedData is defined such that even for the encapsulated data case,
   the value of SignerInfo.digestedAlgorithm 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.

   For the case of detached content, the ASN.1 structures need to be
   procssed prior to processing the detached content in order to obtain

Schaad                  Expires November 6, 2009                [Page 3]

Internet-Draft            CMS Paramertized Hash                 May 2009

   the parameters of the hash function.  In the case of MIME, this is
   the purpose of the micalg field on the multipart/signature content-

   When processing multipart/signed messages two paths exists:

   1.  Process the content before the ASN.1.  The steps involved are:

   - Get a set of hash functions by looking at the micalg parameter and
   potentially add a set of generic algorithms

   - Create a hasher for each of those algorithms

   - Hash the content (the first part of the multipart)

   - Process the ASN.1 and have a potential failure point if a hash
   algorithm is required which was not computed.

   2.  Process the content after the ASN.1.  The steps involved are:

   - Save the content for later processing

   - Parse the ASN.1 and build a list of hash functions based on it's

   - Create a hasher for each of those algorithms

   - Hash the saved content

   - Perform the signature validation.

   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.

   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 in the SignerInfos are
   determined.  It may be that we need to require population of the
   SignedData.digestAlgorithms field if we adopt a parameterized hash

   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

Schaad                  Expires November 6, 2009                [Page 4]

Internet-Draft            CMS Paramertized Hash                 May 2009

   in any way secure.  This hash function MUST NOT be released as
   shipping code, it is designed only for use in experimentation.

Schaad                  Expires November 6, 2009                [Page 5]

Internet-Draft            CMS Paramertized Hash                 May 2009

2.  XOR-MD5 Digest Algorithm

   The XOR-MD5 digest algorithm has been designed to use two existing
   operators, XOR and the MD5 hash algorithm [MD5].  The hash algorithm
   works as follows:

   1.  A random XOR string consisting of exactly 64 bytes is created.

   2.  The input content is broken up into 64 byte blocks.  The last
   block may be less that 64 bytes.

   3.  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.

   4.  The resulting string is run through the MD5 hash function.

   The length of the XOR string was designed to match the barrel size of
   the MD5 hash function.

Schaad                  Expires November 6, 2009                [Page 6]

Internet-Draft            CMS Paramertized Hash                 May 2009

3.  ASN.1 Encoding

   The following ASN.1 is used to define the algorithm:
mda-xor-md5 DIGEST-ALGORITHM ::= {    IDENTIFIER {tbd}    PARAMS OCTET STRING (64) ARE required }

   The octet string holds the value of the random XOR string.

Schaad                  Expires November 6, 2009                [Page 7]

Internet-Draft            CMS Paramertized Hash                 May 2009

4.  CMS ASN.1 Handling

   The algorithm is added to the DigestAlgorithmSet in [CMS].

   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.

Schaad                  Expires November 6, 2009                [Page 8]

Internet-Draft            CMS Paramertized Hash                 May 2009

5.  MIME handling

   This section defines the string that appears in the micalg parameter.

   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.
   Arbitrary amounts of white space may be inserted between any two
   characters in the hex encoded string.  An example content-type string
   would be:
Content-Type: multipart/signed; protocol="application/pkcs7-signature";          micalg=sha1, xor-md5:04400102030405060708090a0b0c0d0e0f00111213141          5161718191a1b1c1d1e1f102122232425262728292a2b2c2d2e2f2031323334353          63738393a3b3c3d3e3f30;          boundary=boundar42

   I debated if the string should be hex encoded rather than base64
   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.

   It may be reasonable to require that whitespace be inserted only on
   encoding boundaries, but it seems to be overly restrictive.

Schaad                  Expires November 6, 2009                [Page 9]

Internet-Draft            CMS Paramertized Hash                 May 2009

6.  Security Considerations

   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.

   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.

Schaad                  Expires November 6, 2009               [Page 10]

Internet-Draft            CMS Paramertized Hash                 May 2009

7.  Informational References

   [CMS]  Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852,
          July 2004.

Schaad                  Expires November 6, 2009               [Page 11]

Internet-Draft            CMS Paramertized Hash                 May 2009

Appendix A.  Examples

   The examples encoded in this document can be extracted using the perl
   script found in [CMS-EXAMPLES].  The certificates and key pairs found
   in that document are also used here.

Appendix A.1.  Encapsulated Signed Data Example

Appendix A.2.  Detached Signed Data Example

Appendix A.3.  Multipart Signed Message

Appendix A.4.  Digested Data Example

Appendix A.5.  Autenticated Data Example

Schaad                  Expires November 6, 2009               [Page 12]

Internet-Draft            CMS Paramertized Hash                 May 2009

Author's Address

   Jim Schaad
   Soaring Hawk Consulting
   PO Box 675
   Gold Bar, WA  98251


Schaad                  Expires November 6, 2009               [Page 13]