Russ,
I agree with your suggestions for Sections 5.1, 5.3 and 5.4.
However, for your reply on my support of extensibility on Section 6, I have
send you my response on another thread.
Francois Rousseau
AEPOS Technologies
Russ Housley wrote:
Francois:
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."
Since this is really a restatement of the discussion already present in the
version discussion. Therefore, I suggest the following: "As discussed
above,
if attribute certificates are present, 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."
How about: "A content-type attribute having as its value the content type
of the
EncapsulatedContentInfo value being signed. Section 11.1 defines the
content-type attribute. The content-type is not required when used as
part of
a countersignature unsigned attribute as defined in section 11.4."
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."
How about: "Since the SignedAttributes value, when present, must contain the
content type and the content message digest attributes, those values are
indirectly included in the result. The content-type is not required when
used
as part of a countersignature unsigned attribute as defined in section 11.4."
Sec 6, I agree with others that it would be preferable if EnvelopeData was
also extensible per message and/or per recipient.
I recall a long discussion concerning this issue. My recollection is that
maintaining backward compatibility with S/MIME v2 and PKCS#7 v1.5 was more
important than this extensibility.
Russ