On Dec 17, John wrote in part:
2) Sec 2.10, ContentHints section: Change "Messages that contain a
signed
receipt MUST include this attribute with the
receipt value set to TRUE." to "When a SignedData/Receipt is
encapsulated by
another SignedData object, then the sending agent SHOULD include a
ContentHints attribute (with receipt set to TRUE) in the
authenticatedAttributes of the outermost SignedData object. For
example, if
a SignedData/Receipt is encrypted within an EnvelopedData object which
is
then signed using an outer SignedData object, then the outer SignedData
object should include a ContentHints attribute with receipt set to
TRUE."
Also, I believe that ESS Sec 1.3.4 should be left as is. It implies
that a
contentHints attribute does not necessarily need to be authenticated.
When
the contentHints includes a contentDescription and receipt set to FALSE,
then it does not necessarily need to be authenticated. I believe that
the
ESS spec should continue to include the flexibility to
support that option. When the contentHints includes receipt set to
TRUE,
then it should be authenticated.
[Jim Schaad]
I agree that this is a good idea. The concept of having all of the
information be placed into the authenticated attributes multiple times
to be redundent and therefore we should avoid it.
I would however like to propose a change to the contentHints type which
I think will greatly improve it and potentially lead it to being used in
more situtations as above. Specifically I would like to see more
accurate information being carried by the contentHints attribute.
Proposal:
1. Change the ASN.1 for the type to be
ConentHints ::= SEQUENCE {
contentDescription DirectoryString OPTIONAL,
contentType OID }
2. Replace the final paragraph of section 2.10 with the following:
The contentDescription field may be used to provide information that the
recipient may use to select protected messages for processing, such as a
message subject. If this field is set, then the attribute is expected
to appear on the signedData object enclosing an encrypted data object
and not on the inner signedData object.
Messages which contain a signed data wrapped around an encrypted data
object, thus masking the inner content type of the message SHOULD
include a content hint attribute except for the case of the data content
type. Specific message content types may either force or preclude the
inclusion of the content hints attribute. For example,signed receipts
state that a contentHint MUST be included if encryption is to be added.
3. Change section 2.4 bullet 6.1
6.1 If a receipt is to be enclosed in an encryption layer, an outer
signedData object must be created and a contentHints attribute SHOULD be
created and added to the SignerInfo structure's authenticated
attributes.