Russ,
Here are few comments.
Sec 5.1, based on how the last sentence of the definition of the SignedData
"certificates" field currently reads, if no attribute certificates are
present although the content type may be other than id-data, the version
could be misinterpreted to be 1. I would suggest that the last sentence of
this definition be amended as follows:
"If no attribute certificates are present in the collection and the
encapsulated content type is id-data, then the value of version shall be 1.
However, if attribute certificates are present or the encapsulated content
type is other than id-data, then the value of version shall be 3."
Sec 5.3, the definition of the SignerInfo "signedAttributes" field
indicates that both the "content-type" and the "message-digest" attributes
must be present if the field is present. However, this does address the
exception created by the "countersignature" attribute in Sec 11.4 where it
is indicated that the signedAttributes field need not contain a
content-type attribute, as there is no content type for countersignatures.
To address this, I would suggest that the statement on the "content-type
attribute" under the SignerInfo "signedAttributes" field reads as follows:
"A content-type attribute having as its value the content type of the
EncapsulatedContentInfo value being signed except within a
countersignature, as there is no content type for countersignatures.
Sections 11.1 and 11.4 respectively define the content-type and the
countersignature attributes."
Sec 5.4, similarly as Sec 5.3 above, the fourth sentence of the second
paragraph should be amended to read as follows:
"Since the SignedAttributes value, when present, must contain the message
digest and the content type attributes, except within a countersignature,
those values are indirectly included in the result."
Sec 6, I agree with others that it would be preferable if EnvelopeData was
also extensible per message and/or per recipient.
Francois Rousseau
AEPOS Technologies