[Top] [All Lists]

RE: WG Last Call: cmsalg

2001-08-21 06:40:54


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

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

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

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

   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.

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

I added:

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