Subject: Draft-11: More complete results

From: "Jim Schaad" <[email-masked]>
Date: Wed, 6 Aug 2003 14:29:47 -0700

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 ([email-masked])
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!!!!!

---

From: "Blake Ramsdell" <[email-masked]>
Date: Sat, 9 Aug 2003 01:17:16 -0700

> -----Original Message-----
> From: Jim Schaad [mailto:[email-masked]] 
> Sent: Wednesday, August 06, 2003 2:30 PM
> To: 'Ietf-Smime-Examples'; [email-masked]; 'Paul Hoffman / IMC'
> Cc: 'Sean P. Turner'; Blake Ramsdell
> Subject: Draft-11: More complete results
> 
> 6.11	FAILED

The bad news is, I can't get this example to work either.  The good news
is that I have written a new implementation, and it could very well have
some kind of problem.  I have only tested my implementation against the
test vectors in RFC 3217.

These are the results that I got with this example, using the
terminology from RFC 3217 section 3.2 wherever possible:

<lotsofboringhexdump>
wrappedKey = 0x74, 0x31, 0xC0, 0x45, 0x51, 0x4C, 0x3C, 0x2D, 0x2E, 0xDA,
0x63, 0x50, 0x8B, 0xAE, 0xD4, 0xAC, 0x64, 0xCC, 0x95, 0xAE, 0xAF, 0xCD,
0x0F, 0x8C, 0xB6, 0x48, 0x1F, 0x0B, 0x45, 0x12, 0x4D, 0xFB, 0xA4, 0xAB,
0xC7, 0x83, 0x30, 0x4B, 0x69, 0xAD

TEMP3 = 0xD7, 0x10, 0x66, 0xEE, 0x9A, 0x42, 0xE0, 0x80, 0x62, 0xA3,
0xE5, 0xDE, 0xB5, 0xEF, 0x4E, 0x7E, 0x5F, 0x13, 0x30, 0xB5, 0x13, 0xD3,
0xA8, 0x4F, 0xBE, 0xDC, 0x02, 0xD4, 0x81, 0x27, 0xDB, 0x50, 0xE5, 0xD8,
0x0F, 0xE9, 0x25, 0x38, 0xF1, 0x7B

TEMP2 = 0x7B, 0xF1, 0x38, 0x25, 0xE9, 0x0F, 0xD8, 0xE5, 0x50, 0xDB,
0x27, 0x81, 0xD4, 0x02, 0xDC, 0xBE, 0x4F, 0xA8, 0xD3, 0x13, 0xB5, 0x30,
0x13, 0x5F, 0x7E, 0x4E, 0xEF, 0xB5, 0xDE, 0xE5, 0xA3, 0x62, 0x80, 0xE0,
0x42, 0x9A, 0xEE, 0x66, 0x10, 0xD7

TEMP1 = 0x50, 0xDB, 0x27, 0x81, 0xD4, 0x02, 0xDC, 0xBE, 0x4F, 0xA8,
0xD3, 0x13, 0xB5, 0x30, 0x13, 0x5F, 0x7E, 0x4E, 0xEF, 0xB5, 0xDE, 0xE5,
0xA3, 0x62, 0x80, 0xE0, 0x42, 0x9A, 0xEE, 0x66, 0x10, 0xD7

IV = 0x7B, 0xF1, 0x38, 0x25, 0xE9, 0x0F, 0xD8, 0xE5

CEKICV = 0x51, 0x1B, 0x27, 0x0E, 0xE8, 0xEA, 0x33, 0x74, 0x37, 0xA5,
0x7D, 0xC7, 0xCC, 0x9B, 0x24, 0xCE, 0x32, 0x41, 0x19, 0x0F, 0x38, 0x47,
0x25, 0x2E, 0xC0, 0xCA, 0x0F, 0x30, 0x3B, 0x86, 0x2E, 0x3D

CEK = 0x51, 0x1B, 0x27, 0x0E, 0xE8, 0xEA, 0x33, 0x74, 0x37, 0xA5, 0x7D,
0xC7, 0xCC, 0x9B, 0x24, 0xCE, 0x32, 0x41, 0x19, 0x0F, 0x38, 0x47, 0x25,
0x2E

ICV = 0xC0, 0xCA, 0x0F, 0x30, 0x3B, 0x86, 0x2E, 0x3D

computedICV = 0x53, 0xFB, 0x3E, 0xCC, 0x8A, 0x06, 0xCC, 0xAF
</lotsofboringhexdump>

> %^...¶Fß³.LÈCº.§ 0x00324364  1f 02 5b 7c 08 38 25 1f

We're on the same page here.  I did not dump my Mail list key, but there
are many problems I would have later if these weren't the same.
Specifically, the next item would not match.

> 0x00324650  e5 d8 0f e9 25 38 f1 7b                         .Ø..%8.{

Same as TEMP3 from mine.

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

Same as my IV also.

> PÛ'.Ô.Ü¾O¨Ó.µ0._ 0x00324640  7e 4e ef b5 de e5 a3 62 80 e0 42 9a ee 66

This should theoretically be the same as my CEKICV (which is the output
of the second decryption), but it's not.  This appears to be the same as
my TEMP1 which is the input to the second decryption, not the output.

> 0x0012EFD8  53 fb 3e cc 8a 06 cc af                         S.>Ì..Ì¯

Same as my computedICV above.  What I can't figure out is how we both
arrived at the same checksum with such different answers for CEKICV
(your "Post Decrypt #2").  My understanding is that it's the first eight
bytes of the sha-1 digest of the first 24 bytes of my CEKICV and your
"Post Decrypt #2".

>  80 e0 42 9a ee 66 10 d7

This does not match my ICV above, but it matches the eight bytes at the
end of your "Post Decrypt #2".

I would hazard a guess that there is an error in one of our
implementations where the input and the output of the second decryption
step are being mistakenly interchanged.  I have checked mine and run the
test vectors from RFC 3217 through it, and I can't see the problem on my
side.  Now, I've said this kind of thing before and been wrong, so take
it with a grain of salt...

In any case, in my test, this example is broken also, but unless Jim and
I can agree on an answer, it could be the case that both of our
implementations are broken.

Blake

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 11 Aug 2003 11:49:34 -0700

Blake,

I don't know what I dumped the first time, but I now get the same CEKICV
as you do.

jim

> From: Blake Ramsdell [mailto:[email-masked]] 
> Sent: Saturday, August 09, 2003 1:17 AM
> To: [email-masked]; 'Ietf-Smime-Examples'; 
> [email-masked]; 'Paul Hoffman / IMC'
> Cc: 'Sean P. Turner'
> Subject: RE: Draft-11: More complete results
> 
> 
> > 	test vectors are appended below on this message.  I 
> don't know where 
> > I am going wrong and this code worked in the past.
> 
> The bad news is, I can't get this example to work either.  
> The good news is that I have written a new implementation, 
> and it could very well have some kind of problem.  I have 
> only tested my implementation against the test vectors in RFC 3217.
> 
> wrappedKey = 0x74, 0x31, 0xC0, 0x45, 0x51, 0x4C, 0x3C, 0x2D, 
> 0x2E, 0xDA, 0x63, 0x50, 0x8B, 0xAE, 0xD4, 0xAC, 0x64, 0xCC, 
> 0x95, 0xAE, 0xAF, 0xCD, 0x0F, 0x8C, 0xB6, 0x48, 0x1F, 0x0B, 
> 0x45, 0x12, 0x4D, 0xFB, 0xA4, 0xAB, 0xC7, 0x83, 0x30, 0x4B, 0x69, 0xAD
> 
> TEMP3 = 0xD7, 0x10, 0x66, 0xEE, 0x9A, 0x42, 0xE0, 0x80, 0x62, 
> 0xA3, 0xE5, 0xDE, 0xB5, 0xEF, 0x4E, 0x7E, 0x5F, 0x13, 0x30, 
> 0xB5, 0x13, 0xD3, 0xA8, 0x4F, 0xBE, 0xDC, 0x02, 0xD4, 0x81, 
> 0x27, 0xDB, 0x50, 0xE5, 0xD8, 0x0F, 0xE9, 0x25, 0x38, 0xF1, 0x7B
> 
> TEMP2 = 0x7B, 0xF1, 0x38, 0x25, 0xE9, 0x0F, 0xD8, 0xE5, 0x50, 
> 0xDB, 0x27, 0x81, 0xD4, 0x02, 0xDC, 0xBE, 0x4F, 0xA8, 0xD3, 
> 0x13, 0xB5, 0x30, 0x13, 0x5F, 0x7E, 0x4E, 0xEF, 0xB5, 0xDE, 
> 0xE5, 0xA3, 0x62, 0x80, 0xE0, 0x42, 0x9A, 0xEE, 0x66, 0x10, 0xD7
> 
> TEMP1 = 0x50, 0xDB, 0x27, 0x81, 0xD4, 0x02, 0xDC, 0xBE, 0x4F, 
> 0xA8, 0xD3, 0x13, 0xB5, 0x30, 0x13, 0x5F, 0x7E, 0x4E, 0xEF, 
> 0xB5, 0xDE, 0xE5, 0xA3, 0x62, 0x80, 0xE0, 0x42, 0x9A, 0xEE, 
> 0x66, 0x10, 0xD7
> 
> CEKICV = 0x51, 0x1B, 0x27, 0x0E, 0xE8, 0xEA, 0x33, 0x74, 
> 0x37, 0xA5, 0x7D, 0xC7, 0xCC, 0x9B, 0x24, 0xCE, 0x32, 0x41, 
> 0x19, 0x0F, 0x38, 0x47, 0x25, 0x2E, 0xC0, 0xCA, 0x0F, 0x30, 
> 0x3B, 0x86, 0x2E, 0x3D
> 
> CEK = 0x51, 0x1B, 0x27, 0x0E, 0xE8, 0xEA, 0x33, 0x74, 0x37, 
> 0xA5, 0x7D, 0xC7, 0xCC, 0x9B, 0x24, 0xCE, 0x32, 0x41, 0x19, 
> 0x0F, 0x38, 0x47, 0x25, 0x2E
> 
> We're on the same page here.  I did not dump my Mail list 
> key, but there are many problems I would have later if these 
> weren't the same. Specifically, the next item would not match.
> 
> > After decrypt #1
> This should theoretically be the same as my CEKICV (which is 
> the output of the second decryption), but it's not.  This 
> appears to be the same as my TEMP1 which is the input to the 
> second decryption, not the output.
> 
> > Computed check sum
> Same as my computedICV above.  What I can't figure out is how 
> we both arrived at the same checksum with such different 
> answers for CEKICV (your "Post Decrypt #2").  My 
> understanding is that it's the first eight bytes of the sha-1 
> digest of the first 24 bytes of my CEKICV and your "Post Decrypt #2".
> 
> > Actual Check sum
> >  80 e0 42 9a ee 66 10 d7
> 
> This does not match my ICV above, but it matches the eight 
> bytes at the end of your "Post Decrypt #2".
> 
> implementations where the input and the output of the second 
> decryption step are being mistakenly interchanged.  I have 
> checked mine and run the test vectors from RFC 3217 through 
> it, and I can't see the problem on my side.  Now, I've said 
> this kind of thing before and been wrong, so take it with a 
> grain of salt...
> 
> In any case, in my test, this example is broken also, but 
> unless Jim and I can agree on an answer, it could be the case 
> that both of our implementations are broken.
> 
> Blake
>