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