Subject: RE: cmsalg-00 Comments

From: "Pawling, John" <[email-masked]>
Date: Thu, 5 Jul 2001 13:50:11 -0400

Jim, 

Thank you for your responses to my comments.  My responses are included in
the message below.  

===========================================
John Pawling, [email-masked]
Getronics Government Solutions, LLC
===========================================

-----Original Message-----
From: Jim Schaad [mailto:[email-masked]]
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, [email-masked]
> Getronics Government Solutions, LLC
> ===========================================
>

jim