Examples Corrections

Here are three items to update the examples documents.

They are 1)  a new certificate for BOB, 2) Example 6.2 encoded as BER
not DER and 3) Example 6.3.  I believe they are correct, but they need
to be verified.

Jim

Comments on new files

Jim,

I have some comments on your last post.

1. I noticed that the public key in BobRSASignByCarl.cer changed to be what
appears to be Carl's public key.  I don't mind this, it's just that I
thought that each one would have their own keypair.

2. From what I can tell, 6.2.ber is still DER, not BER.  Well, I guess
technically it's BER, but using definite lengths for everything ;).  I
presume that the intent was to use indefinite lengths for constructed
elements, which this example does not appear to do.

3. 6.2.ber still does not decrypt in my environment with
BobPrivRSAEncrypt.pri (the unwrapped key does not appear to have the correct
block format, leading me to believe that it is the wrong private key.  I am
in the process of pulling all of this stuff apart to determine if it's a bug
in my code or in the data.

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

RE: Comments on new files

You are correct, I had assumed that the two .pri files where different
and the problem was with the certificate.  This is incorrect.

However I am surprised that 6.2.ber does not decrypt.  It appears to
decrypt correctly in my system.

jim

> -----Original Message-----
> From: owner-ietf-smime-examples <at> mail.imc.org 
> [mailto:owner-ietf-smime-examples <at> mail.imc.org] On Behalf Of 
> Blake Ramsdell
> Sent: Thursday, March 07, 2002 6:19 PM
> To: jimsch <at> exmsft.com
> Cc: John.Pawling <at> GetronicsGov.com; IETF-SMIME-Examples; Paul Hoffman
> Subject: Comments on new files
> 
> 
> 
> Jim,
> 
> I have some comments on your last post.
> 
> 1. I noticed that the public key in BobRSASignByCarl.cer 
> changed to be what
> appears to be Carl's public key.  I don't mind this, it's just that I
> thought that each one would have their own keypair.
> 
> 2. From what I can tell, 6.2.ber is still DER, not BER.  Well, I guess

Re: Comments on new files

----- Original Message -----
From: "Jim Schaad" <jimsch <at> nwlink.com>
To: "'Blake Ramsdell'" <blake <at> brutesquadlabs.com>; <jimsch <at> exmsft.com>
Cc: <John.Pawling <at> GetronicsGov.com>; "'IETF-SMIME-Examples'"
<ietf-smime-examples <at> imc.org>; "'Paul Hoffman'" <phoffman <at> imc.org>
Sent: Friday, March 08, 2002 12:51 AM
Subject: RE: Comments on new files

> You are correct, I had assumed that the two .pri files where different
> and the problem was with the certificate.  This is incorrect.
>
> However I am surprised that 6.2.ber does not decrypt.  It appears to
> decrypt correctly in my system.

With the confusion surrounding the pairings of the public / private keys, I
thought that there was still a possibility that it was encrypted using the
public key from Bob's original certificate, which I don't think I have the
private key.  I'll do some more testing and see what I can come up with.
The RSA code I'm using has only been successfully used for signature
verification, and it's possible that I'm running into some kind of
signed/unsigned big integer conversion error or some such thing.

Blake

RE: Unknown OID

Updated files

Here are a set of updated files for the draft.  

New private key and certificate for Bob RSA.

New example files for section 6.  Note that 6.2 is BER not DER encoded,
but as this is different I think it is good.

Jim

Updated example #7

Here is the updated digest example.

Decrypting 6.2

OK, so I pounded on the new 6.2 a bit.  I was able to unwrap the 3DES key
provided, but I was not successful at decrypting the content.  The relevant
parameters that I extracted from the message are as follows:

IV
E1 D1 EB E0 26 CA 58 49

Keys
13 54 34 97 7A D3 F7 45 EF 89 CE 0E 83 73 FE 2F
1A C2 57 6D E9 C7 19 EC

3DES encrypted content
02 3A 0A 0B BE B7 31 1D D4 C3 EB CA 91 18 AD 89
7B 2D F8 B1 FB FD BF 2A 52 81 77 DA 9F 49 7F 00

This yielded:

Decrypted content
BA 8C 40 73 91 05 EA 2E D6 C2 47 18 3A 9C 38 CD
20 4C E3 FA 21 7B 5C E1

The decrypted content does not appear to be correct, and this could very
well be an error in the decryption code on my side.  If anyone else has a
different result, let me know.  I'm still looking at my implementation, but
I'm running out of possibilities.  I'm putting in another 3DES
implementation to see if the results are any different.  I am fairly certain
that the keys are correct, since the RSA block padding was intact and the
unpadded keying material was 24 bytes long.  I am almost 100% certain that
the input data is correct, since that's verifiable by dumping the ASN.1 and
parsing it by hand.  So I think this leaves "encryption error" or
"decryption error".

Any comments, please let me know.

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

Re: Decrypting 6.2

----- Original Message -----
From: "Blake Ramsdell" <blake <at> brutesquadlabs.com>
To: "IETF-SMIME-Examples" <ietf-smime-examples <at> imc.org>; <jimsch <at> nwlink.com>
Sent: Wednesday, March 20, 2002 11:49 PM
Subject: Decrypting 6.2

> OK, so I pounded on the new 6.2 a bit.  I was able to unwrap the 3DES key
> provided, but I was not successful at decrypting the content.

I forgot to add "due to my own stupidity".

I found an error in my code, and example 6.2 correctly decrypts to the
contents of ExContent.bin using the new private key provided.  Sorry for the
false alarm.  I see no problems with 6.2, and it is indeed indefinite length
encoded.

Blake

Re: Updated example #7

Also my code correctly decrypts the examples 6.2 and 6.3 now, with Jim's
updated files.
By the way, where's 8.2 key?

Luciano Medina