Jack Lloyd <lloyd(_at_)randombit(_dot_)net> writes:
On Mon, 17 Nov 2003, Bonatti, Chris wrote:
To take on a couple of the questions that Peter didn't
address...
Jack Lloyd <lloyd(_at_)randombit(_dot_)net> writes:
3) It is legal to include SignedAttributes and sign
everything
that way even when signing plain data content, correct?
Yes, this is basically what SignedData is for. %-}
Maybe I'm not grokking the question.
When signing something other than plain data content, using
the attributes is required (section 5.3 of 3369). Otherwise,
they are described as "optional"; I'm presuming this means an
implementation MAY use signed attributes when signing plain
data content as well? It is all-in-all fairly clear, but I
would prefer being 100% certain I know what it's trying to
say. When an RFC isn't completely and totally clear, I don't
like to just assume I'm guessing the correct interpretation.
The 'signedAttrs' field is an old function that goes back to
PKCS-7 (i.e., the 'authenticatedAttributes' field). It has
always been an option to include signed attributes in the
signature regardless of the type. I think the reason for the
requirement to include these for content types other than id-data
stems from the desire to have the PKCS-9 'ContentType' attribute
included to bind the type to the data. There has always been a
perception that MIME content was the "default" for PKCS-7. This
is supported by the fact that a MIME object is easily recognized,
and self-identifies what type(s) it carries. This is not true
for many other possible object types. I think that the
requirement to include the 'ContentType' attribute originally
comes from PKCS-9, though, not PKCS-7. There is no converse
requirement to omit signed attributes when signing MIME data.
I hope this helps.
Chris