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

From: Paul Hoffman / IMC <[email-masked]>
Date: Sun, 4 May 2003 15:11:21 -0700

Greetings again. The WG chairs have announced that we are in the WG 
last call for draft-ietf-smime-examples-10.txt. As editor of the 
document, I'd like to find out who has looked at the examples in this 
particular draft and/or tried them out? If you have done so, could 
you send a list of the examples you have reviewed and a short 
description of how you reviewed them? You can send it to me 
personally, or to the two lists. Please post even if you have seen 
other people post about the same examples: we want to know how deep 
our coverage is. Thanks!

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: "Blake Ramsdell" <[email-masked]>
Date: Tue, 6 May 2003 17:26:03 -0700

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> Paul Hoffman / IMC
> Sent: Sunday, May 04, 2003 3:11 PM
> To: [email-masked]; [email-masked]
> Subject: Who has tried some or all of the S/MIME examples?
> 

The files I have worked with:

5.1.bin -- Identified as a CMS SignedData with signatures and content,
checked certificates were present, matched content to ExContent.bin,
verified one signer

5.2.bin -- Checked certificates were present, matched content to
ExContent.bin, verified one signer

5.3.bin -- Identified as a CMS SignedData with signatures and no
content, checked certificates were present, verified one signer against
external content in ExContent.bin

5.4.bin -- Extracted signing time attribute, checked certificates were
present, checked CRLs were present, matched content to ExContent.bin,
verified one signer

5.5.bin -- Checked certificates were present, matched content to
ExContent.bin, verified one signer

5.6.bin -- Checked certificates were present, matched content to
ExContent.bin, verified two signers

5.7.bin -- Checked certificates were present, matched content to
ExContent.bin, verified one signer

5.8.eml -- Parsed content with MIME parser, matched extracted text
content from text part to ExContent.bin, checked certificates were
present, verified one signer against first part of message, identified
as a CMS SignedData with signatures and no content

5.9.eml -- Parsed content with MIME parser, matched extracted text
content from text part to ExContent.bin, checked certificates were
present, verified one signer, identified as a CMS SignedData with
signatures and content

5.10.bin -- Matched content to ExContent.bin, verified one signer

5.11.bin -- Identified as a CMS SignedData with no signatures and no
content, checked certificates were present

6.2.bin -- Decrypted message, matched content to ExContent.bin,
identified as a CMS EnvelopedData

6.3.bin -- Decrypted message, matched content to ExContent.bin

7.0.bin -- Verified hash, matched content to ExContent.bin

8.1.bin -- Decrypted data with given key, matched content to
ExContent.bin

I also worked with the following certificates and private keys:

AliceDSSSignByCarlNoInherit.cer
AlicePrivRSASign.pri
AliceRSASignByCarl.cer
BobPrivRSAEncrypt.pri
BobRSASignByCarl.cer
CarlDSSCRLForAll.crl
CarlDSSSelf.cer
CarlPrivDSSSign.pri
CarlPrivRSASign.pri
CarlRSASelf.cer
DianeDHEncryptByCarl.cer
DianeDSSSignByCarlInherit.cer
DianePrivRSASignEncrypt.pri
DianeRSASignByCarl.cer
EricaDHEncryptByCarl.cer

Blake

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 7 May 2003 14:12:31 -0700

The files I have worked with so far:

4.1.bin - passed
4.2.bin - passed
5.1.bin - failed
	1.  signatureAlgorithm is 1.2.840.10040.4.1 not
1.2.840.10040.4.3
5.2.bin - passed
5.4.bin - failed
	1.  Contains Alice's RSA certificate
	2.  No content hint unsigned attribute
	3.  signatureAlgorithm is 1.2.840.10040.4.1 not
1.2.840.10040.4.3
5.5.bin - passed
5.6.bin - failed
	1.  signatureAlgorithm is 1.2.840.10040.4.1 not
1.2.840.10040.4.3
5.7.bin - failed
	1.  signatureAlgorithm is 1.2.840.10040.4.1 not
1.2.840.10040.4.3
5.10.bin  - failed
	1.  Change "unknown OID" to "unknown OID (1.2.5555)"
	2.  Content Hint should have an OID of 1.2.840.113549.1.7.1
	3.  Content Identifier attribute absent
	4.  Contains Security Label attribute
	5.  Contains encrypt key preference attribute
	6.  Contains ML Expansion History attribute
	7.  Contains Equivalent Label attribute

Jim

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Blake Ramsdell
> Sent: Tuesday, May 06, 2003 5:26 PM
> To: 'Paul Hoffman / IMC'; [email-masked]; 
> [email-masked]
> Subject: RE: Who has tried some or all of the S/MIME examples?
> 
> 
> 
> 5.1.bin -- Identified as a CMS SignedData with signatures and 
> content, checked certificates were present, matched content 
> to ExContent.bin, verified one signer
> 
> 5.2.bin -- Checked certificates were present, matched content 
> to ExContent.bin, verified one signer
> 
> 5.3.bin -- Identified as a CMS SignedData with signatures and 
> no content, checked certificates were present, verified one 
> signer against external content in ExContent.bin
> 
> 5.4.bin -- Extracted signing time attribute, checked 
> certificates were present, checked CRLs were present, matched 
> content to ExContent.bin, verified one signer
> 
> 5.5.bin -- Checked certificates were present, matched content 
> to ExContent.bin, verified one signer
> 
> 5.6.bin -- Checked certificates were present, matched content 
> to ExContent.bin, verified two signers
> 
> 5.7.bin -- Checked certificates were present, matched content 
> to ExContent.bin, verified one signer
> 
> 5.8.eml -- Parsed content with MIME parser, matched extracted 
> text content from text part to ExContent.bin, checked 
> certificates were present, verified one signer against first 
> part of message, identified as a CMS SignedData with 
> signatures and no content
> 
> 5.9.eml -- Parsed content with MIME parser, matched extracted 
> text content from text part to ExContent.bin, checked 
> certificates were present, verified one signer, identified as 
> a CMS SignedData with signatures and content
> 
> 5.11.bin -- Identified as a CMS SignedData with no signatures 
> and no content, checked certificates were present
> 
> 6.2.bin -- Decrypted message, matched content to 
> ExContent.bin, identified as a CMS EnvelopedData
>

---

From: "Blake Ramsdell" <[email-masked]>
Date: Wed, 7 May 2003 15:59:49 -0700

> From: Jim Schaad [mailto:[email-masked]] 
> Sent: Wednesday, May 07, 2003 2:13 PM
> To: 'Blake Ramsdell'; 'Paul Hoffman / IMC'; 
> [email-masked]; [email-masked]

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: "Jim Schaad" <[email-masked]>
Date: Thu, 8 May 2003 10:09:07 -0700

Having looked at the back history of the last argument.  It appears that
Blake argued that the correct think was to use id-dsa-with-sha1 and get
over the fact that it's not consistant with the use of rsa-encryption.
Thus I think that Blake's solution below is correct and the examples
should be corrected to be "Correct".

Jim

> From: Blake Ramsdell [mailto:[email-masked]] 
> Sent: Wednesday, May 07, 2003 4:00 PM
> To: [email-masked]; 'Paul Hoffman / IMC'; 
> algorithm parameters MUST be absent (not encoded as NULL). 
> Receiving agents MUST support rsaEncryption, defined in [CMSALG].
> 
> 
> 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:
> 
> 
> 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].
> 
> 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
>