Subject: WG Last Call: rfc2630bis and cmsalg

From: "Housley, Russ" <[email-masked]>
Date: Thu, 16 Aug 2001 13:14:56 -0400

The update to CMS is ready for WG Last Call.  Please post all comments on 
both documents to the S/MIME WG mail list by 31 August 2001.

	Title		: Cryptographic Message Syntax
	Author(s)	: R. Housley
	Filename	: draft-ietf-smime-rfc2630bis-02.txt
	Pages		: 52
	Date		: 13-Aug-01

	Title		: Cryptographic Message Syntax (CMS) Algorithms
	Author(s)	: R. Housley
	Filename	: draft-ietf-smime-cmsalg-02.txt
	Pages		: 26
	Date		: 14-Aug-01
	
Russ

---

From: "Jim Schaad" <[email-masked]>
Date: Sun, 19 Aug 2001 22:39:17 -0700

1.  Introduction:  CMSALG cannot have a protocol requirement on CMS.  Please
lowercase MAY statements in the first paragraph of the introduction.

2.  Section 2.1:  There is a conflict between MUST in the next to last and
SHOULD in the last paragraph for handling the presence of NULL algorithm
parameters.

3.  Section 3.2: The paragraph "CMS implentations that support ..." should
be removed.  This is a protocol statement on CMS not CMSALGs.

4.  Section 4.1:  I think that the following sentence should be removed from
the text.  I have two problems with this statement.  First, it is imposing a
MUST on a CMS implementation rather than on algorithms.  Second, a protocol
that requires only RSA and 3DES does not need to require 3DES-WRAP as well.

"Any symmetric encryption algorithm that a CMS implementation includes as a
content-encryption algorithm MUST also be included as a key-encryption
algorithm."

That said, I do think that a variation of the criteria should be stated.
"When a key agreement algorithm is used, a key-encrytion algorithm is also
required.  In this case a key-encryption algorithm MUST be provided for each
content-encryption algorithm."

5.  Section 4.1: "A CMS implemenation MAY support mixed..." This paragraph
should be moved into the description of each key-wrap algorithm.  Thus
"3DES-Wrap implementations MAY support wrapping of non-3DES keys."

6.  Section 4.1.1:  "ukm MAY be present or absent."  I think this makes no
sense from a protocol sense.  I believe that one implemenation could require
presence and another could require absense thus leading to
non-interopability.  I had thought the requirements on this was going to be
"ukm may be either present or absent.  Implemenations MUST support ukm being
absent and SHOULD support be present."

7.  Section 4.1.1: description of keyEnryptionAlgorithm. "KeyWrapAlgorihtm"
is misspelt.

8.  Section 4.4, Para 2:  This contains a MUST on CMS.  It needs to be
removed.

9.  Section 4.4:  Some of the PBKDF2 restrictions from the password draft
have been lost:
A) Only the salt CHOICE requires support
B)

10. Section 6.1:  Last paragraph should have MUST not must.

11.  ASN Module:
cmsalg.asn(124) : error 1019: Type symbol AlgorithmIdentifier never
resolved.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Housley, Russ
Sent: Thursday, August 16, 2001 10:15 AM
To: [email-masked]
Subject: WG Last Call: rfc2630bis and cmsalg

	
Russ

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Mon, 20 Aug 2001 09:16:10 -0700

A few notes on Jim's comments.

>lowercase MAY statements in the first paragraph of the introduction.

Disagree. The "MAY" vs "may" here indicates references into this 
document, not external documents. By using "MAY", this is made 
clearer.

>be removed.  This is a protocol statement on CMS not CMSALGs.

Disagree. This paragraph shows a linkage between RSA and SHA-1, which 
is perfectly reasonable.

>8.  Section 4.4, Para 2:  This contains a MUST on CMS.  It needs to be

Disagree for same reason above.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: "Housley, Russ" <[email-masked]>
Date: Tue, 21 Aug 2001 09:05:48 -0400

Jim:

>1.  Introduction:  CMSALG cannot have a protocol requirement on CMS.
>Please lowercase MAY statements in the first paragraph of the
>introduction.

Here is what RFC 2119 says about MAY:

    MAY   This word, or the adjective "OPTIONAL", mean that an item is
       truly optional.  One vendor may choose to include the item because a
       particular marketplace requires it or because the vendor feels that
       it enhances the product while another vendor may omit the same item.
       An implementation which does not include a particular option MUST be
       prepared to interoperate with another implementation which does
       include the option, though perhaps with reduced functionality. In the
       same vein an implementation which does include a particular option
       MUST be prepared to interoperate with another implementation which
       does not include the option (except, of course, for the feature the
       option provides.)

I believe that this is a statement about the things specified in the CMSALG 
document.  CMS implementations can choose to implement them, or not.  I 
think that MAY is the correct word and case.

>2.  Section 2.1:  There is a conflict between MUST in the next to last
>and SHOULD in the last paragraph for handling the presence of NULL
>algorithm parameters.

I have read it three times, and I do not see the problem.  The working 
group decided that the transmission of omitted parameters and NULL 
parameters are both legal.  Therefore, implementations SHOULD be able to 
process both.  However, if parameters are present, they must contain NULL.

Please post a proposed working change if you still think that there is a 
problem.

>3.  Section 3.2: The paragraph "CMS implentations that support ..."
>should be removed.  This is a protocol statement on CMS not CMSALGs.

I do not agree.  If an implementation chooses to implement RSA (PKCS#1 
v1.5) signatures, they MUST also implement SHA-1.  Such implementations 
SHOULD also support MD5.  There is nothing in this document that forces an 
implementation to support RSA (PKCS#1 v1.5) signatures.

>4.  Section 4.1:  I think that the following sentence should be removed
>from the text.  I have two problems with this statement.  First, it is
>imposing a MUST on a CMS implementation rather than on algorithms.
>Second, a protocol that requires only RSA and 3DES does not need to
>require 3DES-WRAP as well.
>
>"Any symmetric encryption algorithm that a CMS implementation includes
>as a content-encryption algorithm MUST also be included as a
>key-encryption algorithm."
>
>"When a key agreement algorithm is used, a key-encrytion algorithm is
>also required.  In this case a key-encryption algorithm MUST be provided
>for each content-encryption algorithm."

I agree.  I propose the following alternative for the subject paragraph:

    When a key agreement algorithm is used, a key-encryption algorithm is
    also needed.  Therefore, when key agreement is supported, a key-
    encryption algorithm MUST be provided for each content-encryption
    algorithm.  The key wrap algorithms for Triple-DES and RC2 are
    described in section 7.

>5.  Section 4.1: "A CMS implemenation MAY support mixed..." This
>paragraph should be moved into the description of each key-wrap
>algorithm.  Thus "3DES-Wrap implementations MAY support wrapping of
>non-3DES keys."

Okay.  Done.

>6.  Section 4.1.1:  "ukm MAY be present or absent."  I think this makes
>no sense from a protocol sense.  I believe that one implemenation could
>require presence and another could require absense thus leading to
>non-interopability.  I had thought the requirements on this was going to
>be "ukm may be either present or absent.  Implemenations MUST support
>ukm being absent and SHOULD support be present."

Okay.  Done.

>7.  Section 4.1.1: description of keyEnryptionAlgorithm.
>"KeyWrapAlgorihtm" is misspelt.

Good catch.  Fixed.

>8.  Section 4.4, Para 2:  This contains a MUST on CMS.  It needs to be

You are correct.  I deleted the sentence with MUST in it.

>9.  Section 4.4:  Some of the PBKDF2 restrictions from the password
>draft have been lost:

I looked through the password-04 draft, and I think that I have covered all 
of the MUST statements.  Therefore you must be talking about the ASN.1.  It 
says:

    PBKDF2-params ::= SEQUENCE {
      salt OCTET STRING,
      iterationCount INTEGER (1..MAX),
      keyLength INTEGER (1..MAX) OPTIONAL,
      prf AlgorithmIdentifier
             DEFAULT { algorithm id-hmacWithSHA1, parameters NULL } }

However, I pulled the syntax from PKCS #5, and they do not match.  The one 
is password-04 is a legal subset.  The one in CMSALG is:

    PBKDF2-params ::= SEQUENCE {
      salt CHOICE {
        specified OCTET STRING,
        otherSource AlgorithmIdentifier },
      iterationCount INTEGER (1..MAX),
      keyLength INTEGER (1..MAX) OPTIONAL,
      prf AlgorithmIdentifier DEFAULT hMAC-SHA1 }

I added two things.  First, I added the setting of the default algorithm 
parameter to NULL.  Second, I added the following sentence about salt:

    Within the PBKDF2-params, the salt MUST use the
    specified OCTET STRING.

>10. Section 6.1:  Last paragraph should have MUST not must.

Due to the inclusion of the NULL parameter in response to your comment 
number 9, I rewrote almost the whole section.  It now says:

6.1  HMAC with SHA-1

    The HMAC with SHA-1 algorithm is described in RFC 2104 [HMAC].  The
    algorithm identifier for HMAC with SHA-1 is:

       hMAC-SHA1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
           dod(6) internet(1) security(5) mechanisms(5) 8 1 2 }

    There are two possible encodings for the HMAC with SHA-1
    AlgorithmIdentifier parameters field.  The two alternatives arise
    from the fact that when the 1988 syntax for AlgorithmIdentifier was
    translated into the 1997 syntax the OPTIONAL associated with the
    AlgorithmIdentifier parameters got lost.  Later the OPTIONAL was
    recovered via a defect report, but by then many people thought that
    algorithm parameters were mandatory.  Because of this history some
    implementations encode parameters as a NULL element and others omit
    them entirely.  CMS implementations that support HMAC with SHA-1 MUST
    handle both an AlgorithmIdentifier parameters field which contains a
    NULL and an AlgorithmIdentifier with an absent parameters.

>cmsalg.asn(124) : error 1019: Type symbol AlgorithmIdentifier never

I added:

   IMPORTS
      -- Directory Authentication Framework (X.509-2000)
            AlgorithmIdentifier
               FROM AuthenticationFramework { joint-iso-itu-t ds(5)
                    module(1) authenticationFramework(7) 4 }

Russ

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 20 Aug 2001 23:06:29 -0700

Paul,

Here are my thoughts in return.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Paul Hoffman / IMC
Sent: Monday, August 20, 2001 9:16 AM
To: [email-masked]; 'Housley, Russ'; [email-masked]
Subject: RE: WG Last Call: cmsalg

>1.  Introduction:  CMSALG cannot have a protocol requirement on CMS.
Please

[JLS]  Given what the statements actually say, I don't think that a
protocol based MAY is very appropriate.  You MAY do this. You MAY do
other things also.  I would not have the first idea of how to write a
test case for this as a protocol statement.  While I understand that
MAYs do not have to be tested, if you were to test this statement how
would you go about doing so.

>3.  Section 3.2: The paragraph "CMS implentations that support ..."
should

[JLS] I would agree with a statement that says.  "Implementations of RSA
(PKCS #1 v1.5) signature algorithm MUST implement the SHA-1 message
digest algorithm."

[JLS] Again what is the test case (this is a MUST).  Do you mean that I
cannot have a CMS implemention that supports password based key
management but does not support PBKDF2?  There are no other manditory
algorithm implementations in this document.  This one should not be
manditory.

--Paul Hoffman, Director

--- regards - jim

---

From: "Housley, Russ" <[email-masked]>
Date: Tue, 21 Aug 2001 12:15:46 -0400

Jim:

>[JLS] 3.  Section 3.2: The paragraph "CMS implentations that support ..." 
>should
>[Paul] Disagree. This paragraph shows a linkage between RSA and SHA-1, which
>is perfectly reasonable.
>

[Russ] I am confused here.  The current text is:

    CMS implementations that support the RSA (PKCS #1 v1.5) signature
    algorithm MUST also support the SHA-1 message digest algorithm.  Such
    implementations SHOULD also support MD5 message digest algorithm.

Are you really only asking that we change "support" to "implement"?

>[JLS] 8.  Section 4.4, Para 2:  This contains a MUST on CMS.  It needs to be
>removed.
>
>[Paul] Disagree for same reason above.
>

[Russ] Here I agree with Jim.  At the London meeting, we agreed that all of 
the algorithms listed in CMSALG would be MAY implement, and that other 
documents would make MUST statements.  For example, the updated MSG 
document will reference CMSALG and make MUST statements.

I think that the updated MSG document should say that implementations that 
support password-based key management, then they MUST implement PBKDF2.

Russ

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 21 Aug 2001 19:43:19 -0700

Russ:

From: [email-masked]
[mailto:[email-masked]] On Behalf Of Housley, Russ
Sent: Tuesday, August 21, 2001 6:06 AM
To: [email-masked]

    MAY   This word, or the adjective "OPTIONAL", mean that an item is
       truly optional.  One vendor may choose to include the item
because a
       particular marketplace requires it or because the vendor feels
that
       it enhances the product while another vendor may omit the same
item.
       An implementation which does not include a particular option MUST
be
       prepared to interoperate with another implementation which does
       include the option, though perhaps with reduced functionality. In
the
       same vein an implementation which does include a particular
option
       MUST be prepared to interoperate with another implementation
which
       does not include the option (except, of course, for the feature
the
       option provides.)

I believe that this is a statement about the things specified in the
CMSALG 
document.  CMS implementations can choose to implement them, or not.  I 
think that MAY is the correct word and case.

process both.  However, if parameters are present, they must contain
NULL.

problem.

[JLS]
1.  MUST handle with a parameters of NULL
2.  SHOULD accept absent parameters (as well as NULL)
3.  SHOULD generate with absent parameters.

The MUST accept and the SHOULD generate are of opposite choices.

I do not agree.  If an implementation chooses to implement RSA (PKCS#1 
v1.5) signatures, they MUST also implement SHA-1.  Such implementations 
SHOULD also support MD5.  There is nothing in this document that forces
an 
implementation to support RSA (PKCS#1 v1.5) signatures.

[JLS]  I don't have a problem with the statement above, it is when you
say CMS implementations... That I have a problem as that appears to be a
CMS requirement not an algorithm requirement.  Please see response
message to Paul on this issue.

    When a key agreement algorithm is used, a key-encryption algorithm
is
    also needed.  Therefore, when key agreement is supported, a key-
    encryption algorithm MUST be provided for each content-encryption
    algorithm.  The key wrap algorithms for Triple-DES and RC2 are
    described in section 7.

[JLS]  This is acceptable to me.

>A) Only the salt CHOICE requires support

I looked through the password-04 draft, and I think that I have covered
all 
of the MUST statements.  Therefore you must be talking about the ASN.1.
It 
says:

However, I pulled the syntax from PKCS #5, and they do not match.  The
one 
is password-04 is a legal subset.  The one in CMSALG is:

[JLS]  The salt issue addresses my concerns.  I don't care about the
question of the NULL parameter, but do agree that is in the password
draft.

6.1  HMAC with SHA-1

       hMAC-SHA1 OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3)
           dod(6) internet(1) security(5) mechanisms(5) 8 1 2 }

    them entirely.  CMS implementations that support HMAC with SHA-1
MUST

[JLS]  This addresses my problem. (And would be good SHA-1 text as
well.)

I added:

   IMPORTS

[JLS]  Don't forget the semi-colon following the OID since there are no
other  IMPORTS in the document. 
[JLS]  I would request that the PKIX module be used rather than the
X.509 since that is more widely available.

jim

---

From: "Housley, Russ" <[email-masked]>
Date: Wed, 22 Aug 2001 15:17:50 -0400

>The MUST accept and the SHOULD generate are of opposite choices.

How about:

    The AlgorithmIdentifier parameters field is OPTIONAL.  If present,
    the parameters field MUST contain a NULL.  Implementations MUST
    accept SHA-1 AlgorithmIdentifiers with absent parameters.
    Implementations SHOULD accept SHA-1 AlgorithmIdentifiers with absent
    parameters.  Implementations SHOULD generate SHA-1
    AlgorithmIdentifiers with absent parameters.

>message to Paul on this issue.

In the message to Paul, you said:
[JLS] I would agree with a statement that says.  "Implementations of RSA
(PKCS #1 v1.5) signature algorithm MUST implement the SHA-1 message
digest algorithm."

The whole point of CMSALG is to describe the use of algorithms in the CMS, 
so of course we are talking about CMS implementations.  How about:

    CMS implementations that include the RSA (PKCS #1 v1.5) signature
    algorithm MUST also implement the SHA-1 message digest algorithm.
    Such implementations SHOULD also support MD5 message digest
    algorithm.

>X.509 since that is more widely available.

I caught the semicolon.

RFC 2630 imports from the ISO/ITU-T modules.  Why change now?

Russ

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 22 Aug 2001 23:01:27 -0700

Russ,

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Housley, Russ
Sent: Wednesday, August 22, 2001 12:18 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: WG Last Call: cmsalg

How about:

[JLS] This addresses my issue.

an

The whole point of CMSALG is to describe the use of algorithms in the
CMS, 
so of course we are talking about CMS implementations.  How about:

[JLS]  This wording is not what I would prefer, but I can live with it.

I caught the semicolon.

[JLS]  Yes, I found out that it does import from the ISO modules when I
went back and look.  I had changed the versions on my system to import
from the PKIX modules since they were easier to get a hold of (no free
versions of the other modules at that point) and thus originally thought
that you had changed from the PKIX to the ISO modules.  

I would prefer using the PKIX modules where possible since 1) they are
more publicly available and 2) this is an IETF effort thus using the
IETF versions make sense.  This does not add any new dependencies since
there are already son-of-2459 and ACC profile dependencies in the
document. 

Jim

---

From: "Housley, Russ" <[email-masked]>
Date: Thu, 23 Aug 2001 10:11:04 -0400

>there are already son-of-2459 and ACC profile dependencies in the

I have no problem making this change.  However, before I do so, I would 
like to hear from other implementors.  Does anyone object to this 
direction?  If I do not hear any objections in the next day or so, I will 
change the imports from the ISO/ITU-T modules to the PKIX modules wherever 
possible.

Off the top of my head, the version 1 attribute certificate syntax is the 
only thing that I can think of that is not included in any PKIX modules.

Russ