OpenPGP User ID Conventions

OpenPGP User ID Conventions ACLU

dkg@fifthhorseman.net

Security openpgp OpenPGP, userid OpenPGP User IDs are UTF-8 strings. Existing documents claim that by conventione, they contain "an RFC 2822 name-addr object", but that's not the case. This document attempts to better describe the actual conventions about User IDs in the deployed OpenPGP ecosystem. The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the OpenPGP Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction OpenPGP certificates contain User IDs. An OpenPGP User ID packet contains a simple UTF-8 string. According to and its successor :

By convention, it includes an 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.

Terminology The term "OpenPGP Certificate" is used in this document interchangeably with "OpenPGP Transferable Public Key", as defined in . The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

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 and 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 ), which uses the Unicode-augmented definitions of atext and dot-atom-text found in :

" 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.

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 )?

Example User IDs

Conventional User IDs Most tools will work fine with the following User IDs, even though most of them are not technically name-addr objects: Alice Jones <alice@example.org> Alice T. Jones <alice@example.org> Sean O'Brian <sean@example.org> Jörg Schmidt <js@example.org> Mr. Ed, the Talking Horse <ed@example.org> alice@example.org

Examples of Atypical User IDs The following examples are UTF-8 strings that are valid name-addr objects, but would most likely cause interoperability problems if they were used as an OpenPGP User ID:

RFC 2047 Encoding of non-ASCII Characters Do not use encoding: =?utf-8?Q?J=C3=B6rg?= Schmidt <js@example.org>

quoted-string Parts Do not use quoted-string parts: "Sean O'Brian" <sean@example.org>

FWS Do not use Folding Whitespace (FWS) (). Alice Jones <alice@example.org> It's probably not a good idea to include any control character or whitespace character at all, other than in an OpenPGP User ID. Do not include newline, carriage returns, tab characters, non-folding characters, byte order marks, etc. Also, leading or trailing whitespace is likely to cause interoperability failures in any context where the User ID must be cleanly parsed.

Comments Avoid Comments () with the possible exception of a single comment just before the angle-bracket that delimits the openpgp-addr-spec FIXME: should we discourage comments entirely? See, for example, the litany of complaints at https://dkg.fifthhorseman.net/blog/openpgp-user-id-comments-considered-harmful.html Alice (the Great) Jones <alice@example.org> or (The Great) Alice Jones <alice@example.org> or Alice Jones <alice@example.org> (The Great)

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.

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

&RFC4880; &I-D.ietf-openpgp-crypto-refresh; &RFC2119; &RFC8174; &RFC5234; &RFC6532; &RFC2822; &RFC5322; &RFC6531; &RFC5980; &RFC2047;

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

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" + pgp_addr_spec + ")" addr_spec_wrapped = pgp_uid_prefix_char + \ "*<(?P" + 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 ]]>

Document History RFC Editor Note: Please delete this section before publication.

Substantive Changes from Origin to draft-ietf-openpgp-userid-conventions-00 added positive and negative examples added Python implementation added FIXME about internationalized domain names

Origin This was originally discussed on the mailing list at https://mailarchive.ietf.org/arch/msg/openpgp/wNo27-0STfGR9JZSlC7s6OYOJkI and was formulated as a patch to the OpenPGP specification at https://mailarchive.ietf.org/arch/msg/openpgp/wNo27-0STfGR9JZSlC7s6OYOJkI .