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

From: [email-masked] (Peter Gutmann)
Date: Wed, 18 Apr 2007 02:57:30 +1200

Russ Housley <[email-masked]> writes:
>> >On the second item, I disagree.  The authenticated attributes are 
>> handled the
>> >same as in AuthenticatedData.
>>
>>They're placed before the data, not after it, which is unlike any other use of
>>authenticated attributes in any CMS PDU.  As both Peter Sylvester and myself
>>have already pointed out, this makes one-pass/streaming processing impossible.
>
>As I already said in response, AES-CCM and AES-GCM both require the 
>processing of the "additional authenticated data" (the authenticated 
>attributes in this structure) prior to the processing of the payload 
>(the encapsulated content in this structure).  Thus, the only way 
>that one-pass processing can be accomplished with these authenticated 
>encryption modes is for the authenticated attributes to appear first.

Hmm, we already went through this one in private mail... what you're doing is 
tying the data format to an artefact of a particular crypto algorithm.  Your 
algorithm choice happens to put the authenticated data first because it was 
designed for use with 802.11 rather than CMS, but there are other algorithms 
like CWC that put them last as per normal CMS usage.  By arbitrarily putting 
the authenticated attributes first, you're forcing implementors to use a 
small subset of 802.11-optimised algorithms for AuthenticatedData rather 
than making it a general-purpose format, and more worryingly making it 
impossible to create a one-pass implementation because with 802.11, fixed 
authenticated headers at the start, and short data packets it's not a concern, 
but with CMS and arbitrary-length data it is.

In order to make this general-purpose, you'd need some provision for having
the auth.attributes either before or after, depending on the algorithm being
used, or some similar way to handle the quirks of different algorithms.

Peter.

---

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

Peter:

CURRENT DOCUMENT:

       AuthEnvelopedData ::= SEQUENCE {
         version CMSVersion,
         originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
         recipientInfos RecipientInfos,
         authAttrs [1] IMPLICIT AuthAttributes OPTIONAL,
         authEncryptedContentInfo EncryptedContentInfo,
         mac MessageAuthenticationCode,
         unauthAttrs [2] IMPLICIT UnauthAttributes OPTIONAL }

WHAT I THINK YOU ARE ADVOCATING:

       AuthEnvelopedData ::= SEQUENCE {
         version CMSVersion,
         originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
         recipientInfos RecipientInfos,
         authEncryptedContentInfo EncryptedContentInfo,
         authAttrs [1] IMPLICIT AuthAttributes OPTIONAL,
         mac MessageAuthenticationCode,
         unauthAttrs [2] IMPLICIT UnauthAttributes OPTIONAL }

The difference is the swapped order of authAttrs and authEncryptedContentInfo.

The best placement seems to depend on the authenticated encryption 
modes that one thinks will become most popular in the Internet over 
time.  We each have examples that support our preferred placement.  I 
do not know which of us has the better crystal ball.

I do agree that the placement that you advocate has the same ordering 
as AuthenicatedData.

Russ

> >> >On the second item, I disagree.  The authenticated attributes 
> are handled the

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 18 Apr 2007 11:38:37 +0200

I mentioned in a previous mail:

Awaht about TWO instances of authenticated attributes.

- the ones that come after can be created/validated in the same way
  as with signedData or authenticatedData, and can, in particular,
  depend on the encapsulatedData.

- If there is something that needs to be added before the data,
  do this independantly. And if this depends on the recipients,
  one should put this in the recipientinfo, ...

Peter