Re: Signer's User ID

Ian Grigg <> Thu, 21 July 2005 12:24 UTC

Received: from ([] by with esmtp (Exim 4.32) id 1Dva5t-0008Oq-P8 for; Thu, 21 Jul 2005 08:24:06 -0400
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id IAA25147 for <>; Thu, 21 Jul 2005 08:24:00 -0400 (EDT)
Received: from ( []) by (8.12.11/8.12.9) with ESMTP id j6LCDQa7028209; Thu, 21 Jul 2005 05:13:26 -0700 (PDT) (envelope-from
Received: (from majordom@localhost) by (8.12.11/8.12.9/Submit) id j6LCDQnk028208; Thu, 21 Jul 2005 05:13:26 -0700 (PDT)
X-Authentication-Warning: majordom set sender to using -f
Received: from ( []) by (8.12.11/8.12.9) with ESMTP id j6LCDPA0028189 for <>; Thu, 21 Jul 2005 05:13:26 -0700 (PDT) (envelope-from
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3BE5B1A34F2; Thu, 21 Jul 2005 14:12:36 +0200 (CEST)
Received: from ([]) by localhost (zentrix []) (amavisd-new, port 10024) with ESMTP id 22038-02; Thu, 21 Jul 2005 14:12:35 +0200 (CEST)
Received: from localhost (localhost []) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTP id 9689F1A349F; Thu, 21 Jul 2005 14:12:35 +0200 (CEST)
From: Ian Grigg <>
To: Werner Koch <>
Subject: Re: Signer's User ID
Date: Thu, 21 Jul 2005 13:11:56 +0100
User-Agent: KMail/1.8.1
References: <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <>
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at
Precedence: bulk
List-Archive: <>
List-Unsubscribe: <>
List-ID: <>
Content-Transfer-Encoding: 7bit

On Thursday 21 July 2005 06:39, Werner Koch wrote:

> I'd like to have a clarification of the signature subpacket
> 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
> 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.

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.

Advances in Financial Cryptography, Issue 2:
Mark Stiegler, An Introduction to Petname Systems
Nick Szabo, Scarce Objects
Ian Grigg, Triple Entry Accounting