Yes I agree that would be a problem, can you suggest an attribute which
might need to be placed there that would have this attribute? Currently the
only one I could think of is a digest which is not needed as this is dealt
with by the encryption algorithm.
I don't need a real one, but I want to have some inkling that this MIGHT be
a real problem before trying to solve it.
Jim
-----Original Message-----
From: pgut001 [mailto:pgut001(_at_)cs(_dot_)auckland(_dot_)ac(_dot_)nz]
Sent: Wednesday, April 25, 2007 1:55 PM
To: housley(_at_)vigilsec(_dot_)com; ietf(_at_)augustcellars(_dot_)com;
pgut001(_at_)cs(_dot_)aucKland(_dot_)ac(_dot_)nz
Cc: ietf-smime(_at_)imc(_dot_)org
Subject: RE: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt
"Jim Schaad" <ietf(_at_)augustcellars(_dot_)com> writes:
I am having a problem seeing why having the attributes first causes a
problem for algorithms that want them second. All that is needed is
that
the encryption wrapper for the code understand that the attributes are
going
to come in first and hold onto them until later. This is assuming
that the
encryption wrapper understands the difference between the body and the
attributes.
What if the attributes depend on the data being processed (as Peter
Sylvester
pointed out)? By putting them first, you can't emit the first byte of
data
until you've processed every other byte of data. This is why current
CMS
practice puts the attributes last.
Peter.