Subject: cmsalg-00 Comments

From: "Pawling, John" <[email-masked]>
Date: Mon, 2 Jul 2001 16:44:35 -0400

All,

In my opinion, Russ has done an outstanding job of producing the
draft-ietf-smime-cmsalg-00.txt Internet-Draft.  I agree with the vast
majority of the document.  I have comments as follows:

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.

2) Section 1, para 2: Please change "implantations" to "implementations".

3) Section 1, para 3:  Please change "Algorithm are be identified" to
"Algorithms can be 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" 

5) Table 1, title: Please change "Implantation" to "Implementation".

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.

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]       --

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.  

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."

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."

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."

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." 

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.

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."  

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."

16) Section 5, 1rst para: Please change "MS" to "CMS" in the following: "MS
implementations SHOULD support Two-Key Triple-DES in CBC mode."

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."

18) Section 7.2, bullet 2: Please change "Section 12.6.1" to "Section 7.1".

19) Section 7.3, bullet 7: Please change "Section 12.6.1" to "Section 7.1".

20) Section 7.4, bullet 4: Please change "Section 12.6.1" to "Section 7.1".

21) Section 7.5, bullet 7: Please change "Section 12.6.1" to "Section 7.1".

22) Security Considerations: Please delete the countersignature section
because it is much more applicable to the rfc2630bis-01 I-D. 

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

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Mon, 2 Jul 2001 15:08:21 -0700

>2) Section 1, para 2: Please change "implantations" to "implementations".

ROTFL. On the other hand, this indicates that almost no one (myself 
included) has read this document carefully.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 3 Jul 2001 15:46:24 -0700

John,

> algorithm, please replace all occurrences of "RSA" with "RSA

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.

> "Algorithms can be identified".

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.

> solution is to change the table such that "Triple-DES Key

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.

> in the rfc2630bis-01 I-D.  The
> draft-ietf-smime-password-03.txt I-D includes

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.

> draft-ietf-smime-password-03.txt I-D.

See my comment on item #6

> support the AuthenticatedData content-type MUST implement the

See my comment on item #6

> management technique is a MUST implement requirement.

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.

> key-encryption keys wrapping Triple-DES content-encryption keys."

See response to #13.  If that does not change then this does not need to
change.

> password.  The object identifier for the PBKDF2 [RFC2898] key

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.

> the algorithm specified in Sections 7.2 and 7.3."

Ditto for response #14

jim

---

From: "Housley, Russ" <[email-masked]>
Date: Tue, 10 Jul 2001 11:12:10 -0400

>algorithm, please replace all occurrences of "RSA" with "RSA (PKCS #1 v1.5)"

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.

>"Algorithms can be identified".

I changed it to "Algorithm are identified"

>NEW: "The algorithm identifier for each algorithm is specified"

Done.

>5) Table 1, title: Please change "Implantation" to "Implementation".

Done.

>solution is to change the table such that "Triple-DES Key Wrap" is a SHOULD

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.

>  Algorithm Type            MUST implement         SHOULD implement

Done.

>draft-ietf-smime-password-03.txt I-D.

Done.

>support the AuthenticatedData content-type MUST implement the HMAC with

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].

>NEW: "Digest values are located in the DigestedData digest field and Message

Done.

>agreement, key transport, previously distributed symmetric key-encryption

Done.

>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.

>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.

>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.

>password.  The object identifier for the PBKDF2 [RFC2898] key derivation

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 }

>implementations SHOULD support Two-Key Triple-DES in CBC mode."

Done.

>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.

>because it is much more applicable to the rfc2630bis-01 I-D.

Done.

Russ

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 10 Jul 2001 12:40:41 -0700

Russ,
>     Algorithm Type            MUST implement         SHOULD implement

Given the confusion and other items for RSA I would like to see the
following done:

Note 4: The use of RSA as a signature algorithm is for historical purposes
only and does not imply that it needs to work with all message digest
algorithms.  RSA (PKCS #1 v1.5) signatures using SHA-1 MUST be implemented.
RSA (PKCS #1 v1.5) signatures using MD5 SHOULD be implemented.

jim

---

From: "Housley, Russ" <[email-masked]>
Date: Tue, 10 Jul 2001 16:10:09 -0400

Jim:

I understand the purpose of the MUST and SHOULD statements, but I do not 
see any reason to include the remark about history.

Russ

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 10 Jul 2001 13:48:37 -0700

The historical remark is to try and make sure that this problem is not
repeated again.  If you have similar text in the body it probably does not
matter.

jim

> -----Original Message-----
> From: Housley, Russ [mailto:[email-masked]]
> Sent: Tuesday, July 10, 2001 1:10 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: cmsalg-00 Comments
>
>
> Jim:
>