Hi Jon,
On 01.10.2020 01:14, Jon Callas wrote:
I've been reading through a lot of this documentation and I like the idea of
whatever we want to call them.
Thanks!
Notations are supposed to be an analogue to X.509v3 extensions;
Yes. One extension in particular seems like a direct analogue: Subject
Alternative Name [0]. Let me quote the RFC 5280:
The subject alternative name extension allows identities to be bound
to the subject of the certificate. (...) Defined options include an
Internet electronic mail address, a DNS name, an IP address, and a
Uniform Resource Identifier (URI).
[0]: https://tools.ietf.org/html/rfc5280#section-4.2.1.6
This is exactly what the notation I proposed contains: URIs for
identities that can be verified.
In contrast, a User Attribute is the generalization of a User ID. It says
"this key speaks for <ID>" whether that ID is an email address, etc. and then
various keys make certification signatures stating that they agree with that.
But does this generalization bring any benefit over just regular User
IDs that contain the identity directly? For example what would be the
actual benefit of having User Attribute that contains URI such as
"https://twitter.com/user"; over a User ID that contains the same exact
value?
In my opinion for values such as URIs there is no benefit and using User
Attribute in this case would be making the solution more complex than
necessary. 4880 says that User Attribute "is capable of storing more
types of data than the User ID packet, which is limited to text." but in
this case text is all that is necessary to represent a URI.
Having implemented social proofs in software using User Attributes [1]
and then User IDs [2] and then using notations [3] I must say, as an
implementer and user of these systems, that User Attributes were the
worst of all three. (We could use the feedback from the implementation
phase to improve the specification of User Attributes but I don't want
to derail the discussion even further).
[1]: https://tools.ietf.org/html/draft-vb-openpgp-linked-ids-01
[2]: https://github.com/wiktor-k/distributed-ids#distributed-ids
[3]: https://github.com/wiktor-k/openpgp-proofs#openpgp-proofs
I can think of another utterly different syntax, though, that would be
similar to what Vinnie Moscaritolo and Tony Mione did in "PGP Tickets" which
you can find as an I-D at
<https://tools.ietf.org/html/draft-moscaritolo-mione-pgpticket-03>.
Thank you for the reference. I have never seen this one.
After a couple of days of discussions and some time to reflect I decided
that I'd like to retract the registration of the "proof" notation.
Social proof system, while interesting to play around, is of limited use
to the general public and as such do not smoothly fit the OpenPGP RFC.
For private projects such as keyoxide.org private/user space for
extensions is everything what's needed and is available right now.
Jon, Neal, thank you for your time discussing this matter!
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