All,
I have the following comments regarding Jim Schaad's 7 June comments to the
draft-ietf-smime-cmsalg-00.txt Internet-Draft. My comments [JP] are
numbered consistently with Jim's original message. I omitted Jim's comments
with which I agree.
2) Section 2.1: Jim stated: "I believe that the MUST and SHOULD statements
in this paragraph are in conflict. ie. MUST encode as and SHOULD generate
with. These should be resolved as MUST in both locations."
[JP: I disagree with Jim that the MUST and SHOULD statements are in
conflict. The paragraph states: "If present, the parameters field MUST
contain an ASN.1 NULL." In my opinion, it is clear that the MUST
requirement does not apply if the parameters field is absent. I also
disagree with Jim's recommendation to change the spec to state that
implementations MUST populate the algorithmIdentifier parameters field with
an ASN.1 NULL. I believe that the text should remain unchanged.]
6) Section 3.2: Jim stated "Boy we really messed this one up. Section 3.2
should occur
as two different sections one for RSAwithMD5 and one for RSAwithSHA1. I
will never understand how all of us missed this one.
The OIDs for this should be:
sha1withRSAEncryption (1 2 840 113549 1 1 5)
or
#define szOID_OIWSEC_sha1RSASign "1.3.14.3.2.29"
md5withRSAEncryption (1 2 840 113549 1 1 4)"
[JP: I disagree with Jim's statements. To support backwards compatibility
with S/MIME v2 implementations that only recognize the rsaEncryption OID, we
specified that the rsaEncryption OID must be included in the signedData
signerInfo signatureAlgorithm field. We decided not to specify the use of
the sha-1WithRSAEncryption, md2withRSAEncryption, or md5withRSAEncryption
OIDs in the signerInfo signatureAlgorithm field.]
7a) Section 4.1, para 2: Jim stated: "There is a different in language
here.
- if ContentEncryptionAlg MUST KEK Alg.
- SHOULD 3DES KEK
- SHOULD RC2 KEK
- MUST 3DES KEK on 3DES Content
- MUST RC2 KEK on RC2 content.
Let me make a new stab at this:
Keep para 1 from section 4.1.
The following is the rest of section 4.1:
A key agreement algorithm consists of the following items:
1. A shared secrect computation that takes the originator and receipient
keys and computes a shared secret.
2. A symmetric key derivation algorithm that uses the shared secret to
compute a symmetric key.
3. A key-wrap algorithm which uses the symmetric key generated by 2 to
encryption the CEK producing the value encded in the CMS kari structure."
[JP: I do not object to the addition of Jim's new text (bullets 1-3 above),
but I do object to the deletion of the remainder of section 4.1 (i.e.
paragraphs 2-7). I believe that text is necessary to explain the use of the
KeyAgreeRecipientInfo fields.]
7b) Jim stated:
"4.1.1 X9.42 Ephemeral-Static Diffie-Hellman
The shared-secret computation and symmetric key derivation algorithms for
Ephemeral-Static Diffie-Hellman key agreement are defined in RFC 2631
[DH-X9.42]. E-S D-H uses the KEK algorithms defined in section 4.3 for
the key wrap algorithm. ES DH MUST support the 3DES KEK for key wrapping.
ES DH SHOULD support RC2 KEK for key wrapping."
[JP: I agree with the intent of Jim's comments. Recommend that the
following sentences should replace the first sentence in section 4.1.1, para
1:
"The shared-secret computation and symmetric key derivation algorithms for
Ephemeral-Static (E-S) Diffie-Hellman (D-H) key agreement are defined in RFC
2631 [DH-X9.42]. The key wrap algorithms defined in section 4.3 of this
document are used in conjunction with E-S D-H. CMS implementations that
include E-S D-H MUST support the use of Triple-DES key-encryption keys to
wrap Triple-DES content-encryption keys and SHOULD support the use of RC2
key-encryption keys to wrap RC2 content-encryption keys."]
7c) Jim stated: "keyEncryptionAlgorithm MUST be the id-alg-ESDH algorithm
<< Changed
identifier. The algorithm identifier parameter field for id-alg-
ESDH is KeyWrapAlgorithm, and this parameter MUST be present. The
<< Changed
KeyWrapAlgorithm denotes the key wrap algorithm used
<< Changed
to encrypt the content-encryption key with the pairwise key-
encryption key generated using the X9.42 Ephemeral-Static Diffie-
Hellman key agreement algorithm. The document uses the KEK algorithms
defined in section 4.3 as the key wrap algorithms. The KEK algorithm used
is defined in the KeyWrapAlgorithm parameter."
[JP: I agree with Jim's comments, except that I believe that the last
sentence should be deleted because it is redundant with the third sentence.
Also, I recommend the following wordsmithing of the fourth sentence: "The
document uses the key wrap algorithms defined in section 4.3.".]
7d) Jim stated: "New requirement: When deriving a Triple-DES key, a three
key Triple-DES key
MUST be derived. When deriving a Triple-DES key wrap key, the parity on
each of the three sub-keys MUST be correctly generated after the key
derivation process is complete."
[JP: Agree.]
12) Section 7: Jim stated: "I do not believe this section needs any MUSTS
for inclusion
of algorithms. That is covered in section 4."
[JP: Rather than delete the first sentence of Section 7, I believe that it
should be changed to: "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."]
===========================================
John Pawling, John(_dot_)Pawling(_at_)GetronicsGov(_dot_)com
Getronics Government Solutions, LLC
===========================================