Jim,
Thank you for your responses to my comments. My responses are included in
the message below.
===========================================
John Pawling, John(_dot_)Pawling(_at_)GetronicsGov(_dot_)com
Getronics Government Solutions, LLC
===========================================
-----Original Message-----
From: Jim Schaad [mailto:jimsch5(_at_)home(_dot_)com]
Sent: Tuesday, July 03, 2001 6:46 PM
To: 'Pawling, John'; 'SMIME WG (E-mail)'
Subject: RE: cmsalg-00 Comments
John,
Here are the comments I have:
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.
[Jim: I thought about recommending this change as well. The reason that I
did not
was that the only reference in the document was to the v1.5. I could go
either way on this issue.]
[John: I too could go either way on this issue. cmsalg-00 already defines
the techniques for using the RSA algorithm. Section 3.2 states: "The RSA
signature algorithm is defined in RFC 2437 [NEWPKCS#1]". Section 4.2.1
states: "The RSA key transport algorithm is the RSA encryption scheme
defined in RFC 2313 [PKCS#1]." However, the security considerations section
does discuss PKCS #1 v2.0. In summary, I will leave it up to Russ. I will
not object if he ignores this comment.]
3) Section 1, para 3: Please change "Algorithm are be identified" to
"Algorithms can be identified".
[Jim: I disagree with this change. The correct text is "are" as this is the
only
way we are identifing these algorithms. If you think it should be "can",
please show another way that they can be identified.]
[John: I agree with you. Recommend that the text should be changed from
"Algorithm are be identified" to "Algorithms are identified".]
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.
[Jim: I disagree with the addition of this node. I don't think that the
table is
where this should be specified. This type of text belongs with the
algorithm description.]
[John: Section 1 states: "Table 1 summarizes the algorithms that CMS
implantations MUST support and SHOULD support." Without the addition of the
recommended note, then Table 1 incorrectly states that Triple-DES Key Wrap
and HMAC with SHA-1 are MUST algorithms for all CMS implementations. That
is not true. 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. Similarly,
only those CMS implementations that support the AuthenticatedData
content-type MUST implement the HMAC with SHA-1 algorithm. If my
recommended notes are not added, then Table 1 must be changed to indicate
that Triple-DES Key Wrap and HMAC with SHA-1 are SHOULD algorithms for all
CMS implementations. In that case, I would agree that the text in the
algorithm description sections could include the notes that I recommended.
In summary, I believe that Table 1 must state the MUST requirements to be
consistent with the following message sent by Russ following the March 2001
S/MIME working group meeting:
"At the face-to-face S/MIME WG meeting yesterday, we came to consensus on a
new set of mandatory to implement algorithms. The people present
overwhelmingly agreed on the following:
Encryption: Triple-DES
Key Mgmt: RSA (using PKCS #1 v1.5)
Msg Digest: SHA-1
Signature: DSA and RSA (using PKCS #1 v1.5)
On signature, we will require that implementations are able to verify
signatures on certificates and messages using both algorithms; however,
implementations are required to generates signatures on messages using at
least one of the signature algorithms."]
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] --
[Jim: I agree that this item needs to be added, however the full PBKDF2 is
not
what is currently specified by the document. The password algorithm
information should be added to this document and the MUST should reference
this document.]
[John: Recommend that Peter Gutmann and/or yourself should propose the text
to be added to this document.]
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.
[Jim: See my comment on item #6]
[John: Without the addition of the recommended note, then Table 1 would
incorrectly state that PBKDF2 [RFC2898] is a MUST algorithm for all CMS
implementations. That is not true. Only those CMS implementations that
support the password-based key management technique MUST implement the
PBKDF2 [RFC2898] key derivation algorithm. If the note is not added, then
Table 1 must indicate that PBKDF2 [RFC2898] is a SHOULD algorithm for all
CMS implementations. In that case, I would agree that the text in the
password-based algorithm description section could include the note that I
recommended.]
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."
[Jim: See my comment on item #6]
[John: Please see my response to item #6]
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.
[Jim: I strongly support the original text. This is a case where CMS and
S/MIME
have different requirements and that is reflected in this text. CMS needs
to support KEK while S/MIME does not.]
[John: Why is supporting "symmetric KEK management" a MUST requirement for
CMS? The S/MIME WG decided that RSA (PKCS #1 v1.5) will be the only MUST
implement key management algorithm. Symmetric KEK algorithms are not
required to support the use of RSA (PKCS #1 v1.5) in conjunction with the
key transport key management technique. Furthermore, RFC 2630 does not
state that supporting the previously-distributed symmetric KEK key
management technique (i.e. KEKRecipientInfo type) is a MUST requirement.
Are you making that proposal? Am I missing something? In summary, I still
believe that my recommended change should be made.]
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."
[Jim: See response to #13. If that does not change then this does not need
to
change.]
[John: Please see my response to #13. I still believe that my recommended
change should be made.]
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."
[Jim: I agree that this needs to be included, however the text is more
complicated
that this and needs to reflect the current state of the password document.]
[John: Recommend that Peter Gutmann and/or yourself should propose the text
to be added to this document.]
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."
[Jim: Ditto for response #14]
[John: Please see my response to #13. I still believe that my recommended
change should be made.]
===========================================
John Pawling, John(_dot_)Pawling(_at_)GetronicsGov(_dot_)com
Getronics Government Solutions, LLC
===========================================
jim