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

Jon Callas <> Sat, 03 October 2020 23:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 045353A097D for <>; Sat, 3 Oct 2020 16:03:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4HDA6tOzNP4M for <>; Sat, 3 Oct 2020 16:03:18 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 99A013A0972 for <>; Sat, 3 Oct 2020 16:03:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=1a1hai; t=1601766197; bh=EKaBvo3WCiyvAR260GQwyImdRmdo/d7TBBfo6583DdE=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=MjSAlTiH0jTg1TI/kyZnOwTeoPdP8avvgrxh26lGamOtQ88cumnthyQTh7MocKngY +YaoZx6F6QRj6RJIdu3yRiM81naz47sUY5lR6ljbQkK5ufi5Vb3rCbmVbcOKFE24Al Mpp6cr2HTJHr47ZpMiCkTJrq5itKppzpOcyBVMqBd4NXgX1Jo0Fp/sqF3D/7av4Qej VEVTZLAqY5YEZO3HU2tOWL/0nPU5f9VP16rloDprNzeTEfEEfm6aWbU+xkfA83/qjJ G6gJGmPVlgu/EujWi4FjzWnR7xWbxPjP/Qhm1ybRKtBy8aTxYJOjYvJwetUUDgMwaz oLvcd88q1uTWA==
Received: from [] ( []) by (Postfix) with ESMTPSA id 67DEA8A0076; Sat, 3 Oct 2020 23:03:15 +0000 (UTC)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Jon Callas <>
In-Reply-To: <>
Date: Sat, 3 Oct 2020 16:03:14 -0700
Cc: Jon Callas <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Wiktor Kwapisiewicz <>
X-Mailer: Apple Mail (2.3608.
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-10-03_17:2020-10-02, 2020-10-03 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2006250000 definitions=main-2010030196
Archived-At: <>
Subject: Re: [openpgp] Registration of the 'proof' notation
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 03 Oct 2020 23:03:20 -0000

> On Oct 2, 2020, at 5:29 AM, Wiktor Kwapisiewicz <> 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]:
> 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
> "" 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 <>. 
> 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 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.