RE: Who has tried some or all of the S/MIME examples?
"Pawling, John" <[email protected]> Thu, 8 May 2003 15:20:57 -0400
| Newsgroups | gmane.ietf.smime-examples,gmane.ietf.smime |
|---|---|
| Message-ID | <[email protected]> |
All, DigitalNet agrees with Russ, Blake and Jim. We will generate a new example 5.1 message that includes the id-dsa-with-sha1 OID. ==================================================== John Pawling, [email protected] DigitalNet (formerly Getronics Government Solutions) =================================================== -----Original Message----- From: Russ Housley [mailto:[email protected]] Sent: Thursday, May 08, 2003 2:47 PM To: [email protected]; [email protected] Cc: [email protected]; [email protected] Subject: RE: Who has tried some or all of the S/MIME examples? I believe that we should be using id-dsa-with-sha1. Russ > > 5.1.bin - failed > > 1. signatureAlgorithm is 1.2.840.10040.4.1 not 1.2.840.10040.4.3 > > From RFC3370, section 3.1: > > The algorithm identifier for DSA with SHA-1 signature values is: > > id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) > us(840) x9-57 (10040) x9cm(4) 3 } > > When the id-dsa-with-sha1 algorithm identifier is used, the > AlgorithmIdentifier parameters field MUST be absent. > > > From RFC2630, section 12.2.1: > > The DSA signature algorithm is defined in FIPS Pub 186 [DSS]. DSA is > always used with the SHA-1 message digest algorithm. The algorithm > identifier for DSA is: > > id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) > us(840) x9-57 (10040) x9cm(4) 3 } > > The AlgorithmIdentifier parameters field must not be present. > > > From RFC2633, section 2.2: > > Sending and receiving agents MUST support id-dsa defined in [DSS]. > The algorithm parameters MUST be absent (not encoded as NULL). > > > From RFC2633, Appendix A: > > -- id-dsa OBJECT IDENTIFIER ::= > -- {iso(1) member-body(2) us(840) x9-57(10040) x9cm(4) 1 } > > > From rfc2633bis-03: > > Receiving agents MUST support id-dsa defined in [CMSALG]. The > algorithm parameters MUST be absent (not encoded as NULL). > Receiving agents MUST support rsaEncryption, defined in [CMSALG]. > > > From RFC3370, section 3.1: > > id-dsa OBJECT IDENTIFIER ::= { iso(1) member-body(2) > us(840) x9-57 (10040) x9cm(4) 1 } > > > So the bottom line is that CMS says one thing > (id-dsa-with-sha1), and MSG says something else (id-dsa). > Consensus welcome. We went round and round about this at one > point, due to the use of the rsaEncryption value vs. the use > of the sha-1WithRSAEncryption value. > > Recommend accept both, emit id-dsa-with-sha1, change the > samples to use id-dsa-with-sha1 and changing rfc2633bis to say: > > > 2.2 SignatureAlgorithmIdentifier > > Receiving agents MUST support id-dsa-with-sha1 defined in > [CMSALG]. The algorithm parameters MUST be absent (not > encoded as NULL). Receiving agents MUST support > rsaEncryption, defined in [CMSALG]. > > Sending agents MUST support either id-dsa-with-sha1 or rsaEncryption. > > Note that S/MIME v3 clients might only implement signing or > signature verification using id-dsa-with-sha1, and might also > use id-dsa as an AlgorithmIdentifier in this field. Receiving > clients SHOULD recognize id-dsa as equivalent to > id-dsa-with-sha1, and sending clients MUST use > id-dsa-with-sha1 if using that algorithm. Also note that > S/MIME v2 clients are only capable of verifying digital > signatures using the rsaEncryption algorithm. > > Blake >