Re: [Trans] Another Question about the PRIVATE option (Ticket #1)
Daniel Kahn Gillmor <dkg@fifthhorseman.net> Tue, 18 March 2014 16:07 UTC
Return-Path: <dkg@fifthhorseman.net>
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 060FB1A040A for <trans@ietfa.amsl.com>; Tue, 18 Mar 2014 09:07:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
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 PPxnkGztU8au for <trans@ietfa.amsl.com>; Tue, 18 Mar 2014 09:07:20 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 029D81A02F5 for <trans@ietf.org>; Tue, 18 Mar 2014 09:07:20 -0700 (PDT)
Received: from [10.70.10.55] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 20539F984; Tue, 18 Mar 2014 12:07:10 -0400 (EDT)
Message-ID: <53286F24.5080407@fifthhorseman.net>
Date: Tue, 18 Mar 2014 12:07:00 -0400
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.2.0
MIME-Version: 1.0
To: Phillip Hallam-Baker <hallam@gmail.com>, Ben Laurie <benl@google.com>
References: <544B0DD62A64C1448B2DA253C011414607C70EAF9E@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <531EE6A6.7000007@comodo.com> <544B0DD62A64C1448B2DA253C011414607C77BCCBE@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <53204F9E.7000507@comodo.com> <CALzYgEf-=7+XpBYgV-+0ijq-whRsn9gam7AELERZfof-TJ5uEg@mail.gmail.com> <53217E29.7040004@comodo.com> <544B0DD62A64C1448B2DA253C011414607C7DAA2CF@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <CABrd9SQONqLvemGtfy6WpyVQEN5Wuq8otFpjA2nKTirF6Z_5Qw@mail.gmail.com> <CAMm+Lwhy+ArnJhY-SjkbPtbZgPfDyZ4LkQ82mNJrvSO7jZr3Bw@mail.gmail.com>
In-Reply-To: <CAMm+Lwhy+ArnJhY-SjkbPtbZgPfDyZ4LkQ82mNJrvSO7jZr3Bw@mail.gmail.com>
X-Enigmail-Version: 1.6
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="BADIcxBrKwcSdQwGUVRTjl6h14eWV8GTO"
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/7DXQUoVwnscZ8qtuRfi7FmFo6Io
Cc: "trans@ietf.org" <trans@ietf.org>, Rick Andrews <Rick_Andrews@symantec.com>
Subject: Re: [Trans] Another Question about the PRIVATE option (Ticket #1)
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list <trans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trans>, <mailto:trans-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/trans/>
List-Post: <mailto:trans@ietf.org>
List-Help: <mailto:trans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trans>, <mailto:trans-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Mar 2014 16:07:23 -0000
On 03/18/2014 08:02 AM, Phillip Hallam-Baker wrote: > Unfortunately it is focused mostly on fixing cookies which is trying to fix > stupid which is never going to produce a sensible result. But there is > already a zone prefix list used for issue of wildcard certs. > > The problem of <private>.<domain>.foo.com looks to me to be the same as the > problem of *.<domain>.foo.com. > > *.uk would be a bad thing... the CABForum guidelines split "registry-controlled" zones from the next level of labels using http://publicsuffix.org/, though they acknowledge that this is not a scalable long-term solution and something else needs to be done eventually (see section 11.1.3): https://cabforum.org/wp-content/uploads/Baseline_Requirements_V1_1_6.pdf This idea of a "natural split" between public registries and private zones is appealing, because of the tradeoffs between auditability and resistance to zone enumeration. The entities closer to the root of the hierarchy need to be audited, since they have power over the leaves; the entities nearer to the leaves have less power, little or no responsibility delegated to them from third-parties, and possibly more legitimate need for hiding individual zone entries or avoiding enumeration. So how would this work in CT? if i'm an admin for the example.com zone, i'd want to monitor the logs for any entries matching: a) <PRIVATE>.com b) example.com c) *.example.com d) <PRIVATE>.example.com if any of b, c, or d are observed which were not issued from within my authority, i now have proof of misissuance, and can take the issuing CA to task. But if (a) is observed from monitoring the log, what can the site operator do? Do we declare that (a) is indication of log misbehavior? if so, then we need to also consider that CT-aware TLS clients need to be able to identify SCTs of the (a) form and report them publicly somehow, so that log misbehavior is known. presumably, this would be the same mechanism used to report an SCT that didn't show up within the MMD, right? is there a reporting mechanism defined? --dkg
- [Trans] Question about PRIVATE option (Ticket #1) Rick Andrews
- Re: [Trans] Question about PRIVATE option (Ticket… Rob Stradling
- Re: [Trans] Question about PRIVATE option (Ticket… Rick Andrews
- Re: [Trans] Question about PRIVATE option (Ticket… Rob Stradling
- Re: [Trans] Question about PRIVATE option (Ticket… Eran Messeri
- Re: [Trans] Question about PRIVATE option (Ticket… Rob Stradling
- [Trans] Another Question about the PRIVATE option… Rick Andrews
- Re: [Trans] Another Question about the PRIVATE op… Ben Laurie
- Re: [Trans] Another Question about the PRIVATE op… Rob Stradling
- Re: [Trans] Another Question about the PRIVATE op… Phillip Hallam-Baker
- Re: [Trans] Another Question about the PRIVATE op… Daniel Kahn Gillmor
- Re: [Trans] Another Question about the PRIVATE op… Ben Laurie
- Re: [Trans] Another Question about the PRIVATE op… Daniel Kahn Gillmor
- Re: [Trans] Another Question about the PRIVATE op… Ben Laurie
- Re: [Trans] Another Question about the PRIVATE op… Ben Laurie