Re: [openpgp] Encryption and signature context parameter

[Michael Richardson <[e-mail]>]

Daniel Kahn Gillmor <[e-mail]> wrote:
> Hi Marcus, Daniel, and the rest of the WG--

what a whirlwind email. Thank you.

    > Also, if we're going to use a distinct signalling mechanism, then it
    > smells like the moral equivalent to a v3 SEIPD, but focused on the
    > particular domain in question, which means it *doesn't* need to be
    > defined now.

    > For example, a future specification could (a) introduce v3 SEIPD, which
    > is identical to v2 SEIPD plus the context parameter, but indicating that
    > it MUST NOT be used in any domain without well-defined, signalled
    > support, (b) define exactly how it is used in the domain of e-mail
    > messages (maybe even declaring a fixed policy), and (c) claim one of the
    > bits in the feature packet to mean "I can do v3 SEIPD in the domain of
    > e-mail messages, using this exact policy".

I can't say that I really understood more than half of the technical details
of your email.   I did understand the part about leaking metadata to the
transports, and how hiding stuff matters to filters, and the Usenix/ORCA
paper is half-read and on my way-to-deep reading Q.

The above solution sure seems like a good idea.
I admit that I am less interested these days in email encryption.

I am mostly interested in email signatures, and despite existence of DKIM
(and claims from some IETF email gurus), I do not find that it's an
ubiquitous enough that I can, for instance, delete all email not DKIM signed
as spam.  (and I can't get my backup relay to do DKIM signatures, and it
turns out I never properly deployed it for my domain until a few weeks ago)

But, my point about signatures is that I really would prefer that every email
was PGP (or SMIME) signed, and that my MUA would therefore learn who signs
their email via TOFU, and enforce that.  Also, this means that I'm much more
likely to received their secure email information before I need to use it.
That's my model.

    > That still doesn't solve the problem of getting Bob's MUAs to all agree
    > that it's OK to set that bit in his cert, but it is at least a clear
    > deployment strategy that won't block us from getting real-world
    > practical experience with v2 SEIPD.

Yeah, I also use multiple MUAs, and my primary one is old enough to have
grandchildren in college.  But, I also use fancy new-fangled stuff on my
smartphone.

    > And it doesn't need us to change anything in the crypto-refresh draft,
    > to get the proximate revision to RFC 4880 out the door.

    > --dkg

    > PS i would be seriously happy to include work on something like the "v3
    > SEIPD + e-mail message policy for decryption context + signalling"
    > spec i sketched above as an item in a potential WG recharter if folks
    > are interested.

Sounds good.


--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide