Magnus Svensson | 5 Mar 15:18 2001

Old issues remaining in draft-ietf-smime-examples-06.txt

I checked the draft-ietf-smime-examples-06.txt to verify that the issues I
reported earlier had been fixed. Unfortunately some of them remains and I
therefore list them here again:

1. Bob's private RSA key is incorrect. It is actually identical to Carl's
private RSA key. This error is present in both the draft text (the ASN.1
text) and the binary file. As Alexei Shamov pointed out for some time ago,
the correct key can be retrieved by downloading SFL and using the path
<INSTALL_DIR>\smimeR1.8\test\CMS_MSExamples2.d\FirstSet.d\certs.d\private.d\
BobPrivRSAEncrypt.pri. This is surely not a preferred solution, so I suggest
that this issue really is fixed for the next draft. Finding this error is
most probably a frustrating and timeconsuming effort if you are not aware of
it's presence.

2. nextUpdate field is missing in all CRLs. I mentioned this problem in a
previous mail but the problem is still present. The nextUpdate field is
required to be present, see RFC 2459 section 5.1.2.5.

3. In the description of example 6.2 the draft text states: "Does not have a
OriginatorInfo, and has unprotected attributes.". Since the example does not
have unprotected attributes the draft text should state "Does not have an
OriginatorInfo or unprotected attributes.".

4. Example 6.1. Listed below the ASN.1 text are additional information
regarding the keys used in the example. This listing contains two CEKs. The
CEK with the hex-sequence beginning with "CD4F7C8373..." is the correct one.
The other one needs to be removed.

5. Alice's and Bob's RSA certificates distributed separately are different
from those present within the messages. The first has a signature algorithm
(Continue reading)

Pawling, John | 5 Mar 16:29 2001

RE: Old issues remaining in draft-ietf-smime-examples-06.txt

All,

I confirmed that Magnus' comments #2 and #3 are correct.  His other comments
are probably accurate also, but I did not confirm.  

Regarding comment #1, attached is the BobPrivRSAEncrypt.pri file that we
used with the SFL to generate the samples submitted for inclusion in the
Examples-06 document.

Regarding comment #3, agree with Magnus that Section 6.2 should state "does
not have unprotected attributes."  We intentionally omitted unprotected
attributes when we created the 6.2 sample using the SFL.  This was requested
on the smime-examples mail list so that the 6.2 sample would be
backwards-compatible with S/MIME v2.  

Jim Schaad was kind enough to generate the certificates and CRLs included in
the Examples-06 document.  Recommend that Jim work with Paul Hoffman to
address Magnus' comments regarding the certificates and CRLs included in the
Examples-06 document.

===========================================
John Pawling, John.Pawling <at> GetronicsGov.com
Getronics Government Solutions, LLC
===========================================

-----Original Message-----
From: Magnus Svensson [mailto:magnus.svensson <at> entegrity.com]
Sent: Monday, March 05, 2001 9:19 AM
To: ietf-smime-examples <at> imc.org
Subject: Old issues remaining in draft-ietf-smime-examples-06.txt
(Continue reading)

comments and corrections for draft-ietf-smime-examples-06


While decoding the examples, I found what I believe are a few bugs.
Specifically:

1) Example 6.7:
	the KEKIdentifier contains a GeneralizedTime of
	'951230235959Z', which not a valid GeneralizedTime - the year
	must be 4 digits long, i.e. '19951230235959Z'.

2) Examples 6.4 and 6.5:
	the OId for the DH key-agreement algorithm in the
	KeyAgreeRecipientInfo.keyEncryptionAlgorithm field is given as
	1.2.840.10046.2.1; however, rfc-2630, section 12.3.1.1 states
	that the OId must be 1.2.840.113549.1.9.16.3.5 .

3) Example 7.0, DigestedData:
	the content is not the ExContent.bin bytes - it's a truncated
	version thereof ("This some sampe content."). The digest however
	was calculated over ExContent.bin bytes, which means that the
	digest doesn't verify. I'm attaching a fixed DigestedData
	(7.0.bin).

4) Examples 5.1, 5.3, 5.6, 5.7, SignedData:
	I'm unable to verify the signatures on these. To double check,
	I've extracted the raw signature bytes and the public key and
	took the ExContent.bin, and they still won't verify, so I'm
	assuming the examples are at fault.

	Also, a hint that the examples might be screwed is that the
	signatures contain a spurious 0 byte at the end (in the case of
(Continue reading)

Re: comments and corrections for draft-ietf-smime-examples-06

On Thu, Mar 15, 2001 at 07:53:04PM -0800, Life is hard, and then you die wrote:
> 7) Bob's RSA private key (BobPrivRSAEncrypt.pri) does not match the
>    public key in his certificate (BobRSASignByCarl.cer) - compare the
>    moduli and you'll see they differ. The examples 6.2 and 6.3 (haven't
>    checked the others yet) seem to use a private key other than the one
>    given (presumably the one matching the public key in the
>    certificate?) as I'm unable to decrypt those.

Oh, sorry, I meant to update this: the key sent by John Pawling on
March 5th and which he claimed is BobPrivRSAEncrypt.pri is actually
still the same as CarlPrivRSASign.pri, i.e. doesn't match Bob's
certificate (unless the list archive is faulty:
http://www.imc.org/ietf-smime-examples/mail-archive/bin00018.bin ).

  Cheers,

  Ronald

Glen Kleidon | 20 Mar 04:46 2001
Picon

I am clearly missing something. General Questions

I  am trying to come to grips with the SMIME.   I am getting there I think but I am just missing a couple of bits of info.  Perhaps there is a RFC I haven't read which answers all these questions.
 
In the examples (draft-ietf-smime-examples-06.txt) I could not understand how you get 9 bytes for the DES3/RSA oid but I have now been told that you encode the
first two digits as a+40 + b but is that 43 (2B)  or $40 + $02 + $01 = $43 and the large number > 7f in multiple bytes.  Are these large numbers encoded in Lowbyte/Highbyte format?
 
eg the new id-RSAES-OAEP   is iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 7  again 10 bytes
  would that be        
2B 03 48 01 BB 8D 01 01 07   or
43 03 48 01 BB 8D 01 01 07   or
2B 48 03 01 8D BB 01 01 07   or
43 48 03 01 8D BB 01 01 07   or
or something else?
 
Also, are the lengths low/high byte too
eg in example 6.1 should the sequence be  for
 
0 30  286: SEQUENCE {          
4 06    9:   OBJECT IDENTIFIER envelopedData (1 2 840 113549 1 7 3)
         :     (PKCS #7)
15 A0  271:   [0] {             --- I can't get this line either?
19 30  267:     SEQUENCE {
23 02    1:       INTEGER 0
 
30 1E 01 06 09 2B 03 48 01 BB 8D 01 07 03 0A 0F 01 00 30 0B 01 02 01 00
     ??   ??         ??                                                                          ??         ??  ?? 
 
And should the lengths for integer data have 4 bytes ? and what about the octec strings?
 
Second, when I base64 decode your examples it is in what appears to be UNICODE.  It isn't though.  I can't see how you go from the sequence above to the data I get after base 64 decoding the example.  If there is a RFC or other document which explains these things could you tell me what it is?
 
Glen Kleidon | 20 Mar 05:07 2001
Picon

Just not getting it. General Questions from brand new Crytographer

I have been working on SMIME for about 4 days so please don't laugh at any of my questions!!
 
At Paul's suggestion, I post these basic questions here.
 
I  am trying to come to grips with the SMIME.   I am getting there I think but I am just missing a couple of bits of info.  Perhaps there is a RFC I haven't read which answers all these questions.
 
In the examples (draft-ietf-smime-examples-06.txt) I could not understand how you get 9 bytes for the DES3/RSA oid but I have now been told that you encode the
first two digits as a+40 + b but is that 43 (2B)  or $40 + $02 + $01 = $43 and the large number > 7f in multiple bytes.  Are these large numbers encoded in Lowbyte/Highbyte format?
 
eg the new id-RSAES-OAEP   is iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 7 
  would that be        
2B 03 48 01 BB 8D 01 01 07   or
43 03 48 01 BB 8D 01 01 07   or
2B 48 03 01 8D BB 01 01 07   or
43 48 03 01 8D BB 01 01 07   or
or something else?
 
Also, are the lengths low/high byte too
eg in example 6.1 should the sequence be  for
 
0 30  286: SEQUENCE {          
4 06    9:   OBJECT IDENTIFIER envelopedData (1 2 840 113549 1 7 3)
         :     (PKCS #7)
15 A0  271:   [0] {             --- I can't get this line either?  if there are 4 bytes what is 18?
19 30  267:     SEQUENCE {      --- and here if there 4 bytes what is 22 (are there 3 bytes per length?)
23 02    1:       INTEGER 0
 
30 1E 01 06 09 2B 03 48 01 BB 8D 01 07 03 0A 0F 01 00 30 0B 01 ?? 02 01 00
     ??   ??         ??                                                                          ??         ??  ?? 
00       04                               15       18 19       22 23
And should the lengths for integer data have 4 bytes ? and what about the octec strings?
 
Second, when I base64 decode your examples it is in what appears to be UNICODE.  It isn't though.  I can't see how you go from the sequence above to the data I get after base 64 decoding the example.  If there is a RFC or other document which explains these things could you tell me what it is?
 
 
Magnus Svensson | 20 Mar 09:26 2001

RE: I am clearly missing something. General Questions

Glenn,
 
The Cryptographic Message Syntax (RFC 2630) is a must when working with S/MIME ASN.1 structures since most of them are described there. This RFC and related documents can be retrieved from http://www.ietf.org/html.charters/smime-charter.html.
 
If you are unsure of how the ASN.1 coding works, check out "A Layman's Guide to a Subset of ASN.1, BER, and DER" at ftp://ftp.rsasecurity.com/pub/pkcs/ascii/layman.asc.
 
The example with RS
-----Original Message-----
From: owner-ietf-smime-examples <at> mail.imc.org [mailto:owner-ietf-smime-examples <at> mail.imc.org]On Behalf Of Glen Kleidon
Sent: Tuesday, March 20, 2001 4:47 AM
To: ietf-smime-examples <at> imc.org
Subject: I am clearly missing something. General Questions

I  am trying to come to grips with the SMIME.   I am getting there I think but I am just missing a couple of bits of info.  Perhaps there is a RFC I haven't read which answers all these questions.
 
In the examples (draft-ietf-smime-examples-06.txt) I could not understand how you get 9 bytes for the DES3/RSA oid but I have now been told that you encode the
first two digits as a+40 + b but is that 43 (2B)  or $40 + $02 + $01 = $43 and the large number > 7f in multiple bytes.  Are these large numbers encoded in Lowbyte/Highbyte format?
 
eg the new id-RSAES-OAEP   is iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 7  again 10 bytes
  would that be        
2B 03 48 01 BB 8D 01 01 07   or
43 03 48 01 BB 8D 01 01 07   or
2B 48 03 01 8D BB 01 01 07   or
43 48 03 01 8D BB 01 01 07   or
or something else?
 
Also, are the lengths low/high byte too
eg in example 6.1 should the sequence be  for

0 30  286: SEQUENCE {          
4 06    9:   OBJECT IDENTIFIER envelopedData (1 2 840 113549 1 7 3)
         :     (PKCS #7)
15 A0  271:   [0] {             --- I can't get this line either?
19 30  267:     SEQUENCE {
23 02    1:       INTEGER 0
 
30 1E 01 06 09 2B 03 48 01 BB 8D 01 07 03 0A 0F 01 00 30 0B 01 02 01 00
     ??   ??         ??                                                                          ??         ??  ?? 
 
And should the lengths for integer data have 4 bytes ? and what about the octec strings?
 
Second, when I base64 decode your examples it is in what appears to be UNICODE.  It isn't though.  I can't see how you go from the sequence above to the data I get after base 64 decoding the example.  If there is a RFC or other document which explains these things could you tell me what it is?
 
Mats Nilsson | 22 Mar 16:28 2001
Picon

OpenSSL S/MIME validation against draft-ietf-smime-examples?

Hi

[openssl-0.9.6, WinNT4sp6]

I tried to verify OpenSSL's S/MIME implementation using the sample messages in
http://www.ietf.org/internet-drafts/draft-ietf-smime-examples-06.txt

First I ran into problems with their base64 encoding, which was rejected by 
OpenSSL due to long lines. To make OpenSSL decode these files, I 
reformatted the contents to fit into the 80 character/line restriction.

Then I tried the tests 5.1 and 5.9 (Basic DH-DSS signed contents, CMS and 
S/MIME formatted).

No matter what I tried (different certificates, different options) I 
couldn't make OpenSSL verify the document signature. The certificate chain 
verification works, though. I tried something like the following (after 
having converted the supplied certificates to pem):

$ openssl smime -verify -certfiles AliceDss.pem -CAfile CarlDssSelf.pem -in 
5.9.eml
This is some sample content.Verification Failure
386:error:0A071003::lib(10) :DSA_do_verify:BN lib:.\crypto\dsa\dsa_ossl.c:288:
386:error:21071069:PKCS7 routines:PKCS7_signatureVerify:signature 
failure:.\cryp
to\pkcs7\pk7_doit.c:815:
386:error:21075069:PKCS7 routines:PKCS7_verify:signature 
failure:.\crypto\pkcs7\
pk7_smime.c:248:

A side comment, I tried the first basic validation test of the NIST X.509 
Path Validation suite (http://csrc.nist.gov/pki/testing/x509paths.html), 
which works. That one uses RSA.

Has anyone successfully verified the OpenSSL S/MIME implementation with 
these samples?
Are the samples incorrect? Am I using OpenSSL incorrectly?

Regards,
Mats Nilsson

Pawling, John | 22 Mar 22:17 2001

RE: OpenSSL S/MIME validation against draft-ietf-smime-examples?

Mats,

We used the S/MIME Freeware Library to successfully verify the 5.1 and 5.9
samples.  We have not tried to use OpenSSL's S/MIME implementation to verify
any of the samples.

===========================================
John Pawling, John.Pawling <at> GetronicsGov.com
Getronics Government Solutions, LLC
===========================================

-----Original Message-----
From: Mats Nilsson [mailto:mats.nilsson <at> xware.se]
Sent: Thursday, March 22, 2001 10:29 AM
To: openssl-dev <at> openssl.org; ietf-smime-examples <at> imc.org
Subject: OpenSSL S/MIME validation against draft-ietf-smime-examples?

Hi

[openssl-0.9.6, WinNT4sp6]

I tried to verify OpenSSL's S/MIME implementation using the sample messages
in
http://www.ietf.org/internet-drafts/draft-ietf-smime-examples-06.txt

First I ran into problems with their base64 encoding, which was rejected by 
OpenSSL due to long lines. To make OpenSSL decode these files, I 
reformatted the contents to fit into the 80 character/line restriction.

Then I tried the tests 5.1 and 5.9 (Basic DH-DSS signed contents, CMS and 
S/MIME formatted).

No matter what I tried (different certificates, different options) I 
couldn't make OpenSSL verify the document signature. The certificate chain 
verification works, though. I tried something like the following (after 
having converted the supplied certificates to pem):

$ openssl smime -verify -certfiles AliceDss.pem -CAfile CarlDssSelf.pem -in 
5.9.eml
This is some sample content.Verification Failure
386:error:0A071003::lib(10) :DSA_do_verify:BN
lib:.\crypto\dsa\dsa_ossl.c:288:
386:error:21071069:PKCS7 routines:PKCS7_signatureVerify:signature 
failure:.\cryp
to\pkcs7\pk7_doit.c:815:
386:error:21075069:PKCS7 routines:PKCS7_verify:signature 
failure:.\crypto\pkcs7\
pk7_smime.c:248:

A side comment, I tried the first basic validation test of the NIST X.509 
Path Validation suite (http://csrc.nist.gov/pki/testing/x509paths.html), 
which works. That one uses RSA.

Has anyone successfully verified the OpenSSL S/MIME implementation with 
these samples?
Are the samples incorrect? Am I using OpenSSL incorrectly?

Regards,
Mats Nilsson

Dr S N Henson | 23 Mar 14:57 2001

Problems with Example 5.1.

It has been reported to me that OpenSSL has problems verifying the
signature on example 5.1.

I have now analysed the example and found a few issues.

Firstly the description:

> A SignedData with no attribute certificates, signed by Alice using
> DH-DSS, just her certificate (not Carl's root cert), no CRL. The
> message is ExContent, and is included in the eContent. There are no
> signed or unsigned attributes.
> 

DH-DSS??

The final OCTET STRING which encapsulates the signature includes a
trailing zero.

Finally I cannot get OpenSSL to verify the signature on that example.
OpenSSL does however verify the signature on the certificate.

I didn't immediately report this because I could not be certain there
wasn't a bug in OpenSSLs DSA implementation that this example triggered.

I have since manually implemented the DSA verification algorithm for
this example using the Unix 'dc' calculator and input the relevant
values.

The result from dc agrees with OpenSSL: that is the value for 'v' is
identical (see FIPS186 section 6) not just the fact that it cannot
verify the signature.

While I cannot rule out the possibility that I've done something silly
the evidence suggests there is a problem with that signature.

Steve.
--

-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: shenson <at> drh-consultancy.demon.co.uk 
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: drh <at> celocom.com PGP key: via homepage.


Gmane