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

[Dr Stephen Henson <lists@xxxxxxxxxxxxxxxxxxxxxxxxxxx>]

Peter Sylvester wrote:
> Peter Gutmann wrote:
>> "Jim Schaad" <ietf@xxxxxxxxxxxxxxxxx> writes:
>>
>>  
>>> Do you really consider this to be done efficiently for use with the two
>>> current document algorithms?  The validator needs to buffer the
>>> entire body
>>> stream before it can start doing the validation pass.
>>>     
>>
>> I consider it done efficiently for the existing (SignedData/AuthData)
>> formats.
>> I consider it done horribly inefficiently for AuthEnvData, for the
>> reason you
>> give above, but it's algorithm-specific: For the two chosen
>> algorithms, it
>> happens to be more convenient to put the auth.attributes first.  For many
>> other algorithms (as illustrated by the existing SignedData/AuthData
>> practice), you need to have the auth.attributes last.
>>
>> Peter.
>>
>>   
> I would like to repeat my suggestion to have two fields, one before and
> one behind.

Just my 2c.

I agree with this.

In SignedData and EnvelopedData we have "parameters" before the content.
They must come first because a streaming decoder needs their values in
order to process the content. Examples would be digest algorithms,
encryption algorithms and parameters and the content encryption key
itself (e.g. encrypted using RSA).

There are also "dependencies" whose value is dependent on the content
which have to appear afterwards because a streaming encoder will only be
able to determine their value after the content has been processed.
Examples include the messageDigest attribute and counter signatures.

AuthEnvData combines elements of the two content types and it seems
reasonable to me that some cases may have both parameters and dependenceis.

The two specific cases of CCM and GCM do have dependencies which appear
after the content but they are part of the encrypted stream itself.

It is not unreasonable to expect that some future algorithms might have
dependencies which are "external" and not part of the encrypted stream.
To support streaming encode they would have to appear after the content.

Steve.