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

From: [email-masked] (Peter Gutmann)
Date: Wed, 18 Apr 2007 04:52:11 +1200

Russ Housley <[email-masked]> writes:

>The difference is the swapped order of authAttrs and authEncryptedContentInfo.

Yup.  That is, I'm not saying they absolutely have to be last, but that
forcing them to be first rules out the use of some algorithms (and vice versa).

>The best placement seems to depend on the authenticated encryption 
>modes that one thinks will become most popular in the Internet over 
>time.  We each have examples that support our preferred placement.  I 
>do not know which of us has the better crystal ball.

Is there any way to put money both ways?  

Peter.

---

From: "Jim Schaad" <[email-masked]>
Date: Sat, 21 Apr 2007 21:48:46 -0700

Peter,

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.

Jim

> -----Original Message-----
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Peter Gutmann
> Sent: Tuesday, April 17, 2007 9:52 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt
> 
>

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 26 Apr 2007 08:54:32 +1200

>encryption wrapper understands the difference between the body and the

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.

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 25 Apr 2007 13:58:17 -0700

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.

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.

Jim

> From: pgut001 [mailto:[email-masked]]
> Sent: Wednesday, April 25, 2007 1:55 PM
> To: [email-masked]; [email-masked];
> [email-masked]
> Cc: [email-masked]
> Subject: RE: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt
>

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 26 Apr 2007 11:12:16 +0200

> 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.
> 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.

>>> 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
>>

---

From: Russ Housley <[email-masked]>
Date: Thu, 26 Apr 2007 10:23:35 -0400

Peter:

>Yup.

Okay.  I'll swap the order.

Russ

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 27 Apr 2007 16:26:26 -0700

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

> [email-masked]] On Behalf Of Peter Sylvester
> Sent: Thursday, April 26, 2007 2:12 AM
> To: Jim Schaad
> Cc: 'pgut001'; [email-masked]; [email-masked]
> >> 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

---

From: Russ Housley <[email-masked]>
Date: Sun, 29 Apr 2007 10:49:01 -0400

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

---

From: Peter Sylvester <[email-masked]>
Date: Mon, 30 Apr 2007 19:09:21 +0200

> assumed to occur more often than the encoding operation.
The messageDigest is an authenticated attribute that cannot be set 
before the data. You
may need some information in order to start the compution, that's why 
there are the
hash algorithms indicated before.

But the global application context or document context knows what you 
have to do,
at least the creator cannot place such an attribute before the data.
> the body I oppose swapping the body and the authenticated attributes.
How would you then insert such the attribute on the fly?

regards
Peter

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 30 Apr 2007 10:15:46 -0700

Peter,

> From: Peter Sylvester [mailto:[email-masked]]
> Sent: Monday, April 30, 2007 10:09 AM
> To: Jim Schaad

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.

> 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.

Jim