Network Working Group J. J. Brucker Internet-Draft Mnêmê Intended status: Informational foopgp Expires: 5 April 2027 2 October 2026 vCard Properties in OpenPGP User IDs, and OpenPGP Certificates as vCards draft-foopgp-openpgp-vcard-00 Abstract This document describes how an OpenPGP certificate can carry the properties of a contact card: each property is a User ID whose text is a single vCard content line, such as FN:Alice Martin or TEL:+33612345678, self-signed and revocable on its own. It then describes how such a certificate, or any other, is rendered as a vCard 4.0, so that an address book can hold a certificate as an ordinary contact. E-mail addresses are the exception: they stay in ordinary Name
User IDs, which mail clients read. 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 5 April 2027. Copyright Notice Copyright (c) 2026 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. Brucker & Mnêmê Expires 5 April 2027 [Page 1] Internet-Draft OpenPGP and vCard October 2026 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 3. Property User IDs . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.2. Properties . . . . . . . . . . . . . . . . . . . . . . . 3 3.3. E-mail Addresses . . . . . . . . . . . . . . . . . . . . 4 3.4. Changing a Property . . . . . . . . . . . . . . . . . . . 5 3.5. Upgrading a Legacy Certificate . . . . . . . . . . . . . 5 4. Rendering a Certificate as a vCard . . . . . . . . . . . . . 5 4.1. Which User IDs . . . . . . . . . . . . . . . . . . . . . 6 4.2. FN . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.3. Carried Properties . . . . . . . . . . . . . . . . . . . 6 4.4. EMAIL . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.5. UID, KIND and GEO . . . . . . . . . . . . . . . . . . . . 7 4.6. KEY . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.7. PHOTO . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.8. Line Folding . . . . . . . . . . . . . . . . . . . . . . 8 4.9. jCard . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 10.2. Informative References . . . . . . . . . . . . . . . . . 11 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction A vCard [RFC6350] is a list of PROPERTY:value lines: a name, a telephone number, an address. Every address book reads it, and nothing in it says who wrote it. An OpenPGP certificate [RFC9580] is a public key and a list of User IDs, each signed by the key, each revocable on its own, and each open to certification by third parties. RFC 9580 puts no restriction on the content of a User ID (Section 5.11 of [RFC9580]). If each User ID is a vCard line, the certificate becomes a signed contact card: only its holder can add or withdraw a line, and the web of trust can vouch for each line separately. The certificate can then be rendered as an ordinary vCard, with the key itself inside, for address books that know nothing of OpenPGP. Brucker & Mnêmê Expires 5 April 2027 [Page 2] Internet-Draft OpenPGP and vCard October 2026 This document describes both directions as they are implemented by the tools listed in Section 6. 2. Conventions and Definitions 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. A "property User ID" is a User ID whose text is a vCard property line as specified in Section 3. A "name-addr User ID" is a User ID of the conventional form Name
, possibly with a comment, as described in [I-D.dkg-openpgp-userid-conventions]. A User ID "stands" when it carries a valid self-signature and no newer valid certification revocation issued by the certificate's own key. 3. Property User IDs 3.1. Syntax A property User ID is one vCard content line (Section 3.3 of [RFC6350]), without the line ending and without folding: property-uid = name *(";" param) ":" value name, param and value are as in RFC 6350. A writer MUST write the property name in upper case, and MUST escape the value as specified in Section 3.4 of [RFC6350]: a backslash, a comma and (except where a property uses it for structure, as ADR does) a semicolon are preceded by a backslash, and a newline is written \n. A writer MUST NOT include a carriage return or a line feed in the User ID. A reader SHOULD accept, and ignore, a single space after the colon, which early implementations wrote; a writer MUST NOT write it. A property User ID is never also a name-addr User ID: a reader MUST NOT look for an address between angle brackets in it. 3.2. Properties The following properties are written by current implementations: Brucker & Mnêmê Expires 5 April 2027 [Page 3] Internet-Draft OpenPGP and vCard October 2026 +==========+=============+======================================+ | Property | Cardinality | Value | +==========+=============+======================================+ | UID | at most one | the entity's URN, e.g. urn:eid:u4... | | | | ([I-D.foopgp-urn-eid]) | +----------+-------------+--------------------------------------+ | FN | exactly one | free text, escaped | +----------+-------------+--------------------------------------+ | NOTE | at most one | free text, escaped | +----------+-------------+--------------------------------------+ | TEL | any | an international number, optionally | | | | as a tel: URI | +----------+-------------+--------------------------------------+ | ADR | any | the seven structured components, | | | | ;-separated | +----------+-------------+--------------------------------------+ | URL | any | an absolute URI | +----------+-------------+--------------------------------------+ | LANG | any | a language tag | +----------+-------------+--------------------------------------+ | GEO | any | a geo: URI | +----------+-------------+--------------------------------------+ Table 1: Properties carried as User IDs Other vCard properties, such as TITLE, ROLE, ORG, NICKNAME or BDAY, MAY be carried in the same way. A writer SHOULD check that a value has the shape its property calls for before minting a User ID, since a User ID, once published, cannot be taken back (see Section 3.4). For example, current implementations accept for TEL ^(tel:)?\+[0-9][0-9 ./()-]{3,22}[0-9]$, for URL a scheme followed by :// and no whitespace, and for LANG ^[a-zA-Z]{2,8}(-[a-zA- Z0-9]{1,8})*$. The UID property User ID is the identity anchor of the certificate: its whole content is UID: followed by the URN, and nothing else ([I-D.foopgp-urn-eid], Section 4.5). It is minted once, when the certificate is created, and SHOULD never be replaced. 3.3. E-mail Addresses An e-mail address MUST NOT be carried as an EMAIL: property User ID. It is carried in a name-addr User ID, Name
, as it always has been. Mail clients parse a User ID as a name-addr (Section 3.4 of [RFC5322]), and do not know property User IDs. In tests, an EMAIL:address User ID made one mail client unable to send to the Brucker & Mnêmê Expires 5 April 2027 [Page 4] Internet-Draft OpenPGP and vCard October 2026 address, and another put EMAIL: into the recipient field. A name- addr User ID, on the other hand, is rendered as the EMAIL property of a vCard (Section 4.4). 3.4. Changing a Property A property is changed by adding a User ID and revoking another, both signed by the certificate's key. For a property of cardinality "exactly one" or "at most one", a writer SHOULD add the new User ID before revoking the one it replaces, so that an interruption leaves the certificate with two values rather than none. A writer MUST NOT leave a certificate without a standing FN User ID. A revoked User ID SHOULD be treated as permanently withdrawn: certification revocations propagate through keyservers, and a later self-signature over the same text is not reliably honoured by implementations. A value that has been withdrawn is therefore re- added, if needed, with a different text. The keyserver a certificate prefers is not a property User ID: it is the Preferred Key Server subpacket (Section 5.2.3.26 of [RFC9580]) of its self-signatures, and is changed by issuing new self-signatures. 3.5. Upgrading a Legacy Certificate A certificate may carry its entity identifier in the comment of a name-addr User ID, in a deprecated form such as Alice Martin (u4=...) ([I-D.foopgp-urn-eid], Section 4.5). Before any other change to such a certificate, an implementation acting for its holder SHOULD: 1. Add the User ID UID:urn:eid:, if no standing User ID begins with UID:urn:eid: and the legacy User IDs name exactly one eid. If they name none, or several different ones, nothing is done. 2. Add an FN User ID carrying the name part of the first legacy User ID (its comment and address removed, then escaped), if no standing FN User ID exists and that name part is not empty. The legacy User IDs MUST NOT be revoked by this upgrade: the certifications that third parties made over them are what the web of trust rests on. The primary User ID flag MUST NOT be moved by it. 4. Rendering a Certificate as a vCard This section describes how a certificate is written as a vCard 4.0 [RFC6350]. It applies to any certificate, with or without property User IDs. Brucker & Mnêmê Expires 5 April 2027 [Page 5] Internet-Draft OpenPGP and vCard October 2026 4.1. Which User IDs Only standing User IDs are rendered. Revoked, expired and invalid User IDs MUST be ignored. 4.2. FN FN is required in a vCard (Section 6.2.1 of [RFC6350]). The value of the standing FN User ID, if there is one, is used as it stands. Otherwise, the name part of the first standing name-addr User ID is used: the text before the angle brackets, with a trailing parenthesised comment and surrounding whitespace removed, escaped as a vCard value. A comment is removed because in legacy certificates it carries an identifier, not a name. If no name can be found, an implementation SHOULD NOT produce a vCard, and SHOULD say why. It MAY instead use the local part of an e-mail address, or a label the user supplied. 4.3. Carried Properties Every standing property User ID other than FN is written to the vCard as it stands, since it already is a valid and escaped content line. This includes the UID property User ID (Section 4.5). An implementation MAY restrict this to the properties it knows. 4.4. EMAIL For each standing name-addr User ID, the address between the last pair of angle brackets is written as an EMAIL property, provided that it contains an "@" and that nothing but whitespace follows the closing bracket. The address of the primary User ID -- the standing User ID whose newest self-signature carries the Primary User ID subpacket (Section 5.2.3.27 of [RFC9580]) -- is written first, with PREF=1 (Section 5.3 of [RFC6350]), which is the address an address book offers first. The other addresses are written without a PREF parameter, in the order of the User IDs: EMAIL;PREF=1:alice@example.org EMAIL:alice@work.example.org A certificate can only designate one primary User ID, and says nothing of the order of the others. If the primary User ID carries no address, or if no User ID is flagged primary, no address is given a PREF parameter: an implementation MUST NOT rank addresses the holder has not ranked. Brucker & Mnêmê Expires 5 April 2027 [Page 6] Internet-Draft OpenPGP and vCard October 2026 4.5. UID, KIND and GEO A standing UID property User ID is written as it stands (Section 4.3): UID:urn:eid:u4vb6UZTMKsllgoH760pc0xwe_42.17-002.76 When there is none, an implementation SHOULD derive the vCard UID from the deprecated comment form of a legacy User ID (Section 3.5), written as the URN of [I-D.foopgp-urn-eid]. If the standing User IDs name several different entity identifiers, an implementation SHOULD NOT write any UID, and SHOULD warn that the certificate does not name one entity. An implementation MAY infer KIND from the identifier, KIND:individual for a u4, which identifies a human being. It MAY infer GEO from the coordinate suffix of a u5, which encodes the place of origin of the entity. A GEO User ID on the certificate takes precedence over an inferred one. 4.6. KEY The certificate itself is written twice: once as the address it can be fetched from, so that a card can follow the certificate as it gains certifications and loses User IDs, and once inline, so that the card is usable on its own. The address MUST be that of the keyserver the certificate prefers, chosen as follows: 1. For each User ID, take its newest self-signature (type 0x10 to 0x13) issued by the certificate's own key, and ignore it if a certification revocation by the same key on that User ID is newer still. 2. Among the User IDs that remain, take the Preferred Key Server subpacket of the one flagged as primary, or failing that of the last one. 3. A Preferred Key Server subpacket in a third-party certification MUST be ignored: it is not for a third party to say where a certificate lives. If the certificate names no keyserver, the implementation's default keyserver is used. The keyserver URI is turned into an HTTP URL by mapping the scheme hkps to https and hkp to http, adding the port 11371 to hkp when none is given, and appending a legacy HKP "get" lookup ([I-D.ietf-openpgp-hkp]) for the primary key fingerprint. The Brucker & Mnêmê Expires 5 April 2027 [Page 7] Internet-Draft OpenPGP and vCard October 2026 fingerprint SHOULD be written in upper case, as fingerprints and key IDs usually are, so that two tools rendering the same certificate write the same card: KEY;MEDIATYPE=application/pgp-keys:https://keys.example.org/pks/lo okup?op=get&search=0x The inline copy is the binary Transferable Public Key (Section 10.1 of [RFC9580]), encoded in base64 as a data URI: KEY:data:application/pgp-keys;base64, User Attribute packets and the signatures over them MUST be left out of the inline copy, since the photograph is carried by PHOTO (Section 4.7) and would otherwise double the size of the card. Third-party certifications MAY also be left out, to keep the card small; the copy at the keyserver address remains complete. 4.7. PHOTO If the certificate carries an image User Attribute (Section 5.12.1 of [RFC9580]), the image of the standing one with the newest self- signature is written as a PHOTO data URI, without its 16-octet image header: PHOTO:data:image/jpeg;base64, The newest is taken, not the first in packet order, which on a certificate whose holder replaced their photograph is the oldest. 4.8. Line Folding Content lines are folded as specified in Section 3.2 of [RFC6350]: at most 75 octets, then CRLF and a single space at the start of each continuation line. A line MUST NOT be folded inside a multi-octet UTF-8 sequence. Inline keys and photographs make lines thousands of octets long, and some readers reject unfolded ones. 4.9. jCard The same card MAY be produced as a jCard [RFC7095]. 5. Example A certificate whose standing User IDs are: Brucker & Mnêmê Expires 5 April 2027 [Page 8] Internet-Draft OpenPGP and vCard October 2026 UID:urn:eid:u4vb6UZTMKsllgoH760pc0xwe_42.17-002.76 FN:François-Xavier de Tocqueville François-Xavier de Tocqueville TEL:+33612345678 NOTE:Ingénieur\, horticulteur whose name-addr User ID is flagged primary, and whose self-signatures name hkps://keys.example.org as preferred keyserver, is rendered as: BEGIN:VCARD VERSION:4.0 FN:François-Xavier de Tocqueville UID:urn:eid:u4vb6UZTMKsllgoH760pc0xwe_42.17-002.76 KIND:individual EMAIL;PREF=1:fx@example.org TEL:+33612345678 NOTE:Ingénieur\, horticulteur KEY;MEDIATYPE=application/pgp-keys:https://keys.example.org/pks/lo okup?op=get&search=0x KEY:data:application/pgp-keys;base64, END:VCARD (KIND is inferred, and MAY be absent; long lines are shown folded.) 6. Implementation Status This section records the status of known implementations at the time of writing, and is to be removed before publication. * pgpid (C), action cert_tovcard: renders a certificate as a vCard as described in Section 4; reads property User IDs. * bl-pgpid (bash): writes property User IDs (Section 3.4) and upgrades legacy certificates (Section 3.5). * foodjis for Android (Kotlin): writes FN, NOTE, TEL, ADR, URL, LANG and GEO User IDs from a security key, and upgrades legacy certificates before any change; renders a certificate as a vCard to share it. * pgp2vcard, a page served by keys.foopgp.org (JavaScript, in the browser): renders a pasted certificate as a vCard or a jCard, including the KIND and GEO inferences of Section 4.5. Brucker & Mnêmê Expires 5 April 2027 [Page 9] Internet-Draft OpenPGP and vCard October 2026 7. Security Considerations A property User ID is a claim by the certificate's holder, like any User ID. That a certificate is valid says that its holder wrote the line, not that the line is true. Third-party certifications over a property User ID are what vouch for it; an application that shows a vCard rendered from a certificate SHOULD show which lines are certified, or at least the validity of the certificate as a whole. A vCard rendered from a certificate is only as trustworthy as the certificate it was rendered from. A vCard that merely carries a KEY property is not thereby authenticated: the key in it must be checked like any other. The keyserver address in a KEY property is chosen by the certificate's holder. Fetching it tells that keyserver that the card is being used. Only the holder's own self-signatures may choose it (Section 4.6); otherwise any third party could redirect the card's updates by certifying a User ID with a Preferred Key Server subpacket. Free-text values are written into User IDs and vCards verbatim except for escaping. An implementation MUST escape values when writing them, and MUST NOT interpret them as anything but text when reading them. 8. Privacy Considerations What a certificate carries is public, and keyservers keep it: revoking a User ID withdraws it, but does not erase it from copies already distributed. A telephone number or a postal address put on a certificate should be considered published for good. An implementation that writes such properties SHOULD say so to the person before doing it. 9. IANA Considerations This document has no IANA actions. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Brucker & Mnêmê Expires 5 April 2027 [Page 10] Internet-Draft OpenPGP and vCard October 2026 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, . [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, DOI 10.17487/RFC6350, August 2011, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9580] Wouters, P., Ed., Huigens, D., Winter, J., and Y. Niibe, "OpenPGP", RFC 9580, DOI 10.17487/RFC9580, July 2024, . 10.2. Informative References [I-D.dkg-openpgp-userid-conventions] Gillmor, D. K., "OpenPGP User ID Conventions", Work in Progress, Internet-Draft, draft-dkg-openpgp-userid- conventions-00, 25 August 2023, . [I-D.foopgp-urn-eid] Brucker, J. J. and Mnêmê, "The 'eid' URN Namespace -- Entity IDentifiers", 14 July 2026, . [I-D.ietf-openpgp-hkp] Shaw, D., Gallagher, A., and D. Huigens, "OpenPGP HTTP Keyserver Protocol", Work in Progress, Internet-Draft, draft-ietf-openpgp-hkp-01, 5 June 2026, . [RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095, DOI 10.17487/RFC7095, January 2014, . Acknowledgments The property User IDs were first tried on the certificates of the members of the foopgp association, whose experience of real mail clients decided Section 3.3. Brucker & Mnêmê Expires 5 April 2027 [Page 11] Internet-Draft OpenPGP and vCard October 2026 Authors' Addresses Jean-Jacques Brucker foopgp Email: jjbrucker@foopgp.org Mnêmê foopgp Email: mneme@foopgp.org Brucker & Mnêmê Expires 5 April 2027 [Page 12]