Re: S/MIME and encrypted certificates

Re: S/MIME and encrypted certificates

[Simon Josefsson]

Martin Christensen <knightsofspamalot-factotum@gvdnet.dk> writes:

> Howdy!
>
> The Info pages about message security describe that when dealing with
> S/MIME, certificates are expected to be stored in PEM format, which is
> also explained to be unencrypted. For all things OpenPGP, it happily
> prompts me for a passphrase for my keyring. The authority that has
> given me this certificate does not allow the certificate to be stored
> unencrypted on disk.

Do you mean the private key?

> Is it not possible to convince the SSL thingy (or whatever handles
> S/MIME) to do the same, or would I have to implement this myself
> (which doesn't look too difficult, at least using OpenSSL)?

Actually smime.el support this now, the documentation is not up to
date.  When you sign a S/MIME message, Gnus asks you for a passphrase.
This passphrase is passed on to OpenSSL via a environment variable and
used to decrypt the PEM file.  If the files aren't encrypted, just
type RET as the passphrase.

(Environment variables may not be the best idea though, improvements
are welcome.  However, if you decide to work on this, please consider
modifying the S/MIME support in Gnus to use something else than
OpenSSL, so the improvements eventually helps free software.)

Re: S/MIME and encrypted certificates

[Martin Christensen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>>>>> "Simon" == Simon Josefsson <jas@extundo.com> writes:
>> The Info pages about message security describe that when dealing
>> with S/MIME, certificates are expected to be stored in PEM format,
>> which is also explained to be unencrypted. For all things OpenPGP,
>> it happily prompts me for a passphrase for my keyring. The
>> authority that has given me this certificate does not allow the
>> certificate to be stored unencrypted on disk.
Simon> Do you mean the private key?

Yes.

>> Is it not possible to convince the SSL thingy (or whatever handles
>> S/MIME) to do the same, or would I have to implement this myself
>> (which doesn't look too difficult, at least using OpenSSL)?
Simon> Actually smime.el support this now, the documentation is not up
Simon> to date.

I'll say! :-) I must say, I had a rather difficult time grokking much
of the code, not because it itself is difficult to follow, but because
the documentation gave me an impression that the code would work in a
way that it doesn't. Oh well...

Simon> When you sign a S/MIME message, Gnus asks you for a
Simon> passphrase.  This passphrase is passed on to OpenSSL via a
Simon> environment variable and used to decrypt the PEM file.  If the
Simon> files aren't encrypted, just type RET as the passphrase.

Yes, so I noticed. This seems a very strange way of doing it. The
implementation to do so... well, I'm not much of an ELisp programmer,
but it seemed to me that it could be made more straight-forward.

Simon> (Environment variables may not be the best idea though,
Simon> improvements are welcome.

Passing the passphrase as a command-line argument seems the most
straight-forward way of doing so. Here, have a diff. :-) I've done
some rudimentary testing, and it seems to work fine.

249c249
< 	(passphrase (smime-ask-passphrase))
- ---
> 	(passphrase (concat "pass:" (smime-ask-passphrase)))
251,252d250
<     (if passphrase
< 	(setenv "GNUS_SMIME_PASSPHRASE" passphrase))
260,262c258
< 			      (list "-passin" "env:GNUS_SMIME_PASSPHRASE"))))
< 		(if passphrase
< 		    (setenv "GNUS_SMIME_PASSPHRASE" "" t))
- ---
> 			      (list "-passin" passphrase))))
379c375
< 	CAs (passphrase (smime-ask-passphrase))
- ---
> 	CAs (passphrase (concat "pass:" (smime-ask-passphrase)))
381,382d376
<     (if passphrase
< 	(setenv "GNUS_SMIME_PASSPHRASE" passphrase))
388,390c382
< 		       (list "-passin" "env:GNUS_SMIME_PASSPHRASE")))
< 	  (if passphrase
< 	      (setenv "GNUS_SMIME_PASSPHRASE" "" t))
- ---
> 		       (list "-passin" passphrase)))


Simon> However, if you decide to work on this, please consider
Simon> modifying the S/MIME support in Gnus to use something else than
Simon> OpenSSL, so the improvements eventually helps free software.)

I'm not sure I understand you. Doesn't OpenSSL qualify as free
software? From what I understand it's just standard OpenBSD stuff.
Moreover, I am next to ignorant regarding the alternatives. What else
can do S/MIME signatures, encryption and verification? Also, I don't
really know much about S/MIME in general. Speaking of which, is it
really necessary to include the public key (as I assume it is) with
each message?

Martin

- -- 
Homepage:       http://www.cs.auc.dk/~factotum/
GPG public key: http://www.cs.auc.dk/~factotum/gpgkey.txt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using Mailcrypt+GnuPG <http://www.gnupg.org>

iEYEARECAAYFAj704kcACgkQYu1fMmOQldV87wCgyuJ64PsSk6p5lRMoWAKyE6+l
eUoAoNVk2YhkFQgqafyYouZXMPi50xd4
=WmxD
-----END PGP SIGNATURE-----

Re: S/MIME and encrypted certificates

[Ben Elliston]

Martin Christensen <knightsofspamalot-factotum@gvdnet.dk> writes:

> Simon> (Environment variables may not be the best idea though,
> Simon> improvements are welcome.

> Passing the passphrase as a command-line argument seems the most
> straight-forward way of doing so. Here, have a diff. :-) I've done
> some rudimentary testing, and it seems to work fine.

Using a command line argument is even worse, as other users can spot
your openssl processes in the process table and will then know your
passphrase.

Ben

Re: S/MIME and encrypted certificates

[Simon Josefsson]

Martin Christensen <knightsofspamalot-factotum@gvdnet.dk> writes:

>>>>>> "Ben" == Ben Elliston <bje@air.net.au> writes:
> Ben> Using a command line argument is even worse, as other users can
> Ben> spot your openssl processes in the process table and will then
> Ben> know your passphrase.
>
> Doh! I was under the impression that this was how it was typically
> done with GnuPG, but apparently not. At least PGG reads the passphrase
> from standard input, while the matter to be (en|de)crypted, signed or
> verified is treated via a file, which I initially thought would be
> taken from stdin. Something similar seems to be possible for
> OpenSSL. That, however, can wait for tomorrow.

Reading the password from a file descriptor is probably the best
solution, yes, and OpenSSL support it via -passin fd:42.

Re: S/MIME and encrypted certificates

[Jesper Harder]

Simon Josefsson <jas@extundo.com> writes:

> Martin Christensen <knightsofspamalot-factotum@gvdnet.dk> writes:
>
>> Speaking of which, is it really necessary to include the public key
>> (as I assume it is) with each message?
>
> No, it isn't technically necessary, but otherwise the receiver will
> have to find the certificate somewhere else, and I'm not sure this
> works well everywhere.  So it is probably a good idea to do so, even
> though it makes the signature much larger.

It's probably a good idea to omit the public key if you want to use
S/MIME on Usenet, though.

Otherwise the signature part gets so big that some newsserver filters
classify the article as a misplaced binary, and throw it away.