OpenPGP User ID Conventions

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 26 February 2024.¶

Copyright Notice

Copyright (c) 2023 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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

OpenPGP certificates contain User IDs. An OpenPGP User ID packet contains a simple UTF-8 string. According to [RFC4880] and its successor [I-D.ietf-openpgp-crypto-refresh]:¶

• By convention, it includes an [RFC2822] mail name-addr¶

But in practice, this is not what most OpenPGP implementations generate or expect. This document tries to better describe the actual convention used.¶

2. OpenPGP User ID Conventions

An OpenPGP User ID has no formal constraints other than being a UTF-8 string, but common conventions govern its use in specific contexts.¶

In the context of sending and receiving signed and encrypted e-mail messages, a User ID typically contains an e-mail address. While [RFC5322] and [RFC6531] describe an addr-spec as it is used e-mail message headers (us-ascii in the former, and Unicode in the latter), the common OpenPGP User ID convention is somewhat simpler, while still permitting extraction of a valid addr-spec. An e-mail-oriented OpenPGP implementation that follows this simpler convention is more likely to be interoperable with Transferable Public Keys found in the wild.¶

In particular, the common convention for an OpenPGP User ID related to e-mail can be described with the following ABNF (see [RFC5234]), which uses the Unicode-augmented definitions of atext and dot-atom-text found in [RFC6532]:¶

openpgp-addr-spec            = dot-atom-text "@" dot-atom-text

openpgp-email-prefix-char    = atext / specials / SPACE

openpgp-email-wrapped-addr   = *openpgp-uid-prefix-char
                               "<" openpgp-addr-spec ">"

openpgp-email-uid-convention = openpgp-addr-spec /
                               openpgp-email-wrapped-addr

Note that any openpgp-addr-spec described in the above sequence is also a valid Unicode addr-spec. The only addr-specs not matched are obsolete forms, or those with CWFS or quoted-string in the local part, or those with domain literals for the domain part. Using such a non-matching addr-spec in an OpenPGP User ID is likely to lead to interoperability problems.¶

3. Internationalized Domain Names

FIXME: if a domain name in the openpgp-addr-spec contains non-ASCII characters, will existing implementations accept A-labels? Or should we encourage standardization on U-labels (see [RFC5980])?¶

4. Example User IDs

5. IANA Considerations

This draft asks IANA to make one change to the OpenPGP protocol group.¶

In the "Packet Types/Tags registry", update row 13 ("User ID Packet") by adding this document to the "Reference" field.¶

6. Security Considerations

This document describes widespread conventions about User IDs in the OpenPGP ecosystem.¶

Generating an OpenPGP certificate with a User ID that does not match these conventions may result in security failures when a peer tries to find a certificate but cannot¶

Appendix A. Python Example

The following Python example can be used to parse a conventional OpenPGP User ID:¶

#!/usr/bin/python3

from typing import Optional, Tuple
import re

def openpgp_userid(test: str) -> Optional[Tuple[str, str]]:
    '''Returns a None if `test` is not a conventional User ID.

    if `test` is a conventional User ID, returns a Tuple containing
    the User ID and the embedded e-mail address.'''

    specials = r'[()<>\[\]:;@\\,."]'
    atext = "[-A-Za-z0-9!#$%&'*+/=?^_`{|}~\x80-\U0010ffff]"
    dot_atom_text = atext + r"+(?:\." + atext + "+)*"
    pgp_addr_spec = dot_atom_text + "@" + dot_atom_text
    pgp_uid_prefix_char = "(?:" + atext + "|" + specials + "| )"
    addr_spec_raw = "(?P<addr_spec_raw>" + pgp_addr_spec + ")"
    addr_spec_wrapped = pgp_uid_prefix_char + \
        "*<(?P<addr_spec_wrapped>" + pgp_addr_spec + ")>"
    pgp_uid_convention = "^(?:" + addr_spec_raw + "|" + \
        addr_spec_wrapped + ")$"

    pgp_uid_convention_re = re.compile(pgp_uid_convention,
                                       re.UNICODE)

    m = pgp_uid_convention_re.search(test)
    if m:
        return (m[0], m['addr_spec_wrapped'] or m['addr_spec_raw'])
    else:
        return None

Appendix B. Document History

RFC Editor Note: Please delete this section before publication.¶

Author's Address