Using Message Authentication Code (MAC) Encryption in the Cryptographic Message Syntax (CMS)
RFC 6476

Note: This ballot was opened for revision 06 and is now closed.

(Sean Turner) Yes

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) (was Discuss) No Objection

(Ralph Droms) No Objection

Comment (2011-08-09 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Sorry, added comment for wrong document.

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

Comment (2011-08-06 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I am balloting No Objection based on a light read and the support of 
the Sposoring AD. I have several minor obeservations about the document.

---

I prefer Individual Submissions to have a third-party document shepherd 
as a sanity check on the IETF demand for the work. But that is not
something to think about fixing at this time.

---

It would be helpful if some more of the acronyms were expanded on first
use, even if they are familiar to normal security technogeek. For
example, you expand CEK but not KEK.

---

   Using a fixed-length key rather than making it a user-selectable
   parameter is done for the same reason as AES' quantised key lengths:
   there's no benefit to allowing, say, 137-bit keys over basic 128- and
   256-bit lengths, it adds unnecessary complexity, and if the lengths
   are user-defined then there'll always be someone who wants keys that
   go up to 12.

"keys that go up to 12" had no meaning to me! Lengths up to 12 words?

---

   If there is any
   ambiguity over which key size should be used then it's recommended
   that the size be specified explicitly in the macAlgorithm
   AlgorithmIdentifier.

Is that "RECOMMENDED"?

(Stephen Farrell) (was Discuss) No Objection

Comment (2011-08-11)
No email
send info
(1) "extensively analysed" as a claim requires some references

(2) "keys that go to 11" will not be understood by many readers, keeping the
colourful antipodean twist on US phrasing is fine but you also need to make
what you mean clear to the non native English reader.

(3) "various analyses" requires a reference

(4) Its fine for an RFC author to write amusingly, and especially fine to do so
when criticising stuff in emails, (I really do appreciate that), but showing
off is less desirable in RFC text since it leads to more confusion. IMO this
text tries to show off too much. I can't be bothered to make so much of this as
to do a blow-by-blow analysis, but the author might consider whether less of
that would improve overall clarity. (And Peter - you can feel free to post an
apparently outraged mail about how frusty people get within months of getting
on the IESG:-) 

(5) Most other CMS docs provide an ASN.1 module for those that like those.
Is there a reason to not do that here?

(David Harrington) No Objection

(Russ Housley) No Objection

Comment (2011-08-10 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
  Please consider the comments from the Gen-ART Review by
  Alexey Melnikov on 8 July 2011.  The review can be found here:
  
  http://www.ietf.org/mail-archive/web/gen-art/current/msg06501.html

(Pete Resnick) No Objection

(Peter Saint-Andre) No Objection

Comment (2011-08-08 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
With tongue slightly in cheek, I note that this paragraph is a bit breezy:

   Providing an
   option for keys that go to 11 avoids potential user acceptance
   problems when someone notices that the authEnc pseudo-key has "only"
   128 bits when they expect their AES keys to be 256 bits long.

I'm not sure that a phrase from Spinal Tap belongs in an RFC, but at least if it's included can we put "go to 11" in scare quotes and include a citation for the movie? (As for "go up to 12", we all know that amplifiers don't have that setting!)

(Robert Sparks) No Objection