Subject: Straw Poll: encoding of authenticated attributes in cms-auth-enveloped ID

From: "Turner, Sean P." <[email-masked]>
Date: Tue, 27 Mar 2007 13:34:09 -0400

At IETF 68, Russ Housley presented an summary of the
Authenticated-Enveloped-Data content type (the slides can be found at
https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=68).
There was one open issue (the last slide) that dealt with the encoding of
authenticated attributes.  It was discussed at the meeting; however,
responses from a wider audience (i.e., this list) is necessary.  Please
indicate your preference on whether:

A) The encoding of the authenticated attributes should be done exactly the
same as in SignedData.

B) The encoding of the authenticated attributes should use the encoding that
will be transmitted.

We are soliciting feed until 10 April 2007.

spt

---

From: Russ Housley <[email-masked]>
Date: Tue, 27 Mar 2007 14:55:55 -0400

I'd like to add one point.  Please look at section 9 of RFC
3852.  The authenticated attributes in AuthenticatedData follow
choice B).

Russ

At 01:34 PM 3/27/2007, Turner, Sean P. wrote:

At IETF 68, Russ
Housley presented an summary of the Authenticated-Enveloped-Data content
type (the slides can be found at

https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=68
).  There was one open issue (the last
slide) that dealt with the encoding of authenticated attributes.  It
was discussed at the meeting; however, responses from a wider audience
(i.e., this list) is necessary.  Please indicate your preference on
whether:

A) The encoding of the authenticated attributes should be
done exactly the same as in SignedData.

B) The encoding of the authenticated attributes should use
the encoding that will be transmitted.

spt

---

From: [email-masked] (Peter Gutmann)
Date: Wed, 28 Mar 2007 22:25:49 +1200

>B) The encoding of the authenticated attributes should use the encoding that

I've already talked to Russ about this in private a while back, I'd strongly
support a move to SEQUENCE OF and bits-on-the-wire encoding:

-- Snip --

There is one other change that would *really* help implementors (and that
should have been made ages ago for any new format that includes
auth.attributes), change the:

  attributes [0] SET OF Attribute

to:

  attributes SEQUENCE OF Attribute

The former is a royal pain for implementors because what's transmitted isn't
what's hashed, and the DER rules for sorting SET OF elements is an eternal
booby-trap for implementors (the CMS spec should really include big red
flashing lights and klaxons in the appropriate section warning people about
this).  With this change, a large chunk of the text necessary in "Message
Digest Calculation Process" simply falls away, because now you can just hash
the bits-on-the-wire form rather than having to rewrite the data first.

-- Snip --

Peter.

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 29 Mar 2007 19:38:31 +0200

I don't care very much but tend to be conservative, thus A.

There is also a third option: A+B and changing the tag of the
authenticated attributes.

It is not only SignedData, AuthenticatedData also has the A encoding
as far as I understand, see below.

I am not sure but why the AuthAttributes are there before the content?
Although a messagedigest is not part of the AuthAttributes, this means
that whene an AuthAttributes for SignedData or AuthenticatedData
requires reading the data, this gets difficult to use. I am thinking
for example a timestamp as attribute.

Russ Housley wrote:
> I'd like to add one point. Please look at section 9 of RFC 3852. The 
> authenticated attributes in AuthenticatedData follow choice B).
Russ, are you sure?

  If authAttrs field is present, the content-type attribute (as
   described in Section 11.1) and the message-digest attribute (as
   described in section 11.2) MUST be included, and the input to the MAC
   calculation process is the DER encoding of authAttrs.  A separate
   encoding of the authAttrs field is performed for message digest
   calculation.  The IMPLICIT [2] tag in the authAttrs field is not used
   for the DER encoding, rather an EXPLICIT SET OF tag is used.  That
   is, the DER encoding of the SET OF tag, rather than of the IMPLICIT
   [2] tag, is to be included in the message digest calculation along
   with the length and content octets of the authAttrs value.

>> <https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=68> 
>> ). There was one open issue (the last slide) that dealt with the 
>> encoding of authenticated attributes. It was discussed at the 
>> meeting; however, responses from a wider audience (i.e., this list) 
>> is necessary. Please indicate your preference on whether:
>>
>> A) The encoding of the authenticated attributes should be done 
>> exactly the same as in SignedData.
>>
>> B) The encoding of the authenticated attributes should use the 
>> encoding that will be transmitted.
>>

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 30 Mar 2007 17:45:06 +1200

>for example a timestamp as attribute.

I've grumbled about that too.  It's an artefact of the way CMC handles
authenticated data, but it makes things really difficult for anything that
isn't CMC.  In particular it makes one-pass processing and streaming
implementations impossible, which was a specific design feature of the CMS
format.

Peter.