The current draft specifies the "Signer's User ID" subpacket as the
user ID that is "responsible for the signing". When I documented the
existing attribute ID design, I was concerned that someone might try
and make a Signer's User ID for an attribute packet which raises a
problem since there is no way for the verifier of the signature to
know if a given Signer's User ID should be parsed as a text or
attribute user ID. Because of this (and a slight worry about massive
signatures that contain embedded JPEGs), I asked Jon Callas to put in
"This subpacket is not appropriate to use to refer to a User Attribute
packet."
This has always bothered me, since I feel that an attribute user ID
should be as useful as a regular text user ID.
Here are two different proposals to fix this. I'm not strongly wedded
to either solution in particular. I just want to address the
limitation.
1) Change the definition of the Signer's User ID to be the SHA-1 hash
of the contents of the User ID (whether textual or attribute) in
question. The usual user ID hashing rules apply (0xd1/0xb4 + len +
contents). This eliminates the problem by making all Signer's User
ID subpackets parsable in the same way. Impact from this change
should be minimal as nobody (so far as I know) has implemented
Signer's User ID yet.
or
2) Add a new signature subpacket, which is an attribute user ID
counterpart to the Signer's User ID subpacket, defined identically
to the current Signer's User ID subpacket, but used for attribute
user IDs. This eliminates the problem by making it clear how the
subpacket needs to be parsed (text or attribute).
Note that #1 has the detail that a signature containing a Signer's
User ID subpacket of a user ID that the verifier does not have on his
local copy of the key does not "give away" the contents of that user
ID. I can see this as an advantage or a disadvantage, depending on
what the signer is trying to accomplish.
#2 has the detail that a signature could conceivably contain an
embedded attribute ID, and thus (for example) contain the photograph
of the signer. Like #1, I can see this as an advantage or
disadvantage, depending on what the signer is trying to accomplish.
(It also can lead to really large signatures).
As I said before, I'm not wedded to either solution. I would like to
address the limitation though.
David