Experiment: Hash Functions with Parameters in the Cryptographic Message Syntax (CMS) and S/MIME
RFC 6210

[Ballot discuss]
[Updated.]

I generally support this experiment. However the MIME section contains several errors that need to be fixed before this document can be approved:

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

I don't believe this comment is correct according to MIME, you should be using the mechanism defined in RFC 2231.


Note that according to RFC 2045, Section 5.1:

    content := "Content-Type" ":" type "/" subtype
                *(";" parameter)
                ; Matching of media type and subtype
                ; is ALWAYS case-insensitive.

So every parameter except for the last one must be followed by a ";" and RFC 2231 doesn't change that.
So the example in Section 5 becomes (also see a couple of extra errors):

Content-Type: multipart/signed;
    protocol="application/pkcs7-signature"; micalg*0="sha1, xor-md5:04";
    micalg*1="400102030405060708090a0b0c0d0e0f001112131415161718191a1b1";
    micalg*1="c1d1e1f102122232425262728292a2b2c2d2e2f203132333435363738";
              ^ should be "2"
    micalg*2="393a3b3c3d3e3f30";  boundary=boundar42
              ^ should be "3"

Also please check everywhere else in the document! I found multiple spots where this is a problem.

[Ballot discuss]
There are many algorithm identifiers that specify a hash algorithm and
  a signature algorithm used in combination.  It is highly desirable
  that the same hash algorithm be used for computing the digest of the
  attributes and the content.  How would xor-md5WithRSAEncryption be
  handled?

[Ballot discuss]
There are many algorithm identifiers that specify a hash algorithm and
  a signature algorithm used in combination.  It is highly desirable
  that the same hash algorithm be used for computing the digest of the
  attributes and the content.  How would xor-md5WithRSAEncryption be
  handled?

[Ballot discuss]
[Updated.]

I generally support this experiment. However the MIME section contains several errors that need to be fixed before this document can be approved:

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

I don't believe this comment is correct according to MIME, you should be using the mechanism defined in RFC 2231.

>  An example content-type string
>  would be:
>
> Content-Type: multipart/signed; protocol="application/pkcs7-signature";
>      micalg=sha1, xor-md5:04400102030405060708090a0b0c0d0e0f00111213141
>      5161718191a1b1c1d1e1f102122232425262728292a2b2c2d2e2f2031323334353
>      63738393a3b3c3d3e3f30;
>      boundary=boundar42

According to RFC 1847, micalg is defined as:

  parameter := "micalg" "=" value

which I believe is referencing the  ABNF production from MIME (RFC 2045):

    value := token / quoted-string

    token := 1*

    tspecials :=  "(" / ")" / "<" / ">" / "@" /
                  "," / ";" / ":" / "\" / <">
                  "/" / "[" / "]" / "?" / "="
                  ; Must be in quoted-string,
                  ; to use within parameter values

So, neither spaces nor commas are allowed in the micalg parameter, unless it is quoted.

quoted-string is defined in RFC 5322 (/2822/822). I don't remember of the top of my head
how folding of lines interacts with quoted strings. I will research that as well.


In Section A.2:

  MIME-Version: 1.0
  To: User2@examples.com
  From: BobRSA@examples.com
  Subject: MD5-XOR signing example
  Message-Id: <091218002550300.249@examples.com>
  Date: Fri, 18 Dec 2010 00:25:21 -0300
  Content-Type: multipart/signed;
      micalg=xor-md5: 0440010203405060708090a0b0c0d0e0f10
      111213415161718191a1b1c1d1e1f20212223425262728292a2b2c2d2e2f30
      313233435363738393a3b3c3d3e3f40

I think the trailing ";" is missing on the above line (in addition to missing quoting).

      boundary="----=_NextBoundry____Fri,_18_Dec_2009_00:25:21";
      protocol="application/pkcs7-signature"

[Ballot discuss]
[Updated.]

I generally support this experiment. However the MIME section contains several errors that need to be fixed before this document can be approved:

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

I don't believe this comment is correct according to MIME, but I need to double check that.

>  An example content-type string
>  would be:
>
> Content-Type: multipart/signed; protocol="application/pkcs7-signature";
>      micalg=sha1, xor-md5:04400102030405060708090a0b0c0d0e0f00111213141
>      5161718191a1b1c1d1e1f102122232425262728292a2b2c2d2e2f2031323334353
>      63738393a3b3c3d3e3f30;
>      boundary=boundar42

According to RFC 1847, micalg is defined as:

  parameter := "micalg" "=" value

which I believe is referencing the  ABNF production from MIME (RFC 2045):

    value := token / quoted-string

    token := 1*

    tspecials :=  "(" / ")" / "<" / ">" / "@" /
                  "," / ";" / ":" / "\" / <">
                  "/" / "[" / "]" / "?" / "="
                  ; Must be in quoted-string,
                  ; to use within parameter values

So, neither spaces nor commas are allowed in the micalg parameter, unless it is quoted.

quoted-string is defined in RFC 5322 (/2822/822). I don't remember of the top of my head
how folding of lines interacts with quoted strings. I will research that as well.


In Section A.2:

  MIME-Version: 1.0
  To: User2@examples.com
  From: BobRSA@examples.com
  Subject: MD5-XOR signing example
  Message-Id: <091218002550300.249@examples.com>
  Date: Fri, 18 Dec 2010 00:25:21 -0300
  Content-Type: multipart/signed;
      micalg=xor-md5: 0440010203405060708090a0b0c0d0e0f10
      111213415161718191a1b1c1d1e1f20212223425262728292a2b2c2d2e2f30
      313233435363738393a3b3c3d3e3f40

I think the trailing ";" is missing on the above line (in addition to missing quoting).

      boundary="----=_NextBoundry____Fri,_18_Dec_2009_00:25:21";
      protocol="application/pkcs7-signature"

[Ballot comment]
INTRODUCTION, paragraph 4:
>    algorithms with parameters, but anecdotic evidence suggests that

  Nit: s/anecdotic/anecdotal/


INTRODUCTION, paragraph 13:
> Internet-Draft            CMS Paramertized Hash            January 2011

  Nit: s/Paramertized/Parametrized/


Section 8., paragraph 0:
>      A.3.  Autenticated Data Example  . . . . . . . . . . . . . . . . 17

  Nit: s/Autenticated/Authenticated/


Section 1., paragraph 9:
>    The ASN.1 defined for the types DigestedData and AthenticatedData are

  Nit: s/AthenticatedData/AuthenticatedData/


Section 1., paragraph 11:
>    SignerInfo.digestedAlgorithm is not seen until the content has been

  Nit: s/SignerInfo.digestedAlgorithm/SignerInfo.digestAlgorithm/ (I
  think?)


Appendix A., paragraph 7:
>  To: BobRSA@examples.com

  "examples.com" is not one of the usual domain names set aside for
  documentation purposes. Do you mean "example.com"?

[Ballot discuss]
[This is a preliminary DISCUSS in order to help authors to resolve issues quicker.]

I generally support this experiment. However the MIME section contains several errors that need to be fixed before this document can be approved:

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

I don't believe this comment is correct according to MIME, but I need to double check that.

>  An example content-type string
>  would be:
>
> Content-Type: multipart/signed; protocol="application/pkcs7-signature";
>      micalg=sha1, xor-md5:04400102030405060708090a0b0c0d0e0f00111213141
>      5161718191a1b1c1d1e1f102122232425262728292a2b2c2d2e2f2031323334353
>      63738393a3b3c3d3e3f30;
>      boundary=boundar42

According to RFC 1847, micalg is defined as:

  parameter := "micalg" "=" value

which I believe is referencing the  ABNF production from MIME (RFC 2045):

    value := token / quoted-string

    token := 1*

    tspecials :=  "(" / ")" / "<" / ">" / "@" /
                  "," / ";" / ":" / "\" / <">
                  "/" / "[" / "]" / "?" / "="
                  ; Must be in quoted-string,
                  ; to use within parameter values

So, neither spaces nor commas are allowed in the micalg parameter, unless it is quoted.

quoted-string is defined in RFC 5322 (/2822/822). I don't remember of the top of my head
how folding of lines interacts with quoted strings. I will research that as well.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Subject: Last Call:  (Experiment: Hash functions with parameters in CMS and S/MIME) to Experimental RFC


The IESG has received a request from an individual submitter to consider
the following document:
- 'Experiment: Hash functions with parameters in CMS and S/MIME'
  as an Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-01-03. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-schaad-smime-hash-experiment/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-schaad-smime-hash-experiment/

1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the document
and, in particular, does he or she believe this version is ready
for forwarding to the IESG for publication?

Jim Schaad

(1.b) Has the document had adequate review both from key members of
the interested community and others? Does the Document Shepherd
have any concerns about the depth or breadth of the reviews that
have been performed?

Document has been presented to the S/MIME working group during
face-to-face meetings and has been sent to the S/MIME mailing list for
review on a couple of occasions. The S/MIME working group decided not
to take this as a WG document to optimize it's shutdown speed.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective, e.g.,
security, operational complexity, someone familiar with AAA,
internationalization or XML?

No. The examples have not had a second person validation, however it
should not be needed in order to successfully test the portions that
need to be tested.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he or
she is uncomfortable with certain parts of the document, or has
concerns whether there really is a need for it. In any event, if
the interested community has discussed those issues and has
indicated that it still wishes to advance the document, detail
those concerns here.

No.

(1.e) How solid is the consensus of the interested community behind
this document? Does it represent the strong concurrence of a few
individuals, with others being silent, or does the interested
community as a whole understand and agree with it?

No consensus exists on this document. It is an issue that people are
trying to ignore.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See the Internet-Drafts Checklist
and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not
enough; this check needs to be thorough. Has the document met all
formal review criteria it needs to, such as the MIB Doctor, media
type and URI type reviews?

The NITs reviewer notes that RFC2119 is not referenced even though the
RFC2119 boilerplate is missing. This was a deliberate choice by the
author not to include the boilerplate since this is an experimental
document and the language is mostly targeted to saying - Don't use this
is public.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that are
not ready for advancement or are otherwise in an unclear state?
If such normative references exist, what is the strategy for their
completion? Are there normative references that are downward
references, as described in [RFC3967]? If so, list these downward
references to support the Area Director in the Last Call procedure
for them [RFC3967].

Not an issue.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body of
the document? If the document specifies protocol extensions, are
reservations requested in appropriate IANA registries? Are the
IANA registries clearly identified? If the document creates a new
registry, does it define the proposed initial contents of the
registry and an allocation procedure for future registrations?
Does it suggested a reasonable name for the new registry? See
[I-D.narten-iana-considerations-rfc2434bis]. If the document
describes an Expert Review process has Shepherd conferred with the
Responsible Area Director so that the IESG can appoint the needed
Expert during the IESG Evaluation?

Yes.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML code,
BNF rules, MIB definitions, etc., validate correctly in an
automated checker?

Yes.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Writeup? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary

The document describes an experiment to determine if any current
implementers have dealt with a new class of hash algorithms which are
not currently deployed. In order to do this a new hash algorithm w/
parameters is defined for use with this experiment and some examples of
the use of the new hash algorithm are included in the document.

Working Group Summary

The S/MIME working group did not consider adopting the document as it
was considered to be esoteric and the working group was planning to shut
down soon. There were no interesting issues discussed on the document.

Document Quality

One implementation of the system exists by the author of the document.
No other known implementations exist. I would not expect people to
consider looking at the document seriously until a serious contender for
a hash algorithm with parameters is presented to the community.

Personnel

Jim Schaad is the Document Shepherd.
Sean Turner is the Responsible Area Director.