ietf-smime
[Top] [All Lists]

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

2007-04-17 08:23:27

Russ Housley <housley(_at_)vigilsec(_dot_)com> 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.