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

From: "Pawling, John" <[email-masked]>
Date: Thu, 5 Jul 2001 15:43:34 -0400

Jim,

Thank you for your responses to my comments.  My responses are included in
the message below.  I snipped the text that we agree on. 

===========================================
John Pawling, [email-masked]
Getronics Government Solutions, LLC
===========================================

-----Original Message-----
From: Jim Schaad [mailto:[email-masked]]
Sent: Tuesday, July 03, 2001 6:58 PM
To: 'Pawling, John'; 'Ietf-Smime (E-mail)'
Subject: RE: Jim's Comments: draft-ietf-smime-cmsalg-00

John,

Here are my responses to your comments.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Pawling, John
> Sent: Tuesday, July 03, 2001 8:31 AM
> To: Ietf-Smime (E-mail)
> Subject: RE: Jim's Comments: draft-ietf-smime-cmsalg-00
>
>
>
> All,
>
> I have the following comments regarding Jim Schaad's 7 June
> comments to the
> draft-ietf-smime-cmsalg-00.txt Internet-Draft.  My comments [JP] are
> numbered consistently with Jim's original message.  I omitted
> Jim's comments
> with which I agree.
>
> 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."]

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

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

>
> ===========================================
> John Pawling, [email-masked]
> Getronics Government Solutions, LLC
> ===========================================
>

jim

---

From: "Housley, Russ" <[email-masked]>
Date: Tue, 10 Jul 2001 12:39:00 -0400

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
> > conflict.  The paragraph states: "If present, the parameters field MUST
> > implementations MUST populate the algorithmIdentifier parameters field with

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.

> > up.  Section 3.2 should occur
> > RSAwithSHA1.  I will never understand how all of us missed this one.
> >
> > [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

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.

> > needs any MUSTS for inclusion
> > [JP: Rather than delete the first sentence of Section 7, I believe that it
> > techniques MUST include encryption of a Triple-DES content-encryption key

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

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 10 Jul 2001 12:30:15 -0700

Russ,
> like to see the SHOULD changed to a MAY.

If this is the preferred encoding, it is certianly not displayed as such in
the current text.  If you really think that is true then we need to make the
following change:

"Implementations SHOULD generate SHA-1 AlgorithmIdentifiers as absent".

> rsaEncryption

I have looked back and tried to remember what was going on then.  I find
that John is correct, for the current algorithms we definately only use the
rsa OID.  I think we want to "fix" this for the new signature algorithms
when they come along bit it's too late for these.

I do, however, think that this confusion deserves some explation text as to
why it is not a "signature" algorithm but a public key algorithm for RSA
v1.5.

jim

---

From: "Housley, Russ" <[email-masked]>
Date: Tue, 10 Jul 2001 16:03:35 -0400

Jim:

> > AlgorithmIdentifiers with NULL parameters."  If we make any
> > change, I would like to see the SHOULD changed to a MAY.
>

Done.

>why it is not a "signature" algorithm but a public key algorithm for RSA

I have just finished composing text that I hope will make this much more 
clear.  It is fairly long, so I will simply post a new version of the 
Internet-Draft.  It should be there tomorrow.

Russ