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

[pgut001@xxxxxxxxxxxxxxxxx (Peter Gutmann)]

Russ Housley <housley@xxxxxxxxxxxx> 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.