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

["Jim Schaad" <ietf@xxxxxxxxxxxxxxxxx>]

> -----Original Message-----
> From: Peter Sylvester [mailto:Peter.Sylvester@xxxxxxxxxx]
> Sent: Thursday, May 03, 2007 4:28 AM
> To: Jim Schaad
> Cc: 'pgut001'; housley@xxxxxxxxxxxx; ietf-smime@xxxxxxx
> 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