Hi Neal,
Actually Vincent's draft was already discussed on the list in 2017
including the design decision of using User Attributes and I have to
agree with Werner's quote from back then:
(...) We have notation data which can be
used to add meta data to a user id.
Hiding things which might act as identities in UAT does not feel right.
We better keep UAT for what they are used today - for the more or less
useless photo-ids
Source:
https://mailarchive.ietf.org/arch/msg/openpgp/zgGQW8qPtJ94tkEVDpDJNsAdkxE/
Yes, you can't certify notations but why would you want to certify my
Twitter handle? It's not up to you to decide if it's valid. The proof is
designed to be checked against the actual service (Twitter in this case).
When Alice certifies that "Bob <bob(_at_)example(_dot_)org>" controls the
Certificate 0xBBBB, is she also certifying Bob's linked identities?
No, why would she? And why is this any different from Alice signing
Bob's User ID containing any other notation? Consider the alternative:
if Bob adds notation to his User ID saying "Alice loves me" should Alice
signature over that User ID be treated as her commitment? Clearly not.
As for the OpenKeychain example please note that the stable version
removed support for their linked identities [0].
[0]: https://github.com/open-keychain/open-keychain/pull/2408
It could be argued that it's the tooling that was missing but given that
both WKD and verifying keyservers strip User Attributes left and right
adding support for your design would require massive implementation
effort on all sides for a questionable benefit.
Thanks for your feedback!
Kind regards,
Wiktor
--
https://metacode.biz/@wiktor
signature.asc
Description: OpenPGP digital signature
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp