Graham Finlayson | 12 Jan 13:34 2004

PFX Problems (Not really a problem with the draft)

The home page for this mailing list has a link to some PFX files. At least one (BobRSASignByCarl.pfx), if not more, of thes files in this archive has the incorrect private key embedded in the PFX. The private key has to be imported from the BobPrivRSAEncrypt.pri file instead.

Graham

Sam Roberts | 15 Sep 18:24 2003

Odd signedContentIdentfier in example 11.1


In draft 11, which is the latest, I think, the signedContentIdentifier
is the octet string 'Example 11.1 (Alice asks for a receipt from
Diane)'. The data is opaque, its not supposed to mean anything, but
given that it is human-readable text, shouldn't it say that Alice is
asking for a receipt from Bob, since that is what she is doing?

Also, in section 11.1, first and only sentence, "receipt" is mis-spelled
"reciept" (i and e are switched).

Cheers,
Sam

--

-- 
Sam Roberts <sroberts <at> certicom.com>

Blake Ramsdell | 12 Aug 08:18 2003

RC2 inconsistency


I was just about to call it a night, thinking that all was right in the
universe of key wrapping...

It appears that I quite unintentionally used two different RC2 keys to
decrypt example 6.7 and 6.9.  The two keys are:

(transcribed from the examples draft) b7 0a 25 fb c9 d8 6a 86 05 0c e0
d7 11 ea d4 d9

(from the extracted MailListRc2.bin)  b7 0d 0a 25 fb c9 d8 6a 86 05 0c
e0 d7 11 ea d4 d9

Notice the CRLF translation...

Now, I would say that this isn't a problem, except for the fact that
example 6.9 appears to require the CRLF version and example 6.7 requires
the other one!

I have tried to monkey with extracting the base64 data for
MailListRc2.bin using other code, and I get the CRLF in that case also.
I have attempted to extract this on three different Oses, and each of
them has the CRLF, so I believe that this is in the encoded data.

So the bottom line seems to be:

1. The encoded file MailListRc2.bin needs to be corrected to match the
printed version in the draft.

2. Example 6.9 will then be incorrect, and the kekri will need to be
regenerated for this example.

It would be good to have some confirmation of this, if anyone can check
on their side.

Blake
--
Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com 

Blake Ramsdell | 12 Aug 05:54 2003

Key wrap examples


I am doing my best to work through this, but I think I'm at the point
where I'm going to say that the 3DES mail list example is wrong.  The
problem is clearly in the key unwrapping step, and based on Jim's
comments, we are arriving at the same answer with two independent
implementations.

I have not had any trouble with the RC2 mailing list key in example 6.7
or 6.9 -- those examples decrypt fine.

I believe that we need to change 6.11 in order to move forward.  I will
see what I can do on my end.

Anyone who has messed with 6.11 feel free to speak up about your
experiences.

Blake
--
Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com 

Jim Schaad | 6 Aug 23:29 2003

Draft-11: More complete results


People,

I now have only a couple of examples that I have not checked.  There are
a couple of failures in this set of messages from my perspective.

jim

4.1 	pass
4.2	pass
5.1	pass
5.2	pass
5.3  -- not checked ---
5.4	pass with comments
	1.  certificates are Alice DSS, Carl DSS (root), Alice RSA
5.5	pass
5.6	--- not checked --  - structurally fine - 
		- First Sig checks
		Diane signature unchecked
5.7  	pass
5.8  -- not checked --
	1. I have an assumption that the wrong signature OID is used in
the message. 
5.9  FAILED 
	1. id-dsa is the signature algorithm not id-dsa-with-sha1
	2. Commentary text states that the body part is the same as 5.1
- this is not correct as the signature values and exContent are
different (content is actually "\0xd\0xaThis is some sample content." 
5.10  pass with comments
	1. List of attributes is
		1. content type
		2. message digest
		3. 1.2.5555 (unknown)
		4. content hint
		5. smime capabilities
		6. security label
		7. content reference
		8. encrypt key preference
		9. ML expansion history
		10. Equivalent label
5.11 	pass with comments
	1. Text should be Alice's and Carl's DSS certificates.

6.1 	passed with comments
	1. New commentary to add to replace that at the end of the
message is appended to this message.
6.2	passed
6.3 	passed with comments
	1. RC2/128 for the content encryption algorithm.
6.4	passed
6.5 	passed 
6.6 	-- not checked --
6.7	passed
6.8	-- not checked --
6.9	FAILED
	Recip #1 pass
	Recip #2 pass
	Recip #3 FAIL
	Content hints says the content is 1.2.6.5.4 not id-data
6.10	pass
6.11	FAILED
	test vectors are appended below on this message.  I don't know
where I am going wrong and this code worked in the past.

7.0	pass

8.1	passed
8.2	passed with comment
	Need to specify that this uses the same key value as does 8.1

9	-- checked--

10.1	-- not checked --
10.2	checked

11.1	FAILED
	1. Text states signed with RSA, message signed with DSA
	2. DSA signature OID incorrect
	3. I retract the comments about the receipt request and
AliceRSA.  This is fine.  The only odditity is the the receipt is going
to a non-example address (robert.colestock <at> wang.com)
11.2	FAILED
	1. I do not get the same value for the msgSigDigest attribute as
this message has.  I am investigating further.
11.3  passed
11.4  passed
11.5  -- not checked -- 
11.6 	-- not checked --

***************************** 6.1 intermediate data for document
**********************

Z

  ae c3 35 7f 90 75 b5 e4 c5 f8 92 6b 9e c5 96 a3
  24 52 9d 85 32 60 7b 8b bd c2 a7 39 63 e9 d6 93
  ad d5 1f 56 8d 91 97 72 a9 c2 f4 83 27 fa 37 3d
  13 12 f3 3b 5c 8d ec ce 6b 2d 4f f1 9b 4c 91 e4
  6d c0 68 1a 2e e0 c4 07 46 c3 f2 90 f4 ae fe c8
  d8 ef dc ca 84 d5 fd 3a 36 ee ba 67 16 18 7f a3
  de f3 df 3b 66 e1 6a 0b 79 bb 6a 50 c2 63 9f 24
  ed 9b 17 d8 c1 b4 4e 8a a1 6a 35 02 d0 81 9c a3

X9.42 Other Info encoding for first hash
  30 61 30 13 06 0b 2a 86 48 86 f7 0d 01 09 10 03 
  06 04 04 00 00 00 01 a0 42 04 40 a9 74 c4 e9 aa 
  79 d3 ce 5c 74 a4 ed a5 db 65 f5 c0 37 d6 81 f1 
  0a 93 5f 24 a1 db 97 96 ee 87 8b 79 db e9 07 11 
  23 ce 70 24 84 30 72 02 83 d5 7d 60 d3 d4 f6 a7 
  4d 4c c2 e0 89 fa cd 59 20 a2 93 a2 06 04 04 00 
  00 00 c0     

Hash Result #1
  5d fa dc ad 89 87 33 7c ec cf af 8a fc e8 fd 56 
  38 d8 89 0c                                     

Hash Result #2
  74 f2 fb f8 2c d7 bd 7a 92 1b 3c 10 df 16 0b a9
  64 08 f2 a5                                    

3DES Key Encryption Key
  5d fb dc ad 89 86 32 7c ec ce ae 8a fd e9 fd 57
  38 d9 89 0d 75 f2 fb f8                        

3DES Content Encryption Key
  92 40 51 b6 43 16 13 52 f7 ad 92 cb f2 57 3e 7f
  a8 ce 02 ba b6 2a cd c2                        

***************************** 6.11 intermediate data from my test
**************** But it fails....

Wrapped key
0x0012F248  74 31 c0 45 51 4c 3c 2d 2e da 63 50 8b ae d4 ac
t1ÀEQL<-.ÚcP.®Ô¬ 0x0012F258  64 cc 95 ae af cd 0f 8c b6 48 1f 0b 45 12
4d fb dÌ.®¯Í..¶H..E.M.
0x0012F268  a4 ab c7 83 30 4b 69 ad                         ¤«Ç.0Ki­

Mail list key
0x00324354  25 5e 0d 1c 07 b6 46 df b3 13 4c c8 43 ba 8a a7
%^...¶Fß³.LÈCº.§ 0x00324364  1f 02 5b 7c 08 38 25 1f

After decrypt #1
0x00324630  d7 10 66 ee 9a 42 e0 80 62 a3 e5 de b5 ef 4e 7e
×.f..B..b£.Þµ.N~ 0x00324640  5f 13 30 b5 13 d3 a8 4f be dc 02 d4 81 27
db 50 _.0µ.Ó¨O¾Ü.Ô.'ÛP
0x00324650  e5 d8 0f e9 25 38 f1 7b                         .Ø..%8.{

IV
0x00324630  7b f1 38 25 e9 0f d8 e5                         {.8%..Ø.

Post Decrypt #2
0x00324630  50 db 27 81 d4 02 dc be 4f a8 d3 13 b5 30 13 5f
PÛ'.Ô.ܾO¨Ó.µ0._ 0x00324640  7e 4e ef b5 de e5 a3 62 80 e0 42 9a ee 66
10 d7 ~N.µÞ.£b..B..f.×

Computed check sum
0x0012EFD8  53 fb 3e cc 8a 06 cc af                         S.>Ì..̯

Actual Check sum
 80 e0 42 9a ee 66 10 d7

--- they don't match!!!!!

Jacoby, Jeffrey | 1 Aug 19:27 2003

RE: Status of the examples draft


FYI,

Our current status...

We have had success with the following messages
from draft-ietf-smime-examples-11.txt.  There is
one additional success, and one failure, since -09 
(or was -10 the last time I responded?):

        4.1.bin
        4.2.bin
        5.1.bin    <- new success since -09
        5.2.bin
        5.3.bin
        5.4.bin
        5.5.bin
        5.10.bin
        5.11.bin
        6.2.bin
        6.3.bin
        7.0.bin
        8.1.bin
                   <-- new failure w/ 11.1.bin (we now don't 
                       support dsa (1 2 840 10040 4 1) as a 
                       signature OID)
        11.3.bin
        11.4.bin
        11.5.bin
        11.6.bin

A few points:

 - Paul, looking back at my previous status note, we had
   never claimed success with 11.2.bin (sorry, I should 
   known that when we spoke)

 - Don't take too much comfort in our success with the other
   examples 11.*.bin.  While the code can parse and verify the 
   signatures, it doesn't do anything else in terms of enhanced 
   security semantics.

 - The same comments Blake made (below) for his results, where we 
   both had successes in common, apply to ours as well.

Jeff
-- 
Jeff Jacoby, Principal Development Engineer  
RSA Security Inc., Developer Solutions
2955 Campus Drive, Suite 400
San Mateo, CA 94403

phone: (650) 295-7569
fax:   (650) 358-2530
email: jjacoby <at> rsasecurity.com        

>  > -----Original Message-----
>  > From: owner-ietf-smime <at> mail.imc.org
>  > [mailto:owner-ietf-smime <at> mail.imc.org] On Behalf Of Paul 
>  Hoffman / IMC
>  > Sent: Wednesday, July 02, 2003 8:44 AM
>  > To: ietf-smime-examples <at> imc.org; ietf-smime <at> imc.org
>  > Subject: Status of the examples draft
>  > 
>  > Hi again. The -11 draft has the following changes:
>  
>  The comments that I posted regarding the -10 draft stand for 
>  the -11 draft, and I have included them below for completeness.
>  
>  The only thing that I've had trouble with so far is 5.6.bin 
>  appears to have changed the order of the SignerInfos.  I 
>  don't believe that this change is relevant, so I don't think 
>  there needs to be any modification of the draft.
>  
>  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
>  

Jim Schaad | 16 Jul 16:19 2003

Draft-11Parital Results


People,

Here is the current state of draft 11 with my testing.  I will continue
to fill out more of the data in the this table as I get some more items
debugged in my code.  I am still trying to figure out why I cannot do
DH.

jim

4.1 	pass
4.2	pass
5.1	pass
5.2	pass
5.3  -- not checked ---
5.4	pass with comments
	1.  certificates are Alice DSS, Carl DSS (root), Alice RSA
	2.  unsigned attributes are JUST counter signature
5.5	pass
5.6	--- not checked --  - structurally fine - Diane signature
unchecked
5.7  	pass
5.8  -- not checked --
	I have an assumption that the wrong signature OID is used in the
message.
5.9  failed 
	id-dsa is the signature algorithm not id-dsa-with-sha1
	Commentary text states that the body part is the same as 5.1 -
this is not correct as the signature values and exContent are different
(content is actually "\0xd\0xaThis is some sample content."
5.10  pass with comments
	List of attributes is
		1. content type
		2. message digest
		3. 1.2.5555 (unknown)
		4. content hint
		5. smime capabilities
		6. security label
		7. content reference
		8. encrypt key preference
		9. ML expansion history
		10. Equivalent label
5.11 	pass with comments
	Text should be Alice's and Carl's DSS certificates.

6.1	-- not checked --
6.2	passed
6.3 	passed with comments
	RC2/128 for the content encryption algorithm.
6.4	-- not checked --
6.5 	-- not checked --
6.6 	-- not checked --
6.7	-- not checked -- fail on the RC2/40 not clear what the source
is yet.
6.8	-- not checked --
6.9	failed
	Content hints says the content is 1.2.6.5.4 not id-data
6.10	-- not checked --
6.11	FAIL
	test vectors are appended below on this message.  I don't know
where I am going wrong and this code worked in the past.

7.0	pass

8.1	passed
8.2	passed with comment
	Need to specify that this uses the same key value as does 8.1

9	-- checked--

10.1	-- not checked --
10.2	-- not checked --

11.1	fails
	Text states signed with RSA, message signed with DSA
	DSA signature OID incorrect
	Receipt is going to cn="AliceRSA" and robert.colestock <at> wang.com
- should alice be an RFC822 name?
11.2	-- not checked --
11.3  passed
11.4  passed
11.5  -- not checked -- 
11.6 	-- not checked --

**************************************** 6.11 intermediate data from my
test ****************
But it fails....

Wrapped key
0x0012F248  74 31 c0 45 51 4c 3c 2d 2e da 63 50 8b ae d4 ac
t1ÀEQL<-.ÚcP.®Ô¬
0x0012F258  64 cc 95 ae af cd 0f 8c b6 48 1f 0b 45 12 4d fb
dÌ.®¯Í..¶H..E.M.
0x0012F268  a4 ab c7 83 30 4b 69 ad                         ¤«Ç.0Ki­

Mail list key
0x00324354  25 5e 0d 1c 07 b6 46 df b3 13 4c c8 43 ba 8a a7
%^...¶Fß³.LÈCº.§
0x00324364  1f 02 5b 7c 08 38 25 1f

After decrypt #1
0x00324630  d7 10 66 ee 9a 42 e0 80 62 a3 e5 de b5 ef 4e 7e
×.f..B..b£.Þµ.N~
0x00324640  5f 13 30 b5 13 d3 a8 4f be dc 02 d4 81 27 db 50
_.0µ.Ó¨O¾Ü.Ô.'ÛP
0x00324650  e5 d8 0f e9 25 38 f1 7b                         .Ø..%8.{

IV
0x00324630  7b f1 38 25 e9 0f d8 e5                         {.8%..Ø.

Post Decrypt #2
0x00324630  50 db 27 81 d4 02 dc be 4f a8 d3 13 b5 30 13 5f
PÛ'.Ô.ܾO¨Ó.µ0._
0x00324640  7e 4e ef b5 de e5 a3 62 80 e0 42 9a ee 66 10 d7
~N.µÞ.£b..B..f.×

Computed check sum
0x0012EFD8  53 fb 3e cc 8a 06 cc af                         S.>Ì..̯

Actual Check sum
 80 e0 42 9a ee 66 10 d7

--- they don't match!!!!!

Holger Ebel | 3 Jul 17:15 2003
Picon

Re: Status of the examples draft


Paul,

please find below our test results for the V 11 of the smime-examples
draft.

-----------------------------------------------------------------------

Test results for S/MIME Examples-11; the libraries which were used for
these tests: - AuthentiDate's Java Security Provider (AJSP 1.5.1)
              - various Java algorithm engines

4. Trivial

4.1 ContentInfo with Data type, BER

ok

4.2 ContentInfo with Data type, DER

ok

5. SignedData

5.1 Basic, DSS/DSA

ok

5.2 Basic, RSA

ok

5.3 Basic, DSS/DSA, detached

ok

5.4 Fancier signed content

ok,

Note: - includes also AliceRSA certificate.
       - *the countersigner is not Diane, but AliceRSA*
       - if Diane is performing the countersignature, her
         cert should be also included in the certificate
         field of the signed data.
         (like AliceRSA cert)

5.5 All RSA signed message

ok

5.6 Multiple signers

ok

5.7 Signing using SKI

ok

5.8 S/MIME clear signed

ok,

Note: - SignatureAlgorithm is 1.2.840.10040.4.1, *not* 1.2.840.10040.4.3
         DSA vs. SHA1withDSA

5.9 S/MIME opaque

ok,

Note: - SignatureAlgorithm is 1.2.840.10040.4.1 *not* 1.2.840.10040.4.3
         DSA vs. SHA1withDSA

5.10 SignedData with Attributes

ok

5.11 CertsCrlsOnly signed message

ok

Note: - *includes also a CRL (CarlDSSCRLForAll.crl)*

6. Enveloped Data

Note: No KeyAgreeRecipientInfo EnvelopedData could be decrypted due
to the fact that Sun's JCE/JCA only covers PKCS#3 DH KeyParameter.

6.1 TripleDES / DH

n/a

6.2 TripleDES / RSA

ok

6.3 RC2/40 / RSA

ok

6.4

n/a

6.5

n/a

6.6

n/a

6.7 RC2/40 / RSA

ok

6.8

n/a

6.9

ok

6.10

n/a

6.11

n/a

7 Digested Data

not supported

8 Encrypted Data

not supported

9 Authenticated Data

not supported

10 Key Wrapping

10.1 RC2

n/a

10.2 3DES

ok

11 ESS

not supported

---------------

Best Regards,

Holger Ebel

Paul Hoffman / IMC wrote:
> 
> Hi again. The -11 draft has the following changes:
> 5.1.bin
> 5.3.bin
> 5.4.bin
> 5.6.bin
> 5.7.bin
> 5.10.bin
> 8.2.bin
> 11.1.bin
> 11.2.bin
> 
> It would be great if everyone who has tested can re-test with these new 
> examples.
> 
> BTW, I forgot to change the title of 6.3 to say RC2/128, and will do so 
> in the -12 draft. (Just to be sure, I have already started the -12 draft 
> so I don't space out again...)
> 
> I would like to update the chart below for the -11 draft soon so we can 
> move it to IETF last call.
> 
> ======================================
> 
> Status of the examples in -10
> 
> 4. Trivial Examples
> 
> 4.1 ContentInfo with Data type, BER
>   John Pawling: tested OK.
>   Jim Schaad: tested OK.
>   Jeff Jacoby: tested OK.
>   Holger Ebel: tested OK.
> 
> 4.2 ContentInfo with Data type, DER
>   John Pawling: tested OK.
>   Jim Schaad: tested OK.
>   Jeff Jacoby: tested OK.
>   Holger Ebel: tested OK.
> 
> 5.  Signed-data
>   Jim Schaad pointed out that many examples had the
>     signatureAlgorithm of 1.2.840.10040.4.1 (dsa) but it should instead
>     be 1.2.840.10040.4.3 (dsaWithSha1).
>   The general decision was that the examples should have dsaWithSha1.
>   John Pawling and Sue Beauchamp at DigitalNet agreed to re-generate
>     the examples.
> 
> 5.1 Basic signed content, DSS
>   John Pawling: tested OK.
>   Blake Ramsdell: tested OK.
>   Jim Schaad: failed.
>     signatureAlgorithm is dsa but should be dsaWithSha1
>   Holger Ebel: tested OK.
>   Sue Beauchamp sent new example file.
> 
> 5.2 Basic signed content, RSA
>   John Pawling: tested OK.
>   Blake Ramsdell: tested OK.
>   Jim Schaad: tested OK.
>   Jeff Jacoby: tested OK.
>   Holger Ebel: tested OK.
> 
> 5.3 Basic signed content, detached content
>   John Pawling: tested OK.
>   Blake Ramsdell: tested OK.
>   Jim Schaad: failed.
>     Contains Alice's RSA certificate
>     No content hint unsigned attribute
>     signatureAlgorithm is dsa but should be dsaWithSha1
>   Jeff Jacoby: tested OK.
>   Holger Ebel: tested OK.
>   Sue Beauchamp sent new example file.
> 
> 5.4 Fancier signed content
>   John Pawling: tested OK.
>   Blake Ramsdell: tested OK.
>   Jeff Jacoby: tested OK.
>   Holger Ebel: tested OK.
>     Countersigner is Alice, not Diane
>     No content hint
>   Sue Beauchamp sent new example file.
> 
> 5.5 All RSA signed message
>   John Pawling: tested OK.
>   Blake Ramsdell: tested OK.
>   Jim Schaad: tested OK.
>   Jeff Jacoby: tested OK.
>   Holger Ebel: tested OK.
> 
> 5.6 Multiple signers
>   John Pawling: tested OK.
>   Blake Ramsdell: tested OK.
>   Jim Schaad: failed.
>     signatureAlgorithm is dsa but should be dsaWithSha1
>   Holger Ebel: tested OK.
>   Sue Beauchamp sent new example file.
> 
> 5.7 Signing using SKI
>   John Pawling: tested OK.
>   Blake Ramsdell: tested OK.
>   Jim Schaad: failed.
>     signatureAlgorithm is dsa but should be dsaWithSha1
>   Holger Ebel: tested OK.
>   Sue Beauchamp sent new example file.
> 
> 5.8 S/MIME multipart/signed message
>   John Pawling: tested OK.
>   Blake Ramsdell: tested OK.
>   Holger Ebel: tested OK except that it has a CRLF prepended.
> 
> 5.9 S/MIME application/pkcs7-mime signed message
>   John Pawling: tested OK.
>   Blake Ramsdell: tested OK.
>   Jim Schaad: failed because signatureAlgorithm of dsa not dsaWithSha1
>   Holger Ebel: tested OK except that it has a CRLF prepended.
> 
> 5.10 SignedData With Attributes
>   John Pawling: tested OK.
>   Blake Ramsdell: tested OK.
>   Jim Schaad: failed.
>     Change "unknown OID" to "unknown OID (1.2.5555)"
>     Content Hint should have an OID of 1.2.840.113549.1.7.1
>     Content Identifier attribute absent
>     Contains Security Label attribute
>     Contains encrypt key preference attribute
>     Contains ML Expansion History attribute
>     Contains Equivalent Label attribute
>   Jeff Jacoby: tested OK.
>   Holger Ebel: failed (not signed by Alice).
> 
> 5.11 SignedData with Certificates Only
>   John Pawling: tested OK.
>   Blake Ramsdell: tested OK.
>   Jeff Jacoby: tested OK.
>   Holger Ebel: tested OK.
> 
> 6.  Enveloped-data
> 
> 6.1 Basic encrypted content, TripleDES and DH
>   John Pawling: tested OK.
>   Holger Ebel: tested OK.
> 
> 6.2 Basic encrypted content, TripleDES and RSA
>   John Pawling: tested OK.
>   Blake Ramsdell: tested OK.
>   Jeff Jacoby: tested OK.
>   Holger Ebel: tested OK.
> 
> 6.3 Basic encrypted content, RC2/40 and RSA
>   Blake Ramsdell: this is actually a 128-bit key.
>   Jeff Jacoby: confirmed Blake's assertion.
>   Paul Hoffman: thinks we could just change the title of the example.
>   John Pawling: tested OK.
>   Blake Ramsdell: tested OK.
>   Jeff Jacoby: tested OK.
>   Holger Ebel: tested OK.
> 
> 6.4 Encrypted content, two recipients, no shared keying material
>   John Pawling: tested OK but noted unsuccessful Invalid tag for
>     privateKeyInfo for second login.
>   Holger Ebel: tested OK.
> 
> 6.5 Encrypted content, two recipients, shared keying material
>   John Pawling: could not test due to bug in his code.
>   Holger Ebel: tested OK.
> 
> 6.6 Encrypted content, TripleDES and DH, previously-distributed keys
>   John Pawling: tested OK.
>   Holger Ebel: tested OK.
> 
> 6.7 Encrypted content, RC2/40 and RSA, previously-distributed keys
>   John Pawling: tested OK.
>   Holger Ebel: tested OK.
> 
> 6.8 S/MIME application/pkcs7-mime encrypted message
>   John Pawling: tested OK.
>   Holger Ebel: tested OK.
> 
> 6.9 EnvelopedData with All Recipient Types
>   John Pawling: tested OK.
>   Holger Ebel: tested OK.
> 
> 6.10 EnvelopedData with KARI RC2 Encryption
>   John Pawling: tested OK.
>   Holger Ebel: tested OK.
> 
> 6.11 EnvelopedData with KEK 3DES Encryption
>   John Pawling: tested OK.
>   Holger Ebel: tested OK.
> 
> 7. Digested-data
>   Blake Ramsdell: tested OK.
>   Jeff Jacoby: tested OK.
> 
> 8. Encrypted-data
> 
> 8.1 Simple EncryptedData
>   Blake Ramsdell: tested OK.
>   Jim Schaad: tested OK.
>   Jeff Jacoby: tested OK.
> 
> 8.2 EncryptedData with unprotected attributes
>   Jim Schaad: failed badly.
>     The key is not in the text and it is not the same as 8.1
>     The encapsulated content type is EncryptedData not id-data
>     The content hint content type does not match the encapsulated 
> content type
> 
> 9. Authenticated-data
>   There are still no examples in this section.
> 
> 10. Key Wrapping
>   John Pawling: tested OK.
> 
> 10.1 Wrapping RC2
>   John Pawling: tested OK.
> 
> 10.2 Wrapping TripleDES
>   John Pawling: tested OK.
>   Holger Ebel: tested OK.
> 
> 11. ESS Examples
> 
> 11.1 ReceiptRequest
>   John Pawling: test failed, has sent new example file.
>   Jeff Jacoby: tested OK.
> 
> 11.2 Receipt
>   John Pawling: test failed, has sent new example file.
> 
> 11.3 eSSSecurityLabel
>   John Pawling: tested OK.
>   Jim Schaad: tested OK.
>   Jeff Jacoby: tested OK.
> 
> 11.4 EquivalentLabels
>   John Pawling: tested OK.
>   Jeff Jacoby: tested OK.
> 
> 11.5 mlExpansionHistory
>   John Pawling: tested OK.
>   Jeff Jacoby: tested OK.
> 
> 11.6 SigningCertificate
>   John Pawling: tested OK.
>   Jeff Jacoby: tested OK.
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium
> 

Paul Hoffman / IMC | 2 Jul 17:32 2003
Picon

Fwd: I-D ACTION:draft-ietf-smime-examples-11.txt


>X-Authentication-Warning: above.proper.com: majordom set sender to 
>owner-ietf-smime <at> mail.imc.org using -f
>To: IETF-Announce: ;
>Cc: ietf-smime <at> imc.org
>From: Internet-Drafts <at> ietf.org
>Reply-to: Internet-Drafts <at> ietf.org
>Subject: I-D ACTION:draft-ietf-smime-examples-11.txt
>Date: Wed, 02 Jul 2003 06:56:53 -0400
>Sender: owner-ietf-smime <at> mail.imc.org
>List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
>List-ID: <ietf-smime.imc.org>
>List-Unsubscribe: <mailto:ietf-smime-request <at> imc.org?body=unsubscribe>
>
>
>
>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>This draft is a work item of the S/MIME Mail Security Working Group 
>of the IETF.
>
>	Title		: Examples of S/MIME Messages
>	Author(s)	: P. Hoffman
>	Filename	: draft-ietf-smime-examples-11.txt
>	Pages		: 8
>	Date		: 2003-7-1
>
>This document gives examples of message bodies formatted using S/MIME.
>Specifically, it has examples of Cryptographic Message Syntax (CMS)
>objects, S/MIME messages (including the MIME formatting), and Enhanced
>Security Services for S/MIME (ESS). It includes examples of most or all
>common CMS and ESS formats; in addition, it gives examples that show
>common pitfalls in implementing CMS. The purpose of this document is to
>help increase interoperability for S/MIME and other protocols that rely
>on CMS.
>This draft is being discussed on the 'ietf-smime' mailing list.  To
>join the list, send a message to <ietf-smime-request <at> imc.org> with the
>single word 'subscribe' in the body of the message.  Also, there is a
>Web site for the mailing list at <http://www.imc.org/ietf-smime/>.
>
>This draft is being discussed on the 'ietf-smime' mailing list.  To
>join the list, send a message to <ietf-smime-request <at> imc.org> with the
>single word 'subscribe' in the body of the message.  Also, there is a
>Web site for the mailing list at <http://www.imc.org/ietf-smime/>.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-smime-examples-11.txt
>
>To remove yourself from the IETF Announcement list, send a message to
>ietf-announce-request with the word unsubscribe in the body of the message.
>
>Internet-Drafts are also available by anonymous FTP. Login with the username
>"anonymous" and a password of your e-mail address. After logging in,
>type "cd internet-drafts" and then
>	"get draft-ietf-smime-examples-11.txt".
>
>A list of Internet-Drafts directories can be found in
>http://www.ietf.org/shadow.html
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>	mailserv <at> ietf.org.
>In the body type:
>	"FILE /internet-drafts/draft-ietf-smime-examples-11.txt".
>
>NOTE:	The mail server at ietf.org can return the document in
>	MIME-encoded form by using the "mpack" utility.  To use this
>	feature, insert the command "ENCODING mime" before the "FILE"
>	command.  To decode the response(s), you will need "munpack" or
>	a MIME-compliant mail reader.  Different MIME-compliant mail readers
>	exhibit different behavior, especially when dealing with
>	"multipart" MIME messages (i.e. documents which have been split
>	up into multiple messages), so check your local documentation on
>	how to manipulate these messages.
>
>
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
>
>
>[The following attachment must be fetched by mail. Command-click the 
>URL below and send the resulting message to get the attachment.]
><mailto:mailserv <at> ietf.org?body=ENCODING%20mime%0D%0AFILE%20/internet-drafts/draft-ietf-smime-examples-11.txt>
>[The following attachment must be fetched by ftp.  Command-click the 
>URL below to ask your ftp client to fetch it.]
><ftp://ftp.ietf.org/internet-drafts/draft-ietf-smime-examples-11.txt>

Holger Ebel | 26 Jun 13:34 2003
Picon

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


Hi folks,

Test results for S/MIME Examples-10; the libraries which were used for
these tests: - AuthentiDate's Java Security Provider (AJSP 1.5)
              - various Java algorithm engines

4. Trivial

4.1 ContentInfo with Data type, BER

Tested content equals ExContent: ok
Tested content type is Data: ok

4.2 ContentInfo with Data type, DER

Tested content equals ExContent: ok
Tested content type is Data: ok

5. SignedData

Note: All occurrences of the signatureAlgorithm DSA have been silently
replaced by DSAwithSHA for our tests since this will be happen also
in the next version of this draft.

5.1 Basic, DSS/DSA

Signed by Alice (DSS/DSA): ok
without attribute certificates: ok
just her cert included in the certificates field: ok
no crl: ok
no signed attributes: ok
no unsigned attributes: ok
the message is exContent: ok
message in included in encap content: ok

5.2 Basic, RSA

Signed by Alice (RSA): ok
without attribute certificates: ok
just her cert included in the certificates field: ok
no crl: ok
no signed attributes: ok
no unsigned attributes: ok
the message is exContent: ok
message in included in encap content: ok

5.3 Basic, DSS/DSA, detached

Signed by Alice (DSS/DSA): ok
without attribute certificates: ok
just her cert included in the certificates field: ok
no crl: ok
no signed attributes: ok
no unsigned attributes: ok
the message is exContent: ok
message is not included in encap content: ok
hash values are equal: ok

5.4 Fancier signed content

Signed by Alice (DSS/DSA): ok
without attribute certificates: ok
include signers cert: AliceDSA *and* AliceRSA: ok
include root cert: ok
crl included: ok (CarlDSSCRLForAll.crl)
signed attributes: found 3
  (1) ContentType   1.2.840.113549.1.9.3
  (2) Signing Time  1.2.840.113549.1.9.5
  (3) MessageDigest 1.2.840.113549.1.9.4

unsigned attributes: found 1
  (1) CounterSignature 1.2.840.113549.1.9.6
      CounterSignature could be verified: ok

the message is exContent: ok
message in included in encap content: ok

Note: - includes also AliceRSA certificate.
       - the countersigner is not Diane, but AliceRSA
       - if Diane is performing the countersignature, her
         cert should be also included in the certificate
         field of the signed data.
         (like AliceRSA cert)
       - the content hint attribute is not included

5.5 All RSA signed message

Signed by Alice (RSA): ok
without attribute certificates: ok
include signer cert: ok
include root cert: ok
no crl: ok
no signed attributes: ok
no unsigned attributes: ok
the message is exContent: ok
message in included in encap content: ok

5.6 Multiple signers

Signed by Alice (DSS/DSA): ok
Signed by Diane (DSS/DSA): ok
no attribute certificates: ok
both signing certs included: ok
no crl: ok
no signed attributes (both): ok
no unsigned attributes (both): ok
the message is exContent: ok
message in included in encap content: ok

Note: Since the key params of Diane are inherited
from Carls key, it whould be nice to have also his
certificate included in the certificate list.

5.7 Signing using SKI

Signed by Alice (DSS/DSA): ok
without attribute certificates: ok
include signer cert: ok
no crl: ok
no signed attributes: ok
no unsigned attributes: ok
the message is exContent: ok
message in included in encap content: ok

5.8 S/MIME clear signed

Message can be parsed: ok

the signatureContainer body part is the one from Chapter 5.3: ok
the signatureContainer is the one from Chapter 5.3: *no*, since
the detached content differs (prepended <CR><LF>).
S/MIME message can be verified: ok

5.9 S/MIME opaque

Message can be parsed: ok
the signatureContainer body part is the one from Chapter 5.1: ok
the signatureContainer is the one from Chapter 5.3: *no*, since
the encap content differs (prepended <CR><LF>).
S/MIME message can be verified: ok

5.10 SignedData with Attributes

no certificate: ok
without attribute certificates: ok
no crl: ok

signed attributes: found 10

  (1)  ContentType 	1.2.840.113549.1.9.3
  (2)  MessageDigest	1.2.840.113549.1.9.4
  (3)  1.2.5555
  (4)  ContentHint	1.2.840.113549.1.9.16.2.4
       -> contentType (Oid) 1.2.3.6.5.4
  (5)  S/Mime capabilities 1.2.840.113549.1.9.15
  (6)  SecurityLabel 	 1.2.840.113549.1.9.16.2.2
  (7)  ContentReference 	 1.2.840.113549.1.9.16.2.10
  (8)  EncryptionKeyPreference	1.2.840.113549.1.9.16.2.11
  (9)  ML ExpandHistory 	 1.2.840.113549.1.9.16.2.3
  (10) EquivalentLabels 	 1.2.840.113549.1.9.16.2.9

no unsigned attributes: ok
the message is exContent: ok
message in included in encap content: ok

Signed by Alice (DSS/DSA): *no*
the message is exContent: ok
message in included in encap content: ok

Note: *Message could not be verified*

5.11 CertsCrlsOnly signed message

no content: ok
no signer: ok
one crl: ok (CarlDSSCRLForAll.crl)
Carl's (root) certificate included: ok
Alice's certificate included: ok

6. Enveloped Data

Note: No KeyAgreeRecipientInfo EnvelopedData could be decrypted due
to the fact that Sun's JCE/JCA only covers PKCS#3 DH KeyParameter. We'll
have to fix it.

6.1 TripleDES / DH

could be parsed: ok
could be decrypted: n/a
clearText is exContent.bin: n/a
no unprotectedAttributes: ok
no originator info: ok

Note: "An EnvelopedData from Alice to Bob", but where are Alics's DH 
keys? (Just to be sure that the public key is from Alice)

6.2 TripleDES / RSA

could be parsed: ok
could be decrypted: ok
clearText is exContent.bin: ok
no unprotectedAttributes: ok
no originator info: ok

6.3 RC2/40 / RSA

could be parsed: ok
could be decrypted: ok
clearText is exContent.bin: ok
no unprotectedAttributes: ok
no originator info: ok

6.4

could be parsed: ok
could be decrypted: n/a
clearText is exContent.bin: n/a
no unprotectedAttributes: ok
no originator info: ok

6.5

could be parsed: ok
could be decrypted: n/a
clearText is exContent.bin: n/a
no unprotectedAttributes: ok
no originator info: ok

6.6

could be parsed: ok
could be decrypted: n/a

6.7 RC2/40 / RSA

could be parsed: ok
could be decrypted: ok
clearText is exContent.bin: ok
no unprotectedAttributes: ok
no originator info: ok

6.8

could be parsed: ok
could be decrypted: n/a

6.9

could be parsed: ok
could be decrypted: ok
clearText is exContent.bin: ok
no originator info: ok
found unprotectedAttributes: ok
  (1) 1.2.5555
  (2) ContentHint 1.2.840.113549.1.9.16.2.4 -> 1.2.3.6.5.4

6.10

could be parsed: ok
could be decrypted: n/a

6.11

could be parsed: ok
could be decrypted: n/a

7 Digested Data

not supported

8 Encrypted Data

not supported anymore (sorry)

9 Authenticated Data

not supported

10 Key Wrapping

10.1 RC2

not tested

10.2 3DES

wrapping: ok
unwrapping: ok

11 ESS

not supported (yet)

Best Regards,

Holger Ebel

----------------------------------------------------------------------------
Paul Hoffman / IMC wrote:

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

ronen | 4 Jun 07:41 2003

example 5.2 basic signed content RSA


hi,
i am coding CMS ( RFC3380 ) and i was parsing example 5.2 at
draft-ietf-smime-examples-10.txt and got to the Certificate part.
i like to know why it is SEQUENCE ( in the example ) and not SET OF  (as
like in the CMS RFC3380 ).

This is how it is defined in the RFC :
SignedData ::= SEQUENCE {
        version CMSVersion,
        digestAlgorithms DigestAlgorithmIdentifiers,
        encapContentInfo EncapsulatedContentInfo,
        certificates [0] IMPLICIT CertificateSet OPTIONAL,
        crls [1] IMPLICIT CertificateRevocationLists OPTIONAL,
        signerInfos SignerInfos }

 CertificateSet ::= SET OF CertificateChoices

in draft-ietf-smime-examples-10.txt  ex5.2 Basic signed content it is :
-------------------- Content
Info -----------------------------------------------------------------------
-
 0 30  850: SEQUENCE {

-------------------- Content
Type ---------------------------------------------------------------------

   4 06    9:   OBJECT IDENTIFIER signedData (1 2 840 113549 1 7 2)
            :     (PKCS #7)

--------------------- content [0] EXPLICIT ANY DEFINED BY
contentType ---------

  15 A0  835:   [0] {

--------------------- 
SignedData -----------------------------------------------------------------
----
  19 30  831:     SEQUENCE {

-------------------- 
 version ---------------------------------------------------------------
  23 02    1:       INTEGER 1
-------------------- 
digestAlgorithems -------------------------------------------------
  26 31   11:       SET {
  28 30    9:         SEQUENCE {
  30 06    5:           OBJECT IDENTIFIER sha1 (1 3 14 3 2 26)
            :             (OIW)
  37 05    0:           NULL
            :           }
----------------------------------------------------------------------------
------------------------
            :         }
-------------------------- encapsulated
Content ----------------------------------------
  39 30   43:       SEQUENCE {
  41 06    9:         OBJECT IDENTIFIER data (1 2 840 113549 1 7 1)
            :           (PKCS #7)
  52 A0   30:         [0] {
  54 04   28:           OCTET STRING 'This is some sample content.'
            :           }
            :         }

-------------- The start of the
Certificate ------------------------------------------------------------

  84 A0  560:       [0] {
  88 30  556:         SEQUENCE {       <------ why not SET !!! ? ? ? ?
  92 30  405:           SEQUENCE {
  96 A0    3:             [0] {
  98 02    1:               INTEGER 2
            :               }
101 02   16:             INTEGER
            :               46 34 6B C7 80 00 56 BC 11 D3 6E 2E
            :               C4 10 B3 B0
119 30   13:             SEQUENCE {
121 06    9:               OBJECT IDENTIFIER
            :                 sha1withRSAEncryption
            :                     (1 2 840 113549 1 1 5)
            :                 (PKCS #1)
132 05    0:               NULL
            :               }
134 30   18:             SEQUENCE {
136 31   16:               SET {
138 30   14:                 SEQUENCE {
140 06    3:                   OBJECT IDENTIFIER
            :                     commonName


Gmane