Static in the Ether

I had an interesting question posed ot me today by Dominic who asked me to verify whether his all new Digital certificate was correctly being used for signing mail. Thunderbird sadly complained that the signature was invalid, which was unexpected, and that the issuer was unknown ( expected since it comes form a private hierarchy.)  The question then lead to where did the problem lie?

My gut feel was that it was the disclaimer being inserted by an intermediary gateway ( one has to love corpmail).  Setting about proving this was the hard part.  The first issue at hand wa to actually extract the certificates so I could play with the verification.  Cert Viewer Plus for Thunderbird made this part a dream. Creating a modified version of the signed message was a little bit more problematic.

Trusting the command line, I started hunting around for details on openssl support for SMIME, which it has.  OPenSSL needs a full CA path for being able to verify SMIME signed messages. One can optain this from various places ( such as exporting form your browser) but in a case like this where a private hierarchy was being used, its enough to just make used of a somewhat smaller subset contianing only the certificates used in this chain.  These can be extracted using Cert Viewer Plus. Alternately some command line magic can be used to extract the PKCS7 formatted embedded certificates out in standard PEM format., using the following command:

openssl smime -pk7out -in mail.txt | \
        openssl pkcs7 -print_certs > extract.crt

Now that we have a certificate chain we can attempt the verify. The extract.crt below can be either from the openssl method above or the Cert Viewer plus PEM dump.

openssl smime -CAfile extract.crt -verify -in mail.txt

Now e actually have a more usable error message. Although I really don’t know why I have such a deep distrust in GUI apps for actually telling me what is wrong.

Verification failure
88175:error:21071065:PKCS7 routines:PKCS7_signatureVerify:digest failure:/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/pkcs7/pk7_doit.c:808:
88175:error:21075069:PKCS7 routines:PKCS7_verify:signature failure:/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/pkcs7/pk7_smime.c:265:

As suspected the digest filed, which lead to a overall signature failure.  The next step was to see if removing the disclaimer worked.  Repeating on a slightly edited version of the the mail gave the following:

openssl smime -CAfile extract.crt -verify -in mail2.txt
...
mail contents deleted
...
Verification successful

So the original question posed was if the signature system was working correctly which it now was. The differences between the two mail files was checked using diff

diff -u mail.txt  mail2.txt
--- mail.txt         Mon Aug 25 18:06:33 2008
+++ mail2.txt      Mon Aug 25 18:08:10 2008
@@ -61,10 +61,6 @@
    South Africa

-Important Notice: This email is subject to important restrictions, qualifications
 and disclaimers ("the Disclaimer") ..that all was one very long line that made
 up the corporate disclaimer.....
-
-
-
 ------=_NextPart_000_0048_01C906C7.DB6FB700
 Content-Type: application/x-pkcs7-signature;
        name="smime.p7s"

From the above the only difference shown is that a mailgateway had added in a extra four lines of disclaimer and whitespace padding.  The question now evolves as to how to provide the now pretty much ubiquitious organisational disclaimer in outgoing mail in such a way that it doesnt trash any cryptographic operations in which the mail is involved.  Ive gone back over mails from a  couple of other people in corporate South Africa that I know , and the problem seems to be widespread.

The solution may be that the disclaimer as such is encapsulated as a separeate mime component, which is what interestingly one university here does ( although it insists on prepending its mime encapsulated HTML disclaimer, which makes for relaly ugly mail reading!)

Having finally completed my points transfer from my Thawte web of Trust to CaCERT, I thought it would be worth documenting the process.  I am already  Thawte WOT notary, and as such a trusted and assured person in the sense of their Web of Trust. details of this migration process can be found here, although my understanding is it applies to ordinary thawte users too.

The following a is a shorthand ticklist of the steps required.

1. sign up with cacert.org
2. On the thawte website make sure your notary details include the email address that you have used for the cacert.org signup.  This may involve just editing your details within the WOT console, and waiting for approval/verification, or having to do this and a ping to the mail address.  having the details verified can take 2-5 days, if the info is not already on your notary page.
3. Generate a certificate compatible for use with Internet Explorer.  This is the tricky part, as even Firefox 3 doesn’t support their client based authentication required by the tverify.cacert.org website  this should also be for the email address you are signed up to cacert.org with.
4. Go to the Thawte verification site (tverify.cacert.org), and choose the appropriate certificate to present to the server. make sure to use your IE browser witht he right client cert installed.
5. Fill in your email address, ( grants you 50 points since youare trusted within the Thawte WOT
6. Wait while a manual verification takes place.
7. Once email is received either notifying you of an error or noting you have succeded, either rinse and repeat, or proceed to the next step.
8. You are now ‘Assured’ but need to take the Assurer Challenge in order to prove your basic knowledge about the system, in oorder to be able to actually start Assuring people.  The link above also includes some background material one may need in order to attain the 80% mark required.

The Assurer Challenge is a relaly nice idea, and although anyone familiar with the concepts around the Thawte WOT system and general CA operations should have no problems witht he the majority of the 25 random questions, there are some which trelate closely to the CA specific rulings etc.

So now I have a full 150 assurance points since I was procesed by the Trusted Third Party (TTP ) system ( and it appears this is the maximum one can get as otherwise ones points are rounded down), as opposed to the 100 point maximum one gets for gathering points via the WOT method.

So now I’m able to embed my name in client certificates (50 points minimum), get server certificates for 2 years, and also get code signing bits on my certificates.