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

"Neal H. Walfield" <> Wed, 30 September 2020 13:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CC1613A0967 for <>; Wed, 30 Sep 2020 06:23:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id K0qFmf-oq7mM for <>; Wed, 30 Sep 2020 06:23:21 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 061593A0966 for <>; Wed, 30 Sep 2020 06:23:20 -0700 (PDT)
Received: from ([] by with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from <>) id 1kNc4k-00046J-0x; Wed, 30 Sep 2020 13:23:18 +0000
Received: from ([] by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1kNc4j-0003X5-8k; Wed, 30 Sep 2020 15:23:17 +0200
Date: Wed, 30 Sep 2020 15:23:17 +0200
Message-ID: <>
From: "Neal H. Walfield" <>
To: Wiktor Kwapisiewicz <>
Cc: "" <>
In-Reply-To: <>
References: <> <> <>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/26 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
X-SA-Exim-Scanned: No (on; SAEximRunCond expanded to false
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: Wed, 30 Sep 2020 13:23:23 -0000

On Wed, 30 Sep 2020 15:04:34 +0200,
Wiktor Kwapisiewicz wrote:
> 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:

Thanks for pointing to that discussion.

Vincent also defends his design there and I find his arguments
convincing.  In particular, we should try and make the parsers
simpler by using UAs to mark items as exactly what they are.

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

Would you also argue that it is not up to me to decide if an email is
valid for a given key, but up to the email server?  I wouldn't and I
don't see the fundamental difference.

> > When Alice certifies that "Bob <>" 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.

Clearly(tm).  :D.

> As for the OpenKeychain example please note that the stable version
> removed support for their linked identities [0].
> [0]:

Thanks for pointing this out.

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

This is a bit unfair.  WKD and verifying keyservers also strip User
IDs left and right, and for good reasons: they only return what they
can authenticate.

FWIW, I think a WKD ought to be allowed to return more, and the WoT
should be used for authenticating bindings, but that is a different

As for Hagrid, it could be modified to return UAs that can be
authenticated similar to how it authenticates email addresses (e.g.,
checking proofs or, say, sending a DM on twitter and requiring a

Sure, modifying software is work.  But I disagree with your claim that
it is a "massive implementation effort".  And, I think the work would
move the ecosystem forward in a positive way.

:) Neal