Thanks for taking a close look. In the most recent version, I
swapped the order. I seemed to be the only one that thought they
should come first. I'm pleased to swap them back if others have an opinion.
Chairs: Can we have a WG Last Call, and ask this question explicitly
in the call?
Russ
At 07:26 PM 4/27/2007, 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.
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.
Jim
PS I apologize Russ, I should have spotted this sooner. I knew that I was
having a problem with the argument but I could not nail it down.
JLS
> -----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 Peter Sylvester
> Sent: Thursday, April 26, 2007 2:12 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:
> > Yes I agree that would be a problem, can you suggest an attribute
> which
> > might need to be placed there that would have this attribute?
> Currently the
> > only one I could think of is a digest which is not needed as this is
> dealt
> > with by the encryption algorithm.
> >
> A time stamp, or something like a the 3 level wrapper of ESS to be
> extracted from
> some data that are structured, i.e. you would have an appliance that
> streams
> end encrypts and adds a resume.
> > I don't need a real one, but I want to have some inkling that this
> MIGHT be
> > a real problem before trying to solve it.
> >
> See above. I am not sure but I always had the impression that the
> possibility of streaming
> is one of the fundamental features. If now we have an algorithm that
> does allow this
> in a reasonable, i.e. for example by splitting the message into chained
> chunks that
> can be authenticated (almost) on the fly and do not require an
> undeterminable
> size limit. requiring several mega of storage is not acceptable for
> processing smime
> message is not acceptable IMO.
>
> > Jim
> >
> >
> >
> >> -----Original Message-----
> >> From: pgut001 [mailto:pgut001(_at_)cs(_dot_)auckland(_dot_)ac(_dot_)nz]
> >> Sent: Wednesday, April 25, 2007 1:55 PM
> >> To: housley(_at_)vigilsec(_dot_)com; ietf(_at_)augustcellars(_dot_)com;
> >> 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
> >>
> >> "Jim Schaad" <ietf(_at_)augustcellars(_dot_)com> writes:
> >>
> >>
> >>> I am having a problem seeing why having the attributes first causes
> a
> >>> problem for algorithms that want them second. All that is needed
> is
> >>>
> >> that
> >>
> >>> the encryption wrapper for the code understand that the attributes
> are
> >>>
> >> going
> >>
> >>> to come in first and hold onto them until later. This is assuming
> >>>
> >> that the
> >>
> >>> encryption wrapper understands the difference between the body and
> the
> >>> attributes.
> >>>
> >> What if the attributes depend on the data being processed (as Peter
> >> Sylvester
> >> pointed out)? By putting them first, you can't emit the first byte
> of
> >> data
> >> until you've processed every other byte of data. This is why
> current
> >> CMS
> >> practice puts the attributes last.
> >>
> >> Peter.
> >>
> >
> >
> >