[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Who has tried some or all of the S/MIME examples?



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, John.Pawling@xxxxxxxxxxxxxx
DigitalNet (formerly Getronics Government Solutions)
===================================================



-----Original Message-----
From: Russ Housley [mailto:housley@xxxxxxxxxxxx] 
Sent: Thursday, May 08, 2003 2:47 PM
To: blake@xxxxxxxxxxxxxxxxxx; phoffman@xxxxxxx
Cc: ietf-smime@xxxxxxx; ietf-smime-examples@xxxxxxx
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
 >