-----Original Message-----
From: Peter Sylvester [mailto:Peter(_dot_)Sylvester(_at_)edelweb(_dot_)fr]
Sent: Thursday, May 03, 2007 4:28 AM
To: Jim Schaad
Cc: 'pgut001'; housley(_at_)vigilsec(_dot_)com; ietf-smime(_at_)imc(_dot_)org
Subject: Re: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt
If you look at the structure, there are no hash indicators before-
hand. In
fact the document explicitly says don't put in a messageDigest
attribute.
I am making the analogy with signedData and authenticatedData in order
to
give one example where a creator wants to stream and can only create an
attribute after having processed all the data.
How would you then insert such the attribute on the fly?
You don't. What I said was that it is more important to make sure
that
things are good for the validator and not for the encoder. The
encoder
knows what is going to be happening and can live with not streaming.
The
validator MUST know in advance what is going to happen in order to be
able
to set things up correctly.
I do not agree with this argument:
If a creator should/must/could live without streaming, then I would
think that SignedData and
AuthenticatedData also should have their signedattributes before in
order to
have maximum information about what to do with the data.
I agree with this. If you make the argument that there are any number of
items you want to do this for, then you need to have the signer place the
attributes before the body in all cases. This is the reason that there is a
list of hashes prior to the body for these cases.
This is the reason that I was trying to establish that there was something
other than a message digest which might need to be used in this manner.
Jim
regards
Peter