Experiment: Hash Functions with Parameters in the Cryptographic Message Syntax (CMS) and S/MIME
RFC 6210
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2020-01-21
|
06 | (System) | Received changes through RFC Editor sync (added Verified Errata tag) |
2015-10-14
|
06 | (System) | Notify list changed from ietf@augustcellars.com, draft-schaad-smime-hash-experiment@ietf.org to (None) |
2012-08-22
|
06 | (System) | post-migration administrative database adjustment to the No Objection position for Alexey Melnikov |
2012-08-22
|
06 | (System) | post-migration administrative database adjustment to the No Objection position for Lars Eggert |
2012-08-22
|
06 | (System) | post-migration administrative database adjustment to the No Objection position for Russ Housley |
2011-04-06
|
06 | Cindy Morgan | State changed to RFC Published from RFC Ed Queue. |
2011-04-06
|
06 | Cindy Morgan | [Note]: changed to 'RFC 6210' |
2011-04-06
|
06 | Cindy Morgan | Status Date has been changed to None from 2010-12-13 |
2011-04-05
|
06 | (System) | RFC published |
2011-01-26
|
06 | Cindy Morgan | State changed to RFC Ed Queue from Approved-announcement sent. |
2011-01-25
|
06 | (System) | IANA Action state changed to No IC from In Progress |
2011-01-25
|
06 | (System) | IANA Action state changed to In Progress |
2011-01-25
|
06 | Cindy Morgan | IESG state changed to Approved-announcement sent |
2011-01-25
|
06 | Cindy Morgan | IESG has approved the document |
2011-01-25
|
06 | Cindy Morgan | Closed "Approve" ballot |
2011-01-25
|
06 | Cindy Morgan | Approval announcement text regenerated |
2011-01-25
|
06 | Cindy Morgan | Ballot writeup text changed |
2011-01-25
|
06 | Alexey Melnikov | [Ballot comment] I generally support this experiment. However the MIME section contains several errors that need to be fixed before this document can be approved: |
2011-01-25
|
06 | Alexey Melnikov | [Ballot Position Update] Position for Alexey Melnikov has been changed to No Objection from Discuss |
2011-01-24
|
06 | Lars Eggert | [Ballot Position Update] Position for Lars Eggert has been changed to No Objection from Discuss |
2011-01-24
|
06 | (System) | New version available: draft-schaad-smime-hash-experiment-06.txt |
2011-01-21
|
06 | Alexey Melnikov | [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 … [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. |
2011-01-21
|
06 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2011-01-21
|
05 | (System) | New version available: draft-schaad-smime-hash-experiment-05.txt |
2011-01-21
|
06 | (System) | Removed from agenda for telechat - 2011-01-20 |
2011-01-20
|
06 | Russ Housley | [Ballot discuss] There are many algorithm identifiers that specify a hash algorithm and a signature algorithm used in combination. It is highly desirable … [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? |
2011-01-20
|
06 | Russ Housley | [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss |
2011-01-20
|
06 | Cindy Morgan | State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation. |
2011-01-20
|
06 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded |
2011-01-20
|
06 | Adrian Farrel | [Ballot comment] This comment intentionally left blank! (Apparently you can't delete a comment) |
2011-01-20
|
06 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded |
2011-01-19
|
06 | Russ Housley | [Ballot discuss] There are many algorithm identifiers that specify a hash algorithm and a signature algorithm used in combination. It is highly desirable … [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? |
2011-01-19
|
06 | Russ Housley | [Ballot Position Update] New position, Discuss, has been recorded |
2011-01-19
|
06 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded |
2011-01-19
|
06 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded |
2011-01-19
|
06 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded |
2011-01-19
|
06 | Alexey Melnikov | [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 … [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" |
2011-01-19
|
06 | Alexey Melnikov | [Ballot comment] RFC 1847 needs to be an Informative Reference. I think MIME as well. |
2011-01-19
|
06 | Alexey Melnikov | [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 … [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" |
2011-01-19
|
06 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded |
2011-01-18
|
06 | Sean Turner | State changed to IESG Evaluation from Waiting for AD Go-Ahead. |
2011-01-17
|
06 | Lars Eggert | [Ballot comment] INTRODUCTION, paragraph 4: > algorithms with parameters, but anecdotic evidence suggests that Nit: s/anecdotic/anecdotal/ INTRODUCTION, paragraph 13: > Internet-Draft … [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"? |
2011-01-17
|
06 | Lars Eggert | [Ballot discuss] DISCUSS: ID is missing the RFC2119 boilerplate and reference. |
2011-01-17
|
06 | Lars Eggert | [Ballot Position Update] New position, Discuss, has been recorded |
2011-01-12
|
06 | Alexey Melnikov | [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 … [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. |
2011-01-12
|
06 | Alexey Melnikov | [Ballot Position Update] New position, Discuss, has been recorded |
2011-01-10
|
06 | Peter Saint-Andre | [Ballot Position Update] New position, No Objection, has been recorded |
2011-01-06
|
04 | (System) | New version available: draft-schaad-smime-hash-experiment-04.txt |
2011-01-06
|
06 | Sean Turner | [Ballot Position Update] New position, Yes, has been recorded for Sean Turner |
2011-01-06
|
06 | Sean Turner | Ballot has been issued |
2011-01-06
|
06 | Sean Turner | Created "Approve" ballot |
2011-01-04
|
06 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Brian Weis. |
2011-01-03
|
06 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call. |
2010-12-21
|
06 | Amanda Baber | We understand that this document does not require any IANA actions. |
2010-12-16
|
06 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Brian Weis |
2010-12-16
|
06 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Brian Weis |
2010-12-13
|
06 | Sean Turner | Placed on agenda for telechat - 2011-01-20 |
2010-12-13
|
06 | Sean Turner | Status Date has been changed to 2010-12-13 from None |
2010-12-06
|
06 | Amy Vezza | Last call sent |
2010-12-06
|
06 | Amy Vezza | 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 … 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/ |
2010-12-06
|
06 | Sean Turner | Last Call was requested |
2010-12-06
|
06 | Sean Turner | State changed to Last Call Requested from Publication Requested. |
2010-12-06
|
06 | Sean Turner | Last Call text changed |
2010-12-06
|
06 | (System) | Ballot writeup text was added |
2010-12-06
|
06 | (System) | Last call text was added |
2010-12-06
|
06 | (System) | Ballot approval text was added |
2010-12-06
|
06 | Cindy Morgan | 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 … 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. |
2010-12-06
|
06 | Cindy Morgan | Draft added in state Publication Requested |
2010-12-06
|
06 | Cindy Morgan | [Note]: 'Jim Schaad (ietf@augustcellars.com) is the document shepherd.' added |
2010-11-23
|
03 | (System) | New version available: draft-schaad-smime-hash-experiment-03.txt |
2010-11-22
|
02 | (System) | New version available: draft-schaad-smime-hash-experiment-02.txt |
2010-06-20
|
06 | (System) | Document has expired |
2009-12-17
|
01 | (System) | New version available: draft-schaad-smime-hash-experiment-01.txt |
2009-05-05
|
00 | (System) | New version available: draft-schaad-smime-hash-experiment-00.txt |