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

From: [email-masked] (Peter Gutmann)
Date: Wed, 09 May 2007 05:49:33 +1200

Russ Housley <[email-masked]> 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.

---

From: Russ Housley <[email-masked]>
Date: Tue, 08 May 2007 14:11:37 -0400

I'm considering this issue resolved, unless Jim wants to re-open the 
discussion.

Russ

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 8 May 2007 17:22:24 -0700

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: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Russ Housley
> Sent: Tuesday, May 08, 2007 11:12 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt
> 
>

---

From: [email-masked] (Peter Gutmann)
Date: Wed, 09 May 2007 16:17:23 +1200

>stream before it can start doing the validation pass.

I consider it done efficiently for the existing (SignedData/AuthData) formats.
I consider it done horribly inefficiently for AuthEnvData, for the reason you
give above, but it's algorithm-specific: For the two chosen algorithms, it
happens to be more convenient to put the auth.attributes first.  For many
other algorithms (as illustrated by the existing SignedData/AuthData
practice), you need to have the auth.attributes last.

Peter.

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 09 May 2007 12:11:57 +0200

> practice), you need to have the auth.attributes last.
I would like to repeat my suggestion to have two fields, one before and 
one behind.

---

From: Dr Stephen Henson <[email-masked]>
Date: Wed, 09 May 2007 11:47:51 +0100

> I would like to repeat my suggestion to have two fields, one before and

Just my 2c.

I agree with this.

In SignedData and EnvelopedData we have "parameters" before the content.
They must come first because a streaming decoder needs their values in
order to process the content. Examples would be digest algorithms,
encryption algorithms and parameters and the content encryption key
itself (e.g. encrypted using RSA).

There are also "dependencies" whose value is dependent on the content
which have to appear afterwards because a streaming encoder will only be
able to determine their value after the content has been processed.
Examples include the messageDigest attribute and counter signatures.

AuthEnvData combines elements of the two content types and it seems
reasonable to me that some cases may have both parameters and dependenceis.

The two specific cases of CCM and GCM do have dependencies which appear
after the content but they are part of the encrypted stream itself.

It is not unreasonable to expect that some future algorithms might have
dependencies which are "external" and not part of the encrypted stream.
To support streaming encode they would have to appear after the content.

Steve.

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 10 May 2007 01:41:16 +1200

Peter Sylvester <[email-masked]> writes:

>I would like to repeat my suggestion to have two fields, one before and one
>behind.

Sounds good to me.

Peter.

---

From: "Turner, Sean P." <[email-masked]>
Date: Fri, 11 May 2007 14:11:37 -0400

This might require that an algorithm registration indicates which one they'd
use.  Unless of course, this is just an efficiency thing and it wouldn't
error out.

spt

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Peter Gutmann
> Sent: Wednesday, May 09, 2007 9:41 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]

---

From: "Turner, Sean P." <[email-masked]>
Date: Thu, 17 May 2007 10:02:26 -0400

Peter(s),

Two questions:

Would it be considered an error if the auth.attrs were supposed to come
before but ended up being after?  Seems like the answer is no.

How will the recipient know whether auth.attrs is supposed to come before or
after?  Seems like the answer is via the algorithm registration/description.

I'm not sure the added complexity for the recipient is worth the savings for
an as yet undefined algorithm.

spt

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 30 May 2007 19:45:48 -0700

I would have to say that I think using two locations in a single object for
auth attributes seems to be a poor idea.  There are too many different ways
to get this messed up.

If this was in the original days of how an RFC worked, I would suggest that
what happens is that two different structures be created.  One with the
attrs first, one with the attrs last.  We could then spend some time (at
least 6 months) doing implementations and playing and then adopt one when
the RFC progressed along the standards track.  As things stand I am
reluctant to suggest and support this as an alternative because both would
be implemented and both would be required forever.  I would rather choose
placing the attributes last (which I feel is incorrect) and live with the
consequences than do it in both locations.

Jim

> [email-masked]] On Behalf Of Turner, Sean P.
> Sent: Thursday, May 17, 2007 7:02 AM
> To: 'Peter Gutmann'; [email-masked]
> Subject: RE: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt
> 
> 
> Peter(s),
> 
> Two questions:
>