ietf-smime
[Top] [All Lists]

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

2001-07-10 13:06:04

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

Done.

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

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