[Gpg4win-devel] Structure of an S/MIME email (Re: Broken claws mail from gpg4win package on the site)

[Dr. Peter Voigt]

Am Fri, 10 Jan 2014 09:26:16 +0100
schrieb Bernhard Reiter <bernhard at intevation.de>:

> Hi Peter,
Hi Bernhard,

> 
> On Thursday 09 January 2014 at 23:55:19, Dr. Peter Voigt wrote:
> > > Overall it is a good idea in this situation, to try to send an
> > > attachment which has the same cryptographic properties, e.g.
> > > encrypted to X,Y, signed by Z and then try gpgsm on the saved
> > > attachment.
> > >
> > > You can make it possible to decode the MIME part for a signed
> > > messages, but it is not that easy.
> >
> > Thanks, Bernhard for clarifying this. I just couldn't believe that
> > decrypting or verifying an S/MIME mail should be that simple. I
> > quick view into the "source code" of an S/MIME mail did not even
> > reveal to me, which encoding out of Quoted-printable, Base64 or
> > Radix64 is used for which part of the mail.
> 
> It is a regular MIME email, so MIME encoding rules apply.
> You do see an Content-Transfer-Encoding: header for each MIME part.
> 
> Of course inside of the S/MIME part it is going to be CMS.
> 
> > Nevertheless, if you should have some minutes left, I would like to
> > get a rough insight into this.
> 
> There are three versions basically:
> a) encrypted email. That is an attachment which properly MIME decoded
> give you a binary CMS file that gpgsm can directly decoded.
> b) multipart/signed : you get two mime parts, e.g.
>   
> --===============1838778857==
> Content-Type: multipart/signed;
>   boundary="nextPart12991707.QleQFXgr9i";
>   protocol="application/pkcs7-signature";
>   micalg=sha1
> Content-Transfer-Encoding: 7bit
> 
> --nextPart12991707.QleQFXgr9i
> Content-Type: text/plain;
>   charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
> Content-Disposition: inline
> 
> On Wednesday 08 January 2014 at 23:13:05, Cristian Baboi wrote:
> > >It would prob
> [..]
> --nextPart12991707.QleQFXgr9i
> Content-Type: application/pkcs7-signature; name="smime.p7s"
> Content-Disposition: attachment; filename="smime.p7s"
> Content-Transfer-Encoding: base64
> 
> MIAGCSqGSIb3DQEHAqCAMIACAQE
> [..]
> 
> The smime.p7s attachment is a detached signature for the text/plain
> part. If you save the text/plain properly, you could be able to
> verify it with gpgsm on the command line. The Problem is: You need to
> have the right line endings, spaces and the end of lines and number
> of lines. There are some rules somewhere probably within the PGP/MIME
> or S/MIME rfcs.
> 
> c) none-mime (aka opaque) signature. Again you have a CMS attachment
> and you can directly decode it using gpgsm -d. (It is not encrypted.)
> 
> Of course it is possible to have a signature within the encrypted part
> again embedded or as a nother mime structure.

Thank you very much for your quick and brief summary being just as
detailed as I have wished. When I will have some time left, I am going
to read about MIME handling and write a small Python script to base64
decode the MIME parts. Then I will do my gpgsm tests. Will your
reflections basically be the same for PGP/MIME mails?

> 
> > PS.: I cannot verify the signature of your last email for unknown
> > reason. Did you recently change your X.509 certificate? 
> 
> No my x509 cert is the same since mid 2012.
> 
> > I checked it 
> > with Claws Mail, Thunderbird and GNU Emacs/Gnus. GNU Emacs/Gnus even
> > hangs forever and had to be interrupted leaving me with a plain
> > base64 message which is very hard to read :-).

Sorry for a possible false alert. I have just seen that I had CRL checks
enabled from some testing long ago. As you are the only X.509
communication partner, I have forgotten about this option. And as you
are using your X.509 certificate less than your openPGP key, I have
found this verification problem late. I have disabled CRL checks again
and now I can verify your X.509 certificate with all my email clients
as expected.

When checking my X.509 certificates I am wondering were I might have
downloaded your certificate. I am only aware of having downloaded
Intevation Root and Intermediate CA from https://ssl.intevation.de/.
But I cannot find a place where to download your X.509 certificate. Can
you help me with this, because X.509 certificates cannot be distributed
via keyservers.
 
> Bernhard
> 
>

Regards,
Peter