Re: Default encryption for Message

Re: Default encryption for Message

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 1297 bytes --]

>> "Jens" == Jens Lechtenboerger <jens.lechtenboerger@fsfe.org> writes:

   > Hi there,

   > My stance on encryption is simple: The Internet is a hostile place,
   > where all personal communication must be encrypted. Network
   > software should perform encryption by default and require a
   > conscious decision on the user’s part to send out plaintext. Based
   > on this conviction I have been maintaining DefaultEncrypt (and
   > ExtendSMIME) for some time [1]:
   > http://www.emacswiki.org/emacs/DefaultEncrypt

Hi,

I wrote a small hack for bbdb, so depending on your bbdb entry the
message is

    -  encrypted+signed (pgp, mime)

    -  encripted+signed (smime)

Where I use epg and gpgsm or (gpg)[1] (I use encrypt-to option in
gpgsm.conf. And I am not sure whether I understand your comment on
emacswiki). It seems that your approach is more general not relying on
bbdb, am I correct?

I have no real strong opinions on the questions you asked, only I hope
that none of your change will break backwards compatibility.

Uwe Brauer 

Footnotes:
[1]  I prefer smime over pgp, simply it is easier for the average user
     (my corresponds) to set up and the key interchange is also simpler
     since the public key is embedded in the signature.




[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5556 bytes --]

Re: Default encryption for Message

[Jens Lechtenboerger]

On 2014-09-22, Uwe Brauer wrote:

> I wrote a small hack for bbdb, so depending on your bbdb entry the
> message is
>
>     -  encrypted+signed (pgp, mime)
>
>     -  encripted+signed (smime)
>
> Where I use epg and gpgsm or (gpg)[1] (I use encrypt-to option in
> gpgsm.conf. And I am not sure whether I understand your comment on
> emacswiki).

Hi Uwe,

which comment are you referring to?

> It seems that your approach is more general not relying on
> bbdb, am I correct?

Exactly, my approach does not rely on bbdb but on the keyring(s)
maintained by GnuPG.

Best wishes
Jens

Default encryption for Message

[Jens Lechtenboerger]

Hi there,

my stance on encryption is simple: The Internet is a hostile place,
where all personal communication must be encrypted.  Network
software should perform encryption by default and require a
conscious decision on the user’s part to send out plaintext.
Based on this conviction I have been maintaining DefaultEncrypt (and
ExtendSMIME) for some time [1]:
http://www.emacswiki.org/emacs/DefaultEncrypt

Essentially, that package extends Gnus Message to add MML encryption
tags if public keys for all recipients are available.

I’d like to integrate that code into Gnus, but I see a couple of
challenges, which I’d like to discuss with you.  (This message is
long, be warned ;)

I prepared a new version of that package with the aim to simplify
discussion, where I replaced the key rebinding with add-hooks and
renamed functions to indicate where they might belong:
http://informationelle-selbstbestimmung-im-internet.de/emacs/jl-encrypt-4.1-discussion.el
http://informationelle-selbstbestimmung-im-internet.de/emacs/jl-encrypt-4.1-discussion.el.asc
(No new functionality is added.  This is not a regular release.)

1. Bcc handling.
Bcc handling in Gnus is broken.  Messages are encrypted to
all recipients, giving away the key IDs (thus, in general the
identities) of all recipients, including the “blind” ones.
The Right Thing is explained there:
http://lists.gnupg.org/pipermail/gnupg-users/2014-April/049394.html

In DefaultEncrypt I added a test to warn against such cases.  In the
version linked above, mml-secure-bcc-is-safe implements that test.
I suggest to copy that function (and its prerequisites) into
mml-sec.el.  Then, mml-secure-bcc-is-safe can be added as
message-send-hook, which I suggest as default until proper Bcc
handling is implemented.

2. mml-default-encrypt-method
The variable mml-default-encrypt-method combines two separate
concepts: First, whether to use OpenPGP or S/MIME.  Second, if
OpenPGP is chosen whether to use MIME Security or not.  For me, this
is not good enough.  Suppose I preferred S/MIME in general (which I
do not).  Then, I would need to customize mml-default-encrypt-method
for S/MIME.  If I then send an e-mail to someone who does not use
S/MIME but OpenPGP, my code kicks in, detects that OpenPGP should be
used, but does not know whether to use MIME Security or not.  Thus,
I’m using an additional variable that focuses on MIME Security for
OpenPGP: mml-secure-pgp-without-mime

If (a variant of) that variable was added to Gnus, mml-encrypt-alist
probably would need to change to include a generic pgp function,
which decides whether to use MIME or something else.  My own variable
mml-secure-pgp-without-mime is currently just a Boolean, so it would
not be good enough to distinguish pgp, pgpmime, and pgpauto.  When
and what is pgpauto good for, anyways?

3. Creation of signatures
If I’m not mistaken, Gnus only supports the creation of signatures
for reply messages (gnus-message-replysign and
gnus-message-replysignencrypted).  I added a variable
mml-secure-insert-signature with the following doc string:
Control whether MML signature tags should be produced.
If it is nil, no signatures are created.  If it is `always',
signature tags are inserted for new messages (with their type
determined by `mml-default-sign-method').  If is is `encrypted',
messages that are encrypted are also signed.

If this variable is set to nil, my code sets
gnus-message-replysignencrypted to nil, which is a hack.  Maybe my
variable should really be called gnus-message-sign and supersede
gnus-message-replysign and gnus-message-replysignencrypted.  Maybe
more values would be necessary then to cover all situations where
MML sign tags should be added automatically (always, only in replies
to signed messages, only in encrypted replies to signed messages,
only in encrypted replies to signed and encrypted messages, in every
encrypted message, never).
I’m not sure about user expectations and the necessity of backwards
compatibility, though.

4. mm-encrypt-option
I wrote code around mm-encrypt-option, via the variable
mml-secure-i-am-aware-of-mm-encrypt-option with the following
doc string:
In general, multiple public keys may exist for a single e-mail
address (e.g., for different security levels or before one key
expires).  In such a case, EasyPG and gpg automatically select a
key, while gpgsm reports an ambiguity.  This variable is intended as
safety check against the default setting of `mm-encrypt-option'.  If
that variable has its default value of nil, some key is selected
automatically, without any documentation as to what selection
process is applied.
If you are really sure about the appropriateness of that process,
set this variable to t.  If you are unsure about that process, do
not touch the default value of this variable, and you will be asked
to select keys manually if multiple ones are available.
If you configure `mm-encrypt-option' to `guided', this variable does
not have any effect.  (However, in that case you will *always* be
asked to choose keys, even if only one per recipient is available.
Quite likely, that is not what you want.)

Clearly, my variable is a hack.  A better approach might be a third
value for mm-encrypt-option, say guided-if-multiple, to only enter
guided mode if multiple keys are available.  That would require,
however, to modify code in mml1991.el, mml2015.el, and mml-smime.el,
which brings me to the next point.

5. Refactoring
mml1991.el, mml2015.el, and mml-smime.el share code, forcing
copy-and-paste on updates.

For example, in the past I used mml2015-epg-find-usable-key to find
usable keys.  With Gnus v5.13, mml2015-epg-find-usable-key and
mml1991-epg-find-usable-key were exact duplicates, while
mml-smime-epg-find-usable-key was similar but did not test for
disabled keys.  I went for mml2015-epg-find-usable-key in all cases.

With Ma Gnus v0.7, mml2015-epg-find-usable-key was rewritten with an
incompatible list of arguments to use the new function
mml2015-epg-check-sub-key, while mml1991-epg-find-usable-key
remained unchanged.  Why actually?

To be honest I don’t understand the comment in
mml2015-epg-find-usable-key about “Non e-mail user-id” with
mml-signers and mml2015-encrypt-to-self.  In fact, I don’t
understand mml2015-encrypt-to-self (which is not mentioned in the
manual) at all.  If I set that to true I cannot send encrypted
messages but receive the error: “Neither message sender nor
mml2015-signers are set”
For reasons I don’t understand the code seems to bind
encrypt-to-self to signing.  I like the freedom of encryption
independently of the controlling chains of signatures (also,
signatures require the presence of private keys, which is not the
case for encryption).  I’m simply using encrypt-to and
hidden-encrypt-to in gpg.conf.  Alternatively, messages could be
encrypted to the From address.  Alternatively, why is gpg’s
encrypt-to not good enough?
(Also, currently users probably need to configure three variables:
mml2015-encrypt-to-self, mml1991-encrypt-to-self,
mml-smime-encrypt-to-self)

In any case, I’d like to use a stable interface into epg and suggest
to provide that in a new file, say mml-epg.el.  Then, we could move
either mml2015-epg-find-usable-key or mml1991-epg-find-usable-key
with the new name mml-epg-find-usable-keys into that file and use
that in mml1991, mml2015, and mml-smime.  Actually, that function
should have an additional Boolean argument specifying whether to
return just one key or all of them.  Also, the functions named
mml-epg-... in jl-encrypt.el could go into that file.

I’d be happy to write that file once we discussed the change in
mml2015-epg-find-usable-key about “Non email user-id” mentioned
above.

What’s your opinion?

Best wishes
Jens

[1] Actually, much more could be done.
(a) Emacs or Gnus could check whether GnuPG is installed.  If not,
    recommend its installation.
The following is what https://www.mailpile.is/ seems to do.
(b) For every message Gnus could check whether a secret key exists
    for the From address.  If not, (recommend to) create one.  (With
    customizable exceptions.)
(c) For every plaintext message, attach the own public key, and
    point to a good guide, e.g.: https://emailselfdefense.fsf.org/
    (With customizable exceptions.)
(d) Automatically import public keys.
(e) Support search over encrypted messages.

Re: Default encryption for Message

[Ted Zlatanov]

On Sun, 21 Sep 2014 12:08:44 +0200 Jens Lechtenboerger <jens.lechtenboerger@fsfe.org> wrote: 

JL> 1. Bcc handling.

JL> Bcc handling in Gnus is broken.  Messages are encrypted to
JL> all recipients, giving away the key IDs (thus, in general the
JL> identities) of all recipients, including the “blind” ones.
JL> The Right Thing is explained there:
JL> http://lists.gnupg.org/pipermail/gnupg-users/2014-April/049394.html

JL> In DefaultEncrypt I added a test to warn against such cases.  In the
JL> version linked above, mml-secure-bcc-is-safe implements that test.
JL> I suggest to copy that function (and its prerequisites) into
JL> mml-sec.el.  Then, mml-secure-bcc-is-safe can be added as
JL> message-send-hook, which I suggest as default until proper Bcc
JL> handling is implemented.

I don't think warning is enough.  If it can be fixed, it should be fixed.

JL> 2. mml-default-encrypt-method

No opinion.

JL> 3. Creation of signatures
...
JL> I’m not sure about user expectations and the necessity of backwards
JL> compatibility, though.

No opinion, except IMO the Right Thing should override backwards
compatibility when it comes to security.

JL> 4. mm-encrypt-option
...
JL> Clearly, my [solution] is a hack.  A better approach might be a third
JL> value for mm-encrypt-option, say guided-if-multiple, to only enter
JL> guided mode if multiple keys are available.  That would require,
JL> however, to modify code in mml1991.el, mml2015.el, and mml-smime.el,
JL> which brings me to the next point.

Ask once, then save the preference in a Customize-controlled variable.

JL> 5. Refactoring

No opinion.

Ted

Re: Default encryption for Message

[Jens Lechtenboerger]

On 2014-09-23, Ted Zlatanov wrote:

> JL> 4. mm-encrypt-option
> ...
> JL> Clearly, my [solution] is a hack.  A better approach might be a third
> JL> value for mm-encrypt-option, say guided-if-multiple, to only enter
> JL> guided mode if multiple keys are available.  That would require,
> JL> however, to modify code in mml1991.el, mml2015.el, and mml-smime.el,
> JL> which brings me to the next point.
>
> Ask once, then save the preference in a Customize-controlled variable.

Before this was saved permanently the user should probably be asked,
as there might be addresses where the “correct” key depends on the
message’s context.

Also, an implementation of such a feature requires more code.
Currently, I’m setting “guided” on a per message basis to reuse the
code around epa-select-keys in the three files mentioned above.
There, epa-select-keys is invoked for *all* recipients of the
message, not just those with multiple keys.

For your proposal, the code in those three files would need to be
changed to iterate over the recipients and invoke epa-select-keys
for each recipient with multiple keys.  Another reason for
refactoring.

Best wishes
Jens

Re: Default encryption for Message

[Ted Zlatanov]

On Wed, 24 Sep 2014 15:59:24 +0200 Jens Lechtenboerger <jens.lechtenboerger@fsfe.org> wrote: 

JL> For your proposal, the code in those three files would need to be
JL> changed to iterate over the recipients and invoke epa-select-keys
JL> for each recipient with multiple keys.  Another reason for
JL> refactoring.

I don't know the internals there (and don't normally use those
facilities) and am happy to let you and others lead the effort.

If you're considering refactoring, please consider adding tests to
support the code.

Ted

Re: Default encryption for Message

[Daiki Ueno]

Jens Lechtenboerger <jens.lechtenboerger@fsfe.org> writes:

> 5. Refactoring
> mml1991.el, mml2015.el, and mml-smime.el share code, forcing
> copy-and-paste on updates.

Unifying those code would be a good idea.

> With Ma Gnus v0.7, mml2015-epg-find-usable-key was rewritten with an
> incompatible list of arguments to use the new function
> mml2015-epg-check-sub-key, while mml1991-epg-find-usable-key
> remained unchanged.  Why actually?

I guess it's a left-over.

> To be honest I don’t understand the comment in
> mml2015-epg-find-usable-key about “Non e-mail user-id” with
> mml-signers and mml2015-encrypt-to-self.  In fact, I don’t
> understand mml2015-encrypt-to-self (which is not mentioned in the
> manual) at all.  If I set that to true I cannot send encrypted
> messages but receive the error: “Neither message sender nor
> mml2015-signers are set”

mml2015-encrypt-to-self requires that either mml2015-sign-with-sender or
mml2015-signers is set.  If the former variable is set, it looks up a
key by a sender's e-mail address.  Otherwise, it looks for keys listed
in mml2015-signers, which could be:

(setq mml2015-signers '("D7E69871" ...))

Here, "D7E69871" is a "Non e-mail user-id"[1].  Perhaps we could enable
mml2015-sign-with-sender by default, if mml2015-encrypt-to-self is set.

> I’m simply using encrypt-to and hidden-encrypt-to in gpg.conf.

This was the idea why epg.el dropped the options like
pgg-encrypt-to-self.  However, in the end we realized that the Gnus
usage of GPG needed more flexibility.  Some people use multiple keys
associated with a single e-mail address.  For example, I have several
keys associated with ueno@gnu.org for different purposes than encrypting
or signing mails, e.g. signing tarballs.

> In any case, I’d like to use a stable interface into epg and suggest
> to provide that in a new file, say mml-epg.el.  Then, we could move
> either mml2015-epg-find-usable-key or mml1991-epg-find-usable-key
> with the new name mml-epg-find-usable-keys into that file and use
> that in mml1991, mml2015, and mml-smime.  Actually, that function
> should have an additional Boolean argument specifying whether to
> return just one key or all of them.  Also, the functions named
> mml-epg-... in jl-encrypt.el could go into that file.

Agreed.

Footnotes: 
[1]  The acceptable patterns are described in: https://www.gnupg.org/documentation/manuals/gnupg/Specify-a-User-ID.html#Specify-a-User-ID

Re: Default encryption for Message

[Jens Lechtenboerger]

On 2014-09-24, Daiki Ueno wrote:

> Jens Lechtenboerger <jens.lechtenboerger@fsfe.org> writes:
>
>> To be honest I don’t understand the comment in
>> mml2015-epg-find-usable-key about “Non e-mail user-id” with
>> mml-signers and mml2015-encrypt-to-self.
>
> mml2015-encrypt-to-self requires that either mml2015-sign-with-sender or
> mml2015-signers is set.  If the former variable is set, it looks up a
> key by a sender's e-mail address.  Otherwise, it looks for keys listed
> in mml2015-signers, which could be:
>
> (setq mml2015-signers '("D7E69871" ...))
>
> Here, "D7E69871" is a "Non e-mail user-id"[1].

Thanks for the clarification.  When and why would you set this
variable to a list?

> Perhaps we could enable mml2015-sign-with-sender by default, if
> mml2015-encrypt-to-self is set.

I fail to see why encrypt-to-self should be tied to sign-related
variables.

>> I’m simply using encrypt-to and hidden-encrypt-to in gpg.conf.
>
> This was the idea why epg.el dropped the options like
> pgg-encrypt-to-self.  However, in the end we realized that the Gnus
> usage of GPG needed more flexibility.  Some people use multiple keys
> associated with a single e-mail address.  For example, I have several
> keys associated with ueno@gnu.org for different purposes than encrypting
> or signing mails, e.g. signing tarballs.

I’m taken by surprise.  Do you sign tarballs in Gnus?

I understand that flexible schemes are necessary, but I still fail
to see why the current mml2015 approach is desirable.  If highly
customizable encrypt-to-self options are needed, I would recommend
Bcc.

Best wishes
Jens

Re: Default encryption for Message

[Daiki Ueno]

Jens Lechtenboerger <jens.lechtenboerger@fsfe.org> writes:

> I fail to see why encrypt-to-self should be tied to sign-related
> variables.

The variable name might not be too intuitive, but maybe you could
imagine how GPG signing and encryption work.  Decryption keys are
usually same as signing keys.  I didn't want to add a separate variable
for this particular feature.

> I’m taken by surprise.  Do you sign tarballs in Gnus?

No.  I'm saying that I don't want Gnus to pick the key I use for singing
tarballs, outside of Gnus.

> I understand that flexible schemes are necessary, but I still fail
> to see why the current mml2015 approach is desirable.  If highly
> customizable encrypt-to-self options are needed, I would recommend
> Bcc.

I'm not sure what you understand nor what you are proposing.  Here is
the detailed use-case:

Suppose that one has three keys associated with his e-mail address.  Key
A is for encrypted e-mail communication with his colleagues, key B is
for communicating with friends, and key C is for automatic signing of
tarballs.

Here, those keys are more securely protected in order of A, B, and C.
He doesn't want to use key C for any e-mail encryption.  He doesn't want
to use key B for confidential communication within his company.

This might sound hypothetical but I do have a similar setting.  How do
you address this situation with ~/.gnupg/gpg.conf options and Bcc?

Re: Default encryption for Message

[Jens Lechtenboerger]

On 2014-09-25, Daiki Ueno wrote:

> Jens Lechtenboerger <jens.lechtenboerger@fsfe.org> writes:
>
>> I fail to see why encrypt-to-self should be tied to sign-related
>> variables.
>
> The variable name might not be too intuitive, but maybe you could
> imagine how GPG signing and encryption work.  Decryption keys are
> usually same as signing keys.

I’m not sure about that, but this may be a side issue.  GnuPG
creates an encryption subkey by default.

> Suppose that one has three keys associated with his e-mail address.  Key
> A is for encrypted e-mail communication with his colleagues, key B is
> for communicating with friends, and key C is for automatic signing of
> tarballs.
>
> Here, those keys are more securely protected in order of A, B, and C.
> He doesn't want to use key C for any e-mail encryption.  He doesn't want
> to use key B for confidential communication within his company.
>
> This might sound hypothetical but I do have a similar setting.  How do
> you address this situation with ~/.gnupg/gpg.conf options and Bcc?

Apparently, we have been talking about different things.

I was interested in mml2015-encrypt-to-self and looked at its doc
string.  Setting to t fails.  You explained that
mml2015-sign-with-sender or mml2015-signers are necessary.
However, I don’t want to sign and suggested gpg.conf/Bcc instead.

In your scenario, I see two choices, say concerning Alice with those
three keys.

(1) Friend Bob wants to send a message to Alice and is supposed to
choose the correct key B (but neither A nor C).

(2) Alice wants to send an encrypted message to colleague Charlie,
and she wants to make sure that the message is encrypted to her key
A (but neither B nor C) in addition to Charlie’s key.

For (1), my code sets mm-encrypt-option to 'guided to enforce a
manual choice so that Bob learns about the existence of those three
public keys in the first place.  (Ted Zlatanov suggested to save
that choice.)

For (2), I think that another variable would be necessary to
customize what key to use for what recipient.  (Gnus could ask if it
detects multiple encryption keys.)

I don’t see how either case is supported by mml2015, though.  What
is your configuration?

Besides, what is the intended meaning for signatures if
mml2015-signers contains multiple keys?

Best wishes
Jens

Re: Default encryption for Message

[Daiki Ueno]

Jens Lechtenboerger <jens.lechtenboerger@fsfe.org> writes:

> I was interested in mml2015-encrypt-to-self and looked at its doc
> string.  Setting to t fails.  You explained that
> mml2015-sign-with-sender or mml2015-signers are necessary.
> However, I don’t want to sign and suggested gpg.conf/Bcc instead.

So, maybe improving the documentation of mml2015-encrypt-to-self would
be a good start?

> In your scenario, I see two choices, say concerning Alice with those
> three keys.
>
> (1) Friend Bob wants to send a message to Alice and is supposed to
> choose the correct key B (but neither A nor C).
>
> (2) Alice wants to send an encrypted message to colleague Charlie,
> and she wants to make sure that the message is encrypted to her key
> A (but neither B nor C) in addition to Charlie’s key.
>
> For (1), my code sets mm-encrypt-option to 'guided to enforce a
> manual choice so that Bob learns about the existence of those three
> public keys in the first place.  (Ted Zlatanov suggested to save
> that choice.)

I don't think this is a good idea.  I know some people ("security" fans)
like this kind of verbose behavior, but others don't even want to
remember key IDs and are prone to choose wrong keys.

There are criticisms about a related topic:
http://www.superlectures.com/guadec2013/more-secure-with-less-security

> For (2), I think that another variable would be necessary to
> customize what key to use for what recipient.  (Gnus could ask if it
> detects multiple encryption keys.)

No objection on that.

> I don’t see how either case is supported by mml2015, though.  What
> is your configuration?

It can be done by dynamically setting mml2015-signers upon sending.  For
some reason I use hooks (namely message-header-hook), but it can be done
more easily by using group parameters or BBDB.

(info "(gnus) Group Parameters")

> Besides, what is the intended meaning for signatures if
> mml2015-signers contains multiple keys?

This is certainly for the case when one wants to sign a message with
multiple keys.

Re: Default encryption for Message

[Jens Lechtenboerger]

On 2014-09-28, Daiki Ueno wrote:

> Jens Lechtenboerger <jens.lechtenboerger@fsfe.org> writes:
>
> So, maybe improving the documentation of mml2015-encrypt-to-self would
> be a good start?

Yes, there is room for improvement ;)
Maybe that variable should not be t or nil but instead a list of key
IDs (empty by default).

>> (1) Friend Bob wants to send a message to Alice and is supposed to
>> choose the correct key B (but neither A nor C).
>>
>> (2) Alice wants to send an encrypted message to colleague Charlie,
>> and she wants to make sure that the message is encrypted to her key
>> A (but neither B nor C) in addition to Charlie’s key.
>>
>> For (1), my code sets mm-encrypt-option to 'guided to enforce a
>> manual choice so that Bob learns about the existence of those three
>> public keys in the first place.  (Ted Zlatanov suggested to save
>> that choice.)
>
> I don't think this is a good idea.  I know some people ("security" fans)
> like this kind of verbose behavior, but others don't even want to
> remember key IDs and are prone to choose wrong keys.
>
> There are criticisms about a related topic:
> http://www.superlectures.com/guadec2013/more-secure-with-less-security

Thank you for the link.  The idea of using intentions is a good one.
I don’t see how to specify intentions without questions in this
case, though.  Maybe I just didn’t get the point of the video.

Bob’s intention is simple: Encrypt a message to Alice.  However, in
the scenario outlined by you, Alice’s intention is much more
complex: Have different parties use different keys in messages sent
to her.  How do those parties and their software learn about her
intention?  As you just pointed out, Bob quite likely does not know
about key IDs.  In contrast, his software does.

I think of a question like this (to be answered by Bob): “Multiple
encryption keys for <Alice@example.org> are available.  Which one(s)
would you like to use?  (Type ?/a/c/m; ? for help.)”

? displays explanation for the other keys:
- a: Abort.  I don’t know what that means, and I’ll ask the
  recipient offline.
- c: Continue.  I don’t know what that means.  Use the default key
  and insert a question for the recipient.
  (This would insert a customizable text like the following into the
  message: “P.S. My software told me that I could use several
  encryption keys, namely <list of key IDs inserted here>, but I
  don’t know how to choose.  Please explain your intention.”)
- m: Menu.  Display a menu (see mm-encrypt-option 'guided), where
  Bob chooses.  Once Bob has chosen, he is asked whether he’d like
  to choose anew for every message sent to Alice or to record this
  choice permanently.

>> Besides, what is the intended meaning for signatures if
>> mml2015-signers contains multiple keys?
>
> This is certainly for the case when one wants to sign a message with
> multiple keys.

My fault.  I wasn’t aware of that idea.  I don’t see why people
would do this, but it works.

Best wishes
Jens