On 06/27/2018 02:42 AM, Marcus Brinkmann wrote:
On 06/27/2018 01:28 AM, Leo Gaspard wrote:
On 06/26/2018 10:45 PM, Marcus Brinkmann wrote:
I think the problem you are facing is Zooko's triangle: Decentralised,
meaningful names for keys can not be secure.
Indeed, this is similar to what I am thinking. But Zooko's triangle is
only for “decentralized” names, and what I see in all implementations
that I know of is that the end-user “validates” a particular (sub)set of
the names the key claims it has, and then uses these names. (similar to
handles defined in XEP-0165)
If the use is purely local, you don't need OpenPGP at all, just store a
local label to name the key. That's what NeoPG will do and Sequoia wants
to do that, too, AFAIK.
The only reason to create (exportable) signatures is to convince
thirdparties of the binding, either by authority (centralized+secure,
CA-style) or by introduction (decentralized+insecure, web of trust).
OpenPGP (standard and implementations) has the concept of a local,
non-exportable signature. As far as I am concerned, that's just a leaky
abstraction due to historic implementation details being exposed, just
as with Trust Packets: Non-exportable signatures are by definition
local, and trust packets are local by a SHOULD rule (and in fact wholly
implementation defined).
Indeed my reply was completely off-track here, and I was thinking only
of local signatures when writing this… which was stupid, given that all
the point is about making signatures for others to use.
Also, I am not trying to solve Zooko's triangle, only to decouple
elements that are currently tightly interwoven without any reasonable
standard in the User ID field (hello @users.noreply.github.com, hello
roles in comments, etc.)
There is value in standardization of user id field values, but I am not
sure that OpenPGP is the place for that. Not only has that ship sailed,
it is also mostly useful if embedded in a larger policy framework, as
you have suggested from the beginning.
Well… OpenPGP already has User Attributes, hence my hope User IDs could
disappear in v5 keys. I do agree that the ship has sailed for <v5 keys,
but still hope things could be “fixed” for v5 keys. Then… maybe I'm just
hoping for something other than OpenPGP, but I would much rather have
something actually specified than yet another home-grown protocol that
will ever have a single implementer, and re-starting from scratch
doesn't sound like a good way to not have yet another home-grown protocol.
The PGP (implementation)
answer to this is the web of trust, but that is pretty much out of scope
for OpenPGP (the standard). This is also apparent from your description
by the introduction of external policies ("when I want to sign X, I need
to check Y"), that are also out of scope for OpenPGP. This might
explain the lack of response here.
Once you are adding additional policies, you can create additional
restrictions for user id fields, or introduce additional (private use?)
user attributes ad lib, and those will be the least of your worries.
Hmm… I think rfc4880bis§5.2, and in particular signature type 0x13 for
instance, do imply that “The issuer of this certification has done
substantial verification of the claim of identity.”?
Doesn't mean anything. In fact, in the same section the standard says:
"Please note that the vagueness of these meanings is not a flaw, but a
feature of the system. Because OpenPGP places final authority for
validity upon the receiver of a signature, it may be that one
signer's casual act might be more rigorous than some other
authority's positive act."
Well, I'm not implying that this paragraph means anything, just that
there is a concept of signature in the OpenPGP spec, and that it sounds
legitimate (to me) to want to have a way to sign only the parts of the
User ID that I want to sign :)
And thus the standard doesn't currently address the “I want to sign an
email address but not the name associated to it, because I haven't
checked the name” use case, unless the one who generated the key (not
the one who wants to sign) did generate orthogonal User IDs.
You can just create your own user ids and bind them to the key. Don't
laugh! See https://bitbucket.org/skskeyserver/sks-keyserver/issues/41
I am not suggesting that you should do this, or that it is or should be
meaningful. Just pointing out that the standard is incomplete in many
more ways than you might think.
Well, thanks for this link! I never noticed this indeed, and it could
come in handy… but I don't think it's a good idea either, indeed.
And actually rfc4880bis even mentions “By convention, it includes an RFC
2822 [RFC2822] mail name-addr” (even if not enforcing it), thus
encouraging non-orthogonal User IDs.
Doesn't mean anything. Here is a key with a key in the user id:
97E4CFC94B1D6212
Well, the fact that some people don't respect the conventions doesn't
mean they're not conventions: in practice, nearly all keys I exchange
information with have only User IDs in the “name <mail>” format. Which
is a problem from the “signing only the mail address” standpoint.
The point in these proposed fields, in my opinion, is that if User IDs
are removed from v5 keys altogether (if they aren't then there is no
point in doing it indeed), then there will be an enforced separation
enforced by whom? according to which rules?
Enforced technically by the absence of a User ID field. I'm not saying
it will not be possible to misuse fields, but that the convention should
naturally follow the namings: names in the “name” fields, pseudonyms in
the “pseudonym” fields, emails in the “email” fields, roles in the
“role” fields, etc.
of
different parts of the (current) User ID into separate fields.
As for these fields becoming free form, I do hope that it wouldn't
happen:
Here is a decentralised file storage based on OpenPGP user ids and
public keyserver networks;
https://github.com/yakamok/keyserver-fs
This is using uids, but if you remove them, hacks like this will move on
to other available fields.
Well, of course it's always possible to hack around things. But I don't
really care for these hacks, they can continue to use v4 keys, or any
other field of their choosing. It's not like I'm going to sign such an
identifier anyway.
What I'm saying is that if I can have, when signing a key, a series of
dialog boxes for all names and then for all pseudonyms and then for all
email addresses etc. that ask me whether I have signed the key, then as
an end-user I'm happy. On the other hand, if I always come back on the
name I haven't checked (like on 0x57B62140, which has User IDs with your
name), then I can only growl against the software and answer “no” to all
questions, despite my having checked the email address.
for the image attribute (the only one standardized afaik), I
haven't heard (yet?) of people using it for storing anything else than
an image. And with fields like:
* name
* pseudonym
* email
* role
* free form UTF-8 tag=value
Then, contrarily to what currently happens with User IDs, I don't think
the first four fields would really be misused: what's the point? there'd
be a free form tag=value attribute type.
"What's the point?" isn't the question. Either you can enforce something
or you can't. If you can't, then you can't rely on it, and then the
value of the rule will be severly diminished.
Well, even if I can't *enforce* that people put the right data at the
right place, if I imagine a user seeing a form like:
Name: [ ]
Pseudonym: [ ] (add another field)
Email: [ ] (add another field)
Role: [ ] (add another field)
Other: [ ] = [ ] (add another field)
(with the “Other” potentially replaced by more user-friendly “GitHub
username”, “GitLab username”, etc.)
Then I think that 99% of legitimate users will make the correct choice.
And then I can just assume that the rule is followed, and reap the
benefit. And even if some people have fun putting files in the “name”
field, then I just won't sign their keys, and who cares?
The 4.5 million or so keys on the SKS keyservers are public, you can
download them and investigate yourself what the consistency of the
existing dataset is. I haven't looked at photo ids yet in detail, so
those might look favorable, but that's probably just because there is
low-hanging fruit.
Just to give you an example: A local non-profit created hundreds of keys
and added signatures to the gpg maintainer's key to wish him a merry
christmas:
http://a.keyserver.pki.scientia.net/pks/lookup?op=vindex&search=0xF2AD85AC1E42B367
(scroll down)
Well… You're describing how broken the SKS network is (not saying these
bugs are not also features), I don't see how that relates to changing
the concept of User ID: such nonsense would (a priori) still be possible
after the change, but not worse than before :)
And this would already be enough to split the User ID tag into
orthogonal parts that could be signed independently, depending on the
signer's policy. And even type “free form tag=value” brings much more
display-ability than private-use types 100-110 that cannot be assumed to
have any type.
However, I do agree it'd be quite some maintenance burden, hence my hope
to get some feedback from an implementer. But I think it's necessary for
users and applications to behave consistently, and not mutilate the User
ID field just because it is the only one that is sanely rendered :)
For NeoPG, I'd simply use an URI scheme in the user id field, if I felt
that it should be exported.
Well… Honestly, I think this represents a failure of the standardization
process. This use case is already present in the real world, and people
have already started using work-arounds around it. For instance, SKS
keyservers return around 460 results for “users.noreply.github.com”, and
that's only the use case I searched for because I know someone with such
a UID.
Basically, what I remember from your message is “that ship has sailed,”
and… that makes me sad. I think these use cases (signing only an email
address, or signing a GitHub identity, or even an OTR identity) do fit
into the scope of the OpenPGP standard, and I'd love to see them addressed.
But maybe it'd be better to have another protocol that'd be dedicated to
only asserting some identities and linking them to the keys for certain
protocols… that'd be splitting off the WoT into a separate protocol, but
maybe it'd be better this way? Anyway, that's getting quite far
off-track for the OpenPGP working group, and I still hope such a change
could make sense for OpenPGP v5 keys.
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp