Subject: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt

From: [email-masked]
Date: Thu, 05 Apr 2007 15:50:02 -0400

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

	Title		: Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type
	Author(s)	: R. Housley
	Filename	: draft-ietf-smime-cms-auth-enveloped-03.txt
	Pages		: 11
	Date		: 2007-4-5
	
This document describes an additional content type for the
   Cryptographic Message Syntax (CMS).  The authenticated-enveloped-data
   content type is intended for use with authenticated encryption modes.
   All of the various key management techniques that are supported in
   the CMS enveloped-data content type are also supported by the CMS
   authenticated-enveloped-data content type.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-cms-auth-enveloped-03.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-smime-cms-auth-enveloped-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-cms-auth-enveloped-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Russ Housley <[email-masked]>
Date: Thu, 05 Apr 2007 16:56:08 -0400

I believe that this document and the companion document that tells 
how to use AES-CCM and AES-GCM are ready for WGLC.

Russ

At 03:50 PM 4/5/2007, [email-masked] wrote:
>         Title           : Cryptographic Message Syntax (CMS) 
> Authenticated-Enveloped-Data Content Type
>         Author(s)       : R. Housley

---

From: [email-masked] (Peter Gutmann)
Date: Sat, 07 Apr 2007 19:06:22 +1200

Russ Housley <[email-masked]> writes:

>I believe that this document and the companion document that tells how to use
>AES-CCM and AES-GCM are ready for WGLC.

Uhhmmm, I beg to differ... it still doesn't contain the changes I sent some
time ago to handle encrypt + MAC combinations (e.g. AES + HMAC), and there was
no agreement about handling of auth.attributes - two people pointed out that
the existing scheme has problems, but this hasn't been resolved yet.

Peter.

---

From: Russ Housley <[email-masked]>
Date: Sat, 07 Apr 2007 18:43:49 -0400

>the existing scheme has problems, but this hasn't been resolved yet.

On the first item, you never sent text.  We discussed potential ways 
to handle it, but you never provided a section to add to the 
document.  I see no reason to delay the AES-CCM and AES-GCM  document 
until you do so.

On the second item, I disagree.  The authenticated attributes are 
handled the same as in AuthenticatedData.  While I understand that 
the use of a SEQUENCE instead of a SET would be easier to process, 
but that would mean that an implementation could not take advantage 
of existing attribute handling routines.

Russ

---

From: Peter Sylvester <[email-masked]>
Date: Tue, 10 Apr 2007 14:05:39 +0200

> handled the same as in AuthenticatedData.  While I understand that the 
> use of a SEQUENCE instead of a SET would be easier to process, but 
> that would mean that an implementation could not take advantage of 
> existing attribute handling routines.
in your proposal, the attributes are placed before the data. Why?

As far as I understand, there is no difference between handling of 
authenticated attributed between
signedData and authenticatedData, so why introducing any new mode here?

Your argument about SEQUENCE  vs SET sounds wrong to me: If you have an 
implicit tagging that
replaces sequence or set, then coding or decoding becomes essentially 
the same except that you
won't need to sort the attributes before coding, but it wouldn't hurt if 
you do. On the other
hand, if you really verify the order when decoding, then sequence hurts, 
but there are several
implementations which ignore the encoded order as far as I know and 
others which fail to
sort etc.

---

From: Russ Housley <[email-masked]>
Date: Tue, 10 Apr 2007 08:57:19 -0400

Peter:

>Your argument about SEQUENCE  vs SET sounds wrong to me: If you have 
>an implicit tagging that
>replaces sequence or set, then coding or decoding becomes 
>essentially the same except that you
>won't need to sort the attributes before coding, but it wouldn't 
>hurt if you do. On the other
>hand, if you really verify the order when decoding, then sequence 
>hurts, but there are several

Such implementations would not be considered compliant with RFC 3852 
or any of its predecessors, including PKCS#7 v1.5.  I do not think we 
should penalize implementors that followed the specification.

I'm pleased to listen to implementors on this point.  So far, two 
have spoken.  One suggesting the move to SEQUENCE and one preferring 
to use their existing attribute handling routines.  Both said, that 
it was not a really big deal either way.  Given that input, I went 
with consistency with AuthenticatedData.

Russ

---

From: Peter Sylvester <[email-masked]>
Date: Tue, 10 Apr 2007 15:59:10 +0200

Russ Housley wrote:
>> won't need to sort the attributes before coding, but it wouldn't hurt 
>> if you do. On the other
Right. But that was not the point. no matter IMO anyway.
>
> I'm pleased to listen to implementors on this point.  So far, two have 
> spoken.  One suggesting the move to SEQUENCE and one preferring to use 
> their existing attribute handling routines.  Both said, that it was 
> not a really big deal either way.  Given that input, I went with 
> consistency with AuthenticatedData.

What do you mean with consistency with AuthenticatedData? Isn't it  the 
same as with SignedData?
Having them before is not what I would call consistant. I think you may 
consider two sets.

---

From: Russ Housley <[email-masked]>
Date: Tue, 10 Apr 2007 11:14:17 -0400

Peter:

>>have spoken.  One suggesting the move to SEQUENCE and one 
>>preferring to use their existing attribute handling routines.  Both 
>>said, that it was not a really big deal either way.  Given that 
>>input, I went with consistency with AuthenticatedData.
>
>What do you mean with consistency with AuthenticatedData? Isn't 
>it  the same as with SignedData?
>Having them before is not what I would call consistant. I think you 
>may consider two sets.

No.  They both use SET, but there is a difference in the first tag of 
the DER encoding that is used for the hash value 
computation.  SignedData has a bit of extra complexity for backward 
compatibility.  PKCS#7 V1.5 did not have AuthenticatedData, so the 
extra complexity is not required.

Russ

---

From: Russ Housley <[email-masked]>
Date: Tue, 10 Apr 2007 12:26:17 -0400

I was very unclear.  Let me try again.  Hopefully this will work out 
more clearly.

For SignedData, Section 5.4 of RFC 3852 says:

    ... A separate encoding
    of the signedAttrs field is performed for message digest calculation.
    The IMPLICIT [0] tag in the signedAttrs is not used for the DER
    encoding, rather an EXPLICIT SET OF tag is used.  That is, the DER
    encoding of the EXPLICIT SET OF tag, rather than of the IMPLICIT [0]
    tag, MUST be included in the message digest calculation along with
    the length and content octets of the SignedAttributes value.

For Authenticated Data. Section 9.2 of RFC 3852 says:

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

So, the same encoding is used to the computation of the hash value, 
but a different initial tag is used in the encoding that is transmitted.

Russ

The same encoding is used At 11:14 AM 4/10/2007, Russ Housley wrote:
>>>preferring to use their existing attribute handling 
>>>routines.  Both said, that it was not a really big deal either 
>>>way.  Given that input, I went with consistency with AuthenticatedData.
>>
>No.  They both use SET, but there is a difference in the first tag 
>of the DER encoding that is used for the hash value

---

From: Russ Housley <[email-masked]>
Date: Tue, 10 Apr 2007 13:56:31 -0400

The encoding issue raised by Peter and Peter needs to be very 
clear.  The current document really handles this by reference, which 
is probably not the best.

I suggest the re-write of the 3rd paragraph of section 2.2 to handle 
this directly instead of by reference:

    If optional authenticated attributes are present, then they are DER
    encoded.  A separate encoding of the authAttrs field is performed to
    construct the authenticated associated data (AAD) input to the
    authenticated encryption algorithm.  The IMPLICIT [1] 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 [1] tag, is to be included in the
    construction of the AAD along with the length and content octets of
    the authAttrs value.  If the authenticated encryption algorithm
    requires the AAD to be padded to a multiple of some block size, then
    the padding MUST be added as described in Section 6.3 of [CMS].  This
    padding method is well defined if and only if number of octets in the
    block size is less than 256.

Russ

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 12 Apr 2007 13:56:13 +0200

You wrote two messages

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

I think that authenticated attributes in AuthenticatedData also follows A.

The question is badly presented anyway: Do you ask whether the input of 
the hash function used to
calculate the hash of the authenticated attributes is not identical with 
the transmitted encoding
as with AuthenticatedData and SignedData (choice A) or whether it is 
identical? (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 
>> <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 

Russ Housley wrote:
>
> The encoding issue raised by Peter and Peter needs to be very clear.  
> The current document really handles this by reference, which is 
> probably not the best.
>
Now I get lost? What is then the strong poll for, isn't this proposed 
section choice A?

Anyway, the other problem of 'one pass' has not been addressed. What is
necessary: I think it would be helpful to have a like like:

- some information concerning each recipient available before the data
- some information concerning the sealing parties available after the data
- some global information (like helpful messagedigest etc).

regards
peter