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?
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 ;) ).
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.
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/
I think that's all from me now, take care!
Kind regards,
Wiktor
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp