Re: [Acme] Review of draft-friel-acme-subdomains-02
"Owen Friel (ofriel)" <ofriel@cisco.com> Wed, 23 September 2020 06:29 UTC
Return-Path: <ofriel@cisco.com>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73D763A09F1 for <acme@ietfa.amsl.com>; Tue, 22 Sep 2020 23:29:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.62
X-Spam-Level:
X-Spam-Status: No, score=-9.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=Qd2H0Ayb; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Gy2KfFbH
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 O6CE3obU2yyI for <acme@ietfa.amsl.com>; Tue, 22 Sep 2020 23:29:20 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17F2E3A09EE for <acme@ietf.org>; Tue, 22 Sep 2020 23:29:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11414; q=dns/txt; s=iport; t=1600842559; x=1602052159; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=8iisi6mnt4DltNrnLn9DtxbrwF4G26kSVRQjUZgeYDE=; b=Qd2H0AybTKU7vPbKlUvVYTQkXcdMjVSkYA5Mg0NjOPPNesayh9n0k5dW hDA9Vl0JK6gYpGjjp9+nTQoMdukFCvAod5wluzSTwIYpSWf2PWp3zIfM+ Z3dUpYugykszMbhW4c1emZeL/qPACz30paZOUm51g5BFZuSrXEeA4dZGv U=;
IronPort-PHdr: 9a23:i/MhNhUkeeFNFRCugai/+VjcFLzV8LGuZFwc94YnhrRSc6+q45XlOgnF6O5wiEPSBN+LufxJj+vOvq/pQnQN+9CKt3VROJBPVhpQj8IQkkRgBcOeEkT0IbbsaDByB8VNUlJpvhTZeUhYEcrzfRve93u16zNBFBj7NBJ4Ke3uAoPIyc+w0rP695jaeQ4dgj27bPt7Jwm3qgOEsM4QjMNiJ689xwGPrGFPfrFdxHhjIhSYmBOv6w==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DSCQAR6mpf/5NdJa1fHgEBCxIMQIMhIy4HcFkvLIQ6g0YDjXiYdoFCgREDVQsBAQENAQEYDQgCBAEBhEsCF4IPAiQ4EwIDAQELAQEFAQEBAgEGBG2FXAyFcgEBAQMBAQEQEREMAQEsBAcBBAcEAgEIEQMBAQEBAgImAgICJQsVCAgCBA4FCBqDBYJLAw4gAQ6rFQKBOYhhdoEygwEBAQWFJBiCEAmBDiqCcYNphjQeG4FBP4ERQ1GBfD6CIzkBAQIBgScBEgEJGoMVM4ItkzWSdZELCoJniHeGUosngwyBJ4hSBZN4nAKBXZUbAgQCBAUCDgEBBYFrI2dwcBU7gmkJRxcCDY4fg3GFFIVCdAIBNAIGAQkBAQMJfI1jAQE
X-IronPort-AV: E=Sophos;i="5.77,293,1596499200"; d="scan'208";a="737840005"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 23 Sep 2020 06:29:18 +0000
Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 08N6TIr9012421 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 23 Sep 2020 06:29:18 GMT
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 23 Sep 2020 01:29:18 -0500
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 23 Sep 2020 01:29:17 -0500
Received: from NAM10-BN7-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 23 Sep 2020 01:29:17 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ay8thb7+XFuX3ijftSUo5Wm2bDqrPIDQMPXSKqvQOGY5SFoc+uc4BSbXqb/+S/Jr4ePskSkIdrMPI76XXnhF50PFbDXD3ahCq5Nq6oFZ1KtmWODOkIXfl9SJre5BlHdqQULoNAaNStAlJLgw2juYFrjvHw6vSdzfHineX7TTjhx/Q8AtNrqUcakenhs3rzkP+GEKjhqMLMpLZau3OPVKubRS9xiP7HmF25K2cxKcCcAPi0DwkHOWOmZPTCWXcuwDwc6txYJMZGVzBtqcUYe4Y5hSR1YqudqxGfCuHmsmeSo++wQ/XN0M265vJBMUnYVEMtq0JfLUhqMKesVTs89X3g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8iisi6mnt4DltNrnLn9DtxbrwF4G26kSVRQjUZgeYDE=; b=a2PgWZmBYdfNkcFElsJPb6UMdtsFkLvs1h5dfil13/b7t2tBxJ+0kOBepn3XHj5GZRFQLhwFb/PAX+faljk/2XN7YTJVMpsBvcHE4KSzeWWP6VI/RMjUr2nEO3BFTRC1zcJE4diSKJtYQvUBz7Ei9ivm0udejvnZKTBIXdJraBtwPyEQEjiCqbuw6B6b76rxiHrkuE0Nxdm1Y9szj/B7ouBPdStG3131AlE6/pV7s98P1QDz7B19x0vrxaIMTZeOsZiRJfKlJeG5e5FF9L9+SH66xDBbXcAP09J/Da/IP2X9NAFUCA9EXX9h/6i5lyN7E2YSYYMR3WDxKKj1oPg2mw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8iisi6mnt4DltNrnLn9DtxbrwF4G26kSVRQjUZgeYDE=; b=Gy2KfFbHQWzc+F7jldeXpRl99POJ9Uxu4YcVx9eyWEY4nET/bQPYqLEvZPrL2H2bt1V7V+tR1dseuM9ERoS4VaDRKNmZMyBZTrImVcDcXz2xJdte/iTOknLmaFV/syzfxyiyqr1HjkIItiKsVN7bui7qamDQx+klivJKUzgmnGE=
Received: from CY4PR11MB1685.namprd11.prod.outlook.com (2603:10b6:903:22::23) by CY4PR11MB1927.namprd11.prod.outlook.com (2603:10b6:903:120::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3391.14; Wed, 23 Sep 2020 06:29:15 +0000
Received: from CY4PR11MB1685.namprd11.prod.outlook.com ([fe80::acba:ff73:21ab:6c5d]) by CY4PR11MB1685.namprd11.prod.outlook.com ([fe80::acba:ff73:21ab:6c5d%3]) with mapi id 15.20.3391.026; Wed, 23 Sep 2020 06:29:15 +0000
From: "Owen Friel (ofriel)" <ofriel@cisco.com>
To: Felipe Gasper <felipe@felipegasper.com>
CC: Russ Housley <housley@vigilsec.com>, IETF ACME <acme@ietf.org>
Thread-Topic: [Acme] Review of draft-friel-acme-subdomains-02
Thread-Index: AQHWarDVa1jsQHCu8UGRQ/b0xVxoz6lVRNdwgAHOEYCAHu5tIA==
Date: Wed, 23 Sep 2020 06:29:15 +0000
Message-ID: <CY4PR11MB16851C6BFD88C213BDD4EED9DB380@CY4PR11MB1685.namprd11.prod.outlook.com>
References: <39F039BC-BFEA-49D4-9D75-267A5446FE99@vigilsec.com> <CY4PR11MB168513A0ECC978396BEF5313DB2F0@CY4PR11MB1685.namprd11.prod.outlook.com> <9C66A87D-070B-43E9-BAF1-EF971144358D@felipegasper.com>
In-Reply-To: <9C66A87D-070B-43E9-BAF1-EF971144358D@felipegasper.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: felipegasper.com; dkim=none (message not signed) header.d=none; felipegasper.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [2001:420:c0d4:1002::305]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b1d3cb2f-a4a4-4e45-0c65-08d85f89fe83
x-ms-traffictypediagnostic: CY4PR11MB1927:
x-microsoft-antispam-prvs: <CY4PR11MB1927F61D572ADD7842F2AAFEDB380@CY4PR11MB1927.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:5797;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Klwc/VsQnDBsSjJ6UcULMHBJrKZ9O+5ojXb6oV38ZCX3fBgdFC2chCYUM5CKcRd/gOaf0gcMVACR4CBKqswEHt1Cw74xa6nyIZrr9E6XvnKD4WoUUxSzhBf0hGpTZypqvxCTYcvT3onCX6AWf2aNTd5vuLriW/8qMTVWZn04d+Dk3v2QcKQyiN0Jm282u/mxm3O7S75yEusiSl6Ul2FWUBXGdmBODs9HqAJXSqJwfqus0cp95SFIBFB2AETT8cFseDO9vPIvDFdfUP2D/2GIksRbHi37M0YJvfKg63vw+VsztYvNN2BqY/ta4OYlzA7bgzwpesnSzAUvoGM6Rr0cCc4fQ4bcHufh9vWBIaaUJCk7uxycBMi2kUtJLNZo9ev9IjdFm+5XkrYdkhY4UhTtwjrl5aKobmP5uU1dxruA3AnUgl/NFqPXYJW04rH+In3x
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CY4PR11MB1685.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(39860400002)(136003)(366004)(376002)(346002)(9686003)(64756008)(8676002)(86362001)(66946007)(66476007)(33656002)(2906002)(6916009)(186003)(8936002)(71200400001)(5660300002)(66446008)(66556008)(4326008)(83380400001)(6506007)(478600001)(53546011)(55016002)(54906003)(76116006)(52536014)(7696005)(966005)(316002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: 4GAWGNqcV+O+LtXz5SLws+f7cTWtvcWwdkgO6BgGZsbHVtG+FsU8cwH0RtJpAE6RhvQmIcks2hS5iiHixWpq77KsU1bS22IBzmiNBBUcXUjw9UegiKuocpjoFBd4FwZEsEo0US1tb+HwVnZ0UaDYMk6XOIFvDWnexchTYTFLnS5bd1ZmhEs3UmMudyq0NNTWDCNtWJ3lIHnbNoMQ/zdC/L3Jr6mefFf3wTmNi41JjHsPE/+5oO25cjvOzcsLD0qYDBBOzW7nij6p8v+ewFSErL0qBpSG44oEEkh++BcLLF4n8/bdFZhttqvElIbwJV9WgWw5Px/OW0gI3dQYoScY9OBkc/DDJm397n/nrz7kK2ZP04J5x0j8FaS8btRJJcmrw4bjSdiFMA0jgib0YELox0x1TvidxWBExv3F2pgb7MC//w1qGFqP1VdGmM0WxxdhvvNgSUoAhvvYPjHSPKBt7pbJQT1lnN6tiq33naoXbLrx2GTtN0JkzXyEsYrT1Bf27q0bGevAbGcRNbY3RvqNwoSt7hY9rvZXOa7+WEiLETGbQwODbesgQj/7ZPzc15CxjpMpphtaAHLneTAr+Oh15zEy6ZKqLfy0CrUCOpfRpcMaZ7uCKA/koj9OcUU3A3VwijrMqRHFaR/ydcYgjK8u14zdeX4xlJhDGV6NISEfrBo=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CY4PR11MB1685.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b1d3cb2f-a4a4-4e45-0c65-08d85f89fe83
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Sep 2020 06:29:15.7445 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: fK2fMoGsSA6nvCEYMPN9PEItUaZwU1h6ganFW5CtFNLLcGvuvUpS9smVBACnXorH6VpBy2WR/0S1qRUeFr81Mg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR11MB1927
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com
X-Outbound-Node: rcdn-core-11.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/63vx7clV_pzrM7Pxaq0uYZfiVpo>
Subject: Re: [Acme] Review of draft-friel-acme-subdomains-02
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Automated Certificate Management Environment <acme.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/acme>, <mailto:acme-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/acme/>
List-Post: <mailto:acme@ietf.org>
List-Help: <mailto:acme-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/acme>, <mailto:acme-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Sep 2020 06:29:22 -0000
Hi Felipe, all, > What if … there’s no need for a standard for this? Or at least, the standard would require no significant changes to the protocol? The current draft-02 attempted to minimize the changes to the standard e.g. there are no significant changes proposed to any of the objects, merely addition of one new field to the authorization object, and one new field to the directory metadata. The core idea of what -02 does is allow a client to submit a newOrder / newAuthz for one identifier (e.g. sub.example.com) and the server to choose the parent identifier (e.g. example.com) that it requires challenge fulfilment on and specify that in the authorization object. That could of course be generalised so that a client could submit a newOrder / newAuthz for e.g. foo1.foo2.bar.example.com and the server could chose the exact identifier or any of the parents for authorization and challenge fulfilment: - foo1.foo2.bar.example.com OR - foo2.bar.example.com OR - bar.example.com OR - example.com With the current RFC8555 specification and structure of order and authorization objects, the server can only choose one of those identifiers to return in the authorization object, it cannot choose multiple identifiers and give the client the option of which identifier challenge to fulfil. The current subdomains-02 draft outlines how that could work. The two big design / requirements questions to ask are: 1. Does the client need a mechanism to indicate that they want to authz a parent domain and not the explicit subdomain identifier? Or a mechanism to indicate that they are happy to authz against a choice of identifiers? E.g. for foo1.foo2.bar.example.com, should the client be able to specify anywhere from 1 to 4 identifiers they are willing to fulfil? 2. Does the server need a mechanism to provide a choice of identifiers to the client and let the client chose which to fulfil? E.g. for foo1.foo2.bar.example.com, should the server be able to specify anywhere from 1 to 4 identifiers that the client can pick from to fulfil? Both 1 and 2 would require changes to the JSON object definitions. For 1, each identifier in the newOrder or newAuthz requests would need a child array of alternative identifiers the client is willing to fulfil. For 2, the current order object contains a set of authorizations that must all be completed, the authorization object contains a single identifier that all challenges are against, so therefore its not possible for the server to give the client a choice of identifiers to pick from. The examples I gave previously in the non-RFC6761-compliant email thread were a few options for addressing 2 by enhancing the JSON objects. I also noticed this text in https://tools.ietf.org/html/rfc8555#section-7.1.3: authorizations (required, array of string): ...The authorizations required are dictated by server policy; there may not be a 1:1 relationship between the order identifiers and the authorizations required. Which is another indication that it appears valid for a client to send an order for a subdomain, and the server to pick any of the parent domains up to and including the base domain for authz fulfilment. I think the key thing is whether 1 and/or 2 are required. Based on that, I can provide example JSONs that enable 1 and/or 2 and make them RFC6717 compliant and align with RFC8555 examples. Cheers, Owen -----Original Message----- From: Felipe Gasper <felipe@felipegasper.com> Sent: 03 September 2020 21:14 To: Owen Friel (ofriel) <ofriel@cisco.com> Cc: Russ Housley <housley@vigilsec.com>; IETF ACME <acme@ietf.org> Subject: Re: [Acme] Review of draft-friel-acme-subdomains-02 Hi all, What if … there’s no need for a standard for this? Or at least, the standard would require no significant changes to the protocol? The application that I help manage integrates alternately with Sectigo and with Let’s Encrypt. Sectigo, when they verify domain control, always checks parent domains along with the domain(s) given in the certificate order. If any of those checks succeeds, the authz is valid. Perhaps the standard could be defined merely in those terms, such that CAs who so choose could simply indicate in the authz objects that parent/ancestor domains suffice for the verification? This would also allow CAs to mandate that such liberty apply only to DNS-based authz, while still requiring HTTP-based authz to be against the literal identifier. A bit of context: our application runs on shared-hosting servers that we don’t administer, subject to firewall rules that neither we nor the admin may control. The admins run the gamut of competence, from highly-skilled on down. The domains are end-user-controlled, not necessarily registered with the same organization that administers the server. We’ve seen all kinds of crazy setups that complicate SSL issuance, as a result of which our certificate-provision logic attempts to accommodate potential misconfigurations. Sectigo’s acceptance of ancestor domains for authz helps toward that end since all we have to do to capitalize on it is to create the relevant HTTP docroot files or DNS records all at once, then send the order. Some oddity might frustrate direct authz against “www.whatever.bobs-store.com”, but as long as “bobs-store.com” works, we can still secure the subdomain. An alternate implementation might be for authz objects to include challenges against whatever ancestor domains and methods the server allows; thus, if I do newAuthz against “foo.bar.example.com”, I might get back: - http-01, foo.bar.example.com - tls-alpn-01, foo.bar.example.com - dns-01, foo.bar.example.com - dns-01, bar.example.com - dns-01, example.com The disadvantage to that, for us, would be that we’d have to recreate the authz for every failure. I assume that that’s also disadvantageous for the ACME server--more so than simply doing “fallback” authz checks against parent domains. That aside, as to Owen’s proposal document: - How is the client to indicate that they want to authz the parent domain (example.com) rather than the literal identifier (sub0.example.com)? And for foo.bar.example.com, how shall the client indicate which parent domain is to be used for authz? Thank you! cheers, -Felipe Gasper > On Sep 2, 2020, at 5:41 AM, Owen Friel (ofriel) <ofriel=40cisco.com@dmarc.ietf.org> wrote: > > Thanks Russ. I've addressed all these in github at: https://github.com/upros/acme-subdomains/blob/master/draft-friel-acme-subdomains.md. I have not pushed out draft-03 yet, lets see what Jacob and Felipe have to say on the related thread about challenge options, and I will incorporate then. > > > -----Original Message----- > From: Acme <acme-bounces@ietf.org> On Behalf Of Russ Housley > Sent: 05 August 2020 06:44 > To: IETF ACME <acme@ietf.org> > Subject: [Acme] Review of draft-friel-acme-subdomains-02 > > Document: draft-friel-acme-subdomains-02 > Reviewer: Russ Housley > Date: 2020-08-04 > > Major Concern: > > The TODO markers regarding wildcard domain names, the 200 response code, and the security considerations should be filled in with strawman text before this I-D is adopted by the ACME WG. > > > Minor Concerns: > > General: s/certificate authority/certification authority/ (many) > > Abstract: s/certificate authority policy/certificate policy/ > > Introduction: s/X.509 (PKIX)/X.509v3 (PKIX) [RFC5280]/ > > Terminology: Correct CA, please. See above. > > Terminology: Please add a definition of subdomain. > > > Nits: > > Section 3: says: > > 3. client sends POST-as-GET requests to retrieve the > "authorizations", with the downloaded "authorization" object(s) > containing the "identifier" that the client must prove control of > > s/client must prove control of/client must prove that they control/ > > There is something wrong with the table formatting in Section 6.2. > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme
- [Acme] Review of draft-friel-acme-subdomains-02 Russ Housley
- Re: [Acme] Review of draft-friel-acme-subdomains-… Owen Friel (ofriel)
- Re: [Acme] Review of draft-friel-acme-subdomains-… Felipe Gasper
- Re: [Acme] Review of draft-friel-acme-subdomains-… Salz, Rich
- Re: [Acme] Review of draft-friel-acme-subdomains-… Michael Richardson
- Re: [Acme] Review of draft-friel-acme-subdomains-… Owen Friel (ofriel)