Re: [ietf-822] [dmarc-ietf] Request for feedback: draft-ser-authentication-results-openpgp

[Simon Ser <[e-mail]>]

Thanks for your reply.

On Tuesday, October 20, 2020 3:24 AM, John Levine <[e-mail]> wrote:

> [ Replies sent to ietf-822 since this is unrelated to DMARC ]

(Sorry, I wasn't sure where to send this e-mail to.)

> In article ZxWD3Yo-oiRI8Rq8k9H-7vG3Rgogp5lhNRwW3JcDUpFjHlfxgubW8rC5g4jQKWnhFazItAexGXsB4xMb69mZg2jRtuXEC7l1GxfmqdBbCOU=@emersion.fr you write:
>
> > I've submitted a draft for a new Authentication-Results method a while
> > back 1. I'd like to get some feedback.
> > My use-case is: on a mailing list system 2, I'd like to display PGP
> > signature status, if a PGP signature is present. ...
>
> >
>
> > Does this sounds like something worth doing?
>
> Maybe, but probably not.
>
> DKIM is intended as a signature for messages in transit, applied as a
> message leaves its sending system and verified as it arrives at the
> recipient system. The sorts of changs made by list managers often
> break DKIM signatures, causing all sorts of excitement when DMARC
> is involved.
>
> PGP signatures (and S/MIME signatures) are normally applied and
> verified by the end-user mail programs. They're in the message body
> and the changes that list managers typically make, tagging the
> signature or adding body headers or footers, are unlikely to break a
> PGP signature.

I can think of ways a ML can change a PGP-signed message to make it
invalid. Adding a footer to all inline text parts for instance.

> Or to put it another way, if your A-R header said the PGP signature on
> the message contents was good, but the end user found it was bad, that
> would suggest something was screwed up, not normal mailing list
> processing.

I don't think I understand your point here.

I don't expect the A-R header of the mailing list server which relayed
the message to be preserved. In fact, many mail filters adding A-R will
just remove all existing A-R header fields.

In an email client, I may want to display the DKIM A-R result in the
UI. A bad DKIM signature might indicate an untrustworthy message.
Similarly, I may want to display the PGP signature verification result.

> PS: It's not unreasonble for a list manager to use a PGP signature to
> verify that it should forward a message, but there's not much use to
> adding a header saying it did so.

(My goal isn't to necessarily block messages with a bad PGP signature,
but rather display the PGP verification result in the mailing list
archives UI.)

Well, what's the use-case for A-R then? Couldn't the receiving server
check DKIM/DMARC without adding an A-R field and drop/quarantine
messages which fail this test?

My understanding was that A-R allows to have standardized email filters
that check DKIM/DMARC, put the result in a header field, and then
system administrators can consume this field and decide what to do. I
think this could apply to PGP as well.

I don't want to perform PGP key lookup and verification in the Web
server displaying the ML archives. I'd rather do this upon receiving
the message, in a completely isolated daemon (just like DKIM, e.g. with
OpenDKIM).

Thanks,

Simon