Subject: Signer's User ID

From: Werner Koch <[email-masked]>
Date: Thu, 21 Jul 2005 07:39:32 +0200

Hello!

I'd like to have a clarification of the signature subpacket

  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.

It is not clear to me whether the string should be a verbatim copy of
the content of a User ID packet or some other information.  The second
paragraph could be viewed as a hint for a verbatim copy.

OTOH, for applications it makes more sense to have just the vanilla
mail address (mailbox@domain) here.  This would make it easier to
compare a mail's From address to the actual signature.

I don't care much about this but given that such a subpacket has been
defined but is not widely used - if at all - we might want to define
it in a stricter way.

Shalom-Salam,

   Werner

---

From: Jeroen Massar <[email-masked]>
Date: Thu, 21 Jul 2005 10:32:50 +0200

>   5.2.3.22. Signer's User ID

<SNIP>

> compare a mail's From address to the actual signature.

As I actually never really took time to read the full spec, I didn't
come across of this before, but this is indeed ideal for making keys
distributed in nature.

"Solution" for making it distributed would be:
http://www.imc.org/ietf-openpgp/mail-archive/msg11035.html

I haven't seen the agenda yet and it is not online, but it might be
interresting to have a chat about this. The slot is monday morning from
09:00 - 10:00...

Question to Werner: does gnupg support the above item, if not can we add
it, and secondly could we have gnupg then derive the keyserver from it
as I noted before? (read: want a patch?)

Greets,
 Jeroen

---

From: David Shaw <[email-masked]>
Date: Thu, 21 Jul 2005 07:47:43 -0400

> paragraph could be viewed as a hint for a verbatim copy.

I suggested that second paragraph when I was documenting the user
attribute / photo ID stuff.  There are some problems using a Signer's
User ID with attribute IDs, both in size and in knowing how to parse
the thing.

A while back, I posted a proposal to fix this:

  http://www.imc.org/ietf-openpgp/mail-archive/msg04775.html

David

---

From: David Shaw <[email-masked]>
Date: Thu, 21 Jul 2005 07:54:51 -0400

> http://www.imc.org/ietf-openpgp/mail-archive/msg11035.html

That message suggests adding the signer's name to signatures in some
manner, and then using that to hint to the keyserver which key to
fetch when verifying a signature.  It seems a fairly roundabout way to
get a key.

Why not just do this directly?  We already have a keyserver subpacket
(24), which is an URL, so it can even point to a web page.  If a
signer wants to give "how to get my key" information in their
signature, just point to it directly.

> as I noted before? (read: want a patch?)

GnuPG already supports what I said above.  And if you set
auto-key-retrieve, it'll even fetch the key for you automatically when
it sees a signature with such information.

David

---

From: Ian Grigg <[email-masked]>
Date: Thu, 21 Jul 2005 13:11:56 +0100

>     personal communications. This subpacket allows such a keyholder to
....
> defined but is not widely used - if at all - we might want to define

Or drop it or mark it deprecated.  If it's been this long and
nobody noticed, then clean it out and make things simpler?

I'm not entirely sure that I understand what the intent is
(which was partly your point!).

But it recalls to mind what we do in contract issuance.  In
our model, we add strings to every keyId in the chain.  These
"roles" then inform the software of how to prepare and check
the signature chain on contracts.  The ones in the chain
should be like this:

    [certification] Iang <iang@...>
    [contract] Iang <iang@...>

That is, a key listing [certification] should sign a key listing
[contract] which signs the contract.  The software checks
all that.

Now, if this is the same sort of thing that the "Signer's User
Id" packet is intended to achieve, I'd suggest that this clear
text method of specifying roles in the keyId may be superior
as it does not require software support to indicate the intent
to the users.  That's very important in legal work as anything
that hides intent in special packets leads to questions as to
whether the software was doing the right thing.

Just some observations - I may be off base here in my
interpretation of what this subpacket does.

iang
-- 
Advances in Financial Cryptography, Issue 2:
   https://www.financialcryptography.com/mt/archives/000498.html
Mark Stiegler, An Introduction to Petname Systems
Nick Szabo, Scarce Objects
Ian Grigg, Triple Entry Accounting

---

From: Werner Koch <[email-masked]>
Date: Thu, 21 Jul 2005 15:15:11 +0200

> "roles" then inform the software of how to prepare and check

This works well when using a new key for each role. 

Assuming you would add the rules as different UID to one key you can't
see from a signature which role/UID was used to sign the document.
The Signer's User ID is a solution to this; however it is far easier
to create separate keys.

> whether the software was doing the right thing.

Agreed.

Salam-Shalom,

   Werner

---

From: Ian Grigg <[email-masked]>
Date: Thu, 21 Jul 2005 14:30:08 +0100

> The Signer's User ID is a solution to this; however it is far easier

I agree entirely, that's in fact what we do, and
the software rejects any additional roles that
might be present.

There's also the issue that generally different
roles have different security models, so for
example ones [certification] key might be better
off locked in the safe.

iang