John:
1) General comment: Since there are multiple techniques for using the RSA
algorithm, please replace all occurrences of "RSA" with "RSA (PKCS #1 v1.5)"
as appropriate.
I put "(PKCS #1 v1.5)" several places. When the new draft comes out, you
can tell me if I should have put it any other places.
2) Section 1, para 2: Please change "implantations" to "implementations".
Done.
3) Section 1, para 3: Please change "Algorithm are be identified" to
"Algorithms can be identified".
I changed it to "Algorithm are identified"
4) Section 1, para 3: Please change:
OLD: "The algorithm identifiers for each algorithm are specified"
NEW: "The algorithm identifier for each algorithm is specified"
Done.
5) Table 1, title: Please change "Implantation" to "Implementation".
Done.
6) Table 1, Symmetric KEK Wrap note: Please add this note to immediately
follow the table: "Note 2: Only those CMS implementations that support the
previously-distributed symmetric KEK or key agreement key management
techniques MUST implement the Triple-DES Key Wrap algorithm." An alternate
solution is to change the table such that "Triple-DES Key Wrap" is a SHOULD
implement requirement.
I disagree. My understanding from the discussion is that we want to
encourage support for mail lists, so we are requiring support for the key
wrap algorithm and previously distributed KEKs.
7) Table 1: I believe that a row should be added to represent key derivation
algorithms since the password-based key management technique is documented
in the rfc2630bis-01 I-D. The draft-ietf-smime-password-03.txt I-D includes
the PBKDF2 [RFC2898] key derivation algorithm as a MUST implement
requirement, so I recommend that the following row should be added to Table
1:
Algorithm Type MUST implement SHOULD implement
-----------------------------------------------------------------
Key Derivation PBKDF2 [RFC2898] --
Done.
8) Table 1. Key Derivation Note: Please add this note to immediately follow
the table: "Note 3: Only those CMS implementations that support the
password-based key management technique MUST implement the PBKDF2 [RFC2898]
key derivation algorithm." An alternate solution would be to change the
table to include the PBKDF2 [RFC2898] key derivation algorithm as a SHOULD
implement requirement, but then it would not be consistent with the
draft-ietf-smime-password-03.txt I-D.
Done.
9) Table 1, Message Authentication note: Please add this note to
immediately follow the table: "Note 3: Only those CMS implementations that
support the AuthenticatedData content-type MUST implement the HMAC with
SHA-1 algorithm."
Done. Here is the updated table (view it in a fixed pitch font):
Table 1. CMS Implementation Algorithm Requirements
Algorithm Type MUST implement SHOULD implement
-----------------------------------------------------------------
Message Digest SHA-1 MD5
Signature DSA and RSA (1) --
Key Management
Key Agreement -- X9.42 E-S D-H
Key Transport RSA --
Symmetric KEK Wrap Triple-DES Key Wrap RC2 Key Wrap
Key Derivation PBKDF2 (2) --
Content Encryption Triple-DES CBC RC2 CBC
Message Authentication HMAC with SHA-1 (3) --
Note 1: CMS implementations MUST be able to verify signatures
with both DSA and RSA (PKCS #1 v1.5), and they MUST be
able to generate signatures with at least one of them.
Note 2: Only those CMS implementations that support password-
based key management MUST implement the PBKDF2 key
derivation algorithm as specified in RFC 2898 [PKCS#5].
Note 3: Only those CMS implementations that support
authenticated-data MUST implement the HMAC with SHA-1
algorithm as specified in RFC 2104 [HMAC].
10) Section 2, intro, 3rd para: Please replace:
OLD: "Digest values are located in the DigestedData digest field, and digest
values are located in the Message Digest authenticated attribute."
NEW: "Digest values are located in the DigestedData digest field and Message
Digest attribute."
Done.
11) Section 4, intro: Please change as follows:
OLD: "CMS accommodates three general key management techniques: key
agreement, key transport, and previously distributed symmetric
key-encryption keys."
NEW: "CMS accommodates the following general key management techniques: key
agreement, key transport, previously distributed symmetric key-encryption
keys, and passwords."
Done.
12) Section 4.1, 2nd para: Please change the following:
OLD: "CMS implementations MUST include Triple-DES wrapping of Triple-DES
content-encryption keys and RC2 wrapping of RC2 content-encryption keys."
NEW: "CMS implementations that support the key agreement key management
technique MUST implement Triple-DES wrapping of Triple-DES
content-encryption keys and SHOULD implement RC2 wrapping of RC2
content-encryption keys."
This one is not so simple. I agree that these are required to support key
agreement, but they are also required to support previously distributed
KEKs. RFC 2630 simply requires them, and I think that we should continue
to do so to encourage the implementation of mail lists.
13) Section 4.3, 1rst para, 1rst sent: Please change MUST to SHOULD in the
following sentence: "CMS implementations MUST support symmetric
key-encryption key management." I don't believe that the S/MIME working
group has ever agreed that the previously-distributed symmetric KEK key
management technique is a MUST implement requirement.
As above, RFC 2630 requires implementation of the key wrap, and I think
that we should continue to do so to encourage the implementation of mail lists.
14) Section 4.3, 1rst para, 2nd sent: Please change the following:
OLD: "CMS implementations MUST include Triple-DES key-encryption keys
wrapping Triple-DES content-encryption keys."
NEW: "CMS implementations that support the previously-distributed symmetric
KEK or key agreement key management techniques MUST include Triple-DES
key-encryption keys wrapping Triple-DES content-encryption keys."
As above, RFC 2630 requires implementation of the key wrap, and I think
that we should continue to do so to encourage the implementation of mail lists.
15) Section 4.4, Please add:
"4.4 Key Derivation Algorithms
Key derivation algorithms are used to convert a password into a KEK as part
of the password-based key management technique. CMS implementations that
support the password-based key management technique MUST implement the
PBKDF2 [RFC2898] key derivation algorithm. The
KeyDerivationAlgorithmIdentifer identifies the key-derivation algorithm, and
any associated parameters, used to derive the KEK from the user-supplied
password. The object identifier for the PBKDF2 [RFC2898] key derivation
algorithm is TBD."
Here is the text that I added to create section 4.4:
4.4 Key Derivation Algorithms
Key derivation algorithms are used to convert a password into a key-
encryption key as part of the password-based key management
technique. CMS implementations that support the password-based key
management technique MUST implement the PBKDF2 key derivation
algorithm specified in RFC 2898 [PKCS#5].
Key derivation algorithms identifiers are located in the
EnvelopedData RecipientInfos PasswordRecipientInfo
keyDerivationAlgorithm and AuthenticatedData RecipientInfos
PasswordRecipientInfo keyDerivationAlgorithm fields.
The key-encryption key that is derived from the password is used to
encrypt the content-encryption key
The content-encryption keys encrypted with password-derived key-
encryption keys are located in the EnvelopedData RecipientInfos
PasswordRecipientInfo encryptedKey field. The message-authentication
keys encrypted with password-derived key-encryption keys are located
in the AuthenticatedData RecipientInfos PasswordRecipientInfo
encryptedKey field.
4.4.1 PBKDF2
The PBKDF2 key derivation algorithm specified in RFC 2898 [PKCS#5].
The KeyDerivationAlgorithmIdentifer identifies the key-derivation
algorithm, and any associated parameters, used to derive the key-
encryption key from the user-supplied password. The algorithm
identifier for the PBKDF2 key derivation algorithm is:
id-PBKDF2 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-5(5) 12 }
The AlgorithmIdentifier parameter field MUST be PBKDF2-params:
PBKDF2-params ::= SEQUENCE {
salt CHOICE {
specified OCTET STRING,
otherSource AlgorithmIdentifier },
iterationCount INTEGER (1..MAX),
keyLength INTEGER (1..MAX) OPTIONAL,
prf AlgorithmIdentifier DEFAULT hMAC-SHA1 }
16) Section 5, 1rst para: Please change "MS" to "CMS" in the following: "MS
implementations SHOULD support Two-Key Triple-DES in CBC mode."
Done.
17) Section 7, 1rst paragraph: Please change the following:
OLD: "CMS implementations MUST include encryption of a Triple-DES
content-encryption key with a Triple-DES key-encryption key using the
algorithm specified in Sections 7.2 and 7.3."
NEW: "CMS implementations that support the previously-distributed symmetric
KEK or key agreement key management techniques MUST include encryption of a
Triple-DES content-encryption key with a Triple-DES key-encryption key using
the algorithm specified in Sections 7.2 and 7.3."
As above, RFC 2630 requires implementation of the key wrap, and I think
that we should continue to do so to encourage the implementation of mail lists.
18) Section 7.2, bullet 2: Please change "Section 12.6.1" to "Section 7.1".
Done. Thanks for the careful read necessary to catch this one.
19) Section 7.3, bullet 7: Please change "Section 12.6.1" to "Section 7.1".
Done.
20) Section 7.4, bullet 4: Please change "Section 12.6.1" to "Section 7.1".
Done.
21) Section 7.5, bullet 7: Please change "Section 12.6.1" to "Section 7.1".
Done.
22) Security Considerations: Please delete the countersignature section
because it is much more applicable to the rfc2630bis-01 I-D.
Done.
Russ