ietf-smime
[Top] [All Lists]

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

2007-04-17 09:18:41

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