Re: [openpgp] Scoped trust (signatures)

Jon Callas <joncallas@icloud.com> Mon, 28 May 2018 00:45 UTC

Return-Path: <joncallas@icloud.com>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 674061204DA for <openpgp@ietfa.amsl.com>; Sun, 27 May 2018 17:45:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.711
X-Spam-Level:
X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.com
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 2-CkB590Vd6E for <openpgp@ietfa.amsl.com>; Sun, 27 May 2018 17:45:47 -0700 (PDT)
Received: from st13p27im-asmtp004.me.com (st13p27im-asmtp004.me.com [17.162.190.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13CBE12D0C3 for <openpgp@ietf.org>; Sun, 27 May 2018 17:45:47 -0700 (PDT)
Received: from process-dkim-sign-daemon.st13p27im-asmtp004.me.com by st13p27im-asmtp004.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) id <0P9E00J00XK47S00@st13p27im-asmtp004.me.com> for openpgp@ietf.org; Mon, 28 May 2018 00:44:25 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1527468265; bh=Cr69IcA0TL8UFkRa7uzGmJIzaEe8QBeL+GTFatFWPzg=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=RUWcMkXREHMORE5PmxUspV7V++Kla25PZajJRXByzhWjxIszkxzXBOKEyiCCYlWFB BnGUuA+dF+gLGvg9FCyG+wgJeIjEfR74/QvECjFCl/P8OXAZLP/jmFlUDCOV1HbDcL Vknr/TIAQdKIDilZRk+zAe/UiQfno7hQ/8dzHRPlVbwMD96qH8T2BUzNWkbp3mzKb7 KvZAlvIiMIqUftjNY2ftGKj4VGNjSB/h6qqKXfNyOoKA7Btr6q8nJ+lF/oOHiDiXS5 YHsigBAgbkEZmftAy/UW5IwHUGv26TkdiY+rFqT2f8WahsvjfleIvJuyFmRRndhtrV oFrJ/KLt4qqlg==
Received: from icloud.com ([127.0.0.1]) by st13p27im-asmtp004.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) with ESMTPSA id <0P9E008BZY1YOY10@st13p27im-asmtp004.me.com>; Mon, 28 May 2018 00:44:24 +0000 (GMT)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2018-05-27_14:,, signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1011 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1805280008
Content-type: text/plain; charset="utf-8"
MIME-version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
From: Jon Callas <joncallas@icloud.com>
In-reply-to: <39e598e1-2bc0-32c9-3489-4bb6ca2a631b@leo.gaspard.ninja>
Date: Sun, 27 May 2018 17:44:21 -0700
Cc: Jon Callas <joncallas@icloud.com>, openpgp@ietf.org
Content-transfer-encoding: quoted-printable
Message-id: <3C4F6769-2D79-469B-B7B6-01B1D02B99AA@icloud.com>
References: <39e598e1-2bc0-32c9-3489-4bb6ca2a631b@leo.gaspard.ninja>
To: Leo Gaspard <ietf=40leo.gaspard.ninja@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/d6XY1yRyPSbtsJ5qXEm2P7IzQMc>
Subject: Re: [openpgp] Scoped trust (signatures)
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 28 May 2018 00:45:50 -0000


> On May 18, 2018, at 1:26 PM, Leo Gaspard <ietf=40leo.gaspard.ninja@dmarc.ietf.org> wrote:
> 
> Hello,
> 
> I have subscribed to this list only recently (late 2016), so please
> forgive me if this has already been discussed, as I couldn't find it in
> the ML archives. I also hope I didn't miss something fundamental while
> writing down this idea.

No problem. Since I wrote that text, I can provide some color. I think gentle persons can also disagree, so I'm not saying what I think is law, merely that I wrote it, and therefore I think I can give some indication of what the group consensus meant. Group consensus is often vague, wishy-washy, etc.

> 
> As I understand it, currently, with OpenPGP, it is possible to simulate
> the Certificate Authority model:
> * The clients wishing to use it assign full trust to the root CAs
> * Root CAs use 255-trust trust signatures for subordinate CAs
> * Subordinate CAs sign the verified OpenPGP keys

That's pretty much the intent. The idea is that you should be able to mark a key as being something like a CA.

Two important things to remember about OpenPGP philosophy are: (1) OpenPGP democratizes being a CA. All keys can sign, endorse, etc. and (2) Trust is also democratized in that trust is in the eye of the beholder. Also note that in many cases the beholder might be an organization. That organization might push its policy to its members, and be polite enough to scope that trust only to keys operating in that environment.

> 
> I think it would be great to also be able to simulate the DNSSEC model,
> so that as a client I would be able to say “I trust [this key] to make
> statements about [this set of keys].” I see it as, is in a way, a
> logical follow-up of Web Key Directory.

I suppose. 

> 
> As I understand it, RFC4880 already has a provision for such a model,
> with §5.2.3.14 _Regular Expression_.
> 
> However, there is from my reading an issue with (the wording of) this
> section: it only restricts one-level trust signatures. In other words,
> from my reading, if:
> * User U trusts(255, r".*<.*@ca-a.com>") "A <root@ca-a.com>"
> * root@ca-a.com trusts(255, r".*<.*@example.org>") "B <b@ca-a.com>"
> * b@ca-a.com signs "C <c@example.org>"
> 
> Then, from A's point of view:
> * root@ca-a.com has trust(255, r".*<.*@ca-a.com>")
> * b@ca-a.com has trust(254, r".*<.*@example.org>")
> * c@example.org is valid
> 
> However, I don't think c@example.org should be valid, as user U only
> wanted to give permissions on r".*<.*@ca-a.com>" to root@ca-a.com. So I
> think all regular expressions in the trust chain should have to match in
> order to not be rejected -- in a similar fashion as the DNSSEC model.
> 
> So the “wrong” line here would be b@ca-a.com's trust, which should be
> calculated as trust(254, r".*<.*@example.org>" AND r".*<.*@ca-a.com>").

Well, I think I disagree. I think that if I am trusting ca-a.com with scope at the root, subordinates cannot widen that scope. Scope is supposed to be narrowed only through subordinates. If that weren't true, then your subordinate that issues trust for example.org could just as easily issue it for ".*" and now all of a sudden the subordinate gets to sign everything, and that's the opposite of what scoping even means.

> 
> Another issue of this scheme, obviously, is that noone “in the wild”
> currently uses regular expression subpackets (that I know of). However,
> I hope this could change, were this change to allow creation of scoped
> CAs, that would interact nicely with WKD.

Yup, it's a little-used feature. So little used that I don't know of anyone using it, either.

> 
> For instance, a mail provider could set up such a “CA”, that would
> automatically sign all keys that would pass the WKD test, and for which
> the UID would be confirmed as valid by the internal database. Then,
> users could start trusting such mail-provider-provided CAs, for
> additional validation of the user ID (in addition to the localpart
> already “validated” by HTTPS), while still restricting them for only
> being valid for the domain(s) they own. For easy discovery,
> mail-provider-provided CAs could have a path at
> .well-known/openpgpkey/mail-provider-key, and the user could decide to
> add some trust to this CA.

I believe that is pretty much the intended use case. The idea is that if I'm a member of an club (or company, etc.), then that club can bring in new members and I don't have to go to the trouble of trusting their keys, it happens for me.

In the naive trust model, I can say, "Whatever Alice signs is okay with me." This is obviously giving Alice a lot of power.

The trust-extension feature says, "Alice can deputize others to sign for her" and also permits those deputies to have deputies to some specified depth. This is obviously extending Alice's power in huge ways. Even with a level of only one, the only limit on Alice's power is that she has to deputize new deputies, but she has unbounded power to deputize.

The scoping feature is there so you can say, "Whatever Alice signs about our club is okay with me." It limits Alice's power. This is a reasonable and arguably important thing, especially if you're going to let Alice deputize people who can deputize people. It's so that the second assistant to the deputy undersecretary of the membership committee can't just go sign anything and I'll believe it.

> 
> The aim of this proposal being to make OpenPGP easier to use by
> introducing ways to reduce the work required for setting up a secure
> channel, while leaving control over these to the user (or to the
> implementer, for opinionated implementations)

Sure! If there's anything OpenPGP needs it's more ease of use and work reduction.

> 
> What do you think about this?

I am not sure what you're really proposing, though. I think you might be proposing the very thing I described, but I'm not sure.


If that's not what I described, then do me a favor and describe the problem you want solved.

	Jon

> 
> Cheers,
> Leo
> 
> _______________________________________________
> openpgp mailing list
> openpgp@ietf.org
> https://www.ietf.org/mailman/listinfo/openpgp