Cryptographic Message Syntax (CMS) Algorithm Identifier Protection Attribute
draft-schaad-smime-algorithm-attribute-05

[Ballot discuss]
Some signature algorithms, such as RSA PKCS#1 v1.5, sign both the
  digest algorithm identifier and the message digest.  So, if the
  attacker changes the identifier, the signature will not
  validate. While this is not true of all signature algorithms, it does
  significantly diminish the scope of the concern being addressed by
  this document.  Please add this to the discussion.

[Ballot comment]
Can the section on comparing fields in the verification process (2nd paragraph of section 3) be made more precise? Currently, it says "It is not required that a field which is absent in one case and present in another case  be compared as equivalent". Does that mean it's allowed to compare those as equivalent? Or was the intent that they MUST NOT be equivalent?

[Ballot discuss]
Some signature algorithms, such as RSA PKCS#1 v1.5, sign both the
  digest algorithm identifier and the message digest.  So, if the
  attacker changes the identifier, the signature will not
  validate. While this is not true of all signature algorithms, it does
  significantly diminish the scope of the concern being addressed by
  this document.  Please add this to the discussion.

[Ballot comment]
I have two issues with this document, but they are not large enough to form a Discuss. Nevertheless, I hope the authros will find time to address them.

---

The use of the passive voice in the first sentence of the Abstract is
disconcerting!

There is also some missing context!

The second sentence is pretty hard to parse.

Why not write:

  This document defines a new attribute that allows for protection of
  the digest and signature algorithm structures in an authenticated
  data or a signer info structure used in the Cryptographic Message
  Syntax (CMS).  When the new attribute is used, the algorithm
  definition information is included in the integrity protection
  process.

The introduction would benefit from a similar (but more verbose) fix.

---

I think it is conventional to include a reference to the ASN.1 spec
that defines the language you are using. Presumably X.208 (1988) and
X.209 (1988) could be added as references.

[Ballot comment]
INTRODUCTION, paragraph 4:
>              Signer Info Algorithm Protection Attribute
>
>    A new attribute is defined that allows for protection of the digest
>    and signature algorithm structures in an authenticated data or a
>    signer info structure.  Using the attribute includes the algorithm
>    definition information in the integrity protection process.

  It's be good if the title and abstract had some context that this
  stuff is about CMS...

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:  (Signer Info Algorithm Protection Attribute) to Proposed Standard


The IESG has received a request from an individual submitter to consider
the following document:
- 'Signer Info Algorithm Protection Attribute'
  as a Proposed Standard

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-algorithm-attribute/

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

Here's the proto write-up for draft-schaad-smime-algorithm-attribute.

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

(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?

The consensus that exists is a strong minority. The document is
attempting to solve an attack for which it is not yet clear the attack
actually exists.
This attribute would probably be of far greater interest to the LTANS
community than it currently is to the S/MIME community.

(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?

Yes.

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

No.

(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

An authenticated/signed attribute is defined to protect the algorithm
definitions of the message body and the signature. Currently this
information is not included in the signature computation and could
theoretically be changed without the signature validator knowing. This
provides an attack avenue on CMS signature and authentication operations
that currently has no known successful attacks. The new attribute is
prophylactic.

Working Group Summary

There was a small amount of discussion on the working group list if this
should be expanded to include the new authenticated encryption
algorithms. It was decided that these should be treated separately by
any interested community. The document was considered in the S/MIME
working group, but there was no push for adoption as it was believed
that the working group would be shutting down shortly.

Document Quality

The document has been implemented by the author and an example of using
the attribute can be found in draft-schaad-smime-hash-experiment. There
are no known plans for vendors to implement this, but I have received
private email asking as to the status of the document.

Personnel

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