ietf-smime
[Top] [All Lists]

RE: Jim's Comments: draft-ietf-smime-cmsalg-00

2001-07-10 09:39:12

John & Jim:

> 2) Section 2.1:  Jim stated: "I believe that the MUST and SHOULD statements
> in this paragraph are in conflict.  ie. MUST encode as and  SHOULD generate
> with.  These should be resolved as MUST in both locations."
>
> [JP: I disagree with Jim that the MUST and SHOULD statements are in
> conflict.  The paragraph states: "If present, the parameters field MUST
> contain an ASN.1 NULL."  In my opinion, it is clear that the MUST
> requirement does not apply if the parameters field is absent.  I also
> disagree with Jim's recommendation to change the spec to state that
> implementations MUST populate the algorithmIdentifier parameters field with
> an ASN.1 NULL.  I believe that the text should remain unchanged.]

[Jim: If present, the parameters field MUST contain an ASN.1 NULL.
Implementations SHOULD generate SHA-1 AlgorithmIdentifiers with NULL
parameters.

I believe that the second line is a MUST not a SHOULD.  I don't object to
the SHOULD handle if it is wrong, but generation needs to be with NULL
parameters.]

[John: This is a style choice.  I do not feel strongly about this issue.
RFC 2630 implementations should be populating this field with NULL anyway
(since it was a SHOULD requirement in RFC 2630).  In summary, I do not
object to your proposed change and I do not believe that it will cause any
interoperability problems.  Recommend the following new text: "The
AlgorithmIdentifier parameters field MUST be present, and the parameters
field MUST contain NULL.  Implementations SHOULD accept SHA-1
AlgorithmIdentifiers with absent parameters as well as NULL parameters.

Also, the following text should be added to section 3.2 RSA: "The
AlgorithmIdentifier parameters field MUST be present, and the parameters
field MUST contain NULL.  Implementations MAY accept rsaEncryption
AlgorithmIdentifiers with absent parameters as well as NULL parameters."]

I believe that the preferred encoding is with parameters absent! Yet, we allow the use of NULL for interoperability with folks that like to follow the convention used with MD2, MD4, and MD5.

Current text is: "Implementations SHOULD generate SHA-1 AlgorithmIdentifiers with NULL parameters." If we make any change, I would like to see the SHOULD changed to a MAY.

> 6) Section 3.2:  Jim stated "Boy we really messed this one
> up.  Section 3.2 should occur
> as two different sections one for RSAwithMD5 and one for
> RSAwithSHA1.  I will never understand how all of us missed this one.
>
> The OIDs for this should be:
>        sha1withRSAEncryption (1 2 840 113549 1 1 5)
> or
> #define szOID_OIWSEC_sha1RSASign "1.3.14.3.2.29"
>
>        md5withRSAEncryption (1 2 840 113549 1 1 4)"
>
> [JP: I disagree with Jim's statements.  To support backwards compatibility
> with S/MIME v2 implementations that only recognize the rsaEncryption OID, we
> specified that the rsaEncryption OID must be included in the signedData
> signerInfo signatureAlgorithm field.  We decided not to specify the use of
> the sha-1WithRSAEncryption, md2withRSAEncryption, or md5withRSAEncryption
> OIDs in the signerInfo signatureAlgorithm field.]

[Jim stated: John -- If I look in the examples draft, the OID that is in the
signatureAlgorithm field of a SignerInfo field is
  119 30   13:             SEQUENCE {
  121 06    9:               OBJECT IDENTIFIER
             :                 sha1withRSAEncryption (1 2 840 113549 1 1 5)
             :                 (PKCS #1)
  132 05    0:               NULL
             :               }
Not RSA.  I don't have the foggiest idea of what you are talking about for
backwards compatability.  This is not an argument that I have ever heard
before (I think).

I think you have not looked at this correctly and ask that you re-check what
I am saying.]


[John: Your quote from the examples-06 document is for an RSA signature on a
certificate (not a signedData signerInfo signatureAlgorithm field).
Examples 5.2, 5.5 and 11.2 in the examples-06 document all include the
rsaEncryption (1 2 840 113549 1 1 1) OID in the signerInfo
signatureAlgorithm field as specified in RFC 2630, section 12.2.2.

There is definitely an inconsistency between the specification of the
rsaEncryption and id-dsa-with-sha1 OIDs in the signerInfo signatureAlgorithm
field.  While RFC 2630 was being developed, I pointed out that
inconsistency.  I was told that the rsaEncryption OID was specified to
support backwards compatibility with S/MIME v2 implementations that only
recognize the rsaEncryption OID.  I was also told that the signerInfo
digestAlgorithm field indicates the algorithm used to calculate the message
digest value used as an input to the signature algorithm, so the use of the
rsaEncryption OID (rather than sha-1withRSAEncryption, md2withRSAEncryption,
or md5withRSAEncryption) was appropriate.  I then proposed that the id-dsa
OID should be used in the signerInfo signatureAlgorithm field to be
consistent with the use of the rsaEncryption OID.  I was told that since DSA
is always used with SHA-1, then the id-dsa-with-sha1 OID is appropriate for
use in the signerInfo signatureAlgorithm field.

Having said all of that, I would support a change to cmsalg to specify the
use of the sha-1withRSAEncryption, md2withRSAEncryption, or
md5withRSAEncryption OIDs (rather than  rsaEncryption) in the signerInfo
signatureAlgorithm field.  This would be consistent with the use of those
OIDs in PKIX X.509 certificates.  It would also eliminate the current
situation in which the rsaEncryption OID is being used for two very
different purposes (to indicate an RSA signature in the signerInfo
signatureAlgorithm field and to indicate an RSA public key in a PKIX X.509
certificate).]

The OIWSEC_sha1RSASign OID (1.3.14.3.2.29) is not appropriate here. This OID is used with X9.31 padding (not PKCS#1 v1.5 padding). As far as I know, no one supports X9.31 padding in any S/MIME (v2 or v3) product, freeware, or tool kit.

The confusion here is which algorithm identifier goes in the public key certificate and which algorithm identifier goes with the signature value. The text clearly needs to handle both situations.

> 12) Section 7:  Jim stated: "I do not believe this section
> needs any MUSTS for inclusion
> of algorithms.  That is covered in section 4."
>
> [JP: Rather than delete the first sentence of Section 7, I believe that it
> should be changed to: "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."]

[Jim: I stand by my original comment. This is a duplication of a MUST and should
be where it makes sense (where the algorithm is used) not here.]

[John: I do not object to your comment.  If the MUST language is removed
from the first sentence, then the SHOULD language should be removed from the
second sentence.]

My recollection from the last IETF meeting was that we wanted the key wrap algorithm to remain mandatory to implement. This was to facilitate mail list deployment. I cannot find anything in the minutes to support my recollection, but I cannot find anything in the minutes that contradicts my recollection either. I will start a separate message thread to debate this issue.

Russ