Re: secure sign & encrypt

["Michael Young" <[e-mail]>]

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

To: [e-mail]
Subject: Re: secure sign & encrypt
X-Comment: I, too, was hoping that this would die out before
  the urge to weigh in overwhelmed me, but it hasn't :-).

I generally side with Jon, Hal, and Derek here.  The intended
recipient is only one of many pieces of context that a user
might mistakenly believe was included in the signed material.
Adding a subpacket to address just this one piece of context
doesn't strike me as necessary, particularly since there are
very reasonable solutions within the existing framework:
notation subpackets; or, layered (encrypt-sign-encrypt) processing.

Ultimately the problem is one of user misunderstanding, arguably
exacerbated by the user interfaces in specific implementations.
Either the users need to be better educated, or the implementations
need to do a better job expressing exactly what has been signed
(and, perhaps, for naive users, the indirect implications).
Neither requires a change to the specification, just to the
implementation (of the tool or the user :-).

I appreciate Terje's desire to encode context so that it can be
checked automatically, and a desire for a convention for doing the
encoding, for implementations that want to do so.  I would have no
objection to publishing a convention for encoding the intended
recipients in a notation packet.  That wouldn't have to be part of the
base RFC.  That said, I wouldn't *strenuously* object to this being
documented in the base RFC, or even to a new OPTIONAL subpacket.  I
just don't think it helps enough: it doesn't cover other context;
and, it doesn't help for "legacy" messages.  Here "legacy" means
both old implementations (that don't support the packet) and
old V3 signatures (which don't have subpackets at all).

A few specific comments on one of Terje's notes:

> To word the problem in another way, when Alice send a message to Bob
> that is signed and encrypted, Bob should be able to be sure that it
> was Alice that encrypted the message.

I disagree that this is a fundamental goal -- it is a derived one.
The real goal is more likely that Bob wants to know that the message
is intended for him.  Knowing that Alice encrypted it is neither
necessary nor sufficient to meet this real goal.  I think this
difference is what Derek was getting at when he asked about goals.

> Some solutions:
> - Teach Bob not to trust PGPs sign & encrypt to know who the sender

Perhaps, as a means of teaching Bob:
  - Warn Bob about the limitations, something like:
    "The signature does not name you as the recipient.  This document
     may have been forwarded to you by the original recipient.
     Do not assume that it was intended for you."

    This may seem verbose, but naive users often have problems
    with shorthands for complex concepts: "(Invalid)" comes to mind :-).

    Again, this is the best that you can do for legacy messages, anyway.

> - Make PGP use Encrypt, Sign and Encrypt.

It's fine to have a particular implementation adopt this layering (or
to offer it as an option).  It would be very wrong to legislate this
particular layering.  While users may not understand the implications
of particular layerings, implementors clearly should understand, and
should be trusted to choose the layering appropriate for their
perceived users' needs.  You may want a tool that offers
encrypt-sign-encrypt (to identify the intended recipient); someone
else may want a tool that meets other goals (e.g., anonymity or
plausible deniability).  Any good tool should make it clear what
function it is performing, but that's not a *protocol specification*
issue.

> - Add fingerprints of recipient keys in signature packets (Requires
> a change
>   in the protocol)

Or,
  - Offer to copy context into the plaintext, or into notations.
    For example, an MUA might offer to copy the "To", "cc", and "Subject"
    headers.  It could even inject an "X-To-PGP-Key" header to record the
    key fingerprint/ID for automatic verification by like-minded agents.
    There's no deep reason that this requires a protocol change.

-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.3

iQA+AwUBPO7hEFMkvpTT8vCGEQL7FgCYtT6tpDktAg76EHnLwzyjBY6qzgCgudgy
q/a45lzca9Bqq+m6FmlLlVo=
=VplY
-----END PGP SIGNATURE-----