1. I just realized there is no abstract for this document. Is one
2. Section 2, p1: s/[CMS] provides/[CMSALG] provides/
3. Section 1.1, p 4: Should there be a dependency/reference to CMSALG here
4. Section 2.5.2, p1: Need to add text for Compression Algorithms.
5. Section 2.5.2: The following statement is no longer true (please
Note that all OIDs associated with the MUST and SHOULD implement algorithms
are included in section A of this document.
6. section 3, p 1: s/[ESS] document provides examples/[ESS] document
s/ESS provides an example of/ESS provides a
7. Section 3.1, p 5, s/implementor/implementer/
Section 3.6, p 3: ditto
Section 4.1, p 2: ditto
- I don't know if that is really an incorrect spelling, but MS Word
does not know it.
8. Section 3.2.1, s/Application/pkcs7-signature/Application/pkcs7-signature
9. Section 3.2.2, p last: Suggest adding the text: "An smime-type
parameters is not intended to give indications of security layers applied in
the event of multiple levels of wrapping."
10. Section 3.4: In general, the multipart/signed form is preferred for
receiving agents SHOULD be able to handle both. --- what is the MUST handle?
Otherwise there is no interop.
11: Section 22.214.171.124: The text
"The SHA-256, SHA-384 and SHA-512 algorithms [FIPS180-2] are not
currently supported in S/MIME, and are included here for completeness."
Is only partially correct. They are supported, just not required by this
document. I would like to clean this up by saying this in a tighter
12. Section 4, p 1: s/certification/certificate/
13. Section A: s/prefered/preferred/
14. References: CMSAES = RFC 3565
15. Section 1.1, p 4: s/the Cryptographic Message Syntax/the Cryptographic
Message Syntax document/
16. Is a specification MUST/SHOULD (section 1.1, p4) or the document
(section 1.1, p3) (The same word is used, but in completely different
meanings. Would not be a problem but for the MUST in p4 potentially wanting
to force meaning into p3).
17. Section 2.2, p 3: s/the algorithms/the hash algorithms/
18. Section 2.4.1, p1: s/signedData/SignedData/
- also envelopedData vs EnvelopedData and compressedData vs
signedData does not actually exist in the CMS documents. The type
is SignedData or the concept is signed data. I think we need to clean this
Russ: Please note there is one section in CMS that needs to be
cleaned up in the same way.
19. Section 2.4.1, p1: s/encryptedContentInfo
20. Section 2.4.1, p1: s/in the envelopedData/in the EnvelopedData/
21. Section 2.4.2, p1: Should add "This content type does not provide
22. Section 2.5 title, s/Attribute/Attributes and the/
23. Section 2.5.2, p 3: s/SMIMECapabilites/SMIMECapabilities/
24. I heard this comment at the last IETF meeting from somebody. As I have
had the same problem in a number of cases (esp with doing interop matrixes)
I am throwing it out for your consideration:
The use of the words must, should and may in lower case causes some
confusion dealing with the question of - did the author just forget to
uppercase this or is it really not a protocol statement. SHOULD examine all
instances of these words to see if a different word works just as well.