1. Should the X.400 on hetrogenous messaging be expanded to X.400/P1 similar
to SMTP/MIME
2. Section 1.0 bullet 4: Should be Heterogeneous Message Formats not
transports.
The problem is if you cannot carry the S/MIME content type not the wrapper
on the message. (Microsoft Exchange actually uses X.400 headers with a custom
content type for internal replication last time I checked and this did not break
signatures on these messages as the MIME structure was carried intact.)
3. Section 1 last paragraph: change to more standard wording on MUST.
4. Section 2.1 formatting problem: "signature(if present)using" goes to
"signature
(if present) using"
5. Section 2.2 - remove MAY from the last sentence. This is a reason to do
the signatures, but is not part of the protocol definition. -- change MAY to
could.
6. Section 2.3 - ditto above comment for first sentence. You can do this, but
it is not part of the protocol defintion. change MAY to can.
7. Section 3.0 bullet 1: change "will be id-data" to "MUST be id-data"
8. Section 3.0 bullet 1: This concept bothers me. I think that there may be
some programs out there that assume atleast one signature in a signed data
object
except for cases such as degenerate certs only messages.
9. Section 3.0 bullet 1: A better term for this might be a null (or empty)
signature
layer. This will difference the concept from the discussions about signing
with the NULL signature algorithm.
10. Section 3.0 bullet 2: This not clear about the presence (or absense) of
a MIME layer. If MIME layer exists, then I fail to see the need for bullet
1 at all.
11. Section 3.0 Para 1: Simple example of why counter-signature and parallel
signatures do or don't work for this might be called for.
12. Section 3.1.1 Paragraph 5 - Apears to imply that cn="Jim Schaad -
review-authority"
is legal (difference between 'in' and 'as'. Additionally you might want to
do capitalization here as utf8 strings do not do case insensitive name
compararisions
(i.e. Review-Authority). Also is cn="Jim Schaad" cn="review-authority" legal?
[By definition I think that this would only need to be done if the review was
on the innermost signature layer. On outer layers I don't believe the intent
was that name checking of the certificate and sender should occur otherwise
signing MLAs will create lots of havoc.]
13. Section 3.1.1 Paragraphy ? - Should "domain-signing-authority(_at_)com" be
explicity
forbidden?
14. Section 3.1.1 Last Paragraphy - Please soften last sentence. The correct
action should be to flag sender/certificate mismatch not to reject as invalid.
15. Section 3.1.2 Paragraph 4 - Please tell me where [CMS] provides a
description
of generating and processing siganture types. I believe that you meant "All
signatures are processed..."
16. Section 3.1.2 Paragraph ~5 - Please put text in to OID definition using
the -- comment syntax of ASN. i.e.
id-aa-sigtype-domain-signature :: OBJECT ID {....}
-- Domain Signature
17. Section 3.1.2 Paragraphy last - 3 - Please remove or refine text about
originator
signature not ecapuslating other signatures -- you are eleminating triple
wrapped
signature from existance (i.e. S2(E(S1(M))) where S1 and S2 are by the
originator.
18. Section 3.1.2 Paragraph last-2 - Can different SignerInfos at the same level
have different content in the SigantureType attribute or not?
19. Section 3.2 Paragraph 4 - If this siganture is to be kept around, you must
remove the mlaExpansion or the first MLA outside will strip the domain signature
from the message.
20. Section 3.2 Paragarph 11 - Why is this only a MAY. It would appear that
the correct statement is MUST as otherwise the whole process is wasted.
21. Section 3.2 Paragaph ? - Where and how did you get the FROM address in
the message. Unless you make a statement about including the SMTP headers at
the time of wrapping all you get is the MIME headers which do not include this
information. (i.e. this is never going to happen unless you call for it to
happen.)
22. Section 3.2 Last Paragraph - Change to make a statement about a single layer
as well (or instead of).
23. Section 3.3 Paragraph 4 - did you mean to reference ESS not CMS?
24. Section 3.3 Bullet 1 - If I have S1(S2(S3(M))). S1 has an equivalent label,
S2 and S3 both have labels, and the labels are different. Is the equivalent
label the same as both labels or only one?
25. Section 3.3 Paragraphy Last-2 - This MAY should be a MUST
26. Section 3.3 Paragarph Last - ditto froms ection 3.3
27. Section 3.5 - By default you can have multiple originator signatures
(potentially
with different algorithms) in a message. So the restriction in this section
makes no sense.
28. Section 4 - Where on this table would you put the case of Originator
Encrypts
to Recipient Domain which encrypts to Receipient? It would appear to be an
instance of (a), (b) and (c).
29. Section 4 Paragraphy Last-2 - How can I possibly enforce this? For Key
Transport the sender is anonymous, for Key Agreement the senders certificate
is often not examined. Additionally the domain component could change so that
does match -- or it might be my domain component that did the re-enecryption
and would therefore match my domain name and not the senders domain name.
30. General - Please include ASN.1 module at the end with a list of all defined
OIDs and structures. Get module oid from Russ. (This request is just pure
lazyness on my part but makes some things easier.)
31. General - Do we need to specify the big brother syndrome at this time
(encrypt
for end-entity and for DCA)?
jim schaad
http://www.nwlink.com