Subject: [openpgp] Signer's User ID

From: "Neal H. Walfield" <[email-masked]>
Date: Thu, 15 Sep 2016 11:33:10 +0200

RFC 4880 says:

  5.2.3.22.  Signer's User ID

   (String)

   This subpacket allows a keyholder to state which User ID is
   responsible for the signing.  Many keyholders use a single key for
   different purposes, such as business communications as well as
   personal communications.  This subpacket allows such a keyholder to
   state which of their roles is making a signature.

   This subpacket is not appropriate to use to refer to a User Attribute
   packet.

In GnuPG, we use the user id's email address.  Thus, if a key has the
user id "Neal H. Walfield" <[email-masked]>, and the user runs:

  echo data to sign | gpg --default-key [email-masked] -s

or

  echo data to sign | gpg --default-key 'Neal H. Walfield' -s

Then, in both cases we include this subpacket in the signature packet
with the string "[email-masked]".

Note: we use data for locating the key via DANE or WKS as well as in
our TOFU implementation to identify the intended binding.

Since, IMO, the spec is unclear about the contents of this field and
Werner pointed out that another implementation could reasonably use
the hash of the user id here, I think it makes sense to clarify
exactly what is expected to increase interoperability.  My proposal to
standardize GnuPG's behavior is:

  5.2.3.22.  Signer's User ID

   (String)

   This subpacket allows a keyholder to state which User ID is
   responsible for the signing.  Many keyholders use a single key for
   different purposes, such as business communications as well as
   personal communications.  This subpacket allows such a keyholder to
*  state which of their roles is making a signature.  The value of
*  this subpacket is a byte-for-byte copy of the RFC 2822 mail name-addr
*  portion of the User ID.

   This subpacket is not appropriate to use to refer to a User Attribute
   packet.

Thanks,

:) Neal

---

From: Thijs van Dijk <[email-masked]>
Date: Thu, 15 Sep 2016 12:23:55 +0200

Good catch. I think being explicit about the expected contents of this
packet also makes the next sentence redundant (the one that prohibits
embedding a UAT).

-Thijs

--
Thijs van Dijk

6A94 F9A2 DFE5 40E3 067E  C282 2AFE 9EFA 718B 6165

On 15 September 2016 at 11:33, Neal H. Walfield <[email-masked]> wrote:

> _______________________________________________
> openpgp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/openpgp
>

---

From: "Neal H. Walfield" <[email-masked]>
Date: Thu, 15 Sep 2016 12:24:55 +0200

On Thu, 15 Sep 2016 12:23:55 +0200,
> packet also makes the next sentence redundant (the one that prohibits

Good point.

:) Neal

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 20 Sep 2016 16:39:08 -0400

>    This subpacket is not appropriate to use to refer to a User Attribute

fwiw, i've always assumed this was a byte-for-byte match of the signing
User ID itself, UTF-8-encoded just like the User ID.  Making this a
specific transformation of the User ID seems like an extra complication,
without much gain, no?

Tools that do DANE or WKS or other lookups can do whatever
transformation they need independently of what's stored in this
subpacket.  Why require a new transformation in the OpenPGP spec itself?

        --dkg

---

From: "Neal H. Walfield" <[email-masked]>
Date: Wed, 21 Sep 2016 11:21:57 +0200

Hi Daniel,

On Tue, 20 Sep 2016 22:39:08 +0200,
> specific transformation of the User ID seems like an extra complication,

This was my initial assumption as well, but Werner had some arguments,
which I'm having trouble reproducing now.  Hopefully he'll respond
here.

:) Neal

---

From: Werner Koch <[email-masked]>
Date: Wed, 21 Sep 2016 17:40:16 +0200

> which I'm having trouble reproducing now.  Hopefully he'll respond

There are lot of things in OpenPGP which are not strictly defined and it
is assumed that applications do the Right Thing.  IIRC, the Signer's UID
was discussed but nobody had a real interest in using it.  Thus what we
have is a subpacket number and a generic description for what it may be
used.

I am in favor of not changing the specs.

Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.