On 06/27/2018 09:27 PM, Wiktor Kwapisiewicz wrote:
Hello,
Well, yes, and I claim this strict technical term designates something
that has no sensible meaning. If I remember correctly, GnuPG uses it to
show whether at least one User ID has been signed by a key that is
trusted. The validity should instead apply to the (key, User ID) couple,
and then it does make sense.
Actually, 4880bis§5.2.1 already defines type 0x10 (which is IIRC the
most used type for certification signatures) as “Generic certification
of a User ID and Public-Key packet,” which isn't “Generic certification
of a Public-Key packet.”
Yes, person X certifies User ID Y of key Z. Y and Z are part of the
signature (signed User ID + Key ID [0]) but the other party - the person
X (issuer) puts only their key ID as a part of the signature, not their
User ID [1]. Thus you still need validity per key to know if you can
trust Person X's certifications. [2]
[0]: This is described here:
https://tools.ietf.org/html/rfc4880#section-5.2.4
[1]: There is Signer's User ID subpacket but it's rarely used and not
used for key certifications as far as I know.
[2]: Personally, having issuer's User ID be part of trust calculations
seems to be overly complex, what difference does it make if it's the
same person signing the key?
Well, I agree with you until the “Thus”. You don't need validity per key
to know if you can trust Person X's certifications, you only need
ownertrust :)
And I think we stopped understanding each other at some point, at least
I didn't mean to imply that we should insert the issuer's User ID into
trust calculations.
What I'm saying is:
* When you “sign a key”, you actually sign a (Key, User ID)
association, so the “validity” is actually a property of the (Key, User
ID) couple, not of the key.
* When you want to verify a (Key, User ID) validity, you list the
signatures. In the signatures, you look for signatures of keys you trust
(as in ownertrust, which AFAIR isn't defined in rfc4880, apart from in
trust signatures). If you trust enough keys that signed the (Key, User
ID) couple, then you can consider it valid.
* Trust is completely decoupled from validity, and you could perfectly
trust a key that's not valid to you (even though I can't think of a
reasonable use case for it).
* Trust signatures extend this scheme by allowing a trusted key to
introduce you to other keys that will then become trusted (and most
likely valid, because the trust signature is also a signature -- all
this depends on local policy).
And, with this in mind, I can't find a reasonable concept of “valid
key”, only of “valid key-User Id associations”, which would become under
my proposal “valid key-User Attribute associations”, and would likely
decrease the risk of UIs misleading the user into thinking that a key is
“valid”, whatever that could mean.
And in particular of showing an unvalidated User ID just because it is
the primary User ID.
Exactly. And this kind of modification that requires changing all tools
along the path, for a standard so widely used as OpenPGP can be hard to
pull off.
Well, my hope in pushing this for v5 is that a lot of tools will already
have to be changed along the path, so I was hoping this would be only an
additional change that wouldn't be delayed as much :)
Well, this is the most complex change suggested that I've seen here,
everything else is mostly backwards compatible (note that there is not
much traffic here ;) ).
Indeed, then anyway rfc4880bis isn't anywhere close to completion as the
WG was even closed, so I guess it's not really pressing matters. But
yes, implementation weight is, in my mind, the biggest (and potentially
blocking, though I can't speak for implementers) drawback of this idea.
All this could help particularly in relation to scoped trust, allowing
to trust certain keys only for signatures on certain User Attributes,
eg. allowing a GitHub official key to sign all “free form tag=value”
User Attributes for which “tag” is “github”. Which would be next to
impossible to do without at least a minimal amount of standardization in
User Attributes, as is currently the case with everyone misusing User
IDs everyone with their custom scheme for this purpose
This is already possible with trust signatures with domain restriction.
If GitHub had their key (and that's a big if) and signed their user's
IDs that have e-mails in form *@users.noreply.github.com with trust sig
level 1 then you could trust sign GitHub's key with trust signature
level 2 limiting that to the users.noreply.github.com domain.
Indeed, but that requires all users to “naturally standardize” on
*@users.noreply.github.com. Everything I propose can be done with the
current User ID scheme. Heck, it's even possible to just “naturally
standardize” on putting “name=My Name”,
“email=my(_dot_)email(_at_)example(_dot_)org”,
etc. in the User ID fields.
The main thing I try to do with this proposal is to give things a place
“by standard”, thus allowing tools to rely on it and eg. assume that in
the “name” attribute then it is the name of the person, without having
to parse the User ID field and try to guess which “natural standard”
this specific key has followed :)
BTW, just for completeness, the current tsign-based scheme wouldn't
require GitHub to issue trust-signatures to keys, it could work the
following way:
* Users put *@users.noreply.github.com User IDs
* GitHub issues normal signatures on validated (Key, User ID in
*@users.noreply.github.com format) pairs
* Users willing to trust GitHub add a Trust Packet with trust level 255
(because why not, trust level 1 would be enough but could be considered
lower than “marginal” and thus not actually be enough to validate
associations) and a limitation to *@users.noreply.github.com to their
local copy of the GitHub key (or can alternatively use a trust signature
if they feel like it)
The same approach with trust signatures could be used by organizations
and their "role" system.
This article goes into more detail:
https://www.linuxfoundation.org/blog/pgp-web-of-trust-delegated-trust-and-keyservers/
Indeed that's possible, but it requires “naturally standardizing” for
eg. roles in comment sections of User IDs. And in my mind de facto
standardization that isn't recognized by the standard means that de jure
standardization has failed.
Anyway, that's all I have to say, I think, so if I receive no positive
feedback I guess I'll just try to, within a few years, turn my idea into
yet another protocol with its single implementation, and see what
happens. :)
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp