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, John(_dot_)Pawling(_at_)GetronicsGov(_dot_)com
Getronics Government Solutions, LLC
===========================================
-----Original Message-----
From: Jim Schaad [mailto:jimsch5(_at_)home(_dot_)com]
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: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org]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, John(_dot_)Pawling(_at_)GetronicsGov(_dot_)com
Getronics Government Solutions, LLC
===========================================
jim