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

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

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

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

I am clearly missing something. General Questions

Just not getting it. General Questions from brand new Crytographer

RE: I am clearly missing something. General Questions

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

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

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.