Subject: Re: secure sign & encrypt

From: "Adrian 'Dagurashibanipal' von Bidder" <[email-masked]>
Date: 10 Jun 2002 14:09:44 +0200

Yo!

Jumpin' in late... [site-admin: please mark the mail archive at
../ietf-open-pgp/mail-archive as dead, or redirect to the real mail
archive. the charter on
http://www.ietf.org/html.charters/openpgp-charter.html still points to
the old location, so I assumed the list was dead. Just being nosy: the
agenda in the charter seems pretty much outdated, too. How does the
current agenda of the wg look like?]

As the one who apparently sparked this particular instance of this
discussion (remember
http://www.imc.org/ietf-openpgp/mail-archive/msg04314.html )

http://www.imc.org/ietf-openpgp/mail-archive/msg04373.html and the fact
that it's always difficult to prove that you have not done something or
that you do not possess some information convinces me that both ESE (or
SES) and my proposed 'intended encryption key' extension will never work
out. It all boils down to the fact that cryptography cannot replace
trust. So: No, I don't want to reopen this discussion.

Other comments to issues raised in this thread:

Something seemed odd throughout the discussion (the one I had on
gnupg-users, as well as the one you had here, which I only just found):
Tools (e.g. software) are made to automate and ease some tasks. The user
employs tools to get something he wants. It's not that tools are just
around until a user comes along and thinks 'oh, my, what may I do with
/that/?' So, if the user's expectations and the current behaviour of the
tool disagree, I'd want the tool fixed, not the user. To me, it seemed
that this got a bit lost in the discussion.

context info in mail, Mail headers: while message/rfc822 encapsulated in
multipart/signed would cover the issue of the headers not being
protected, it would be cumbersome to use with non-gpg users. Why not
copy these headers down into the MIME headers of the first MIME part of
the multipart/signed message? Of course, mailers will have to support
this and indicate clearly which information is signed and which is not
(kmail 1.4 does this nicely with colored boxes (at least for clearsigned
mail), evolution doesn't). encrypted messages can only be read with
gpg-enabled mailers anyway, so rfc822-encapsulation would probably be
easiest (encrypting recipient and sender may make sense, people could
just use usenet groups to make messages intraceable. Of course, normal
e-mail will still have valid To: and From: headers...). This was
probably discussed before - might somebody point me to the relevant
thread?

cheers
-- vbi

-- 
secure email with gpg            [email-masked]: key id 0x92082481
                                 [email-masked]:    key id 0x5E4B731F

---

From: [email-masked]
Date: Mon, 10 Jun 2002 13:09:16 -0500

From: John Dlugosz

Emails are the only thing where we might have missing context information.
In an informal note typed by a person, it might assume the conversation in
progress.  But what contract or other formal document doesn't list the
parties as part of the document content?  And what does "intended
recipient" mean for things that are not messages sent to somebody?

If an application wants to automatically add context information before
signing, without messing up the document proper, then a general purpose
"extra information" field is needed, since "TO:" is just a special case of
this general problem.  And I think it's been said that a suitable field
already exists.

Terje Braaten <[email-masked]>@mail.imc.org on 05-30-2002
12:38:22 AM

Sent by:    [email-masked]

To:    "OpenPGP (E-mail)" <[email-masked]>
cc:
Subject:    RE: secure sign & encrypt

Michael Young writes that "The intended recipient is only one of many
pieces of context that a user might mistakenly believe was included
in the signed material." That is correct, but I will still argue that
the information on which keys the message is encrypted to (or intended
to be encrypted to) is special, and belongs in the OpenPGP standard.

It is not only mail that can be signed and encrypted with OpenPGP,
it can be all kinds of electronic documents and messages. When f.ex.
an "X-To-PGP-Key" header might be an adequate solution for e-mail
messages, it will not fit at all for other sorts of messages.
In fact, the only meta data about a message that is common to all
encrypted messages is the recipient public keys. And since this
is meta data about the message that is always present, I think
it is very appropriate to be specified in the protocol a convention
on how this is to be protected in a message that is signed and encrypted.

(If we could just have an optional sub packet on the signature in the first
round I would be happy.)

--
Terje Bråten

---

From: Terje Braaten <[email-masked]>
Date: Mon, 10 Jun 2002 20:24:45 +0200

> recipient" mean for things that are not messages sent to somebody?

Everything that is "signed & encrypted" has a list of recipients that it
is encrypted to. This list of recipients is included in the protocol. That
is why I mean the protection of this information by signing it also belongs
in
the protocol.

> this general problem.  And I think it's been said that a 

I think you have completely missed my point here. Please read what
I wrote once again. I am making an argument for that this is NOT
a kind of general "extra information", it is information that already
are included as a part of the protocol. And a proper standard for how
to duplicate this information inside the signed part of the message
should also be a part of the standard, so that this can be done in the
same way by all applications that uses this standard. Is this to much
to ask?