[openpgp] Signer's User ID

[Neal H. Walfield]

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" <***@walfield.org>, and the user runs:

echo data to sign | gpg --default-key ***@walfield.org -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 "***@walfield.org".


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

[Thijs van Dijk]

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

Post by Neal H. Walfield
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
or
echo data to sign | gpg --default-key 'Neal H. Walfield' -s
Then, in both cases we include this subpacket in the signature packet
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
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
_______________________________________________
openpgp mailing list
https://www.ietf.org/mailman/listinfo/openpgp

[Neal H. Walfield]

On Thu, 15 Sep 2016 12:23:55 +0200,

Post by Thijs van Dijk
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).

Good point.

:) Neal

[Daniel Kahn Gillmor]

Post by Neal H. Walfield
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
or
echo data to sign | gpg --default-key 'Neal H. Walfield' -s
Then, in both cases we include this subpacket in the signature packet
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
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.

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

[Neal H. Walfield]

Hi Daniel,

On Tue, 20 Sep 2016 22:39:08 +0200,

Post by Daniel Kahn Gillmor
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?

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

[Werner Koch]

Post by Neal H. Walfield
This was my initial assumption as well, but Werner had some arguments,
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