[Top] [All Lists]

RE: WG Last Call: cmsalg

2001-08-21 20:13:32


From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Housley, 
Sent: Tuesday, August 21, 2001 6:06 AM
To: jimsch(_at_)exmsft(_dot_)com


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
       it enhances the product while another vendor may omit the same
       An implementation which does not include a particular option MUST
       prepared to interoperate with another implementation which does
       include the option, though perhaps with reduced functionality. In
       same vein an implementation which does include a particular
       MUST be prepared to interoperate with another implementation
       does not include the option (except, of course, for the feature
       option provides.)

I believe that this is a statement about the things specified in the
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

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


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.

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

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
"When a key agreement algorithm is used, a key-encrytion algorithm is
also required.  In this case a key-encryption algorithm MUST be
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
    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.

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
of the MUST statements.  Therefore you must be talking about the ASN.1.

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

[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

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)
           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
    handle both an AlgorithmIdentifier parameters field which contains a
    NULL and an AlgorithmIdentifier with an absent parameters.

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

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 }

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