After reviewing the latest draft, I have a few issues and corrections I
would like to see in it.
1. Section 1.1.2 - I would like to see this document become agnostic
on the application/signed-data vs. multipart/signed issue. This is the
policy in the new S/MIME V3 documents and I don't think that this
document should attempt to address the issue. There are possible
reasons why the inner signature should be multipart/signed if you have a
gateway that is striping the encryption. And the use of two signedData
and one encryptedData object with base64 encoding leads to a doubling of
the message body size.
2. Section 1.1.3 - There are no longer eight layers of wrapping on the
original message listed. I count 11 items listed. Either we need to
adjust the count in the text, or describe which items in the list are
not really encapsulations.
3. Section 1.3.2 - Change : "attributes of a SignedData object." to
"attributes of any SignedData object" in paragraph 1.
4. Section 1.3.4 - Change contentType to be "MUST BE authenticated"
this is called for in the CMS and PKCS 1.7 specifications if any
attributes are present. The purpose of this attribute unauthenticated
makes no sense and is required authenticated.
5. Section 1.3.4. - Last paragraph : Change the last sentence to
"These attributes are required and must be in the authenticated
attribute section if a receiptRequest attribute is present."
6. Section 2.2.1 - Some issues regarding the existence of multiple
SignerInfo's with receipt requests.
A. Add the following text to paragraph 3. "If ReceiptRequest
are present which conflict, no receipt is to be returned."
B. If there are multiple signerInfos, and I can understand but
cannot verify all of the signatures. Do I send a receipt. My
assumption is "New Paragraph(?) A receipt must be returned if any
signature containing a receipt request can be validated, even if other
signatures containing the same receipt request cannot be validated."
7. Section 2.5 -- Who does a receipt get sent to? It dawned on me
that I was assuming that a receipt is returned to the RFC-822 From field
(reply-to?) in the message. I don't know that is true any more with
multiple signerInfos. Is the receipt mailed to the transport's idea of
who sent the message, or according to the subject/subjectAltName in the
certificate which was used to create the signature?
8. Section 2.7 -- It is nice to know that I should not use 0 or 1 for
BuildinContentType. The problem is that I don't know what I SHOULD put
in to this field. perhaps I'll always leave it blank from fear of being
wrong. Can we get some type of description or verify specific pointer
to what does go into this field. So far the best I have is from John
where he said "Oh -- if you were using this in X400 it make more sense."
9. Section 3.1.1 - Security labels and multiple SignerInfos -- I
disagree with the next to last paragraph. IMHO if any SignedInfo has a
security label, every SignedInfo in the same SignedData object MUST have
the same label. I do not want a security label ignored simply because
somebody else signed the message and did not include a security label.
10. Section 4.1 paragraph 4. I don't know that I agree that it makes
any sense to allow for multiple SignerInfos within the outer SignedData
object which DO NOT have the mlExpansionHistory in the event that any
SignerInfo contains the mlExpansionHistory attribute. The reason that I
worry about this is that there may be loops which will not be detected.
If a MLA understands the ONE SignerInfo which does not contain the
mlExpansionHistory attribute -- it just may go ahead and send the
message with a NEW mlExchangeHistory starting with it and just deleting
the other SignerInfos it was unable to validate. If we are going to
keep this then we need to see some type of justification for it.
11. Section 4.4 paragraph 1 -- Spelling error "ub-ml-expansion-hsitory"
12. Please add a section to Appendix A which contains all of the OIDs
referenced in this document.
Regards
Jim Schaad