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