Authentication-Results Registration for OpenPGP Signature Verification
draft-ser-authentication-results-openpgp-00

Abstract

RFC 7601 specifies the Authentication-Results header field for conveying results of message authentication checks. This document defines a new authentication method to be used in the Authentication- Results header field for PGP-related signature checks.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on September 12, 2019.

Copyright Notice

Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

Table of Contents

• 1. Introduction
• 2. "pgp" Authentication Method
• 2.1. OpenPGP Results
• 2.2. Email Authentication Parameters for OpenPGP
• 2.2.1. body.pgp-fingerprint
• 2.2.2. body.pgp-user-id
• 2.3. Examples
• 3. IANA Considerations
• 4. Security Considerations
• 5. Normative References
• Author's Address

1. Introduction

[RFC7601] specifies the Authentication-Results header field for conveying results of message authentication checks. OpenPGP signature verification is sometimes implemented in border message transfer agents (for instance some MTAs have their own OpenPGP PKI), there is a need to convey signature verification status to Mail User Agents (MUAs) and downstream filters. This document defines a new authentication method to be used in the Authentication-Results header field for OpenPGP-related signature checks.

2. "pgp" Authentication Method

OpenPGP signature verification is represented by the "pgp" method and is defined in [RFC4880].

2.1. OpenPGP Results

The result values used by OpenPGP [RFC4880] are as follows:

A signature is "acceptable to the verifier" if it passes local policy checks (or there are no specific local policy checks). For example, a verifier might require that the domain in the user ID in the signing OpenPGP key matches the domain in the address of the author of the message (value of the From header field), thus making third-party signatures unacceptable. [RFC5751] advises that if a message fails verification, it should be treated as an unsigned message. A report of "fail" here permits the receiver of the report to decide how to handle the failure. A report of "neutral" or "none" preempts that choice, ensuring that the message will be treated as if it had not been signed.

2.2. Email Authentication Parameters for OpenPGP

This document defines several new authentication parameters for conveying OpenPGP-related information, such as the identity associated with the entity that signed the message or one of its body parts.

2.2.1. body.pgp-fingerprint

body.pgp-fingerprint contains the fingerprint [RFC4880] of the key used to generate the OpenPGP signature referenced in the corresponding body.pgp-part.

2.2.2. body.pgp-user-id

body.pgp-user-id contains the signer's user ID [RFC4880] associated with the OpenPGP signature referenced in the corresponding body.pgp-part.

2.3. Examples

Return-Path: <elkins@aero.org>
Authentication-Results: example.net;
  pgp=pass (1024-bit key)
  body.pgp-fingerprint=89A8DCE5EAE72D530905C65241BA574B8FBB172B
  body.pgp-user-id="Michael Elkins <elkins@aero.org>"
Received: from ietfa.example.com (localhost [IPv6:::1])
  by ietfa.example.com (Postfix) with ESMTP id 2875111E81A0;
  Fri, 06 Sep 2002 00:35:14 -0700 (PDT)
From: Michael Elkins <elkins@aero.org>
To: Michael Elkins <elkins@aero.org>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary=bar; micalg=pgp-md5;
  protocol="application/pgp-signature"

--bar
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

=A1Hola!

Did you know that talking to yourself is a sign of senility?

It's generally a good idea to encode lines that begin with
From=20because some mail transport agents will insert a greater-
than (>) sign, thus invalidating the signature.

Also, in some cases it might be desirable to encode any   =20
trailing whitespace that occurs on lines in order to ensure  =20
that the message signature is not invalidated when passing =20
a gateway that modifies such whitespace (like BITNET). =20

me

--bar

Content-Type: application/pgp-signature

-----BEGIN PGP MESSAGE-----
Version: 2.6.2

iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC//
jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq
uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn
HOxEa44b+EI=
=ndaj
-----END PGP MESSAGE-----

--bar--

3. IANA Considerations

IANA has added the following entries to the "Email Authentication Methods" sub-registry of the "Email Authentication Parameters" registry:

TBD

IANA has added the following entries to the "Email Authentication Result Names" sub-registry of the "Email Authentication Parameters" registry:

TBD

4. Security Considerations

TODO

5. Normative References

Author's Address