John,
Here are my responses to your comments.
-----Original Message-----
From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of Pawling,
John
Sent: Tuesday, July 03, 2001 8:31 AM
To: Ietf-Smime (E-mail)
Subject: RE: Jim's Comments: draft-ietf-smime-cmsalg-00
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.]
If present, the parameters field MUST contain an ASN.1 NULL.
Implementations SHOULD generate SHA-1 AlgorithmIdentifiers with NULL
parameters.
I believe that the second line is a MUST not a SHOULD. I don't object to
the SHOULD handle if it is wrong, but generation needs to be with NULL
parameters.
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.]
John -- If I look in the examples draft, the OID that is in the
signatureAlgorithm field of a SignerInfo field is
119 30 13: SEQUENCE {
121 06 9: OBJECT IDENTIFIER
: sha1withRSAEncryption (1 2 840 113549 1 1 5)
: (PKCS #1)
132 05 0: NULL
: }
Not RSA. I don't have the foggiest idea of what you are talking about for
backwards compatability. This is not an argument that I have ever heard
before (I think).
I think you have not looked at this correctly and ask that you re-check what
I am saying.
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.]
I agree that the paragraphs describing how to use the different fields does
need to be included.
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.".]
This seems fine.
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."]
I stand by my original comment. This is a duplication of a MUST and should
be where it makes sense (where the algorithm is used) not here.
===========================================
John Pawling, John(_dot_)Pawling(_at_)GetronicsGov(_dot_)com
Getronics Government Solutions, LLC
===========================================
jim