On Oct 2, 2020, at 5:29 AM, Wiktor Kwapisiewicz
<wiktor(_at_)metacode(_dot_)biz> wrote:
Hi Jon,
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.
I think I see.
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?
I don't know.
The definition of a User ID is intentionally that it's just a string and is by
convention an email address. There's no reason you can't do what you said or
even "twitter:@user" and just have it be a User ID. That's completely covered
by 4880.
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.
Okay, so that says that it could just be a User ID. Why not?
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.
Well said. That's really why things need to be in the standard. I try to
remember Jeff Schiller's comment from when he was AD that the primary purpose
of a standard is interoperability.
Today, there are a lot of ways that one can take standard parts and put them
together in reasonably obvious ways -- like my suggestion of clear signing a
text-based structure, like YAML, JSON, etc. It just works, and you can write
your own document about what the structure means.
In PGP days, we ended up doing a lot of work where we wanted to have a complex
email with embedded attachments (like pix) be encrypted and signed. The
OpenPGP/MIME documents are simple, elegant, and allow one to format the MIME in
a lot of ways. To get now-modern MUAs to reassemble the message the right way,
dropping the pictures in the text in the right places, all the parts had to be
assembled just the right way. So we documented what we'd found and used a
notation to let a key declare, "if you send me MIME this way, I can make it
look pretty." We thus didn't need to have a standards discussion, we could just
do it.
There's a lot to be said for innovating in a way that doesn't break other
people, and if it becomes popular, *then* standardize it. (And of course,
accept the cost of migrating one's things to the standard one inspired.)
Jon, Neal, thank you for your time discussing this matter!
No problem and please keep us all informed. This is interesting and cool and
it's nice that you let us know what you're up to. It sounds like you're doing
some awesome innovative things.
Jon
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp