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(_at_)(_dot_)(_dot_)(_dot_)>
[contract] Iang <iang(_at_)(_dot_)(_dot_)(_dot_)>
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