ietf-smime
[Top] [All Lists]

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

2007-05-08 17:43:13

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(_at_)mail(_dot_)imc(_dot_)org [mailto:owner-ietf-
smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Russ Housley
Sent: Tuesday, May 08, 2007 11:12 AM
To: 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


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(_at_)vigilsec(_dot_)com> 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.


<Prev in Thread] Current Thread [Next in Thread>