[openpgp] Re: [openpgp-email] Re: Re: Fwd: New Ver sion Notification for draft-gallagher-email-invisible-signatures- 00.txt

Daniel Kahn Gillmor <[email protected]>
Newsgroups gmane.ietf.openpgp
Message-ID <[email protected]>
Hi Andre--

Thanks for the followup!  My reply here is as a proponent of the draft,
not in any WG chair capacity.  I'd like to understand your concerns
better.

On Tue 2025-05-06 18:03:25 +0200, esus wrote:
> You can give the Attachment a reasonable Filename Like openpgp digital
> signature.asc and then have that handled by a third Party Program
> which links the File Extension .asc

I'm not sure i understand this proposal.  If by "third party program"
you mean some kind of plugin to the MUA, that is a challenging thing for
most users to set up, and most MUAs don't offer sufficient hooks for any
kind of plugin to make the sort of in-depth UX integration needed to
make end-to-end cryptographic protections meaningful.  See for example
the in-depth discussion about e2e MUA best practices over at
https://datatracker.ietf.org/doc/draft-ietf-lamps-e2e-mail-guidance/

For the Invisible Signatures draft, did you read the specific problem
statement at:
https://www.ietf.org/archive/id/draft-gallagher-email-invisible-signatures-00.html#name-problems-with-existing-sign
?  there are at least three significant disincentives to sign mail at
the moment, and i don't see how any of them would be significantly
mitigated by naming the attachment "openpgp digital signature.asc".
Even the "Unknown Attachment" concern
(https://www.ietf.org/archive/id/draft-gallagher-email-invisible-signatures-00.html#name-unknown-attachment)
which is the most relevant, isn't really mitigated much by this
proposal, since most recipients don't even know what "openpgp" or
"digital" or "signature" means independently, let alone strung together
in a filename.

The point is, as a sender, you don't know whether your recipient can
make sense of it.  So you hide the signature in a way that it won't
annoy an uncomprehending recipient.

> This proposal Breaks PGP Mail even further.

Even further than it's already broken?  Because it sounds like we can
both agree that it's broken right now, given the remarkably low uptake.

This proposal is an attempt to make it easier to increase the uptake by
removing disincentives to signing cleartext mail.

What additional breakage does it introduce?

> MIME is dead. Its recursive and a dos by Design. Modern Mail is a HTML
> Body of a Message with File Attachments. Thats it. 

I'm not even sure what this means.  If you mean that complex MIME
structures are problematic, then i absolutely agree with you.  In fact,
all of my own recent work at improving the e2e e-mail ecosystem has
aimed specifically at simplifying and standardizing a minimal subset of
expected MIME structures that are known to not have interoperability
problems with legacy MUAs.

If you mean that wrapping an entire message in a multipart/mixed object
(which is the only MIME manipulation that
draft-gallagher-email-invisible-signatures asks for) is going to cause
rendering errors on some common MUA, then i'd very much like to know
about it.  Can you provide a pointer?  I'd be happy to test the sample
messages in the draft against any MUA i can get my hands on.

> No Magic Headers.

I'm not sure what this means -- without "magic headers" we wouldn't be
able do things like name any attachment "openpgp digital signature.asc",
right?  Are you objecting to the introduction of a new header which we
expect legacy MUAs to ignore?  What is problematic about a novel header
field?

Regards,

       --dkg

_______________________________________________
openpgp mailing list -- [email protected]
To unsubscribe send an email to [email protected]
signature.asc (application/pgp-signature, 227 B)
-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQRjrBGOWy5dZsiKhad4C4VO2cK0lgUCaBp6PQAKCRB4C4VO2cK0
lvAlAP9E/WKjY9mwrX9H1w1W1wqSQ+k9yg9qpvz0VHmjBvq5OwEA9adNPp5MaaWm
m45d1WncyFc4LYQDW7fv19cHYto3Gw8=
=oqki
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.