Re: Signer's User ID
Ian Grigg <iang@systemics.com> Thu, 21 July 2005 12:24 UTC
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dva5t-0008Oq-P8 for openpgp-archive@megatron.ietf.org; Thu, 21 Jul 2005 08:24:06 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25147 for <openpgp-archive@lists.ietf.org>; Thu, 21 Jul 2005 08:24:00 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6LCDQa7028209; Thu, 21 Jul 2005 05:13:26 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6LCDQnk028208; Thu, 21 Jul 2005 05:13:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from postix.sonance.net (mx2.sonance.net [62.116.45.130]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6LCDPA0028189 for <ietf-openpgp@imc.org>; Thu, 21 Jul 2005 05:13:26 -0700 (PDT) (envelope-from iang@systemics.com)
Received: from localhost (localhost [127.0.0.1]) by postix.sonance.net (Postfix) with ESMTP id 3BE5B1A34F2; Thu, 21 Jul 2005 14:12:36 +0200 (CEST)
Received: from postix.sonance.net ([127.0.0.1]) by localhost (zentrix [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22038-02; Thu, 21 Jul 2005 14:12:35 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by postix.sonance.net (Postfix) with ESMTP id 9689F1A349F; Thu, 21 Jul 2005 14:12:35 +0200 (CEST)
From: Ian Grigg <iang@systemics.com>
To: Werner Koch <wk@gnupg.org>
Subject: Re: Signer's User ID
Date: Thu, 21 Jul 2005 13:11:56 +0100
User-Agent: KMail/1.8.1
Cc: ietf-openpgp@imc.org
References: <87u0iok99n.fsf@wheatstone.g10code.de>
In-Reply-To: <87u0iok99n.fsf@wheatstone.g10code.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200507211311.58692.iang@systemics.com>
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at sonance.net
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
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 > > 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 .... > 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. 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
- Signer's User ID David Shaw
- Signer's User ID Werner Koch
- Re: Signer's User ID Jeroen Massar
- Re: Signer's User ID David Shaw
- Re: Signer's User ID David Shaw
- Re: Signer's User ID Ian Grigg
- Re: Signer's User ID Werner Koch
- Re: Signer's User ID Ian Grigg
- [openpgp] Signer's User ID Neal H. Walfield
- Re: [openpgp] Signer's User ID Thijs van Dijk
- Re: [openpgp] Signer's User ID Neal H. Walfield
- Re: [openpgp] Signer's User ID Daniel Kahn Gillmor
- Re: [openpgp] Signer's User ID Neal H. Walfield
- Re: [openpgp] Signer's User ID Werner Koch