Jim Schaad wrote:
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.
Consistency is not always a good argument, s**t must be good because
zillions of
flies little, thus.. :-)
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.
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?
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.
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.
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.
No, you may loose the possibility for the client to stream.
hm, it seems we are still out of sync. :-)
jim
-----Original Message-----
From: Peter Sylvester [mailto:Peter(_dot_)Sylvester(_at_)edelweb(_dot_)fr]
Sent: Thursday, May 03, 2007 7:33 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
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.
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.
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.
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
smime.p7s
Description: S/MIME Cryptographic Signature