|
RE: Jim's Comments: draft-ietf-smime-cmsalg-00
2001-07-10 12:30:24
Russ,
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.
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".
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.
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.
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
jim
|
|