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

From: Peter Sylvester <[email-masked]>
Date: Thu, 03 May 2007 13:28:13 +0200

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

I am making the analogy with signedData and authenticatedData in order to
give one example where a creator wants to stream and can only create an
attribute after having processed all the data.

>>>       
>> 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.
>   
I do not agree with this argument:
If a creator should/must/could live without streaming, then I would 
think that SignedData and
AuthenticatedData also should have their signedattributes before in order to
have maximum information about what to do with the data.

regards
Peter

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 3 May 2007 07:03:09 -0700

> -----Original Message-----
> From: Peter Sylvester [mailto:[email-masked]]
> Sent: Thursday, May 03, 2007 4:28 AM
> To: Jim Schaad
> Cc: 'pgut001'; [email-masked]; [email-masked]
> Subject: Re: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt
> 
> 
> >

I agree with this.  If you make the argument that there are any number of
items you want to do this for, then you need to have the signer place the
attributes before the body in all cases.  This is the reason that there is a
list of hashes prior to the body for these cases.

This is the reason that I was trying to establish that there was something
other than a message digest which might need to be used in this manner.

Jim

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 03 May 2007 16:32:39 +0200

> list of hashes prior to the body for these cases.
The list of hash algorithms is in front of the data indicating that you 
should use
them because they are later needed. You need this in the document because
the algoritms can change.

I agree that may be a need some additional not secured hints like that 
in order
to calculate something for an attribute, but this can also be done with 
a content-type
or a mime-type or a global document policy.
> other than a message digest which might need to be used in this manner.
I think this may depend on whether there is a structure of the content.
One could think about: "This document doesn't violate IPR or DRM" :-)
or the doc has been virus-checked.

Anyway, I  think the problem is settled, these attributes are behind the 
data?
regards

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 3 May 2007 09:42:29 -0700

Peter,

I don't know that I agree that this is a settled issue.  Here are the
arguments that I see on the issue:

1.  Consistency:  If you want to be consistent with what SignedData and
AuthenticatedData are doing, then you want the attributes following the
body.

2.  Source based attributes:  If you want to include a source based
attribute, that is an attribute which is computed on the content of the body
in a similar manner to MessageDigest.  This argument does not apply to any
attribute which does not need to be computed by BOTH the creator and the
validator. The creator wants the attribute after the body.  The validator
REQUIRES that that either the attribute or an indicator that the attribute
needs to be computed exists before the body.  Attributes of the type that
you suggested below do not influence this argument.  Validations by the
creator on DRM or virus-free can be made, and the message not sent
independent of the location of the attributes package in the block. Note
that the indicator exists for MessageDigest in the case of both SignedData
and AuthenticatedData.

3.  Matching of Algorithms:  The algorithm used can have the attributes
either before or after the body.  This argues that you want to have the
attributes before the body in the message based on the fact that one would
expect the length of the body to be substantially greater than the length of
the attributes.  Thus one would prefer to cache the attributes in the case
they are used last, rather than the body in the case it is used last.

Taking all of the arguments together I think it makes more sense to place
the attributes first.  You lose the consistency but gain for the other two
items.

jim
 
> Sent: Thursday, May 03, 2007 7:33 AM
> To: Jim Schaad

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 04 May 2007 14:48:36 +0200

> AuthenticatedData are doing, then you want the attributes following the
Consistency is not always a good argument, s**t must be good because 
zillions of
flies little, thus.. :-)
> that the indicator exists for MessageDigest in the case of both SignedData
I am talking about an attestation that says that the data have been 
validated or a warning:
I am not talking about not sending the data, i.e. not revealing the 
content. A signature
verification service can add an unsigned attrute on the fly after the 
data in a similar
way.

Attestion the result that you are virus free etc cannot be made if you 
assume streaming
at the client side. If you assume that the client can make something on 
the data
and then set the result before the data, then I would ask why this is 
not made with
SignedData and the messageDigest, you wouldn't encode the algorithm twice.

I am not convinced that we assume that a client is required to buffer 
anything
in order to be able to encode a signedAttribute before the data.

Encoding attributes before mean in any case that the client need to read the
data twice or buffer it. Avoing this by using an appropriate encoding 
structure
is something that I always thought is one of the important things in 
pkcs7/cms?

> they are used last, rather than the body in the case it is used last.
If you want to create a messageDigest and to verify it, then
in case of a fixed hash algorithm you just encode the messagedigest 
after the
data, no caching of whatever.
In order to indicate the algorithm to the verifier you either could put the
messagedigest before but then the creator has to buffer the data
(while computing the digest), therefore we just encode a hint about the
algo identifier allowing the verifier also to stream. Whether the
verifier reveals the data is another story, i.e. what it does after 
verifying the
messagedigest or signatures.
> the attributes first.  You lose the consistency but gain for the other two
No, you may loose the possibility for the client to stream.

hm, it seems we are still out of sync. :-)
>>> I agree with this.  If you make the argument that there are any
>>>       
>> number of
>>     
>>> items you want to do this for, then you need to have the signer place
>>>       
>> the
>>     
>>> attributes before the body in all cases.  This is the reason that
>>>       
>> there is a
>>     
>>> This is the reason that I was trying to establish that there was
>>>       
>> something
>>     
>>> other than a message digest which might need to be used in this
>>>       
>> manner.
>>

---

From: Russ Housley <[email-masked]>
Date: Fri, 04 May 2007 17:19:04 -0400

>have maximum information about what to do with the data.

When faced with streaming trade-offs in the past, we have usually 
considered the recipient as the one that needs to be able handle the 
stream efficiently.  This is because there are many situations where 
there is one originator and many recipients.

Russ

---

From: [email-masked] (Peter Gutmann)
Date: Mon, 07 May 2007 15:17:26 +1200

Russ Housley <[email-masked]> writes:

>When faced with streaming trade-offs in the past, we have usually considered
>the recipient as the one that needs to be able handle the stream efficiently.
>This is because there are many situations where there is one originator and
>many recipients.

This is a very email-centric view.  I know of a number of applications
involving secure transmission of content from sensing devices (medical imaging
for example, which generates huge uncompressed images) and security monitoring
where the sender has minimal resources and the receiver has all the storage
and processing power.

Peter.

---

From: Peter Sylvester <[email-masked]>
Date: Mon, 07 May 2007 10:58:24 +0200

"we" is who, and when had you/they been faced with such a problem?

I do not see may places where a creator/sender has been penalized by that
(except may when DER encoding is required).

---

From: Russ Housley <[email-masked]>
Date: Mon, 07 May 2007 09:39:42 -0400

Originally, the authors of PKCS#7, and then the S/MIME WG.

Russ

---

From: Russ Housley <[email-masked]>
Date: Mon, 07 May 2007 09:32:09 -0400

Peter:

I can imagine many applications where the originator performs 
encryption, and no recipient even process the result.  One example is 
an archive, where recovery from the archive is a rare event.

I can also imagine many applications where there is a single 
originator and a single recipient are involved.  The use of CMS in 
SIP in the simple cases is an example.

I can think of many applications, not just email, where there is a 
single originator and many recipients.  RFC 4108 (the protection of 
firmware images) is one non-email example.

As you point out, there can also be an asymmetry in the resources 
available to the originator and the recipient.  This asymmetry can 
occur in each of the scenarios listed above.

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.

Russ