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

From: "Pawling, John" <[email-masked]>
Date: Tue, 6 May 2003 14:20:17 -0400

Paul,

DigitalNet has used the S/MIME Freeware Library (SFL) (and underlying libraries) to successfully process the vast majority of the examples in the draft-ietf-smime-examples-10.txt.  This message includes the notes regarding our testing.  We will send you corrected examples for sections 11.1 and 11.2.

Test Results for S/MIME Examples-10:

These tests were executed by DigitalNet using the S/MIME Freeware Library (SFL) and underlying libraries.  Point of contact is Bob Colestock, [email-masked].

(Note: Test numbers correspond to Examples-10 section numbers.)

4.  ContentInfo Tests

4.1	ContentInfo with Data type, BER:  Successfully ASN.1 decoded the BER-encoded ContentInfo sample in Examples document, but SFL can only create DER-encoded ContentInfo objects because the Enhanced SNACC library always uses DER to ASN.1 encode objects.

4.2	ContentInfo with Data type, DER:  Successfully decoded sample in Examples document using SFL.

5.  SignedData Tests

5.1	Basic signed content, DSS:  Successfully verified signature of sample in Examples document using SFL.

5.2	Basic signed content, RSA:  Successfully verified signature of sample in Examples document using SFL.

5.3	Basic signed content, detached content: Successfully verified signature of sample in Examples document using SFL.

5.4	Fancier signed content, Signed content with signed/unsigned attributes: Successfully verified signature of sample in Examples document using SFL.  

5.5	All RSA signed message:  Successfully verified signature of sample in Examples document using SFL.

5.6	Multiple DSS signatures: Successfully verified all of the signatures in the sample in the Examples document.  

5.7	Signing using SKI:  Successfully verified signature of sample in Examples document using SFL. 

5.8	S/MIME multipart/signed message: Successfully verified signature of sample in Examples document using SFL. 

5.9	S/MIME application/pkcs7-mime signed message:  Successfully verified signature of sample in Examples document using SFL.

5.10	SignedData With Attributes: Successfully verified signature of sample in Examples document.

5.11	SignedData with Certificates Only: Successfully verified that there were no SignerInfos that were present or verified in the sample in the Examples document.

6.   Enveloped-data Tests

6.1.	Basic encrypted content, TripleDES and DH:  Successfully used SFL to process this envelopedData sample.   

6.2.	Basic encrypted content, TripleDES and RSA:  Successfully decrypted sample in Examples document using SFL.

6.3.	Basic encrypted content, RC2/40 and RSA:  Successfully decrypted sample in Examples document using SFL.
  
6.4.	Encrypted content, two recipients, no shared keying material: Successfully used SFL to process the envelopedData sample.  NOTE:  Unsuccessful Invalid tag for privateKeyInfo for second login

6.5.	Encrypted content, two recipients, shared keying material: Was unable to use the SFL to process the envelopedData sample because of an SFL bug related to processing shared UKMs.  SFL will be fixed to be able to successfully process this message as it has in the past.

6.6.	Encrypted content, TripleDES and DH, previously-distributed keys: Used SFL to successfully process the envelopedData sample.

6.7.	Encrypted content, RC2/40 and RSA, previously-distributed keys: Used SFL to successfully process the envelopedData sample.  

6.8.	S/MIME application/pkcs7-mime encrypted message:  Successfully used SFL to process the envelopedData sample.

6.9.	EnvelopedData with All Recipient Types: Successfully used SFL to process the envelopedData sample for all recipient types KARI, KTRI, and KEKRI.

6.10.	EnvelopedData with KARI RC2 Encryption: Successfully used SFL to process the envelopedData sample.

6.11.	EnvelopedData with KEK 3DES Encryption: Successfully used SFL to process the envelopedData sample.

7.  DigestedData:  SFL does not support.

8.  Encrypted-Data Tests: 

8.1. Simple EncryptedData: Successfully used SFL to process the encryptedData sample.

8.2. EncryptedData with unprotected attributes: Successfully used SFL to process the encryptedData sample.

9.  Authenticated-Data:  SFL does not support.

10. Key Wrapping:  Tests conducted as part of EnvelopedData testing. 

11.  ESS Examples

11.1	ReceiptRequest:  Used SFL to successfully process the signedData including a receiptRequest attribute.  Note that the 11.2 signedReceipt is supposed to be in response to the 11.1 signedData receiptRequest, but the examples-10 samples are incorrect.  DigitalNet will provide new samples for 11.1 and 11.2 that are correct.

11.2	Receipt:  Used SFL to successfully process the signedData including a receipt content type.  NOTE - Unsuccessful - no match in signer info error

11.3	ESSSecurityLabel:  Used SFL to successfully process the signedData including a ESSSecurityLabel signed attribute.

11.4	EquivalentLabels:  Used SFL to successfully process the signedData including an EquivalentLabels signed attribute.

11.5	mlExpansionHistory:  Used SFL to successfully process the signedData including an mlExpansionHistory signed attribute.

11.6	SigningCertificate:  Used SFL to successfully process the signedData including a SigningCertificate signed attribute.

====================================================
John Pawling, [email-masked]
DigitalNet (formerly Getronics Government Solutions)
====================================================

---

From: Russ Housley <[email-masked]>
Date: Thu, 08 May 2003 14:47:23 -0400

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
 >

---

From: "Pawling, John" <[email-masked]>
Date: Thu, 8 May 2003 15:20:57 -0400

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-masked]
DigitalNet (formerly Getronics Government Solutions)
===================================================

-----Original Message-----
From: Russ Housley [mailto:[email-masked]] 
Sent: Thursday, May 08, 2003 2:47 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: Who has tried some or all of the S/MIME examples?

Russ