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

["Jim Schaad" <ietf@xxxxxxxxxxxxxxxxx>]

Peter,

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.

Jim


> -----Original Message-----
> From: owner-ietf-smime@xxxxxxxxxxxx [mailto:owner-ietf-
> smime@xxxxxxxxxxxx] On Behalf Of Russ Housley
> Sent: Tuesday, May 08, 2007 11:12 AM
> To: pgut001@xxxxxxxxxxxxxxxxx
> Cc: ietf-smime@xxxxxxx
> Subject: Re: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt
> 
> 
> I'm considering this issue resolved, unless Jim wants to re-open the
> discussion.
> 
> Russ
> 
> At 01:49 PM 5/8/2007, Peter Gutmann wrote:
> >Russ Housley <housley@xxxxxxxxxxxx> writes:
> >
> > >CMS needs to support all of these situations.  The question is
> > which case the
> > >syntax is optimized to handle.  All of them are accommodated.  I
> > believe that
> > >we have always in the past arranged the field placement to permit
> the
> > >recipient to handle the stream efficiently.
> >
> >The existing format allows both the sender and the recipient to handle
> the
> >stream efficiently - that's the nice thing about the existing format,
> both
> >low-powered senders and low-powered recipients can handle it (and if
> you're
> >streaming in the order of gigabytes of data in real time, almost
> everything
> >falls into the "low-powered" class).  So in the past the field
> placement seems
> >to have been designed to allow both sides to handle the stream
> efficiently,
> >which seems to have worked pretty well so far.  If the existing PKCS
> #7/CMS
> >field format has worked just fine and handled all sorts of
> applications for
> >15-odd years, why change it now?
> >
> >Peter.