Peter Sylvester wrote:
Peter Gutmann wrote:
"Jim Schaad" <ietf(_at_)augustcellars(_dot_)com> 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.