[openpgp] Re: [Technical Errata Reported] RFC9580 (844 9)

Daniel Kahn Gillmor <[email protected]>
Newsgroups gmane.ietf.openpgp
Message-ID <[email protected]>
Hi Jasper, OpenPGP WG--

I believe that reported erratum 8849 is correct that the User ID
convention in section 5.11 of RFC 9580 is incorrect (as it was in RFC
4880 before, and RFC 2440 before that), but I don't agree with the
proposed corrected text.

The topic of what the actual convention of the OpenPGP User ID is has
come up repeatedly in the working group, but the working group has not
yet chosen to adopt any particular clarification on it.

A few years ago, I wrote up
https://datatracker.ietf.org/doc/draft-dkg-openpgp-userid-conventions/
to try to describe the actual conventions that members of the working
group have observed in the wild, but the working group has been focused
on other matters recently.  (see also the mailing list threads
referenced in §B.2 of that draft)

A skim of that drafts suggests that neither mailbox nor name-addr are
appropriate choices here.  For example, if non-ASCII characters are
present in the display name, they are simply encoded as UTF-8 directly,
and not escaped according to RFC 2047.

Furthermore, since writing that draft, i've observed in practice issues
with leaving off angle brackets in an OpenPGP user ID that is intended
to just be an e-mail address.  Wrapping a pure-email-address user ID in
angle brackets is an effective way to clearly signal to the certificate
consumer that the given User ID is intended as an e-mail address.

As a result, I'm not sure how to propose categorizing this erratum.

Regards,

        --dkg

On Thu 2025-06-05 06:30:10 -0700, RFC Errata System wrote:
> The following errata report has been submitted for RFC9580,
> "OpenPGP".
>
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid8449
>
> --------------------------------------
> Type: Technical
> Reported by: Jasper Spaans <[email protected]>
>
> Section: 5.11
>
> Original Text
> -------------
>    A User ID packet consists of UTF-8 text that is intended to represent
>    the name and email address of the keyholder.  By convention, it
>    includes a mail name-addr as described in [RFC2822], but there are no
>    restrictions on its content.  The packet length in the header
>    specifies the length of the User ID.
>
>
> Corrected Text
> --------------
>    A User ID packet consists of UTF-8 text that is intended to represent
>    the name and email address of the keyholder.  By convention, it
>    includes a mailbox as described in [RFC2822], but there are no
>    restrictions on its content.  The packet length in the header
>    specifies the length of the User ID.
>
>
> Notes
> -----
> A name-addr requires angled brackets around the mail address, which in practice are left off when there is no display name.
> `mailbox` in rfc2822 (and 5322) is defined as `name-addr / addr-spec` so it can be either the original name-addr, or a bare address which does occur in the wild.
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". (If it is spam, it 
> will be removed shortly by the RFC Production Center.) Please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> will log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC9580 (draft-ietf-openpgp-crypto-refresh-13)
> --------------------------------------
> Title               : OpenPGP
> Publication Date    : July 2024
> Author(s)           : P. Wouters, Ed., D. Huigens, J. Winter, Y. Niibe
> Category            : PROPOSED STANDARD
> Source              : Open Specification for Pretty Good Privacy
> Stream              : IETF
> Verifying Party     : IESG

_______________________________________________
openpgp mailing list -- [email protected]
To unsubscribe send an email to [email protected]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.