ietf-smime
[Top] [All Lists]

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

2007-04-27 16:58:49

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.