On Fri, Jan 30, 2009 at 9:06 PM, Daniel Kahn Gillmor
<dkg(_at_)fifthhorseman(_dot_)net> wrote:
I don't have an immediate example (i haven't used policy URIs on
self-sigs or anywhere else). But simply saying "these two policy-type
statements don't make sense" is different from saying "there could be no
possible policy statement that you would like to reference in a
self-signature."
Uhm,... well I'm not sure what the others are thinking.
Of course I see your point in preserving compatibility, but even if
this semantical change would be introduced in a future version of the
RFC it wouldn't probably hurt that much, would it? I mean policy URIs
are quite rare and everybody could still interpret it as he wants ;-)
For example, here's a policy statement: "This identity is found on
official government documents in the legitimate possession of the keyholder"
Say Margaret has two user IDs:
"Margaret Kantor <margaret(_at_)example(_dot_)com>"
"Maggie Kantor <maggie(_at_)example(_dot_)net>"
Since her gov't id doesn't have anything with "Maggie Kantor" on it (but
she's known by all of her friends as maggie) she might want to assert
the above policy for the former self-sig but not the latter.
I'm not saying it's a great use case, but it would be really unfortunate
if she had done that and then later found that it meant that all
signatures issued by the Margaret Kantor uid (if she used a Signer's
User ID subpacket, for example) suddenly meant that she had verified
specific gov't-issued ID.
Not sure if I understand what you mean.
A goverment could simply just sign the first UID and specify perhaps
the governmental policy that was used (but this is of course not on
the self signature).
Which information would you exactly put in the policy from the
self-signature's Policy URI?
(I actually believe that there might be reasonable cases, and just
want to understand yours correctly :-) )
1) Look at all policies whether they specify how to resolve conflicts.
this assumes that the policies are machine-parseable in a form that
includes conflict resolution, no?
Why? All policies might have a human readable chapter "X. In case of
policy conflicts", where they explain what should happen.
what form are you proposing? my
reading of the RFC is that there is no restriction on what can be
contained in the policy URI.
I don't see that point why this would have to be machine-readable.
If we're ok with saying something like: "well-implemented clients should
be configured well enough to know to not make any conflicts", why not
just tell the well-implemented clients to embed the policy URI subpacket
in every signature they make, and not introduce this special case at
all?
This is actually a good point and in principle you're right (and this
could be done without changing the RFC at all).
But my model would allow to implement a more mighty policy model
imagine the following:
The policy "in" the self-signature is used as I proposed above. It
could contain information like the following:
- How is the key secured (security building, fences, safes, guards)
- What are the procedures in case of a security compromise
- How are other key/UIDs certified (e.g. when is a 0x10, 0x11, 0x12 or
0x13 issued)
All these are very general information.
The policy of the non-self-signatures could contain additional
information about just that single signed document (for example).
That seems simpler all around to me, and wouldn't require any
retroactive changes to the specification.
Well that's a point.
But the whole idea with the semantic addition/change to the policy URI
was just an idea, that I wanted to be discussed by all these wonderful
experts here.
I don't claim that I have the proof that it makes sense or is the best
and only solution ;-)
btw, please don't take my opposition to this particular idea as
opposition to you
Oh and I was just about to add you to my deadly enemy list ;-) (just kidding)
proposing changes to the OpenPGP specification in
general. It's great to see this sort of discussion. Thanks for raising it!
Thank you :-) ... but again I was inspired by some threads I've found
on the gnupg-lists,... so I must thank Christoph Mitterer ;-)
Cheers,
Peter