From nobody Mon Apr 6 11:20:07 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFD731A908E for ; Mon, 6 Apr 2015 11:20:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.322 X-Spam-Level: * X-Spam-Status: No, score=1.322 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-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 P7Cqt1M_jXjU for ; Mon, 6 Apr 2015 11:20:02 -0700 (PDT) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (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 990F81A9095 for ; Mon, 6 Apr 2015 11:19:31 -0700 (PDT) Received: by ignm3 with SMTP id m3so24088958ign.0 for ; Mon, 06 Apr 2015 11:19:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=se1YAezjpKWMn5aKt3Q2OWeAy396BIMKpBgoWnIUlIw=; b=J1rlxUM/2eKk+U+PzFNYkIGcgmKblKJAEqyBmXsGBLqSekg69DeY8pXhnRLL8+2nPK PJz11OXuy7mKwnV3PhYQLr0/FKdrW0Xw9IcMyEq1fJBvoJZGxThwePW7frc2kJobl48r APdSEPTInjdG3guL/Pk7p7HWbJqG7/b7J11aM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=se1YAezjpKWMn5aKt3Q2OWeAy396BIMKpBgoWnIUlIw=; b=Dvi1FYtty9uwSdotzGqf8R79zd9JVGJ5te6P3r1rdnpLzlIjkofKzLrDA3+PX2J+p9 VRnUmr4iBsLQaRnVvHq6IeK7LfZL9ceF4PRujm3L5CtEwbXY+Ajoal822A4ygSeAv/UE +BlccvY7UoaZL2MEg0gAuBt+2KvBTxAILmbbXomkzd3aVMoKa5oG94LmDJBgVkw0opzo Oo8N6NAjK9vi/pq/KpL/sQ4rQXzaxlK2rVohLC1i+OAp+oigQY97wrJdmYic8DZ5Fd51 JQwivr218kDZ618igh5h/bbk3nsnSmKMAQ1shWuJ4xnaR2me6G43z02rTtVE07WG2BBH ziQw== X-Gm-Message-State: ALoCoQmYetrtuGXQKTYa0N2KCmXm2LNy3LMSnDSaCKrZZrEaMWD0jRXNXjGJ2aPbQPVIj9PVK76R MIME-Version: 1.0 X-Received: by 10.50.8.6 with SMTP id n6mr21078988iga.12.1428344371018; Mon, 06 Apr 2015 11:19:31 -0700 (PDT) Received: by 10.50.57.233 with HTTP; Mon, 6 Apr 2015 11:19:30 -0700 (PDT) In-Reply-To: References: <55104501.3070906@KingsMountain.com> Date: Mon, 6 Apr 2015 14:19:30 -0400 Message-ID: From: Casey Deccio To: "dbound@ietf.org" Content-Type: multipart/alternative; boundary=089e0115f6dada19d60513125671 Archived-At: Subject: Re: [dbound] comments on draft-deccio-domain-name-relationships-00 X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 18:20:04 -0000 --089e0115f6dada19d60513125671 Content-Type: text/plain; charset=UTF-8 On Tue, Mar 24, 2015 at 4:00 PM, Jothan Frakes wrote: > One observation that I have witnessed is that "Public / Private" has some > different context, depending upon the reader, and the use and application > of these terms. I suspect that these contexts are blurring and confusing > things a tad. > > There is a concept of those that have been delegated directly from > IANA/ICANN, and those that jump in at some point within that which are not > necessarily 'registries' (some are, some aren't) being Public and Private. > There was an attempt to describe the boundaries attached to these names generically in the document as "first-level" and "lower-level" boundaries--not to imply their differences or the impact of their differences, but only to indicate that they existed. Admittedly the model needs tweaking to more accurately define these--from this standpoint. > I think Casey and John have done a fair job of summarizing some of the > contexts of Public/Private within Casey's draft, yet one thing that is > possibly blurred between this and the IANA/ICANN direct relationships is > the concept of administrative transition. > > I would not encourage that the PSL definitions of Public/Private sections > or comments about entries from within the PSL .dat file be used as any > frame of reference other than convenience. The entries as submitted by > respective administrators should be used for context of how these > administrators wanted cookies to behave. That's essentially it. These are > two separate things, regardless of where they are in the file. > There are two points to the document: historical context, including description of the PSL and known current usage; and concepts for identifying policy relationships between domain names. It does not attempt to endorse PSL use for one purpose or other, but it does speak of the concepts (i.e., so-called "public"/"private" suffixes) introduced by the PSL, as well a PSL-like registry to implement those concepts, as part of a solution. However, it explicitly mentions that neither the PSL nor a PSL-like registry is sufficient for a complete solution to the problem. > The cookie realm is different than the SSL Cert realm, is different from > the email realm, is different than the _____ realm. > > Does the PSL get used for other things - absolutely. And each potentially > has its own concept of 'Public'/'Private'. > If there is a solution involving a PSL-like registry/oracle, then either the registry must distinguish between uses, or it must be conservative (e.g., default). I personally think the latter is the right decision (i.e., for something to fill the role of public/private registry, it should be on a per-name basis). The draft mentions other types of solutions (e.g., per-name, in the DNS) that can be used to identify policy relationships/boundaries more specifically. > ... > The core focus of PSL is, from its origin, one of creating a solution to > aid in securing cookies from bleeding out to the wrong places. The > derivative uses that have evolved since its creation have been amazing and > very indicative of a need for solution space, such as search engines, > browser 'omnibox' behavior, anti-spam, and the numerous development > community. > Agreed. Candidly, (and I realize this additional and important color does not > necessarily put these terms into clean buckets) the concept of > public/private scope will absolutely change from circumstance of > application/use and depend upon that scope - these are different in DNS > than in EMAIL than in Cookies and varieties of Web activity. Other > examples of derivative uses include UX/UI (form validation being an > example, wanting to exclude invalid entries), Security / Log Forensics > (need to have a clear indicia of subdomain vs domain ownership breakpoints, > to query a whois server, for example). Each will have their own context > and scope for 'public' or 'private'. > I don't believe that (that each will have their own context and scope for public or private) is the case--if the scope is truly "public". Neither am I insinuating that the current PSL is 100% accurate based on the described notion of public/private. > I would encourage that where possible, there can be a scope included in > DBOUND efforts which contextually identify the usage, akin to how MX vs A > records work in DNS. > This is among the solution paradigms described in section 6. > I'll repeat something that is frequently said within the community of > developers who like myself help maintain the PSL, PSL exists only because > nothing else did, and it is the least awful solution out there. > That might be true. But don't fault the concepts that have been brought to light with the PSL because of the improper/overextended application of the PSL. In the context of our DBOUND efforts, there would be a grateful transition > to something that does what it does or better, but it is likely that > something that does not, shall not be attractive enough to the base of > developers, libraries, and integrators to make the effort to pivot to > something else. > The document considers at a high level per-domain name policy relationship signaling, as well as supplementary (not stand-alone) registry based solutions. It attempts to be objective in identifying pros and cons of these solution paradigms, without actually endorsing anything. Regards, Casey --089e0115f6dada19d60513125671 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Mar 24, 2015 at 4:00 PM, Jothan Frakes <jothan@= jothan.com> wrote:
One observ= ation that I have witnessed is that "Public / Private" has some d= ifferent context, depending upon the reader, and the use and application of= these terms.=C2=A0 I suspect that these contexts are blurring and confusin= g things a tad.

There is a concept of those that have been dele= gated directly from IANA/ICANN, and those that jump in at some point within= that which are not necessarily 'registries' (some are, some aren&#= 39;t) being Public and Private.

There was an attempt to describe the boundaries attached to these names ge= nerically in the document as "first-level" and "lower-level&= quot; boundaries--not to imply their differences or the impact of their dif= ferences, but only to indicate that they existed.=C2=A0 Admittedly the mode= l needs tweaking to more accurately define these--from this standpoint.
=
=C2=A0
I think Casey and John have done a fair job of summarizing some of the con= texts of Public/Private within Casey's draft, yet one thing that is pos= sibly blurred between this and the IANA/ICANN direct relationships is the c= oncept of administrative transition.

I would not e= ncourage that the PSL definitions of Public/Private sections or comments ab= out entries from within the PSL .dat file be used as any frame of reference= other than convenience.=C2=A0 The entries as submitted by respective admin= istrators should be used for context of how these administrators wanted coo= kies to behave.=C2=A0 That's essentially it.=C2=A0 These are two separa= te things, regardless of where they are in the file.

There are two points to the document: historical cont= ext, including description of the PSL and known current usage; and concepts= for identifying policy relationships between domain names.=C2=A0 It does n= ot attempt to endorse PSL use for one purpose or other, but it does speak o= f the concepts (i.e., so-called "public"/"private" suff= ixes) introduced by the PSL, as well a PSL-like registry to implement those= concepts, as part of a solution.=C2=A0 However, it explicitly mentions tha= t neither the PSL nor a PSL-like registry is sufficient for a complete solu= tion to the problem.
=C2=A0
The cookie realm is different than the SSL Cert re= alm, is different from the email realm, is different than the _____ realm.<= /div>

Does the PSL get used for other things - absolutel= y.=C2=A0 And each potentially has its own concept of 'Public'/'= Private'.

If there is a sol= ution involving a PSL-like registry/oracle, then either the registry must d= istinguish between uses, or it must be conservative (e.g., default).=C2=A0 = I personally think the latter is the right decision (i.e., for something to= fill the role of public/private registry, it should be on a per-name basis= ).=C2=A0 The draft mentions other types of solutions (e.g., per-name, in th= e DNS) that can be used to identify policy relationships/boundaries more sp= ecifically.
=C2=A0
...
The core focus of PSL is, from its orig= in, one of creating a solution to aid in securing cookies from bleeding out= to the wrong places.=C2=A0 The derivative uses that have evolved since its= creation have been amazing and very indicative of a need for solution spac= e, such as search engines, browser 'omnibox' behavior, anti-spam, a= nd the numerous development community. =C2=A0

=C2=A0Agreed.

Candidly, (and I realize= this additional and important color does not necessarily put these terms i= nto clean buckets) the concept of public/private scope will absolutely chan= ge from circumstance of application/use and depend upon that scope - these = are different in DNS than in EMAIL than in Cookies and varieties of Web act= ivity.=C2=A0 Other examples of derivative uses include UX/UI (form validati= on being an example, wanting to exclude invalid entries), Security / Log Fo= rensics (need to have a clear indicia of subdomain vs domain ownership brea= kpoints, to query a whois server, for example).=C2=A0 Each will have their = own context and scope for 'public' or 'private'.

I don't believe tha= t (that each will have their own context and scope for public or private) i= s the case--if the scope is truly "public".=C2=A0 Neither am I in= sinuating that the current PSL is 100% accurate based on the described noti= on of public/private.
=C2=A0
I would encourage that where possible, th= ere can be a scope included in DBOUND efforts which contextually identify t= he usage, akin to how MX vs A records work in DNS.
<= /div>

This is among the solution paradigms = described in section 6.
=C2=A0
I'll repeat something that is fr= equently said within the community of developers who like myself help maint= ain the PSL, PSL exists only because nothing else did, and it is the least = awful solution out there. =C2=A0
=

That might be true. But don't fault the concepts th= at have been brought to light with the PSL because of the improper/overexte= nded application of the PSL.

In the context of our DBOUND efforts, th= ere would be a grateful transition to something that does what it does or b= etter, but it is likely that something that does not, shall not be attracti= ve enough to the base of developers, libraries, and integrators to make the= effort to pivot to something else.

The document considers at a high level per-domai= n name policy relationship signaling, as well as supplementary (not stand-a= lone) registry based solutions.=C2=A0 It attempts to be objective in identi= fying pros and cons of these solution paradigms, without actually endorsing= anything.

Regards,
C= asey
--089e0115f6dada19d60513125671-- From nobody Mon Apr 6 15:02:55 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43CA81A8968 for ; Mon, 6 Apr 2015 15:02:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001] 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 EfjcBK_hVUja for ; Mon, 6 Apr 2015 15:02:52 -0700 (PDT) Received: from mx2.yitter.info (mx2.yitter.info [IPv6:2600:3c03::f03c:91ff:fedf:cfab]) by ietfa.amsl.com (Postfix) with ESMTP id 6957B1A895B for ; Mon, 6 Apr 2015 15:02:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id 3295E1062C for ; Mon, 6 Apr 2015 22:02:51 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G8dfoeCwlx0E for ; Mon, 6 Apr 2015 22:02:50 +0000 (UTC) Received: from mx2.yitter.info (c-50-169-68-91.hsd1.nh.comcast.net [50.169.68.91]) by mx2.yitter.info (Postfix) with ESMTPSA id 48E8E10602 for ; Mon, 6 Apr 2015 22:02:50 +0000 (UTC) Date: Mon, 6 Apr 2015 18:02:48 -0400 From: Andrew Sullivan To: dbound@ietf.org Message-ID: <20150406220248.GR24862@mx2.yitter.info> References: <55104501.3070906@KingsMountain.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dbound] comments on draft-deccio-domain-name-relationships-00 X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 22:02:54 -0000 On Mon, Apr 06, 2015 at 02:19:30PM -0400, Casey Deccio wrote: > to endorse PSL use for one purpose or other, but it does speak of the > concepts (i.e., so-called "public"/"private" suffixes) introduced by the > PSL, as well a PSL-like registry to implement those concepts, as part of a > solution. I am not even a little bit convinced that the distinction is part of any solution. It seems to me that it is a distinction that obscures at least as much as it clarifies, and it is the source of much confusion. I think outlining how we got the distinction and so on might help for historical reasons, but I think the distinction will do more harm than good in figuring out how to proceed. > I don't believe that (that each will have their own context and scope for > public or private) is the case--if the scope is truly "public". But this is actually part of the problem: the so-called public suffixes are often _not_ truly public, even though in many circumstances we want to treat them as such. If you need additional gradations, then the public/private boundary starts to blur, and pretty soon you have a bunch of different categories. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Mon Apr 6 15:28:24 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDF1E1A870F for ; Mon, 6 Apr 2015 15:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-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 PPkLA8SA--GH for ; Mon, 6 Apr 2015 15:28:21 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (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 95EA41A870E for ; Mon, 6 Apr 2015 15:28:21 -0700 (PDT) Received: by iebrs15 with SMTP id rs15so32551873ieb.3 for ; Mon, 06 Apr 2015 15:28:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6e9XzPhaZKTjQWATm+vh/t3As9Fu8jLXV5N3XGztbzg=; b=QBWu6t8ymdeaHhPu3ojTT9JKIPtpM81Un4CYf3MAjSnN7gYXxmviI7UTlGM5YXn06/ wmuqqiCsky/S/5+aBkW9b9rE0zFjmdCLzVg78Qf9teB7j7Qni/wTFCpdD81/KJUzsB+d wL2Hm3jfY9r+ySLMax0FAonnyUfkA6zxBTRhw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=6e9XzPhaZKTjQWATm+vh/t3As9Fu8jLXV5N3XGztbzg=; b=S6dCtOzdFcXMgWZDf14vHDlXznUttgmFCxfvlEoQjdAAF/PK7qhbc2f5jiF0Q/H5Ey 3s3hR318s5kiU9eMc9Ofi4UycF/maXzvgTsew0WkMxQ2ZmEWySlFmWKd2DcEwepqajet 43WliKjqLUlfLeiIOLXV9i90u0uBRqo5bwBAmLqOlh+iOQY0OUfvi6LTCLJNvO22Faez pda46JwyhLyt9hRo+RwFbFU4hDnlR2Bnh1YefP/nF+ljYc0CNWRcx4NjJ17lGu1OsE7d mgAjLHhipbTPQ6IrNzRBAjPs+MFZIvH8quri/njbH7LpB8bT4oM+cr905XcF4irjspLc ANYw== X-Gm-Message-State: ALoCoQm2Ikv6TF5B0nxh9oBOhhfa2QTztY+CnMrTiSzvq0o8cl0x5YJH/RH4vkDa/SoRQCIH/9TB MIME-Version: 1.0 X-Received: by 10.42.10.198 with SMTP id r6mr17072481icr.10.1428359301051; Mon, 06 Apr 2015 15:28:21 -0700 (PDT) Received: by 10.50.57.233 with HTTP; Mon, 6 Apr 2015 15:28:20 -0700 (PDT) In-Reply-To: <20150406220248.GR24862@mx2.yitter.info> References: <55104501.3070906@KingsMountain.com> <20150406220248.GR24862@mx2.yitter.info> Date: Mon, 6 Apr 2015 18:28:20 -0400 Message-ID: From: Casey Deccio To: Andrew Sullivan Content-Type: multipart/alternative; boundary=20cf30266e40c04e40051315d09e Archived-At: Cc: "dbound@ietf.org" Subject: Re: [dbound] comments on draft-deccio-domain-name-relationships-00 X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 22:28:22 -0000 --20cf30266e40c04e40051315d09e Content-Type: text/plain; charset=UTF-8 On Mon, Apr 6, 2015 at 6:02 PM, Andrew Sullivan wrote: > On Mon, Apr 06, 2015 at 02:19:30PM -0400, Casey Deccio wrote: > > > to endorse PSL use for one purpose or other, but it does speak of the > > concepts (i.e., so-called "public"/"private" suffixes) introduced by the > > PSL, as well a PSL-like registry to implement those concepts, as part of > a > > solution. > > I am not even a little bit convinced that the distinction is part of > any solution. Are you saying that there is no solution that can effectively use a public/private distinction of names to determine whether or not there is some sort of policy relationship between them? Casey --20cf30266e40c04e40051315d09e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Apr 6, 2015 at 6:02 PM, Andrew Sullivan <aj= s@anvilwalrusden.com> wrote:
On Mon, Apr 06, 2015 at = 02:19:30PM -0400, Casey Deccio wrote:

> to endorse PSL use for one purpose or other, but it does speak of the<= br> > concepts (i.e., so-called "public"/"private" suffi= xes) introduced by the
> PSL, as well a PSL-like registry to implement those concepts, as part = of a
> solution.

I am not even a little bit convinced that the distinction is part of=
any solution.

Are you saying that there is no so= lution that can effectively use a public/private distinction of names to de= termine whether or not there is some sort of policy relationship between th= em?

Casey
--20cf30266e40c04e40051315d09e-- From nobody Mon Apr 6 15:33:54 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D71751A909E for ; Mon, 6 Apr 2015 15:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-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 M3l2dyjdX42w for ; Mon, 6 Apr 2015 15:33:52 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (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 AE4751A906F for ; Mon, 6 Apr 2015 15:33:52 -0700 (PDT) Received: by iebrs15 with SMTP id rs15so32635760ieb.3 for ; Mon, 06 Apr 2015 15:33:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bmK9Y/VLK28W9jtdv64lfL2uOpy46j2lvUko9jXilUM=; b=II5sfpAOpoWvvNVI2QZPraPqgZwAIOfTLz5T0NdTf7MPyj1kmA9WcMiY1+XqqHkT+0 uWXEr2lkiCUL+vChYETmhXCHHVCVHrzLYa7SIV1evNiBDpZy3LwXAjfPMJ/OnL4ypSh6 XcJQUMyjKgCqBk3G5zV4z60CVFifUjP/bG/I4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=bmK9Y/VLK28W9jtdv64lfL2uOpy46j2lvUko9jXilUM=; b=S08aZYyJfg+MKSdTsoDtvqnEYwdLhDUS576GXTzOTcymWuNrqOANhYnRHoaaeQP6ac 2vTaFBHVWc6GA57HNu4E+ZM78qQfpXfQf6Vu9YHuWU/lrQb+sCFjQ3pDbZB7MCFaytQj 2/XsRlQSaOnWotCw5IJSo0QzWhLmSstzCv4OOyeB5dDV1YRVdG1EjdRPefBdxL5enoUR eLILaZW5UGmNxX2+hfV61k+l77jZglQkU7oRzxB3ZUU8Rkzy8Xwgsu7YoFfhpSzcUxpZ 27Hz4m82t9g3QktrIWZsUmTNw8Z9akaC2wIf6ev5hcVRBdPiOn1ee0zZjeEuFC0AfCZS Ketg== X-Gm-Message-State: ALoCoQmqliZt0wXflf7rQ4wyv9COKpnamA4C3MOaxMsXDVVN3ae69CnKaYI9xSiWpVZqOo32aml1 MIME-Version: 1.0 X-Received: by 10.42.204.14 with SMTP id fk14mr22005309icb.96.1428359632218; Mon, 06 Apr 2015 15:33:52 -0700 (PDT) Received: by 10.36.196.5 with HTTP; Mon, 6 Apr 2015 15:33:50 -0700 (PDT) In-Reply-To: References: <55104501.3070906@KingsMountain.com> <20150406220248.GR24862@mx2.yitter.info> Date: Mon, 6 Apr 2015 15:33:50 -0700 Message-ID: From: Kurt Andersen To: Casey Deccio Content-Type: multipart/alternative; boundary=20cf30363b937d828b051315e462 Archived-At: Cc: Andrew Sullivan , "dbound@ietf.org" Subject: Re: [dbound] comments on draft-deccio-domain-name-relationships-00 X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 22:33:54 -0000 --20cf30363b937d828b051315e462 Content-Type: text/plain; charset=UTF-8 On Mon, Apr 6, 2015 at 3:28 PM, Casey Deccio wrote: > On Mon, Apr 6, 2015 at 6:02 PM, Andrew Sullivan > wrote: > >> >> I am not even a little bit convinced that the distinction is part of >> any solution. > > > Are you saying that there is no solution that can effectively use a > public/private distinction of names to determine whether or not there is > some sort of policy relationship between them? > I think that Andrew is saying, and I agree, that the names "public" and "private" are not useful any more in the dbound discussions. They are badly overloaded and, at best, vaguely defined. We would be better served to start referring to "foo" names and "bar" names. But I think that categorization in general is still a misdirection to the task of identifying names which share policy scopes. --Kurt --20cf30363b937d828b051315e462 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Apr 6, 2015 at 3:28 PM, Casey Deccio <casey@deccio.net><= /span> wrote:
On Mon, Apr 6, 2015 at 6:02 PM, Andrew Sullivan &l= t;ajs@anvilwalr= usden.com> wrote:
<= span class=3D"">

I am not even a little bit convinced that the distinction is part of=
any solution.

Are you saying that there i= s no solution that can effectively use a public/private distinction of name= s to determine whether or not there is some sort of policy relationship bet= ween them?
=

I think that Andrew is s= aying, and I agree, that the names "public" and "private&quo= t; are not useful any more in the dbound discussions. They are badly overlo= aded and, at best, vaguely defined. We would be better served to start refe= rring to "foo" names and "bar" names. But I think that = categorization in general is still a misdirection to the task of identifyin= g names which share policy scopes.

--Kurt
--20cf30363b937d828b051315e462-- From nobody Tue Apr 7 02:16:14 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0D961B334F for ; Tue, 7 Apr 2015 02:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 7827JslPOiw8 for ; Tue, 7 Apr 2015 02:16:10 -0700 (PDT) Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (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 8BDE21B3350 for ; Tue, 7 Apr 2015 02:16:10 -0700 (PDT) Received: by wiaa2 with SMTP id a2so10526270wia.0 for ; Tue, 07 Apr 2015 02:16:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:openpgp:message-id :date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=OB+Bx62Ih/Im9AmbZLHbUa2jYgMf6EU5tozAGB0bx70=; b=JABdfdoz8mGR6CiCKUcQ2+y8GzF/sHFAL79vaKN+QaAcbzHtKmZU2bU4EFWXhOn9rD tvckEtsQWjdCYA6u4vIeUMDlY17walUE/romyO/raSuP5AceZJ60Yp5b82fCHx17lcne GNkRp5p6gdQjGgw2R5eAi+O6kL8+CwwHyQ1a0dfg9tiyCcKYxMaV0dmFJBOX2NSf0GIi 1ysWlM6KA75Qxl+oLoXn2RWJdsLvviVzY2CF8zDnnx9TaLLcZH9fg3mwt9yI0bYK4Kjp eUrO8LylvnUTxarAadSjrjI0YL/DgWHWuvAwa1MJysptiV8f4FD0jF9ooV4lBLTx8xqC Lt+g== X-Gm-Message-State: ALoCoQlQJToxshM4oJRRRjZlYGn1mepD6PNdxvP4Q50f1+Bzf18+jmSIVpu5E/uoqlZP+BLs6VH9 X-Received: by 10.194.79.226 with SMTP id m2mr37479651wjx.60.1428398169081; Tue, 07 Apr 2015 02:16:09 -0700 (PDT) Received: from [192.168.0.224] (93.243.187.81.in-addr.arpa. [81.187.243.93]) by mx.google.com with ESMTPSA id a13sm10039266wjx.30.2015.04.07.02.16.07 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Apr 2015 02:16:08 -0700 (PDT) To: Casey Deccio , "dbound@ietf.org" references: <55104501.3070906@KingsMountain.com> From: Gervase Markham openpgp: id=EEDEEFF962E97696DACBD2CCD9B347EA9DF43DBB x-enigmail-draft-status: N1110 message-id: <5523A056.8040102@mozilla.org> Date: Tue, 7 Apr 2015 10:16:06 +0100 user-agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.0 mime-version: 1.0 in-reply-to: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dbound] comments on draft-deccio-domain-name-relationships-00 X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 09:16:13 -0000 On 06/04/15 19:19, Casey Deccio wrote: > There are two points to the document: historical context, including > description of the PSL and known current usage; and concepts for > identifying policy relationships between domain names. It does not > attempt to endorse PSL use for one purpose or other, but it does speak > of the concepts (i.e., so-called "public"/"private" suffixes) introduced > by the PSL, as well a PSL-like registry to implement those concepts, as > part of a solution. However, it explicitly mentions that neither the > PSL nor a PSL-like registry is sufficient for a complete solution to the > problem. When we split the PSL into two, various other use cases were floated, but it was decided that the distinction we made was the one people most commonly wanted to make, and would serve. But indeed, there may well be use cases for which other distinctions would be better. > Neither am I insinuating that the current PSL is 100% accurate based on > the described notion of public/private. Bug reports welcome :-) Although remember, we only add domains to the PRIVATE section upon request of the domain owner, because we want to be certain that the owner is aware of the ramifications of doing so. So that list is necessarily incomplete, in that it does not contain all privately-held domains which issue subdomains to mutually-untrusting parties. Gerv From nobody Tue Apr 7 06:42:35 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9DC81B3397 for ; Tue, 7 Apr 2015 06:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-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 25m8K-lSrHfB for ; Tue, 7 Apr 2015 06:42:27 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (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 E141D1AD34D for ; Tue, 7 Apr 2015 06:42:26 -0700 (PDT) Received: by iebmp1 with SMTP id mp1so46558211ieb.0 for ; Tue, 07 Apr 2015 06:42:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nHkbmSJiAK7Av2sG7YIbZ99xlW3Br3QAfGpDDkg9dfE=; b=F8L0JszysUj4XjktKuRaxz/+oyLED8e7/kB5jt5+AUtqmp1iby3nui8xSpEr0yqbZf pHqNiYKQPXxFr8K0APLJGfjRau4QhlRvyhtRRMs/ZYuBFu3c1kxrxIwxrgVO9fMRSPTL Pkxkq+e+Mfv3kFX122aADNffuviivWA0DLEFE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=nHkbmSJiAK7Av2sG7YIbZ99xlW3Br3QAfGpDDkg9dfE=; b=jYKN3gU1XPd2dn/s2vLXp0oYXzAeRcxVkaxbVGR8quj4MwujMyQ3jF13X5E/Fo/+99 dx0x8QRSVfhEkGlT9B59iAaFk+luZa3WR5+5b3kcpxzXg58lpj/7u5G8TG9YnsV7wxhZ NI9E361eXmcbVBRAOFt9jwJScDCI+ChdHNx8VG14PElFhtrR3681HyulcWlLyeVEF+Ik BzH7VMWvUO58LEoSYgc74x4HeTTFrzTa9w6WaYNAeMlxH/lcsewcw4A7i41Bu6ONWnhf DikCuJhOeyDqDskDrml/GSU60Nxnu6HQKZGcqrYWGM+Cn92kNBjwbjziud8u3c5IL52Y 2LWg== X-Gm-Message-State: ALoCoQm2cU6eoYaXIMtktPGams0XLm8ORnwWxJni7RcYaIP4p3f6PTvy+qaVvfnzoakqussrT0p0 MIME-Version: 1.0 X-Received: by 10.42.14.131 with SMTP id h3mr25571083ica.7.1428414146262; Tue, 07 Apr 2015 06:42:26 -0700 (PDT) Received: by 10.50.57.233 with HTTP; Tue, 7 Apr 2015 06:42:25 -0700 (PDT) In-Reply-To: References: <55104501.3070906@KingsMountain.com> <20150406220248.GR24862@mx2.yitter.info> Date: Tue, 7 Apr 2015 09:42:25 -0400 Message-ID: From: Casey Deccio To: Kurt Andersen Content-Type: multipart/alternative; boundary=20cf303f6c9cc7d35b05132295b5 Archived-At: Cc: Andrew Sullivan , "dbound@ietf.org" Subject: Re: [dbound] comments on draft-deccio-domain-name-relationships-00 X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 13:42:30 -0000 --20cf303f6c9cc7d35b05132295b5 Content-Type: text/plain; charset=UTF-8 On Mon, Apr 6, 2015 at 6:33 PM, Kurt Andersen wrote: > > On Mon, Apr 6, 2015 at 3:28 PM, Casey Deccio wrote: > >> On Mon, Apr 6, 2015 at 6:02 PM, Andrew Sullivan >> wrote: >> >>> >>> I am not even a little bit convinced that the distinction is part of >>> any solution. >> >> >> Are you saying that there is no solution that can effectively use a >> public/private distinction of names to determine whether or not there is >> some sort of policy relationship between them? >> > > I think that Andrew is saying, and I agree, that the names "public" and > "private" are not useful any more in the dbound discussions. They are badly > overloaded and, at best, vaguely defined. > I think you'll find that the terminology used in the draft being discussed is consistent with descriptions within RFCs that use the terms (see RFC 6265 and RFC 7489, for example). By overloaded, are you mostly referring to the "split" in the PSL that has been noted by several individuals (i.e., the sections labeled "ICANN DOMAINS" vs. "PRIVATE DOMAINS" in the file)? Or do you mean something else? The draft makes an attempt to model the two sections of names--to consider their conceptual merit. But it (the draft) doesn't refer to them in the same way the PSL does (i.e., by "ICANN DOMAINS" and "PRIVATE DOMAINS"). Perhaps it could be more explicit in referencing those sections. Among the solution considerations in Section 6 is the creation of a scope definition resource (i.e., a PSL-like registry) to supplement a per-name based solution. While not explicitly stated in the draft, my personal feeling is that the section of names that is under the section "PRIVATE DOMAINS" (or "lower-level" public names, as denoted in the draft) should *not* be candidates for such a registry. Though that is not explicitly noted in the draft. Regarding "public" and "private" not being useful, I disagree. See Sections 3 and 6 in the -00 draft. We would be better served to start referring to "foo" names and "bar" names. > I'm not sure that makes any sense. > But I think that categorization in general is still a misdirection to the > task of identifying names which share policy scopes. > There seems to be a lot of hang-up on the use of the terms "public" and "private" in the draft. I can't help but feel that some of this results from an effort to distance ourselves from current "makeshift" notions and solutions. However, please don't throw out the baby with the bathwater. While there is a general feeling that the existing solutions are misused and inadequate, there is value in the concepts that they have introduced. The draft at hand is not meant to be a solution, but rather presents a picture of current notions for considerations for solutions, which current notions include implementation (PSL) and specification (RFCs). Understanding the starting point does not imply constraint by that starting point. That being said, the on-list discussions on this topic/draft can only be contextually accurate if participants have read the -00 draft at hand, so this is a general (i.e., not directed) request to read it if you haven't. Regards, Casey --20cf303f6c9cc7d35b05132295b5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Apr 6, 2015 at 6:33 PM, Kurt Andersen <kurta@drkur= t.com> wrote:

On Mon, A= pr 6, 2015 at 3:28 PM, Casey Deccio <casey@deccio.net> wrote:=
On Mon, Apr 6, 2015 at 6:02 PM, Andrew Sullivan <ajs@a= nvilwalrusden.com> wrote:

I am not even a little bit convinced that the distinction is part of=
any solution.

Are you saying that there i= s no solution that can effectively use a public/private distinction of name= s to determine whether or not there is some sort of policy relationship bet= ween them?

I think that Andrew is saying, and= I agree, that the names "public" and "private" are not= useful any more in the dbound discussions. They are badly overloaded and, = at best, vaguely defined.

I think you'll find that the terminology used in the draft being= discussed is consistent with descriptions within RFCs that use the terms (= see RFC 6265 and RFC 7489, for example).

By ov= erloaded, are you mostly referring to the "split" in the PSL that= has been noted by several individuals (i.e., the sections labeled "IC= ANN DOMAINS" vs. "PRIVATE DOMAINS" in the file)?=C2=A0 Or do= you mean something else?=C2=A0 The draft makes an attempt to model the two= sections of names--to consider their conceptual merit.=C2=A0 But it (the d= raft) doesn't refer to them in the same way the PSL does (i.e., by &quo= t;ICANN DOMAINS" and "PRIVATE DOMAINS").=C2=A0 Perhaps it co= uld be more explicit in referencing those sections.

Among the soluti= on considerations in Section 6 is the creation of a scope definition resour= ce (i.e., a PSL-like registry) to supplement a per-name based solution.=C2= =A0 While not explicitly stated in the draft, my personal feeling is that t= he section of names that is under the section "PRIVATE DOMAINS" (= or "lower-level" public names, as denoted in the draft) should *n= ot* be candidates for such a registry.=C2=A0 Though that is not explicitly = noted in the draft.

Regarding "public" and "private&q= uot; not being useful, I disagree.=C2=A0 See Sections 3 and 6 in the -00 dr= aft.

We wou= ld be better served to start referring to "foo" names and "b= ar" names.

I&#= 39;m not sure that makes any sense.
=C2=A0
But I think that categorization in ge= neral is still a misdirection to the task of identifying names which share = policy scopes.
There seems to be a lot of hang-up on the use of the terms &qu= ot;public" and "private" in the draft.=C2=A0 I can't hel= p but feel that some of this results from an effort to distance ourselves f= rom current "makeshift" notions and solutions.=C2=A0 However, ple= ase don't throw out the baby with the bathwater.=C2=A0 While there is a= general feeling that the existing solutions are misused and inadequate, th= ere is value in the concepts that they have introduced.=C2=A0 The draft at = hand is not meant to be a solution, but rather presents a picture of curren= t notions for considerations for solutions, which current notions include i= mplementation (PSL) and specification (RFCs).=C2=A0 Understanding the start= ing point does not imply constraint by that starting point.

That being said, the on-list discussions on this topic/draft can only be= contextually accurate if participants have read the -00 draft at hand, so = this is a general (i.e., not directed) request to read it if you haven'= t.

Regards,
Casey
--20cf303f6c9cc7d35b05132295b5-- From nobody Tue Apr 7 07:47:36 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08AC11B3636 for ; Tue, 7 Apr 2015 07:47:35 -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 0Z_zTmVS7brl for ; Tue, 7 Apr 2015 07:47:33 -0700 (PDT) Received: from mx2.yitter.info (mx2.yitter.info [IPv6:2600:3c03::f03c:91ff:fedf:cfab]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF4E1B3665 for ; Tue, 7 Apr 2015 07:47:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id BC0311062A for ; Tue, 7 Apr 2015 14:47:32 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gn5OMQnPuaLT for ; Tue, 7 Apr 2015 14:47:30 +0000 (UTC) Received: from mx2.yitter.info (mobile-107-107-59-148.mycingular.net [107.107.59.148]) by mx2.yitter.info (Postfix) with ESMTPSA id B923610602 for ; Tue, 7 Apr 2015 14:47:30 +0000 (UTC) Date: Tue, 7 Apr 2015 10:47:27 -0400 From: Andrew Sullivan To: dbound@ietf.org Message-ID: <20150407144726.GB28661@mx2.yitter.info> References: <55104501.3070906@KingsMountain.com> <20150406220248.GR24862@mx2.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dbound] comments on draft-deccio-domain-name-relationships-00 X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 14:47:35 -0000 On Mon, Apr 06, 2015 at 06:28:20PM -0400, Casey Deccio wrote: > Are you saying that there is no solution that can effectively use a > public/private distinction of names to determine whether or not there is > some sort of policy relationship between them? I'm saying that the categories are either too generic not to need subclassing (in which case they're inadequate to our needs) or else we will solve the wrong problem (in which case, they're inadequate to our needs). A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Tue Apr 7 07:59:35 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CCCF1A872A for ; Tue, 7 Apr 2015 07:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-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 AxR6hMBVT3dY for ; Tue, 7 Apr 2015 07:59:32 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (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 2A2901A8715 for ; Tue, 7 Apr 2015 07:59:32 -0700 (PDT) Received: by iebrs15 with SMTP id rs15so48961263ieb.3 for ; Tue, 07 Apr 2015 07:59:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=008BRxtAVma7uqmXSm5Bden7yiRX9O5iquNKTanKUoo=; b=QlMf9CBW5fyqEeG/hX2SJCgtgm7ypS35zzOJLUq7MFzBtGY3oyvAr+W90HNS3dJked MICKc4X7iAAlxMs+JobG7Lm87tGDMX7By3kIyh/XonpbhMQcMQqkKSwB9OivY74JUKbt DVdqDHbDmBiGBN0e42xfmWA22uSB96V3aDcDw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=008BRxtAVma7uqmXSm5Bden7yiRX9O5iquNKTanKUoo=; b=h0uqn3uJTRcwVDvv6S4CYA5UdyCuSftlAURyZCkzBmSlAaTu+XjRl2yOntBceb9JjO FkcxeB3FUZXYYgZZjNCOnFTgvz2IQ5xMMKpOz8wqz6zEW+9CK7N2CxvWQ2NqcMW89Tut +o/BIxPakSmsU0bBQix5eJsHz4VdyQUrn7jIuN6ODf62udNkbxXN4Llcz9myPnPHN7eI 4vMOb9GvmR/SIWOhFqD4sjieqj46SYfAcoWbZV/Xzs2hETQX3NZtNbclwQMEC4Dn5iD8 bj784Qm3oWm9HPVF1pGvvIHbWTCUw1aswazp3aJRLV0jF1Tc7FSuAuzE2F/fxB+896qI DZKw== X-Gm-Message-State: ALoCoQl+U5P2QITTwfWbzgCOe3IV6SabsxVz+sw/g5KwZJwHD8VkQfCayFkZM0yFBxh+3DmRfMP2 MIME-Version: 1.0 X-Received: by 10.107.167.3 with SMTP id q3mr30554987ioe.18.1428418771605; Tue, 07 Apr 2015 07:59:31 -0700 (PDT) Received: by 10.50.57.233 with HTTP; Tue, 7 Apr 2015 07:59:31 -0700 (PDT) In-Reply-To: <20150407144726.GB28661@mx2.yitter.info> References: <55104501.3070906@KingsMountain.com> <20150406220248.GR24862@mx2.yitter.info> <20150407144726.GB28661@mx2.yitter.info> Date: Tue, 7 Apr 2015 10:59:31 -0400 Message-ID: From: Casey Deccio To: "dbound@ietf.org" Content-Type: multipart/alternative; boundary=001a1141ca9e78f7bf051323a91a Archived-At: Subject: Re: [dbound] comments on draft-deccio-domain-name-relationships-00 X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 14:59:33 -0000 --001a1141ca9e78f7bf051323a91a Content-Type: text/plain; charset=UTF-8 Hi Andrew, On Tue, Apr 7, 2015 at 10:47 AM, Andrew Sullivan wrote: > On Mon, Apr 06, 2015 at 06:28:20PM -0400, Casey Deccio wrote: > > Are you saying that there is no solution that can effectively use a > > public/private distinction of names to determine whether or not there is > > some sort of policy relationship between them? > > I'm saying that the categories are either too generic not to need > subclassing (in which case they're inadequate to our needs) or else we > will solve the wrong problem (in which case, they're inadequate to our > needs). > Thanks for the clarification. Please understand that the public/private scope delineation discussed in the draft does not imply that it is a solution; it is a conceptual notion from which a solution component might be based (and by component, I mean does not stand alone). Nor does the draft intend to equate scope with policy. Please don't dismiss the notion or the language on that basis. Sections 3 and 6 respectively discuss the utility of scope knowledge and the high-level solution considerations, which might be a composite set. Casey --001a1141ca9e78f7bf051323a91a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Andrew,

On Tue, Apr 7, 2015 at 10:47 AM, Andrew Sullivan <= ajs@anvilwalrusden.com> wrote:
On Mon, Apr 06, 2015 at 06:28:20PM = -0400, Casey Deccio wrote:
> Are you saying that there is no solution that can effectively use a > public/private distinction of names to determine whether or not there = is
> some sort of policy relationship between them?

I'm saying that the categories are either too generic not to nee= d
subclassing (in which case they're inadequate to our needs) or else we<= br> will solve the wrong problem (in which case, they're inadequate to our<= br> needs).

Thanks for the clarification.= =C2=A0 Please understand that the public/private scope delineation discusse= d in the draft does not imply that it is a solution; it is a conceptual not= ion from which a solution component might be based (and by component, I mea= n does not stand alone).=C2=A0 Nor does the draft intend to equate scope wi= th policy.=C2=A0 Please don't dismiss the notion or the language on tha= t basis.=C2=A0 Sections 3 and 6 respectively discuss the utility of scope k= nowledge and the high-level solution considerations, which might be a compo= site set.

Casey
--001a1141ca9e78f7bf051323a91a-- From nobody Tue Apr 7 19:33:23 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98CF81B2B96 for ; Tue, 7 Apr 2015 19:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 EbgjI7ZPNtrz for ; Tue, 7 Apr 2015 19:33:21 -0700 (PDT) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (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 36AA71B2B94 for ; Tue, 7 Apr 2015 19:33:21 -0700 (PDT) Received: by iggg4 with SMTP id g4so28832329igg.0 for ; Tue, 07 Apr 2015 19:33:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=BMl15t1OWQTEvJG82MmeAlQ5XUN3s9RC6kucSWzyCn8=; b=XdXGa/02sLTMPRP3X3ipvqMKasiD5wLp180Qx8VdnI0e/DAjfwSekeAHS2BzBaxS9n BoB3o7PtQRyKIbQC9a+3miwklNT/IZMhOEc1eiy6HsK8Rs820L6QSeOUM/dJ8Cf4h5DQ Vy16T0LUBauUPTNgz/vkOHib1Lwz8pDEgvCJ+zdGtD8p1yUrSbHIk9GzTQH1GAML/ll+ /vTpimTDQnjiH+niCASXo2RYHyw1ILw93Jh6/glM1qTPzATUvF9dL8uUArDodWD8pVmM 7eDx09P2/KxmqfMqXgCEJzNlHlFpJx6Rrqn7duWEbIhAUeCx150MKq29b6n3k6b1N1Nd Qaxg== MIME-Version: 1.0 X-Received: by 10.50.61.175 with SMTP id q15mr8620686igr.34.1428460400694; Tue, 07 Apr 2015 19:33:20 -0700 (PDT) Received: by 10.36.77.15 with HTTP; Tue, 7 Apr 2015 19:33:20 -0700 (PDT) Date: Tue, 7 Apr 2015 22:33:20 -0400 Message-ID: From: Jeffrey Walton To: "dbound@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [dbound] Another use case to consider.... X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: noloader@gmail.com List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 02:33:22 -0000 Hi Everyone, I know its a little late in the game, but the following use case might be helpful (if its not already covered). The use case is verifying the end-entity certificate issued by an organizational subordinate CA *without* constraints. In the case of organization subordinate CA *without* constraints, the independent 3rd party auditor (the RA) was removed *and* a name constraint was not used to enforce policy. Lack of name constraints means we don't know what domains the organization is authorized to issue for. It seems like DBOUND would be a good place to look for an answer to the question: what domains is an organizational subordinate CA authorized to issue for? From nobody Wed Apr 8 06:26:01 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D17DC1A702B for ; Wed, 8 Apr 2015 06:25:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1 X-Spam-Level: * X-Spam-Status: No, score=1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, MANGLED_SAVELE=2.3] 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 5MEfI1QL_DTg for ; Wed, 8 Apr 2015 06:25:53 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id E2AE01A6F2A for ; Wed, 8 Apr 2015 06:25:52 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 257D9F984; Wed, 8 Apr 2015 09:25:48 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 31ACD2011F; Wed, 8 Apr 2015 08:25:38 -0500 (CDT) From: Daniel Kahn Gillmor To: noloader@gmail.com, "dbound\@ietf.org" In-Reply-To: References: User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Wed, 08 Apr 2015 09:25:34 -0400 Message-ID: <877ftm4ur5.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [dbound] Another use case to consider.... X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 13:25:57 -0000 --=-=-= Content-Type: text/plain On Tue 2015-04-07 22:33:20 -0400, Jeffrey Walton wrote: > The use case is verifying the end-entity certificate issued by an > organizational subordinate CA *without* constraints. > > In the case of organization subordinate CA *without* constraints, the > independent 3rd party auditor (the RA) was removed *and* a name > constraint was not used to enforce policy. Lack of name constraints > means we don't know what domains the organization is authorized to > issue for. > > It seems like DBOUND would be a good place to look for an answer to > the question: what domains is an organizational subordinate CA > authorized to issue for? The implication here is that the organizational subordinate CA doesn't have name constraints, but *does* have some DNS label embedded in it somehow. is that right? Take a look at the "Google Internet Authority G2" intermediate organizational certificate below (with parsed output from GnuTLS's certtool -i). The only DNS labels included in this certificate are AIA and CRL distribution points. How would you apply dbound to limit the scope of this organizational intermediate certificate? I tend to think that explicit name constraints are the way to go, since they are already pretty clearly specified; we just need to actually get tools to respect them (and CAs to issue intermediate certs with them)! --dkg X.509 Certificate Information: Version: 3 Serial Number (hex): 023a76 Issuer: C=US,O=GeoTrust Inc.,CN=GeoTrust Global CA Validity: Not Before: Fri Apr 05 15:15:55 UTC 2013 Not After: Sat Dec 31 23:59:59 UTC 2016 Subject: C=US,O=Google Inc,CN=Google Internet Authority G2 Subject Public Key Algorithm: RSA Algorithm Security Level: Medium (2048 bits) Modulus (bits 2048): 00:9c:2a:04:77:5c:d8:50:91:3a:06:a3:82:e0:d8:50 48:bc:89:3f:f1:19:70:1a:88:46:7e:e0:8f:c5:f1:89 ce:21:ee:5a:fe:61:0d:b7:32:44:89:a0:74:0b:53:4f 55:a4:ce:82:62:95:ee:eb:59:5f:c6:e1:05:80:12:c4 5e:94:3f:bc:5b:48:38:f4:53:f7:24:e6:fb:91:e9:15 c4:cf:f4:53:0d:f4:4a:fc:9f:54:de:7d:be:a0:6b:6f 87:c0:d0:50:1f:28:30:03:40:da:08:73:51:6c:7f:ff 3a:3c:a7:37:06:8e:bd:4b:11:04:eb:7d:24:de:e6:f9 fc:31:71:fb:94:d5:60:f3:2e:4a:af:42:d2:cb:ea:c4 6a:1a:b2:cc:53:dd:15:4b:8b:1f:c8:19:61:1f:cd:9d a8:3e:63:2b:84:35:69:65:84:c8:19:c5:46:22:f8:53 95:be:e3:80:4a:10:c6:2a:ec:ba:97:20:11:c7:39:99 10:04:a0:f0:61:7a:95:25:8c:4e:52:75:e2:b6:ed:08 ca:14:fc:ce:22:6a:b3:4e:cf:46:03:97:97:03:7e:c0 b1:de:7b:af:45:33:cf:ba:3e:71:b7:de:f4:25:25:c2 0d:35:89:9d:9d:fb:0e:11:79:89:1e:37:c5:af:8e:72 69 Exponent (bits 24): 01:00:01 Extensions: Authority Key Identifier (not critical): c07a98688d89fbab05640c117daa7d65b8cacc4e Subject Key Identifier (not critical): 4add06161bbcf668b576f581b6bb621aba5a812f Basic Constraints (critical): Certificate Authority (CA): TRUE Path Length Constraint: 0 Key Usage (critical): Certificate signing. CRL signing. CRL Distribution points (not critical): URI: http://g.symcb.com/crls/gtglobal.crl Authority Information Access (not critical): Access Method: 1.3.6.1.5.5.7.48.1 (id-ad-ocsp) Access Location URI: http://g.symcd.com Certificate Policies (not critical): 1.3.6.1.4.1.11129.2.5.1 Signature Algorithm: RSA-SHA1 Signature: 27:8c:cf:e9:c7:3b:be:c0:6f:e8:96:84:fb:9c:5c:5d 90:e4:77:db:8b:32:60:9b:65:d8:85:26:b5:ba:9f:1e de:64:4e:1f:c6:c8:20:5b:09:9f:ab:a9:e0:09:34:45 a2:65:25:37:3d:7f:5a:6f:20:cc:f9:fa:f1:1d:8f:10 0c:02:3a:c4:c9:01:76:96:be:9b:f9:15:d8:39:d1:c5 03:47:76:b8:8a:8c:31:d6:60:d5:e4:8f:db:fa:3c:c6 d5:98:28:f8:1c:8f:17:91:34:cb:cb:52:7a:d1:fb:3a 20:e4:e1:86:b1:d8:18:0f:be:d6:87:64:8d:c5:0a:25 42:51:ef:b2:38:b8:e0:1d:d0:e1:fc:e6:f4:af:46:ba ef:c0:bf:c5:b4:05:f5:94:75:0c:fe:a2:be:02:ba:ea 86:5b:f9:35:b3:66:f5:c5:8d:85:a1:1a:23:77:1a:19 17:54:13:60:9f:0b:e1:b4:9c:28:2a:f9:ae:02:34:6d 25:93:9c:82:a8:17:7b:f1:85:b0:d3:0f:58:e1:fb:b1 fe:9c:a1:a3:e8:fd:c9:3f:f4:d7:71:dc:bd:8c:a4:19 e0:21:23:23:55:13:8f:a4:16:02:09:7e:b9:af:ee:db 53:64:bd:71:2f:b9:39:ce:30:b7:b4:bc:54:e0:47:07 Other Information: SHA1 fingerprint: bbdce13e9d537a5229915cb123c7aab0a855e798 SHA256 fingerprint: c3f697a92a293d86f9a3ee7ccb970e20e0050b8728cc83ed1b996ce9005d4c36 Public Key ID: 43dad630ee53f8a980ca6efd85f46aa37990e0ea Public key's random art: +--[ RSA 2048]----+ | | | | | + | | . = = | | . . .o S o | | . oo = + . | | . ...o = o | |......++ o | |.E+ o=o.. | +-----------------+ -----BEGIN CERTIFICATE----- MIID8DCCAtigAwIBAgIDAjp2MA0GCSqGSIb3DQEBBQUAMEIxCzAJBgNVBAYTAlVT MRYwFAYDVQQKEw1HZW9UcnVzdCBJbmMuMRswGQYDVQQDExJHZW9UcnVzdCBHbG9i YWwgQ0EwHhcNMTMwNDA1MTUxNTU1WhcNMTYxMjMxMjM1OTU5WjBJMQswCQYDVQQG EwJVUzETMBEGA1UEChMKR29vZ2xlIEluYzElMCMGA1UEAxMcR29vZ2xlIEludGVy bmV0IEF1dGhvcml0eSBHMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AJwqBHdc2FCROgajguDYUEi8iT/xGXAaiEZ+4I/F8YnOIe5a/mENtzJEiaB0C1NP VaTOgmKV7utZX8bhBYASxF6UP7xbSDj0U/ck5vuR6RXEz/RTDfRK/J9U3n2+oGtv h8DQUB8oMANA2ghzUWx//zo8pzcGjr1LEQTrfSTe5vn8MXH7lNVg8y5Kr0LSy+rE ahqyzFPdFUuLH8gZYR/Nnag+YyuENWllhMgZxUYi+FOVvuOAShDGKuy6lyARxzmZ EASg8GF6lSWMTlJ14rbtCMoU/M4iarNOz0YDl5cDfsCx3nuvRTPPuj5xt970JSXC DTWJnZ37DhF5iR43xa+OcmkCAwEAAaOB5zCB5DAfBgNVHSMEGDAWgBTAephojYn7 qwVkDBF9qn1luMrMTjAdBgNVHQ4EFgQUSt0GFhu89mi1dvWBtrtiGrpagS8wEgYD VR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAQYwNQYDVR0fBC4wLDAqoCig JoYkaHR0cDovL2cuc3ltY2IuY29tL2NybHMvZ3RnbG9iYWwuY3JsMC4GCCsGAQUF BwEBBCIwIDAeBggrBgEFBQcwAYYSaHR0cDovL2cuc3ltY2QuY29tMBcGA1UdIAQQ MA4wDAYKKwYBBAHWeQIFATANBgkqhkiG9w0BAQUFAAOCAQEAJ4zP6cc7vsBv6JaE +5xcXZDkd9uLMmCbZdiFJrW6nx7eZE4fxsggWwmfq6ngCTRFomUlNz1/Wm8gzPn6 8R2PEAwCOsTJAXaWvpv5Fdg50cUDR3a4iowx1mDV5I/b+jzG1Zgo+ByPF5E0y8tS etH7OiDk4Yax2BgPvtaHZI3FCiVCUe+yOLjgHdDh/Ob0r0a678C/xbQF9ZR1DP6i vgK66oZb+TWzZvXFjYWhGiN3GhkXVBNgnwvhtJwoKvmuAjRtJZOcgqgXe/GFsNMP WOH7sf6coaPo/ck/9Ndx3L2MpBngISMjVROPpBYCCX65r+7bU2S9cS+5Oc4wt7S8 VOBHBw== -----END CERTIFICATE----- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQJ8BAEBCgBmBQJVJSxPXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcyHcP/Rqj0Krio7PicWMFVUuoBwSu cEhebu5g3+tqmmIsdKVBJAclYAM8wBhapCziIdITJHh8N2pJVMUQV+6JYjANny+m 4QjSn5Qg08C+GYTewKtE/JoX3rYAUUaxmZSctr7pXVJjfO4c5KzbBjtoVVmMADAC qpE41svS9N3rFSk9LO9ZPTHQBBu2Q1izDpM065HFbutEteCrWME7cnpPpatP4PK/ E7AnImiMUuB0IZYu8FZsU6CXBRntkIP2srzMJv4e80e0Lg4qifjlh1izsvXWtgQS N877ufHcTNj4ffgF2695cp98R+PuE504uVtu+vdGyrhVS0//A62ubA5i5SIfeydJ WVg/CTQOkrc9i9SXVeBNSJr4xSh5o1J1ixy5htkG1Si5dQtZYbJEOFHqiIM4tjaM FYCdyBnkdChgvQOEtJtOQ/VLn2kJjowbGwUs85H5lWM4QsEbP+evJYbu+hHvtOdl 2nCgb+kDm/AaE8Tb7UoUKpV2U2q1zRFnhBrF8jK2pWpgmREGbkw3+u+aaLVgzKlk 4PChtlbWg8qWR8gmlslnOkX++DeW6XZ0P4uBjjOmC0U+3MUa+nXGUSCHABpL5p88 fMUZCs7cNu8wMLsBPPf6S/LVpquUn1yrMBOn9mSz+o6bEXjYs15ZsLOWIc/aRQJz j0x294E959eH9nu1aDCy =Nfla -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Apr 8 10:44:35 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2ACA1A87D5; Wed, 8 Apr 2015 10:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] 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 mm5CvR6NncUc; Wed, 8 Apr 2015 10:44:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6A11A87B2; Wed, 8 Apr 2015 10:44:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150408174431.21986.83516.idtracker@ietfa.amsl.com> Date: Wed, 08 Apr 2015 10:44:31 -0700 Archived-At: Cc: dbound@ietf.org Subject: [dbound] Spencer Dawkins' No Objection on charter-ietf-dbound-00-03: (with COMMENT) X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 17:44:33 -0000 Spencer Dawkins has entered the following ballot position for charter-ietf-dbound-00-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/charter-ietf-dbound/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Just a nit: In this text: "This working group will not seek to amend the consuming protocols themselves (standards for any web, email, or other such protocols) without rechartering, and such rechartering will only be considered after completion of the base work." I was guessing that these emendations would happen in working groups that are responsible for the protocols, but this paragraph makes it sound like this working group would be rechartered to do that work. Is that what you intend to happen? From nobody Wed Apr 8 11:33:47 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 209431A8BBD; Wed, 8 Apr 2015 11:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-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 CKTN0lgiW-rt; Wed, 8 Apr 2015 11:33:46 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (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 3B2441A8BB2; Wed, 8 Apr 2015 11:33:46 -0700 (PDT) Received: by iebrs15 with SMTP id rs15so81997785ieb.3; Wed, 08 Apr 2015 11:33:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=KZ9NvL6kHgkPRM1htEGK6BIFjB9inv9hdUoEeKVdGAw=; b=H+D8awR1+h9GQN8mdKj2pAkR7SMPhOkYj5fLOKT4ndXmOkbqbo3oHVgvNqsq0SRuZ5 sDV7NEQKYEUEGIHka06xrXZ5ozEUvhkdE1WVNFaReHLhU3FwBaO+nuNwdni894tJGnPv 7j1xlW43+iTqVp3C1Inxx2Fd4dPXzEPMtwfF5hfGCSaI9GiuoVOkBpozNZ/+acOI6Io2 ZbOCPUqtI+U8109WOft8IIEwj7A+FztWg4mIMB3saAyM3ZvEKjsrN7nQbODS75zqWXd+ KGcBdEWe6BVjjVGOQFOO6tW51OJJq1LllB1ThXxxZFVyI9t6CXmgj/SRih+9YtFmiBto 63ow== MIME-Version: 1.0 X-Received: by 10.43.55.12 with SMTP id vw12mr34431256icb.30.1428518025800; Wed, 08 Apr 2015 11:33:45 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.107.7.130 with HTTP; Wed, 8 Apr 2015 11:33:45 -0700 (PDT) In-Reply-To: <20150408174431.21986.83516.idtracker@ietfa.amsl.com> References: <20150408174431.21986.83516.idtracker@ietfa.amsl.com> Date: Wed, 8 Apr 2015 14:33:45 -0400 X-Google-Sender-Auth: pg9tw_zUFBXE_mPgOJBfIUTOy-4 Message-ID: From: Barry Leiba To: Spencer Dawkins Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: The IESG , "dbound@ietf.org" Subject: Re: [dbound] Spencer Dawkins' No Objection on charter-ietf-dbound-00-03: (with COMMENT) X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 18:33:47 -0000 >> "This working group will not seek to amend the consuming protocols >> themselves (standards for any web, email, or other such protocols) >> without rechartering, and such rechartering will only be considered >> after completion of the base work." > > I was guessing that these emendations would happen in working groups that > are responsible for the protocols, but this paragraph makes it sound like > this working group would be rechartered to do that work. Is that what you > intend to happen? The intent is that *if* the work is to be done in this working group, it would require a recharter. Clearly, the process of rechartering would include making a decision about the right place to do the work: the IESG won't approve a work item for this working group if it thinks that item should be done elsewhere. Do you really think the charter text needs to be changed to clarify that? If so, please propose text. Barry From nobody Wed Apr 8 11:55:15 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F8721B34FB; Wed, 8 Apr 2015 11:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 hbee47-u3EKo; Wed, 8 Apr 2015 11:55:09 -0700 (PDT) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (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 2A5861B3505; Wed, 8 Apr 2015 11:55:09 -0700 (PDT) Received: by lagv1 with SMTP id v1so73104527lag.3; Wed, 08 Apr 2015 11:55:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=juNcbO2BhZyBYxva9/Tshvr6jGVYQf9p9BQd03Uofzo=; b=kmMWwcX1iQgu0z09jZajs3l0dN3CYSJBbfcw59Gj3jPzDMclJhc4eHVgAwvVcO6oI2 Ji9EXT+YuFEOHYwiGK1LqDLmq2ewy8cTsXVVLe5QHSnrJXro5+uxGp33ir5P6hPfyfK+ gLAjFDy1+o4Z5vCynU2StiwfxsjA23zdP8fGptDcCADHsYKpFsDIyExb1V8y+JBsgh/D tIX+8+QI4BlucJX8ZlDb8B4KsC56tDmO+kkStSLMPkIi7BjkkpSKPX6G47TowWZp+jOj CxZ38kXU3qfTrb57r1kzZA8K2BGJrdQ+irTv3b5oeyeoMiPSPDeG1sk2CFltTKe709zc cYUw== MIME-Version: 1.0 X-Received: by 10.112.146.41 with SMTP id sz9mr20256354lbb.77.1428519307591; Wed, 08 Apr 2015 11:55:07 -0700 (PDT) Received: by 10.152.129.3 with HTTP; Wed, 8 Apr 2015 11:55:07 -0700 (PDT) In-Reply-To: References: <20150408174431.21986.83516.idtracker@ietfa.amsl.com> Date: Wed, 8 Apr 2015 13:55:07 -0500 Message-ID: From: Spencer Dawkins at IETF To: Barry Leiba Content-Type: multipart/alternative; boundary=047d7b3a8784e244e005133b11a4 Archived-At: Cc: The IESG , "dbound@ietf.org" Subject: Re: [dbound] Spencer Dawkins' No Objection on charter-ietf-dbound-00-03: (with COMMENT) X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 18:55:11 -0000 --047d7b3a8784e244e005133b11a4 Content-Type: text/plain; charset=UTF-8 Hi, Barry, On Wed, Apr 8, 2015 at 1:33 PM, Barry Leiba wrote: > >> "This working group will not seek to amend the consuming protocols > >> themselves (standards for any web, email, or other such protocols) > >> without rechartering, and such rechartering will only be considered > >> after completion of the base work." > > > > I was guessing that these emendations would happen in working groups that > > are responsible for the protocols, but this paragraph makes it sound like > > this working group would be rechartered to do that work. Is that what you > > intend to happen? > > The intent is that *if* the work is to be done in this working group, > it would require a recharter. Clearly, the process of rechartering > would include making a decision about the right place to do the work: > the IESG won't approve a work item for this working group if it thinks > that item should be done elsewhere. Right. I was reading this text as pointing out that the work might be done in a rechartered DBOUND, without mentioning that the work group could also be added to the charter of working groups responsible for the consuming protocols. You and I know that the second possibility is a possibility. I was thinking that pointing this out in the charter might be helpful. > Do you really think the charter text needs to be changed to clarify > that? If so, please propose text. Perhaps something like this, but do the right thing. "If amendments to the consuming protocols themselves (standards for any web, email or other such protocols) are needed, those amendments will only be chartered after the base work is completed, and the work may be rechartered in DBOUND or in another working group responsible for maintaining the consuming protocol." Thanks, Spencer --047d7b3a8784e244e005133b11a4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Barry,

On Wed, Apr 8, 2015 at 1:33 PM, Barry Leiba <= ;barryleiba@co= mputer.org> wrote:
>&= gt; "This working group will not seek to amend the consuming protocols=
>> themselves (standards for any web, email, or other such protocols)=
>> without rechartering, and such rechartering will only be considere= d
>> after completion of the base work."
>
> I was guessing that these emendations would happen in working groups t= hat
> are responsible for the protocols, but this paragraph makes it sound l= ike
> this working group would be rechartered to do that work. Is that what = you
> intend to happen?

The intent is that *if* the work is to be done in this working group= ,
it would require a recharter.=C2=A0 Clearly, the process of rechartering would include making a decision about the right place to do the work:
the IESG won't approve a work item for this working group if it thinks<= br> that item should be done elsewhere.

Right. = I was reading this text as pointing out that the work might be done in a re= chartered DBOUND, without mentioning that the work group could also be adde= d to the charter of working groups responsible for the consuming protocols.=

You and I know that the second possibility is a p= ossibility. I was thinking that pointing this out in the charter might be h= elpful.
=C2=A0
Do you really think the char= ter text needs to be changed to clarify
that?=C2=A0 If so, please propose text.

Per= haps something like this, but do the right thing.

= "If amendments to the consuming protocols themselves (standards for
any web, email or other such protocols) are needed, those=C2=A0
amendments will only be chartered after the base work is completed, = and=C2=A0
the work may be rechartered in DBOUND or in another wor= king group
responsible for maintaining the consuming protocol.&qu= ot;

Thanks,

Spencer
=
--047d7b3a8784e244e005133b11a4-- From nobody Wed Apr 8 12:55:25 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1471E1B35AA; Wed, 8 Apr 2015 12:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-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 X_u4rzs4KwDt; Wed, 8 Apr 2015 12:55:23 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (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 D39C21B35A8; Wed, 8 Apr 2015 12:55:22 -0700 (PDT) Received: by iebmp1 with SMTP id mp1so83929131ieb.0; Wed, 08 Apr 2015 12:55:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=U8zMEkEl+DDw7gTCDhZVMf8HcGU9ohPsoCCX1WfrXaI=; b=lx+Qvv87x1wG0Ko4tGAVk9IWRWFSCUWA8LL0dNft53eweGoCBfH9CopBMWPjk86NRY 0oBIgoY0DzLbctY3qmrpuwLs44wRd48YnIowk0mEeUnKBnN2NYG+iP/03IRvcNAZiSyT ZLmln/dY0eYBa43fL2zZS0gth7nx3gD4WIeD6AnsWONFWzhFKuLrvTwkEoHhtJO76o9m NfYM0M8Vd4EUJkAiyzDHQQcqcff4RtC7gLyLJlbdXggRgvUCvYPjFW8SYE2eB1FEGQxP c1AT6WIIAfgukV8+YkeoywpBBjpCSu0LHCZhC7a/PtMPPRYHh/+NNouvY3iVw+Be075j Aakg== MIME-Version: 1.0 X-Received: by 10.43.55.12 with SMTP id vw12mr34859926icb.30.1428522922053; Wed, 08 Apr 2015 12:55:22 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.107.7.130 with HTTP; Wed, 8 Apr 2015 12:55:22 -0700 (PDT) In-Reply-To: References: <20150408174431.21986.83516.idtracker@ietfa.amsl.com> Date: Wed, 8 Apr 2015 15:55:22 -0400 X-Google-Sender-Auth: bLnq6Kxkfr_pqk86wh5HXWImAcg Message-ID: From: Barry Leiba To: Spencer Dawkins at IETF Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: The IESG , "dbound@ietf.org" Subject: Re: [dbound] Spencer Dawkins' No Objection on charter-ietf-dbound-00-03: (with COMMENT) X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 19:55:24 -0000 I went with this in -04: << This working group will not seek to amend the consuming protocols themselves (standards for any web, email, or other such protocols) under this charter. If such work is desirable, it will be assigned to another appropriate working group or defined as a work item in an updated charter. Rechartering will only be considered after completion of the base work. >> Barry On Wed, Apr 8, 2015 at 2:55 PM, Spencer Dawkins at IETF wrote: > Hi, Barry, > > On Wed, Apr 8, 2015 at 1:33 PM, Barry Leiba wrote: >> >> >> "This working group will not seek to amend the consuming protocols >> >> themselves (standards for any web, email, or other such protocols) >> >> without rechartering, and such rechartering will only be considered >> >> after completion of the base work." >> > >> > I was guessing that these emendations would happen in working groups >> > that >> > are responsible for the protocols, but this paragraph makes it sound >> > like >> > this working group would be rechartered to do that work. Is that what >> > you >> > intend to happen? >> >> The intent is that *if* the work is to be done in this working group, >> it would require a recharter. Clearly, the process of rechartering >> would include making a decision about the right place to do the work: >> the IESG won't approve a work item for this working group if it thinks >> that item should be done elsewhere. > > > Right. I was reading this text as pointing out that the work might be done > in a rechartered DBOUND, without mentioning that the work group could also > be added to the charter of working groups responsible for the consuming > protocols. > > You and I know that the second possibility is a possibility. I was thinking > that pointing this out in the charter might be helpful. > >> >> Do you really think the charter text needs to be changed to clarify >> that? If so, please propose text. > > > Perhaps something like this, but do the right thing. > > "If amendments to the consuming protocols themselves (standards for > any web, email or other such protocols) are needed, those > amendments will only be chartered after the base work is completed, and > the work may be rechartered in DBOUND or in another working group > responsible for maintaining the consuming protocol." > > Thanks, > > Spencer From nobody Wed Apr 8 19:21:25 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A7C51B2A80; Wed, 8 Apr 2015 19:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.61 X-Spam-Level: X-Spam-Status: No, score=-5.61 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FSL_MY_NAME_IS=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 JQ9014byN3cc; Wed, 8 Apr 2015 19:21:21 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E5591B2A82; Wed, 8 Apr 2015 19:20:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1428546057; x=1460082057; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; bh=RuCHLjP/+F0J4heC56a6CxnuwAK3h2nScwG16zWaBfg=; b=WhR+J8I8yyuh6QvZvUB8+u6FHIsLa/7iT9yUVjXw1JGsh9bVMx0gcSbD VhpsR2LhUj9QM4n71gKd6gdzV2LRMzt6io1IyARbTX3PmrwbWipsaKjB5 RhWUKWipLaF1ZbRPfwRLzpclqe0ycqUVtW6Rxenqj/q/4RE4K96dci4kH I=; X-IronPort-AV: E=McAfee;i="5700,7163,7765"; a="204666884" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Apr 2015 19:20:56 -0700 X-IronPort-AV: E=Sophos;i="5.11,547,1422950400"; d="scan'208";a="944173842" Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 08 Apr 2015 19:20:56 -0700 Received: from presnick-mac.local (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Wed, 8 Apr 2015 19:20:55 -0700 Message-ID: <5525E204.60004@qti.qualcomm.com> Date: Wed, 8 Apr 2015 21:20:52 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: The IESG Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01C.na.qualcomm.com (10.85.0.83) To NASANEXM01F.na.qualcomm.com (10.85.0.32) Archived-At: Cc: dbound@ietf.org Subject: [dbound] DBOUND charter editorial changes X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 02:21:23 -0000 Sorry for the late post. I thought that, given my name is on the charter page, I might catch up on reading the list and the proposed charter. Still working on the former. Please accept these (hopefully minor) editorial changes regarding the latter: OLD See the "Additional Background Information" section, below, for more details. NEW See the WG wiki at for more details. (Since the below says that it's going away.) OLD For the purpose of this work, domain names are identifiers used by organizations and services, independent of underlying protocols or mechanisms. We define an "organizational domain" to be a name... NEW For the purpose of this work, "domain names" are identifiers used by organizations and services, independent of underlying protocols or mechanisms, and an "organizational domain" is defined as a name... (As the joke goes: "Who is this 'we'...?" I think the above reads better.) OLD The current way most of this is handled is via a list published at publicsuffix.org NEW The current way most of this is handled is via a list published at publicsuffix.org (commonly known as the "Public Suffix List" or "PSL") (It seems to me that the words "Public Suffix List" or "PSL" should appear somewhere in the published charter. At least it makes those words searchable.) pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Thu Apr 9 04:45:07 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 801571A0242; Thu, 9 Apr 2015 04:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 CKx6lL2qvPAX; Thu, 9 Apr 2015 04:45:01 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (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 A90191A0366; Thu, 9 Apr 2015 04:44:59 -0700 (PDT) Received: by labbd9 with SMTP id bd9so75958686lab.2; Thu, 09 Apr 2015 04:44:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zMoRe1Ne7TaDIpH3ahG9fXl8DR1vXiYFw2kMaGr6E/w=; b=W13FPwzxCKTgjqnAi29LQCx0yMsVigu2YLTYT3Ek9c+YkrQsb9kJwHXBM58kZIQBVz Wi2mx99UjsWKCXlFZ/yGNE7Oe8PDmfqopdvgL6ZKPY/LUTdS29peY5NArGzBNpR3Agg6 e1wRkcce1j5dPvBequQuv4l2NbpvrHEdAmTwTzn3x0v/XlJnA6+GnfDydmJzB4BafFPS cYvuSeWyz04KPv1X1eLDJEQwaYyFLrO/d8RbG7CtaBpCrFwhgR73KuEju0EXnv9pIOQa qcqPKOxxrT446fuWCxaVFwzbL4iqIAL1L4zJezZrLHqxbpee61VyHl/9XM0Qe2heYruq 6Y4Q== MIME-Version: 1.0 X-Received: by 10.152.203.162 with SMTP id kr2mr4069517lac.68.1428579898232; Thu, 09 Apr 2015 04:44:58 -0700 (PDT) Received: by 10.152.129.3 with HTTP; Thu, 9 Apr 2015 04:44:58 -0700 (PDT) Received: by 10.152.129.3 with HTTP; Thu, 9 Apr 2015 04:44:58 -0700 (PDT) In-Reply-To: References: <20150408174431.21986.83516.idtracker@ietfa.amsl.com> Date: Thu, 9 Apr 2015 06:44:58 -0500 Message-ID: From: Spencer Dawkins at IETF To: Barry Leiba Content-Type: multipart/alternative; boundary=001a113463265e13b10513492d4f Archived-At: Cc: iesg@ietf.org, dbound@ietf.org Subject: Re: [dbound] Spencer Dawkins' No Objection on charter-ietf-dbound-00-03: (with COMMENT) X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 11:45:03 -0000 --001a113463265e13b10513492d4f Content-Type: text/plain; charset=UTF-8 Hi, Barry, On Apr 8, 2015 14:55, "Barry Leiba" wrote: > > I went with this in -04: Perfect. Thanks. > << > This working group will not seek to amend the consuming protocols > themselves (standards for any web, email, or other such protocols) > under this charter. If such work is desirable, it will be assigned to > another appropriate working group or defined as a work item in an > updated charter. Rechartering will only be considered after completion > of the base work. > >> > > Barry > > On Wed, Apr 8, 2015 at 2:55 PM, Spencer Dawkins at IETF > wrote: > > Hi, Barry, > > > > On Wed, Apr 8, 2015 at 1:33 PM, Barry Leiba wrote: > >> > >> >> "This working group will not seek to amend the consuming protocols > >> >> themselves (standards for any web, email, or other such protocols) > >> >> without rechartering, and such rechartering will only be considered > >> >> after completion of the base work." > >> > > >> > I was guessing that these emendations would happen in working groups > >> > that > >> > are responsible for the protocols, but this paragraph makes it sound > >> > like > >> > this working group would be rechartered to do that work. Is that what > >> > you > >> > intend to happen? > >> > >> The intent is that *if* the work is to be done in this working group, > >> it would require a recharter. Clearly, the process of rechartering > >> would include making a decision about the right place to do the work: > >> the IESG won't approve a work item for this working group if it thinks > >> that item should be done elsewhere. > > > > > > Right. I was reading this text as pointing out that the work might be done > > in a rechartered DBOUND, without mentioning that the work group could also > > be added to the charter of working groups responsible for the consuming > > protocols. > > > > You and I know that the second possibility is a possibility. I was thinking > > that pointing this out in the charter might be helpful. > > > >> > >> Do you really think the charter text needs to be changed to clarify > >> that? If so, please propose text. > > > > > > Perhaps something like this, but do the right thing. > > > > "If amendments to the consuming protocols themselves (standards for > > any web, email or other such protocols) are needed, those > > amendments will only be chartered after the base work is completed, and > > the work may be rechartered in DBOUND or in another working group > > responsible for maintaining the consuming protocol." > > > > Thanks, > > > > Spencer --001a113463265e13b10513492d4f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi, Barry,

On Apr 8, 2015 14:55, "Barry Leiba" <barryleiba@computer.org> wrote:
>
> I went with this in -04:

Perfect. Thanks.

> <<
> This working group will not seek to amend the consuming protocols
> themselves (standards for any web, email, or other such protocols)
> under this charter.=C2=A0 If such work is desirable, it will be assign= ed to
> another appropriate working group or defined as a work item in an
> updated charter. Rechartering will only be considered after completion=
> of the base work.
> >>
>
> Barry
>
> On Wed, Apr 8, 2015 at 2:55 PM, Spencer Dawkins at IETF
> <spencerdawkins.ie= tf@gmail.com> wrote:
> > Hi, Barry,
> >
> > On Wed, Apr 8, 2015 at 1:33 PM, Barry Leiba <barryleiba@computer.org> wrote:
> >>
> >> >> "This working group will not seek to amend the = consuming protocols
> >> >> themselves (standards for any web, email, or other s= uch protocols)
> >> >> without rechartering, and such rechartering will onl= y be considered
> >> >> after completion of the base work."
> >> >
> >> > I was guessing that these emendations would happen in wo= rking groups
> >> > that
> >> > are responsible for the protocols, but this paragraph ma= kes it sound
> >> > like
> >> > this working group would be rechartered to do that work.= Is that what
> >> > you
> >> > intend to happen?
> >>
> >> The intent is that *if* the work is to be done in this workin= g group,
> >> it would require a recharter.=C2=A0 Clearly, the process of r= echartering
> >> would include making a decision about the right place to do t= he work:
> >> the IESG won't approve a work item for this working group= if it thinks
> >> that item should be done elsewhere.
> >
> >
> > Right. I was reading this text as pointing out that the work migh= t be done
> > in a rechartered DBOUND, without mentioning that the work group c= ould also
> > be added to the charter of working groups responsible for the con= suming
> > protocols.
> >
> > You and I know that the second possibility is a possibility. I wa= s thinking
> > that pointing this out in the charter might be helpful.
> >
> >>
> >> Do you really think the charter text needs to be changed to c= larify
> >> that?=C2=A0 If so, please propose text.
> >
> >
> > Perhaps something like this, but do the right thing.
> >
> > "If amendments to the consuming protocols themselves (standa= rds for
> > any web, email or other such protocols) are needed, those
> > amendments will only be chartered after the base work is complete= d, and
> > the work may be rechartered in DBOUND or in another working group=
> > responsible for maintaining the consuming protocol."
> >
> > Thanks,
> >
> > Spencer

--001a113463265e13b10513492d4f-- From nobody Fri Apr 10 10:08:52 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DE9D1ABC0F; Fri, 10 Apr 2015 09:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 8YcByGYsXM4h; Fri, 10 Apr 2015 09:26:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B8E211AC41D; Fri, 10 Apr 2015 09:26:32 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 5.13.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150410162632.3280.48979.idtracker@ietfa.amsl.com> Date: Fri, 10 Apr 2015 09:26:32 -0700 Archived-At: X-Mailman-Approved-At: Fri, 10 Apr 2015 10:08:50 -0700 Cc: dbound WG Subject: [dbound] WG Action: Formed Domain Boundaries (dbound) X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 16:26:43 -0000 A new IETF working group has been formed in the Applications Area. For additional information please contact the Area Directors or the WG Chairs. Domain Boundaries (dbound) ------------------------------------------------ Current Status: Proposed WG Chairs: Pete Resnick Murray Kucherawy Assigned Area Director: Barry Leiba Mailing list Address: dbound@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/dbound Archive: http://www.ietf.org/mail-archive/web/dbound Charter: Various Internet protocols and applications require some mechanism for determining whether two domain names are related. The meaning of "related" in this context is not a unitary concept. The DBOUND working group will develop one or more solutions to this family of problems, and will clarify the types of relations relevant. For example, it is often necessary or useful to determine whether example.com and foo.example.com, or even example.net, are subject to the same administrative control. To humans, the answer to this may be obvious. However, the Domain Name System (DNS), which is the service that handles domain name queries, does not provide the ability to mark these sorts of relationships. This makes it impossible to discern relationships algorithmically. The right answer is not always "compare the rightmost two labels". Applications and organizations impose policies and procedures that create additional structure in their use of domain names. This creates many possible relationships that are not evident in the names themselves or in the operational, public representation of the names. Prior solutions for identifying relationships between domain names have sought to use the DNS namespace and protocol to extract that information when it isn't actually there. See the "Additional Background Information" section of the working group wiki for more details: https://trac.tools.ietf.org/wg/dbound/trac/wiki/AdditionalBackgroundInformation For the purpose of this work, "domain names" are identifiers used by organizations and services, independent of underlying protocols or mechanisms, and an "organizational domain" is defined as a name that is at the top of an administrative hierarchy, defining transition from one "outside" administrative authority to another that is "inside" the organization. The current way most of this is handled is via a list published at publicsuffix.org (commonly known as the "Public Suffix List" or "PSL"), and the general goal is to accommodate anything people are using that for today. However, there are broadly speaking two use patterns. The first is a "top ancestor organization" case. In this case, the goal is to find a single superordinate name in the DNS tree that can properly make assertions about the policies and procedures of subordinate names. The second is to determine, given two different names, whether they are governed by the same administrative authority. The goal of the DBOUND working group is to develop a unified solution, if possible, for determining organizational domain boundaries. However, the working group may discover that the use cases require different solutions. Should that happen, the working group will develop those different solutions, using as many common pieces as it can. Solutions will not involve the proposal of any changes to the DNS protocol. They might involve the creation of new resource record types. This working group will not seek to amend the consuming protocols themselves (standards for any web, email, or other such protocols) under this charter. If such work is desirable, it will be assigned to another appropriate working group or defined as a work item in an updated charter. Rechartering will only be considered after completion of the base work. The working group has a pre-IETF draft to consider as a possible starting point: draft-sullivan-dbound-problem-statement Milestones: TBD From nobody Fri Apr 10 11:33:15 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 845771A8A5E for ; Fri, 10 Apr 2015 11:33:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.112 X-Spam-Level: X-Spam-Status: No, score=-5.112 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 DZ0NoaoKiOd3 for ; Fri, 10 Apr 2015 11:33:11 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A53CA1A1BF5 for ; Fri, 10 Apr 2015 11:33:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1428690791; x=1460226791; h=message-id:date:from:mime-version:to:subject:sender: content-transfer-encoding; bh=OFUyYWqlEHAUhqE0WN4JvRYnFlXwjOyi/s8pGs78LDc=; b=E3+KtX8+74Pk7fiIg0HuU9uj+sX6i+AD88iG6jpwLe9jnqJc/NX16hN2 3D7yfoXTY6inCw9DAzbuwli/bxYaHwaOEmTXfaAXcwMKwdTMxbSo5x6tH vr3NDbSKJe8phvYxkuDfN9rVx+My9LH0NgNdkfcWPFtpT/ph10Uoc9/k6 Q=; X-IronPort-AV: E=McAfee;i="5700,7163,7767"; a="112747333" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Apr 2015 11:33:10 -0700 X-IronPort-AV: E=Sophos;i="5.11,558,1422950400"; d="scan'208";a="945594235" Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 10 Apr 2015 11:33:10 -0700 Received: from resnick2.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Fri, 10 Apr 2015 11:33:10 -0700 Message-ID: <55281764.10107@qti.qualcomm.com> Date: Fri, 10 Apr 2015 13:33:08 -0500 From: Pete Resnick , "Murray S. Kucherawy" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Sender: Pete Resnick Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01E.na.qualcomm.com (10.85.0.31) To NASANEXM01F.na.qualcomm.com (10.85.0.32) Archived-At: Subject: [dbound] Getting official work started X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 18:33:13 -0000 Folks, As you saw, the WG is now officially chartered. There's already been quite a bit of discussion on the list and we don't want to lose any of that work going forward. So your humble chairs will be talking early next week, come up with a summary of where we think things are, put together a specific plan of action going forward (with milestones), and let you all correct us if you think we've blown it. We think we can move this work along right quick. Look for a message from us early next week. Murray & Pete From nobody Sat Apr 11 14:45:56 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 357911B2D61 for ; Sat, 11 Apr 2015 14:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.6 X-Spam-Level: *** X-Spam-Status: No, score=3.6 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_12=0.6, MANGLED_SAVELE=2.3, SPF_PASS=-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 zjSmzOpiDGzp for ; Sat, 11 Apr 2015 14:45:54 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (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 93D9B1B2D5E for ; Sat, 11 Apr 2015 14:45:54 -0700 (PDT) Received: by iebmp1 with SMTP id mp1so41069452ieb.0 for ; Sat, 11 Apr 2015 14:45:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=hVdcGQDGfQsVxdlRlhQTAaDzT6bJ0xLm2r0C8SXnagQ=; b=ErlmYvjx3t3vCaePpfXk+553HUPjNMeD1iOwJlt/VTyrcrMA7OYpoQaBtRhT71QXcy ps7if0hG3twxvvu4/22KpvLlK7d6UmSywlyJg5i7tUOeSQoN5B9xKbM29pZmVZMVTFWE Ml0HLc1QXGYAIYld20Hcd1dP1IbFDVOlV0k1bSgVwyhA7HPqZ7Pw5J34NUaYVUnhlzZL VkvA5SIEkDUXM5vECj873cUi7DVjKtOUQcZpoUZR1+/TKw17t6WjgAlShLePIk1qfsQV MFzurBJAmj0Dj0aKtG8jCshFoKXWLK8+KSh3Xa3kJMpb4+G/mp0V0R9UARkR7k0xvvMP /R+w== MIME-Version: 1.0 X-Received: by 10.42.20.197 with SMTP id h5mr11069403icb.22.1428788754045; Sat, 11 Apr 2015 14:45:54 -0700 (PDT) Received: by 10.36.77.15 with HTTP; Sat, 11 Apr 2015 14:45:53 -0700 (PDT) In-Reply-To: <877ftm4ur5.fsf@alice.fifthhorseman.net> References: <877ftm4ur5.fsf@alice.fifthhorseman.net> Date: Sat, 11 Apr 2015 17:45:53 -0400 Message-ID: From: Jeffrey Walton To: Daniel Kahn Gillmor Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "dbound@ietf.org" Subject: Re: [dbound] Another use case to consider.... X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: noloader@gmail.com List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2015 21:45:56 -0000 > The only DNS labels included in this certificate are AIA and CRL > distribution points. > > How would you apply dbound to limit the scope of this organizational > intermediate certificate? I'm trying to get that cleared up now at https://www.ietf.org/mail-archive/web/pkix/current/msg33275.html. The first step in handling them correctly is identifying them. But I suspect all of this is fundamentally broken. Unconstrained subordinates issued to an organization is just a bad idea... Jeff On Wed, Apr 8, 2015 at 9:25 AM, Daniel Kahn Gillmor wrote: > On Tue 2015-04-07 22:33:20 -0400, Jeffrey Walton wrote: > >> The use case is verifying the end-entity certificate issued by an >> organizational subordinate CA *without* constraints. >> >> In the case of organization subordinate CA *without* constraints, the >> independent 3rd party auditor (the RA) was removed *and* a name >> constraint was not used to enforce policy. Lack of name constraints >> means we don't know what domains the organization is authorized to >> issue for. >> >> It seems like DBOUND would be a good place to look for an answer to >> the question: what domains is an organizational subordinate CA >> authorized to issue for? > > The implication here is that the organizational subordinate CA doesn't > have name constraints, but *does* have some DNS label embedded in it > somehow. is that right? > > Take a look at the "Google Internet Authority G2" intermediate > organizational certificate below (with parsed output from GnuTLS's > certtool -i). > > The only DNS labels included in this certificate are AIA and CRL > distribution points. > > How would you apply dbound to limit the scope of this organizational > intermediate certificate? > > I tend to think that explicit name constraints are the way to go, since > they are already pretty clearly specified; we just need to actually get > tools to respect them (and CAs to issue intermediate certs with them)! > > --dkg > > > X.509 Certificate Information: > Version: 3 > Serial Number (hex): 023a76 > Issuer: C=US,O=GeoTrust Inc.,CN=GeoTrust Global CA > Validity: > Not Before: Fri Apr 05 15:15:55 UTC 2013 > Not After: Sat Dec 31 23:59:59 UTC 2016 > Subject: C=US,O=Google Inc,CN=Google Internet Authority G2 > Subject Public Key Algorithm: RSA > Algorithm Security Level: Medium (2048 bits) > Modulus (bits 2048): > 00:9c:2a:04:77:5c:d8:50:91:3a:06:a3:82:e0:d8:50 > 48:bc:89:3f:f1:19:70:1a:88:46:7e:e0:8f:c5:f1:89 > ce:21:ee:5a:fe:61:0d:b7:32:44:89:a0:74:0b:53:4f > 55:a4:ce:82:62:95:ee:eb:59:5f:c6:e1:05:80:12:c4 > 5e:94:3f:bc:5b:48:38:f4:53:f7:24:e6:fb:91:e9:15 > c4:cf:f4:53:0d:f4:4a:fc:9f:54:de:7d:be:a0:6b:6f > 87:c0:d0:50:1f:28:30:03:40:da:08:73:51:6c:7f:ff > 3a:3c:a7:37:06:8e:bd:4b:11:04:eb:7d:24:de:e6:f9 > fc:31:71:fb:94:d5:60:f3:2e:4a:af:42:d2:cb:ea:c4 > 6a:1a:b2:cc:53:dd:15:4b:8b:1f:c8:19:61:1f:cd:9d > a8:3e:63:2b:84:35:69:65:84:c8:19:c5:46:22:f8:53 > 95:be:e3:80:4a:10:c6:2a:ec:ba:97:20:11:c7:39:99 > 10:04:a0:f0:61:7a:95:25:8c:4e:52:75:e2:b6:ed:08 > ca:14:fc:ce:22:6a:b3:4e:cf:46:03:97:97:03:7e:c0 > b1:de:7b:af:45:33:cf:ba:3e:71:b7:de:f4:25:25:c2 > 0d:35:89:9d:9d:fb:0e:11:79:89:1e:37:c5:af:8e:72 > 69 > Exponent (bits 24): > 01:00:01 > Extensions: > Authority Key Identifier (not critical): > c07a98688d89fbab05640c117daa7d65b8cacc4e > Subject Key Identifier (not critical): > 4add06161bbcf668b576f581b6bb621aba5a812f > Basic Constraints (critical): > Certificate Authority (CA): TRUE > Path Length Constraint: 0 > Key Usage (critical): > Certificate signing. > CRL signing. > CRL Distribution points (not critical): > URI: http://g.symcb.com/crls/gtglobal.crl > Authority Information Access (not critical): > Access Method: 1.3.6.1.5.5.7.48.1 (id-ad-ocsp) > Access Location URI: http://g.symcd.com > Certificate Policies (not critical): > 1.3.6.1.4.1.11129.2.5.1 > Signature Algorithm: RSA-SHA1 > Signature: > 27:8c:cf:e9:c7:3b:be:c0:6f:e8:96:84:fb:9c:5c:5d > 90:e4:77:db:8b:32:60:9b:65:d8:85:26:b5:ba:9f:1e > de:64:4e:1f:c6:c8:20:5b:09:9f:ab:a9:e0:09:34:45 > a2:65:25:37:3d:7f:5a:6f:20:cc:f9:fa:f1:1d:8f:10 > 0c:02:3a:c4:c9:01:76:96:be:9b:f9:15:d8:39:d1:c5 > 03:47:76:b8:8a:8c:31:d6:60:d5:e4:8f:db:fa:3c:c6 > d5:98:28:f8:1c:8f:17:91:34:cb:cb:52:7a:d1:fb:3a > 20:e4:e1:86:b1:d8:18:0f:be:d6:87:64:8d:c5:0a:25 > 42:51:ef:b2:38:b8:e0:1d:d0:e1:fc:e6:f4:af:46:ba > ef:c0:bf:c5:b4:05:f5:94:75:0c:fe:a2:be:02:ba:ea > 86:5b:f9:35:b3:66:f5:c5:8d:85:a1:1a:23:77:1a:19 > 17:54:13:60:9f:0b:e1:b4:9c:28:2a:f9:ae:02:34:6d > 25:93:9c:82:a8:17:7b:f1:85:b0:d3:0f:58:e1:fb:b1 > fe:9c:a1:a3:e8:fd:c9:3f:f4:d7:71:dc:bd:8c:a4:19 > e0:21:23:23:55:13:8f:a4:16:02:09:7e:b9:af:ee:db > 53:64:bd:71:2f:b9:39:ce:30:b7:b4:bc:54:e0:47:07 > Other Information: > SHA1 fingerprint: > bbdce13e9d537a5229915cb123c7aab0a855e798 > SHA256 fingerprint: > c3f697a92a293d86f9a3ee7ccb970e20e0050b8728cc83ed1b996ce9005d4c36 > Public Key ID: > 43dad630ee53f8a980ca6efd85f46aa37990e0ea > Public key's random art: > +--[ RSA 2048]----+ > | | > | | > | + | > | . = = | > | . . .o S o | > | . oo = + . | > | . ...o = o | > |......++ o | > |.E+ o=o.. | > +-----------------+ > > -----BEGIN CERTIFICATE----- > MIID8DCCAtigAwIBAgIDAjp2MA0GCSqGSIb3DQEBBQUAMEIxCzAJBgNVBAYTAlVT > MRYwFAYDVQQKEw1HZW9UcnVzdCBJbmMuMRswGQYDVQQDExJHZW9UcnVzdCBHbG9i > YWwgQ0EwHhcNMTMwNDA1MTUxNTU1WhcNMTYxMjMxMjM1OTU5WjBJMQswCQYDVQQG > EwJVUzETMBEGA1UEChMKR29vZ2xlIEluYzElMCMGA1UEAxMcR29vZ2xlIEludGVy > bmV0IEF1dGhvcml0eSBHMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB > AJwqBHdc2FCROgajguDYUEi8iT/xGXAaiEZ+4I/F8YnOIe5a/mENtzJEiaB0C1NP > VaTOgmKV7utZX8bhBYASxF6UP7xbSDj0U/ck5vuR6RXEz/RTDfRK/J9U3n2+oGtv > h8DQUB8oMANA2ghzUWx//zo8pzcGjr1LEQTrfSTe5vn8MXH7lNVg8y5Kr0LSy+rE > ahqyzFPdFUuLH8gZYR/Nnag+YyuENWllhMgZxUYi+FOVvuOAShDGKuy6lyARxzmZ > EASg8GF6lSWMTlJ14rbtCMoU/M4iarNOz0YDl5cDfsCx3nuvRTPPuj5xt970JSXC > DTWJnZ37DhF5iR43xa+OcmkCAwEAAaOB5zCB5DAfBgNVHSMEGDAWgBTAephojYn7 > qwVkDBF9qn1luMrMTjAdBgNVHQ4EFgQUSt0GFhu89mi1dvWBtrtiGrpagS8wEgYD > VR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAQYwNQYDVR0fBC4wLDAqoCig > JoYkaHR0cDovL2cuc3ltY2IuY29tL2NybHMvZ3RnbG9iYWwuY3JsMC4GCCsGAQUF > BwEBBCIwIDAeBggrBgEFBQcwAYYSaHR0cDovL2cuc3ltY2QuY29tMBcGA1UdIAQQ > MA4wDAYKKwYBBAHWeQIFATANBgkqhkiG9w0BAQUFAAOCAQEAJ4zP6cc7vsBv6JaE > +5xcXZDkd9uLMmCbZdiFJrW6nx7eZE4fxsggWwmfq6ngCTRFomUlNz1/Wm8gzPn6 > 8R2PEAwCOsTJAXaWvpv5Fdg50cUDR3a4iowx1mDV5I/b+jzG1Zgo+ByPF5E0y8tS > etH7OiDk4Yax2BgPvtaHZI3FCiVCUe+yOLjgHdDh/Ob0r0a678C/xbQF9ZR1DP6i > vgK66oZb+TWzZvXFjYWhGiN3GhkXVBNgnwvhtJwoKvmuAjRtJZOcgqgXe/GFsNMP > WOH7sf6coaPo/ck/9Ndx3L2MpBngISMjVROPpBYCCX65r+7bU2S9cS+5Oc4wt7S8 > VOBHBw== > -----END CERTIFICATE----- From nobody Thu Apr 16 12:17:55 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8E241B34F7 for ; Thu, 16 Apr 2015 12:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 E4E5DHpiD9mP for ; Thu, 16 Apr 2015 12:17:53 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 199B01B34F6 for ; Thu, 16 Apr 2015 12:17:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1429211873; x=1460747873; h=message-id:date:from:mime-version:to:subject:sender: content-transfer-encoding; bh=urTdg+WudnmhfTSCJoF1/qMd1yCkqfrYUqYmLm+lSUk=; b=UJLlUlH5XaO3rNZHSU4p0MHwGV+0BR8VyWDXm1kVpsRrNS1NoQkdy5Mk HnDX0Xejp8JpchluOv9dyxysi9RxNTfjXjbV2TZ0Lql+Ul0A65ysGMu0R f0tn8Yeex4fhFZzthkSSxjCLC8zi4k2AliXDpmAhraKgNZ4auORTPFc8D w=; X-IronPort-AV: E=McAfee;i="5700,7163,7773"; a="87093479" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by sabertooth01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Apr 2015 12:17:51 -0700 X-IronPort-AV: E=Sophos;i="5.11,589,1422950400"; d="scan'208";a="950109885" Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 16 Apr 2015 12:17:51 -0700 Received: from presnick-mac.local (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Thu, 16 Apr 2015 12:17:50 -0700 Message-ID: <55300ADD.4080001@qti.qualcomm.com> Date: Thu, 16 Apr 2015 14:17:49 -0500 From: Pete Resnick , "Murray S. Kucherawy" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Sender: Pete Resnick Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01F.na.qualcomm.com (10.85.0.32) To NASANEXM01F.na.qualcomm.com (10.85.0.32) Archived-At: Subject: [dbound] Schedule and milestones X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 19:17:54 -0000 We're still plowing through the mailing list to come up with an issues list from previous discussions, but wanted to get a "plan" on the table. Here's what we've come up with, including due dates for each of the initial milestones: * Stabilization of the problem statement (May 15, 2015) * no intent to publish * could move it to the Wiki * Proposals for solutions (June 2, 2015) * on-list discussion of drafts * expect them to be Standards Track or Experimental; these are protocols * Drafts for discussion at IETF 93 (July 6, 2015) * Calls for Adoption of some documents at IETF 93 (July 24, 2015) That's a pretty aggressive beginning, but we think it is doable. Concerns? Murray and Pete