[openpgp] Supporting services beyond email as uid
kellerfuchs <kellerfuchs@hashbang.sh> Sun, 24 January 2016 19:38 UTC
Return-Path: <kellerfuchs@hashbang.sh>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 739E91ACEA9 for <openpgp@ietfa.amsl.com>; Sun, 24 Jan 2016 11:38:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.399
X-Spam-Level: *
X-Spam-Status: No, score=1.399 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_72=0.6, RP_MATCHES_RCVD=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cNbLegAmQpTW for <openpgp@ietfa.amsl.com>; Sun, 24 Jan 2016 11:38:49 -0800 (PST)
Received: from mail.hashbang.sh (mail.hashbang.sh [104.236.230.244]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 022251ACEA6 for <openpgp@ietf.org>; Sun, 24 Jan 2016 11:38:48 -0800 (PST)
Received: from to1.hashbang.sh (to1.hashbang.sh [104.245.37.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hashbang.sh (Postfix) with ESMTPS id B449337C39 for <openpgp@ietf.org>; Sun, 24 Jan 2016 19:38:47 +0000 (UTC)
Received: by to1.hashbang.sh (Postfix, from userid 3412) id 0D9F5E13B3; Sun, 24 Jan 2016 19:39:02 +0000 (UTC)
Date: Sun, 24 Jan 2016 19:39:01 +0000
From: kellerfuchs <kellerfuchs@hashbang.sh>
To: openpgp@ietf.org
Message-ID: <20160124193901.GA28994@hashbang.sh>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/openpgp/HcR2tUSEOfOVNTE1pdScSGo5FHc>
Subject: [openpgp] Supporting services beyond email as uid
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 24 Jan 2016 19:50:35 -0000
Hello, I couldn't help but notice a usecase that is gaining interest fast, yet seems to have been conspicuously absent from the WG's discussions: tying not an email address, but another kind of account (typically, so-called “social media”) to the OpenPGP key. I believe this is relevant for two main reasons: - enabling authenticated/encrypted communication over those services; this is the most immediate use, but perhaps not the most relevant; - enabling people to establish secure communication channels with other users of such service; in that case, the identity they want to link to a key is not a (name, email) pair but a (username, service) pair. A popular implementation of this is keybase.io, which make users publish a signed, parseable claim of ownership of the account in some location where only the account holder (and the service provider) can publish. Unfortunately, keybase.io does so by acting as a central database[0] where users can publish URLs to the proofs of ownership. However, I believe it should be possible to support that usecase without relying on a third-party database, by extending the notion of uid beyond mail addresses. I would feel natural to use URIs there (or a subset thereof), as they work for designating a variety of things a user might wish to associate with their identity. This makes verifying the ownership of an uid harder: in the case of email, it is done safely (by tools such as `caff`) by sending the signature as an encrypted email. In our case, the 'acct' scheme is only an abstract identifier, and does not specify how to interact with the service. It would be possible to specify the use of a given protocol, such as Web Finger [RFC 7033], to obtain the proof of ownership for the account. On the other hand, that solution would require active cooperation from the service, whereas the current, adhoc solution does not. Moreover, certain services have strong size limitations, which would not allow publishing complete signed proofs of ownership (assuming we do not require the service to implement Web Finger or somesuch). That can be handled by storing only a hash of the proof on the service, and either storing the proof as a key packet or storing a URL where the proof can be fetched. In both cases, I do not believe it can be done for the current OpenPGP spec. I hope this mail was readable, I'm afraid it has quite a bit of content. Please take it as a request to discuss whether broadening the notion of uids would be relevant, what would be the “right” thing to use as a uid and how to actually check the validity of an uid. Best regards, Keller Fuchs [0]: I am aware that keybase now publishes their database in the Bitcoin blockchain. keybase still acts as the single publisher for it, so this doesn't address the issues raised here.