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

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

Peter Gutmann wrote:
> 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.
>
>
>

smime.p7s
Description: S/MIME Cryptographic Signature