[Top] [All Lists]

RE: WG Last Call: cmsalg

2001-08-22 23:01:13


-----Original Message-----
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: Wednesday, August 22, 2001 12:18 PM
To: jimsch(_at_)exmsft(_dot_)com
Cc: ietf-smime(_at_)imc(_dot_)org
Subject: RE: WG Last Call: cmsalg


2.  Section 2.1:  There is a conflict between MUST in the next to
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
process both.  However, if parameters are present, they must contain

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

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.

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.

[JLS] This addresses my issue.

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
CMS requirement not an algorithm requirement.  Please see response
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
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

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

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.

I caught the semicolon.

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

[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