Peter,
-----Original Message-----
From: Peter Sylvester [mailto:Peter(_dot_)Sylvester(_at_)edelweb(_dot_)fr]
Sent: Monday, April 30, 2007 10:09 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
Jim Schaad wrote:
Peters,
I think that you are off base on this. If you are going to make an
attribute that is dependent on the body you WANT the attributes to
come
before the body. If this is not the case, the authenticator does not
know
that the attribute validation needs to be setup until the body has
been
completely processed and it cannot be placed in stream anymore. This
does
make things harder for the encoder, but the authentication operation
can be
assumed to occur more often than the encoding operation.
The messageDigest is an authenticated attribute that cannot be set
before the data. You
may need some information in order to start the compution, that's why
there are the
hash algorithms indicated before.
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.
But the global application context or document context knows what you
have to do,
at least the creator cannot place such an attribute before the data.
If this swap is done for reasons of consistency I can agree with
this. If
this is done to satisfy the need for the argument based on the
content of
the body I oppose swapping the body and the authenticated attributes.
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.
Jim
regards
Peter