Subject: Re: [openpgp] Registration of the 'proof' notation

From: "Neal H. Walfield" <[email-masked]>
Date: Thu, 01 Oct 2020 12:41:34 +0200

Hi Jon,

Thanks for your comments.

On Thu, 01 Oct 2020 01:14:22 +0200,
Jon Callas wrote:
> 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>.
> 
> The idea here would be that it would be like an Attribute
> Certificate, or a capability. It would permit (e.g.) a sysadmin to
> be able to say that the holder of a key is the owner of a file path
> on a server. (Vinnie wrote software for this exact case. You could
> sign in to a file server with an OpenPGP key and the ticket could
> describe what authorizations you had.)
> 
> I don't think this is exactly what you want, but it's close. An
> advantage of the ticket approach is that you don't need anyone's
> permission to do it. It could literally be a bit of defined YAML or
> JSON that you clear-sign as text, and then poof, you're done. You
> don't have to listen to any of us give helpful comments about what
> you want to do, you just do it.

Thanks for pointing this out, I was not aware of this work.  I have a
special place in my heart for object capability systems, so I was
happy to learn that some work has already been done on that in the
OpenPGP ecosystem.

I'm a bit confused, however, how PGPtickets are analogous to social
proofs.  A social proof is an identity ("my handle on this service is
X").  PGPtickets are authorizations.  When I create a social proof,
I'm not normally delegating any authority; I'm advertising an
identity.  And, an authorization in the o-cap world is normally free
of identity information (authorization-based, not identity-based,
access control is the mantra).

Thanks for any feedback.

:) Neal

---

From: Wiktor Kwapisiewicz <[email-masked]>
Date: Fri, 2 Oct 2020 14:29:51 +0200

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

---

From: Jon Callas <[email-masked]>
Date: Sat, 3 Oct 2020 15:36:22 -0700

> On Oct 1, 2020, at 3:41 AM, Neal H. Walfield <[email-masked]> wrote:
> 
> Hi Jon,
> 

One point is that they don't have to be embedded in the OpenPGP key. They're separate statements with their own syntax. Just because OpenPGP is a nice hammer doesn't mean that everything's got to be a nail. It's okay to have other hardware.

While I agree with you that these social proofs correspond reasonably well to an identifier, especially more than making them be a notation, there's no reason to jam them into even that. Wiktor has his own uses, and the fact that he's suggested an approach different to what you and I thought says to me that perhaps we don't quite get his use case.

Thus, why not just go take something and do it? Other people have done it before. When Vinnie and Tony were doing the tickets, they could have done it so that it was a notation as well. In their case, the sysadmin could have signed the actor's key with a notation, even, and had it work that way. It also makes sense to make it be a wholly separate object, purpose built to its need. Moreover, it doesn't require the likes of us to agree to it.

That's why I suggested it. Among the implementation options is for Wiktor to go off to the side and do his social proofs with another syntax. Moreover, the consumer of the proofs only has to verify the signature around the proof and then parse the proof on its own, without having to go to the trouble of parsing a whole OpenPGP key.

	Jon

---

From: Jon Callas <[email-masked]>
Date: Sat, 3 Oct 2020 16:03:14 -0700

> On Oct 2, 2020, at 5:29 AM, Wiktor Kwapisiewicz <[email-masked]> wrote:
> 
> Hi Jon,
> 

I think I see.

> "https://twitter.com/user" over a User ID that contains the same exact

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.

> 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?
> 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

---

From: Wiktor Kwapisiewicz <[email-masked]>
Date: Sun, 4 Oct 2020 21:50:19 +0200

Hi Jon,

> 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…

Thanks for the confirmation.

As for "https://twitter.com/user" vs "twitter:@user" I did lean towards
the former only due to my standards-paranoia: not to invent URI schemes
but to use ones that are already registered [0]. Of course both formats
would work just fine.

[0]: https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml

> Okay, so that says that it could just be a User ID. Why not?

In the latest design I chose notations instead of User IDs out of
practical considerations:

  - while fetching the key over WKD GnuPG will strip them,
  - they will be stripped with some keyservers like keys.openpgp.org,
  - I don't want them to be signed by others.

The last point may be something that's rather personal than technical
but having a User Attribute on my key and seeing people blinding signing
it made me think that the social proofs should be only checked against
the target social site.

In my opinion there is no benefit for others signing Twitter handles but
the social proof design doesn't depend on the place where the proof is
stored.

> 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.…

Yes, clearsigning a document with well-known format is actually a very
nice technique I've been considering for other uses (like voting or
assigning permissions etc.)

> 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, an…

I think you're referring to the
"[email-masked]=pgpmime" notation. This was the first
instance of a notation I've seen in the wild and I wondered why
notations are so grossly underused :)

> 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…

Well said. I'm pondering the feedback loop between the standards and
implementors. I've seen it first-hand while developing this little
proof-of-concept that the implementation frequently influenced the design.

> 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.

This idea is already being used by other parties to provide something
akin to profile page generated purely from the OpenPGP key in the browser:

https://keyoxide.org/9f0048ac0b23301e1f77e994909f6bd6f80f485d

What I find especially fascinating is that the OpenPGP key can be used
as a root of trust to verify other keys of the user including XMPP OMEMO
keys (that is a Signal-like protocol with forward secrecy for XMPP) or
things that are not social profiles such as Bitcoin addresses. As all of
them are URIs this is still using the same design (of course the
verification procedure varies).

> It sounds like you're doing some awesome innovative things.

Thanks Jon, I appreciate kind words especially if they come from a
renown standards expert.

Regards,
Wiktor