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)
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.)
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.”?
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.
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.
OTOH, without such additional policies (that can be enforced by
conforming implementations), the proposed fields will just be more free
form fields in OpenPGP that accumulate cruft over time. There are a
couple of those already, and we have a pretty bad track record
validating those.
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 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: 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.
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 :)
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp