I was very unclear. Let me try again. Hopefully this will work out
more clearly.
For SignedData, Section 5.4 of RFC 3852 says:
... A separate encoding
of the signedAttrs field is performed for message digest calculation.
The IMPLICIT [0] tag in the signedAttrs is not used for the DER
encoding, rather an EXPLICIT SET OF tag is used. That is, the DER
encoding of the EXPLICIT SET OF tag, rather than of the IMPLICIT [0]
tag, MUST be included in the message digest calculation along with
the length and content octets of the SignedAttributes value.
For Authenticated Data. Section 9.2 of RFC 3852 says:
... A separate
encoding of the authAttrs field is performed for message digest
calculation. The IMPLICIT [2] tag in the authAttrs field is not used
for the DER encoding, rather an EXPLICIT SET OF tag is used. That
is, the DER encoding of the SET OF tag, rather than of the IMPLICIT
[2] tag, is to be included in the message digest calculation along
with the length and content octets of the authAttrs value.
So, the same encoding is used to the computation of the hash value,
but a different initial tag is used in the encoding that is transmitted.
Russ
The same encoding is used At 11:14 AM 4/10/2007, Russ Housley wrote:
Peter:
I'm pleased to listen to implementors on this point. So far, two
have spoken. One suggesting the move to SEQUENCE and one
preferring to use their existing attribute handling
routines. Both said, that it was not a really big deal either
way. Given that input, I went with consistency with AuthenticatedData.
What do you mean with consistency with AuthenticatedData? Isn't
it the same as with SignedData?
Having them before is not what I would call consistant. I think you
may consider two sets.
No. They both use SET, but there is a difference in the first tag
of the DER encoding that is used for the hash value
computation. SignedData has a bit of extra complexity for backward
compatibility. PKCS#7 V1.5 did not have AuthenticatedData, so the
extra complexity is not required.
Russ