From nobody Mon Jul 3 08:10:29 2017 Return-Path: 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 9D05D13167B for ; Mon, 3 Jul 2017 08:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 RuMeSfspfKC9 for ; Mon, 3 Jul 2017 08:10:22 -0700 (PDT) Received: from mail.core-networks.de (mail.core-networks.de [IPv6:2001:1bc0:d::4:9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6076C131679 for ; Mon, 3 Jul 2017 08:10:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.core-networks.de id 1dS2zT-0008JH-6w with ESMTPSA (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) for acme@ietf.org; Mon, 03 Jul 2017 17:10:19 +0200 To: acme@ietf.org From: "Rene 'Renne' Bartsch, B.Sc. Informatics" Message-ID: <0ed4eb20-d8b9-38c6-d3d1-9c02c0508a49@bartschnet.de> Date: Mon, 3 Jul 2017 17:10:18 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: de-DE Archived-At: Subject: [Acme] Automated procedure for DNS challenge records? X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 15:10:28 -0000 Hello, is there any procedure proposed in the ACME documents to update the ACME resource records on the primary DNS server (e.g. DynDNS/TSIG RFCs 2136/2845)? Best regards, Renne From nobody Mon Jul 3 08:17:24 2017 Return-Path: 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 A4895131681 for ; Mon, 3 Jul 2017 08:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xkzrJtWtxgRc for ; Mon, 3 Jul 2017 08:17:20 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DC6F13167F for ; Mon, 3 Jul 2017 08:17:20 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v63FHBtT016168; Mon, 3 Jul 2017 16:17:11 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=7BlLWuAqbMQ/SCIUKfj4pvk4fnUaPi+z/x3uvOUOfx0=; b=Bi1LtgJZxHyZH/HVBiyJf2rKdTGE1PkO1OcoMih/4+MFYWiDjr7WwSZj/dhMe8/YWBC9 XpQBmizySV0erFieQ6rnSWXVGpFM1hLW0FEVGSReiausoGCN8wK0FUJ/ic9xAdS39gPC NjrQ+TwsrKwIsFeam66QqNmbd1rhukkLj7KHrOsWOI4qrNeCuhWdB1Du+ZadQw/Yry72 tZZsCBohy8Eov8Rl8kFwIhRGnB1HYbq0XnWrCexeetg6pF1dDWtUlEAfeLXe+SoWZf2J h845u/kmSv85OtQiJAJTfIuaQkWP2wZJusVDwOux+kA/gXuCtpPKhCzKeibtjvzOsgNb xw== Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050096.ppops.net-00190b01. with ESMTP id 2be456ghwy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 03 Jul 2017 16:17:10 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v63FG6Db020355; Mon, 3 Jul 2017 11:17:06 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint3.akamai.com with ESMTP id 2be72uxded-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 03 Jul 2017 11:17:06 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 3 Jul 2017 11:17:02 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Mon, 3 Jul 2017 11:17:02 -0400 From: "Salz, Rich" To: "Rene 'Renne' Bartsch, B.Sc. Informatics" , "acme@ietf.org" Thread-Topic: [Acme] Automated procedure for DNS challenge records? Thread-Index: AQHS9A6Gl/VXFHhkE0qGQUwoFA975qJCNpBw Date: Mon, 3 Jul 2017 15:17:01 +0000 Message-ID: <77c51beccad146d1a6df2b80af6c920a@usma1ex-dag1mb1.msg.corp.akamai.com> References: <0ed4eb20-d8b9-38c6-d3d1-9c02c0508a49@bartschnet.de> In-Reply-To: <0ed4eb20-d8b9-38c6-d3d1-9c02c0508a49@bartschnet.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.45.87] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-03_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1707030254 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-03_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1707030254 Archived-At: Subject: Re: [Acme] Automated procedure for DNS challenge records? X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 15:17:22 -0000 > is there any procedure proposed in the ACME documents to update the > ACME resource records on the primary DNS server (e.g. DynDNS/TSIG RFCs > 2136/2845)? No, there is no DNS-update protocol specified. But what ACME resource records are you thinking of? From nobody Mon Jul 3 08:30:06 2017 Return-Path: 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 EE9F113165A for ; Mon, 3 Jul 2017 08:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xXB7fhRRi_4 for ; Mon, 3 Jul 2017 08:30:03 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::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 AC1B112871F for ; Mon, 3 Jul 2017 08:30:02 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id i127so112456853wma.0 for ; Mon, 03 Jul 2017 08:30:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dWxAP1C82P3KOAETPR72Ub9LHVY0Szp9iEOg3uwpzAA=; b=jtPDtWWG94I7czyA+wIglCsGM0ORmUPa2ADamQVGI+lWn2dsRjRaBCs0SBxH1iEpgv IDyr9i7ChZVD3HHkKuTigE7f5W10nLBRNiSIs30Tt9HPpAbZjI7w9r277uIwQ9sNErPl j4EvQ4vtFNkHeE77nMfU+CcadVK6dbPi+pXYwHfQ90HyxzQ4hTwBJJ5mT4NGyDxAc/If jeKUI3+gdlmOl+sFlCJi0Bs+fZxAhyaZeS3rzo17xalMqV04UcQqoq3gKNQFsXu3vjzI AxrhpwxBxC18rVrxPeBAAdI7M1rhc+V+LUb/rle5J/nyqpSwPwnsVRzA3somPnhlN4Rd pm0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dWxAP1C82P3KOAETPR72Ub9LHVY0Szp9iEOg3uwpzAA=; b=d1zBBq+RLvYcfj0hMoDnaBnoe/f1qP2W5pTC56Rl80Z37w12cKhAJCep47xKOfyRzw Ba/GZlZ4DYO8mNFVcjG/vkLLCTKCYJpuEQvfL7CKQ05l2s7XZQrDWV9dzWHieuHoAG2+ fYfQLKNx9h8is1sZd8AtmvLcoejzQppf1Q0mys1eQYyLPZKWFTbaArDFA0eAFFRMb//M O10wKcIn4vsEvfmJh4sggaRI8BDwNQXr7qhVJPwFZ9z5mXQmnCW46jfrLcLx5vUiEqiV 78C4TM2zIIcAcKGIre/5RUPIybqXXK/idPFHmyLAhIA+RfadHerlnBrnJ6r/wlX9GHG7 3kRQ== X-Gm-Message-State: AKS2vOzceaEAcWXNcaFiM6PxiX70pn/UM7dLRTspm9upLs84BaoDqqlH e7JhHdeOSj585kNOVH2cAsSKIv0SCvTIAAK/Gg== X-Received: by 10.28.191.134 with SMTP id o6mr26262560wmi.11.1499095801068; Mon, 03 Jul 2017 08:30:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.72.4 with HTTP; Mon, 3 Jul 2017 08:30:00 -0700 (PDT) In-Reply-To: <0ed4eb20-d8b9-38c6-d3d1-9c02c0508a49@bartschnet.de> References: <0ed4eb20-d8b9-38c6-d3d1-9c02c0508a49@bartschnet.de> From: Richard Barnes Date: Mon, 3 Jul 2017 11:30:00 -0400 Message-ID: To: "Rene 'Renne' Bartsch, B.Sc. Informatics" Cc: "acme@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c072056b517aa05536b7043" Archived-At: Subject: Re: [Acme] Automated procedure for DNS challenge records? X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 15:30:05 -0000 --94eb2c072056b517aa05536b7043 Content-Type: text/plain; charset="UTF-8" There isn't anything in the current spec(s), and it doesn't really seem in scope for this work. That is, I don't think it's worthwhile to make a one-off solution for updating the DNS with records for ACME, vs. improving the state of DNS management in general. That said, you can certainly integrate ACME tools with existing DNS APIs. For example: https://github.com/xenolf/lego/tree/master/providers/dns On Mon, Jul 3, 2017 at 11:10 AM, Rene 'Renne' Bartsch, B.Sc. Informatics < ietf@bartschnet.de> wrote: > Hello, > > > is there any procedure proposed in the ACME documents to update the ACME > resource records on the primary DNS server (e.g. DynDNS/TSIG RFCs > 2136/2845)? > > > Best regards, > > > Renne > > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > --94eb2c072056b517aa05536b7043 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
There isn't anything in the current spec(s), and = it doesn't really seem in scope for this work.=C2=A0 That is, I don'= ;t think it's worthwhile to make a one-off solution for updating the DN= S with records for ACME, vs. improving the state of DNS management in gener= al.

That said, you can certainly integrate ACME to= ols with existing DNS APIs.=C2=A0 For example:


On Mon, Jul 3, 2017 at 11= :10 AM, Rene 'Renne' Bartsch, B.Sc. Informatics &= lt;ietf@bartschnet.= de> wrote:
Hello,


is there any procedure proposed in the ACME documents to update the ACME re= source records on the primary DNS server (e.g. DynDNS/TSIG RFCs 2136/2845)?=


Best regards,


Renne


_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

--94eb2c072056b517aa05536b7043-- From nobody Mon Jul 3 09:26:00 2017 Return-Path: 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 1FD2E129B16 for ; Mon, 3 Jul 2017 09:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 L5BsKBO1ASUN for ; Mon, 3 Jul 2017 09:25:57 -0700 (PDT) Received: from mail.core-networks.de (mail.core-networks.de [IPv6:2001:1bc0:d::4:9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 702BA129482 for ; Mon, 3 Jul 2017 09:25:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.core-networks.de id 1dS4Ad-0003iz-2w with ESMTPSA (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) for acme@ietf.org; Mon, 03 Jul 2017 18:25:55 +0200 To: "acme@ietf.org" References: <0ed4eb20-d8b9-38c6-d3d1-9c02c0508a49@bartschnet.de> <77c51beccad146d1a6df2b80af6c920a@usma1ex-dag1mb1.msg.corp.akamai.com> From: "Rene 'Renne' Bartsch, B.Sc. Informatics" Message-ID: Date: Mon, 3 Jul 2017 18:25:54 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <77c51beccad146d1a6df2b80af6c920a@usma1ex-dag1mb1.msg.corp.akamai.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Content-Language: de-DE Archived-At: Subject: Re: [Acme] Automated procedure for DNS challenge records? X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 16:25:59 -0000 Am 03.07.2017 um 17:17 schrieb Salz, Rich: >> is there any procedure proposed in the ACME documents to update the >> ACME resource records on the primary DNS server (e.g. DynDNS/TSIG RFCs >> 2136/2845)? > No, there is no DNS-update protocol specified. > > But what ACME resource records are you thinking of? For a fully automated validation process the ACME-client needs some kind of protocol/interface to add/update/remove the DNS challenge records on the primare DNS server. From nobody Mon Jul 3 09:28:42 2017 Return-Path: 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 B6BE3126DEE for ; Mon, 3 Jul 2017 09:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wbXI0Dqy0Ljt for ; Mon, 3 Jul 2017 09:28:40 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 494CB129B77 for ; Mon, 3 Jul 2017 09:28:40 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v63GRenm029178; Mon, 3 Jul 2017 17:28:31 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=O5So/eJleR66HLgV7GtiGhQvsY4IjX1RleiHhvGEaCA=; b=hNO7Q/U5YG1isJtF9A1BOVBBPTdnZh4HYsYsmH4SktylFmKxHSNtcOplNmX7wfDZQdQl zCEU6VaTxY2KeozSWDIPuHRTTndCGoabGMzZwAP1/h/4xOw5r938eBc2pk+B7GV74VKC mnDfhK258lf/NP4FSBtc03QcfXtCmK5RnEWoIjGptsx2LMUIdrfLf3sVpVe6YVHcohFh 6H5sfpC+ZTAG81GcCGSG1CGBsau5mJyWLM/Oms/6A3PKP5/Cj9GSZM3Nc1RKzLDTfjW2 qQuETe1ZUPgzSYsyp9oNs6ZQtHKeB4e8SfmIllCPacEaYrqLIP8YBdOQ7kkYmP9olp/Z 2g== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2be3949153-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 03 Jul 2017 17:28:31 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v63GPjcY021929; Mon, 3 Jul 2017 12:28:30 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 2be72u51pd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 03 Jul 2017 12:28:30 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag3mb5.msg.corp.akamai.com (172.27.123.55) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 3 Jul 2017 09:28:29 -0700 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 3 Jul 2017 12:28:29 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Mon, 3 Jul 2017 12:28:29 -0400 From: "Salz, Rich" To: "Rene 'Renne' Bartsch, B.Sc. Informatics" , "acme@ietf.org" Thread-Topic: [Acme] Automated procedure for DNS challenge records? Thread-Index: AQHS9A6Gl/VXFHhkE0qGQUwoFA975qJCNpBwgABWdgD//70ysA== Date: Mon, 3 Jul 2017 16:28:28 +0000 Message-ID: References: <0ed4eb20-d8b9-38c6-d3d1-9c02c0508a49@bartschnet.de> <77c51beccad146d1a6df2b80af6c920a@usma1ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.45.87] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-03_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1707030273 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-03_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1031 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1707030273 Archived-At: Subject: Re: [Acme] Automated procedure for DNS challenge records? X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 16:28:42 -0000 > For a fully automated validation process the ACME-client needs some kind = of > protocol/interface to add/update/remove the DNS challenge records on the > primare DNS server. This is out of scope for our WG, but since we are looking at rechartering, = it could be brought within scope. But I think programmatic maintenance of DNS records should probably be done= within the DNS groups. From nobody Mon Jul 3 09:46:34 2017 Return-Path: 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 0A2E3127F0E for ; Mon, 3 Jul 2017 09:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 4QKpP_T8POG4 for ; Mon, 3 Jul 2017 09:46:31 -0700 (PDT) Received: from mail.core-networks.de (mail.core-networks.de [IPv6:2001:1bc0:d::4:9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93F3A126DEE for ; Mon, 3 Jul 2017 09:46:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.core-networks.de id 1dS4UX-0004Xu-Es with ESMTPSA (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) for acme@ietf.org; Mon, 03 Jul 2017 18:46:30 +0200 To: "acme@ietf.org" References: <0ed4eb20-d8b9-38c6-d3d1-9c02c0508a49@bartschnet.de> <77c51beccad146d1a6df2b80af6c920a@usma1ex-dag1mb1.msg.corp.akamai.com> From: "Rene 'Renne' Bartsch, B.Sc. Informatics" Message-ID: Date: Mon, 3 Jul 2017 18:46:29 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Content-Language: de-DE Archived-At: Subject: Re: [Acme] Automated procedure for DNS challenge records? X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 16:46:33 -0000 Am 03.07.2017 um 18:28 schrieb Salz, Rich: >> For a fully automated validation process the ACME-client needs some kind of >> protocol/interface to add/update/remove the DNS challenge records on the >> primare DNS server. > This is out of scope for our WG, but since we are looking at rechartering, it could be brought within scope. > > But I think programmatic maintenance of DNS records should probably be done within the DNS groups. In my opinion we shouldn't reinvent the wheel. With RFC 2138 (DynDNS) there is already a protocol for clients to add/update/delete resource records on DNS servers. Most DNS server softwares support RFC 2136 out of the box. We just have to define a protocol to use (-> RFC 2136) in the ACME client. From nobody Mon Jul 3 12:31:05 2017 Return-Path: X-Original-To: acme@ietf.org Delivered-To: acme@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D95C712ECC1; Mon, 3 Jul 2017 12:30:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: acme@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149911025785.22857.7973610985615528660@ietfa.amsl.com> Date: Mon, 03 Jul 2017 12:30:57 -0700 Archived-At: Subject: [Acme] I-D Action: draft-ietf-acme-telephone-00.txt X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 19:30:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Automated Certificate Management Environment of the IETF. Title : ACME Identifiers and Challenges for Telephone Numbers Authors : Jon Peterson Richard Barnes Filename : draft-ietf-acme-telephone-00.txt Pages : 8 Date : 2017-07-03 Abstract: This document specifies identifiers and challenges required to enable the Automated Certificate Management Environment (ACME) to issue certificate for telephonoe numbers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-acme-telephone/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-acme-telephone-00 https://datatracker.ietf.org/doc/html/draft-ietf-acme-telephone-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jul 4 07:28:49 2017 Return-Path: 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 36D7213192E for ; Tue, 4 Jul 2017 07:28:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=letsencrypt.org 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 hjATxMIRGhCB for ; Tue, 4 Jul 2017 07:28:46 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::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 2237B13161A for ; Tue, 4 Jul 2017 07:28:45 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id v202so101537147itb.0 for ; Tue, 04 Jul 2017 07:28:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=letsencrypt.org; s=google; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=UUunANCkwlqiJeUDCzFBZPIiO0EGTm8p7uWMJets4A0=; b=IDhSlty7L1jmxpoKNAW72h+kWsgYA24tv7ei5wWiX2DyfXXUfVFpyLgjyG3dSn8PP/ JE7FRpI7wmSbD+JZhu/2PF9jcU1d9HPU5wBZi0DysxBbvavzh/mGo2FnaCFZxCimYvIf soJ8fmOmXeKQKh7Lm8fOvdooO1Gg5YregXNI8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=UUunANCkwlqiJeUDCzFBZPIiO0EGTm8p7uWMJets4A0=; b=r/vL1v7UqkQiAwOXHcnM/IWj1Y/AKUdMD1r676huxx6Lh++1dt4rKHd0fogc+U18E/ Tle8SiNFM9sdLZuE3ljLfdPf/f0LX+mwgEtrHP0rDn45CuLQQa9znlzU1W+dUNx5xGzK uhBOjUGmUT3EMvCz0SbXzrCFKizyanwGzCdY8fdMgGIcCstAPb9yd0LXjICvj7aajWwI WO/Z5MEIN5spmw05nmLx2PX7hgt3/H80XpYTn4/xyDhORpzIHfjHNXswBFmWk1POCfQg 8NwBxVlCnLTqRMZv1J0CsDnBqy7v4X118KI3dz/0d2WMGoJSWtdt9Duybej90wApYsW1 3HFQ== X-Gm-Message-State: AIVw110KJcY1v/9BlENlg0vkZbeH+owjQ/Cl7xB2dExf4dg525wTdPJL CcsyP2zYXyh5VViUC0u6P1I7iTQBeYtvW/m6uA== X-Received: by 10.36.215.135 with SMTP id y129mr13620353itg.3.1499178525301; Tue, 04 Jul 2017 07:28:45 -0700 (PDT) MIME-Version: 1.0 Reply-To: cpu@letsencrypt.org Received: by 10.107.9.9 with HTTP; Tue, 4 Jul 2017 07:28:44 -0700 (PDT) In-Reply-To: References: <0ed4eb20-d8b9-38c6-d3d1-9c02c0508a49@bartschnet.de> <77c51beccad146d1a6df2b80af6c920a@usma1ex-dag1mb1.msg.corp.akamai.com> From: Daniel McCarney Date: Tue, 4 Jul 2017 10:28:44 -0400 Message-ID: To: "Rene 'Renne' Bartsch, B.Sc. Informatics" Cc: "acme@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c0b16c474b5ba05537eb3c9" Archived-At: Subject: Re: [Acme] Automated procedure for DNS challenge records? X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 14:28:48 -0000 --94eb2c0b16c474b5ba05537eb3c9 Content-Type: text/plain; charset="UTF-8" I agree with the others that have shared the opinion that this is outside of the scope of ACME and this WG. In my opinion we shouldn't reinvent the wheel. With RFC 2138 (DynDNS) there > is already a protocol for clients to add/update/delete resource records on > DNS servers. Most DNS server softwares support RFC 2136 out of the box. We > just have to define a protocol to use (-> RFC 2136) in the ACME client. That's exactly right. At least one ACME client (Certbot) has been working on support for RFC 2136 (https://github.com/certbot/certbot/pull/4701) in addition to one-off provider specific DNS APIs. If you need a generic way to update DNS dynamically RFC 2138 is it. If your DNS provider doesn't support RFC 2136 it seems hard to imagine you could convince them to adopt a newly invented ACME DNS update scheme. - cpu On Mon, Jul 3, 2017 at 12:46 PM, Rene 'Renne' Bartsch, B.Sc. Informatics < ietf@bartschnet.de> wrote: > > > Am 03.07.2017 um 18:28 schrieb Salz, Rich: > >> For a fully automated validation process the ACME-client needs some kind >>> of >>> protocol/interface to add/update/remove the DNS challenge records on the >>> primare DNS server. >>> >> This is out of scope for our WG, but since we are looking at >> rechartering, it could be brought within scope. >> >> But I think programmatic maintenance of DNS records should probably be >> done within the DNS groups. >> > > In my opinion we shouldn't reinvent the wheel. With RFC 2138 (DynDNS) > there is already a protocol for clients to add/update/delete resource > records on DNS servers. Most DNS server softwares support RFC 2136 out of > the box. We just have to define a protocol to use (-> RFC 2136) in the ACME > client. > > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > --94eb2c0b16c474b5ba05537eb3c9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree with the others that have shared the opinion that = this is outside of the scope of ACME and this WG.

In my opi= nion we shouldn't reinvent the wheel. With RFC 2138 (DynDNS) there is a= lready a protocol for clients to add/update/delete resource records on DNS = servers. Most DNS server softwares support RFC 2136 out of the box. We just= have to define a protocol to use (-> RFC 2136) in the ACME client.

That's exactly right. At least one ACME client = (Certbot) has been working on support for RFC 2136 (https://github.com/certbot/certbot/pull/4= 701) in addition to one-off provider specific DNS APIs.

If you n= eed a generic way to update DNS dynamically RFC 2138 is it. If your DNS pro= vider doesn't support RFC 2136 it seems hard to imagine you could convi= nce them to adopt a newly invented ACME DNS update scheme.

- cpu

On Mon, J= ul 3, 2017 at 12:46 PM, Rene 'Renne' Bartsch, B.Sc. Informatics <= ietf@bartschnet.de> wrote:
=

Am 03.07.2017 um 18:28 schrieb Salz, Rich:
For a fully automated validation process the ACME-client needs some kind of=
protocol/interface to add/update/remove the DNS challenge records on the primare DNS server.
This is out of scope for our WG, but since we are looking at rechartering, = it could be brought within scope.

But I think programmatic maintenance of DNS records should probably be done= within the DNS groups.

 In my opinion we shouldn't reinvent the wheel. With RFC 2138 (DynDNS) t= here is already a protocol for clients to add/update/delete resource record= s on DNS servers. Most DNS server softwares support RFC 2136 out of the box= . We just have to define a protocol to use (-> RFC 2136) in the ACME cli= ent.


_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

--94eb2c0b16c474b5ba05537eb3c9-- From nobody Tue Jul 4 18:08:41 2017 Return-Path: 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 1FF24129AFE for ; Tue, 4 Jul 2017 18:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 9LuhCODFrdzC for ; Tue, 4 Jul 2017 18:08:37 -0700 (PDT) Received: from bigsvr.orionnetworks.ie (hosting.orionnetworks.ie [195.2.202.63]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECE951204DA for ; Tue, 4 Jul 2017 18:08:36 -0700 (PDT) Received: from host249.freudenhaus.alandoherty.net ([193.120.128.249]:3857 helo=alans-p4.alandoherty.net) by bigsvr.orionnetworks.ie with esmtpsa(TLSv1:DHE-RSA-AES256-SHA:256) (auth-as tel1) (nexus 1.3.4.80.1) (envelope-from ) id 1dSYnv-0001zD-Jh for acme@ietf.org; Wed, 05 Jul 2017 01:08:34 +0000 X-AD-RPFS-HEAD: for info on below codes http://www.alandoherty.net/mailsystem/mail-tagging/ X-AD-RPFS-GOOD-0: AV-SCAN-PASS SA-SCORE--1.6 SA-BAR-(-) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 05 Jul 2017 02:08:28 +0100 To: "acme@ietf.org" From: Alan Doherty In-Reply-To: References: <0ed4eb20-d8b9-38c6-d3d1-9c02c0508a49@bartschnet.de> <77c51beccad146d1a6df2b80af6c920a@usma1ex-dag1mb1.msg.corp.akamai.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: X-VIRUS: NONE {no virus found, This is no guarentee} Archived-At: Subject: Re: [Acme] Automated procedure for DNS challenge records? X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 01:08:40 -0000 +1 agreed the acme client design (plugins/modules/supported server architectures etc) should really be down to the implementors/designers as some smaller ones will only talk acme + http-01 + 1 specific server (say acme client built into server/device) others may offer many/all auth mechanisms and server architectures (and dns apis) the WG is realy concerned with the api (and CA server reactions (and expectation of responses) the myriad clients should handle the third side or the triangle client <--> acme-ca <----> client selected 3rd party client <-----out of scope-> client selected 3rd party (3rd party as the webserver or dns provider can be entirely separate) At 15:28 04/07/2017 Tuesday, Daniel McCarney wrote: >I agree with the others that have shared the opinion that this is outside of the scope of ACME and this WG. > >In my opinion we shouldn't reinvent the wheel. With RFC 2138 (DynDNS) there is already a protocol for clients to add/update/delete resource records on DNS servers. Most DNS server softwares support RFC 2136 out of the box. We just have to define a protocol to use (-> RFC 2136) in the ACME client. > > >That's exactly right. At least one ACME client (Certbot) has been working on support for RFC 2136 (https://github.com/certbot/certbot/pull/4701) in addition to one-off provider specific DNS APIs. > >If you need a generic way to update DNS dynamically RFC 2138 is it. If your DNS provider doesn't support RFC 2136 it seems hard to imagine you could convince them to adopt a newly invented ACME DNS update scheme. > >- cpu > >On Mon, Jul 3, 2017 at 12:46 PM, Rene 'Renne' Bartsch, B.Sc. Informatics <ietf@bartschnet.de> wrote: > > >Am 03.07.2017 um 18:28 schrieb Salz, Rich: >For a fully automated validation process the ACME-client needs some kind of >protocol/interface to add/update/remove the DNS challenge records on the >primare DNS server. > >This is out of scope for our WG, but since we are looking at rechartering, it could be brought within scope. > >But I think programmatic maintenance of DNS records should probably be done within the DNS groups. > > >In my opinion we shouldn't reinvent the wheel. With RFC 2138 (DynDNS) there is already a protocol for clients to add/update/delete resource records on DNS servers. Most DNS server softwares support RFC 2136 out of the box. We just have to define a protocol to use (-> RFC 2136) in the ACME client. > > >_______________________________________________ >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 From nobody Wed Jul 5 08:42:49 2017 Return-Path: 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 897CB13194B for ; Wed, 5 Jul 2017 08:42:48 -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_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id urLphNr175mE for ; Wed, 5 Jul 2017 08:42:46 -0700 (PDT) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (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 4F49613164D for ; Wed, 5 Jul 2017 08:42:46 -0700 (PDT) Received: by mail-wr0-x22a.google.com with SMTP id r103so265443316wrb.0 for ; Wed, 05 Jul 2017 08:42:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=c0yXzZBRFI2jLXmsG1apBrH8369SFG5DtGN1hLiqBBI=; b=DsRnZJl7OJlQMmzQMp1YLzEypwcrFoVJEr8QRbmjw8DVxXvnkWuzjfuj/Wi4Iy7g4r 6SWmAkGq/nO4diTdpZimR/p1828TQhHBuH35ZYv7ypcd/fB1EBclJAQFT500hSz48I/e 5rE7cXZ4bOHrHSG01fjPjm/HTJ/54DkK6B8x5HioY4nZBsiaCvSwqM+KkOEXSGzMimr6 oPZqjpSMB9ylLeK/ftZK2PEterGpNjIMPHhPP9yTB36XAUJZFP2aHU4woO7U1r1aSCKj oHFFPF/clcZ6S38gLePcQV2kuRxL4gNO+zrgdMOsEV9orhNJtUHOavl6ay6DF5va1Kxm MdIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=c0yXzZBRFI2jLXmsG1apBrH8369SFG5DtGN1hLiqBBI=; b=SdT7GILfrprZRX7ArS5Qe4CkukhO1Ie6S7EPKW18K0lSwAAyjsL8xpYoHgNJOChUtY w6dyXkbSdBl8uu0dEAqq+dNL3rLo0Jdkh9ebQAAG0aVSJFsB+WHtFMFU2sJ/qm1zGXkQ /18YWEBDw2BMTTho1HG0JMQCDy26/NO3Lv2wMYCiipDWLjjGQbCLWtqUSxbZX7aEOxE9 8cjqryV6j9cvwXLLekHLplqBdPhIMtOyHxsVtak3fdQkARHRSVd/dUCBqms9ODzuMn/n lk47L2myrnu8awXVEoCSihDU9zbJHcVzP+syjX4xCz9qh6Ey+cCMNCayiH69ctNE+jDR hE9w== X-Gm-Message-State: AKS2vOw0uzEYrQR/twuh6IYHARDfxYcNMcbgUk87r0h9WN8Y79o09NSa jefQxBz/CfTqNfg8IPwIoIaIJNR+2ZpV X-Received: by 10.223.142.143 with SMTP id q15mr40402052wrb.180.1499269364763; Wed, 05 Jul 2017 08:42:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.72.4 with HTTP; Wed, 5 Jul 2017 08:42:44 -0700 (PDT) In-Reply-To: <8baacb86ea9b455291fab177ce85b5ce@usma1ex-dag1mb1.msg.corp.akamai.com> References: <40e652477a2f47b0848330e64f72e8b2@usma1ex-dag1mb1.msg.corp.akamai.com> <177d761f214441a0b20bfc4ddc8dee9b@usma1ex-dag1mb1.msg.corp.akamai.com> <20170613173105.GB12048@LK-Perkele-V2.elisa-laajakaista.fi> <8baacb86ea9b455291fab177ce85b5ce@usma1ex-dag1mb1.msg.corp.akamai.com> From: Richard Barnes Date: Wed, 5 Jul 2017 11:42:44 -0400 Message-ID: To: "Salz, Rich" Cc: "ilariliusvaara@welho.com" , "acme@ietf.org" Content-Type: multipart/alternative; boundary="f403045f517ce8f666055393d9fb" Archived-At: Subject: Re: [Acme] Consensus -- CAA draft to WGLC? X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 15:42:48 -0000 --f403045f517ce8f666055393d9fb Content-Type: text/plain; charset="UTF-8" There's no listing going on here, since there's no registry for the values. CABF could put tokens in their documents if they like. On Tue, Jun 13, 2017 at 1:33 PM, Salz, Rich wrote: > > The two last ones are editorial, but the first about enumerating all BR > > methods isn't (since it needs new validation method identifiers). > > Thinking about it a bit more, I don't think it is appropriate for ACME to > list CABF things. That's a strong view as an individual, and a moderate > view as a WG chair. > --f403045f517ce8f666055393d9fb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
There's no listing going on here, since there's no= registry for the values.=C2=A0 CABF could put tokens in their documents if= they like.

On Tue, Jun 13, 2017 at 1:33 PM, Salz, Rich <rsalz@akamai.com> wrote:
> The tw= o last ones are editorial, but the first about enumerating all BR
> methods isn't (since it needs new validation method identifiers).<= br>
Thinking about it a bit more, I don't think it is appropriate fo= r ACME to list CABF things.=C2=A0 That's a strong view as an individual= , and a moderate view as a WG chair.

--f403045f517ce8f666055393d9fb-- From nobody Wed Jul 5 08:47:20 2017 Return-Path: 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 5E2D9131647 for ; Wed, 5 Jul 2017 08:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BXPSTC4GPPk2 for ; Wed, 5 Jul 2017 08:47:18 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17AF7131D6C for ; Wed, 5 Jul 2017 08:47:16 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v65FksCl022601; Wed, 5 Jul 2017 16:47:14 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=46ctbvJfx7R4vL24zWWg7EuNEFc0JmrmOrrwZWibtEc=; b=JlwUPLVE0Abh120SzhP8HZn/OmaY8EalxJrq19A17dgLKp/oVKl1xpyLR68709yKhvvS RqSlTmNh9RB4ZWNiyIFjLNXi3sx53XW1y/kc7ou2M10Nh9vhS0wvEc1d+ryJwJ0KPkq+ RP2wi1yi9YzM4KBLcIF2ZR2ZA0yVLEj1jzmMnD0rRpHkQAZ3c0M+12IvdTalpL7tNAfJ 1VFxZrgmVKoCtD0fWvzLmVOVgJcONfA2ng1xhfPDYTQE2+YViEFQO/NS6tz6DBb019qY CfvzO/waaU6zWqIua+2EfKovpURvJVD+j3kXzUzShb4jLD/buGcVeV8fymnd3EFDssb0 kQ== Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2bgsdjaru8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 05 Jul 2017 16:47:14 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v65FjlYQ030317; Wed, 5 Jul 2017 11:47:13 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint1.akamai.com with ESMTP id 2be72ua36h-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 05 Jul 2017 11:47:13 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 5 Jul 2017 11:47:12 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Wed, 5 Jul 2017 11:47:12 -0400 From: "Salz, Rich" To: Richard Barnes CC: "ilariliusvaara@welho.com" , "acme@ietf.org" Thread-Topic: [Acme] Consensus -- CAA draft to WGLC? Thread-Index: AdLgaixZ2HxcGKQGRUWoL8+FK3tFFwD/4jaAAAR+qwAABCs5gAAIUaCABEZO7AAACD9nAA== Date: Wed, 5 Jul 2017 15:47:11 +0000 Message-ID: References: <40e652477a2f47b0848330e64f72e8b2@usma1ex-dag1mb1.msg.corp.akamai.com> <177d761f214441a0b20bfc4ddc8dee9b@usma1ex-dag1mb1.msg.corp.akamai.com> <20170613173105.GB12048@LK-Perkele-V2.elisa-laajakaista.fi> <8baacb86ea9b455291fab177ce85b5ce@usma1ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.34.202] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-05_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1707050266 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-05_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1707050266 Archived-At: Subject: Re: [Acme] Consensus -- CAA draft to WGLC? X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 15:47:19 -0000 PiBUaGVyZSdzIG5vIGxpc3RpbmcgZ29pbmcgb24gaGVyZSwgc2luY2UgdGhlcmUncyBubyByZWdp c3RyeSBmb3IgdGhlIHZhbHVlcy7CoCBDQUJGIGNvdWxkIHB1dCB0b2tlbnMgaW4gdGhlaXIgZG9j dW1lbnRzIGlmIHRoZXkgbGlrZS4NCg0KT2theSwgcGxlYXNlIHByb3Bvc2Ugd29yZGluZyAob3Ig ZGlkIHlvdT8gIFNvcnJ5IGlmIHNvKSB0byBjaGFuZ2UgZm9yIHRoZSBDQUEgZHJhZnQuDQoNCg== From nobody Wed Jul 5 09:41:26 2017 Return-Path: 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 7795B131D72 for ; Wed, 5 Jul 2017 09:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dyZ5dkTC_Ajy for ; Wed, 5 Jul 2017 09:41:23 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::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 D56CB13167C for ; Wed, 5 Jul 2017 09:41:22 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id i127so172799839wma.0 for ; Wed, 05 Jul 2017 09:41:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EEAwj5beb7bJmGubFHowrZx0W3fxJJbBsw0GPnf34vM=; b=UFi4ZjrhcjibuF/nTWohwQoC0p+l3z+Q0+v5Bpp8MEckzGyDvLlddzYbSqr3IhAGtm 6e/4xKB/kN7RyWARjHSZxf6gVxzwwWHEOKfDD0yUfLJp03bj/qdO0kBb0Jl/0chZtsQp L26DhmomNJDcdQt+FR8XNOAPx/xiZ+71FxZ5H46+MOl0ndcUqhxwGUuVusZfp+vQKBf7 YLAzy0/zukxh2qlN/0r9Gay/GaUCnlnzgtI9kGmj5ilGbPSoYqydot8N0dvchI24YPV1 jt5QD6HMmypOFW7P2r1kaDmJ0xmIzQM0tAzNE5qLmnOrq9bA7W/3ETsaZfGzdGuNaG4o TEcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EEAwj5beb7bJmGubFHowrZx0W3fxJJbBsw0GPnf34vM=; b=nECUrGj1INofxY+vhcGBAQOHIk8acb+0lDEY9dR69YUFR2jprLDlrIdyYTBcSTr79b +3a2TFSUFnwvJMQwVCSH4WPIzjF+edTxSGpn4jlAIzRQT8APlMIqbPPVxHVQb/XfKxam vpGbTDawaPHCuGXMoacV/pBvDAaPohwqq3I8E1tbPee41qXXMgmeJYRcpz9DmdzJFYsD kCq4ipDyFt6nrMewS/spYb2H4VTnwbU1PTfYu/dD0cjBKoDXNRPUvDF3ScPoJWL8AMjN aT9npwMzmo4wEmM8ireCazMY50Llzkd/qaQWnL0lFMmI6SzIz2w0Z9f82XySVl8Abhd6 hHlQ== X-Gm-Message-State: AKS2vOwcwsUP3o4eB5nAHBTZgFm8AqvrW4VNTR9UzmG42lQPbGg/zjKF axvXCBG8ZbI+PRulTLYRnLG0/B0tgJFM X-Received: by 10.28.218.149 with SMTP id r143mr30949680wmg.74.1499272881143; Wed, 05 Jul 2017 09:41:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.72.4 with HTTP; Wed, 5 Jul 2017 09:41:20 -0700 (PDT) In-Reply-To: References: <40e652477a2f47b0848330e64f72e8b2@usma1ex-dag1mb1.msg.corp.akamai.com> <177d761f214441a0b20bfc4ddc8dee9b@usma1ex-dag1mb1.msg.corp.akamai.com> <20170613173105.GB12048@LK-Perkele-V2.elisa-laajakaista.fi> <8baacb86ea9b455291fab177ce85b5ce@usma1ex-dag1mb1.msg.corp.akamai.com> From: Richard Barnes Date: Wed, 5 Jul 2017 12:41:20 -0400 Message-ID: To: "Salz, Rich" Cc: "ilariliusvaara@welho.com" , "acme@ietf.org" Content-Type: multipart/alternative; boundary="001a1145a6dc80b050055394ab50" Archived-At: Subject: Re: [Acme] Consensus -- CAA draft to WGLC? X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 16:41:25 -0000 --001a1145a6dc80b050055394ab50 Content-Type: text/plain; charset="UTF-8" https://github.com/ietf-wg-acme/acme-caa/pull/2 On Wed, Jul 5, 2017 at 11:47 AM, Salz, Rich wrote: > > There's no listing going on here, since there's no registry for the > values. CABF could put tokens in their documents if they like. > > Okay, please propose wording (or did you? Sorry if so) to change for the > CAA draft. > > --001a1145a6dc80b050055394ab50 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Wed, Jul 5, 2017 at 11:4= 7 AM, Salz, Rich <rsalz@akamai.com> wrote:
> There's no listing going on here,= since there's no registry for the values.=C2=A0 CABF could put tokens = in their documents if they like.

Okay, please propose wording (or did you?=C2=A0 Sorry if so) to chan= ge for the CAA draft.


--001a1145a6dc80b050055394ab50-- From nobody Wed Jul 5 12:45:28 2017 Return-Path: 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 3F4BF131CD6 for ; Wed, 5 Jul 2017 12:45:27 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzv2k-9Eeoj1 for ; Wed, 5 Jul 2017 12:45:24 -0700 (PDT) Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::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 7DCDA131569 for ; Wed, 5 Jul 2017 12:45:24 -0700 (PDT) Received: by mail-wr0-x229.google.com with SMTP id c11so269405718wrc.3 for ; Wed, 05 Jul 2017 12:45:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=1myi4CTYNbeUTGWI4RvO79r1JB7RQwN3PJUaChCqagk=; b=mOl/+LS3g71ecUhhcEpzcjT11g+t11yA0Rc7SiNXvzAed58S+qRDqWLdZCIyHkImpK l+QBWmuEgEc9G5U+flYHlubYJK+FeNpi4t2XGa8BH8W2ox+hQQlDTKhZyoVTA2yJhlKr 3LWt9fYDQUqZFAF65Co1GZP6vDZ8WbBdLfx5hilc3UUpx95wYFtxL8C9rTMU5CzdgHNc hyl+ZRqEZGr+BK769ih42Yxdm5zCAvhRqWn2VMiRW1HCNYwyG6VGAuzD/GOQggvZLsDd FS3mIMudHLPiXMIhL8ba9BkUTxRDMa+o4Gl3cOqNlcZH27H0SymuSF5lY81AxX2r1SrA RZXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=1myi4CTYNbeUTGWI4RvO79r1JB7RQwN3PJUaChCqagk=; b=oTlPihLrapMxDThMKeuYL94lawyn1nx+W9vBnC2tA9QILWFBMRZiOiF3mTOT4Eymr8 gIciYzUT/Xuymx86CySoNUt1YcDxeIrDiQrmJ/OvpJEPHECmgbRzUhullRRIr0jCDeS8 1/yjFviFze6sIohgJOaLD9zlKbt8hO6hlCHHntt/f0+n9moY+v7474J9qzi85lR61wxl D2QVJY1fAeRMil07d/KcT6ZWOrITH2YHyLq0YpZ6onsVCYkaAvpw4wgBupR4BI2LglPT a1Q5qxT7IcGWcP8fY5xgASp/zd6oMb1kj4tcGEi+ajXLDDMbRckltV4eU6Hqah+nF6d9 1JPQ== X-Gm-Message-State: AIVw112YuuReykRVJPwdsPLu1HHVTNEHBT+ETere7zxTUYhQffUi25Ze TaV1XPUWR9TYU9A05c0= X-Received: by 10.28.15.8 with SMTP id 8mr7943143wmp.80.1499283922739; Wed, 05 Jul 2017 12:45:22 -0700 (PDT) Received: from [10.0.0.9] (bzq-109-67-14-33.red.bezeqint.net. [109.67.14.33]) by smtp.gmail.com with ESMTPSA id i136sm5458515wmf.33.2017.07.05.12.45.21 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Jul 2017 12:45:22 -0700 (PDT) To: acme@ietf.org References: From: Yaron Sheffer Message-ID: Date: Wed, 5 Jul 2017 22:45:20 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Acme] Consensus -- CAA draft to WGLC? X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 19:45:27 -0000 I support moving forward with the document. However I think the treatment of the acme-methods (or validation-methods) param is inconsistent, before and certainly after Richard's PR. The original draft only allows ACME methods and the special name "non-acme". This leaves the responsibility to ensure names are well defined with the IETF. If we allow mixing ACME methods with CA-defined methods per Richard's proposal, we should make sure that there is no overlap. And even if names are defined by individual CAs, the CA should provide a precise definition of each validation method. IMO there are two good options: - Define an IANA registry for the validation-methods values. (This is simple enough, and would be my preference). - Define an IANA registry for prefixes (such as "cabf" mentioned in Richard's text) and specify that everything else must be defined by ACME. Thanks, Yaron > https://github.com/ietf-wg-acme/acme-caa/pull/2 > > On Wed, Jul 5, 2017 at 11:47 AM, Salz, Rich wrote: > >>> There's no listing going on here, since there's no registry for the >> values. CABF could put tokens in their documents if they like. >> >> Okay, please propose wording (or did you? Sorry if so) to change for the >> CAA draft. >> >> > From nobody Wed Jul 5 14:17:44 2017 Return-Path: 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 86351131DE3 for ; Wed, 5 Jul 2017 14:17:42 -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_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Rh46U6U5y2q for ; Wed, 5 Jul 2017 14:17:37 -0700 (PDT) Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::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 2AAC9131A30 for ; Wed, 5 Jul 2017 14:17:37 -0700 (PDT) Received: by mail-wr0-x229.google.com with SMTP id r103so1889162wrb.0 for ; Wed, 05 Jul 2017 14:17:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GS6NVYiIBqxCfg5lSCTCqV1ulV5wcD0kHTG/rSKa5PY=; b=E1xv3Kdrr27q7ioiCT6WLrJTbv/jQxQXKNkXgEHAn873Y6hnSgOl4rx8INYHMCK1q7 d4wUYVQrL056Y8K8b28RWd8/iqlo7t/GFKPEXG6EPjFUUgMpyyXG/efJgmHGgaDWjAU6 +BOSE/51o1/4LZ+iLDqSjVJLM+4PgwOjLUA1cE8UvZo1y4fU8t/oayobrWuNdNlYmlFv NFvi0CdHUBzfaGNLeYcfmiTioFitkQvMtMlNWZyX8G+I/iwXvrbzobEr7B6cBxGf7vI1 UpYLnfp1vuaAoaUURre78bZ5f+zmxzDNomOYOCXA+nClM4zCaEMvXShdX1n+ad7ziCvF cieg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GS6NVYiIBqxCfg5lSCTCqV1ulV5wcD0kHTG/rSKa5PY=; b=eyM4VSziWi3q6w4118CD3HBj8HGxhDh2gYS5GeGAtVLkGofyR89L4LKa3hAhDwzN0t qu2fVvxRnwMqq6q57kxlNBXjHuLU/WjdpBzPrX+rPb3m42zo4O8719vLogYvHMKdgcRU 8wCrO3/9daxY+Im24HLh8O8notttEz00/3z+6RGrAp2ZNrF7Aew87EN88tJyml2ZXE5H e9fRBRRWBQFb48iN67bZkUOmxXrH/A4P6dBum7iwauYDg5RebVqUdGAsAYonsQkZ4FYD /7o2zRQJDwsl+z+5m0qgLTE3uDey9gkHq4foNzpCeCvrDRrSU+970TH3VVCer2E4EpZS l5wQ== X-Gm-Message-State: AIVw1130XayzLlSOjy2uFu8ciV/FuxOchHmzrUpMmASlmg6Wm4Xn72Oj ouP+QQdVuPBou3KcBxbmBISdk89Ixi2T X-Received: by 10.28.97.86 with SMTP id v83mr11928232wmb.74.1499289455514; Wed, 05 Jul 2017 14:17:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.72.4 with HTTP; Wed, 5 Jul 2017 14:17:34 -0700 (PDT) In-Reply-To: References: From: Richard Barnes Date: Wed, 5 Jul 2017 17:17:34 -0400 Message-ID: To: Yaron Sheffer Cc: "acme@ietf.org" Content-Type: multipart/alternative; boundary="001a1148e9f0696cf30553988713" Archived-At: Subject: Re: [Acme] Consensus -- CAA draft to WGLC? X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 21:17:42 -0000 --001a1148e9f0696cf30553988713 Content-Type: text/plain; charset="UTF-8" Just for context here: I think the original operating model for CAA was that the CA would tell the customer what values to put in there in order to authorize issuance. So it was safe to use arbitrary values because it was basically a closed loop CA -> Customer -> CAA -> CA. Nonetheless, I sympathize with your point here. With ACME, we're moving things in a more standardized / automated direction, so we can automate out some of the CA interaction around CAA if we standardize some values. Note that the ACME challenge type values are already registered. Would it be sufficient to say something like "Tokens registered as ACME challenge types MUST NOT be used to identify non-ACME validation methods"? --- This reminds me a related point that I forgot in my initial review. It would be nice if it were possible to specify a validation method policy independent of CA. So I wouldn't have to authorize each CA I interact with individually, but I would be able to say "Only validate my domains using dns-01". In fact, is there any reason to have different validation methods per CA? It's a property of the domain owner / certificate applicant, not the CA. Is there a reason you would trust CA X to do "http-01" but not CA Y? (I totally understand why "account-uri" is CA-specific, though.) I would suggest pulling out "validation-methods" from being an attribute to being a "tag" / "property", parallel to "issue" and "issuewild". On Wed, Jul 5, 2017 at 3:45 PM, Yaron Sheffer wrote: > I support moving forward with the document. > > However I think the treatment of the acme-methods (or validation-methods) > param is inconsistent, before and certainly after Richard's PR. The > original draft only allows ACME methods and the special name "non-acme". > This leaves the responsibility to ensure names are well defined with the > IETF. > > If we allow mixing ACME methods with CA-defined methods per Richard's > proposal, we should make sure that there is no overlap. And even if names > are defined by individual CAs, the CA should provide a precise definition > of each validation method. IMO there are two good options: > > - Define an IANA registry for the validation-methods values. (This is > simple enough, and would be my preference). > - Define an IANA registry for prefixes (such as "cabf" mentioned in > Richard's text) and specify that everything else must be defined by ACME. > > Thanks, > Yaron > > > > https://github.com/ietf-wg-acme/acme-caa/pull/2 >> >> On Wed, Jul 5, 2017 at 11:47 AM, Salz, Rich wrote: >> >> There's no listing going on here, since there's no registry for the >>>> >>> values. CABF could put tokens in their documents if they like. >>> >>> Okay, please propose wording (or did you? Sorry if so) to change for the >>> CAA draft. >>> >>> >>> >> > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > --001a1148e9f0696cf30553988713 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just for context here: I think the original operating= model for CAA was that the CA would tell the customer what values to put i= n there in order to authorize issuance.=C2=A0 So it was safe to use arbitra= ry values because it was basically a closed loop CA -> Customer -> CA= A -> CA.

Nonetheless, I sympathize with your po= int here.=C2=A0 With ACME, we're moving things in a more standardized /= automated direction, so we can automate out some of the CA interaction aro= und CAA if we standardize some values.

Note that t= he ACME challenge type values are already registered.=C2=A0 Would it be suf= ficient to say something like "Tokens registered as ACME challenge typ= es MUST NOT be used to identify non-ACME validation methods"?

---

This reminds me a related= point that I forgot in my initial review.=C2=A0 It would be nice if it wer= e possible to specify a validation method policy independent of CA.=C2=A0 S= o I wouldn't have to authorize each CA I interact with individually, bu= t I would be able to say "Only validate my domains using dns-01".= =C2=A0

In fact, is there any reason to have d= ifferent validation methods per CA?=C2=A0 It's a property of the domain= owner / certificate applicant, not the CA. Is there a reason you would tru= st CA X to do "http-01" but not CA Y?=C2=A0 (I totally understand= why "account-uri" is CA-specific, though.)

I would suggest pulling out "validation-methods" from bei= ng an attribute to being a "tag" / "property", parallel= to "issue" and "issuewild".



On Wed, Jul 5, 2017 at 3:45 PM, Yaron Sheffer <yaronf.ietf@gmail.com= > wrote:
I support moving f= orward with the document.

However I think the treatment of the acme-methods (or validation-methods) p= aram is inconsistent, before and certainly after Richard's PR. The orig= inal draft only allows ACME methods and the special name "non-acme&quo= t;. This leaves the responsibility to ensure names are well defined with th= e IETF.

If we allow mixing ACME methods with CA-defined methods per Richard's p= roposal, we should make sure that there is no overlap. And even if names ar= e defined by individual CAs, the CA should provide a precise definition of = each validation method. IMO there are two good options:

- Define an IANA registry for the validation-methods values. (This is simpl= e enough, and would be my preference).
- Define an IANA registry for prefixes (such as "cabf" mentioned = in Richard's text) and specify that everything else must be defined by = ACME.

Thanks,
=C2=A0 =C2=A0 Yaron



https://github.com/ietf-wg-acme/acme-caa/pull/2<= /a>

On Wed, Jul 5, 2017 at 11:47 AM, Salz, Rich <rsalz@akamai.com> wrote:

There's no listing going on here, since there's no registry for the=
values.=C2=A0 CABF could put tokens in their documents if they like.

Okay, please propose wording (or did you?=C2=A0 Sorry if so) to change for = the
CAA draft.




_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

--001a1148e9f0696cf30553988713-- From nobody Wed Jul 5 14:48:17 2017 Return-Path: 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 2D87612ECBC for ; Wed, 5 Jul 2017 14:48:15 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IIiRXHYaVGHP for ; Wed, 5 Jul 2017 14:48:12 -0700 (PDT) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::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 DA85F13144F for ; Wed, 5 Jul 2017 14:48:11 -0700 (PDT) Received: by mail-wr0-x231.google.com with SMTP id r103so2793453wrb.0 for ; Wed, 05 Jul 2017 14:48:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=+MbGr5ooXTo3DA9E6aWz5ytTT8lCHmnj46ZS7hXG1e8=; b=Lx59rjiFwXWtsK9X7F2j7KoTYNWedToOu1OkrNVZUiWqcaufo5W2RpGIeX0KcWxgX6 AjKqokzCJylKEN+3aH3srIbjgnDsNmtbdFgO6QY7dlwsFg7dLSDc1UfP3FMn8Or26bKE wRFTwHpKmCvAc1d6v4NKbmI2Imi10D/oPQsEi/Qp8GwxDQRnGlYqG1jKUdBTsU4RMj8d AT9qyas6jQOaEeOi1NUA5Wo3ed494sJyrWeFP2uUu4Hseyd4jpvH8IneVCzewpyNRGd+ LxhH4mBTmXoGY+n5CsjjFHCYiHzpy1BuUfJD3tk0CFyvWO3iaFqY0YwCjghKPW1PtyLj MOVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=+MbGr5ooXTo3DA9E6aWz5ytTT8lCHmnj46ZS7hXG1e8=; b=rBFzw7znSCjrGS1o16QfneNiT58taf8W+Xj92It317wCfEdkRQlO1o2RE1dzgQjSJR vdALH89frQ2HIbcLynxNqoV+e/27w5kcFVfOqF+u04csuNG1snv4/uVr5ub+3fGJvcb2 ZjDBFVCT1Qx6eQFpk2cxVE+EWFlazlS7/kIVkDu3/zFBFaXYtw2VSEd+qXgBYKQcZSLA tOuxhyQXCTvyHwJpQsFtJPB3LO4Vw/aZ0gLavT4/j0gITSXWhUST3pb4wv0xovlxcSCj dh9K3cwhoA7drmwsVFKZFYgQlqueXRzEZlyiuovBCHFo9UrWiFmW6CQZonyPBfVAx52s oN8A== X-Gm-Message-State: AKS2vOwvGW0ya33hMu8TNo3crvcANwYK5+SHB/u/PJt+tdHDRlMRvho/ mxSbSskx92YS3/n4JjQ= X-Received: by 10.28.135.79 with SMTP id j76mr30905412wmd.27.1499291290048; Wed, 05 Jul 2017 14:48:10 -0700 (PDT) Received: from [10.0.0.9] (bzq-109-67-14-33.red.bezeqint.net. [109.67.14.33]) by smtp.gmail.com with ESMTPSA id u62sm19388940wmd.5.2017.07.05.14.48.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Jul 2017 14:48:09 -0700 (PDT) To: Richard Barnes Cc: "acme@ietf.org" References: From: Yaron Sheffer Message-ID: <70794fbf-fa86-4009-5c71-80096b451a3d@gmail.com> Date: Thu, 6 Jul 2017 00:48:08 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Acme] Consensus -- CAA draft to WGLC? X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 21:48:15 -0000 The problem with saying "Tokens registered as ACME challenge types MUST NOT be used to identify non-ACME validation methods" is that ACME might want to come up with additional method names in the future, and those just might happen to conflict with methods that have been used by other organizations in the meantime. This is exactly the kind of mess that IANA is designed to prevent. A simple way to go around this issue is if we changed the draft to use "acme-dns-01" instead of "dns-01" and similarly for all ACME methods. Then we COULD say that non-ACME CAs MUST not use "acme-*" methods. To your second point, many enterprise users will want the extra security of "use this specific CA AND only with this method". There are probably other use cases though. Thanks, Yaron On 06/07/17 00:17, Richard Barnes wrote: > Just for context here: I think the original operating model for CAA > was that the CA would tell the customer what values to put in there in > order to authorize issuance. So it was safe to use arbitrary values > because it was basically a closed loop CA -> Customer -> CAA -> CA. > > Nonetheless, I sympathize with your point here. With ACME, we're > moving things in a more standardized / automated direction, so we can > automate out some of the CA interaction around CAA if we standardize > some values. > > Note that the ACME challenge type values are already registered. > Would it be sufficient to say something like "Tokens registered as > ACME challenge types MUST NOT be used to identify non-ACME validation > methods"? > > --- > > This reminds me a related point that I forgot in my initial review. > It would be nice if it were possible to specify a validation method > policy independent of CA. So I wouldn't have to authorize each CA I > interact with individually, but I would be able to say "Only validate > my domains using dns-01". > > In fact, is there any reason to have different validation methods per > CA? It's a property of the domain owner / certificate applicant, not > the CA. Is there a reason you would trust CA X to do "http-01" but not > CA Y? (I totally understand why "account-uri" is CA-specific, though.) > > I would suggest pulling out "validation-methods" from being an > attribute to being a "tag" / "property", parallel to "issue" and > "issuewild". > > > > On Wed, Jul 5, 2017 at 3:45 PM, Yaron Sheffer > wrote: > > I support moving forward with the document. > > However I think the treatment of the acme-methods (or > validation-methods) param is inconsistent, before and certainly > after Richard's PR. The original draft only allows ACME methods > and the special name "non-acme". This leaves the responsibility to > ensure names are well defined with the IETF. > > If we allow mixing ACME methods with CA-defined methods per > Richard's proposal, we should make sure that there is no overlap. > And even if names are defined by individual CAs, the CA should > provide a precise definition of each validation method. IMO there > are two good options: > > - Define an IANA registry for the validation-methods values. (This > is simple enough, and would be my preference). > - Define an IANA registry for prefixes (such as "cabf" mentioned > in Richard's text) and specify that everything else must be > defined by ACME. > > Thanks, > Yaron > > > > https://github.com/ietf-wg-acme/acme-caa/pull/2 > > > On Wed, Jul 5, 2017 at 11:47 AM, Salz, Rich > wrote: > > There's no listing going on here, since there's no > registry for the > > values. CABF could put tokens in their documents if they > like. > > Okay, please propose wording (or did you? Sorry if so) to > change for the > CAA draft. > > > > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > > > From nobody Wed Jul 5 15:03:05 2017 Return-Path: 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 BB800131841 for ; Wed, 5 Jul 2017 15:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org 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 zEJaisLN_pbf for ; Wed, 5 Jul 2017 15:03:02 -0700 (PDT) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8053C127201 for ; Wed, 5 Jul 2017 15:03:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject; bh=PPQT9vA/giq4EUq9PS7cSP1wCJnFFC5KRANSu2fmbPk=; b=25kFDpfXOMa6Ad8gRUBDRmX+sws9wmra7ayji/d0/ceXhxXG050PbhlAt7k7vWOwVgUmhTotgdXN9qEF10dY7yrudO7B5lEfqqbuDnLHbRS9HjpFScbQz82nGs7LJRFDcu0KrhRPqxaFWOHmkSg+3N8dw0dZhmAqyPo4HMxTNVs=; Received: ; Wed, 05 Jul 2017 15:03:00 -0700 To: "Dunning, John" , Ilari Liusvaara , Richard Barnes Cc: "Salz, Rich" , "acme@ietf.org" References: <0896b144e7e942b1ac68db9ead4c42bb@usma1ex-dag1mb1.msg.corp.akamai.com> <20170619184423.wtpj2qtq6awk3rju@LK-Perkele-VII> <53c76454-56ac-dde7-6cf8-94a6e39a89fc@eff.org> <30977E7E-FD36-4FB1-A7CF-1390095E1EB2@akamai.com> From: Jacob Hoffman-Andrews Message-ID: Date: Wed, 5 Jul 2017 15:03:00 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <30977E7E-FD36-4FB1-A7CF-1390095E1EB2@akamai.com> Content-Type: multipart/alternative; boundary="------------489F6F88B1E6CB843DA65C12" Content-Language: en-US Received-SPF: skipped for local relay Archived-At: Subject: Re: [Acme] Rolling keys and pending validations X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 22:03:05 -0000 This is a multi-part message in MIME format. --------------489F6F88B1E6CB843DA65C12 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 06/30/2017 09:54 AM, Dunning, John wrote: > Based on your description below, I think door A makes more sense to > me. My paraphrase of it is that key authorizations get bound at > creation time, and thus get “grandfathered” in after a credential > rotation. This is a good paraphrase. What do other folks on this list think about binding key authorization objects at creation time? I can't immediately see a security issue with it, but as a reminder, an earlier version of the protocol was subject to a vulnerability (https://www.ietf.org/mail-archive/web/acme/current/msg00484.html) related to changing the account key after creating an authorization object, so I think tweaks in this area deserve extra scrutiny. --------------489F6F88B1E6CB843DA65C12 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 06/30/2017 09:54 AM, Dunning, John wrote:
Based on your description below, I think door A makes more sense to me.  My paraphrase of it is that key authorizations get bound at creation time, and thus get “grandfathered” in after a credential rotation.
This is a good paraphrase. What do other folks on this list think about binding key authorization objects at creation time? I can't immediately see a security issue with it, but as a reminder, an earlier version of the protocol was subject to a vulnerability (https://www.ietf.org/mail-archive/web/acme/current/msg00484.html) related to changing the account key after creating an authorization object, so I think tweaks in this area deserve extra scrutiny.
--------------489F6F88B1E6CB843DA65C12-- From nobody Wed Jul 5 15:44:07 2017 Return-Path: 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 36CBF127201 for ; Wed, 5 Jul 2017 15:44:06 -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_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NG3M-MpSABbs for ; Wed, 5 Jul 2017 15:44:03 -0700 (PDT) Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::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 61347126B72 for ; Wed, 5 Jul 2017 15:44:03 -0700 (PDT) Received: by mail-wr0-x229.google.com with SMTP id r103so4272197wrb.0 for ; Wed, 05 Jul 2017 15:44:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vTKz6InCVgwEY/1jO+6ePLi9vR034Ywv3BmoXe7YlGw=; b=gfYyB0+fKDWN8XFTmJIUrTt0a2XA114yGnXSsGC7pXbONhyJYf6d4iOkuilx9uCl5g sqqBgCQXkiIBzq2mXi0T8EWqzlgQ+tHYzNe2PzI6DNDc3xT6/TU9lFTklN1uQWUGPXtr 7VR1NbrdUi3kNlTIBxDHRtkaDGqE5AChdhm9/37XxTNOfucwnpcMb5OAeSvWieIhbEDk UgBRDYs5RV6bBM9ZTcS870hKU444a6oPWiOeMMsfjt7/FJxBGOl+iKC4AnaklPjexeqT bUwwy2obpmVp5omL3C39DNIuvKwtjtfRsoQPnNkcAuJg8npF9LME9y0Ht98oCNVZz9XO Js8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vTKz6InCVgwEY/1jO+6ePLi9vR034Ywv3BmoXe7YlGw=; b=gy5KutOBcT+EFVne68IFclqUpK9s0cUFM1qpOwzETYOuGk6cKCSSjgH/spISIAhLYB vZF+awhLmxg+b36R+JefKKlzFFIsy9pNMrBI2IJpoUL/d7h0azeTEUe1b7cfvLmwltBs XLuD1CCb2XmevmLQu2DRRdFxuUsngeRcbyZ2LghQqKtUcm7URE3so9CmJKb3VWgOJroA I+dTVpWd43jVx5+WH5tfuOaBkZ+hYS787+nZJVB7X7rJ0eya79yS9t65HvvtjFGmgwvb eRfT4AyoA2lIq61y9AaI5hgQNnjKxOwZ2hPZgv7e3UBnEHGrjUhFWQ++pyyTeWw4dxC0 hjBQ== X-Gm-Message-State: AIVw11058XxIYNjqvR95EWwRdwW+Uvp6XQPUbVRkgMGB4CQctd9qZAMx SM4oqpZjXF/Tfbj+gfuNcNPZs3N+4+cR X-Received: by 10.28.97.86 with SMTP id v83mr12084257wmb.74.1499294641058; Wed, 05 Jul 2017 15:44:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.72.4 with HTTP; Wed, 5 Jul 2017 15:43:59 -0700 (PDT) In-Reply-To: <70794fbf-fa86-4009-5c71-80096b451a3d@gmail.com> References: <70794fbf-fa86-4009-5c71-80096b451a3d@gmail.com> From: Richard Barnes Date: Wed, 5 Jul 2017 18:43:59 -0400 Message-ID: To: Yaron Sheffer Cc: "acme@ietf.org" Content-Type: multipart/alternative; boundary="001a1148e9f07e8e47055399bcb0" Archived-At: Subject: Re: [Acme] Consensus -- CAA draft to WGLC? X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 22:44:06 -0000 --001a1148e9f07e8e47055399bcb0 Content-Type: text/plain; charset="UTF-8" On Wed, Jul 5, 2017 at 5:48 PM, Yaron Sheffer wrote: > The problem with saying "Tokens registered as ACME challenge types MUST > NOT be used to identify non-ACME validation methods" is that ACME might > want to come up with additional method names in the future, and those just > might happen to conflict with methods that have been used by other > organizations in the meantime. This is exactly the kind of mess that IANA > is designed to prevent. > > A simple way to go around this issue is if we changed the draft to use > "acme-dns-01" instead of "dns-01" and similarly for all ACME methods. Then > we COULD say that non-ACME CAs MUST not use "acme-*" methods. > You could also set aside a vendor prefix (e.g., "vnd-", "ca-") that ACME stuff would be ruled out of. But your proposed solution seems better to me in light of the lessons of of RFC 6648. https://tools.ietf.org/html/rfc6648 > To your second point, many enterprise users will want the extra security > of "use this specific CA AND only with this method". There are probably > other use cases though. > I was about to say that such users could just specify an "issue" directive and a "validation-methods" directive, but the CAA spec is actually unclear on how the rules combine. I suppose that's because CAA right now is really only a CA whitelist, so there's no need for combining. If we want the CAA "tag" space to be extensible, it seems like there needs to be an update to the CAA spec to decide this. ISTM the conservative rule would be "You must satisfy one rule of each tag type; if you don't understand a tag type, don't issue". That would create the semantic I mention above. That part should probably go into a separate minor update spec, though, not in this spec. --Richard > > Thanks, > > Yaron > > > On 06/07/17 00:17, Richard Barnes wrote: > >> Just for context here: I think the original operating model for CAA was >> that the CA would tell the customer what values to put in there in order to >> authorize issuance. So it was safe to use arbitrary values because it was >> basically a closed loop CA -> Customer -> CAA -> CA. >> >> Nonetheless, I sympathize with your point here. With ACME, we're moving >> things in a more standardized / automated direction, so we can automate out >> some of the CA interaction around CAA if we standardize some values. >> >> Note that the ACME challenge type values are already registered. Would >> it be sufficient to say something like "Tokens registered as ACME challenge >> types MUST NOT be used to identify non-ACME validation methods"? >> >> --- >> >> This reminds me a related point that I forgot in my initial review. It >> would be nice if it were possible to specify a validation method policy >> independent of CA. So I wouldn't have to authorize each CA I interact with >> individually, but I would be able to say "Only validate my domains using >> dns-01". >> >> In fact, is there any reason to have different validation methods per >> CA? It's a property of the domain owner / certificate applicant, not the >> CA. Is there a reason you would trust CA X to do "http-01" but not CA Y? >> (I totally understand why "account-uri" is CA-specific, though.) >> >> I would suggest pulling out "validation-methods" from being an attribute >> to being a "tag" / "property", parallel to "issue" and "issuewild". >> >> >> >> On Wed, Jul 5, 2017 at 3:45 PM, Yaron Sheffer > > wrote: >> >> I support moving forward with the document. >> >> However I think the treatment of the acme-methods (or >> validation-methods) param is inconsistent, before and certainly >> after Richard's PR. The original draft only allows ACME methods >> and the special name "non-acme". This leaves the responsibility to >> ensure names are well defined with the IETF. >> >> If we allow mixing ACME methods with CA-defined methods per >> Richard's proposal, we should make sure that there is no overlap. >> And even if names are defined by individual CAs, the CA should >> provide a precise definition of each validation method. IMO there >> are two good options: >> >> - Define an IANA registry for the validation-methods values. (This >> is simple enough, and would be my preference). >> - Define an IANA registry for prefixes (such as "cabf" mentioned >> in Richard's text) and specify that everything else must be >> defined by ACME. >> >> Thanks, >> Yaron >> >> >> >> https://github.com/ietf-wg-acme/acme-caa/pull/2 >> >> >> On Wed, Jul 5, 2017 at 11:47 AM, Salz, Rich > > wrote: >> >> There's no listing going on here, since there's no >> registry for the >> >> values. CABF could put tokens in their documents if they >> like. >> >> Okay, please propose wording (or did you? Sorry if so) to >> change for the >> CAA draft. >> >> >> >> >> _______________________________________________ >> Acme mailing list >> Acme@ietf.org >> https://www.ietf.org/mailman/listinfo/acme >> >> >> >> > --001a1148e9f07e8e47055399bcb0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jul 5, 2017 at 5:48 PM, Yaron Sheffer <yaronf.ietf@gmail.c= om> wrote:
The problem with saying "Tokens registered as ACME challenge types = MUST NOT be used to identify non-ACME validation methods" is that ACME= might want to come up with additional method names in the future, and thos= e just might happen to conflict with methods that have been used by other o= rganizations in the meantime. This is exactly the kind of mess that IANA is= designed to prevent.

A simple way to go around this issue is if we changed the draft to use &quo= t;acme-dns-01" instead of "dns-01" and similarly for all ACM= E methods. Then we COULD say that non-ACME CAs MUST not use "acme-*&qu= ot; methods.

You could also set aside a= vendor prefix (e.g., "vnd-", "ca-") that ACME stuff wo= uld be ruled out of.=C2=A0 But your proposed solution seems better to me in= light of the lessons of of RFC 6648.


=C2=A0
To your second point, many enterprise users will want the extra security of= "use this specific CA AND only with this method". There are prob= ably other use cases though.

I was abou= t to say that such users could just specify an "issue" directive = and a "validation-methods" directive, but the CAA spec is actuall= y unclear on how the rules combine.=C2=A0 I suppose that's because CAA = right now is really only a CA whitelist, so there's no need for combini= ng.

If we want the CAA "tag" space to be= extensible, it seems like there needs to be an update to the CAA spec to d= ecide this.=C2=A0 ISTM the conservative rule would be "You must satisf= y one rule of each tag type; if you don't understand a tag type, don= 9;t issue".=C2=A0 That would create the semantic I mention above.=C2= =A0 That part should probably go into a separate minor update spec, though,= not in this spec.

--Richard

=C2=A0

Thanks,

=C2=A0 =C2=A0 Yaron


On 06/07/17 00:17, Richard Barnes wrote:
Just for context here: I think the original operating model for CAA was tha= t the CA would tell the customer what values to put in there in order to au= thorize issuance.=C2=A0 So it was safe to use arbitrary values because it w= as basically a closed loop CA -> Customer -> CAA -> CA.

Nonetheless, I sympathize with your point here.=C2=A0 With ACME, we're = moving things in a more standardized / automated direction, so we can autom= ate out some of the CA interaction around CAA if we standardize some values= .

Note that the ACME challenge type values are already registered.=C2=A0 Woul= d it be sufficient to say something like "Tokens registered as ACME ch= allenge types MUST NOT be used to identify non-ACME validation methods"= ;?

---

This reminds me a related point that I forgot in my initial review.=C2=A0 I= t would be nice if it were possible to specify a validation method policy i= ndependent of CA.=C2=A0 So I wouldn't have to authorize each CA I inter= act with individually, but I would be able to say "Only validate my do= mains using dns-01".

In fact, is there any reason to have different validation methods per CA?= =C2=A0 It's a property of the domain owner / certificate applicant, not= the CA. Is there a reason you would trust CA X to do "http-01" b= ut not CA Y?=C2=A0 (I totally understand why "account-uri" is CA-= specific, though.)

I would suggest pulling out "validation-methods" from being an at= tribute to being a "tag" / "property", parallel to &quo= t;issue" and "issuewild".



 On Wed, Jul 5, 2017 at 3:45 PM, Yaron Sheffer <yaronf.ietf@gmail.com <mailto:yaronf.ietf@gmail.co= m>> wrote:

=C2=A0 =C2=A0 I support moving forward with the document.

=C2=A0 =C2=A0 However I think the treatment of the acme-methods (or
=C2=A0 =C2=A0 validation-methods) param is inconsistent, before and certain= ly
=C2=A0 =C2=A0 after Richard's PR. The original draft only allows ACME m= ethods
=C2=A0 =C2=A0 and the special name "non-acme". This leaves the re= sponsibility to
=C2=A0 =C2=A0 ensure names are well defined with the IETF.

=C2=A0 =C2=A0 If we allow mixing ACME methods with CA-defined methods per =C2=A0 =C2=A0 Richard's proposal, we should make sure that there is no = overlap.
=C2=A0 =C2=A0 And even if names are defined by individual CAs, the CA shoul= d
=C2=A0 =C2=A0 provide a precise definition of each validation method. IMO t= here
=C2=A0 =C2=A0 are two good options:

=C2=A0 =C2=A0 - Define an IANA registry for the validation-methods values. = (This
=C2=A0 =C2=A0 is simple enough, and would be my preference).
=C2=A0 =C2=A0 - Define an IANA registry for prefixes (such as "cabf&qu= ot; mentioned
=C2=A0 =C2=A0 in Richard's text) and specify that everything else must = be
=C2=A0 =C2=A0 defined by ACME.

=C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Yaron



=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://github.com/ietf-w= g-acme/acme-caa/pull/2
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://github.com/ie= tf-wg-acme/acme-caa/pull/2>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 On Wed, Jul 5, 2017 at 11:47 AM, Salz, Rich <= ;rsalz@akamai.com=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:rsalz@akamai.com>> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 There's no list= ing going on here, since there's no
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 registry for the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 values.=C2=A0 CABF could put toke= ns in their documents if they
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 like.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Okay, please propose wording (or = did you?=C2=A0 Sorry if so) to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 change for the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CAA draft.




=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 Acme mailing list
 =C2=A0 =C2=A0 Acme@ietf.= org <mailto:Acme@= ietf.org>
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/a= cme
=C2=A0 =C2=A0 <https://www.ietf.org/mailman/listin= fo/acme>




--001a1148e9f07e8e47055399bcb0-- From nobody Thu Jul 6 01:40:25 2017 Return-Path: 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 BBF731270A3 for ; Thu, 6 Jul 2017 01:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 HpbYB6LvUKfn for ; Thu, 6 Jul 2017 01:40:21 -0700 (PDT) Received: from mail.core-networks.de (mail.core-networks.de [IPv6:2001:1bc0:d::4:9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D398113145E for ; Thu, 6 Jul 2017 01:40:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.core-networks.de id 1dT2Kd-0005VE-K4 with ESMTPSA (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) for acme@ietf.org; Thu, 06 Jul 2017 10:40:19 +0200 To: acme@ietf.org References: <0ed4eb20-d8b9-38c6-d3d1-9c02c0508a49@bartschnet.de> <77c51beccad146d1a6df2b80af6c920a@usma1ex-dag1mb1.msg.corp.akamai.com> From: "Rene 'Renne' Bartsch, B.Sc. Informatics" Message-ID: <7c328796-67cd-64ad-f577-593a2ed93cfd@bartschnet.de> Date: Thu, 6 Jul 2017 10:40:14 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: de-DE Archived-At: Subject: Re: [Acme] Automated procedure for DNS challenge records? X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 08:40:24 -0000 You think there should be a proprietary plug-in for any combination of DNS-provider <-> ACME-client? Creating DNS challenges on the fly makes things quite complicated. Another way to circumvent the whole challenge protocol for DNS would be to let the ACME-client create a static RSA-key-pair an publish the public key in die ACME-TXT-record. The ACME-client connects to the CA-server via TLS with it's private key and the CA-server just checks if the public key in the _acme-challenge.xxx.xxx TXT-record matches the private key of the TLS connection. Am 05.07.2017 um 03:08 schrieb Alan Doherty: > +1 > > agreed the acme client design (plugins/modules/supported server architectures etc) should really be down to the implementors/designers > > as some smaller ones will only talk acme + http-01 + 1 specific server (say acme client built into server/device) > > others may offer many/all auth mechanisms and server architectures (and dns apis) > > the WG is realy concerned with the api (and CA server reactions (and expectation of responses) > the myriad clients should handle the third side or the triangle > > client <--> acme-ca <----> client selected 3rd party > client <-----out of scope-> client selected 3rd party > > (3rd party as the webserver or dns provider can be entirely separate) > > At 15:28 04/07/2017 Tuesday, Daniel McCarney wrote: >> I agree with the others that have shared the opinion that this is outside of the scope of ACME and this WG. >> >> In my opinion we shouldn't reinvent the wheel. With RFC 2138 (DynDNS) there is already a protocol for clients to add/update/delete resource records on DNS servers. Most DNS server softwares support RFC 2136 out of the box. We just have to define a protocol to use (-> RFC 2136) in the ACME client. >> >> >> That's exactly right. At least one ACME client (Certbot) has been working on support for RFC 2136 (https://github.com/certbot/certbot/pull/4701) in addition to one-off provider specific DNS APIs. >> >> If you need a generic way to update DNS dynamically RFC 2138 is it. If your DNS provider doesn't support RFC 2136 it seems hard to imagine you could convince them to adopt a newly invented ACME DNS update scheme. >> >> - cpu >> >> On Mon, Jul 3, 2017 at 12:46 PM, Rene 'Renne' Bartsch, B.Sc. Informatics <ietf@bartschnet.de> wrote: >> >> >> Am 03.07.2017 um 18:28 schrieb Salz, Rich: >> For a fully automated validation process the ACME-client needs some kind of >> protocol/interface to add/update/remove the DNS challenge records on the >> primare DNS server. >> >> This is out of scope for our WG, but since we are looking at rechartering, it could be brought within scope. >> >> But I think programmatic maintenance of DNS records should probably be done within the DNS groups. >> >> >> In my opinion we shouldn't reinvent the wheel. With RFC 2138 (DynDNS) there is already a protocol for clients to add/update/delete resource records on DNS servers. Most DNS server softwares support RFC 2136 out of the box. We just have to define a protocol to use (-> RFC 2136) in the ACME client. >> >> >> _______________________________________________ >> 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 mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme From nobody Thu Jul 6 03:07:08 2017 Return-Path: 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 EB4DB128D3E for ; Thu, 6 Jul 2017 03:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=devever.net 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 AzVjz0MduXNJ for ; Thu, 6 Jul 2017 03:07:04 -0700 (PDT) Received: from umbriel.devever.net (umbriel.devever.net [149.202.51.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7547D127241 for ; Thu, 6 Jul 2017 03:07:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by umbriel.devever.net (Postfix) with ESMTP id 947891D661; Thu, 6 Jul 2017 12:07:02 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=devever.net; h= user-agent:in-reply-to:content-disposition:content-type :content-type:mime-version:references:message-id:subject:subject :from:from:date:date:received:received; s=mimas; t=1499335622; x=1517524983; bh=vLEwILHNzKupmhOZwO+XYi13QLqg7pY+76lC5oxsTKs=; b= cZpq6a6AhlhP1C3v9aw+Z5OV+COgPgqjBc9rIgJWssetSn0HnAD3feh1CZmMp3ME 7XTJMKL/IF5CjQpQYNflC82q/V0gF+GsMiUucP7fvW1iOPYH+CXBMOBxeCtwjCtO STfbKvKQL8ENuYmT8KHo3o4K04IBlmWd+ST02KF1cpizM9Bt11fdwW1ZcEcJVf36 VJ/zAHKR/b8K8JnohfDwpm6F1+IDPGlshAIbsKvWYXFgEyc5Z94nUPkD39z//y6o FxUQ+HRB675MAOjP/WC2oWcb1stBXtKXvVAmmbcVj/cSHSVkf4ckGff+z+1Aqkw7 DXzoIEpB1x0lqY3+ippqGQ== Received: from umbriel.devever.net ([127.0.0.1]) by localhost (umbriel.devever.net [127.0.0.1]) (amavisd-new, port 10026) with LMTP id ySInJIoKo8nB; Thu, 6 Jul 2017 12:07:02 +0200 (CEST) Received: from andover.lhh.devever.net (localhost [127.0.0.1]) by umbriel.devever.net (Postfix) with SMTP id 537701D660; Thu, 6 Jul 2017 12:07:02 +0200 (CEST) Date: Thu, 6 Jul 2017 11:07:02 +0100 From: Hugo Landau To: Richard Barnes Cc: acme@ietf.org Message-ID: <20170706100702.GA14472@andover.lhh.devever.net> References: <40e652477a2f47b0848330e64f72e8b2@usma1ex-dag1mb1.msg.corp.akamai.com> <177d761f214441a0b20bfc4ddc8dee9b@usma1ex-dag1mb1.msg.corp.akamai.com> <20170613173105.GB12048@LK-Perkele-V2.elisa-laajakaista.fi> <8baacb86ea9b455291fab177ce85b5ce@usma1ex-dag1mb1.msg.corp.akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.1 (2017-04-11) Archived-At: Subject: Re: [Acme] Consensus -- CAA draft to WGLC? X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 10:07:07 -0000 > [1]https://github.com/ietf-wg-acme/acme-caa/pull/2 1. I'm not sure what the point of changing "acme-methods" to "validation-methods" is. It still has the "non-acme" value, so it's clearly defined in relation to ACME. (Even if it wasn't, how is this namespace supposed to be defined? Should an IANA registry be requested rather than reusing the ACME validation methods registry? If so, it creates the possibility of divergence between the ACME methods registry and the validation methods registry. That, in turn, could be solved via some sort of inheritance between the two registries, but that would require changes to the ACME validation method registry, insofar that if someone registers string X in the ACME-CAA validation method registry for something unrelated to ACME, string X cannot thereafter be registered as an ACME validation method. Since this would restrain the ACME validation methods registry, consent would need to be obtained for this.) I see some of these concerns have already been mentioned. The prefix registry proposal works: Have an "acme" prefix which accesses the ACME validation methods namespace, e.g. "validation-methods=acme:dns-01,acme:tls-sni-02,cabf:foo". There could be an "unknown" value which would represent any validation method without an assigned identifier - but now that I think about it, since this structure would enable all parties to assign identifiers to even legacy validation methods, that seems like an unnecessary footgun. Vendor-assigned identifiers could be supported as such: vnd:example.com/custom-method But now we're reinventing URIs. So perhaps we should just switch to URIs and define an URN mapping for ACME validation methods. I'd support that. To summarise, I think we should keep "acme-methods" (and rely on the extensibility of CAA at the parameter level where non-ACME validation method constraints are to be expressed) or replace it with "validation-methods" taking a list of URIs (and defining a mapping from ACME validation method names to URNs). 2. Adding a reference to CABF is weird because it references a policy body. This is quite orthogonal to the IETF's mission, and these things should probably be kept separate. Since all commercial CAs need to be aware of the requirements of the CA/Browser forum anyway, the utility of this statement seems to be zero, and unnecessarily politicises the standard (for some value of politics). 3. Changing CA A to CA X, etc. is fine. (Splitting this up into multiple PRs would probably be desirable.) From nobody Thu Jul 6 03:17:13 2017 Return-Path: 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 48595129B4C for ; Thu, 6 Jul 2017 03:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NxJL3gzQYseB for ; Thu, 6 Jul 2017 03:16:58 -0700 (PDT) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::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 64C6E129468 for ; Thu, 6 Jul 2017 03:16:58 -0700 (PDT) Received: by mail-lf0-x22f.google.com with SMTP id z78so9903477lff.0 for ; Thu, 06 Jul 2017 03:16:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WKI1e65AMwFUqfHooVly9UuX3kZNd4SgALWVpnSGCN0=; b=qXPsnpYlt3ESlsQBJNVaIIo/B3t3unE2CJbK3lpAc5Rc2gGr9OaS28n7BCds3K1fNE q2pog9C+Op/MCbEb0+E/A+J2455MDM+YpBV2uz/JLG1r9Uq3OM99kcclQs/ozeqyYka3 T0dQfY5aSthLREC9yyZQGJmaYnxOi4yLCUv8IlmDtVYquaVzjgrY+LviTCmCRdEjLccp EpwCwPnr8M7KlpC9YcicqxY/Yhm2jvcKvCyF6SxR78AFDp9zwYqepd5lkp9w6h5gibOo QhEUxa/XTDUcZMWDU0c7l+EVtXaZuWy+qt0ZsgweUlNBYUGSkux3wM+fajyfXQn2eC4w lxoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WKI1e65AMwFUqfHooVly9UuX3kZNd4SgALWVpnSGCN0=; b=QfDnWei7vqZ8D+BW6P2FY09GYCaPHthk5Vy4Z4rPo726h01uInvT7ymDeIpval/g/F ep+/kU8O0UlkB76AT9cW0+Wpjttp++oJszUeqluek6jSfSvQAcISKd6awpqxoUly1jov 4+5RXQpbg7MoiKYfj5zNnGgR2YpItgsmBgIoZpIdJ0E7qQrckySlLWymyHFeTpTHsCL1 QFZYvAaFXEnbeLoD+zk+KE4mYyLVQUXjwzDvqasi7+pRM5IWdpwCoVyYNpB1x03ekzdD gaxccloRfNNFogLTIudCpSowL+arZ1sVMcNwMv34duw9I/e/mIzz24RWBy2HmbLhLYAa +hOw== X-Gm-Message-State: AKS2vOyzTZLqgnoQYhnBIxzs/WaTBzeTrL6e1KFKbkv54YwSWCT1dTm1 mtPgBl6axNDfJu74mjG80cxqpBVxyftG X-Received: by 10.25.202.82 with SMTP id h18mr12630829lfj.172.1499336216625; Thu, 06 Jul 2017 03:16:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.69.84 with HTTP; Thu, 6 Jul 2017 03:16:55 -0700 (PDT) In-Reply-To: <20170706100702.GA14472@andover.lhh.devever.net> References: <40e652477a2f47b0848330e64f72e8b2@usma1ex-dag1mb1.msg.corp.akamai.com> <177d761f214441a0b20bfc4ddc8dee9b@usma1ex-dag1mb1.msg.corp.akamai.com> <20170613173105.GB12048@LK-Perkele-V2.elisa-laajakaista.fi> <8baacb86ea9b455291fab177ce85b5ce@usma1ex-dag1mb1.msg.corp.akamai.com> <20170706100702.GA14472@andover.lhh.devever.net> From: Martin Thomson Date: Thu, 6 Jul 2017 20:16:55 +1000 Message-ID: To: Hugo Landau Cc: Richard Barnes , "acme@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Acme] Consensus -- CAA draft to WGLC? X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 10:17:01 -0000 On 6 July 2017 at 20:07, Hugo Landau wrote: > Vendor-assigned identifiers could be supported as such: > vnd:example.com/custom-method RFC 6648 explains why vendor-prefixes can be a bad idea. I think that you should do as Yaron suggested and establish a registry. Set the bar low (specification required would be my choice) and then CABF can make a new entry as they see fit. In particular, do away with attaching some sort of semantic to prefixes. > 2. Adding a reference to CABF is weird This I agree with. From nobody Thu Jul 6 05:15:04 2017 Return-Path: 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 8F5A91316B9 for ; Thu, 6 Jul 2017 05:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w_u4AHF-OGVn for ; Thu, 6 Jul 2017 05:15:02 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 708551316DE for ; Thu, 6 Jul 2017 05:15:00 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v66CC1Hf015947; Thu, 6 Jul 2017 13:14:52 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=12MY6/lDbNC0V0jCBrMmglF9qghuwlkafQtgIEeuMic=; b=O8yOitx5XurR/U7Db6qQg7MGzYS/GzDd4LcatE3y7mvj7+wGCpMJWn7D80VcWaJvaZ4U nafClkHnRmyfHwgX3HprNgGql+3DR2MnPn7NYoUracE0nqMHwF8I6YzS7K7foPoYVzGR z1S9pXuAkv4oSqlrSKWerkXU0+xwTi2c/PLx0YoDgM4bwQLHUKyPuRECF78dFaswO7FH lbbtGyGm7+rYjThXLUJSwDVlrtuSc2aG0/QaUWEZgi2g4Jw+Sj/VMM0bgYfFuhfNIrcs GSL96B1cnyEfIFH+uQm0bUWRP64uBP5JKcqSJFLhCvvN4PYpTQ0ufqFA4iHWhrzm/tk0 Vg== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2bhjxw8f4a-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 06 Jul 2017 13:14:52 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v66CBWoQ014362; Thu, 6 Jul 2017 08:14:51 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 2bhm6e03tj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 06 Jul 2017 08:14:51 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 6 Jul 2017 05:14:50 -0700 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Thu, 6 Jul 2017 08:14:50 -0400 From: "Salz, Rich" To: "Rene 'Renne' Bartsch, B.Sc. Informatics" , "acme@ietf.org" Thread-Topic: [Acme] Automated procedure for DNS challenge records? Thread-Index: AQHS9A6Gl/VXFHhkE0qGQUwoFA975qJCNpBwgABWdgD//70ysIAASI6AgAFr2QCAAG/EQIACU4cA///4v4A= Date: Thu, 6 Jul 2017 12:14:49 +0000 Message-ID: References: <0ed4eb20-d8b9-38c6-d3d1-9c02c0508a49@bartschnet.de> <77c51beccad146d1a6df2b80af6c920a@usma1ex-dag1mb1.msg.corp.akamai.com> <7c328796-67cd-64ad-f577-593a2ed93cfd@bartschnet.de> In-Reply-To: <7c328796-67cd-64ad-f577-593a2ed93cfd@bartschnet.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.40.100] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-06_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1707060211 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-06_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1707060211 Archived-At: Subject: Re: [Acme] Automated procedure for DNS challenge records? X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 12:15:03 -0000 > You think there should be a proprietary plug-in for any combination of DN= S- > provider <-> ACME-client? The question is backwards. Does there have to be an open standard for any DNS provider/ACME client? There is an important distinction. From nobody Thu Jul 6 05:19:28 2017 Return-Path: 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 2CF031201F8 for ; Thu, 6 Jul 2017 05:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=figel.email 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 mHc82HakHSE3 for ; Thu, 6 Jul 2017 05:19:24 -0700 (PDT) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (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 D7BE712EA74 for ; Thu, 6 Jul 2017 05:19:23 -0700 (PDT) Received: by mail-wr0-x233.google.com with SMTP id r103so596447wrb.0 for ; Thu, 06 Jul 2017 05:19:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=figel.email; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=qvItGv8QfSRrPXaYntHp+/WlGC0b4iV+Me2EYC2FrIo=; b=nI9N+/B3+FaTX4f1654dupspocoyyyUxgA6QHTbgVDdKp4FZqObfwuwlOALqsTLTdO 2O2UZUKJk9vmqu+D6W8UUW3lAnVuStplFo+DilWwOVA6gKJ9HvEydkPNnTSzOdoYnHvv yRB+pavNajq8sa6p9LFh2udduOjfjXDVa8f+dkIQm93C/WrR5BVY36ICzJEoIYgt1t82 cn+WK9f2kLK8l3h+RXngm3CsRqWwm6wVJYVp5p8SFzt0sp/qmfaYUep5ADzUHswXUgle Ek8AbwFoOhQkecnLCvnzQ1cHrYhu6K11j4fj4Fv91BaAleWux5Wdf+VojRYaTY10f2BV ddiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=qvItGv8QfSRrPXaYntHp+/WlGC0b4iV+Me2EYC2FrIo=; b=dPuHu67U+xoXVgfE/IrDJpdMXPncAH0dG7HDnJkMHLyIiAGJB0iU4CGNZaUvmqS4ed LStA5In0JUT4zlo+jj3ZHFMKGsB1sdd/vdYV1t657t2h3pkswqMzSSNlfa/p/5F3XkEx WU1TTaliaMjxZjFxrnrNJvDNT3ksYVgkqIvtV/fKVb1719tc68UoS0j+N5I8iWnyJglV w0+szMgqPW4leMACbg0ZDnuFXDSpzvAZCNbbXR4sEed5XAgilK5/URMo7SbyrVhYGhBx Rl/Go276oTdVfzBBtusa/BQJPB946ad/w0BeJwj1lXvZFSJo6jjvJrzGoxGvePzvzjgw cI/A== X-Gm-Message-State: AKS2vOzdAd5HNTl/I1y8KCAwJjIygI4MN1gaD4eQmwrKq8cYrLPxMhw2 4JPS9vaV7tMu2LoVZXDtfg== X-Received: by 10.28.16.17 with SMTP id 17mr25453893wmq.1.1499343561901; Thu, 06 Jul 2017 05:19:21 -0700 (PDT) Received: from Patricks-MBP.home.pf.vc (213-47-56-124.cable.dynamic.surfer.at. [213.47.56.124]) by smtp.gmail.com with ESMTPSA id y2sm88419wmy.29.2017.07.06.05.19.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Jul 2017 05:19:21 -0700 (PDT) To: "Rene 'Renne' Bartsch, B.Sc. Informatics" , acme@ietf.org References: <0ed4eb20-d8b9-38c6-d3d1-9c02c0508a49@bartschnet.de> <77c51beccad146d1a6df2b80af6c920a@usma1ex-dag1mb1.msg.corp.akamai.com> <7c328796-67cd-64ad-f577-593a2ed93cfd@bartschnet.de> From: Patrick Figel Message-ID: <6b841add-dbe6-af3a-b806-2ba43776e090@figel.email> Date: Thu, 6 Jul 2017 14:19:20 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:54.0) Gecko/20100101 Thunderbird/54.0 MIME-Version: 1.0 In-Reply-To: <7c328796-67cd-64ad-f577-593a2ed93cfd@bartschnet.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Acme] Automated procedure for DNS challenge records? X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 12:19:27 -0000 On 7/6/17 10:40 AM, Rene 'Renne' Bartsch, B.Sc. Informatics wrote: > You think there should be a proprietary plug-in for any combination of > DNS-provider <-> ACME-client? The best case would be RFC 2138, but that's not something that can be enforced. > Creating DNS challenges on the fly makes things quite complicated. > Another way to circumvent the whole challenge protocol for DNS would be > to let the ACME-client create a static RSA-key-pair an publish the > public key in die ACME-TXT-record. The ACME-client connects to the > CA-server via TLS with it's private key and the CA-server just checks if > the public key in the _acme-challenge.xxx.xxx TXT-record matches the > private key of the TLS connection. I don't think this option is viable in the Web PKI today, given current CA/B Forum policies. The Baseline Requirements state that either a Random Value or a (single-use) Request Token must be part of the DNS record used for validation. I'm inclined to agree that some sort of key-based validation would be beneficial both from a UX perspective and in order to avoid situations where API keys for DNS servers are stored on web servers for no reason other than challenge validation. Naturally, demonstrating ownership of a key that's published in the DNS is not quite the same thing as demonstrating the ability to change records on demand, given that keys can leak, but the same can be said for API keys. I would say that a situation where the attacker has the ability to issue a certificate is preferable to one where they have both the ability to issue a certificate *and* change DNS records at will, saving them the trouble of finding some other way to intercept traffic. Do other WG members feel similar to this, and should this be brought up on the CA/B Forum mailing list? Patrick > Am 05.07.2017 um 03:08 schrieb Alan Doherty: >> +1 >> >> agreed the acme client design (plugins/modules/supported server >> architectures etc) should really be down to the implementors/designers >> >> as some smaller ones will only talk acme + http-01 + 1 specific server >> (say acme client built into server/device) >> >> others may offer many/all auth mechanisms and server architectures >> (and dns apis) >> >> the WG is realy concerned with the api (and CA server reactions (and >> expectation of responses) >> the myriad clients should handle the third side or the triangle >> >> client <--> acme-ca <----> client selected 3rd party >> client <-----out of scope-> client selected 3rd party >> >> (3rd party as the webserver or dns provider can be entirely separate) >> >> At 15:28 04/07/2017 Tuesday, Daniel McCarney wrote: >>> I agree with the others that have shared the opinion that this is >>> outside of the scope of ACME and this WG. >>> >>> In my opinion we shouldn't reinvent the wheel. With RFC 2138 (DynDNS) >>> there is already a protocol for clients to add/update/delete resource >>> records on DNS servers. Most DNS server softwares support RFC 2136 >>> out of the box. We just have to define a protocol to use (-> RFC >>> 2136) in the ACME client. >>> >>> >>> That's exactly right. At least one ACME client (Certbot) has been >>> working on support for RFC 2136 >>> (https://github.com/certbot/certbot/pull/4701) >>> in addition to one-off provider specific DNS APIs. >>> >>> If you need a generic way to update DNS dynamically RFC 2138 is it. >>> If your DNS provider doesn't support RFC 2136 it seems hard to >>> imagine you could convince them to adopt a newly invented ACME DNS >>> update scheme. >>> >>> - cpu >>> >>> On Mon, Jul 3, 2017 at 12:46 PM, Rene 'Renne' Bartsch, B.Sc. >>> Informatics <ietf@bartschnet.de> wrote: >>> >>> >>> Am 03.07.2017 um 18:28 schrieb Salz, Rich: >>> For a fully automated validation process the ACME-client needs some >>> kind of >>> protocol/interface to add/update/remove the DNS challenge records on the >>> primare DNS server. >>> >>> This is out of scope for our WG, but since we are looking at >>> rechartering, it could be brought within scope. >>> >>> But I think programmatic maintenance of DNS records should probably >>> be done within the DNS groups. >>> >>> >>> In my opinion we shouldn't reinvent the wheel. With RFC 2138 (DynDNS) >>> there is already a protocol for clients to add/update/delete resource >>> records on DNS servers. Most DNS server softwares support RFC 2136 >>> out of the box. We just have to define a protocol to use (-> RFC >>> 2136) in the ACME client. >>> >>> >>> _______________________________________________ >>> 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 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 From nobody Thu Jul 6 08:57:28 2017 Return-Path: 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 8D2B612EC0B for ; Thu, 6 Jul 2017 08:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uz1RgsS88ikW for ; Thu, 6 Jul 2017 08:57:25 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09982129AAA for ; Thu, 6 Jul 2017 08:57:24 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v66FvKq2015765; Thu, 6 Jul 2017 16:57:20 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=Bvt2GgQzZoFeYvO8f/DQvAVXS50aKTgyDDPI5z/VfCc=; b=UWB4/nQ8Wi3fsP7BVFHbSGhSe2QUK7R3o+qNuDJMP9e2vftZI39AEP4FI3OvVGsN0aQT T80Umr0b6ekY6Bgct29ExdRBY+QqL2ktJ/sYIJbVqeOk2VvwJ97oZ5X2uxaW5v2o8NYJ E9f6OJlUh8YNSYKVXRm9e5f9V7Cpeu5rlFWGrj3a7b2l6SIUaFCDvApzVOoXrctoxXIP NXdU9VQl/uqXIaus2AJMG4qln2vZ/XraROIWRtnA9J3e8i1fnM6mJYsEsONPgzSiEOCh Xxg8fh+7mMXUJnXCZXmp9NGolR15PEP94hKkaxc6A64MgNQ+2YfYC3jpTAX8bVeBraLX qw== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2bhjxw9g3j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 06 Jul 2017 16:57:20 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v66Fu9wx004347; Thu, 6 Jul 2017 11:57:16 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint2.akamai.com with ESMTP id 2bhm6e0r0m-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 06 Jul 2017 11:57:15 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 6 Jul 2017 08:57:15 -0700 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Thu, 6 Jul 2017 11:57:15 -0400 From: "Salz, Rich" To: Hugo Landau , Richard Barnes CC: "acme@ietf.org" Thread-Topic: [Acme] Consensus -- CAA draft to WGLC? Thread-Index: AdLgaixZ2HxcGKQGRUWoL8+FK3tFFwD/4jaAAAR+qwAABCs5gAAIUaCABEZO7AAACD9nAP//zmQAgAEkKgD//+GdYA== Date: Thu, 6 Jul 2017 15:57:14 +0000 Message-ID: References: <40e652477a2f47b0848330e64f72e8b2@usma1ex-dag1mb1.msg.corp.akamai.com> <177d761f214441a0b20bfc4ddc8dee9b@usma1ex-dag1mb1.msg.corp.akamai.com> <20170613173105.GB12048@LK-Perkele-V2.elisa-laajakaista.fi> <8baacb86ea9b455291fab177ce85b5ce@usma1ex-dag1mb1.msg.corp.akamai.com> <20170706100702.GA14472@andover.lhh.devever.net> In-Reply-To: <20170706100702.GA14472@andover.lhh.devever.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.233] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-06_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1707060276 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-06_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1707060276 Archived-At: Subject: Re: [Acme] Consensus -- CAA draft to WGLC? X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 15:57:26 -0000 So let's see. Can we live with this? Create a spec-required registry for validation method names. Do not reference CABF docs. Change the CA sample names from A B to X Y or foo bar or this that or whate= ver. From nobody Thu Jul 6 09:23:59 2017 Return-Path: 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 2146A129462 for ; Thu, 6 Jul 2017 09:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8GS8VAjnEA92 for ; Thu, 6 Jul 2017 09:23:56 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 934171317DF for ; Thu, 6 Jul 2017 09:23:51 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v66GMWUo005300 for ; Thu, 6 Jul 2017 17:23:50 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=lBs7ZX9GJbJvVliTZyVwCw1tAWvDybEduCwIP2Z6OnU=; b=KFr0ARjOysKnWpMZiRXJ8D+On42DpDNxDrxLnXKj/6iZuYN6sM/ran/46Qd1fi8XWIQh KhxvpqN5QTueecQm+jJAvm9+qcdl7EFpfpIs3qmNtOGnDhhTojZSR1ZBbGybAo/mtUev xj8E4W/E/TUt2fUTB/bovE3Wak0AMUZVrWnaCsxlD1n6xIJm6eJx+K9wRDIo4h4DnmD1 rsR2uGX0IG5c1jbbkYX8k5t6JhznAW9+C+hPHkOoieRsE8xYmBsTBW1hWclTB86cmdtN UOfIE4i5T5I0mc6Dl545JfUfLqBGKPOfAeWijSHyYI9Iyi6n8DfL369Tz6tPpYSXsrnf HQ== Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2bhjxw9mqy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 06 Jul 2017 17:23:50 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v66GLRCf019677 for ; Thu, 6 Jul 2017 12:23:50 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint1.akamai.com with ESMTP id 2be72uda7d-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Thu, 06 Jul 2017 12:23:49 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 6 Jul 2017 12:23:49 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Thu, 6 Jul 2017 12:23:49 -0400 From: "Salz, Rich" To: "acme@ietf.org" Thread-Topic: Draft agenda for IETF in Prague Thread-Index: AdL2cxQ7RSdQ1LL0R6yJmMz5cusk1A== Date: Thu, 6 Jul 2017 16:23:48 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.233] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-06_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1707060281 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-06_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1707060281 Archived-At: Subject: [Acme] Draft agenda for IETF in Prague X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 16:23:57 -0000 We have two hours Friday morning. Administrivia 5 minutes Note well Introduction of our new co-chair Jabber scribe, minute taker (there will be gifts) Richard Barnes et al, draft-ietf-acme-acme-07 20 minutes Whatever it takes to advance this past WGLC; to be confirmed on the list Hugo Landau, draft-ietf-acme-caa 10 minutes Same as previous Jon Peterson, et al draft-ietf-acme-telephone 15 minutes Introduction to draft; get volunteers to read/review Mary Barnes et al draft-ietf-acme-service-provider 15 minutes Same as previous Yaron Sheffer et al, draft-ietf-acme-star 15 minutes Discussion of auto-renewal mechanism Alexey Melnikov, draft-ietf-acme-email-smime and draft-ietf-acme-email-tls = 15 minutes We will not rathole. We will not rathole Recharter discussion 5 minutes Ted Leaves amidst a flurry of memes 5 minutes Rich leaves for the airport :) From nobody Thu Jul 6 18:57:06 2017 Return-Path: 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 446F9129B38 for ; Thu, 6 Jul 2017 18:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 FjsFxw7PLSPo for ; Thu, 6 Jul 2017 18:57:02 -0700 (PDT) Received: from bigsvr.orionnetworks.ie (hosting.orionnetworks.ie [195.2.202.63]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B9B812F251 for ; Thu, 6 Jul 2017 18:57:02 -0700 (PDT) Received: from host249.freudenhaus.alandoherty.net ([193.120.128.249]:1205 helo=alans-p4.alandoherty.net) by bigsvr.orionnetworks.ie with esmtpsa(TLSv1:DHE-RSA-AES256-SHA:256) (auth-as tel1) (nexus 1.3.4.80.1) (envelope-from ) id 1dTIVv-0006y3-0z ; Fri, 07 Jul 2017 01:57:01 +0000 X-AD-RPFS-HEAD: for info on below codes http://www.alandoherty.net/mailsystem/mail-tagging/ X-AD-RPFS-GOOD-0: AV-SCAN-PASS SA-SCORE--1.6 SA-BAR-(-) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 07 Jul 2017 02:56:51 +0100 To: "Rene 'Renne' Bartsch, B.Sc. Informatics" , acme@ietf.org From: Alan Doherty In-Reply-To: <7c328796-67cd-64ad-f577-593a2ed93cfd@bartschnet.de> References: <0ed4eb20-d8b9-38c6-d3d1-9c02c0508a49@bartschnet.de> <77c51beccad146d1a6df2b80af6c920a@usma1ex-dag1mb1.msg.corp.akamai.com> <7c328796-67cd-64ad-f577-593a2ed93cfd@bartschnet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: X-VIRUS: NONE {no virus found, This is no guarentee} Archived-At: Subject: Re: [Acme] Automated procedure for DNS challenge records? X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 01:57:05 -0000 At 09:40 06/07/2017 Thursday, Rene 'Renne' Bartsch, B.Sc. Informatics wrote: >You think there should be a proprietary plug-in for any combination of DNS-provider <-> ACME-client? not at all (only mentioned plugin as many acme clients use separately maintained plugins for each/every challenge type (as thats how they roll) obviously monolithic ones such as the LE clients add support for whatever dns-providers they wish themselves but as with all challenge types having an optional (call user provided script X to update dns/http/etc is worthwhile so people can roll their own) >Creating DNS challenges on the fly makes things quite complicated. Another way to circumvent the whole challenge protocol for DNS would be to let the ACME-client create a static RSA-key-pair an publish the public key in die ACME-TXT-record. The ACME-client connects to the CA-server via TLS with it's private key and the CA-server just checks if the public key in the _acme-challenge.xxx.xxx TXT-record matches the private key of the TLS connection. I disagree its no more/less easy http challenge on-the-fly I suspect Im not the only one running my own private and acl'd off from internet, api on my dns master that receives updates, edits the zone and responds when complete (to avoid exposing a public api that may be brute forced) and I run a (3rd party) acme(letsencrypt) client that calls my client-side-script for each challenge (these talk to my private api on the master dns server) all im saying is there are 3 sides to the conversation client <1> acme-server <2> dns/http/other-auth-system <3> client I think acme should only codify the communication on the two sides that the acme-server converses on as client developers can decide to support/neglect as many (or few) auth types and http/dns/other providers as they like >Am 05.07.2017 um 03:08 schrieb Alan Doherty: >>+1 >> >>agreed the acme client design (plugins/modules/supported server architectures etc) should really be down to the implementors/designers >> >>as some smaller ones will only talk acme + http-01 + 1 specific server (say acme client built into server/device) >> >>others may offer many/all auth mechanisms and server architectures (and dns apis) >> >>the WG is realy concerned with the api (and CA server reactions (and expectation of responses) >>the myriad clients should handle the third side or the triangle >> >>client <--> acme-ca <----> client selected 3rd party >>client <-----out of scope-> client selected 3rd party >> >>(3rd party as the webserver or dns provider can be entirely separate) >> >>At 15:28 04/07/2017 Tuesday, Daniel McCarney wrote: >>>I agree with the others that have shared the opinion that this is outside of the scope of ACME and this WG. >>> >>>In my opinion we shouldn't reinvent the wheel. With RFC 2138 (DynDNS) there is already a protocol for clients to add/update/delete resource records on DNS servers. Most DNS server softwares support RFC 2136 out of the box. We just have to define a protocol to use (-> RFC 2136) in the ACME client. >>> >>> >>>That's exactly right. At least one ACME client (Certbot) has been working on support for RFC 2136 (https://github.com/certbot/certbot/pull/4701) in addition to one-off provider specific DNS APIs. >>> >>>If you need a generic way to update DNS dynamically RFC 2138 is it. If your DNS provider doesn't support RFC 2136 it seems hard to imagine you could convince them to adopt a newly invented ACME DNS update scheme. >>> >>>- cpu >>> >>>On Mon, Jul 3, 2017 at 12:46 PM, Rene 'Renne' Bartsch, B.Sc. Informatics <ietf@bartschnet.de> wrote: >>> >>> >>>Am 03.07.2017 um 18:28 schrieb Salz, Rich: >>>For a fully automated validation process the ACME-client needs some kind of >>>protocol/interface to add/update/remove the DNS challenge records on the >>>primare DNS server. >>> >>>This is out of scope for our WG, but since we are looking at rechartering, it could be brought within scope. >>> >>>But I think programmatic maintenance of DNS records should probably be done within the DNS groups. >>> >>> >>>In my opinion we shouldn't reinvent the wheel. With RFC 2138 (DynDNS) there is already a protocol for clients to add/update/delete resource records on DNS servers. Most DNS server softwares support RFC 2136 out of the box. We just have to define a protocol to use (-> RFC 2136) in the ACME client. >>> >>> >>>_______________________________________________ >>>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 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 From nobody Thu Jul 6 22:04:39 2017 Return-Path: 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 CCF2E129AF7 for ; Thu, 6 Jul 2017 22:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 e-Z6wa_FV4cA for ; Thu, 6 Jul 2017 22:04:34 -0700 (PDT) Received: from mail.core-networks.de (mail.core-networks.de [IPv6:2001:1bc0:d::4:9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1E55129AF6 for ; Thu, 6 Jul 2017 22:04:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.core-networks.de id 1dTLRN-0001f1-Ef with ESMTPSA (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) for acme@ietf.org; Fri, 07 Jul 2017 07:04:33 +0200 To: acme@ietf.org References: <0ed4eb20-d8b9-38c6-d3d1-9c02c0508a49@bartschnet.de> <77c51beccad146d1a6df2b80af6c920a@usma1ex-dag1mb1.msg.corp.akamai.com> <7c328796-67cd-64ad-f577-593a2ed93cfd@bartschnet.de> From: "Rene 'Renne' Bartsch, B.Sc. Informatics" Message-ID: Date: Fri, 7 Jul 2017 07:04:27 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Acme] Automated procedure for DNS challenge records? X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 05:04:38 -0000 Am 07.07.2017 um 03:56 schrieb Alan Doherty: > At 09:40 06/07/2017 Thursday, Rene 'Renne' Bartsch, B.Sc. Informatics wrote: >> You think there should be a proprietary plug-in for any combination of DNS-provider <-> ACME-client? > not at all > (only mentioned plugin as many acme clients use separately maintained plugins for each/every challenge type (as thats how they roll) > obviously monolithic ones such as the LE clients add support for whatever dns-providers they wish themselves > but as with all challenge types having an optional (call user provided script X to update dns/http/etc is worthwhile so people can roll their own) > > >> Creating DNS challenges on the fly makes things quite complicated. Another way to circumvent the whole challenge protocol for DNS would be to let the ACME-client create a static RSA-key-pair an publish the public key in die ACME-TXT-record. The ACME-client connects to the CA-server via TLS with it's private key and the CA-server just checks if the public key in the _acme-challenge.xxx.xxx TXT-record matches the private key of the TLS connection. > I disagree its no more/less easy http challenge on-the-fly > I suspect Im not the only one running my own private and acl'd off from internet, api on my dns master that receives updates, edits the zone and responds when complete (to avoid exposing a public api that may be brute forced) > and I run a (3rd party) acme(letsencrypt) client that calls my client-side-script for each challenge (these talk to my private api on the master dns server) > > > all im saying is there are 3 sides to the conversation > > client <1> acme-server <2> dns/http/other-auth-system <3> client > > I think acme should only codify the communication on the two sides that the acme-server converses on > as client developers can decide to support/neglect as many (or few) auth types and http/dns/other providers as they like A lot of DNS server providers do not allow to modify the zones on the fly. My DNS server provider e.g. uses a hidden primary DNS for security reasons. Changing zones is only possible manually via the web-interface. A lot of other DNS server providers limit the update rate or use timeouts. DNS was explicitly planned as a non-real-time system. In that cases e.g. CertBot runs always in timeouts and cannot work automatically. A static key in the DNS zone would solve that problem. From nobody Thu Jul 6 22:10:20 2017 Return-Path: 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 8989C129AFC for ; Thu, 6 Jul 2017 22:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 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 BasnnPUHrJCL for ; Thu, 6 Jul 2017 22:10:16 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 824CE129AF7 for ; Thu, 6 Jul 2017 22:10:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8024; q=dns/txt; s=iport; t=1499404215; x=1500613815; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=3XGOhwibkxfb+zRzwCPu8G18uXANns0CSv0IpzznrDM=; b=MNFHvrloa2SpLmQ/yjs8/5JhmCx5i4JiMAEWLYEhE790cU6ayqL9KEO6 uAEjIAdg24IDRjfbqAf4MvZMLYQdAySqQyVu86zf3lVTZpY6jrMaWdmnQ 3O2CTaFavUgex+vmR/lSC3yoBhJ4Nl2Qhmn1BcCTkTjVzTbJyMX+tbgZY g=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DZAACYFl9Z/xbLJq1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgy2BEIERjglzkFQilgOBMgNcBxoLgjWDOwKDdhgBAgEBAQEBAQFrKIU?= =?us-ascii?q?ZAQEBAwEBIQRHGwsOCicDAgInHxEGAQwGAgEBiisQsDSBbDoYixwBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBEA+DJ4UtKwuCboRUgymCYQWfFoQqgh2BAYxCggxXiEKGeok?= =?us-ascii?q?3jAIfOIEKMSEIGxVJhxg+NoZhK4ISAQEB?= X-IronPort-AV: E=Sophos;i="5.40,320,1496102400"; d="asc'?scan'208";a="653083358" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Jul 2017 05:10:10 +0000 Received: from [10.61.167.96] ([10.61.167.96]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v675AAil004030; Fri, 7 Jul 2017 05:10:10 GMT To: Alan Doherty , "Rene 'Renne' Bartsch, B.Sc. Informatics" , acme@ietf.org References: <0ed4eb20-d8b9-38c6-d3d1-9c02c0508a49@bartschnet.de> <77c51beccad146d1a6df2b80af6c920a@usma1ex-dag1mb1.msg.corp.akamai.com> <7c328796-67cd-64ad-f577-593a2ed93cfd@bartschnet.de> From: Eliot Lear Message-ID: <5404f249-e642-5137-6430-9df5d097057b@cisco.com> Date: Fri, 7 Jul 2017 07:10:09 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="f6KPICGbhRChkCF3XkXF5oKNkkSXdBOsI" Archived-At: Subject: Re: [Acme] Automated procedure for DNS challenge records? X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 05:10:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --f6KPICGbhRChkCF3XkXF5oKNkkSXdBOsI Content-Type: multipart/mixed; boundary="52aivD8lXPpUlppl9u3k9t3kikJquqkee"; protected-headers="v1" From: Eliot Lear To: Alan Doherty , "Rene 'Renne' Bartsch, B.Sc. Informatics" , acme@ietf.org Message-ID: <5404f249-e642-5137-6430-9df5d097057b@cisco.com> Subject: Re: [Acme] Automated procedure for DNS challenge records? References: <0ed4eb20-d8b9-38c6-d3d1-9c02c0508a49@bartschnet.de> <77c51beccad146d1a6df2b80af6c920a@usma1ex-dag1mb1.msg.corp.akamai.com> <7c328796-67cd-64ad-f577-593a2ed93cfd@bartschnet.de> In-Reply-To: --52aivD8lXPpUlppl9u3k9t3kikJquqkee Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Just a caution that configuration for 2138 is not always straight forward and in implementation and deployment sometimes has interactions with other functions. I suggest that someone who really wants to do the standardization here install a version of opendnssec and get things working with that code running. Documenting those steps would prove useful (he says having chosen another form of auth, having been down this road). Eliot On 7/7/17 3:56 AM, Alan Doherty wrote: > At 09:40 06/07/2017 Thursday, Rene 'Renne' Bartsch, B.Sc. Informatics = wrote: >> You think there should be a proprietary plug-in for any combination of= DNS-provider <-> ACME-client? > not at all > (only mentioned plugin as many acme clients use separately maintained p= lugins for each/every challenge type (as thats how they roll) > obviously monolithic ones such as the LE clients add support for whatev= er dns-providers they wish themselves > but as with all challenge types having an optional (call user provided = script X to update dns/http/etc is worthwhile so people can roll their ow= n) > > >> Creating DNS challenges on the fly makes things quite complicated. Ano= ther way to circumvent the whole challenge protocol for DNS would be to l= et the ACME-client create a static RSA-key-pair an publish the public key= in die ACME-TXT-record. The ACME-client connects to the CA-server via TL= S with it's private key and the CA-server just checks if the public key i= n the _acme-challenge.xxx.xxx TXT-record matches the private key of the T= LS connection. > I disagree its no more/less easy http challenge on-the-fly > I suspect Im not the only one running my own private and acl'd off from= internet, api on my dns master that receives updates, edits the zone and= responds when complete (to avoid exposing a public api that may be brute= forced) > and I run a (3rd party) acme(letsencrypt) client that calls my client-s= ide-script for each challenge (these talk to my private api on the master= dns server) > > > all im saying is there are 3 sides to the conversation > > client <1> acme-server <2> dns/http/other-auth-system <3> client > > I think acme should only codify the communication on the two sides that= the acme-server converses on > as client developers can decide to support/neglect as many (or few) aut= h types and http/dns/other providers as they like=20 > > > > > > > >> Am 05.07.2017 um 03:08 schrieb Alan Doherty: >>> +1 >>> >>> agreed the acme client design (plugins/modules/supported server archi= tectures etc) should really be down to the implementors/designers >>> >>> as some smaller ones will only talk acme + http-01 + 1 specific serve= r (say acme client built into server/device) >>> >>> others may offer many/all auth mechanisms and server architectures (a= nd dns apis) >>> >>> the WG is realy concerned with the api (and CA server reactions (and = expectation of responses) >>> the myriad clients should handle the third side or the triangle >>> >>> client <--> acme-ca <----> client selected 3rd party >>> client <-----out of scope-> client selected 3rd party >>> >>> (3rd party as the webserver or dns provider can be entirely separate)= >>> >>> At 15:28 04/07/2017 Tuesday, Daniel McCarney wrote: >>>> I agree with the others that have shared the opinion that this is ou= tside of the scope of ACME and this WG. >>>> >>>> In my opinion we shouldn't reinvent the wheel. With RFC 2138 (DynDNS= ) there is already a protocol for clients to add/update/delete resource r= ecords on DNS servers. Most DNS server softwares support RFC 2136 out of = the box. We just have to define a protocol to use (-> RFC 2136) in the AC= ME client. >>>> >>>> >>>> That's exactly right. At least one ACME client (Certbot) has been wo= rking on support for RFC 2136 (https://github.com/certbot/certbot/pull/4701) in addition to one-off = provider specific DNS APIs. >>>> >>>> If you need a generic way to update DNS dynamically RFC 2138 is it. = If your DNS provider doesn't support RFC 2136 it seems hard to imagine yo= u could convince them to adopt a newly invented ACME DNS update scheme. >>>> >>>> - cpu >>>> >>>> On Mon, Jul 3, 2017 at 12:46 PM, Rene 'Renne' Bartsch, B.Sc. Informa= tics <ietf@bartschnet.de> wrote: >>>> >>>> >>>> Am 03.07.2017 um 18:28 schrieb Salz, Rich: >>>> For a fully automated validation process the ACME-client needs some = kind of >>>> protocol/interface to add/update/remove the DNS challenge records on= the >>>> primare DNS server. >>>> >>>> This is out of scope for our WG, but since we are looking at rechart= ering, it could be brought within scope. >>>> >>>> But I think programmatic maintenance of DNS records should probably = be done within the DNS groups. >>>> >>>> >>>> In my opinion we shouldn't reinvent the wheel. With RFC 2138 (DynDNS= ) there is already a protocol for clients to add/update/delete resource r= ecords on DNS servers. Most DNS server softwares support RFC 2136 out of = the box. We just have to define a protocol to use (-> RFC 2136) in the AC= ME client. >>>> >>>> >>>> _______________________________________________ >>>> 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 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 mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > --52aivD8lXPpUlppl9u3k9t3kikJquqkee-- --f6KPICGbhRChkCF3XkXF5oKNkkSXdBOsI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEbBAEBCAAGBQJZXxeyAAoJEIe2a0bZ0nozDKEH92eiIkmvAdhLIOJ/KFZLk1+R a7aFroukHMil5mXJlbrijYQfBdOZKCSPc+f3Krn/qaxz4ttXMjaZz5rucnanCtvm 9yzqg9ZoTO7o/ov3GXK2/p1zyf7U+clUZcbeECZN0UEoG7/AmqL2iiNKIzQT72JC JhkfOibeoiRmwhWutk56KL3I0C4JscQadb3Iv4ZmLyhqUapvyEznDwV0oM5y1VjB M2WDc4AxOPvuld93Sq4BrbOfSeOo96utWQ8xjpN3TRDUPZVIrwrzbE7TuJpcDYJa raex8Xj4SnB3r9l86BOLIgUbLx3lWfsv9hCyZahw9IUymAnh+XOl2KdWj1v5hQ== =rpX/ -----END PGP SIGNATURE----- --f6KPICGbhRChkCF3XkXF5oKNkkSXdBOsI-- From nobody Thu Jul 6 22:28:27 2017 Return-Path: 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 9FB1F128B8D for ; Thu, 6 Jul 2017 22:28:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 dojHTZlS-O43 for ; Thu, 6 Jul 2017 22:28:25 -0700 (PDT) Received: from mail.core-networks.de (mail.core-networks.de [IPv6:2001:1bc0:d::4:9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87760126D45 for ; Thu, 6 Jul 2017 22:28:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.core-networks.de id 1dTLoV-0002Rz-U8 with ESMTPSA (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) for acme@ietf.org; Fri, 07 Jul 2017 07:28:24 +0200 To: acme@ietf.org References: <0ed4eb20-d8b9-38c6-d3d1-9c02c0508a49@bartschnet.de> <77c51beccad146d1a6df2b80af6c920a@usma1ex-dag1mb1.msg.corp.akamai.com> <7c328796-67cd-64ad-f577-593a2ed93cfd@bartschnet.de> <5404f249-e642-5137-6430-9df5d097057b@cisco.com> From: "Rene 'Renne' Bartsch, B.Sc. Informatics" Message-ID: <4f89629d-a6e4-bc09-02fb-747456983b7e@bartschnet.de> Date: Fri, 7 Jul 2017 07:28:23 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <5404f249-e642-5137-6430-9df5d097057b@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Acme] Automated procedure for DNS challenge records? X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 05:28:26 -0000 Am 07.07.2017 um 07:10 schrieb Eliot Lear: > Just a caution that configuration for 2138 is not always straight > forward and in implementation and deployment sometimes has interactions > with other functions. I suggest that someone who really wants to do the > standardization here install a version of opendnssec and get things > working with that code running. Documenting those steps would prove > useful (he says having chosen another form of auth, having been down > this road). After the information of my DNS server provider not having any interface for automated operations I have given up the RFC 2136 approach. In my opinion a solution with dynamic records is way to complicated. The easier solution is if every ACME-client creates a static asymmetric key pair. The operator can add the public key manually to the DNS records and the ACME-client uses the private key for authorization with the CA. From nobody Fri Jul 7 04:01:35 2017 Return-Path: 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 BC2E0126C22 for ; Fri, 7 Jul 2017 04:01:33 -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, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 sbZgDnjTwO9Z for ; Fri, 7 Jul 2017 04:01:31 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 9837E126BF6 for ; Fri, 7 Jul 2017 04:01:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id A2F0120363; Fri, 7 Jul 2017 14:01:29 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id dj_mleJab_8x; Fri, 7 Jul 2017 14:01:29 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id EFA2AC4; Fri, 7 Jul 2017 14:01:26 +0300 (EEST) Date: Fri, 7 Jul 2017 14:01:26 +0300 From: Ilari Liusvaara To: "Rene 'Renne' Bartsch, B.Sc. Informatics" Cc: acme@ietf.org Message-ID: <20170707110126.aodu7vuixwef7gwg@LK-Perkele-VII> References: <0ed4eb20-d8b9-38c6-d3d1-9c02c0508a49@bartschnet.de> <77c51beccad146d1a6df2b80af6c920a@usma1ex-dag1mb1.msg.corp.akamai.com> <7c328796-67cd-64ad-f577-593a2ed93cfd@bartschnet.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [Acme] Automated procedure for DNS challenge records? X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 11:01:33 -0000 On Fri, Jul 07, 2017 at 07:04:27AM +0200, Rene 'Renne' Bartsch, B.Sc. Informatics wrote: > > A lot of DNS server providers do not allow to modify the zones on the fly. > My DNS server provider e.g. uses a hidden primary DNS for security reasons. > Changing zones is only possible manually via the web-interface. A lot of > other DNS server providers limit the update rate or use timeouts. DNS was > explicitly planned as a non-real-time system. In that cases e.g. CertBot > runs always in timeouts and cannot work automatically. A static key in the > DNS zone would solve that problem. However, CABForum BRs (which all public CAs are required to abide by) prohibit static keys in DNS (funkily enough, BRs seem to allow static keys in WHOIS). I think if one wanted to change that, next step would be to make a fleshed out proposal for such validation method and a through security analysis of it (in order to guide possible changes to BRs). As note: The time it takes from a CABForum member positing a ballot with two endorsers to incorporation of said ballot (if ballot passes vote and there are no IPR issues) into BRs is about 7 weeks. Of course, with complicated ballots, it takes a lot of time to prepare the ballot. -Ilari From nobody Fri Jul 7 06:23:26 2017 Return-Path: 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 DC88312942F for ; Fri, 7 Jul 2017 06:23:23 -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_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aj5og8yArA6W for ; Fri, 7 Jul 2017 06:23:22 -0700 (PDT) Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::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 CA3D212EC10 for ; Fri, 7 Jul 2017 06:23:21 -0700 (PDT) Received: by mail-wr0-x229.google.com with SMTP id k67so46858504wrc.2 for ; Fri, 07 Jul 2017 06:23:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uTz/OwoIrNs7pZJpUlAgexIDfsu4zsIw/pemU6UFCFc=; b=2P54IvCirTcv9zVRsaPZsmqYAxuUtvJJwG/O4ABKXp0cNsJ9qKH71XavwL4vIfCwug 35bI5ZQ7oeTUNw5EwMvrkTKzhK+Opqvxdl5uuhpB2hIsJl7vsPubWRhvnrXO70L8xKMr 0tucmD2dDVIfdieWaSvaxMilUBR/l/ra/LuX2/gjL0mZhgJKca63ymIBsEIaxjBDRub1 LcSxrR123ScxCF6tAQ6QjOREI8E+ODpqU0l1cU52EPVgfu+RPB6xkQBLor0F4yy647oo w4Z9W/eCJ5TkwDKaebCjmHTyCH5TLgnpYhbT/JEUjql73P/h6iNW9SZfjImo2oKYX0bT oH9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uTz/OwoIrNs7pZJpUlAgexIDfsu4zsIw/pemU6UFCFc=; b=uGOxLkktjiK+ycr7ZhdXPr6H1t2QKnDx5XsqPybQ18HSu1+WsB4z0213xjL1zBxQYg L76gKMM++9z8/+WXPEMCdAEMuMEtollfp2dT78G6EJmeZsToOHcF2kFhQSBMAjXqH6kt RtfKxICzFvIpgOSd3OI2YPmcEdOd4zEUNwRZoahpadj2aHNKzEu1MaloH1BL7LoRJFzd tn3UvZoPCW0qXcE4IH2FC+7UqSdOeWvyL3qEhQvjk9qcKt5shpSOn/eZcrThCK64kEPb zsCdEk0MzJG9dmNr+P3spoPOLFOwn6WOiuJ9ohA/PzrQNpnzRqnK2G4DrT/B/haBO4eG W5TQ== X-Gm-Message-State: AIVw112FvsJhgeCFI7TldWP1FXBW0lVt6FD1rn0LyzWu0A9idB8l6sIo RvMI7JfF2XyvkU0VWnEniv8fksCv7yP1 X-Received: by 10.28.178.203 with SMTP id b194mr2366334wmf.36.1499433800091; Fri, 07 Jul 2017 06:23:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.72.4 with HTTP; Fri, 7 Jul 2017 06:23:19 -0700 (PDT) In-Reply-To: References: <40e652477a2f47b0848330e64f72e8b2@usma1ex-dag1mb1.msg.corp.akamai.com> <177d761f214441a0b20bfc4ddc8dee9b@usma1ex-dag1mb1.msg.corp.akamai.com> <20170613173105.GB12048@LK-Perkele-V2.elisa-laajakaista.fi> <8baacb86ea9b455291fab177ce85b5ce@usma1ex-dag1mb1.msg.corp.akamai.com> <20170706100702.GA14472@andover.lhh.devever.net> From: Richard Barnes Date: Fri, 7 Jul 2017 09:23:19 -0400 Message-ID: To: "Salz, Rich" Cc: Hugo Landau , "acme@ietf.org" Content-Type: multipart/alternative; boundary="001a11444ad804efa30553ba2304" Archived-At: Subject: Re: [Acme] Consensus -- CAA draft to WGLC? X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 13:23:24 -0000 --001a11444ad804efa30553ba2304 Content-Type: text/plain; charset="UTF-8" On Thu, Jul 6, 2017 at 11:57 AM, Salz, Rich wrote: > So let's see. Can we live with this? > > Create a spec-required registry for validation method names. > I share Hugo's concern about divergence here. Should we maybe just put these in the ACME challenge types registry? It is already Spec-Required. That would mean that not all of those values would be usable with ACME, but that doesn't seems very likely to lead to interop problems, since a sensible ACME server wouldn't offer the non-ACME ones. Or you could just add a column to indicate ACME / non-ACME. In any case, if we go down this path, I would suggest we change "non-acme" to "vendor", in order to signify "something that is not in the registry". > Do not reference CABF docs. > I don't understand the concern here. IETF document reference non-IETF docs all the time. This seems like useful context. > Change the CA sample names from A B to X Y or foo bar or this that or > whatever. > This is already in my PR. I updated the PR with the "vendor" stuff above: https://github.com/ietf-wg-acme/acme-caa/pull/2/commits/e40c9cb7cfdf34b6fd2b4e0017ae626105287f58 --Richard --001a11444ad804efa30553ba2304 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Jul 6, 2017 at 11:57 AM, Salz, Rich <rsalz@akamai.com> wrote:
So let= 9;s see.=C2=A0 Can we live with this?

Create a spec-required registry for validation method names.

I share Hugo's concern about divergence here.=C2= =A0 Should we maybe just put these in the ACME challenge types registry?=C2= =A0 It is already Spec-Required.=C2=A0 That would mean that not all of thos= e values would be usable with ACME, but that doesn't seems very likely = to lead to interop problems, since a sensible ACME server wouldn't offe= r the non-ACME ones.=C2=A0 Or you could just add a column to indicate ACME = / non-ACME.

In any case, if we go down this pa= th, I would suggest we change "non-acme" to "vendor", i= n order to signify "something that is not in the registry".

=C2=A0
Do not reference CABF docs.

I don't= understand the concern here.=C2=A0 IETF document reference non-IETF docs a= ll the time.=C2=A0 This seems like useful context.

=
=C2=A0
Change the CA sample names from A B to X Y or foo bar or this that or whate= ver.

This is already in my PR.=C2=A0 I = updated the PR with the "vendor" stuff above:

--001a11444ad804efa30553ba2304-- From nobody Fri Jul 7 06:33:21 2017 Return-Path: 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 758CF131546 for ; Fri, 7 Jul 2017 06:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=devever.net 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 TJ8mAKWsTpbC for ; Fri, 7 Jul 2017 06:33:16 -0700 (PDT) Received: from umbriel.devever.net (umbriel.devever.net [149.202.51.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6947B131551 for ; Fri, 7 Jul 2017 06:33:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by umbriel.devever.net (Postfix) with ESMTP id CFDBC1D66A; Fri, 7 Jul 2017 15:33:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=devever.net; h= user-agent:in-reply-to:content-transfer-encoding :content-disposition:content-type:content-type:mime-version :references:message-id:subject:subject:from:from:date:date :received:received; s=mimas; t=1499434393; x=1517623754; bh=g6+v +vZ+CeGJUapUUDjPriYSsaCxDME9exKHzX0ZV1Q=; b=PX+uI8G4jz4uOLXHrFbz NDuHzBJnv9B1CNtDeLJ1Q2xg0Tt4G+XhhKLizQpKWvy/gzJNWTXpQO0dAQaPSXFm I+9eXw1kOkK31XEEN6Ddwu/7gQQN4vGoi0RucyPW2pSM2be6kO5d6uOamhp91ks7 kfbtWyIx4NeTYIwDvtW+UBakmjgk3cAEs+oCj2UwqpvHoF76rMjuLo2g1xCxW0MY g5m48NULgxyPeYv8VRWPzcbuTj9pAJsNTQKMhGwKcrytXYUiSHqNMGmBXqax4/If gBE5QSW8ej60AD/uNyYDvfD6z0lvm4VUZgFm6SruVAuJ6zo6Q01YOGVaP4hz/Afm 1g== Received: from umbriel.devever.net ([127.0.0.1]) by localhost (umbriel.devever.net [127.0.0.1]) (amavisd-new, port 10026) with LMTP id iDHBpIRQ4Kaz; Fri, 7 Jul 2017 15:33:13 +0200 (CEST) Received: from andover.lhh.devever.net (localhost [127.0.0.1]) by umbriel.devever.net (Postfix) with ESMTP id 966121D669; Fri, 7 Jul 2017 15:33:13 +0200 (CEST) Date: Fri, 7 Jul 2017 14:33:13 +0100 From: Hugo Landau To: Richard Barnes Cc: acme@ietf.org Message-ID: <20170707133313.GA15228@andover.lhh.devever.net> References: <177d761f214441a0b20bfc4ddc8dee9b@usma1ex-dag1mb1.msg.corp.akamai.com> <20170613173105.GB12048@LK-Perkele-V2.elisa-laajakaista.fi> <8baacb86ea9b455291fab177ce85b5ce@usma1ex-dag1mb1.msg.corp.akamai.com> <20170706100702.GA14472@andover.lhh.devever.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.8.1 (2017-04-11) Archived-At: Subject: Re: [Acme] Consensus -- CAA draft to WGLC? X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 13:33:19 -0000 > On Thu, Jul 6, 2017 at 11:57 AM, Salz, Rich <[1]rsalz@akamai.com> wrote: > > So let's see. Can we live with this? > > Create a spec-required registry for validation method names. > > I share Hugo's concern about divergence here. Should we maybe just put > these in the ACME challenge types registry? It is already Spec-Required. > That would mean that not all of those values would be usable with ACME, > but that doesn't seems very likely to lead to interop problems, since a > sensible ACME server wouldn't offer the non-ACME ones. Or you could just > add a column to indicate ACME / non-ACME. > In any case, if we go down this path, I would suggest we change "non-acme" > to "vendor", in order to signify "something that is not in the registry". In this case we may as well keep it called "acme-methods" and leave the extension of that namespace (ACME challenge method names) to non-ACME things to the future. From nobody Fri Jul 7 06:42:55 2017 Return-Path: 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 78C4412EB43 for ; Fri, 7 Jul 2017 06:42:54 -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_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jeK7nCeg6JlM for ; Fri, 7 Jul 2017 06:42:52 -0700 (PDT) Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::236]) (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 E984A1201F2 for ; Fri, 7 Jul 2017 06:42:51 -0700 (PDT) Received: by mail-wr0-x236.google.com with SMTP id c11so47715046wrc.3 for ; Fri, 07 Jul 2017 06:42:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aJdjxPruM2o4CzddD3dTdeDiPPkm8LGC1FGcEPDMFkc=; b=ZPGM/BkvNPQIEZv4HzVRH6VIfEDqg0ICCHrgYgmoFf7FeCDPe9ZKLQrNiN441TJpvN kGhyVl6VJNgNRVZNmNQqUPn/TYqgNryl2kiydiNODrjXZhH+qQIyLkYtl0eTa0hh4RRW H+fPEbKOYAI+uO+3sCrAY5W9ZoYlR3PvD46iFXMi4ERT/dmt6NG9q3zlwjkCnSPJ40xU J7k5RkamVM07o6TLRFWRWFtb7SRDzd5Bg5jIIpwsSC2/+NhiSdUKwMUcZw+iucc8Ypd4 iyqjaA1FeWaJ6COgja1dshgFN/rJ7DLaNbVFNhYujbakQrdb0WQ85hx8Flu7MyvgizaV pW7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=aJdjxPruM2o4CzddD3dTdeDiPPkm8LGC1FGcEPDMFkc=; b=cRkHd9PNpnJrRoL4alU5EKrzPaAVrrZw3ByfQy72akJpUPB+e7dnS54oVIK7vsoeJM YFrZ+M7S7N8ZdmQuTIy3G8okA3Gsj5ZbR3ZoZFzyDheuXIt/CHpGqeDtmkwG/vXg6qqo x8orD8B+E/zjt2jKSKMJxLO9W9JrUpWDv4iOoUl6n/OxYpYWZcDR1hiGuyWgCSSiMGVw Of/F2joqtPNqI1RbddhBBiAfZ7LscF0FBMKtRAXIqOrTNa4BxgoxCqfRQ3S7p2PYbfEd WaQYftvjpxea6cyVeXN/UJoPdTz3w6q9XUdRIJ5Aj2GZyOz1d/kp8frtpMGCNnrv0cqx pdBg== X-Gm-Message-State: AIVw113PMCqdVv2RHgMUPL6VlyPIsavAH+8dW3KdoieWPZ9zult/G4K7 AjFgNZpE3vhrdjIVo3vKlhCHku3Bxr5J X-Received: by 10.28.167.207 with SMTP id q198mr2396827wme.36.1499434970311; Fri, 07 Jul 2017 06:42:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.72.4 with HTTP; Fri, 7 Jul 2017 06:42:49 -0700 (PDT) In-Reply-To: References: <0896b144e7e942b1ac68db9ead4c42bb@usma1ex-dag1mb1.msg.corp.akamai.com> <20170619184423.wtpj2qtq6awk3rju@LK-Perkele-VII> <53c76454-56ac-dde7-6cf8-94a6e39a89fc@eff.org> <30977E7E-FD36-4FB1-A7CF-1390095E1EB2@akamai.com> From: Richard Barnes Date: Fri, 7 Jul 2017 09:42:49 -0400 Message-ID: To: Jacob Hoffman-Andrews Cc: "Dunning, John" , Ilari Liusvaara , "Salz, Rich" , "acme@ietf.org" Content-Type: multipart/alternative; boundary="001a114ba0c6c5071b0553ba6805" Archived-At: Subject: Re: [Acme] Rolling keys and pending validations X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 13:42:54 -0000 --001a114ba0c6c5071b0553ba6805 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 5, 2017 at 6:03 PM, Jacob Hoffman-Andrews wrote: > On 06/30/2017 09:54 AM, Dunning, John wrote: > > Based on your description below, I think door A makes more sense to me. > My paraphrase of it is that key authorizations get bound at creation time= , > and thus get =E2=80=9Cgrandfathered=E2=80=9D in after a credential rotati= on. > > This is a good paraphrase. What do other folks on this list think about > binding key authorization objects at creation time? I can't immediately s= ee > a security issue with it, but as a reminder, an earlier version of the > protocol was subject to a vulnerability (https://www.ietf.org/mail- > archive/web/acme/current/msg00484.html) related to changing the account > key after creating an authorization object, so I think tweaks in this are= a > deserve extra scrutiny. > Note that the solution I implemented in -07 was to bind not at challenge creation time, but at the time that a client responds to a challenge. I think I probably agree that it's simpler to bind at creation time, in the sense that it avoids more race conditions. It does move us more in the direction of the server just providing an opaque value to the client, but at least the client can still validate that the value makes sense. I'm tempted to propose an option (C), but I'm not sure it's actually a good idea: C) Instead of using *key* authorizations, use *account* authorizations. Instead of the object being of "token.H(key)", make it "token.H(account-url)". This would remove any question of roll-over interactions, and kind of match the pattern we established when we moved from using "jwk" in JWS to using "kid" with the account URL. In fact, I think that would remove the last reference we have to account keys outside of account management. However, I have the usual worries about the indirection caused by using account URLs, and the potential ambiguity of treating a URL as an octet string. --Richard --001a114ba0c6c5071b0553ba6805 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jul 5, 2017 at 6:03 PM, Jacob Hoffman-Andrews <jsha@ef= f.org> wrote:
=20 =20 =20
On 06/30/2017 09:54 AM, Dunning, John wrote:
=20 =20 =20 =20 =20
Based on your description below, I think door A makes more sense to me.=C2=A0 M= y paraphrase of it is that key authorizations get bound at creation time, and thus get =E2=80=9Cgrandfathered=E2=80=9D in af= ter a credential rotation.
 This is a good paraphrase. What do other folks on this list think about binding key authorization objects at creation time? I can't immediately see a security issue with it, but as a reminder, an earlier version of the protocol was subject to a vulnerability (https://www.ietf.org/mail-archive/web/acme/current/msg00484.ht= ml) related to changing the account key after creating an authorization object, so I think tweaks in this area deserve extra scrutiny.

Note that the solution I implemented in -07 was to bind not a= t challenge creation time, but at the time that a client responds to a chal= lenge.=C2=A0 I think I probably agree that it's simpler to bind at crea= tion time, in the sense that it avoids more race conditions.=C2=A0 It does = move us more in the direction of the server just providing an opaque value = to the client, but at least the client can still validate that the value ma= kes sense.

I'm tempted to propose an option (C), but I'm not sure it&= #39;s actually a good idea:

C) Instead of using *key* authorizations, use *accoun= t* authorizations.=C2=A0 Instead of the object being of "token.H(key)&= quot;, make it "token.H(account-url)".

This would remove any question o= f roll-over interactions, and kind of match the pattern we established when= we moved from using "jwk" in JWS to using "kid" with t= he account URL.=C2=A0 In fact, I think that would remove the last reference= we have to account keys outside of account management.=C2=A0 However, I ha= ve the usual worries about the indirection caused by using account URLs, an= d the potential ambiguity of treating a URL as an octet string.

--Richard
=

--001a114ba0c6c5071b0553ba6805-- From nobody Fri Jul 7 06:57:06 2017 Return-Path: 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 42331129B10 for ; Fri, 7 Jul 2017 06:57:05 -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_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ot39M0_-KrBA for ; Fri, 7 Jul 2017 06:57:03 -0700 (PDT) Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::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 E4092126C83 for ; Fri, 7 Jul 2017 06:57:02 -0700 (PDT) Received: by mail-wr0-x22e.google.com with SMTP id c11so48243561wrc.3 for ; Fri, 07 Jul 2017 06:57:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GCsoZuWoAo6iRuVItMXQt48FcZKeGrMn7c+yn/RQqnc=; b=d7r0oa2QJ15b2EJgrADBXaGxKxU+OzlD+behVL/PwnRtgiz5ADhbaiZdJ7l4HYFY3V t9I9R1v9wOSsLNQ6xThorYdm+EhpBiqvgj/wL6JWv6k7LAcb9hOcwc5T5Sun2KNfxNZg 8IcG+Vo+/AnYGZqM9s8qbhazDJVBezSFN8uXk4VLO45YoCPlAGJwG+jLrxeS3VjoUmRq a9TS+4Jt8gdHBfVw5gfru4GzT+K5P0rFOwy5xHTxpYUHnQim5x7AQ6NDFzQkvrfwWHC4 zjRULDEJx2mzjipOP1qRYp8L2Q0IFIv8VrBJPiUPaFoFMG0htXqFs4P62uSKiBBX18Fa p6wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GCsoZuWoAo6iRuVItMXQt48FcZKeGrMn7c+yn/RQqnc=; b=hXH7JT9F8Z3+LnP5lPORixuzvALKprJYXjZcCtghKnT9dZL4LOU9xasRistChR4oR2 fsPn20SVa7TsgasRAcjTvgQhV+wxLW66PPD6K0GBcjDPogUM1ubHke00xcCiIZZdi8wI NhAjlYNI3TR9Ftq2aA5yG7q6ScEoOlOdQ0S9lIHwDUlniFoFlr25mP9763eX6o8Oo0Yh 9r7HAWiDp+pzu9wgjsog3J8ZLj7A7hDBuR8fqIl/CX69kPJSLKv5nITHEhR9BpRtMbYD kQuoJDbUxYo/D6THKy9lgsfhMzmzmpxGLRjXaVuaHEQLbolCvZiug8BiXMed4XKf1Sl3 Syng== X-Gm-Message-State: AIVw112zDl3UMPOmdyb7m/feC4Q90l2yBID+v3zXQpinu8ckMHZNeW4U 61KcyxkaT73i76CEnZ4PbAQqXYqhxNpx7wHKHw== X-Received: by 10.223.139.218 with SMTP id w26mr815748wra.206.1499435821164; Fri, 07 Jul 2017 06:57:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.72.4 with HTTP; Fri, 7 Jul 2017 06:57:00 -0700 (PDT) In-Reply-To: <20170707133313.GA15228@andover.lhh.devever.net> References: <177d761f214441a0b20bfc4ddc8dee9b@usma1ex-dag1mb1.msg.corp.akamai.com> <20170613173105.GB12048@LK-Perkele-V2.elisa-laajakaista.fi> <8baacb86ea9b455291fab177ce85b5ce@usma1ex-dag1mb1.msg.corp.akamai.com> <20170706100702.GA14472@andover.lhh.devever.net> <20170707133313.GA15228@andover.lhh.devever.net> From: Richard Barnes Date: Fri, 7 Jul 2017 09:57:00 -0400 Message-ID: To: Hugo Landau Cc: "acme@ietf.org" Content-Type: multipart/alternative; boundary="f403045e9cf07c0b470553ba9b7d" Archived-At: Subject: Re: [Acme] Consensus -- CAA draft to WGLC? X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 13:57:05 -0000 --f403045e9cf07c0b470553ba9b7d Content-Type: text/plain; charset="UTF-8" On Fri, Jul 7, 2017 at 9:33 AM, Hugo Landau wrote: > > On Thu, Jul 6, 2017 at 11:57 AM, Salz, Rich <[1]rsalz@akamai.com> > wrote: > > > > So let's see. Can we live with this? > > > > Create a spec-required registry for validation method names. > > > > I share Hugo's concern about divergence here. Should we maybe just > put > > these in the ACME challenge types registry? It is already > Spec-Required. > > That would mean that not all of those values would be usable with > ACME, > > but that doesn't seems very likely to lead to interop problems, since > a > > sensible ACME server wouldn't offer the non-ACME ones. Or you could > just > > add a column to indicate ACME / non-ACME. > > In any case, if we go down this path, I would suggest we change > "non-acme" > > to "vendor", in order to signify "something that is not in the > registry". > In this case we may as well keep it called "acme-methods" and leave the > extension of that namespace (ACME challenge method names) to non-ACME > things to the future. > The future is now! :) https://github.com/ietf-wg-acme/acme/pull/332 Even if we don't make the ACME change, if we think that some day there might be non-ACME identifiers in this CAA field, then I would propose that we use "validation-methods" instead of "acme-methods", for future-proofing. --Richard --f403045e9cf07c0b470553ba9b7d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Jul 7, 2017 at 9:33 AM, Hugo Landau <hlandau@devever.net= > wrote:
>=C2=A0 =C2=A0 On Thu, Jul 6, 2017 at 11:57 AM, Salz= , Rich <[1]rsalz@akamai.com> = wrote:
>
>=C2=A0 =C2=A0 =C2=A0 So let's see.=C2=A0 Can we live with this?
>
>=C2=A0 =C2=A0 =C2=A0 Create a spec-required registry for validation met= hod names.
>
>=C2=A0 =C2=A0 I share Hugo's concern about divergence here.=C2=A0 S= hould we maybe just put
>=C2=A0 =C2=A0 these in the ACME challenge types registry?=C2=A0 It is a= lready Spec-Required.=C2=A0
>=C2=A0 =C2=A0 That would mean that not all of those values would be usa= ble with ACME,
>=C2=A0 =C2=A0 but that doesn't seems very likely to lead to interop= problems, since a
>=C2=A0 =C2=A0 sensible ACME server wouldn't offer the non-ACME ones= .=C2=A0 Or you could just
>=C2=A0 =C2=A0 add a column to indicate ACME / non-ACME.
>=C2=A0 =C2=A0 In any case, if we go down this path, I would suggest we = change "non-acme"
>=C2=A0 =C2=A0 to "vendor", in order to signify "somethin= g that is not in the registry".
In this case we may as well keep it called "acme-methods" = and leave the
extension of that namespace (ACME challenge method names) to non-ACME
things to the future.

The future is now= !=C2=A0 :)

https://github.com/ietf-wg-acme/acme/pull/332

Even if we don't make the ACME change, if we thi= nk that some day there might be non-ACME identifiers in this CAA field, the= n I would propose that we use "validation-methods" instead of &qu= ot;acme-methods", for future-proofing.

--= Richard

--f403045e9cf07c0b470553ba9b7d-- From nobody Fri Jul 7 07:51:51 2017 Return-Path: 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 12CF2129687 for ; Fri, 7 Jul 2017 07:51:48 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S6tzkAp_Euhj for ; Fri, 7 Jul 2017 07:51:46 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 378B013161F for ; Fri, 7 Jul 2017 07:51:46 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v67EpZp1020732; Fri, 7 Jul 2017 15:51:42 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=TFugCXdCIPi7EK/DwHwvqnMvZnUWuZamoDfLLqgTZqM=; b=iZ+gBUi3JL613Bzow2qhECLKHR9PkQC4ybPwFp6oOF20z+vGgVIx57blU+8VVcxwbOqo H2Rf9CKwzihNnYXOBWLavb/Hh4f4zAET0G+u+Den2jZXdZr6OdXgkGjWaCjBeGGk/nR/ QLwzBKxeVAiCqXAVq47uAC49+9pjiYMreQ9rg7nEg8VcfI4t91Mvl2ivAj1yTmEC8VSQ BZvJtlBtWlLJ4SYDqvio2Qwe4tRWCsoYWRnzndZHZItLB8qn8MUZRlgKiGX6mDO9ifuf +vb4kvmw5hAEUBA3neYSMH+ZO7CcP3EFn3MsukV86bRocVfe3nPXnG2aVM7ZI2MieySD wQ== Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2bj3dy1u2j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 07 Jul 2017 15:51:42 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v67EogJX009821; Fri, 7 Jul 2017 10:51:41 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint1.akamai.com with ESMTP id 2be72ug13v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 07 Jul 2017 10:51:41 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 7 Jul 2017 07:51:40 -0700 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Fri, 7 Jul 2017 10:51:40 -0400 From: "Salz, Rich" To: Richard Barnes , Hugo Landau CC: "acme@ietf.org" Thread-Topic: [Acme] Consensus -- CAA draft to WGLC? Thread-Index: AdLgaixZ2HxcGKQGRUWoL8+FK3tFFwD/4jaAAAR+qwAABCs5gAAIUaCABEZO7AAACD9nAP//zmQAgAEkKgD//+GdYIAB54+AgAACxICAAAalAIAANAJA Date: Fri, 7 Jul 2017 14:51:39 +0000 Message-ID: <94eda8437c13496c8a5c32a0d294bb8b@usma1ex-dag1mb1.msg.corp.akamai.com> References: <177d761f214441a0b20bfc4ddc8dee9b@usma1ex-dag1mb1.msg.corp.akamai.com> <20170613173105.GB12048@LK-Perkele-V2.elisa-laajakaista.fi> <8baacb86ea9b455291fab177ce85b5ce@usma1ex-dag1mb1.msg.corp.akamai.com> <20170706100702.GA14472@andover.lhh.devever.net> <20170707133313.GA15228@andover.lhh.devever.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-07_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1707070245 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-07_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1707070246 Archived-At: Subject: Re: [Acme] Consensus -- CAA draft to WGLC? X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 14:51:48 -0000 PiBodHRwczovL2dpdGh1Yi5jb20vaWV0Zi13Zy1hY21lL2FjbWUvcHVsbC8zMzINCg0KSSBsaWtl IHRoaXMuICBJIHByb3Bvc2VkIG9uZSBtaW5vciB3b3JkaW5nIGNsYXJpZmljYXRpb24uDQo= From nobody Fri Jul 7 11:06:18 2017 Return-Path: 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 931551316A3 for ; Fri, 7 Jul 2017 11:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.003 X-Spam-Level: X-Spam-Status: No, score=-7.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org 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 gh9qCVw6fW5K for ; Fri, 7 Jul 2017 11:06:16 -0700 (PDT) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A9F3126C0F for ; Fri, 7 Jul 2017 11:06:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject; bh=tyFrsbnOBXFH1hrm0nPIwd7zTBH1u4JbwN6P3M+4yfU=; b=GwU2KAzqPyFy90JZx2ssHjmbPk+bt/Ob0QIaWdh6Db/IWJjVAuGbOFeuXJ1P0aJQRKuhMnxzvbN9tchFCd2VWpg/0w55o0+1jzO5jLit00CHbqAq1u0syHWy5Eaw31av3C5u0uzzG9jU1Krx/DQv33M1ZhB5qsvQi5EEDSGw11Y=; Received: ; Fri, 07 Jul 2017 11:06:13 -0700 To: Richard Barnes Cc: "Salz, Rich" , Ilari Liusvaara , "acme@ietf.org" , "Dunning, John" References: <0896b144e7e942b1ac68db9ead4c42bb@usma1ex-dag1mb1.msg.corp.akamai.com> <20170619184423.wtpj2qtq6awk3rju@LK-Perkele-VII> <53c76454-56ac-dde7-6cf8-94a6e39a89fc@eff.org> <30977E7E-FD36-4FB1-A7CF-1390095E1EB2@akamai.com> From: Jacob Hoffman-Andrews Message-ID: <76e97edb-f652-02e4-b05b-c8ad6b5f89fc@eff.org> Date: Fri, 7 Jul 2017 11:06:14 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Received-SPF: skipped for local relay Archived-At: Subject: Re: [Acme] Rolling keys and pending validations X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 18:06:17 -0000 On 07/07/2017 06:42 AM, Richard Barnes wrote: > C) Instead of using *key* authorizations, use *account* > authorizations. Instead of the object being of "token.H(key)", make > it "token.H(account-url)". I like this in principle, and wish we'd adopted it several months ago. At this point, I think it's too big a change for too little benefit. The "bind keyAuthorization at challenge creation" approach has the benefit that most clients will not even notice the change. It only makes a different when key rollover and long-term pending challenges are in play, which is pretty uncommon. From nobody Fri Jul 7 12:35:48 2017 Return-Path: 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 D1D3A12EC11 for ; Fri, 7 Jul 2017 12:35:46 -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_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TCNMIF127nL6 for ; Fri, 7 Jul 2017 12:35:45 -0700 (PDT) Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::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 3AB89126CB6 for ; Fri, 7 Jul 2017 12:35:45 -0700 (PDT) Received: by mail-wr0-x22d.google.com with SMTP id 77so60082921wrb.1 for ; Fri, 07 Jul 2017 12:35:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4/gAhphqbB6HodvaC2u/NAxGSgjoBNL/dyu74fRcERw=; b=lDj260Ug5IZ3cHHDxWdFWY/Phqf4wk1Dq0a7q+i9gSlhuJOf58oXhsgunYKgMGydFL x43ZTgx3uPiUd3NnBiFxm4mM1sN8lYhfjvgeBYGmT7JxnI+7tQReOZTVsj/NGiuH5BjC cCPINp1FFQUG/F4MYzdU/pjPYMwKeaDzcA0RXJ75bKb1Z92fGdh6RLiel+ABnRiJA1B+ HNBxNqjA8e5CpIPc0f02zrjxJOrA55nVwadI90o2JLGUf0UmdybrymXd+WrR4LXMPapj Gbx/0syDLnRU0gpBCQmcq1CpZnslJ+fGYx7VDJtlM0YmccGMg06lILNToc47Z42d9SrS 7HLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4/gAhphqbB6HodvaC2u/NAxGSgjoBNL/dyu74fRcERw=; b=owOpGU5Pa5QoqdVUN+urOn8FLnO0SsrxHWvBhM9RIQRNcuJ9imrIE/pf71zERGylxX Ox6yKhkFFXIHEFVZ83gXgZh3DnhfrsxoX31XccueJpVsja/zzPbgPrKmx6FRqHIph9LM 9R0qysnfcWXq/03d9/yMG88t5aG/mMBabtJhPkgZnNCIRQm9l/+D4sbESu0N1PVsfAme LIhhvwKL3WuYqBsBO2bgW6ccz3NUePdwh3d/8FB3AfnN9sGg/PQFJ9ETZZDOTP+6Xrwe oxfBMAfH5ZQLEOlSzTd2tf9zUo0dJHse1K6JU2F0GZ6KN1DXjNx+Vi2/3Ldor/w3DjQU 3t1g== X-Gm-Message-State: AIVw112d/OQhTlYdUrJor+LZptzbZPyXRMxu5RhFG54txI1xDW6ElsB/ Tluhxuk3IYibHnfytZ2QR9jwIyYbcuLLFiFtwA== X-Received: by 10.28.178.203 with SMTP id b194mr279417wmf.36.1499456143613; Fri, 07 Jul 2017 12:35:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.72.4 with HTTP; Fri, 7 Jul 2017 12:35:42 -0700 (PDT) In-Reply-To: <76e97edb-f652-02e4-b05b-c8ad6b5f89fc@eff.org> References: <0896b144e7e942b1ac68db9ead4c42bb@usma1ex-dag1mb1.msg.corp.akamai.com> <20170619184423.wtpj2qtq6awk3rju@LK-Perkele-VII> <53c76454-56ac-dde7-6cf8-94a6e39a89fc@eff.org> <30977E7E-FD36-4FB1-A7CF-1390095E1EB2@akamai.com> <76e97edb-f652-02e4-b05b-c8ad6b5f89fc@eff.org> From: Richard Barnes Date: Fri, 7 Jul 2017 15:35:42 -0400 Message-ID: To: Jacob Hoffman-Andrews Cc: "Salz, Rich" , Ilari Liusvaara , "acme@ietf.org" , "Dunning, John" Content-Type: multipart/alternative; boundary="001a11444ad8cbfdfe0553bf56f9" Archived-At: Subject: Re: [Acme] Rolling keys and pending validations X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 19:35:47 -0000 --001a11444ad8cbfdfe0553bf56f9 Content-Type: text/plain; charset="UTF-8" On Fri, Jul 7, 2017 at 2:06 PM, Jacob Hoffman-Andrews wrote: > On 07/07/2017 06:42 AM, Richard Barnes wrote: > > C) Instead of using *key* authorizations, use *account* > > authorizations. Instead of the object being of "token.H(key)", make > > it "token.H(account-url)". > I like this in principle, and wish we'd adopted it several months ago. > At this point, I think it's too big a change for too little benefit. The > "bind keyAuthorization at challenge creation" approach has the benefit > that most clients will not even notice the change. It only makes a > different when key rollover and long-term pending challenges are in > play, which is pretty uncommon. > Whether clients will notice depends on how we change the syntax to express the "binding". You seem to be assuming that we'll keep the syntax the same. That would mean that the server would note the keyAuthorization to be used with the challenge at creation time, in a way that's invisible to the client, and the client would still compute and send back a keyAuthorization. So you'll break clients in the following scenario: 1. Server creates challenge bound to keyAuthorization_oldkey, sends to client 2. Client rolls keys 3. Client computes keyAuthorization_newkey 4. Client provisions the validation response with keyAuthorization_newkey 5. Client sends keyAuthorization_newkey in a response to the challenge, signed with newkey ... since now the client's keyAuthorization doesn't match the one the server bound. You only avoid the race condition if you express the keyAuthorization in the challenge. And that entails changing the "token" field to a "key-authorization" field, which will break clients. If clients are going to have to change either way, then option (C) seems like a marginally smaller change: Option (A): Pull the keyAuthorization from the challenge; delete keyAuthorization computation code Option (B): Put the account URL in the keyAuthorization instead of the account key; delete JWK thumbprint code --001a11444ad8cbfdfe0553bf56f9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Jul 7, 2017 at 2:06 PM, Jacob Hoffman-Andrews <jsha@ef= f.org> wrote:
On 07/07/2017 06:42 AM, Richard Barnes wrote:
> C) Instead of using *key* authorizations, use *account*
> authorizations.=C2=A0 Instead of the object being of "token.H(key= )", make
> it "token.H(account-url)".
I like this in principle, and wish we'd adopted it several month= s ago.
At this point, I think it's too big a change for too little benefit. Th= e
"bind keyAuthorization at challenge creation" approach has the be= nefit
that most clients will not even notice the change. It only makes a
different when key rollover and long-term pending challenges are in
play, which is pretty uncommon.

Whether clients will notice depends on how we change the synt= ax to express the "binding".=C2=A0 You seem to be assuming that w= e'll keep the syntax the same.=C2=A0 That would mean that the server wo= uld note the keyAuthorization to be used with the challenge at creation tim= e, in a way that's invisible to the client, and the client would still = compute and send back a keyAuthorization.=C2=A0 So you'll break clients= in the following scenario:

1. Server creates challenge bound to keyAuthorization= _oldkey, sends to client
2. Client roll= s keys
3. Client computes keyAuthorization_= newkey
4. Client provisions the valida= tion response with keyAuthorization_newkey
= 5. Client sends keyAuthorization_newkey in a response to the challenge, sig= ned with newkey

... since now the client's keyAuthorization doesn't m= atch the one the server bound.=C2=A0 You only avoid the race condition if y= ou express the keyAuthorization in the challenge.=C2=A0 And that entails ch= anging the "token" field to a "key-authorization" field= , which will break clients.

If clients are going to have to change either way, th= en option (C) seems like a marginally smaller change:

Option (A): Pull the keyAut= horization from the challenge; delete keyAuthorization computation code
=
Option (B): Put the account URL in the key= Authorization instead of the account key; delete JWK thumbprint code




--001a11444ad8cbfdfe0553bf56f9-- From nobody Fri Jul 7 15:09:46 2017 Return-Path: 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 D0ACF126B7F for ; Fri, 7 Jul 2017 15:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.002 X-Spam-Level: X-Spam-Status: No, score=-7.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org 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 1TOEZRiQZqCD for ; Fri, 7 Jul 2017 15:09:43 -0700 (PDT) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 526621316BC for ; Fri, 7 Jul 2017 15:09:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject; bh=JLvwK4NlftmZGfR+PJ8vctZmQGMQxtztRrcyTDFqDD8=; b=SgaWuKeglthDuZbM729EGsFhTXBG2/Ud4EIiEtNa7c32GK/8cPqy5l1FiJPau8D+WjxMMbj2EYPGXapt62mYAOtJJu8he7qsN6kr/a0arDO6mgb/d513GdT+uHnWE5OzffVDiaat0o5gB0HcF4IegA5P4vQs/vs1rBH6zJVuTkk=; Received: ; Fri, 07 Jul 2017 15:09:40 -0700 To: Richard Barnes Cc: "Salz, Rich" , Ilari Liusvaara , "acme@ietf.org" , "Dunning, John" References: <0896b144e7e942b1ac68db9ead4c42bb@usma1ex-dag1mb1.msg.corp.akamai.com> <20170619184423.wtpj2qtq6awk3rju@LK-Perkele-VII> <53c76454-56ac-dde7-6cf8-94a6e39a89fc@eff.org> <30977E7E-FD36-4FB1-A7CF-1390095E1EB2@akamai.com> <76e97edb-f652-02e4-b05b-c8ad6b5f89fc@eff.org> From: Jacob Hoffman-Andrews Message-ID: <8fa19fb2-6298-e882-1d23-3a409abaa247@eff.org> Date: Fri, 7 Jul 2017 15:09:41 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------DD15E576516206160C1C1EE8" Content-Language: en-US Received-SPF: skipped for local relay Archived-At: Subject: Re: [Acme] Rolling keys and pending validations X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 22:09:45 -0000 This is a multi-part message in MIME format. --------------DD15E576516206160C1C1EE8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 07/07/2017 12:35 PM, Richard Barnes wrote: > Whether clients will notice depends on how we change the syntax to > express the "binding". You seem to be assuming that we'll keep the > syntax the same. That would mean that the server would note the > keyAuthorization to be used with the challenge at creation time, in a > way that's invisible to the client Yep, I am assuming we'll keep the syntax the same. I don't see a reason to change. > So you'll break clients in the following scenario: > > 1. Server creates challenge bound to keyAuthorization_oldkey, sends to > client > 2. Client rolls keys > 3. Client computes keyAuthorization_newkey > 4. Client provisions the validation response with keyAuthorization_newk= ey > 5. Client sends keyAuthorization_newkey in a response to the > challenge, signed with newkey Yep, this was the scenario I was describing when I said: > It only makes a different when key rollover and long-term pending challenges are in play, which is pretty uncommon. Thanks for spelling it out in more detail, that makes it clearer. Essentially, I am saying that it is very rare for clients to hold onto pending authorizations while rolling keys. The most common clients (Cerbot, dehydrated, lego, etc) treat "get authorization; provision validation response; request validation" as a single automated steps, taking seconds or minutes. Those clients generally don't keep authorizations around between runs, and would be rotating keys between runs. So no problem. The only clients that would have to change are those that (a) cannot be fully automated, and therefore hold onto pending authorizations for days, and (b) rotate their keys regularly. As far as I'm aware, Akamai is the only client doing that, and they are the ones asking for "bind at creation time." I believe that most other clients would not notice a difference. --------------DD15E576516206160C1C1EE8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 07/07/2017 12:35 PM, Richard Barnes wrote:
Whether clients will notice depends on how we change the syntax to express the "binding".  You seem to be assuming that we'll keep the syntax the same.  That would mean that the server would note the keyAuthorization to be used with the challenge at creation time, in a way that's invisible to the client
Yep, I am assuming we'll keep the syntax the same. I don't see a reason to change.
So you'll break clients in the following scenario:

1. Server creates challenge bound to keyAuthorization_oldkey, sends to client
2. Client rolls keys
3. Client computes keyAuthorization_newkey
4. Client provisions the validation response with keyAuthorization_newkey
5. Client sends keyAuthorization_newkey in a response to the challenge, signed with newkey
Yep, this was the scenario I was describing when I said:

> It only makes a different when key rollover and long-term pending challenges are in
play, which is pretty uncommon.

Thanks for spelling it out in more detail, that makes it clearer. Essentially, I am saying that it is very rare for clients to hold onto pending authorizations while rolling keys. The most common clients (Cerbot, dehydrated, lego, etc) treat "get authorization; provision validation response; request validation" as a single automated steps, taking seconds or minutes. Those clients generally don't keep authorizations around between runs, and would be rotating keys between runs. So no problem.

The only clients that would have to change are those that (a) cannot be fully automated, and therefore hold onto pending authorizations for days, and (b) rotate their keys regularly. As far as I'm aware, Akamai is the only client doing that, and they are the ones asking for "bind at creation time." I believe that most other clients would not notice a difference.
--------------DD15E576516206160C1C1EE8-- From nobody Sat Jul 8 01:44:34 2017 Return-Path: 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 8B043126C23 for ; Sat, 8 Jul 2017 01:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=devever.net 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 Gm3AqB6V71p7 for ; Sat, 8 Jul 2017 01:44:31 -0700 (PDT) Received: from umbriel.devever.net (umbriel.devever.net [149.202.51.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C1D6124D68 for ; Sat, 8 Jul 2017 01:44:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by umbriel.devever.net (Postfix) with ESMTP id 456A81D676; Sat, 8 Jul 2017 10:44:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=devever.net; h= user-agent:in-reply-to:content-disposition:content-type :content-type:mime-version:references:message-id:subject:subject :from:from:date:date:received:received; s=mimas; t=1499503469; x=1517692830; bh=djeM+4Zz53/lU+LZu4HMMg3TyW0eUAbc/pRrz5ZYOyo=; b= hZGLzOEA19aY1BkV+NQ8Ds2rrouIAL6W8XC2iolRbvDESiXOy/9K2N4xK/1hItKc hiZujDOzp+HwIbE/NjfYDoRy57wh7v/NAOclkSD2dQCXjRGavLIfnK8vOs0p/+HI ZZCdNGaXqpGA8NqSqtHFV078j8r6XIYwWl2B4sTIcq6aLS+67+xeLrFSYlbsFS58 l9Vl/8ch8uGrmIwkne7SqlNXR+liuSAP+iOurjKlYy/SJlv6mEmj9Voy3HjtywnN OSta3/D5r3NIS1V7jqBFWJnubSTJsjKVJaJaMp2ymdLJMndksD+8yrygHiCVKqzc qYGMjcmFsULZqF4oVrKMtA== Received: from umbriel.devever.net ([127.0.0.1]) by localhost (umbriel.devever.net [127.0.0.1]) (amavisd-new, port 10026) with LMTP id 6cVbOIYd1NdD; Sat, 8 Jul 2017 10:44:29 +0200 (CEST) Received: from andover.lhh.devever.net (localhost [127.0.0.1]) by umbriel.devever.net (Postfix) with SMTP id EFD631D675; Sat, 8 Jul 2017 10:44:28 +0200 (CEST) Date: Sat, 8 Jul 2017 09:44:28 +0100 From: Hugo Landau To: "Salz, Rich" Cc: acme@ietf.org Message-ID: <20170708084427.GA18015@andover.lhh.devever.net> References: <8baacb86ea9b455291fab177ce85b5ce@usma1ex-dag1mb1.msg.corp.akamai.com> <20170706100702.GA14472@andover.lhh.devever.net> <20170707133313.GA15228@andover.lhh.devever.net> <94eda8437c13496c8a5c32a0d294bb8b@usma1ex-dag1mb1.msg.corp.akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <94eda8437c13496c8a5c32a0d294bb8b@usma1ex-dag1mb1.msg.corp.akamai.com> User-Agent: Mutt/1.8.1 (2017-04-11) Archived-At: Subject: Re: [Acme] Consensus -- CAA draft to WGLC? X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jul 2017 08:44:32 -0000 > > https://github.com/ietf-wg-acme/acme/pull/332 Alright, if the ACME spec wants to genericise its validation methods registry, I'm okay with the validation-methods change as-is. Questions: 1. Should we drop "non-acme", since any non-ACME method can have its own identifier listed? I think probably. 2. An ACME validation method, such as http-01, can only be used in the context of using ACME. Conversely, should non-ACME validation methods only be usable in non-ACME contexts? For example, suppose someone registered a "cabf-dv-http" validation method generically referring to CABF-compliant HTTP-based DV. If someone wants to use ACME, they can list http-01 specifically, so I think ACME CAs should ignore method specifiers like this. These method names would be applicable solely to non-ACME CAs. (This is sort of implied already by the subtext that an act of validation has exactly one validation method name applicable to it, but we could be clearer about this.) With regard to ACME-CAA PR#2: Is a "vendor" validation method, rather than a prefix, really that useful? RFC6648 deprecates prefixes like "x-", but thinks that vendor-specific prefixes like domain names are still OK. So we could amend the ACME specification allowing challenge method names of the form "foo@example.com", say (this is inspired by SSH capability names). This would have utility for vendors both in and outside of the context of ACME-CAA. From nobody Sun Jul 9 18:36:31 2017 Return-Path: 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 65A4713146E for ; Sun, 9 Jul 2017 18:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A3syW33fZVnx for ; Sun, 9 Jul 2017 18:36:29 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::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 ECC6412955F for ; Sun, 9 Jul 2017 18:36:28 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id v202so20574825itb.0 for ; Sun, 09 Jul 2017 18:36:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=rePUki5loc+JXANpMof4Np2Rr7jaGYbqj6tyfiVgaqI=; b=fVdq4nBSB1PfELw1+r4RtO5vqB9kuK5icWMnbfKCgAqPXHQuVzuK++YTAF5AZQ8a83 IJsPWR2lqEN9U7XE5N2Jn4a93+Bs9QJxdUj4TRVEJzovXqzGRykVwXuCstTsnluNemdy 3FWA9uqwdwPZ9S5An2FT1pTPXMa97xiRGKDnkSjiM8HPTHpIp4P+sLO/6E0e47NkO0Zr kMCbSV701o0QzaJkgMwSs5s6p9le6XVPG3lfJSG12I0UnlzHG612Pjz6bho4NLo/sX1m EFJG6cAYQbqOC9o+bjOcQ5TfGtZVaHP5KOyGjyMG7SPb/CfEhD8xV91Hwt1tp6X6BE7p Km5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=rePUki5loc+JXANpMof4Np2Rr7jaGYbqj6tyfiVgaqI=; b=qrk+ylYnGMdaP1vXd8385+ksgizZoTOHSV5ETkUq2oRTNEGUtTH9VHoFhwwU7SIJrw 2nmo7VaBwPK5nKmG80536+P/yJR6bPj8fWe5oWvUf6zh1AgwzEA8xqKI9RjJ6B6Hpfel J+zRMUfhNbE2sch++GKJ22RS11k3s/dry6hhK3ppNryNjAcqYlLOqSAf282FiKxhA6u5 5a04nM1u1Q7YdiEqqS6p9as38zGX4nSIwUVpoNmOwks5VIswHSX/Adf18dAqUIPhS/qd CGdrqhxQlbf5D4fkEoZR2MrxqSLiLrMgbIWRuzZarP1FpCWGUJX32bhuD47GvSVdcYoK pwtQ== X-Gm-Message-State: AIVw1100K2xcCslBHcSLXRFUmfTP5IIeIj5ol5NtfDrSjp1ULV9ZZ94E C5DM+7Yy8wwpn/++tCL8dPnjhywE0BPM43o= X-Received: by 10.107.39.205 with SMTP id n196mr1109607ion.37.1499650587585; Sun, 09 Jul 2017 18:36:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.26 with HTTP; Sun, 9 Jul 2017 18:36:26 -0700 (PDT) From: Martin Thomson Date: Mon, 10 Jul 2017 11:36:26 +1000 Message-ID: To: "acme@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Acme] Comments on draft-barnes-acme-service-provider X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 01:36:30 -0000 This document is a key piece of the STIR/SHAKEN infrastructure, as such, I think that this is worth working on and a good basis for that. I have a few questions, some of which might touch on the stir-certificates draft (which I see is in the RFC editor's queue, hmm). STIR certificates define TNAuthList to be a list of service provider codes, number ranges and numbers. Is there any reason why this needs have more than one service provider code? Indeed, is there any reason that service provider codes and telephone numbers need to be merged into a single type? Reading RFC 5280, subjectAltName can include multiple otherName values, each of which could be a serviceProviderCode or a telephone number set. I see several alternatives, for instance each otherName could be: 1. a mix of SPC and TN sets (today) 2. either a SPC or a TN set as two separate types 3. a single SPC with an associated TN set 4. a TN set with a optional SPC associated 5. a TN set with an optional SPC set It's not obvious, but I assume that there are cases where service providers end up with multiple service provider codes over time. If the numbers allocated to that provider get all mixed up so that there is no longer a clean mapping from a number to a service provider code, then option 1 (or 5) seem like the best choice. I ask because the encoding of TNAuthList into JSON isn't specified in the draft. It seems like the interactions here with the STI-PA are largely based on service provider code and the example is actually showing a service provider code (and not an E.164 range as might be inferred from the hypen). Is this the intended interaction model: a. the service provider sends its codes to the CA, b. the CA asks the STI-PA about the service provider codes, c. the STI-PA returns in the affirmative (possibly including associated telephone numbers), d. the CA authorizes the certificate issuance (possibly including the telephone numbers or using the telephone numbers to validate the subjectAltName proposed in the CSR). Or is the model intentionally flexible about what the service provider can request authorization for? Can the service provider request authorization for a telephone number range that is orthogonal to the codes that it might use? Having this explained in more details would help a lot. A ladder diagram for the interaction above might help too - existing ACME challenges mostly involve talking back to the ACME client, this goes to a third party. If there is some directed association between service provider codes and telephone numbers, then option 5 above might be a more natural fit for the certificate (or 4 if the TN-SPC mapping is forced to be many-to-one at the STI-PA). Otherwise, I'm not sure why the two types of data are intermixed. From the ACME perspective, I want to understand why there is a TNAuthList type rather than separate "service-provider-code" and "tn-set" identifiers. From nobody Sun Jul 9 18:46:10 2017 Return-Path: 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 D860D13146C for ; Sun, 9 Jul 2017 18:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RE_8TsJLO4TT for ; Sun, 9 Jul 2017 18:46:07 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::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 526BA1289C3 for ; Sun, 9 Jul 2017 18:46:07 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id k192so24355494ith.1 for ; Sun, 09 Jul 2017 18:46:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=fr6VuWdqlCRQ4AKEM8kQYUsmChme48nnPQRh9KU7F58=; b=cT38kRo+OeAALT9Ls7sxw5pbsrr3MIC1JMB/AwEybddTxymdos5SMzuDsIm/AacwhY 6sHZfdPnzeUHl6pLtYiWM3jVZat6UOUVppGXf36dS4dE/FJNjdyVk9oiuN5fAlmhws5/ r5VeWYaw0EIZuyTgWyMUDCSKYRkVsdM3jUImESWs+CK4h4BVjgYQb0vIno1oAevPmpo2 YTZDE1slL7fpkaJO0aKQlvEkXfMyL3ZYNu5wsPXOl5qdtgNogbZe7dajkKx2F1l4W4BY wajbxTbDBoFqrgk4QtLPvri57U9SfimPMTyW5jEIRwdYU5/gVkBOfDXjHBV98XYyu0gN w7zQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=fr6VuWdqlCRQ4AKEM8kQYUsmChme48nnPQRh9KU7F58=; b=SfrCKxfB1sBFlzeSveBUHo0plTq6zuRFuXfIPwu2GpiTHnP89B9Pjuz57rsalwlVib /arH/p/Gh46yLTe17Lv6NCbLGc/sDUcVxTDmez7CYVV7jZkZLpqRKCz05OP3HNkRjEq9 c968zPw3BraDhvAHvb93l441ONOZV/HrkiikZCd7FngXEtMcM/JrTINeeEuZpD9luv+n nyIuHm7YvjnETeiRvIR0NEpa2pEyniIvol/L2+7j49Opv65hAexniOH4NRe17Jw6/Qxw hDB/8COgExutq/pfrUqd1ZYCRwwUHfF/ZoxZBr3p/VnoBZyMxgejMCsVB4A2FNOScIES 2zPA== X-Gm-Message-State: AIVw11207ycOqTFt7bE3KQZpKGoaejH2VPhn9u6dRYwb/HpYldLh1Agj qYZUpIiMwB6uMjRhfaM8FIkzbpIKH4MG X-Received: by 10.36.175.73 with SMTP id l9mr9673048iti.102.1499651166433; Sun, 09 Jul 2017 18:46:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.26 with HTTP; Sun, 9 Jul 2017 18:46:05 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Mon, 10 Jul 2017 11:46:05 +1000 Message-ID: To: "acme@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Acme] Comments on draft-barnes-acme-service-provider X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 01:46:09 -0000 I just realized that I misunderstood and there is a bearer token being used to resolve the challenge and the service provider is responsible for talking to the STI-PA to get this. I think that this needs to have a bit more detail for it to be understood. On 10 July 2017 at 11:36, Martin Thomson wrote: > This document is a key piece of the STIR/SHAKEN infrastructure, as > such, I think that this is worth working on and a good basis for that. > I have a few questions, some of which might touch on the > stir-certificates draft (which I see is in the RFC editor's queue, > hmm). > > STIR certificates define TNAuthList to be a list of service provider > codes, number ranges and numbers. Is there any reason why this needs > have more than one service provider code? Indeed, is there any reason > that service provider codes and telephone numbers need to be merged > into a single type? Reading RFC 5280, subjectAltName can include > multiple otherName values, each of which could be a > serviceProviderCode or a telephone number set. I see several > alternatives, for instance each otherName could be: > > 1. a mix of SPC and TN sets (today) > 2. either a SPC or a TN set as two separate types > 3. a single SPC with an associated TN set > 4. a TN set with a optional SPC associated > 5. a TN set with an optional SPC set > > It's not obvious, but I assume that there are cases where service > providers end up with multiple service provider codes over time. If > the numbers allocated to that provider get all mixed up so that there > is no longer a clean mapping from a number to a service provider code, > then option 1 (or 5) seem like the best choice. > > I ask because the encoding of TNAuthList into JSON isn't specified in > the draft. It seems like the interactions here with the STI-PA are > largely based on service provider code and the example is actually > showing a service provider code (and not an E.164 range as might be > inferred from the hypen). > > Is this the intended interaction model: > > a. the service provider sends its codes to the CA, > b. the CA asks the STI-PA about the service provider codes, > c. the STI-PA returns in the affirmative (possibly including > associated telephone numbers), > d. the CA authorizes the certificate issuance (possibly including the > telephone numbers or using the telephone numbers to validate the > subjectAltName proposed in the CSR). > > Or is the model intentionally flexible about what the service provider > can request authorization for? Can the service provider request > authorization for a telephone number range that is orthogonal to the > codes that it might use? > > Having this explained in more details would help a lot. A ladder > diagram for the interaction above might help too - existing ACME > challenges mostly involve talking back to the ACME client, this goes > to a third party. > > If there is some directed association between service provider codes > and telephone numbers, then option 5 above might be a more natural fit > for the certificate (or 4 if the TN-SPC mapping is forced to be > many-to-one at the STI-PA). Otherwise, I'm not sure why the two types > of data are intermixed. From the ACME perspective, I want to > understand why there is a TNAuthList type rather than separate > "service-provider-code" and "tn-set" identifiers. From nobody Mon Jul 10 14:29:38 2017 Return-Path: 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 9EB1112EC05 for ; Mon, 10 Jul 2017 14:29:37 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8j2x8OHKtkAT for ; Mon, 10 Jul 2017 14:29:35 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::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 BB874127735 for ; Mon, 10 Jul 2017 14:29:34 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id i2so84256552qta.3 for ; Mon, 10 Jul 2017 14:29:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VosUmuNwR42yLHiO4yYaHW4t0/qw0s1lWz8vA+Jai3I=; b=n1B3pu9CFiDb2KTfGuV3+Fatv33hqvAUxI3fD7l2HDkhUs1ZQI1kIXxlZUkORod3d6 ZRMO1cIRwnZRfyGLC/6jkAL8VxySVgmLtSwKFkoiC5NvVdrFRSNMi8B9NdfuT8/RMP/J EMxNuTrW9WZUhcOGfm7QJuSW0RczxB/G88p7616rjTTUnCZTO+2wxAW0a75Mb8o5wu1G cULqh3vtgDkAXRUsFY8QcqXLbmadIjQxp0Zz6Aj5b1NNNqfpBCuEndreQY0XjbVUntvO wHu91ecppEeTSRg7otEzlu95mSCWTvF8K+4GL3TJ6J5+uuDS3gP3f18JyVAOcYZJibJr uL7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VosUmuNwR42yLHiO4yYaHW4t0/qw0s1lWz8vA+Jai3I=; b=tM/o5bymSHJs8+k9SgaHw2drXyQsXIWQT2I4SkxQfPpQ6IFkujWzC11iQZC3bWzsRO pu60VTkfyfA6vsf3vJkulG+JBnvJnbQ3l87mpmo4tGqyjeQHB2XNnT+eYKa6UZmCqOll qdLOawyeTn8tpB6qMSgFgvLRpsZQ19PSJpVvYtuNJ3Sj+S/nucFRSHwrOPeIrlrd9FlV 9h3xbOj4tZmH18K11+tI2nK/1etbG3FfT60aN7ZquD9dIfL6b5CFHbMEAbXQ7gRkc1sD UOoXjy9+4zdifD1EuG7U7kvKa+KwT2XmXNr2SY8hxxARopllPh1yi9K7z3nAU5L3FOQC etFQ== X-Gm-Message-State: AIVw11215Wy46clPeX+EX9ZI5oqzfHyRWYBEv5zc47k8rsTjr/jTM3Eh tlF2HjtJP60Qib4AX8oQqsH1lVpalmvI X-Received: by 10.200.53.151 with SMTP id k23mr6821922qtb.104.1499722173818; Mon, 10 Jul 2017 14:29:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.43.54 with HTTP; Mon, 10 Jul 2017 14:29:32 -0700 (PDT) In-Reply-To: References: From: Mary Barnes Date: Mon, 10 Jul 2017 16:29:32 -0500 Message-ID: To: Martin Thomson Cc: "acme@ietf.org" Content-Type: multipart/alternative; boundary="001a113eced46eaad60553fd47b6" Archived-At: Subject: Re: [Acme] Comments on draft-barnes-acme-service-provider X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 21:29:38 -0000 --001a113eced46eaad60553fd47b6 Content-Type: text/plain; charset="UTF-8" Hi Martin, Thanks for taking the time to review. We're actually working on a revision right now addressing your comments and agree totally with your point that more detail is definitely needed in this draft. Since we were still reviewing letter ballot comments on the document at the draft deadline, we decided to wait for the revision until we knew how those would be handled and whether we might need additional changes to accommodate any of those comments. But, we plan to submit once the draft submissions re-open. One important note is that this document is dealing only with challenges associated with the Service Provider Codes and related token. Jon has a separate draft outlining challenges for telephone numbers: https://tools.ietf.org/html/draft-ietf-acme-telephone-00 I do have a few inline comments below [MB]. Regards, Mary. On Sun, Jul 9, 2017 at 8:46 PM, Martin Thomson wrote: > I just realized that I misunderstood and there is a bearer token being > used to resolve the challenge and the service provider is responsible > for talking to the STI-PA to get this. I think that this needs to > have a bit more detail for it to be understood. > > On 10 July 2017 at 11:36, Martin Thomson wrote: > > This document is a key piece of the STIR/SHAKEN infrastructure, as > > such, I think that this is worth working on and a good basis for that. > > I have a few questions, some of which might touch on the > > stir-certificates draft (which I see is in the RFC editor's queue, > > hmm). > > > > STIR certificates define TNAuthList to be a list of service provider > > codes, number ranges and numbers. Is there any reason why this needs > > have more than one service provider code? > [MB] Right now, for SHAKEN we are just using one service provider code for a certificate. It's not clear if/when there would be a need for multiple, but for SHAKEN (as I think is the case for STIR), we didn't necessarily want to include that as a restriction. In the end, in practice, that may well be the way it works out. [/MB] > Indeed, is there any reason > > that service provider codes and telephone numbers need to be merged > > into a single type? > [MB] That's a good question for STIR WG, but again I think it was for flexibility, although I guess you could still define each separately and if you had a mix, then you have both. [/MB] Reading RFC 5280, subjectAltName can include > > multiple otherName values, each of which could be a > > serviceProviderCode or a telephone number set. I see several > > alternatives, for instance each otherName could be: > > > > 1. a mix of SPC and TN sets (today) > > 2. either a SPC or a TN set as two separate types > > 3. a single SPC with an associated TN set > > 4. a TN set with a optional SPC associated > > 5. a TN set with an optional SPC set > > > > It's not obvious, but I assume that there are cases where service > > providers end up with multiple service provider codes over time. If > > the numbers allocated to that provider get all mixed up so that there > > is no longer a clean mapping from a number to a service provider code, > > then option 1 (or 5) seem like the best choice. > [MB] So, I don't think we've explored all those combinations. Right now for SHAKEN obviously we are only using a single SPC. Obviously, SPs will have a way of associating TNs with an SPC, but at this point, there's no intent to use certificates or do validation per TN (or a set of). Jon talks a little bit about cases with both in section 4.1 of his draft. But, I don't think we have a definitive approach yet. [/MB] > > > > I ask because the encoding of TNAuthList into JSON isn't specified in > > the draft. It seems like the interactions here with the STI-PA are > > largely based on service provider code and the example is actually > > showing a service provider code (and not an E.164 range as might be > > inferred from the hypen). > [MB] The intent for this draft is to encode the TNAuthList as an array of strings to support multiple service provider codes. Now perhaps we should rename it from TNAuthList to SPAuthList since we don't intend for this challenge type to support TNs. [/MB] > > > > Is this the intended interaction model: > > > > a. the service provider sends its codes to the CA, > > b. the CA asks the STI-PA about the service provider codes, > > c. the STI-PA returns in the affirmative (possibly including > > associated telephone numbers), > > d. the CA authorizes the certificate issuance (possibly including the > > telephone numbers or using the telephone numbers to validate the > > subjectAltName proposed in the CSR). > > > > Or is the model intentionally flexible about what the service provider > > can request authorization for? Can the service provider request > > authorization for a telephone number range that is orthogonal to the > > codes that it might use? > > > > Having this explained in more details would help a lot. A ladder > > diagram for the interaction above might help too - existing ACME > > challenges mostly involve talking back to the ACME client, this goes > > to a third party. > [MB] I'll add a ladder diagram to the revision as I agree it would be helpful.[/MB] > > > > If there is some directed association between service provider codes > > and telephone numbers, then option 5 above might be a more natural fit > > for the certificate (or 4 if the TN-SPC mapping is forced to be > > many-to-one at the STI-PA). Otherwise, I'm not sure why the two types > > of data are intermixed. From the ACME perspective, I want to > > understand why there is a TNAuthList type rather than separate > > "service-provider-code" and "tn-set" identifiers. > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > --001a113eced46eaad60553fd47b6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Martin,

Thanks for taking t= he time to review.=C2=A0=C2=A0 We're actually working on a revision rig= ht now addressing your comments and agree totally with your point that more= detail is definitely needed in this draft.=C2=A0 Since we were still revie= wing letter ballot comments on the document at the draft deadline, we decid= ed to wait for the revision until we knew how those would be handled and wh= ether we might need additional changes to accommodate any of those comments= . But, we plan to submit once the draft submissions re-open.=C2=A0

=
One important note is that this document is dealing only with ch= allenges associated with the Service Provider Codes and related token.=C2= =A0 Jon has a separate draft outlining challenges for telephone numbers:=C2= =A0 ht= tps://tools.ietf.org/html/draft-ietf-acme-telephone-00 =C2=A0=C2=A0 =C2= =A0 I do have a few inline comments below [MB].=C2=A0

Regards,
Mary.

On Sun, Jul 9, 2017 at 8:46 PM, Martin Thomson <= martin.thomson@gmail.com> wrote:
I just realized that I misunderstood and there is = a bearer token being
used to resolve the challenge and the service provider is responsible
for talking to the STI-PA to get this.=C2=A0 I think that this needs to
have a bit more detail for it to be understood.

On 10 July 2017 at 11:36, Martin Thomson <martin.thomson@gmail.com> wrote:
> This document is a key piece of the STIR/SHAKEN infrastructure, as
> such, I think that this is worth working on and a good basis for that.=
> I have a few questions, some of which might touch on the
> stir-certificates draft (which I see is in the RFC editor's queue,=
> hmm).
>
> STIR certificates define TNAuthList to be a list of service provider > codes, number ranges and numbers.=C2=A0 Is there any reason why this n= eeds
> have more than one service provider code?=C2=A0
[MB] Right now, for SHAKEN we are just using one service provider co= de for a certificate.=C2=A0 It's not clear if/when there would
be a need for multiple, but for SHAKEN (as I think is the case for ST= IR), we didn't necessarily want to include that as a restriction.=C2=A0=
In the end, in practice, that may well be the way it works = out. [/MB]
Indeed, is there any reaso= n
> that service provider codes and telephone numbers need to be merged > into a single type?=C2=A0
[MB] That'= s a good question for STIR WG, but again I think it was for flexibility, al= though I guess you could still define each separately and if
= you had a mix, then you have both. [/MB]

Reading RFC 5280, subjectAltName can include
> multiple otherName values, each of which could be a
> serviceProviderCode or a telephone number set.=C2=A0 I see several
> alternatives, for instance each otherName could be:
>
> 1. a mix of SPC and TN sets (today)
> 2. either a SPC or a TN set as two separate types
> 3. a single SPC with an associated TN set
> 4. a TN set with a optional SPC associated
> 5. a TN set with an optional SPC set
>
> It's not obvious, but I assume that there are cases where service<= br> > providers end up with multiple service provider codes over time.=C2=A0= If
> the numbers allocated to that provider get all mixed up so that there<= br> > is no longer a clean mapping from a number to a service provider code,=
> then option 1 (or 5) seem like the best choice.
[MB] So, I don't think we've explored all those combinat= ions.=C2=A0 Right now for SHAKEN obviously we are only using a single SPC.= =C2=A0 Obviously, SPs will have a way of associating TNs with an SPC, but a= t this point, there's no intent to use certificates or do validation pe= r TN (or a set of).=C2=A0=C2=A0=C2=A0 Jon talks a little bit about cases wi= th both in section 4.1 of his draft.=C2=A0 But, I don't think we have a= definitive approach yet. [/MB]
>
> I ask because the encoding of TNAuthList into JSON isn't specified= in
> the draft.=C2=A0 It seems like the interactions here with the STI-PA a= re
> largely based on service provider code and the example is actually
> showing a service provider code (and not an E.164 range as might be > inferred from the hypen).
[MB] The in= tent for this draft is to encode the TNAuthList as an array of strings to s= upport multiple service provider codes.
Now perhaps we should rename it= from TNAuthList to SPAuthList since we don't intend for this challenge= type to support
TNs. [/MB]
>
> Is this the intended interaction model:
>
> a. the service provider sends its codes to the CA,
> b. the CA asks the STI-PA about the service provider codes,
> c. the STI-PA returns in the affirmative (possibly including
> associated telephone numbers),
> d. the CA authorizes the certificate issuance (possibly including the<= br> > telephone numbers or using the telephone numbers to validate the
> subjectAltName proposed in the CSR).
>
> Or is the model intentionally flexible about what the service provider=
> can request authorization for?=C2=A0 Can the service provider request<= br> > authorization for a telephone number range that is orthogonal to the > codes that it might use?
>
> Having this explained in more details would help a lot.=C2=A0 A ladder=
> diagram for the interaction above might help too - existing ACME
> challenges mostly involve talking back to the ACME client, this goes > to a third party.
[MB] I'll add a= ladder diagram to the revision as I agree it would be helpful.[/MB]
>
> If there is some directed association between service provider codes > and telephone numbers, then option 5 above might be a more natural fit=
> for the certificate (or 4 if the TN-SPC mapping is forced to be
> many-to-one at the STI-PA).=C2=A0 Otherwise, I'm not sure why the = two types
> of data are intermixed.=C2=A0 From the ACME perspective, I want to
> understand why there is a TNAuthList type rather than separate
> "service-provider-code" and "tn-set" identifiers.<= br>
_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

--001a113eced46eaad60553fd47b6-- From nobody Mon Jul 10 17:26:35 2017 Return-Path: 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 64A1F12F290 for ; Mon, 10 Jul 2017 17:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vI-LifYFYQYK for ; Mon, 10 Jul 2017 17:26:32 -0700 (PDT) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (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 3DD82127201 for ; Mon, 10 Jul 2017 17:26:32 -0700 (PDT) Received: by mail-lf0-x234.google.com with SMTP id b207so72928875lfg.2 for ; Mon, 10 Jul 2017 17:26:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=GNM9BflWbzqnYIbKBUCLYda6erYzaAguS7+VWI8FLR0=; b=nhlgwVNv8O5XVHzlp/CR9+uEGCm1xHAw55rZ79PN9BQlknUqrqg73BgZKpscXWyp1k 4nelMSTv/fvxkBo6nVdkdcyzecXfKSIMBT3wIZj2Jy2n5lAMptIVhz3pk1xBJVlNmpx7 7KvwEQgk7IL+iQKJfomsp/GNkUA0sf+604+X2oSnaGH4PSfrWirQMNllH9ta3ElJCAUa K5b4u70yBs/hWRHsdEfHfSqOLA5mSwL2miq+X0z4LZ7slX8rmIDKHWJ3qPPUgRdcimBZ RhjMQiz+JwVSr3rt/S3sHVSuUP9ZMF6cd/WJz/eGnHWKc00yNvGynKpR1twOgMYXQrpp jtOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=GNM9BflWbzqnYIbKBUCLYda6erYzaAguS7+VWI8FLR0=; b=puhTkT2YXEaUvM1MT2hTMg4x6uCJP/k3vlcf6q9rFf/kkRIX4nrA80Jts3NwwezGXW ySei432lZCmbIGK1s1J+8o5ZHYnWQjQ8ufJmg4YieK6Iw/Cf5Cm90ZWICCwZN14Gpmtp EMcXNTthSkNgKl0B9W0VskFnCIwimjL1W8Ybt3Z0B2+rMsRUTa5AUow28fBMdMYyY5Ww nPyUepdDuEmFYu3jJzlkylscU9nLKmznhw/gqt3l0xV4pbACR13iTUeJKFf/7bKeQPOk AxlFM5aom6SniwbHXmt6mxtKZzIqIdGuVpGXiTGJ/7AX4OR8izZokX5QibZ/mwMb7KXL vYmQ== X-Gm-Message-State: AIVw110wyugosnqFTHWTZbUVHW53qPV21ij9ydIFNZ2UsnCWJYyeok44 l3zXWHuEcPtHdBLMlfP402YZXsDe4A== X-Received: by 10.25.199.131 with SMTP id x125mr1789617lff.75.1499732790516; Mon, 10 Jul 2017 17:26:30 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.25.181.214 with HTTP; Mon, 10 Jul 2017 17:26:29 -0700 (PDT) In-Reply-To: References: <40e652477a2f47b0848330e64f72e8b2@usma1ex-dag1mb1.msg.corp.akamai.com> <177d761f214441a0b20bfc4ddc8dee9b@usma1ex-dag1mb1.msg.corp.akamai.com> <20170613173105.GB12048@LK-Perkele-V2.elisa-laajakaista.fi> <8baacb86ea9b455291fab177ce85b5ce@usma1ex-dag1mb1.msg.corp.akamai.com> <20170706100702.GA14472@andover.lhh.devever.net> From: Phillip Hallam-Baker Date: Mon, 10 Jul 2017 20:26:29 -0400 X-Google-Sender-Auth: r5NiwEQTD68aX5_e8MYtATXl8kI Message-ID: To: Martin Thomson Cc: Hugo Landau , Richard Barnes , "acme@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c19bb2e3ca4ca0553ffc024" Archived-At: Subject: Re: [Acme] Consensus -- CAA draft to WGLC? X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2017 00:26:34 -0000 --94eb2c19bb2e3ca4ca0553ffc024 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jul 6, 2017 at 6:16 AM, Martin Thomson wrote: > On 6 July 2017 at 20:07, Hugo Landau wrote: > > Vendor-assigned identifiers could be supported as such: > > vnd:example.com/custom-method > > RFC 6648 explains why vendor-prefixes can be a bad idea. I think that > you should do as Yaron suggested and establish a registry. Set the > bar low (specification required would be my choice) and then CABF can > make a new entry as they see fit. In particular, do away with > attaching some sort of semantic to prefixes. > > > 2. Adding a reference to CABF is weird > =E2=80=8BCAA already has a tag registry. The bar to entry is deliberately l= ow. If you really can't use the existing registry, use the existing one as a template. But the thing with DNS records is that you have a left hand side (domain name, record type) and a right hand side (record data) and the DNS protocol only allows you to select on the left hand side. If you do a CAA query, you are always going to get back the full set of records. =E2=80=8BSo you are always going to have to look at them all. CAA tags are text labels with a deliberately generous number of possibilities. We are not going to run out. Rather than create a subordinate registry, I would prefix within the label. --94eb2c19bb2e3ca4ca0553ffc024 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Thu, Ju= l 6, 2017 at 6:16 AM, Martin Thomson <martin.thomson@gmail.com&= gt; wrote:
On 6 J= uly 2017 at 20:07, Hugo Landau <h= landau@devever.net> wrote:
> Vendor-assigned identifiers could be supported as such:
>=C2=A0 =C2=A0vnd:example.com/custom-method

RFC 6648 explains why vendor-prefixes can be a bad idea.=C2=A0 I thi= nk that
you should do as Yaron suggested and establish a registry.=C2=A0 Set the bar low (specification required would be my choice) and then CABF can
make a new entry as they see fit.=C2=A0 In particular, do away with
attaching some sort of semantic to prefixes.

> 2. Adding a reference to CABF is weird
=E2=80=8BCAA = already has a tag registry. The bar to entry is deliberately low. If you re= ally can't use the existing registry, use the existing one as a templat= e.

But the thing with DNS= records is that you have a left hand side (domain name, record type) and a= right hand side (record data) and the DNS protocol only allows you to sele= ct on the left hand side.=C2=A0

If you do a CAA query, you are always going to get back the full set= of records. =E2=80=8BSo you are always going to have to look at them all.= =C2=A0

CAA tags are text = labels with a deliberately generous number of possibilities. We are not goi= ng to run out. Rather than create a subordinate registry, I would prefix wi= thin the label.
--94eb2c19bb2e3ca4ca0553ffc024-- From nobody Mon Jul 10 17:30:57 2017 Return-Path: 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 121BC12FB9A for ; Mon, 10 Jul 2017 17:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cix38swXdrSb for ; Mon, 10 Jul 2017 17:30:53 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::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 B0243127201 for ; Mon, 10 Jul 2017 17:30:52 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id b207so72962561lfg.2 for ; Mon, 10 Jul 2017 17:30:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=NUr/JsiuyLXUORZaVPnGNKMAYrzwv/f1b0Q3LYAZWwg=; b=ioBCSThumL/k5H5NTzawKjsA6mbrnG/BkrkT2/XXd3crqKciSkv+as1ge/gQmo9/y5 1xe3N4F2RDs/QhvRJGj+FpdUEhc7jKCabbmUjA4VXe+iUE/ynTlszwylSXi9NczLI4MB avfJOd9dqrb3/YProzSzS52DcidbjK3TNemobIzfQBk63Xkl2T8/QqbYRLAPc/SYmyFH xmC/wvmEMNUF39ue6iQx0uuPAsvY1mm17+e5WQqwrBjLuxxNl/JDvQO4r64LNrFujqpS q1/j88vibgmDYP3u1bFuNmOO49d7Q5gdOlClkicWECwpe2Q0w750Unvs5yB25oB7txvu qukg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=NUr/JsiuyLXUORZaVPnGNKMAYrzwv/f1b0Q3LYAZWwg=; b=HU7oUisL3kKF9YeK1D4cAv22ByqHORg8GOAKTJtnqu4HdtevRhU5efOEXR3X2YjaGX w2uytd4t+EmTI7Jme9SyLk027PWG7L/oebR5/wswNNs6+FFTqNMvTnF33P7A/C/qdcTy Cze5Oo40iSOY29Ux8pcburbzjwfM0lTOGL1FjXSk0/4tCZFkUYlL0qT9GZe/WQmK7yw1 xF+L754POkJasJ3t5l1BOJfJX+ZS1R2mJFKOafRVqNxqIgx7FZyKyfR5hz+P1n86Jn9i LJHUUF5G2TkyhmSSpqBxGsPA5VIlvm/fciYgN11m2rfU91EQIiK59THSWblKnTnR7g0R 0wsQ== X-Gm-Message-State: AIVw1121bp2OizGOcMAcqHpUa9Ex6xnF1ESk8f3engxAlU95SipcAA5h gVsybWhmm77nH5yXBx1kaFcnnWLviQ== X-Received: by 10.46.92.196 with SMTP id q187mr5107527ljb.132.1499733051066; Mon, 10 Jul 2017 17:30:51 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.25.181.214 with HTTP; Mon, 10 Jul 2017 17:30:50 -0700 (PDT) In-Reply-To: <20170708084427.GA18015@andover.lhh.devever.net> References: <8baacb86ea9b455291fab177ce85b5ce@usma1ex-dag1mb1.msg.corp.akamai.com> <20170706100702.GA14472@andover.lhh.devever.net> <20170707133313.GA15228@andover.lhh.devever.net> <94eda8437c13496c8a5c32a0d294bb8b@usma1ex-dag1mb1.msg.corp.akamai.com> <20170708084427.GA18015@andover.lhh.devever.net> From: Phillip Hallam-Baker Date: Mon, 10 Jul 2017 20:30:50 -0400 X-Google-Sender-Auth: e3C6a3nMhczIxG6XqAU_pqQANss Message-ID: To: Hugo Landau Cc: "Salz, Rich" , "acme@ietf.org" Content-Type: multipart/alternative; boundary="f40304366e82c450590553ffcf31" Archived-At: Subject: Re: [Acme] Consensus -- CAA draft to WGLC? X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2017 00:30:55 -0000 --f40304366e82c450590553ffcf31 Content-Type: text/plain; charset="UTF-8" x- prefixes were for experimental. They are bad because they inevitably fail. either the experiment fails and is forgotten or it succeeds and all the software has to check for both in perpetuity. Its just bad. Do not do. acme-foo acme-bar etc. Is a totally different proposition. That is a good thing provided that you don't go expecting the software to treat these as anything other than opaque labels. As it won't. On Sat, Jul 8, 2017 at 4:44 AM, Hugo Landau wrote: > > > https://github.com/ietf-wg-acme/acme/pull/332 > Alright, if the ACME spec wants to genericise its validation methods > registry, I'm okay with the validation-methods change as-is. > > Questions: > > 1. Should we drop "non-acme", since any non-ACME method can have its own > identifier listed? I think probably. > > 2. An ACME validation method, such as http-01, can only be used in the > context of using ACME. Conversely, should non-ACME validation methods > only be usable in non-ACME contexts? > > For example, suppose someone registered a "cabf-dv-http" validation > method generically referring to CABF-compliant HTTP-based DV. > If someone wants to use ACME, they can list http-01 specifically, > so I think ACME CAs should ignore method specifiers like this. > These method names would be applicable solely to non-ACME CAs. > > (This is sort of implied already by the subtext that an act of > validation has exactly one validation method name applicable to it, > but we could be clearer about this.) > > > With regard to ACME-CAA PR#2: Is a "vendor" validation method, rather > than a prefix, really that useful? > > RFC6648 deprecates prefixes like "x-", but thinks that vendor-specific > prefixes like domain names are still OK. So we could amend the ACME > specification allowing challenge method names of the form > "foo@example.com", say (this is inspired by SSH capability names). This > would have utility for vendors both in and outside of the context of > ACME-CAA. > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > --f40304366e82c450590553ffcf31 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
x- = prefixes were for experimental. They are bad because they inevitably fail. = either the experiment fails and is forgotten or it succeeds and all the sof= tware has to check for both in perpetuity. Its just bad. Do not do.

acme-foo
acme-bar
etc.

Is a totally different proposition. That is a good thing provi= ded that you don't go expecting the software to treat these as anything= other than opaque labels. As it won't.





On Sat, Jul 8, 2017 at 4:44 AM, Hugo Landau = <hlandau@deveve= r.net> wrote:
> > https://github.com/ietf-wg-acme/acme/pull/332
Alright, if the ACME spec wants to genericise its validation methods
registry, I'm okay with the validation-methods change as-is.

Questions:

1. Should we drop "non-acme", since any non-ACME method can have = its own
=C2=A0 =C2=A0identifier listed? I think probably.

2. An ACME validation method, such as http-01, can only be used in the
=C2=A0 =C2=A0context of using ACME. Conversely, should non-ACME validation = methods
=C2=A0 =C2=A0only be usable in non-ACME contexts?

=C2=A0 =C2=A0For example, suppose someone registered a "cabf-dv-http&q= uot; validation
=C2=A0 =C2=A0method generically referring to CABF-compliant HTTP-based DV.<= br> =C2=A0 =C2=A0If someone wants to use ACME, they can list http-01 specifical= ly,
=C2=A0 =C2=A0so I think ACME CAs should ignore method specifiers like this.=
=C2=A0 =C2=A0These method names would be applicable solely to non-ACME CAs.=

=C2=A0 =C2=A0(This is sort of implied already by the subtext that an act of=
=C2=A0 =C2=A0validation has exactly one validation method name applicable t= o it,
=C2=A0 =C2=A0but we could be clearer about this.)


With regard to ACME-CAA PR#2: Is a "vendor" validation method, ra= ther
than a prefix, really that useful?

RFC6648 deprecates prefixes like "x-", but thinks that vendor-spe= cific
prefixes like domain names are still OK. So we could amend the ACME
specification allowing challenge method names of the form
"foo@example.com", say (th= is is inspired by SSH capability names). This
would have utility for vendors both in and outside of the context of
ACME-CAA.

_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

--f40304366e82c450590553ffcf31-- From nobody Mon Jul 10 18:00:37 2017 Return-Path: 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 D5AEE127201 for ; Mon, 10 Jul 2017 18:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Klc4U4RFnWGM for ; Mon, 10 Jul 2017 18:00:33 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::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 C3FFA1241FC for ; Mon, 10 Jul 2017 18:00:33 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id m68so49848836ith.1 for ; Mon, 10 Jul 2017 18:00:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YfZ/c2ZFVsKbiky1lg9TAni14NhjITUMc7JRzEMzac4=; b=TDWZ6g+IwLxcTg8KDg4EngkjLa3JApa4NaVAx2neux02zw2kIW762dXGjsxw7ddTcz vx9lpSbgN+vaBSKnj23nfDPLJl4zhENjMQ4z8CV6Wegx183Vj/gSpwQuYSiVIs1QiP9X Gd4iZXkAmKehyC7IRbch6gsuP02BNYYbScIGjxEHwbG/3v9Z5XmR4m/WQzbxcAKyps+r RNYob2nYyM2zLCx7TOVr0r2bxip1o79i5s4rzFXpNgGKi1DtCF8JzJIiuUSQZU81KA/i 51P/7bP8xD+cNuGUqrbwHpAlTV3rsZd3zlv9sNd6MqfGto9cC7noEcs7dmU1EPHfMD2D ksjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YfZ/c2ZFVsKbiky1lg9TAni14NhjITUMc7JRzEMzac4=; b=Y83mgajvQ+3S6E0i3O8YBB+mYXhbtMfTiocJjxu5Rwz0O/j5HPOuOrGxKFq+KDd1Ah VC4rvCcg0C5fXQTmcyWzaXQbHFGRk6qm7p/N0SSjppMI99dNmOt0riVeNyYDL7UPynGH 94X5d70DpnfpuWgN/4IpIyFltJWWju9JNS0wDKzM2lkqigKEY/f1CHzXWUAbzC9wDo1a gp2sLpbIOxBf6EPDBK8CI7u9lhKAZnqjkgW9f5TPxAHe2asn6F9CeDhH/E1Z+qamD8vJ y0zcSORSTzJ0NPg3Zo/Jedx8+tJdLembdGzUBx8MF0um2B9Q3inLhGRE57geVEDsPCIC wIFw== X-Gm-Message-State: AIVw110kyhhdlVyWEEK1OorCw1GkVx3KCX5SC3W4rm0vjOzxwCMVj+kB 2EP00MI+5BBbjB3/A/EV8UmrVn4wlvX+ X-Received: by 10.107.182.132 with SMTP id g126mr6790065iof.216.1499734833039; Mon, 10 Jul 2017 18:00:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.26 with HTTP; Mon, 10 Jul 2017 18:00:32 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Tue, 11 Jul 2017 11:00:32 +1000 Message-ID: To: Mary Barnes Cc: "acme@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Acme] Comments on draft-barnes-acme-service-provider X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2017 01:00:36 -0000 On 11 July 2017 at 07:29, Mary Barnes wrote: > Hi Martin, > > Thanks for taking the time to review. We're actually working on a revision > right now addressing your comments and agree totally with your point that > more detail is definitely needed in this draft. Since we were still > reviewing letter ballot comments on the document at the draft deadline, we > decided to wait for the revision until we knew how those would be handled > and whether we might need additional changes to accommodate any of those > comments. But, we plan to submit once the draft submissions re-open. > > One important note is that this document is dealing only with challenges > associated with the Service Provider Codes and related token. Jon has a > separate draft outlining challenges for telephone numbers: > https://tools.ietf.org/html/draft-ietf-acme-telephone-00 I do have a > few inline comments below [MB]. I reviewed the number one also, but didn't have any concrete questions. I was going to provide comments on automating the process, but it's been one of those weeks. >> Indeed, is there any reason >> > that service provider codes and telephone numbers need to be merged >> > into a single type? > > [MB] That's a good question for STIR WG, but again I think it was for > flexibility, although I guess you could still define each separately and if > you had a mix, then you have both. [/MB] subjectAltName more or less relies on this. The only cost is inefficiency. You wouldn't want to have a SAN otherName for every telephone number, but I think that you could easily pay that cost for the service provider code. >> > 1. a mix of SPC and TN sets (today) >> > 2. either a SPC or a TN set as two separate types >> > 3. a single SPC with an associated TN set >> > 4. a TN set with a optional SPC associated >> > 5. a TN set with an optional SPC set > > [MB] So, I don't think we've explored all those combinations. Right now for > SHAKEN obviously we are only using a single SPC. Obviously, SPs will have a > way of associating TNs with an SPC, but at this point, there's no intent to > use certificates or do validation per TN (or a set of). Jon talks a > little bit about cases with both in section 4.1 of his draft. But, I don't > think we have a definitive approach yet. [/MB] I see that the IESG approved stir-certificates. I'm a little concerned that it's going to be published without ever having discussed this rather fundamental piece. I'll ping Jon and STIR (YAML, FML); maybe this was discussed and there is a good story. > [MB] The intent for this draft is to encode the TNAuthList as an array of > strings to support multiple service provider codes. > Now perhaps we should rename it from TNAuthList to SPAuthList since we don't > intend for this challenge type to support > TNs. [/MB] That's an improvement better. To be consistent with domain names, you probably want to include just a single service provider code. You can gain authorizations for multiple codes separately, and ACME supports that. From nobody Sun Jul 16 16:24:57 2017 Return-Path: X-Original-To: acme@ietf.org Delivered-To: acme@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C8C5C1200C1; Sun, 16 Jul 2017 16:24:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: acme@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.56.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150024748968.32685.14490661799494398616@ietfa.amsl.com> Date: Sun, 16 Jul 2017 16:24:49 -0700 Archived-At: Subject: [Acme] I-D Action: draft-ietf-acme-ip-00.txt X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 23:24:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Automated Certificate Management Environment of the IETF. Title : ACME IP Identifier Validation Extension Author : Roland Bracewell Shoemaker Filename : draft-ietf-acme-ip-00.txt Pages : 7 Date : 2017-07-16 Abstract: This document specifies identifiers and challenges required to enable the Automated Certificate Management Environment (ACME) to issue certificates for IP addresses. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-acme-ip/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-acme-ip-00 https://datatracker.ietf.org/doc/html/draft-ietf-acme-ip-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jul 16 16:29:25 2017 Return-Path: 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 9831B12426E for ; Sun, 16 Jul 2017 16:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=letsencrypt.org 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 Iov4dPqL9uiQ for ; Sun, 16 Jul 2017 16:29:22 -0700 (PDT) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (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 7BE571200C1 for ; Sun, 16 Jul 2017 16:29:22 -0700 (PDT) Received: by mail-pf0-x232.google.com with SMTP id q85so67936067pfq.1 for ; Sun, 16 Jul 2017 16:29:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=letsencrypt.org; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=QF9yD66WaqZNth1+C2DzuTjlvMQBBHLyGp8foIBe+xc=; b=MNuMBfZYwe3U9d0jA+MJhTyIrEsJs0+Wc9dfdNLAU8sPJ7Gc0lmFLWIWfxpnJv24vP 6DDn9N/XVW9sEMVrOfJ98mfyQRLEUNpTK8qEtyZc7XQnWmwKRGl0QiZDFiNVhLzUg92Q ABqpH/Tqg35jns3RMjAlTJA3v8S9jVlKmmrLM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=QF9yD66WaqZNth1+C2DzuTjlvMQBBHLyGp8foIBe+xc=; b=n0LL73ZFRxiHWQZ9NWPgRYlG/kjXfgyUPsibCtBBKHvMMz22ZKw9AYb/BX282+NJ87 wqS6Rq6i+svDb2NnJY/R+CNK2sQG4Qoql/+cdyiYNLK+PSR6a7vQ/INjC7td9+O10A5m kc9slI0zaG9W5kdvgPv/F11DUmJmYn5tPF2CKzF5BLEHWs/oVWnrRXxpPulFyGyCLV+H xhb1unUHEZF29bI6o+B9Ebxk/CSZfWKxSDJ+2osA1cW6w+94PuWYD8QftbBHs44YQDEn +zGCtG2b6V6OrJ0WhafAmHhAFxI69Z8z/98ZxIlPR+TMEpCnyichYhEOExr0C1BSKsCR WqPQ== X-Gm-Message-State: AIVw110M0Zf6n9fpOEaQ6cXIOVTSF8C3BF0TK2/GMgw1MZQbTB7FtepN HK+XONgpS0O2iGLkqLlhOQ== X-Received: by 10.101.70.70 with SMTP id k6mr25643405pgr.39.1500247761748; Sun, 16 Jul 2017 16:29:21 -0700 (PDT) Received: from [192.168.42.101] ([50.1.57.72]) by smtp.gmail.com with ESMTPSA id q81sm31514556pfj.85.2017.07.16.16.29.20 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 16 Jul 2017 16:29:21 -0700 (PDT) To: acme@ietf.org References: <150024748968.32685.14490661799494398616@ietfa.amsl.com> From: Roland Bracewell Shoemaker Message-ID: <20bfb08c-7f6c-0faf-b026-2cefa7f49b58@letsencrypt.org> Date: Sun, 16 Jul 2017 16:29:20 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <150024748968.32685.14490661799494398616@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Acme] I-D Action: draft-ietf-acme-ip-00.txt X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 23:29:25 -0000 There was some previous discussion about possibly using a slightly simpler DNS based verification method on the list last time I posted this as an individual submission. After reading through the CABF BRs for IP validation I'm pretty sure the proposed solution (checking for a TXT record in the reverse mapping zone) would not be considered BR compliant so I've stuck with the originally proposed challenge. On 07/16/2017 04:24 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Automated Certificate Management Environment of the IETF. > > Title : ACME IP Identifier Validation Extension > Author : Roland Bracewell Shoemaker > Filename : draft-ietf-acme-ip-00.txt > Pages : 7 > Date : 2017-07-16 > > Abstract: > This document specifies identifiers and challenges required to enable > the Automated Certificate Management Environment (ACME) to issue > certificates for IP addresses. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-acme-ip/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-acme-ip-00 > https://datatracker.ietf.org/doc/html/draft-ietf-acme-ip-00 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > From nobody Sun Jul 16 22:14:59 2017 Return-Path: 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 D9FCA1270B4 for ; Sun, 16 Jul 2017 22:14:57 -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, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 ugPHXE_nvV74 for ; Sun, 16 Jul 2017 22:14:55 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id B1B211252BA for ; Sun, 16 Jul 2017 22:14:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 33C753648A; Mon, 17 Jul 2017 08:14:54 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id hoHFcZGHvwfL; Mon, 17 Jul 2017 08:14:53 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id C3CDC283; Mon, 17 Jul 2017 08:14:51 +0300 (EEST) Date: Mon, 17 Jul 2017 08:14:51 +0300 From: Ilari Liusvaara To: Roland Bracewell Shoemaker Cc: acme@ietf.org Message-ID: <20170717051451.v6vvigheknyyx2nc@LK-Perkele-VII> References: <150024748968.32685.14490661799494398616@ietfa.amsl.com> <20bfb08c-7f6c-0faf-b026-2cefa7f49b58@letsencrypt.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20bfb08c-7f6c-0faf-b026-2cefa7f49b58@letsencrypt.org> User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [Acme] I-D Action: draft-ietf-acme-ip-00.txt X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 05:14:58 -0000 On Sun, Jul 16, 2017 at 04:29:20PM -0700, Roland Bracewell Shoemaker wrote: > There was some previous discussion about possibly using a slightly > simpler DNS based verification method on the list last time I posted > this as an individual submission. After reading through the CABF BRs for > IP validation I'm pretty sure the proposed solution (checking for a TXT > record in the reverse mapping zone) would not be considered BR compliant > so I've stuck with the originally proposed challenge. The relevant (proposed) text I could find says: "[...] in a TXT record for the IP Address." (This is from proposed "7 IP Address validation methods"[1]). The only way I can make sense for having DNS records for the IP address is the QNAME corresponding to the IP in reverse mapping. I don't see the "or prepend a underscore label" or similar language for the method, unlike the DNS domain validation, which has that sort of language. So I interpret that for IP address of 192.0.2.1, the QNAME has to be: "1.2.0.192.in-addr.arpa". I guess the person to ask would Jeremy Rowley (he posted the latest version of the text I could find to CABForum validation list). Also, the relevant section for TLS-SNI in the "7 methods" says: "[...] a Certificate on the IP Address [...]" Whatever that actually means (I can come up with at least two different interpretations, and both of these are probably wrong): - The certificate has to certify the IP address. - The connection has to ask for certificate on IP address, i.e., omit server_name. ... Both of these interpretations are technically problematic. And neither is compatible with what the I-D text says. [1] I presume CABForum wants to first get the "10 Domain Validation methods" through, and then work on getting the "7 IP Address Validation methods" passed. -Ilari From nobody Sun Jul 16 23:10:42 2017 Return-Path: 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 DDF5F12EC0D for ; Sun, 16 Jul 2017 23:10:40 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=letsencrypt.org 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 V-pfD1Rg46QX for ; Sun, 16 Jul 2017 23:10:38 -0700 (PDT) Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::235]) (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 99949129562 for ; Sun, 16 Jul 2017 23:10:38 -0700 (PDT) Received: by mail-pg0-x235.google.com with SMTP id 123so1203508pgj.1 for ; Sun, 16 Jul 2017 23:10:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=letsencrypt.org; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=XfJHFEhLC5bIQEL2n0FQJ5rP2M0O++nw+eBXXz8iakI=; b=MJFGB4s8qWOEndBksGoynAj2LJ+27D5yEFPlRn5dNeNrKFa6Q4UGbuw+n9O0C/tfhn iWOE5hyt08k4/3KpDwkUVtMj5kQvAphJknlFgfH8Ah+fokvG68H6q+v2kFEq9QqXESlh FXvulu8uPS7B3tmiv+CbJBOZdlqu4D5aqX0J4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=XfJHFEhLC5bIQEL2n0FQJ5rP2M0O++nw+eBXXz8iakI=; b=RdfhMD5BUIVwUxgeYRqkFcj1R5xIBmmeRvFjz/ruAVtfmTQP0qipW93Aql+Oe00IfO 3NFB2xJMXLLNcFxeADdMEvBARvA1zS3MqHfiGd1Xh4ZlwE7CNddDqjK5onkoIxmYpKSE Hg/Vva8bJL05vUudSqeb1WqsNJlx5JO/n/bt2lP0Id93OsQ4GQvbuS+aKONKYIUQ3y6E 04N6sizm17lSXM4/AAzfru3gIpXj4DhmnMIm8v2QOsjfklCSZR27Ac3vGPQ7Zqa1M8N3 DT2j8wN7ZBsCAbJHbvLInAxDGLUcx/zb47bBsfD0qeXUUV2dV8IH6lBTWrP2kOh3lyoT eZ9A== X-Gm-Message-State: AIVw110jiIpk3pi0Qht/NqlT/V355o5g8wquWM/pGXO4HL3gPQlaMiBG 84lTckt6trf1fH0+o4HOfw== X-Received: by 10.84.231.143 with SMTP id g15mr29215500plk.157.1500271837430; Sun, 16 Jul 2017 23:10:37 -0700 (PDT) Received: from [192.168.42.101] ([50.1.57.72]) by smtp.gmail.com with ESMTPSA id d74sm32676678pfb.31.2017.07.16.23.10.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 16 Jul 2017 23:10:36 -0700 (PDT) To: Ilari Liusvaara Cc: acme@ietf.org References: <150024748968.32685.14490661799494398616@ietfa.amsl.com> <20bfb08c-7f6c-0faf-b026-2cefa7f49b58@letsencrypt.org> <20170717051451.v6vvigheknyyx2nc@LK-Perkele-VII> From: Roland Bracewell Shoemaker Message-ID: <07cb017b-04bc-afa2-2536-9a49b6831bed@letsencrypt.org> Date: Sun, 16 Jul 2017 23:10:35 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170717051451.v6vvigheknyyx2nc@LK-Perkele-VII> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Acme] I-D Action: draft-ietf-acme-ip-00.txt X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 06:10:41 -0000 On 07/16/2017 10:14 PM, Ilari Liusvaara wrote: > On Sun, Jul 16, 2017 at 04:29:20PM -0700, Roland Bracewell Shoemaker wrote: >> There was some previous discussion about possibly using a slightly >> simpler DNS based verification method on the list last time I posted >> this as an individual submission. After reading through the CABF BRs for >> IP validation I'm pretty sure the proposed solution (checking for a TXT >> record in the reverse mapping zone) would not be considered BR compliant >> so I've stuck with the originally proposed challenge. > > The relevant (proposed) text I could find says: > > "[...] in a TXT record for the IP Address." > > (This is from proposed "7 IP Address validation methods"[1]). > > The only way I can make sense for having DNS records for the IP address > is the QNAME corresponding to the IP in reverse mapping. I don't see > the "or prepend a underscore label" or similar language for the method, > unlike the DNS domain validation, which has that sort of language. > > So I interpret that for IP address of 192.0.2.1, the QNAME has to be: > "1.2.0.192.in-addr.arpa". > > I guess the person to ask would Jeremy Rowley (he posted the latest > version of the text I could find to CABForum validation list). > Could you clarify which proposed ballot or mailing list message you are referencing. As far as I am aware the most recent CABF validation WG product that discusses IP validation is from March and doesn't include any reference to using TXT records (https://cabforum.org/pipermail/public/2017-March/010214.html). The most recent proposed language clarifies that any method which looks up a DNS name for an IP using the reverse mapping then applies a 3.2.2.4 method is considered acceptable. > > Also, the relevant section for TLS-SNI in the "7 methods" says: > > "[...] a Certificate on the IP Address [...]" > > Whatever that actually means (I can come up with at least two different > interpretations, and both of these are probably wrong): > > - The certificate has to certify the IP address. > - The connection has to ask for certificate on IP address, i.e., omit > server_name. > > ... Both of these interpretations are technically problematic. And > neither is compatible with what the I-D text says. > My understanding of this, admittedly confusing, language simply means the certificate presented by whatever server is running on the IP, not that the cert needs to be for the IP or served blindly. This language is in fact basically a copy/paste of the 3.2.2.4.10 language, for which tls-sni-02 was designed to be compatible with, that is used for DNS names where "Authorization Domain Name" has been replaced with "IP Address". > > > [1] I presume CABForum wants to first get the "10 Domain Validation > methods" through, and then work on getting the "7 IP Address Validation > methods" passed. > > > -Ilari > From nobody Mon Jul 17 00:39:27 2017 Return-Path: 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 78846131A63 for ; Mon, 17 Jul 2017 00:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 7FMMZv-1Fe98 for ; Mon, 17 Jul 2017 00:39:23 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 23676131A85 for ; Mon, 17 Jul 2017 00:39:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 0604136192; Mon, 17 Jul 2017 10:39:13 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id Ms8NO9dWxoip; Mon, 17 Jul 2017 10:39:12 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id B2ACE21C; Mon, 17 Jul 2017 10:39:10 +0300 (EEST) Date: Mon, 17 Jul 2017 10:39:10 +0300 From: Ilari Liusvaara To: Roland Bracewell Shoemaker Cc: acme@ietf.org Message-ID: <20170717073910.boyia5lxwdzsl56v@LK-Perkele-VII> References: <150024748968.32685.14490661799494398616@ietfa.amsl.com> <20bfb08c-7f6c-0faf-b026-2cefa7f49b58@letsencrypt.org> <20170717051451.v6vvigheknyyx2nc@LK-Perkele-VII> <07cb017b-04bc-afa2-2536-9a49b6831bed@letsencrypt.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <07cb017b-04bc-afa2-2536-9a49b6831bed@letsencrypt.org> User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [Acme] I-D Action: draft-ietf-acme-ip-00.txt X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 07:39:25 -0000 On Sun, Jul 16, 2017 at 11:10:35PM -0700, Roland Bracewell Shoemaker wrote: > On 07/16/2017 10:14 PM, Ilari Liusvaara wrote: > > On Sun, Jul 16, 2017 at 04:29:20PM -0700, Roland Bracewell Shoemaker wrote: > > The most recent proposed language clarifies that any method which looks > up a DNS name for an IP using the reverse mapping then applies a 3.2.2.4 > method is considered acceptable. Oh, indeed the draft does it that way. Also, multiple mailing lists and unlabeled versions makes following what is the most recent quite confusing... Missed the later version that dropped most of the methods. > > Also, the relevant section for TLS-SNI in the "7 methods" says: > > > > "[...] a Certificate on the IP Address [...]" > > > > Whatever that actually means (I can come up with at least two different > > interpretations, and both of these are probably wrong): > > > > - The certificate has to certify the IP address. > > - The connection has to ask for certificate on IP address, i.e., omit > > server_name. > > > > ... Both of these interpretations are technically problematic. And > > neither is compatible with what the I-D text says. > > > > My understanding of this, admittedly confusing, language simply means > the certificate presented by whatever server is running on the IP, not > that the cert needs to be for the IP or served blindly. > > This language is in fact basically a copy/paste of the 3.2.2.4.10 > language, for which tls-sni-02 was designed to be compatible with, that > is used for DNS names where "Authorization Domain Name" has been > replaced with "IP Address". I searched the archives of Validation WG. The initial drafts of what became ballot 169 contained a method based on text by J.C. Jones. This text covers TLS-SNI (even if I consider the method bit dubious). However, that definition got changed before the text became ballot, specifically adding the "on the Authorization Domain Name" part. I can not locate proper discussion of this change. Some text impiles it was from F2F meeting, but minutes of that meeting don't seem to discuss the matter. Apparenty third interpretation of that is: Look up the IP address and send some crap there. However, this interpretation seems to cause trouble with method 6 (HTTP), which has the same language, with quite clear implications. Yeah, this is messy. (And this confusing text is not the only problem with method 10, e.g., the method doesn't have the needed protections around use of random values, seemingly allowing blatantly insecure validation... This isn't fixed even in draft for ballot 190). -Ilari From nobody Mon Jul 17 04:01:42 2017 Return-Path: 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 72BC1131B25 for ; Mon, 17 Jul 2017 04:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Q06rBZ9zgmE for ; Mon, 17 Jul 2017 04:01:36 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (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 54373131B24 for ; Mon, 17 Jul 2017 04:01:36 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id b134so43917962wma.0 for ; Mon, 17 Jul 2017 04:01:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:to; bh=vnj4JLE+ijdP87x8bGDPeZVmpeZVzReQLLQ0641Gfgk=; b=g2PmDFKaWqAlUW4m1VhI0yopm2gGDxmvLFnWvM0islHEnCr4WRiQeAZWKTPHYe3kjU +LBSiM91y/Dm0WBkPnSTScSUGW5HehSDpggWoTLKGc2PeWpD7HHep2vbYzwbYVQkRkR7 L/SswuOlFA19lVY2yOvq6XT8wZZXcGx9M2s87mfQaWp8Tui+OuBXYPABmyinbKh6KYDU 7qRWwJxJahKsN0bw4l/pqZ8WFmyg/LZ5gds+6t9aXavyBo3Ornn+og+Ce1r7vfQgc20C t5HNhvPPHZR7sZkTSHEplAM132RTqZ2E/OCHq/FKOBeFZJpCXzCRkuN7sXX76g/hcneb RoNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=vnj4JLE+ijdP87x8bGDPeZVmpeZVzReQLLQ0641Gfgk=; b=pk2TUe47dxkxItLtx0htskm9I5Btg2iVwhjR6/uYlyJk63C0ssnMp8Zt6Lzfm0YjbG gVrc/RBMdYh3HTWhdsBTbldtRxHrnwPn5tzxWkFaiJsTN5nOMvwG4YlwwzYbguVlnZ+D nw0zFWCv4gtVd/sTbRxB4YBmQR7m46v46/m6We01cDzm2uV4zehbaFh0lRSm6kWkfVr4 NCm+S11D0rz+XSRA7IhVlpq2oOg3yRMlWi2KsC8Vak9WAkrxGsXPXJVwSYz4oUGyAnTb TSsr7O81lESNrq6SPPAIXD1aSbtwYJgTutKsn8RioB1xdSUa2fVU6yYdEHeBGFBC2OxC l1lg== X-Gm-Message-State: AIVw112DVLyMqzR/mEsakDSyKE40xgpwbRue/onCBBJ8VZB5zQrQ4vqM z9PRgOwz4MY3LHUe7Tg= X-Received: by 10.28.213.75 with SMTP id m72mr4146582wmg.41.1500289294659; Mon, 17 Jul 2017 04:01:34 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:35e6:37fc:76cb:c554? ([2001:67c:370:128:35e6:37fc:76cb:c554]) by smtp.gmail.com with ESMTPSA id p23sm1620354wrc.35.2017.07.17.04.01.33 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Jul 2017 04:01:34 -0700 (PDT) From: Yoav Nir Content-Type: multipart/signed; boundary="Apple-Mail=_08833E9B-740F-40F3-9C72-70280DA43309"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <6FA304D0-F7B3-4D15-9652-89A23DA894EC@gmail.com> Date: Mon, 17 Jul 2017 13:01:31 +0200 To: ACME WG X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [Acme] Friday's meeting X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 11:01:39 -0000 --Apple-Mail=_08833E9B-740F-40F3-9C72-70280DA43309 Content-Type: multipart/alternative; boundary="Apple-Mail=_78BB17B8-1EC0-48EE-9079-B6EA375F08B5" --Apple-Mail=_78BB17B8-1EC0-48EE-9079-B6EA375F08B5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, folks. As a reminder, the ACME working group will meet on Friday at 9:30 AM in = the Athens/Barcelona room on the main lobby level. The Agenda is already up: = https://www.ietf.org/proceedings/99/agenda/agenda-99-acme-00.txt = We need a Jabber scribe and a note taker. Please volunteer. People making presentations (that=E2=80=99s you! right there on the = agenda) please send us your slides in whatever format you want (I can = handle .pdf, .ppt, .pptx, .odp, .key) as long as the slides have = numbers. See you all this Friday. Ted, Rich, and Yoav --Apple-Mail=_78BB17B8-1EC0-48EE-9079-B6EA375F08B5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, folks.

As a reminder, the ACME working group will meet on Friday at = 9:30 AM in the Athens/Barcelona room on the main lobby level.

The Agenda is already = up: https://www.ietf.org/proceedings/99/agenda/agenda-99-acme-00.tx= t

We need = a Jabber scribe and a note taker.  Please volunteer.

People making = presentations (that=E2=80=99s you! right there on the agenda) please = send us your slides in whatever format you want (I can handle .pdf, = .ppt, .pptx, .odp, .key) as long as the slides have numbers.

See you all this = Friday.

Ted, = Rich, and Yoav

= --Apple-Mail=_78BB17B8-1EC0-48EE-9079-B6EA375F08B5-- --Apple-Mail=_08833E9B-740F-40F3-9C72-70280DA43309 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJZbJkMAAoJELhJCxUKWMyZtQIIAMwUUbHNubuSpCErJwitC0xG 7RpWKYlFz2iXYvjEhQVt7pxiJX6vEr6F+0MIW2xfKpCqakm6Zn9MFXmmWB/3r+Ul rvhPhAoxqP1zNb3cBC3HMf5a9KtY0X2qP1/TdY4G2VdQI12zPPctEq1QNOptHkA2 xtqJGofSnEIU4XsalMoXJZ2s72c4YkAXIfZGb3ork7Pqrrfkc4nI8K+FaZKitB62 koJJkz4288psmAbdHNMLCnqkLH3AbARBGKFXAwugyQZRz34ImvlMa/b6ZbQOmQou jVvXNVT2Nh5FpEFIIWmV7b6hHJQUeHRh0O+lbT8jJMjh8Ox1/KrwUP/Gxa2sSMg= =jaks -----END PGP SIGNATURE----- --Apple-Mail=_08833E9B-740F-40F3-9C72-70280DA43309-- From nobody Mon Jul 17 04:49:19 2017 Return-Path: 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 7641C13188F for ; Mon, 17 Jul 2017 04:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wqTnT71ynC3A for ; Mon, 17 Jul 2017 04:49:17 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BC7E1287A5 for ; Mon, 17 Jul 2017 04:49:17 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v6HBlJng001423; Mon, 17 Jul 2017 12:49:17 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=Kp8hSUAMI5briozovLoKrldM9yquxPRM5NXvL2jvT84=; b=e4LuYRjOINUPXQjmmKAU2SW1zwoq+pmKEnO1fPAoKtS0gCH4YUeoubALwECNqrpC1aYg dnXsxKxz0HVRXiZbEB6XR2EQ/mPUK44Z0GdAVDOOG/6YaBu6G/mCTnfqkkMmqtmXt0XX xJHpCwyKAR+rTYukzpouSMiNzKkMgD5UnARmgvAGxWzv/3Oq4hYV7JauWo7khcig+UFV vok5sD4b0L28dR8ngy5a9gSS2JmjJDZ3zvhCRMmmlmvHpbirakOh9RE+Llp7PLWcjlmh qDn22aa4lPymTBo53L800kHzvzUA/Su7mL+6rGxtX3Z4WTeuShmVvl2FwsqlcaZ1ZTwv EQ== Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050095.ppops.net-00190b01. with ESMTP id 2bqak4qn4w-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 17 Jul 2017 12:49:16 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v6HBk4HX008783; Mon, 17 Jul 2017 07:49:16 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint3.akamai.com with ESMTP id 2bqecvdh1r-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 17 Jul 2017 07:49:15 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 17 Jul 2017 07:49:14 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Mon, 17 Jul 2017 07:49:13 -0400 From: "Salz, Rich" To: Yoav Nir , ACME WG Thread-Topic: [Acme] Friday's meeting Thread-Index: AQHS/uwYkbkahMe4ZUWb2eUTqpIrdKJX539w Date: Mon, 17 Jul 2017 11:49:13 +0000 Message-ID: References: <6FA304D0-F7B3-4D15-9652-89A23DA894EC@gmail.com> In-Reply-To: <6FA304D0-F7B3-4D15-9652-89A23DA894EC@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.153.37] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-17_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707170186 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-17_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707170187 Archived-At: Subject: Re: [Acme] Friday's meeting X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 11:49:18 -0000 PiBXZSBuZWVkIGEgSmFiYmVyIHNjcmliZSBhbmQgYSBub3RlIHRha2VyLiDCoFBsZWFzZSB2b2x1 bnRlZXIuDQoNClRoZXJlIHdpbGwgYmUgZ2lmdHMuDQo= From nobody Mon Jul 17 17:03:17 2017 Return-Path: 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 2AD58129ACD for ; Mon, 17 Jul 2017 17:03:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.002 X-Spam-Level: X-Spam-Status: No, score=-7.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org 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 TAdnxKaeJ2kE for ; Mon, 17 Jul 2017 17:03:12 -0700 (PDT) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9334E12441E for ; Mon, 17 Jul 2017 17:03:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=nl3YfrJjgVfhU1/8eaVk5NdPewhujqbhESTpr6ZQXiI=; b=qHiDEhlDqR15wTqVWfeCUFL2ixF/S/6hGiCpKEzi0OWWYX/F2KQ9KMdB028Y4b/4HNL0k74R/BQjO8XnadyT65nDOI0PX3Esat+87wNQbRRF/eyslpJ+WM/30X+6klzExmO7PhftrfnwK1SBsUZAVyLnTVUrlW7fLzSTguS6+SI=; Received: ; Mon, 17 Jul 2017 17:03:10 -0700 To: Roland Bracewell Shoemaker , acme@ietf.org References: <150024748968.32685.14490661799494398616@ietfa.amsl.com> <20bfb08c-7f6c-0faf-b026-2cefa7f49b58@letsencrypt.org> From: Jacob Hoffman-Andrews Message-ID: <3ab6eecc-9790-ced0-39d8-d15a6bf87c93@eff.org> Date: Mon, 17 Jul 2017 17:03:12 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <20bfb08c-7f6c-0faf-b026-2cefa7f49b58@letsencrypt.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Received-SPF: skipped for local relay Archived-At: Subject: Re: [Acme] I-D Action: draft-ietf-acme-ip-00.txt X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 00:03:15 -0000 This looks good! Nice work. On 07/16/2017 04:29 PM, Roland Bracewell Shoemaker wrote: > There was some previous discussion about possibly using a slightly > simpler DNS based verification method on the list last time I posted > this as an individual submission. After reading through the CABF BRs for > IP validation I'm pretty sure the proposed solution (checking for a TXT > record in the reverse mapping zone) would not be considered BR compliant > so I've stuck with the originally proposed challenge. > > On 07/16/2017 04:24 PM, internet-drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Automated Certificate Management Environment of the IETF. >> >> Title : ACME IP Identifier Validation Extension >> Author : Roland Bracewell Shoemaker >> Filename : draft-ietf-acme-ip-00.txt >> Pages : 7 >> Date : 2017-07-16 >> >> Abstract: >> This document specifies identifiers and challenges required to enable >> the Automated Certificate Management Environment (ACME) to issue >> certificates for IP addresses. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-acme-ip/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-acme-ip-00 >> https://datatracker.ietf.org/doc/html/draft-ietf-acme-ip-00 >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> 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 > From nobody Mon Jul 17 22:49:02 2017 Return-Path: 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 C06C6126B72 for ; Mon, 17 Jul 2017 22:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K_aYJ2-4PtAw for ; Mon, 17 Jul 2017 22:48:59 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (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 08C9A12706D for ; Mon, 17 Jul 2017 22:48:59 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id a62so15101825itd.1 for ; Mon, 17 Jul 2017 22:48:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sGhioiDjoD6V7AUU0pPBnPha4eUH8Xdfx3hamH1PK5s=; b=f6B4Z7YjXKoNEUPusWpvENdJHENp0QwHwqYNiacRiCBQbK499WIrwU3+zU5LDOJ+9m npo92BhO79BQ3LnotZqrE92DBdEEuxvYrMOdFB/usW5aToL8yli6yD9gjHq2DOc+wTTG Giy7b1ZsxEGyhK3FC5hzWgc+n4QpVaRANysJUxoC7FYkTLBq1kt6btoBSyVFP3sx5CrS y1eOs2ODydubqQs3zvx3L5iQ3nwcvbDKu5HA0cx5Ef8VgC4G8/JG4LYjSZkGKQOQDGeN 4iAkkCG/8J34F3XjpAjFz9RilKrTh6foMePgreNn+W3IjOh5t4B4mjfzX2NGYUsRLQ0w lipw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sGhioiDjoD6V7AUU0pPBnPha4eUH8Xdfx3hamH1PK5s=; b=Kl89V8x1D3kLn5FlfqBA6K/xNjP8RqZfKzFS8TnElWiqFAzR55xX5Dpz7Sse+WTdHS ulCb/PQne3MiIkibU0lcSnqOaCVRnlwgEv2RVIUlRzhYxtcP5Wha3AtiWJAVfsf6JAIm H9G4FlSpwLj8t8L+9BfAtAslzj2xnwQmHN2UcQTCN7ylu97M/9pXNP+7l3712cgbUv7x D7uo+VqGNyXpVUJQDQfhsnC0i13PscSZ4zYvf68OAV4aetmLYagZIWkktk2yBTTkU2Vd qsCTy3L55ZhPkriEPCs78bjIBbTc37bRIPkiaj8Eq0InNqkOFhBD/vdt7HkuXrI44Bjc Awgw== X-Gm-Message-State: AIVw1116nQBO7hLWPsUu8wUbcifq0DtIK2fx9WcOBr4rocrslAcCOFle zWX1AeUqK4ZNm25GMDpjSQ4oc2XxfQ== X-Received: by 10.36.104.83 with SMTP id v80mr367469itb.97.1500356938212; Mon, 17 Jul 2017 22:48:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.26 with HTTP; Mon, 17 Jul 2017 22:48:57 -0700 (PDT) In-Reply-To: <3ab6eecc-9790-ced0-39d8-d15a6bf87c93@eff.org> References: <150024748968.32685.14490661799494398616@ietfa.amsl.com> <20bfb08c-7f6c-0faf-b026-2cefa7f49b58@letsencrypt.org> <3ab6eecc-9790-ced0-39d8-d15a6bf87c93@eff.org> From: Martin Thomson Date: Tue, 18 Jul 2017 07:48:57 +0200 Message-ID: To: Jacob Hoffman-Andrews Cc: Roland Bracewell Shoemaker , "acme@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Acme] I-D Action: draft-ietf-acme-ip-00.txt X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 05:49:01 -0000 The biggest concern I have is the text regarding certificate lifetime and the handling of the possibility that IP addresses are dynamically allocated. This seems a little weak and it leaves a lot to the CA to manage. Is there anything that can be done to gain a stronger assertion that the allocation is (more) persistent? An affirmation from someone higher in the tree perhaps? Some nits: You definitely want to reference RFC 5952 here when it comes to IPv6 addresses. Break the long line with the ip6.arpa example. I would also recommend a shorter label, maybe _acme-ip. You don't want a very long name in case the base name is long (which is relatively commonplace). On 18 July 2017 at 02:03, Jacob Hoffman-Andrews wrote: > This looks good! Nice work. > > On 07/16/2017 04:29 PM, Roland Bracewell Shoemaker wrote: >> There was some previous discussion about possibly using a slightly >> simpler DNS based verification method on the list last time I posted >> this as an individual submission. After reading through the CABF BRs for >> IP validation I'm pretty sure the proposed solution (checking for a TXT >> record in the reverse mapping zone) would not be considered BR compliant >> so I've stuck with the originally proposed challenge. >> >> On 07/16/2017 04:24 PM, internet-drafts@ietf.org wrote: >>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>> This draft is a work item of the Automated Certificate Management Environment of the IETF. >>> >>> Title : ACME IP Identifier Validation Extension >>> Author : Roland Bracewell Shoemaker >>> Filename : draft-ietf-acme-ip-00.txt >>> Pages : 7 >>> Date : 2017-07-16 >>> >>> Abstract: >>> This document specifies identifiers and challenges required to enable >>> the Automated Certificate Management Environment (ACME) to issue >>> certificates for IP addresses. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-acme-ip/ >>> >>> There are also htmlized versions available at: >>> https://tools.ietf.org/html/draft-ietf-acme-ip-00 >>> https://datatracker.ietf.org/doc/html/draft-ietf-acme-ip-00 >>> >>> >>> Please note that it may take a couple of minutes from the time of submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> 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 mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme From nobody Tue Jul 18 00:59:20 2017 Return-Path: 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 E7512131A4F for ; Tue, 18 Jul 2017 00:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XGRTHhG5u7dj for ; Tue, 18 Jul 2017 00:59:13 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79AF412ECF0 for ; Tue, 18 Jul 2017 00:59:13 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v6I7vOxv014293; Tue, 18 Jul 2017 08:59:09 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=P/SJowye3DiI1LukXv5BoNSOB/q67gO/Qu5qF5zxhNY=; b=UkgZW4gXLyx9iWKBrWnXOSB3rk3SH52zReFv5HRcsNxzFaj2WWA+L/hno3nzFL6sUEi0 u47s6zLmgH8B21jb5ymx8R3kfiOktkWS6PfLps/hoNrPFKM/uMIrggkEqspEHFOAusav nnR/uqjtG+dgXPHan7V2kluBJ5DaBuM42WsOzZMlaSaw/zddDEFgDeooAzKgDU0I/t/I REDGrkAidfdLbZem2X6yKQJdkgb4UlIKxOyfr/u0Zq7vbyLmeeKQrlv4o2v+LR2fWgUQ YypBmi0j4R3bXt9zgBn5wuSVNVACOjjQ2LNUb9d8YYh8wayZZwKfzMcG0QmmxOoko8jf oQ== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2bqbf9b3y8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 18 Jul 2017 08:59:09 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v6I7u2Ka012245; Tue, 18 Jul 2017 03:59:08 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint2.akamai.com with ESMTP id 2bqecuqb0y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 18 Jul 2017 03:59:08 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 18 Jul 2017 03:59:07 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Tue, 18 Jul 2017 03:59:07 -0400 From: "Salz, Rich" To: Martin Thomson , Jacob Hoffman-Andrews CC: "acme@ietf.org" , Roland Bracewell Shoemaker Thread-Topic: [Acme] I-D Action: draft-ietf-acme-ip-00.txt Thread-Index: AQHS/orF14OYhqIhKkGqcyIssGwrhqJXXKsAgAGbywCAAGCagP//4IrA Date: Tue, 18 Jul 2017 07:59:07 +0000 Message-ID: <5aea6fbf86f84861a7a687ee9a68bc15@usma1ex-dag1mb1.msg.corp.akamai.com> References: <150024748968.32685.14490661799494398616@ietfa.amsl.com> <20bfb08c-7f6c-0faf-b026-2cefa7f49b58@letsencrypt.org> <3ab6eecc-9790-ced0-39d8-d15a6bf87c93@eff.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.152.228] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-18_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707180130 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-18_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707180131 Archived-At: Subject: Re: [Acme] I-D Action: draft-ietf-acme-ip-00.txt X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 07:59:15 -0000 > The biggest concern I have is the text regarding certificate lifetime and= the > handling of the possibility that IP addresses are dynamically allocated. = This > seems a little weak and it leaves a lot to the CA to manage. Is there an= ything > that can be done to gain a stronger assertion that the allocation is (mor= e) > persistent? An affirmation from someone higher in the tree perhaps? That's interesting. Who is "higher" in the tree? IP space isn't hierarchical like DNS is it? From nobody Tue Jul 18 05:23:30 2017 Return-Path: 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 03B5B126B6D for ; Tue, 18 Jul 2017 05:23:29 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id riV0Vs5eE7Z4 for ; Tue, 18 Jul 2017 05:23:25 -0700 (PDT) Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::236]) (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 2CF32131B3A for ; Tue, 18 Jul 2017 05:23:25 -0700 (PDT) Received: by mail-wr0-x236.google.com with SMTP id a10so27215973wrd.0 for ; Tue, 18 Jul 2017 05:23:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=p8/XxoIl89xnkIXdSjJ5H/apmCf/FqgEbuDzikHzNHQ=; b=Zr+2/PLQZAeHK5bmQoztkP9n9f2R9RaA/xo0Hhp+DZD9Ny6chtZnpOQqNbt6Uu73mq 0OO+Dj3ynf69NU4+SlEbGz4W3yXfE4ogTm0MmcjsIVpliYbCVHPfgslXaTN/X+AnWGDP XWGVOzaCdVHUdFEfqUU5iOvjenzysyk9RRjn7AeLM0/1qbsCdT7zLGyI5eIQRppLYVjb BknwmcmS9SHbbxh35Cy1+m2xweIDMbbnr9mkuxVzpcdHOQd3sf1CXsR9PiKOJcg+Uked F587bxPDahajcoWfpwkNMJU1AZ5wA5Q+GHT7Zfh7QnXjLj2Ui5nSHH/fS2c12e4tZGzO m7QQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=p8/XxoIl89xnkIXdSjJ5H/apmCf/FqgEbuDzikHzNHQ=; b=CNqi9gS+y2+TB6c3vVtVyWmtZRwd9FtmPNleus3wxUoXmkj6lWtOAJ6IA9BLTLmv8T 5u+UUALsBlSnOGdZh8wkgCJ/WyNRRIk3O3KTWjn44d+TmbJxws9q/Y/JDnq35fgfzUnM D6zgWYsBwhwNCL+rXABAnSFMC8jNx5nW/xxXhzvVAl4ZZlKGy28/QXuQa/oOPshs5XLz QhB1czO73mV/9jpFFr2rhcChMOdiM1lzVdfMqKqGPibsAyv4o6BM0xhTjrT2DrHO8N6B u+qZnL5DdOcdCzAPaTUi8kWyheom7BIiMR1mp9+S+0MfpB9Ery0GTXPDNoa/GpIqisX9 E5aQ== X-Gm-Message-State: AIVw113y8A4ovGcbw/IymMGoyD6RWrj5LbWHQzdIZivmlA5hheZeK5CU RXe9xLhL/i6driC1nBA= X-Received: by 10.28.145.12 with SMTP id t12mr1987706wmd.107.1500380603547; Tue, 18 Jul 2017 05:23:23 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:cdff:5c1a:87f0:2e96? ([2001:67c:370:128:cdff:5c1a:87f0:2e96]) by smtp.gmail.com with ESMTPSA id i67sm1343053wri.61.2017.07.18.05.23.22 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Jul 2017 05:23:22 -0700 (PDT) From: Yoav Nir Content-Type: multipart/signed; boundary="Apple-Mail=_FB5E5F7F-82DF-44ED-B12D-9A93CB017F75"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 18 Jul 2017 14:23:21 +0200 References: <6FA304D0-F7B3-4D15-9652-89A23DA894EC@gmail.com> To: ACME WG In-Reply-To: <6FA304D0-F7B3-4D15-9652-89A23DA894EC@gmail.com> Message-Id: <7FBAF6A4-3C5F-4CE7-852A-E08B96F2F7AA@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Acme] Friday's meeting X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 12:23:29 -0000 --Apple-Mail=_FB5E5F7F-82DF-44ED-B12D-9A93CB017F75 Content-Type: multipart/alternative; boundary="Apple-Mail=_62819E18-42E3-4D14-93BF-F2A6AB254180" --Apple-Mail=_62819E18-42E3-4D14-93BF-F2A6AB254180 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi again. We have a jabber scribe. Still need a minutes taker. Praise will be = heaped. Gifts will be bestowed. Some presentations are still missing. Please send them soon and with = slide numbers. > On 17 Jul 2017, at 13:01, Yoav Nir wrote: >=20 > Hi, folks. >=20 > As a reminder, the ACME working group will meet on Friday at 9:30 AM = in the Athens/Barcelona room on the main lobby level. >=20 > The Agenda is already up: = https://www.ietf.org/proceedings/99/agenda/agenda-99-acme-00.txt = >=20 > We need a Jabber scribe and a note taker. Please volunteer. >=20 > People making presentations (that=E2=80=99s you! right there on the = agenda) please send us your slides in whatever format you want (I can = handle .pdf, .ppt, .pptx, .odp, .key) as long as the slides have = numbers. >=20 > See you all this Friday. >=20 > Ted, Rich, and Yoav >=20 --Apple-Mail=_62819E18-42E3-4D14-93BF-F2A6AB254180 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi again.

We have a jabber scribe. Still need a minutes taker. Praise = will be heaped. Gifts will be bestowed.

Some presentations are still missing. = Please send them soon and with slide numbers.


On 17 Jul 2017, at 13:01, Yoav = Nir <ynir.ietf@gmail.com> wrote:

Hi, folks.

As a reminder, the ACME = working group will meet on Friday at 9:30 AM in the Athens/Barcelona = room on the main lobby level.

The Agenda is already up: https://www.ietf.org/proceedings/99/agenda/agenda-99-acme-00.tx= t

We need = a Jabber scribe and a note taker.  Please volunteer.

People making = presentations (that=E2=80=99s you! right there on the agenda) please = send us your slides in whatever format you want (I can handle .pdf, = .ppt, .pptx, .odp, .key) as long as the slides have numbers.

See you all this = Friday.

Ted, = Rich, and Yoav


= --Apple-Mail=_62819E18-42E3-4D14-93BF-F2A6AB254180-- --Apple-Mail=_FB5E5F7F-82DF-44ED-B12D-9A93CB017F75 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJZbf26AAoJELhJCxUKWMyZ7SQIAJaQS+j7dqndiRBwd/wInjK6 YC9qQXjo+x1Nq/L/8YWN8E7p/N0tO0n5TLP0eTvc1kTh1PTJviRFlnbN8W14D7Nh Biu9kS2afqfIZT0BX3jbia2LhzyJPxDNXBvGQ2bGf87rPq3RqI8A7myfZyApiiQ8 MnBOqtammgYyii0M48fJsiwau0BL3vIB/sznKobKeyHDVw1S2bvATOcQ7RmQT/M8 j+Q0Sy4deFDJ2zIg4wyE25uCgxUrYSluuQ2onupgZ6RaoKNwmwLlRFvF0OqecoP0 Zr8sdAhzdEw71/xpVU+jd7Pw4g5Boq0s3lKFKFq3jM7CJpQGi/Gd+AgnvA6B/f0= =jEYd -----END PGP SIGNATURE----- --Apple-Mail=_FB5E5F7F-82DF-44ED-B12D-9A93CB017F75-- From nobody Tue Jul 18 08:36:50 2017 Return-Path: X-Original-To: acme@ietf.org Delivered-To: acme@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B5F67131B6D; Tue, 18 Jul 2017 08:36:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: acme@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.56.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150039220869.11381.8154704118381813232@ietfa.amsl.com> Date: Tue, 18 Jul 2017 08:36:48 -0700 Archived-At: Subject: [Acme] I-D Action: draft-ietf-acme-service-provider-01.txt X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 15:36:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Automated Certificate Management Environment of the IETF. Title : ACME Identifiers and Challenges for VoIP Service Providers Authors : Mary Barnes Chris Wendt Filename : draft-ietf-acme-service-provider-01.txt Pages : 9 Date : 2017-07-18 Abstract: This document specifies identifiers and challenges required to enable the Automated Certificate Management Environment (ACME) to issue certificates for VoIP service providers to support Secure Telephony Identity (STI). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-acme-service-provider/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-acme-service-provider-01 https://datatracker.ietf.org/doc/html/draft-ietf-acme-service-provider-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-service-provider-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jul 18 08:44:06 2017 Return-Path: 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 B79F0131B46 for ; Tue, 18 Jul 2017 08:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o4gmRaF1Z2RX for ; Tue, 18 Jul 2017 08:44:03 -0700 (PDT) Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::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 9AB19131A7E for ; Tue, 18 Jul 2017 08:44:02 -0700 (PDT) Received: by mail-wr0-x22e.google.com with SMTP id 12so34898863wrb.1 for ; Tue, 18 Jul 2017 08:44:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EtKP5hrFOkrjaeNUSZaZpNXH5ZRcJEZK3pxZ07oTEbE=; b=IMIo6l9QSG/X8RlUaOtj++v9Qmk2abJ8iFgfrIu9X5hdfwpC/4U23EJjzpdbC+kKB5 nTvt9dlhWNd2n+2eUiCvAOO+5yCu4asDjcK+mED5RDeihh6ZCueetdD68xp1qNv7ImIg k0qP6sFBuC+s9az5re4l1z9cxKPOWFViUwcEsIMXCGy9uwtNlN7LHSmfdAvGrUbMdleN MM9WoJ2t2E5qowaNud1pygUVsx9c/2kvcC8rOdG66EUWMJBLSlEbX61H2inCo7PaxA6z 0idHm3SGmvdOgYloTkm3lCFu5MKobOGkDbT9u2XZnfRBEhS+djQ5znpenBb5DVcQJ+Hg DP+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EtKP5hrFOkrjaeNUSZaZpNXH5ZRcJEZK3pxZ07oTEbE=; b=H2oRCN0wwmB8J4wWuMr0fllDtwO60jh2obMPTi8glubadc/qa2EmnjCu4vOXHtPyl/ U415t+eyAH30WjGH2pvRbrjv2VAZg9rgID9jSTpxvh8ofwgkGu0yNenpNUqhZFc59FIZ vyIRm7WSC4aGTezuu1H3YAocJ0rtBVMaImKjMMX2zmHkhF4aM0oXdXZvSJRDwcrPK4/R juUGsQm4dZD7D7mWXm8up5u8fBLMnYFBQUzAP70HkOrTrnGbL+7tyw6n07LHHgpK9S7U Vh1MIn9AliDybzcCykwHoOANstfgLZy+JgMYY7b8oRqJEo3CcCTXSCru0GfUahnvMVra H9tg== X-Gm-Message-State: AIVw1117ARAcHIvJWwMRzlsidIQwneQVbOiUwrOFTgntBmM37nNKI5PK 1jBq25Zke+KE+wi3jbPLaH5nOApBp1bx X-Received: by 10.223.153.70 with SMTP id x64mr1707198wrb.18.1500392640987; Tue, 18 Jul 2017 08:44:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.94.5 with HTTP; Tue, 18 Jul 2017 08:44:00 -0700 (PDT) In-Reply-To: References: <149807165247.15932.14866158682370663408@ietfa.amsl.com> From: Richard Barnes Date: Tue, 18 Jul 2017 17:44:00 +0200 Message-ID: To: Rifaat Shekh-Yusef Cc: Ted Hardie , "Salz, Rich" , "acme@ietf.org" , Yoav Nir Content-Type: multipart/alternative; boundary="f403045f574663e02b05549962e3" Archived-At: Subject: Re: [Acme] Fwd: I-D Action: draft-ietf-acme-acme-07.txt X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 15:44:04 -0000 --f403045f574663e02b05549962e3 Content-Type: text/plain; charset="UTF-8" On Fri, Jun 23, 2017 at 3:33 PM, Rifaat Shekh-Yusef wrote: > I do not believe that I got an answer to my pre-authorization question > here: > https://www.ietf.org/mail-archive/web/acme/current/msg01991.html > > What would be the response of the server if the client sends the > certificate issuance request after it sends the pre-authorization request > but > before it completes the pre-authorization process? > > Would the server reply with the same challenges it provided in the > response to the pre-authorization request? > Hey Rifaat, Sorry for missing this. I think the short answer is that it's up to the server. Either way, the server is instructing the client to fulfill certain instructions. I don't think this really needs much specification; the most would be a recommendation that the server should re-use existing pending challenges. --Richard > > Regards, > Rifaat > > > > On Wed, Jun 21, 2017 at 3:20 PM, Ted Hardie wrote: > >> Howdy, >> >> We'd like to start a short working group last call on the changes made in >> response to the previous last call. It will end June 28th, 2017, any time >> zone (to accommodate any changes needed before the draft deadline the >> following Monday). >> >> Please review carefully, but please respect the discussion which have >> already been held by focusing on new issues or new information about the >> issues that have been resolved. >> >> thanks, >> >> Ted, Rich, (and now) Yoav >> >> >> >> ---------- Forwarded message ---------- >> From: >> Date: Wed, Jun 21, 2017 at 12:00 PM >> Subject: [Acme] I-D Action: draft-ietf-acme-acme-07.txt >> To: i-d-announce@ietf.org >> Cc: acme@ietf.org >> >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Automated Certificate Management >> Environment of the IETF. >> >> Title : Automatic Certificate Management Environment >> (ACME) >> Authors : Richard Barnes >> Jacob Hoffman-Andrews >> James Kasten >> Filename : draft-ietf-acme-acme-07.txt >> Pages : 74 >> Date : 2017-06-21 >> >> Abstract: >> Certificates in PKI using X.509 (PKIX) are used for a number of >> purposes, the most significant of which is the authentication of >> domain names. Thus, certificate authorities in the Web PKI are >> trusted to verify that an applicant for a certificate legitimately >> represents the domain name(s) in the certificate. Today, this >> verification is done through a collection of ad hoc mechanisms. This >> document describes a protocol that a certification authority (CA) and >> an applicant can use to automate the process of verification and >> certificate issuance. The protocol also provides facilities for >> other certificate management functions, such as certificate >> revocation. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-acme-acme/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-acme-acme-07 >> https://datatracker.ietf.org/doc/html/draft-ietf-acme-acme-07 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-acme-07 >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> 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 mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > > --f403045f574663e02b05549962e3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Jun 23, 2017 at 3:33 PM, Rifaat Shekh-Yusef &= lt;rifaat.ietf@g= mail.com> wrote:
I do not believe that I got an answer to my pre-authorization ques= tion here:

Wh= at would be the response of the server if the client sends the
ce= rtificate issuance request after it sends the pre-authorization request but= =C2=A0
before it completes the pre-authorization process?

Would the server reply with the same challenges it = provided in the response to the pre-authorization request?

Hey Rifaat,

Sorry for = missing this.=C2=A0 I think the short answer is that it's up to the ser= ver.=C2=A0 Either way, the server is instructing the client to fulfill cert= ain instructions.=C2=A0 I don't think this really needs much specificat= ion; the most would be a recommendation that the server should re-use exist= ing pending challenges.

--Richard

=C2=A0

Regards,
=C2=A0Rifaat

<= div>

On Wed, Jun 21, 2017 at 3:20 PM,= Ted Hardie <ted.ietf@gmail.com> wrote:
Howdy,

We&= #39;d like to start a short working group last call on the changes made in = response to the previous last call.=C2=A0 It will end June 28th, 2017, any = time zone (to accommodate any changes needed before the draft deadline the = following Monday).

Please review carefully, but please respect= the discussion which have already been held by focusing on new issues or n= ew information about the issues that have been resolved.

thank= s,

Ted, Rich, (and now) Yoav



-= --------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Wed, Jun = 21, 2017 at 12:00 PM
Subject: [Acme] I-D Action: draft-ietf-acme-acme-07= .txt
To: i-d-= announce@ietf.org
Cc: acme@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Automated Certificate Management Environme= nt of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Automatic Certificate Management Environment (ACME)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Rich= ard Barnes
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Jacob Hoffman-Andrews
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 James Kasten
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-acme-acme-07.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 74
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-06-21

Abstract:
=C2=A0 =C2=A0Certificates in PKI using X.509 (PKIX) are used for a number o= f
=C2=A0 =C2=A0purposes, the most significant of which is the authentication = of
=C2=A0 =C2=A0domain names.=C2=A0 Thus, certificate authorities in the Web P= KI are
=C2=A0 =C2=A0trusted to verify that an applicant for a certificate legitima= tely
=C2=A0 =C2=A0represents the domain name(s) in the certificate.=C2=A0 Today,= this
=C2=A0 =C2=A0verification is done through a collection of ad hoc mechanisms= .=C2=A0 This
=C2=A0 =C2=A0document describes a protocol that a certification authority (= CA) and
=C2=A0 =C2=A0an applicant can use to automate the process of verification a= nd
=C2=A0 =C2=A0certificate issuance.=C2=A0 The protocol also provides facilit= ies for
=C2=A0 =C2=A0other certificate management functions, such as certificate =C2=A0 =C2=A0revocation.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ie= tf-acme-acme/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-acme-= acme-07
https://datatracker.ietf.org/doc/h= tml/draft-ietf-acme-acme-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3D= draft-ietf-acme-acme-07


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
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 mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme


--f403045f574663e02b05549962e3-- From nobody Tue Jul 18 10:13:59 2017 Return-Path: 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 E5E26127342 for ; Tue, 18 Jul 2017 10:13:57 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id whPf9tloP6fI for ; Tue, 18 Jul 2017 10:13:56 -0700 (PDT) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::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 AA569131488 for ; Tue, 18 Jul 2017 10:13:55 -0700 (PDT) Received: by mail-ua0-x22e.google.com with SMTP id y47so16195639uag.0 for ; Tue, 18 Jul 2017 10:13:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Vjc5hJZCX+4FHXTgTCqTgANTCSGju23CZ+ScXmlYZ3k=; b=ZJCXe7xaggLe26hgaCcRboftzLHyvTh4bnW5EN96wiTVy1ibgieuTj2l5TOTHJoS4t i9Pp+PsTR99J+I3Nvn208COLrKmUEGTZ2m98fZiLOtegREQE4kLPcoQPc+i2Mz8V5buP LtnR3+R8UGpJ6HMzKCYR+q3p19T4OWteXXFMbw1wq1E9upQVP4z2XzpE6uFXlL2q5Vgb 3ousOCoPTcEy0SfbOYWPG8IueM2npSHC7Ch+aOWPBqFOVZ+lpS/gcDB6n+C72POyMZZf FbMo7xvBxQMuycd4kL/XfdPurmUMMyirvCs5cATDfA0gbwooPCCB7SucmT/VsK+rp/HB NbDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Vjc5hJZCX+4FHXTgTCqTgANTCSGju23CZ+ScXmlYZ3k=; b=uWCudf1ScGTL2zliOm+X85uSRPTjsqru5mABo+yLdu7hSlBxAAob0clk/XSPOvUBjp avxlk1KIli5Y8u4L+mesG8wPDqKl9sIPCG9Pxlps1FCjeoXRuljl8Nj4k5ku+urwMIRU s0ygtiAH+0KxVraCPIYWoVnztAV0gxXQ374UPjU8V7HZjdGjT39ZKYolX2OujbtJCVRb d2ovfx3WfekDfcvTSGn7QHzjSqqvP3GfD7Gp2pjcOuYzyWkHsOHlYj83z7SXUKDc0N+s oDcelXOkqxXErjUgAjJHQtB78+4QoJ82RhiF9H9aoAllp9ka5pfbFiY1gwVe9ECoQ9k8 5TkQ== X-Gm-Message-State: AIVw1131kK8F+UX2GPwUetFsqquZWNR1ry8Oyxgst05Y2367n573y4kr VXRyjLRV6i9L0Lc2htL0GgmijHCtkw== X-Received: by 10.31.203.66 with SMTP id b63mr1289452vkg.48.1500398034752; Tue, 18 Jul 2017 10:13:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.76.29 with HTTP; Tue, 18 Jul 2017 10:13:54 -0700 (PDT) In-Reply-To: References: <149807165247.15932.14866158682370663408@ietfa.amsl.com> From: Rifaat Shekh-Yusef Date: Tue, 18 Jul 2017 13:13:54 -0400 Message-ID: To: Richard Barnes Cc: Ted Hardie , "Salz, Rich" , "acme@ietf.org" , Yoav Nir Content-Type: multipart/alternative; boundary="001a114ddf10e2197505549aa3db" Archived-At: Subject: Re: [Acme] Fwd: I-D Action: draft-ietf-acme-acme-07.txt X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 17:13:58 -0000 --001a114ddf10e2197505549aa3db Content-Type: text/plain; charset="UTF-8" Hi Richard, Take a look at the following exchange with Jacob: https://www.ietf.org/mail-archive/web/acme/current/msg02085.html I think the draft should be clear on the response when the server reuses existing pending authorization: 1. Is it still 201 Created? or should it be 200 OK? 2. Would the payload include the "challenges" object as per the response to the /new-authz request, or would the payload still include the "authorization" object as per the response to the /new-order? Regards, Rifaat On Tue, Jul 18, 2017 at 11:44 AM, Richard Barnes wrote: > > > On Fri, Jun 23, 2017 at 3:33 PM, Rifaat Shekh-Yusef > wrote: > >> I do not believe that I got an answer to my pre-authorization question >> here: >> https://www.ietf.org/mail-archive/web/acme/current/msg01991.html >> >> What would be the response of the server if the client sends the >> certificate issuance request after it sends the pre-authorization request >> but >> before it completes the pre-authorization process? >> >> Would the server reply with the same challenges it provided in the >> response to the pre-authorization request? >> > > Hey Rifaat, > > Sorry for missing this. I think the short answer is that it's up to the > server. Either way, the server is instructing the client to fulfill > certain instructions. I don't think this really needs much specification; > the most would be a recommendation that the server should re-use existing > pending challenges. > > --Richard > > > >> >> Regards, >> Rifaat >> >> >> >> On Wed, Jun 21, 2017 at 3:20 PM, Ted Hardie wrote: >> >>> Howdy, >>> >>> We'd like to start a short working group last call on the changes made >>> in response to the previous last call. It will end June 28th, 2017, any >>> time zone (to accommodate any changes needed before the draft deadline the >>> following Monday). >>> >>> Please review carefully, but please respect the discussion which have >>> already been held by focusing on new issues or new information about the >>> issues that have been resolved. >>> >>> thanks, >>> >>> Ted, Rich, (and now) Yoav >>> >>> >>> >>> ---------- Forwarded message ---------- >>> From: >>> Date: Wed, Jun 21, 2017 at 12:00 PM >>> Subject: [Acme] I-D Action: draft-ietf-acme-acme-07.txt >>> To: i-d-announce@ietf.org >>> Cc: acme@ietf.org >>> >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Automated Certificate Management >>> Environment of the IETF. >>> >>> Title : Automatic Certificate Management Environment >>> (ACME) >>> Authors : Richard Barnes >>> Jacob Hoffman-Andrews >>> James Kasten >>> Filename : draft-ietf-acme-acme-07.txt >>> Pages : 74 >>> Date : 2017-06-21 >>> >>> Abstract: >>> Certificates in PKI using X.509 (PKIX) are used for a number of >>> purposes, the most significant of which is the authentication of >>> domain names. Thus, certificate authorities in the Web PKI are >>> trusted to verify that an applicant for a certificate legitimately >>> represents the domain name(s) in the certificate. Today, this >>> verification is done through a collection of ad hoc mechanisms. This >>> document describes a protocol that a certification authority (CA) and >>> an applicant can use to automate the process of verification and >>> certificate issuance. The protocol also provides facilities for >>> other certificate management functions, such as certificate >>> revocation. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-acme-acme/ >>> >>> There are also htmlized versions available at: >>> https://tools.ietf.org/html/draft-ietf-acme-acme-07 >>> https://datatracker.ietf.org/doc/html/draft-ietf-acme-acme-07 >>> >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-acme-07 >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> 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 mailing list >> Acme@ietf.org >> https://www.ietf.org/mailman/listinfo/acme >> >> > --001a114ddf10e2197505549aa3db Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Richard,

Take a look at the followin= g exchange with Jacob:

=

I think the draft should be clear on the response= when the server reuses existing pending authorization:
1. Is it = still 201 Created? or should it be 200 OK?
2. Would the payload i= nclude the "challenges" object as per the response to the /new-au= thz request, or would the payload still include the "authorization&quo= t; object as per the response to the /new-order?

R= egards,
=C2=A0Rifaat



=

On Tue, Jul= 18, 2017 at 11:44 AM, Richard Barnes <rlb@ipv.sx> wrote:

On Fri, Jun 23, 2017 at 3:33 PM, Rifaat = Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
I do not believe that I got an answer= to my pre-authorization question here:
https://www= .ietf.org/mail-archive/web/acme/current/msg01991.html

What would be the response of the server if the = client sends the
certificate issuance request after it sends the = pre-authorization request but=C2=A0
before it completes the pre-a= uthorization process?

Would the server reply= with the same challenges it provided in the response to the pre-authorizat= ion request?

Hey Rifaat,=

Sorry for missing this.=C2=A0 I think the short a= nswer is that it's up to the server.=C2=A0 Either way, the server is in= structing the client to fulfill certain instructions.=C2=A0 I don't thi= nk this really needs much specification; the most would be a recommendation= that the server should re-use existing pending challenges.

--Richard
=

=C2=A0

Regards,
=C2=A0Rifaat

=

On Wed, Jun 21, 2017 at 3:20 PM, Ted Hardie <= ted.ietf@gmail.com> wrote:
=
Howdy,

We'd like to s= tart a short working group last call on the changes made in response to the= previous last call.=C2=A0 It will end June 28th, 2017, any time zone (to a= ccommodate any changes needed before the draft deadline the following Monda= y).

Please review carefully, but please respect the discussion= which have already been held by focusing on new issues or new information = about the issues that have been resolved.

thanks,

Ted, Rich, (and now) Yoav



---------- Forwarded messag= e ----------
From: = <internet-= drafts@ietf.org>
Date: Wed, Jun 21, 2017 at 12:00 PM
Su= bject: [Acme] I-D Action: draft-ietf-acme-acme-07.txt
To: i-d-announce@ietf.org
C= c: acme@ietf.org
=


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Automated Certificate Management Environme= nt of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Automatic Certificate Management Environment (ACME)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Rich= ard Barnes
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Jacob Hoffman-Andrews
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 James Kasten
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-acme-acme-07.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 74
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-06-21

Abstract:
=C2=A0 =C2=A0Certificates in PKI using X.509 (PKIX) are used for a number o= f
=C2=A0 =C2=A0purposes, the most significant of which is the authentication = of
=C2=A0 =C2=A0domain names.=C2=A0 Thus, certificate authorities in the Web P= KI are
=C2=A0 =C2=A0trusted to verify that an applicant for a certificate legitima= tely
=C2=A0 =C2=A0represents the domain name(s) in the certificate.=C2=A0 Today,= this
=C2=A0 =C2=A0verification is done through a collection of ad hoc mechanisms= .=C2=A0 This
=C2=A0 =C2=A0document describes a protocol that a certification authority (= CA) and
=C2=A0 =C2=A0an applicant can use to automate the process of verification a= nd
=C2=A0 =C2=A0certificate issuance.=C2=A0 The protocol also provides facilit= ies for
=C2=A0 =C2=A0other certificate management functions, such as certificate =C2=A0 =C2=A0revocation.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ie= tf-acme-acme/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-acme-= acme-07
https://datatracker.ietf.org/doc/h= tml/draft-ietf-acme-acme-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3D= draft-ietf-acme-acme-07


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
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 mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme



--001a114ddf10e2197505549aa3db-- From nobody Tue Jul 18 17:49:45 2017 Return-Path: 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 C0C44131935 for ; Tue, 18 Jul 2017 17:49:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org 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 WLi5VB8BV-tl for ; Tue, 18 Jul 2017 17:49:41 -0700 (PDT) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBCBF131691 for ; Tue, 18 Jul 2017 17:49:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject; bh=HqEBE0w3WShf3255mnxR7QkgrrOguM7CFzNZ2U7YyqQ=; b=hy5JtGDoktSOQHJYtQIty5wSrFWXxfbYnli0TZ1dIMr6GIn+n6vKWuO5n2ctYL8/XhQ5VZq1k8x8bmmM7h0W+8R5UjD5+Z3gJJRnVp23Iz35BI8rD0J2lEL9dZ2DRqp/E9KIBNKvQiZ4bXXXQOAZiqa4R6gqBspo3PNchL8Z1BQ=; Received: ; Tue, 18 Jul 2017 17:49:39 -0700 To: Rifaat Shekh-Yusef , Richard Barnes Cc: "Salz, Rich" , Ted Hardie , "acme@ietf.org" , Yoav Nir References: <149807165247.15932.14866158682370663408@ietfa.amsl.com> From: Jacob Hoffman-Andrews Message-ID: Date: Tue, 18 Jul 2017 17:49:40 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------3ECBF657B5C322F2BF5A60C6" Content-Language: en-US Received-SPF: skipped for local relay Archived-At: Subject: Re: [Acme] Fwd: I-D Action: draft-ietf-acme-acme-07.txt X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 00:49:44 -0000 This is a multi-part message in MIME format. --------------3ECBF657B5C322F2BF5A60C6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 07/18/2017 10:13 AM, Rifaat Shekh-Yusef wrote: > Hi Richard, > > Take a look at the following exchange with Jacob: > https://www.ietf.org/mail-archive/web/acme/current/msg02085.html > > > > I think the draft should be clear on the response when the server > reuses existing pending authorization: > 1. Is it still 201 Created? or should it be 200 OK? FWIW, Let's Encrypt is planning to return the exact same code when reusing an existing pending authorization as when creating a new one. --------------3ECBF657B5C322F2BF5A60C6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit On 07/18/2017 10:13 AM, Rifaat Shekh-Yusef wrote:
Hi Richard,

Take a look at the following exchange with Jacob:


I think the draft should be clear on the response when the server reuses existing pending authorization:
1. Is it still 201 Created? or should it be 200 OK?
FWIW, Let's Encrypt is planning to return the exact same code when reusing an existing pending authorization as when creating a new one.
--------------3ECBF657B5C322F2BF5A60C6-- From nobody Tue Jul 18 18:46:00 2017 Return-Path: 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 60927129B70 for ; Tue, 18 Jul 2017 18:45:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.003 X-Spam-Level: X-Spam-Status: No, score=-7.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org 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 k3A2FU6LojDY for ; Tue, 18 Jul 2017 18:45:58 -0700 (PDT) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59A9C1274D0 for ; Tue, 18 Jul 2017 18:45:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject; bh=sWW3BgPGAFAWCxCF1iTf04JNFzOfE3/cbThMBCYFce8=; b=cRR2wWJrCvL7FgmZG5vpHo99O6rPEqK4UMhPLZLtm811c1zd0n1AO0MvHu2QBUIxkd3Mz3CYbRtFtWEetp2PNU1mrGJ+GezGKkV7DWuK1xC18DdmFjwcHvglp6RK7U4TaS1qsJ7j5pwnGbTus1qRMg7WFY67BlDYUAdQcjZILxo=; Received: ; Tue, 18 Jul 2017 18:45:56 -0700 To: Martin Thomson Cc: "acme@ietf.org" , Roland Bracewell Shoemaker References: <150024748968.32685.14490661799494398616@ietfa.amsl.com> <20bfb08c-7f6c-0faf-b026-2cefa7f49b58@letsencrypt.org> <3ab6eecc-9790-ced0-39d8-d15a6bf87c93@eff.org> From: Jacob Hoffman-Andrews Message-ID: Date: Tue, 18 Jul 2017 18:45:57 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Received-SPF: skipped for local relay Archived-At: Subject: Re: [Acme] I-D Action: draft-ietf-acme-ip-00.txt X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 01:45:59 -0000 On 07/17/2017 10:48 PM, Martin Thomson wrote: > The biggest concern I have is the text regarding certificate lifetime > and the handling of the possibility that IP addresses are dynamically > allocated. This seems a little weak and it leaves a lot to the CA to > manage. Is there anything that can be done to gain a stronger > assertion that the allocation is (more) persistent? An affirmation > from someone higher in the tree perhaps? I think ultimately this is a policy question and outside the scope of ACME (except for pointing out that it's worth thinking about). If we want a mechanism for owners of IP space to express the policy they'd like CAs to apply to that space, it should probably look something like CAA. From nobody Wed Jul 19 05:28:04 2017 Return-Path: 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 9D374131451 for ; Wed, 19 Jul 2017 05:28:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id En6y3ieYDb6T for ; Wed, 19 Jul 2017 05:28:02 -0700 (PDT) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::232]) (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 71DC5131B2F for ; Wed, 19 Jul 2017 05:28:01 -0700 (PDT) Received: by mail-ua0-x232.google.com with SMTP id 64so47557641uae.2 for ; Wed, 19 Jul 2017 05:28:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RNrxMrq2LfCJaDxhHakr3tVOZIOeZx92f2c3ifI0oqM=; b=ikok+2GoTZq2nj+qNg5G9siBoYQKE0RwGZ8aDKSH885VYWTz/9LGDWUg8LYw0pH2QJ xS23ymkoRuMAWJf1o+d65xnatZ3IoMJvGu1wfF9XMLig0yD8O68fyXQzHG39OWsarHDx d5Xi1CfvLMMoFas6KENwgWgpUMhmmccrB2BxJRAZxAPV8kcyp5k1v1CygHisQvgwfWsl Oft8SCdxGT0Pj30d6P0Xz7BynIH9AYet6lYnDmgoJDqvv7UX9h3dcCbNzmkrt171IjEK TXlglgZVuG7z8ow5H3ZGGcsNUIRxkLwJpmGIx72/XWsObAr7Ka0yR1Mz2ubKfzx6lSY2 wHOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RNrxMrq2LfCJaDxhHakr3tVOZIOeZx92f2c3ifI0oqM=; b=k79262hccr1pVNKmbwkfxiFCSdVgpVifpTSq3gzJ/ukPoGjWoksy6MK6w0a2KnJ8f0 yBhjBs4ubhY6Npa9Luo1FquwSTDBrAFeyPR+Us6ua34WX+xnSx7hJ3vBQnP4Fu2fypeo MLPPV8w/1Vu0de/BjjbnfTAWHcbF+TZY5Hj1c0U08LyErxPAKtFvOw3Zin5BKouELbUk JP1L7T2vQfgsxskLfzNu3xDCZYLgQK9WdgMnHSzxcHw6YBn82eF/Ah+xhvKd90Jqu/z5 iy8ycHrc5yIQSfPWbWz3gkqKjr1Jth8n0ecnvCmIUajJjAN1dODTxu3ELYZsF0Opdl1T aBEA== X-Gm-Message-State: AIVw111J9XZO56YeQOtfhihBfYOU5laJqmn9hSg3UKb+KTDSE7AjHdop +Pb/7oo1aMCpz2kHPoCCylPqx7USpw== X-Received: by 10.176.80.12 with SMTP id b12mr1147448uaa.63.1500467280662; Wed, 19 Jul 2017 05:28:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.76.29 with HTTP; Wed, 19 Jul 2017 05:28:00 -0700 (PDT) In-Reply-To: References: <149807165247.15932.14866158682370663408@ietfa.amsl.com> From: Rifaat Shekh-Yusef Date: Wed, 19 Jul 2017 08:28:00 -0400 Message-ID: To: Jacob Hoffman-Andrews Cc: Richard Barnes , "Salz, Rich" , Ted Hardie , "acme@ietf.org" , Yoav Nir Content-Type: multipart/alternative; boundary="94eb2c1927b242d5e20554aac3b7" Archived-At: Subject: Re: [Acme] Fwd: I-D Action: draft-ietf-acme-acme-07.txt X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 12:28:04 -0000 --94eb2c1927b242d5e20554aac3b7 Content-Type: text/plain; charset="UTF-8" What about the payload? would you return "challenges" or "authorization? Regards, Rifaat On Tue, Jul 18, 2017 at 8:49 PM, Jacob Hoffman-Andrews wrote: > On 07/18/2017 10:13 AM, Rifaat Shekh-Yusef wrote: > > Hi Richard, > > Take a look at the following exchange with Jacob: > https://www.ietf.org/mail-archive/web/acme/current/msg02085.html > > > I think the draft should be clear on the response when the server reuses > existing pending authorization: > 1. Is it still 201 Created? or should it be 200 OK? > > FWIW, Let's Encrypt is planning to return the exact same code when reusing > an existing pending authorization as when creating a new one. > --94eb2c1927b242d5e20554aac3b7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
What about the payload? would you return "challe= nges" or "authorization?

Regards,
=C2=A0Rifaat

<= br>
On Tue, Jul 18, 2017 at 8:49 PM, Jacob Hoffma= n-Andrews <jsha@eff.org> wrote:
=20 =20 =20
On 07/18/2017 10:13 AM, Rifaat Shekh-Yusef wrote:
Hi Richard,

Take a look at the following exchange with Jacob:


I think the draft should be clear on the response when the server reuses existing pending authorization:
1. Is it still 201 Created? or should it be 200 OK?
 FWIW, Let's Encrypt is planning to return the exact same code when reusing an existing pending authorization as when creating a new one.

--94eb2c1927b242d5e20554aac3b7-- From nobody Wed Jul 19 07:39:34 2017 Return-Path: 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 AFBC112F268 for ; Wed, 19 Jul 2017 07:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2pY3KeibB2IP for ; Wed, 19 Jul 2017 07:39:30 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::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 AB08B131D0C for ; Wed, 19 Jul 2017 07:39:25 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id c74so1044647iod.4 for ; Wed, 19 Jul 2017 07:39:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6+6HVSaGpD78HnukfiiMR+eMAkm+kEm6yKSIQHkkh7Q=; b=qfY5dVAhrfXiwBN7XnEQO//TowF6eJo8sta6fS9FvXilj4WunZhiDHxTaB0lz5LXSA TZJyD8b+rRBMkmHo6KLp+h+9J8cd7bvMUG+8+7cMBFGzT4aTOJTvtDbj7zPwSuv4IxZN qOWswVhPC92csAoljiYu+2dw9WcgxccCVn7398ZFMAjnmgwmJXD4nDXCVMU8jVB/Aw0X mr7URZv2ZwfZrBHuIK3wXXDVJxaweWNyWHc6octLYyLooK+mMBWb78miLLwlG31/Vfhp 9ElQR1QemgFQ9t8N9S9bZ0W0zO/03xUxrpgFkj6c1qjITF4cXDj2cONA8rlDoHQO/id9 c5ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6+6HVSaGpD78HnukfiiMR+eMAkm+kEm6yKSIQHkkh7Q=; b=la6pjZWUets2WiG21cqYS8EwVncq+xecfaQnPjYbphaNykpeln2Z5JB9DjG0mc7oqd Gof3oW6pnpemzVp6FhHNrG8gqRxdwq1ykLFCecSS96TYmHpUfzxoHK+ilWHxbr2AszMT ZlH1aNk4iBN/Jfp0piliwtLG3X+6R/kWIR1omlRqsK+nw1sWar0DCsiAO3QPEyHf8mmA Lkr5rCH6Hlu7rlB50sjYcN21Z2PFp52zcvfm5UGqZnR1eWR2I2d0EK5h9Kmu7JP/5WjQ qT/62W1rMJRDCAaHm/j1moQWk0EEP752MAz6gve21cftnO4Vpnz+kqvFOR2442AqQfSN 3Lzw== X-Gm-Message-State: AIVw112by92xV816V8iZNGMuQGcdRJbrI3tIqV1pZbgEP2pgRhIsVqv4 jSjbY6EbKItWPej9LjNSTQg4ioNmcA== X-Received: by 10.107.16.196 with SMTP id 65mr311290ioq.297.1500475165057; Wed, 19 Jul 2017 07:39:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.26 with HTTP; Wed, 19 Jul 2017 07:39:24 -0700 (PDT) In-Reply-To: References: <150024748968.32685.14490661799494398616@ietfa.amsl.com> <20bfb08c-7f6c-0faf-b026-2cefa7f49b58@letsencrypt.org> <3ab6eecc-9790-ced0-39d8-d15a6bf87c93@eff.org> From: Martin Thomson Date: Wed, 19 Jul 2017 16:39:24 +0200 Message-ID: To: Jacob Hoffman-Andrews Cc: "acme@ietf.org" , Roland Bracewell Shoemaker Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Acme] I-D Action: draft-ietf-acme-ip-00.txt X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 14:39:33 -0000 On 19 July 2017 at 03:45, Jacob Hoffman-Andrews wrote: > On 07/17/2017 10:48 PM, Martin Thomson wrote: >> The biggest concern I have is the text regarding certificate lifetime >> and the handling of the possibility that IP addresses are dynamically >> allocated. This seems a little weak and it leaves a lot to the CA to >> manage. Is there anything that can be done to gain a stronger >> assertion that the allocation is (more) persistent? An affirmation >> from someone higher in the tree perhaps? > > I think ultimately this is a policy question and outside the scope of > ACME (except for pointing out that it's worth thinking about). If we > want a mechanism for owners of IP space to express the policy they'd > like CAs to apply to that space, it should probably look something like CAA. In this case, I disagree. With names, there is an expectation that certificates can be issued for them. This is not the default case for IP addresses, so the defender is not naturally aware that they need to defend this way. I don't think that this needs to be onerous, but an explicit opt in (as opposed to an opt out) would be preferable. From nobody Wed Jul 19 13:38:22 2017 Return-Path: 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 9C7EA12ECC0 for ; Wed, 19 Jul 2017 13:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.003 X-Spam-Level: X-Spam-Status: No, score=-7.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org 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 oaMwdi840E9v for ; Wed, 19 Jul 2017 13:38:19 -0700 (PDT) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3EBC131456 for ; Wed, 19 Jul 2017 13:38:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject; bh=JmB0u9fkPHPQtoHwf18QUvz/op6sLIR3OI52EHq1jwo=; b=qcvtqYB8rvi/sey7/P7ZanBu7wUsJD3ZnCVuNVU6VBZ4dEVFSjl4jLBaEcWb2oyVJ2v0T/97lqa26NWBnV9Xk0GCIKxd/HjcT1sR+GYRV4mEgU9g/FqzQta02cxZKgrzykBbqN+oeqPQXamnmV/1uIt9O2tLWUcwgHty7NbACRk=; Received: ; Wed, 19 Jul 2017 13:38:18 -0700 To: Martin Thomson Cc: "acme@ietf.org" , Roland Bracewell Shoemaker References: <150024748968.32685.14490661799494398616@ietfa.amsl.com> <20bfb08c-7f6c-0faf-b026-2cefa7f49b58@letsencrypt.org> <3ab6eecc-9790-ced0-39d8-d15a6bf87c93@eff.org> From: Jacob Hoffman-Andrews Message-ID: <8a9c7cf0-c5b5-f304-b3fb-ca8dc6e5319a@eff.org> Date: Wed, 19 Jul 2017 13:38:19 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Received-SPF: skipped for local relay Archived-At: Subject: Re: [Acme] I-D Action: draft-ietf-acme-ip-00.txt X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 20:38:22 -0000 On 07/19/2017 07:39 AM, Martin Thomson wrote: > In this case, I disagree. With names, there is an expectation that > certificates can be issued for them. This is not the default case for > IP addresses Why do you say that issuance is disallowed by default for most IP addresses? The CA/Browser Forum Baseline Requirements have authentication methods that can be used to authenticate and issue for any IP address. From nobody Thu Jul 20 00:18:56 2017 Return-Path: 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 1FC0812EB2B for ; Thu, 20 Jul 2017 00:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.701 X-Spam-Level: X-Spam-Status: No, score=-3.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 8exE1xJBgcRS for ; Thu, 20 Jul 2017 00:18:51 -0700 (PDT) Received: from mx1.engr.ucsb.edu (mx1.engr.ucsb.edu [128.111.53.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAC0B127735 for ; Thu, 20 Jul 2017 00:18:51 -0700 (PDT) Received: from mail-wm0-f45.google.com (mail-wm0-f45.google.com [74.125.82.45]) (authenticated bits=0) by mx1.engr.ucsb.edu (8.15.2/8.15.2) with ESMTPSA id v6K7IfJX017721 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 20 Jul 2017 00:18:49 -0700 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.99.2 at mx1.engr.ucsb.edu DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.engr.ucsb.edu v6K7IfJX017721 Received: by mail-wm0-f45.google.com with SMTP id w126so16449625wme.0 for ; Thu, 20 Jul 2017 00:18:48 -0700 (PDT) X-Gm-Message-State: AIVw112rYulHM5lI4DGpTGeTqAna+QSAO+ARrMF/4xu6p679LGNnDxKZ XuUeYzATJvNtxyM6sCn+HXe61bEi7Mg+ X-Received: by 10.80.174.233 with SMTP id f38mr2201899edd.77.1500535120830; Thu, 20 Jul 2017 00:18:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.176.129 with HTTP; Thu, 20 Jul 2017 00:18:10 -0700 (PDT) X-Originating-IP: [98.171.167.82] In-Reply-To: <149807165247.15932.14866158682370663408@ietfa.amsl.com> References: <149807165247.15932.14866158682370663408@ietfa.amsl.com> From: Kevin Borgolte Date: Thu, 20 Jul 2017 00:18:10 -0700 X-Gmail-Original-Message-ID: Message-ID: To: acme@ietf.org Cc: Shuang Hao , Tobias Fiebig , Christopher Kruegel , Giovanni Vigna Content-Type: multipart/alternative; boundary="f403045c2786d9b97d0554ba8e30" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.7 (mx1.engr.ucsb.edu [128.111.53.4]); Thu, 20 Jul 2017 00:18:50 -0700 (PDT) Archived-At: Subject: Re: [Acme] I-D Action: draft-ietf-acme-acme-07.txt X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 07:18:54 -0000 --f403045c2786d9b97d0554ba8e30 Content-Type: text/plain; charset="UTF-8" Hi everyone, we are currently conducting a measurement study about DNS staleness issues with a focus on IP address churning. We encountered the issue that Let's Encrypt (and ACME in general) can be (ab)used to request and receive a valid certificate for a domain, as long as the attacker obtains access to the IP address to which the DNS record points. This can happen due to stale DNS records (e.g., pointing to cloud providers), or through MitM attacks (e.g., as recently observed when an (accidental) BGP hijack re-routed all major payment processors via Moscow). The issued certificates are independent of the actual IP address used for the fraudulent certificate request, and can later be used for malicious purposes (local interception etc.). Although it is a valid certificate request, we think that the ACMEv2 standard should mention practical ways to prevent these cases. This is especially the case, as the malicious certificate issuances may not necessarily attract attention through certificate transparency logs (as the domain points to the same IP address before/after). For example: Consider that Let's Encrypt is used by a service running a.example.com, where the A record of a.example.com points to 192.0.2.1 and 198.51.100.1, with the record pointing to 198.51.100.1 being a stale DNS record, and 198.51.100.1 being an address for a VM instance in a cloud provider's pool. If an attacker now finds a way to allocate 198.51.100.1, she might also use Let's Encrypt to obtain a valid certificate. The certificate request by the attacker is indistinguishable from the outside and from interpreting the certificate transparency logs from what the legitimate operator would do to fix the service behind 198.51.100.1, which previously went stale. Since ACMEv2 is currently in draft, we think now is a good idea to bring up our proposal in the hope to incorporate parts of it into the draft. It relates closely to Yaron's and Jacob's earlier discussion on HTTPS authorization (acme-acme) and -to some degree- also to CAA (acme-caa). While stale DNS records are technically a DNS issue, we think that adding additional language to "11. Operational Considerations" is in the interest of the standard given the impact that it can have in the real world. We also propose, focusing on high-risk targets, a stricter issuance policy: If a valid certificate (e.g., issued by the same operator or a set of operators, checked via CT logs) exists for the requested domain, then the current challenge should be signed by the key. If the last certificate has expired, a grace period set by operators could apply (e.g., 1 month or 3 months). If the expiration date has passed a long time ago, or if no grace period is used by the operator, then a second channel should be used to verify the request (e.g., DNS CRP). This stricter issuance policy has the following benefits: * No burden in the normal and regular case * No (significant) burden if a domain changes ownership legitimately * Only minor and a one-time burden if a certificate has expired recently (depending on a grace period being used) At the same time, it prevents issuing certificates for domains that have stale DNS records (due to caching or not updated yet). Furthermore, it is a solution independent of CAA records, which is not a solution for all problems arising from stale DNS records (e.g., if a DNS record is stale, it points (A RR) to a cloud IP that an attacker gained control over, a CA is designated as allowed to issue certificates via a CAA RR, and the designated account at the CA is using an email address pointing to the same domain; in this case, the attacker can request a certificate valid for some months, giving ample time for an attack). While one could argue that an attacker could use a different domain-validating CA all together, HTTP Public Key Pinning could prevent her attacks in practice. In respect to high-risk targets, we are seeing significant staleness issues for domains pointing to IP addresses at various cloud providers in our study. Additionally, from our results, requesting the respective IP addresses quickly and automatically is practical for an attacker. Therefore, we would recommend to classify domains pointing to cloud providers as high-risk targets; practically, this should be a decision made by the operator and the standard should only inform the operator about the issue and possible solution. Please let us know what you think about the proposal. We would also be happy to share a version of our paper once we have finalized it for submission in the upcoming weeks. Best, Kevin On Wed, Jun 21, 2017 at 12:00 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Automated Certificate Management > Environment of the IETF. > > Title : Automatic Certificate Management Environment > (ACME) > Authors : Richard Barnes > Jacob Hoffman-Andrews > James Kasten > Filename : draft-ietf-acme-acme-07.txt > Pages : 74 > Date : 2017-06-21 > > Abstract: > Certificates in PKI using X.509 (PKIX) are used for a number of > purposes, the most significant of which is the authentication of > domain names. Thus, certificate authorities in the Web PKI are > trusted to verify that an applicant for a certificate legitimately > represents the domain name(s) in the certificate. Today, this > verification is done through a collection of ad hoc mechanisms. This > document describes a protocol that a certification authority (CA) and > an applicant can use to automate the process of verification and > certificate issuance. The protocol also provides facilities for > other certificate management functions, such as certificate > revocation. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-acme-acme/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-acme-acme-07 > https://datatracker.ietf.org/doc/html/draft-ietf-acme-acme-07 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-acme-07 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > --f403045c2786d9b97d0554ba8e30 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi everyone,

we are currentl= y conducting a measurement study about DNS staleness issues with a focus on= IP address churning. We encountered the issue that Let's Encrypt (and = ACME in general) can be (ab)used to request and receive a valid certificate= for a domain, as long as the attacker obtains access to the IP address to = which the DNS record points. This can happen due to stale DNS records (e.g.= , pointing to cloud providers), or through MitM attacks (e.g., as recently = observed when an (accidental) BGP hijack re-routed all major payment proces= sors via Moscow). The issued certificates are independent of the actual IP = address used for the fraudulent certificate request, and can later be used = for malicious purposes (local interception etc.).

= Although it is a valid certificate request, we think that the ACMEv2 standa= rd should mention practical ways to prevent these cases. This is especially= the case, as the malicious certificate issuances may not necessarily attra= ct attention through certificate transparency logs (as the domain points to= the same IP address before/after).

For example: C= onsider that Let's Encrypt is used by a service running a.example.com, where the A record o= f a.example.com poin= ts to 192.0.2.1 and 198.51.100.1, with the record pointing to 198.51.100.1 = being a stale DNS record, and 198.51.100.1 being an address for a VM instan= ce in a cloud provider's pool. If an attacker now finds a way to alloca= te 198.51.100.1, she might also use Let's Encrypt to obtain a valid cer= tificate. The certificate request by the attacker is indistinguishable from= the outside and from interpreting the certificate transparency logs from w= hat the legitimate operator would do to fix the service behind 198.51.100.1= , which previously went stale.

Since ACMEv2 is cur= rently in draft, we think now is a good idea to bring up our proposal in th= e hope to incorporate parts of it into the draft. It relates closely to Yar= on's and Jacob's earlier discussion on HTTPS authorization (acme-ac= me) and -to some degree- also to CAA (acme-caa).

W= hile stale DNS records are technically a DNS issue, we think that adding ad= ditional language to "11. Operational Considerations" is in the i= nterest of the standard given the impact that it can have in the real world= .

We also propose, focusing on high-risk targets, = a stricter issuance policy:

If a valid certificate= (e.g., issued by the same operator or a set of operators, checked via CT l= ogs) exists for the requested domain, then the current challenge should be = signed by the key. If the last certificate has expired, a grace period set = by operators could apply (e.g., 1 month or 3 months). If the expiration dat= e has passed a long time ago, or if no grace period is used by the operator= , then a second channel should be used to verify the request (e.g., DNS CRP= ).

This stricter issuance policy has the following= benefits:

* No burden in the normal and regular c= ase
* No (significant) burden if a domain changes ownership legit= imately
* Only minor and a one-time burden if a certificate has e= xpired recently (depending on a grace period being used)

At the same time, it prevents issuing certificates for domains that = have stale DNS records (due to caching or not updated yet). Furthermore, it= is a solution independent of CAA records, which is not a solution for all = problems arising from stale DNS records (e.g., if a DNS record is stale, it= points (A RR) to a cloud IP that an attacker gained control over, a CA is = designated as allowed to issue certificates via a CAA RR, and the designate= d account at the CA is using an email address pointing to the same domain; = in this case, the attacker can request a certificate valid for some months,= giving ample time for an attack).

While one could= argue that an attacker could use a different domain-validating CA all toge= ther, HTTP Public Key Pinning could prevent her attacks in practice.
<= div>
In respect to high-risk targets, we are seeing significa= nt staleness issues for domains pointing to IP addresses at various cloud p= roviders in our study. Additionally, from our results, requesting the respe= ctive IP addresses quickly and automatically is practical for an attacker. = Therefore, we would recommend to classify domains pointing to cloud provide= rs as high-risk targets; practically, this should be a decision made by the= operator and the standard should only inform the operator about the issue = and possible solution.

Please let us know what you= think about the proposal. We would also be happy to share a version of our= paper once we have finalized it for submission in the upcoming weeks.

Best,
Kevin


On Wed, Jun 21, 2017 at 12:= 00 PM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Automated Certificate Management Environme= nt of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Automatic Certificate Management Environment (ACME)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Rich= ard Barnes
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Jacob Hoffman-Andrews
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 James Kasten
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-acme-acme-07.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 74
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-06-21

Abstract:
=C2=A0 =C2=A0Certificates in PKI using X.509 (PKIX) are used for a number o= f
=C2=A0 =C2=A0purposes, the most significant of which is the authentication = of
=C2=A0 =C2=A0domain names.=C2=A0 Thus, certificate authorities in the Web P= KI are
=C2=A0 =C2=A0trusted to verify that an applicant for a certificate legitima= tely
=C2=A0 =C2=A0represents the domain name(s) in the certificate.=C2=A0 Today,= this
=C2=A0 =C2=A0verification is done through a collection of ad hoc mechanisms= .=C2=A0 This
=C2=A0 =C2=A0document describes a protocol that a certification authority (= CA) and
=C2=A0 =C2=A0an applicant can use to automate the process of verification a= nd
=C2=A0 =C2=A0certificate issuance.=C2=A0 The protocol also provides facilit= ies for
=C2=A0 =C2=A0other certificate management functions, such as certificate =C2=A0 =C2=A0revocation.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ie= tf-acme-acme/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-acme-= acme-07
https://datatracker.ietf.org/doc/h= tml/draft-ietf-acme-acme-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3D= draft-ietf-acme-acme-07


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

--f403045c2786d9b97d0554ba8e30-- From nobody Thu Jul 20 01:25:01 2017 Return-Path: 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 E50EA131A7C for ; Thu, 20 Jul 2017 01:24:47 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FUrA_-WF0i33 for ; Thu, 20 Jul 2017 01:24:46 -0700 (PDT) Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::232]) (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 817EB129B3A for ; Thu, 20 Jul 2017 01:24:46 -0700 (PDT) Received: by mail-wr0-x232.google.com with SMTP id y43so67538593wrd.3 for ; Thu, 20 Jul 2017 01:24:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=tNn6HEboVyzS7QhMKySjU9fyGUrkpcO+x9HWr0sOAew=; b=TI0PHyYPMxSA0TIBZsyU7emRU9nhU/ICxf6TxoEz/7Q6bN+vMbWjBet54Z9V0g4hLN 0K8TEDLd8mYTbV7meM+4viqJHwRfYaOB8ihovrRC+peHpHWSSz3VijuVj+D8zJt9Dk5s OSf8SRxQ9pD7AMe4+J7vrjNiWVvmYnsL5waI9pTG4+1i2toDNIWvyhQVpzQkA1pmhU9I mw3IaQdOyBthIjTraePJkm7ykj1QbPSqAQiWYLhDOua3+wXK1dvmYFCH98bnjGLI38+R ZaFCJLtNeWb26VCD2np8CHg17mqYXAR8c8oBczoXUg3YJSffdhzP/ykJZuZEEXtmQEva imFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=tNn6HEboVyzS7QhMKySjU9fyGUrkpcO+x9HWr0sOAew=; b=KOq8/UWnK/MiyBX0QToMo7tUHQBBKW2QO+wVLts1DbsBb/YDWqjNVLMisJF7uk72dQ b5ehTYjfyzWj803HugAWlmvk/TM7s2LMNaJWo5BfmwG4+gtJC96LWDACsWb/Cw+TnA1m dFQC6d4Mtc1Au/VPiHdV3qVzT5HuwsrXCVAelpCDZYIlmwVW3thjKoUMNIbaw4/dXRg1 lSwpiE40RW2Xc1eKGKdKuTfC6GuV/5101zlUueJlGchZM76bN7vEwWZz94g11dl+S9m0 G5CLQHtJyN2XYA0Rwv4OkklKuo1wnDuDNBIPRMEntgwRUO4cNhy51XdKIBk6ajzP72m8 z/Cg== X-Gm-Message-State: AIVw112y827R9Y9NDAyKBCLSdGfVHNfz0etBvykS3d5NgISUfy3AGt8/ ws+dL1Aep9K0I6nV0E8= X-Received: by 10.223.163.207 with SMTP id m15mr1520960wrb.197.1500539084864; Thu, 20 Jul 2017 01:24:44 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:7059:801e:36de:6305? ([2001:67c:370:128:7059:801e:36de:6305]) by smtp.gmail.com with ESMTPSA id d26sm2598603wra.92.2017.07.20.01.24.44 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Jul 2017 01:24:44 -0700 (PDT) From: Yoav Nir Content-Type: multipart/signed; boundary="Apple-Mail=_D9EBE633-C876-4233-86E2-5C946C3FD204"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 20 Jul 2017 10:24:42 +0200 References: <6FA304D0-F7B3-4D15-9652-89A23DA894EC@gmail.com> <7FBAF6A4-3C5F-4CE7-852A-E08B96F2F7AA@gmail.com> To: ACME WG In-Reply-To: <7FBAF6A4-3C5F-4CE7-852A-E08B96F2F7AA@gmail.com> Message-Id: <770331DC-4791-4172-87E5-107BB4079B8D@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Acme] Friday's meeting X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 08:24:48 -0000 --Apple-Mail=_D9EBE633-C876-4233-86E2-5C946C3FD204 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 18 Jul 2017, at 14:23, Yoav Nir wrote: >=20 > Hi again. >=20 > We have a jabber scribe. Still need a minutes taker. Praise will be = heaped. Gifts will be bestowed. Folks, we still need a volunteer for minutes taker. We can=E2=80=99t run = a meeting without one. --Apple-Mail=_D9EBE633-C876-4233-86E2-5C946C3FD204 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJZcGjLAAoJELhJCxUKWMyZdjIH/03qS2SgONERze5O8lucDyw6 bO/x1lAEdsPEZ38Y6xCY03l64hb9gY2mQxK89A0afhcaqQst9pnavXgjqVH19A1k pTOodZVrZ/gfFmqgJTkyGB74/bntbDLzyPJjNHHLq2oN3MlWKJEdtv0Fh3okI+ZC OzMO73/nHrTlZHjcR9YDA9u9aIzRKDLuZwYbSrhMhgAI3ROgyAqysC8l13sGUW8W Eefx6/56oXW3A/W1qI6Jz3muKVbR/WGgq/1I0arzpCCeAwQSW5RybJCf2xyoHD2w hVutRBK7Yp9K96098Qo8gQI6Q+kS/oEF/QtE67Hfk1AAB5NaLbUj42COle1Qm9A= =cjAd -----END PGP SIGNATURE----- --Apple-Mail=_D9EBE633-C876-4233-86E2-5C946C3FD204-- From nobody Thu Jul 20 02:53:09 2017 Return-Path: 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 F037E127735 for ; Thu, 20 Jul 2017 02:53:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 mU4tGEjGisq0 for ; Thu, 20 Jul 2017 02:53:03 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 0F2D812009C for ; Thu, 20 Jul 2017 02:53:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 1829565750; Thu, 20 Jul 2017 12:53:02 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id fpUvkZ5VFbGH; Thu, 20 Jul 2017 12:53:01 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 57E762313; Thu, 20 Jul 2017 12:52:55 +0300 (EEST) Date: Thu, 20 Jul 2017 12:52:55 +0300 From: Ilari Liusvaara To: Kevin Borgolte Cc: acme@ietf.org, Christopher Kruegel , Shuang Hao , Tobias Fiebig , Giovanni Vigna Message-ID: <20170720095255.d6su4om7hizt6fzq@LK-Perkele-VII> References: <149807165247.15932.14866158682370663408@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [Acme] I-D Action: draft-ietf-acme-acme-07.txt X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 09:53:06 -0000 On Thu, Jul 20, 2017 at 12:18:10AM -0700, Kevin Borgolte wrote: > Hi everyone, > > we are currently conducting a measurement study about DNS staleness issues > with a focus on IP address churning. We encountered the issue that Let's > Encrypt (and ACME in general) can be (ab)used to request and receive a > valid certificate for a domain, as long as the attacker obtains access to > the IP address to which the DNS record points. This can happen due to stale > DNS records (e.g., pointing to cloud providers), or through MitM attacks > (e.g., as recently observed when an (accidental) BGP hijack re-routed all > major payment processors via Moscow). The issued certificates are > independent of the actual IP address used for the fraudulent certificate > request, and can later be used for malicious purposes (local interception > etc.). > > Although it is a valid certificate request, we think that the ACMEv2 > standard should mention practical ways to prevent these cases. This is > especially the case, as the malicious certificate issuances may not > necessarily attract attention through certificate transparency logs (as the > domain points to the same IP address before/after). The methods in base spec just fundamentially rely on security of DNS. The only way to remove dependence on routing would be: 1) Deploy DNSSEC and 2) Add acme-CAA record restricting validation to DNS. > For example: Consider that Let's Encrypt is used by a service running > a.example.com, where the A record of a.example.com points to 192.0.2.1 and > 198.51.100.1, with the record pointing to 198.51.100.1 being a stale DNS > record, and 198.51.100.1 being an address for a VM instance in a cloud > provider's pool. If an attacker now finds a way to allocate 198.51.100.1, > she might also use Let's Encrypt to obtain a valid certificate. The > certificate request by the attacker is indistinguishable from the outside > and from interpreting the certificate transparency logs from what the > legitimate operator would do to fix the service behind 198.51.100.1, which > previously went stale. Stale IP addresses cause problems when renewing (however, that does not occur that often). Also, due to recent "fixes", IPv6 stale addresses can be missed (there are just so many folks with busted DNS configuraiton). And I think that would also cause large amounts of problems for users if the stale record is IPv4 (if it is IPv6, then "happy eyeballs" hides the problem). > We also propose, focusing on high-risk targets, a stricter issuance policy: > > If a valid certificate (e.g., issued by the same operator or a set of > operators, checked via CT logs) exists for the requested domain, then the > current challenge should be signed by the key. If the last certificate has > expired, a grace period set by operators could apply (e.g., 1 month or 3 > months). If the expiration date has passed a long time ago, or if no grace > period is used by the operator, then a second channel should be used to > verify the request (e.g., DNS CRP). There was PoP challenge in earlier versions of ACME spec for exactly that. However, it was removed, because it seemed to be more trouble than worth, and because it signed JSON messages with key intended for something else, which is cryptographically not kosher (and contexts are unusable in real world). In the "order flow" change, did put the CSR first so one can look up the requested key first. However, this would cause major problems if trying to change keys (and many (I am not among them) believe that rotating private keys often is important). This would also complicate "disaster recovery" where the previous keys are lost (usually due to admin mistake, and backups being AWOL like usual). You would not believe how often that happens (and I hear just a small subset). > This stricter issuance policy has the following benefits: > > * No burden in the normal and regular case > * No (significant) burden if a domain changes ownership legitimately > * Only minor and a one-time burden if a certificate has expired recently > (depending on a grace period being used) Err, what? These don't seem even remotely right to me. > At the same time, it prevents issuing certificates for domains that have > stale DNS records (due to caching or not updated yet). Furthermore, it is a > solution independent of CAA records, which is not a solution for all > problems arising from stale DNS records (e.g., if a DNS record is stale, it > points (A RR) to a cloud IP that an attacker gained control over, a CA is > designated as allowed to issue certificates via a CAA RR, and the > designated account at the CA is using an email address pointing to the same > domain; in this case, the attacker can request a certificate valid for some > months, giving ample time for an attack). Caching should not be a big issue: LE limits the cache validity to pretty short values. How many times has LE issued certificate to wrong actor due to stale DNS data (I am aware of at least one DNS hijack incident, but protecting against those is considered too high bar for CAs, even DNSSEC would not have helped). > While one could argue that an attacker could use a different > domain-validating CA all together, HTTP Public Key Pinning could prevent > her attacks in practice. Unfortunately, HPKP is pretty hard to deploy: CA HPKP has two major problems: - CAs rotating intermediate keys in unpredictable ways (upcoming LE ECDSA intermediate anyone?). - Chain-building problems, especially with Chrome. Sending the pinned intermediate in legal chain does not imply that HPKP will pass! EE HPKP does not fail due to CAs rotating keys or chain-building issues, however: - One needs to be serious about backups. And EE HPKP would take care of this problem by itself anyway. > In respect to high-risk targets, we are seeing significant staleness issues > for domains pointing to IP addresses at various cloud providers in our > study. Additionally, from our results, requesting the respective IP > addresses quickly and automatically is practical for an attacker. > Therefore, we would recommend to classify domains pointing to cloud > providers as high-risk targets; practically, this should be a decision made > by the operator and the standard should only inform the operator about the > issue and possible solution. Unfortunately domains pointing at cloud provoders is pretty common, and classifying those as high-risk would cause major issues for legimate users. > Please let us know what you think about the proposal. We would also be > happy to share a version of our paper once we have finalized it for > submission in the upcoming weeks. I think it is a bad bad idea. -Ilari From nobody Thu Jul 20 10:17:07 2017 Return-Path: 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 65DFB131945 for ; Thu, 20 Jul 2017 10:17:05 -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_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 yLC18Y4Krdy9 for ; Thu, 20 Jul 2017 10:17:04 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5B171287A5 for ; Thu, 20 Jul 2017 10:17:03 -0700 (PDT) Received: from [192.168.1.216] (unknown [70.166.5.157]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 6C90A22E271 for ; Thu, 20 Jul 2017 13:16:57 -0400 (EDT) From: Sean Leonard Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 20 Jul 2017 10:16:56 -0700 References: <149807165247.15932.14866158682370663408@ietfa.amsl.com> To: ACME WG In-Reply-To: <149807165247.15932.14866158682370663408@ietfa.amsl.com> Message-Id: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Acme] I-D Action: draft-ietf-acme-acme-07.txt X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 17:17:05 -0000 I reviewed this draft. The concerns raised about the textual transmission of certificates, have = not been fully addressed. But at least they have been partially = addressed, so that progress is appreciated. However since it=E2=80=99s my bad that I have not had the time to flesh = out a response, we can let this go if the certificates are just = transmitted =E2=80=9Caccording to [RFC7468]=E2=80=9D, and as text/plain. = I would also advocate stronger language about the format, namely, that = it is just -----BEGIN CERTIFICATE----- and -----END CERTIFICATE-----, = separated only by newlines (no other text, supplemental or otherwise). I = also don=E2=80=99t see why a client =E2=80=9C=E2=80=98SHOULD=E2=80=99 = verify that the =E2=80=98file=E2=80=99 contains only encoded = certificates. =E2=80=9CMUST=E2=80=9D would be better, and closes = security holes. (MUST is also essentially stated by the sentence that = follows.) If there is any =E2=80=9CSHOULD=E2=80=9D, the client = =E2=80=9CSHOULD=E2=80=9D verify that the public key of the certificate = matches the public key of the submission. Also it=E2=80=99s not a = =E2=80=98file=E2=80=99, it=E2=80=99s unnamed content. Given that the payload is text (and, in particular, no supplementary = text), you may want to note that it=E2=80=99s charset=3Dus-ascii. = However that is the default anyway. I can supply draft text if desirable. Regards, Sean > On Jun 21, 2017, at 12:00 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Automated Certificate Management = Environment of the IETF. >=20 > Title : Automatic Certificate Management Environment = (ACME) > Authors : Richard Barnes > Jacob Hoffman-Andrews > James Kasten > Filename : draft-ietf-acme-acme-07.txt > Pages : 74 > Date : 2017-06-21 >=20 > Abstract: > Certificates in PKI using X.509 (PKIX) are used for a number of > purposes, the most significant of which is the authentication of > domain names. Thus, certificate authorities in the Web PKI are > trusted to verify that an applicant for a certificate legitimately > represents the domain name(s) in the certificate. Today, this > verification is done through a collection of ad hoc mechanisms. = This > document describes a protocol that a certification authority (CA) = and > an applicant can use to automate the process of verification and > certificate issuance. The protocol also provides facilities for > other certificate management functions, such as certificate > revocation. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-acme-acme/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-acme-acme-07 > https://datatracker.ietf.org/doc/html/draft-ietf-acme-acme-07 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-acme-acme-07 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme From nobody Thu Jul 20 11:47:31 2017 Return-Path: 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 93C91131B72 for ; Thu, 20 Jul 2017 11:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.003 X-Spam-Level: X-Spam-Status: No, score=-7.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org 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 Zhaj7z7x7EPp for ; Thu, 20 Jul 2017 11:47:27 -0700 (PDT) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EEB912785F for ; Thu, 20 Jul 2017 11:47:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject; bh=sRfrAD8moaKGg6okHQGfkSaCUxI2Xdex4AhuY8QLTHw=; b=Pp7yrwQf4QfnW39Avfu/JS4eU35E3URYMtrn120P2jUy3glk1+60Gp60A6p15Z4AqZV6RGR7YFdRXD3dFy1BKQt7eqMhVJC+J07hF8rvd1vRUGZu+CYq6gmeJ2FYKVEzQ1hewcnniemoBhfYeVr9hPbiqg8MFx9GM+ELk2dAGNw=; Received: ; Thu, 20 Jul 2017 11:46:22 -0700 To: Kevin Borgolte , acme@ietf.org Cc: Christopher Kruegel , Shuang Hao , Tobias Fiebig , Giovanni Vigna References: <149807165247.15932.14866158682370663408@ietfa.amsl.com> From: Jacob Hoffman-Andrews Message-ID: <175b34b2-f966-901c-6eff-75286b9246ff@eff.org> Date: Thu, 20 Jul 2017 11:46:22 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Received-SPF: skipped for local relay Archived-At: Subject: Re: [Acme] Stale DNS and high-risk issuance X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 18:47:30 -0000 On 07/20/2017 12:18 AM, Kevin Borgolte wrote: > we are currently conducting a measurement study about DNS staleness > issues with a focus on IP address churning. Excellent, I look forward to reading it! > We encountered the issue that Let's Encrypt (and ACME in general) can > be (ab)used to request and receive a valid certificate for a domain, > as long as the attacker obtains access to the IP address to which the > DNS record points. This is true of HTTP and TLS based validation in general. I think the place to address these issues is not in the ACME standard, but potentially as a separate IETF draft with the goal of later adoption by the CA/Browser Forum. For instance, if HTTP and TLS validation were required to contact every IP address they found in DNS, that would mitigate the stale DNS issue you raise. On the other hand, it would hurt usability and reliability. And my intuition is that truly "high risk" domains (those with lots of users, or important data) do not tend to leave stale entries in DNS, because it would harm performance. Hopefully your study will shed light on that assumption! > We also propose, focusing on high-risk targets, a stricter issuance > policy: > > If a valid certificate (e.g., issued by the same operator or a set of > operators, checked via CT logs) exists for the requested domain, then > the current challenge should be signed by the key. If the last > certificate has expired, a grace period set by operators could apply > (e.g., 1 month or 3 months). If the expiration date has passed a long > time ago, or if no grace period is used by the operator, then a second > channel should be used to verify the request (e.g., DNS CRP). As Ilari mentioned, this was originally in the plan for ACME, but we removed it because it was not fully baked. I think it's definitely valuable to consider a successor as a separate document. Currently the idea I have running around my head is to specify an HTTPS challenge alongside the HTTP challenge, where the server expects to receive a currently valid certificate that chains either to its own roots or to some other roots it chooses to trust. This would be an optional extra level of validation that CAs could apply to domains they consider high risk. Upsides: Easy to implement for the both the CA and the Subscriber. Downsides: If all certificate keys are lost, issuance would be blocked; HTTPS validation still assumes that it's hard for third parties to upload unauthorized files to certain paths on the web server. From nobody Thu Jul 20 23:21:44 2017 Return-Path: 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 E4CE1126DFF for ; Thu, 20 Jul 2017 23:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.701 X-Spam-Level: X-Spam-Status: No, score=-3.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 Z5pZws7HkFo9 for ; Thu, 20 Jul 2017 23:21:40 -0700 (PDT) Received: from mx1.engr.ucsb.edu (mx1.engr.ucsb.edu [128.111.53.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51E45126D05 for ; Thu, 20 Jul 2017 23:21:40 -0700 (PDT) Received: from mail-wm0-f53.google.com (mail-wm0-f53.google.com [74.125.82.53]) (authenticated bits=0) by mx1.engr.ucsb.edu (8.15.2/8.15.2) with ESMTPSA id v6L6LUCs001478 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 20 Jul 2017 23:21:38 -0700 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.99.2 at mx1.engr.ucsb.edu DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.engr.ucsb.edu v6L6LUCs001478 Received: by mail-wm0-f53.google.com with SMTP id e131so5206679wme.0 for ; Thu, 20 Jul 2017 23:21:37 -0700 (PDT) X-Gm-Message-State: AIVw110oQCyZvo275jfyP9vKHuPO7SjSv+N4GOWs+4aXT9n/ko+QDVob GPnJvGqcS9m5at3Ag8GbIWhFTg9AUd5m X-Received: by 10.80.137.131 with SMTP id g3mr4531826edg.125.1500618089430; Thu, 20 Jul 2017 23:21:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.176.129 with HTTP; Thu, 20 Jul 2017 23:20:58 -0700 (PDT) X-Originating-IP: [98.171.167.82] From: Kevin Borgolte Date: Thu, 20 Jul 2017 23:20:58 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Ilari Liusvaara Cc: acme@ietf.org, Christopher Kruegel , Shuang Hao , Tobias Fiebig , Giovanni Vigna Content-Type: text/plain; charset="UTF-8" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.7 (mx1.engr.ucsb.edu [128.111.53.4]); Thu, 20 Jul 2017 23:21:38 -0700 (PDT) Archived-At: Subject: Re: [Acme] Stale DNS and high-risk issuance X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 06:21:43 -0000 Hi Ilari, thanks for the thoughtful and fast response, we certainly did not expect one this quickly! > On Thu, Jul 20, 2017 at 12:18:10AM -0700, Kevin Borgolte wrote: > > Hi everyone, > > > > we are currently conducting a measurement study about DNS staleness issues > > with a focus on IP address churning. We encountered the issue that Let's > > Encrypt (and ACME in general) can be (ab)used to request and receive a > > valid certificate for a domain, as long as the attacker obtains access to > > the IP address to which the DNS record points. This can happen due to stale > > DNS records (e.g., pointing to cloud providers), or through MitM attacks > > (e.g., as recently observed when an (accidental) BGP hijack re-routed all > > major payment processors via Moscow). The issued certificates are > > independent of the actual IP address used for the fraudulent certificate > > request, and can later be used for malicious purposes (local interception > > etc.). > > > > Although it is a valid certificate request, we think that the ACMEv2 > > standard should mention practical ways to prevent these cases. This is > > especially the case, as the malicious certificate issuances may not > > necessarily attract attention through certificate transparency logs (as the > > domain points to the same IP address before/after). > The methods in base spec just fundamentially rely on security of DNS. > The only way to remove dependence on routing would be: > > 1) Deploy DNSSEC and > 2) Add acme-CAA record restricting validation to DNS. This would indeed be an alternative solution to our proposal, as it would similarly solve the problem of DNS-related issues. However, a DNS-based solution would not be as practical for most ACME users (yet) because they might not have full control over their nameservers (the web interface of their registrar that they might have to use might not even support CAA), or it might require manual work to renew the certificate. Further considering regular key renewals, a DNS-based solution appears to be less practical and could hamper adoption. > > For example: Consider that Let's Encrypt is used by a service running > > a.example.com, where the A record of a.example.com points to 192.0.2.1 and > > 198.51.100.1, with the record pointing to 198.51.100.1 being a stale DNS > > record, and 198.51.100.1 being an address for a VM instance in a cloud > > provider's pool. If an attacker now finds a way to allocate 198.51.100.1, > > she might also use Let's Encrypt to obtain a valid certificate. The > > certificate request by the attacker is indistinguishable from the outside > > and from interpreting the certificate transparency logs from what the > > legitimate operator would do to fix the service behind 198.51.100.1, which > > previously went stale. > Stale IP addresses cause problems when renewing (however, that does not > occur that often). Also, due to recent "fixes", IPv6 stale addresses can > be missed (there are just so many folks with busted DNS configuraiton). > > And I think that would also cause large amounts of problems for users > if the stale record is IPv4 (if it is IPv6, then "happy eyeballs" hides > the problem). We are not 100% sure what you mean exactly here, but for us, the problem with stale DNS records is not with renewing itself, but with an attacker exploiting the stale DNS information combined with the high IP address churn (which we see particularly for cloud providers). Our definition of stale DNS seems be slightly different or broader than yours: specifically, we also consider domains as stale for which there is only A record, and not only cases in which a single IP address out of multiple might be stale. For instance, a practice we encountered quite often is that VM instances on a cloud provider are freed and the associated IP addresses are released, but the respective DNS records are not updated for some days. In turn, someone else can claim the same IP address and then request a certificate for the domain. In practice, some hours are often sufficient to claim a released address to successfully launch the attack (which might be possible with caching depending on the used nameservers) and we have seen some cases with customer-specific sub-domains being susceptible to the attack (which might be a worthwhile phishing target). > > We also propose, focusing on high-risk targets, a stricter issuance policy: > > > > If a valid certificate (e.g., issued by the same operator or a set of > > operators, checked via CT logs) exists for the requested domain, then the > > current challenge should be signed by the key. If the last certificate has > > expired, a grace period set by operators could apply (e.g., 1 month or 3 > > months). If the expiration date has passed a long time ago, or if no grace > > period is used by the operator, then a second channel should be used to > > verify the request (e.g., DNS CRP). > There was PoP challenge in earlier versions of ACME spec for exactly > that. However, it was removed, because it seemed to be more trouble > than worth, and because it signed JSON messages with key intended for > something else, which is cryptographically not kosher (and contexts are > unusable in real world). We should have been more clear here: rather than signing JSON messages, the authorization should happen over HTTPS rather than HTTP, with the current certificate being used for signing/TLS. There would be no non-kosher JSON signing. > In the "order flow" change, did put the CSR first so one can look up > the requested key first. However, this would cause major problems if > trying to change keys (and many (I am not among them) believe that > rotating private keys often is important). Would you mind elaborate where this would cause major problems exactly when changing keys? Following 7.4 "Applying for Certificate Issuance," the CSR should be part of the initial POST request. Therefore, to verify that the certificate can be issued according to the stricter policy, the ACME server could simply use the HTTP challenge adapted for HTTPS before issuing the certificate, verifying ownership of the old/current certificate non-intrusively. Since the HTTP challenge must be done over HTTP, not HTTPS, there is also no potential conflict. > This would also complicate "disaster recovery" where the previous keys > are lost (usually due to admin mistake, and backups being AWOL like > usual). You would not believe how often that happens (and I hear just > a small subset). Correct, disaster recovery would be made slightly more manual by requiring a second channel to verify the request (e.g., setting a DNS record in addition to HTTPS). Although this might happen quite frequently, we strongly believe that we should opt for secure by default, instead of allowing a practical attack because of disaster recovery eventualities. The burden of our solution is not significant in that case (see below) and what is to be expected for recovering lost credentials (e.g., your email account): a second channel. > > This stricter issuance policy has the following benefits: > > > > * No burden in the normal and regular case > > * No (significant) burden if a domain changes ownership legitimately > > * Only minor and a one-time burden if a certificate has expired recently > > (depending on a grace period being used) > Err, what? These don't seem even remotely right to me. >From what we can tell, most users are/will be using ACME through an ACME client and via HTTP authorization (e.g., LE). For our proposal, the entire process would be transparent for them (case 1). If necessary, a simple prompt can be thrown to instruct users to select a second channel (email, DNS, etc.), with instructions to set them up (case 2 and 3). For cases 2 and 3, after the initial request, the domain would fall back into case 1, which does not require any user interaction and is transparent to the user. In general, the alternative solution, using DNSSEC and restricting ACME to DNS, would be much more cumbersome for users, as they need to set DNS records (often manually). > > At the same time, it prevents issuing certificates for domains that have > > stale DNS records (due to caching or not updated yet). Furthermore, it is a > > solution independent of CAA records, which is not a solution for all > > problems arising from stale DNS records (e.g., if a DNS record is stale, it > > points (A RR) to a cloud IP that an attacker gained control over, a CA is > > designated as allowed to issue certificates via a CAA RR, and the > > designated account at the CA is using an email address pointing to the same > > domain; in this case, the attacker can request a certificate valid for some > > months, giving ample time for an attack). > Caching should not be a big issue: LE limits the cache validity to > pretty short values. > > How many times has LE issued certificate to wrong actor due to stale > DNS data (I am aware of at least one DNS hijack incident, but > protecting against those is considered too high bar for CAs, even > DNSSEC would not have helped). Generally, that is a very difficult (if not impossible) question to answer: it does not show up in CT logs as problematic because the attack looks like a common renewal. To determine whether it was a staleness issue and that the certificate request is illegitimate, one needs complimentary and historical DNS and IP and port liveness data (particularly the latter is almost impossible to get). We focus our data on potential cases that could be claimed certificates for and for which there is DNS traffic on the Internet. Our results show conclusively that the attack is practical for a large number of cases. > > In respect to high-risk targets, we are seeing significant staleness issues > > for domains pointing to IP addresses at various cloud providers in our > > study. Additionally, from our results, requesting the respective IP > > addresses quickly and automatically is practical for an attacker. > > Therefore, we would recommend to classify domains pointing to cloud > > providers as high-risk targets; practically, this should be a decision made > > by the operator and the standard should only inform the operator about the > > issue and possible solution. > Unfortunately domains pointing at cloud provoders is pretty common, > and classifying those as high-risk would cause major issues for > legimate users. With our proposed solution, the only time the user would see a burden is if a domain changed ownership legitimately while a certificate is still valid (case 2), or if the certificate renewal lapsed (case 3). In the normal case, legitimate users should see no difference and encounter no issues. Naturally, system administrator experience is a driving force for HTTPS adoption, and it is why we think our solution has significant potential. Best, Kevin On Thu, Jul 20, 2017 at 2:52 AM, Ilari Liusvaara wrote: > On Thu, Jul 20, 2017 at 12:18:10AM -0700, Kevin Borgolte wrote: >> Hi everyone, >> >> we are currently conducting a measurement study about DNS staleness issues >> with a focus on IP address churning. We encountered the issue that Let's >> Encrypt (and ACME in general) can be (ab)used to request and receive a >> valid certificate for a domain, as long as the attacker obtains access to >> the IP address to which the DNS record points. This can happen due to stale >> DNS records (e.g., pointing to cloud providers), or through MitM attacks >> (e.g., as recently observed when an (accidental) BGP hijack re-routed all >> major payment processors via Moscow). The issued certificates are >> independent of the actual IP address used for the fraudulent certificate >> request, and can later be used for malicious purposes (local interception >> etc.). >> >> Although it is a valid certificate request, we think that the ACMEv2 >> standard should mention practical ways to prevent these cases. This is >> especially the case, as the malicious certificate issuances may not >> necessarily attract attention through certificate transparency logs (as the >> domain points to the same IP address before/after). > > The methods in base spec just fundamentially rely on security of DNS. > The only way to remove dependence on routing would be: > > 1) Deploy DNSSEC and > 2) Add acme-CAA record restricting validation to DNS. > >> For example: Consider that Let's Encrypt is used by a service running >> a.example.com, where the A record of a.example.com points to 192.0.2.1 and >> 198.51.100.1, with the record pointing to 198.51.100.1 being a stale DNS >> record, and 198.51.100.1 being an address for a VM instance in a cloud >> provider's pool. If an attacker now finds a way to allocate 198.51.100.1, >> she might also use Let's Encrypt to obtain a valid certificate. The >> certificate request by the attacker is indistinguishable from the outside >> and from interpreting the certificate transparency logs from what the >> legitimate operator would do to fix the service behind 198.51.100.1, which >> previously went stale. > > Stale IP addresses cause problems when renewing (however, that does not > occur that often). Also, due to recent "fixes", IPv6 stale addresses can > be missed (there are just so many folks with busted DNS configuraiton). > > And I think that would also cause large amounts of problems for users > if the stale record is IPv4 (if it is IPv6, then "happy eyeballs" hides > the problem). > >> We also propose, focusing on high-risk targets, a stricter issuance policy: >> >> If a valid certificate (e.g., issued by the same operator or a set of >> operators, checked via CT logs) exists for the requested domain, then the >> current challenge should be signed by the key. If the last certificate has >> expired, a grace period set by operators could apply (e.g., 1 month or 3 >> months). If the expiration date has passed a long time ago, or if no grace >> period is used by the operator, then a second channel should be used to >> verify the request (e.g., DNS CRP). > > There was PoP challenge in earlier versions of ACME spec for exactly > that. However, it was removed, because it seemed to be more trouble > than worth, and because it signed JSON messages with key intended for > something else, which is cryptographically not kosher (and contexts are > unusable in real world). > > In the "order flow" change, did put the CSR first so one can look up > the requested key first. However, this would cause major problems if > trying to change keys (and many (I am not among them) believe that > rotating private keys often is important). > > This would also complicate "disaster recovery" where the previous keys > are lost (usually due to admin mistake, and backups being AWOL like > usual). You would not believe how often that happens (and I hear just > a small subset). > >> This stricter issuance policy has the following benefits: >> >> * No burden in the normal and regular case >> * No (significant) burden if a domain changes ownership legitimately >> * Only minor and a one-time burden if a certificate has expired recently >> (depending on a grace period being used) > > Err, what? These don't seem even remotely right to me. > >> At the same time, it prevents issuing certificates for domains that have >> stale DNS records (due to caching or not updated yet). Furthermore, it is a >> solution independent of CAA records, which is not a solution for all >> problems arising from stale DNS records (e.g., if a DNS record is stale, it >> points (A RR) to a cloud IP that an attacker gained control over, a CA is >> designated as allowed to issue certificates via a CAA RR, and the >> designated account at the CA is using an email address pointing to the same >> domain; in this case, the attacker can request a certificate valid for some >> months, giving ample time for an attack). > > Caching should not be a big issue: LE limits the cache validity to > pretty short values. > > How many times has LE issued certificate to wrong actor due to stale > DNS data (I am aware of at least one DNS hijack incident, but > protecting against those is considered too high bar for CAs, even > DNSSEC would not have helped). > >> While one could argue that an attacker could use a different >> domain-validating CA all together, HTTP Public Key Pinning could prevent >> her attacks in practice. > > Unfortunately, HPKP is pretty hard to deploy: > > CA HPKP has two major problems: > > - CAs rotating intermediate keys in unpredictable ways (upcoming LE > ECDSA intermediate anyone?). > - Chain-building problems, especially with Chrome. Sending the pinned > intermediate in legal chain does not imply that HPKP will pass! > > EE HPKP does not fail due to CAs rotating keys or chain-building > issues, however: > > - One needs to be serious about backups. > > > And EE HPKP would take care of this problem by itself anyway. > >> In respect to high-risk targets, we are seeing significant staleness issues >> for domains pointing to IP addresses at various cloud providers in our >> study. Additionally, from our results, requesting the respective IP >> addresses quickly and automatically is practical for an attacker. >> Therefore, we would recommend to classify domains pointing to cloud >> providers as high-risk targets; practically, this should be a decision made >> by the operator and the standard should only inform the operator about the >> issue and possible solution. > > Unfortunately domains pointing at cloud provoders is pretty common, > and classifying those as high-risk would cause major issues for > legimate users. > >> Please let us know what you think about the proposal. We would also be >> happy to share a version of our paper once we have finalized it for >> submission in the upcoming weeks. > > I think it is a bad bad idea. > > > -Ilari From nobody Thu Jul 20 23:55:11 2017 Return-Path: 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 2CD451250B8 for ; Thu, 20 Jul 2017 23:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.701 X-Spam-Level: X-Spam-Status: No, score=-3.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 7M6d8n3v0zhO for ; Thu, 20 Jul 2017 23:55:07 -0700 (PDT) Received: from mx1.engr.ucsb.edu (mx1.engr.ucsb.edu [128.111.53.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 552FF124D85 for ; Thu, 20 Jul 2017 23:55:07 -0700 (PDT) Received: from mail-wm0-f51.google.com (mail-wm0-f51.google.com [74.125.82.51]) (authenticated bits=0) by mx1.engr.ucsb.edu (8.15.2/8.15.2) with ESMTPSA id v6L6svW1012598 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 20 Jul 2017 23:55:05 -0700 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.99.2 at mx1.engr.ucsb.edu DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.engr.ucsb.edu v6L6svW1012598 Received: by mail-wm0-f51.google.com with SMTP id w191so5753815wmw.1 for ; Thu, 20 Jul 2017 23:55:05 -0700 (PDT) X-Gm-Message-State: AIVw113dGR4MjYyGu6uE36HUPUkkrZ1q7h7P8fBAzRYu8ay1ViS+0uYK gjOK6/SB1dYH39DQNB2HN6ByEaL8dJHk X-Received: by 10.80.163.135 with SMTP id s7mr3576092edb.18.1500620097394; Thu, 20 Jul 2017 23:54:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.176.129 with HTTP; Thu, 20 Jul 2017 23:54:26 -0700 (PDT) X-Originating-IP: [98.171.167.82] In-Reply-To: <175b34b2-f966-901c-6eff-75286b9246ff@eff.org> References: <149807165247.15932.14866158682370663408@ietfa.amsl.com> <175b34b2-f966-901c-6eff-75286b9246ff@eff.org> From: Kevin Borgolte Date: Thu, 20 Jul 2017 23:54:26 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Jacob Hoffman-Andrews Cc: acme@ietf.org, Christopher Kruegel , Shuang Hao , Tobias Fiebig , Giovanni Vigna Content-Type: text/plain; charset="UTF-8" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.7 (mx1.engr.ucsb.edu [128.111.53.4]); Thu, 20 Jul 2017 23:55:06 -0700 (PDT) Archived-At: Subject: Re: [Acme] Stale DNS and high-risk issuance X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 06:55:09 -0000 Hi Jacob, On Thu, Jul 20, 2017 at 11:46 AM, Jacob Hoffman-Andrews wrote: > > On 07/20/2017 12:18 AM, Kevin Borgolte wrote: > > we are currently conducting a measurement study about DNS staleness > > issues with a focus on IP address churning. > > Excellent, I look forward to reading it! Great! We will be happy to reach out to you in a separate thread if you are interested in reading a draft version, and providing some feedback? > > We encountered the issue that Let's Encrypt (and ACME in general) can > > be (ab)used to request and receive a valid certificate for a domain, > > as long as the attacker obtains access to the IP address to which the > > DNS record points. > > This is true of HTTP and TLS based validation in general. I think the > place to address these issues is not in the ACME standard, but > potentially as a separate IETF draft with the goal of later adoption by > the CA/Browser Forum. For instance, if HTTP and TLS validation were > required to contact every IP address they found in DNS, that would > mitigate the stale DNS issue you raise. On the other hand, it would hurt > usability and reliability. And my intuition is that truly "high risk" > domains (those with lots of users, or important data) do not tend to > leave stale entries in DNS, because it would harm performance. Hopefully > your study will shed light on that assumption! Thanks for the suggestion about the IETF draft, we will look into. I do not think anyone of us has any prior IETF draft experience, so hopping onto an existing one would be the better option for us :-) >From our other response to Ilari: Our definition of stale DNS seems be slightly different or broader than yours: specifically, we also consider domains as stale for which there is only A record, and not only cases in which a single IP address out of multiple might be stale. For instance, a practice we encountered quite often is that VM instances on a cloud provider are freed and the associated IP addresses are released, but the respective DNS records are not updated for some days. In turn, someone else can claim the same IP address and then request a certificate for the domain. In practice, some hours are often sufficient to claim a released address to successfully launch the attack (which might be possible with caching depending on the used nameservers) and we have seen some cases with customer-specific sub-domains being susceptible to the attack (which might be a worthwhile phishing target). We definitely agree with you that requiring all IP addresses they found in DNS to complete HTTP/TLS challenges to combat stale DNS is not a solution, simply for performance and reliability reasons as you mentioned. > > We also propose, focusing on high-risk targets, a stricter issuance > > policy: > > > > If a valid certificate (e.g., issued by the same operator or a set of > > operators, checked via CT logs) exists for the requested domain, then > > the current challenge should be signed by the key. If the last > > certificate has expired, a grace period set by operators could apply > > (e.g., 1 month or 3 months). If the expiration date has passed a long > > time ago, or if no grace period is used by the operator, then a second > > channel should be used to verify the request (e.g., DNS CRP). > > As Ilari mentioned, this was originally in the plan for ACME, but we > removed it because it was not fully baked. I think it's definitely > valuable to consider a successor as a separate document. Currently the > idea I have running around my head is to specify an HTTPS challenge > alongside the HTTP challenge, where the server expects to receive a > currently valid certificate that chains either to its own roots or to > some other roots it chooses to trust. This would be an optional extra > level of validation that CAs could apply to domains they consider high > risk. Upsides: Easy to implement for the both the CA and the Subscriber. > Downsides: If all certificate keys are lost, issuance would be blocked; > HTTPS validation still assumes that it's hard for third parties to > upload unauthorized files to certain paths on the web server. Possibly overly naive, but a solution here could be: * Adapt the HTTP challenge to HTTPS, requiring a valid certificate chain. * Upon receiving a certificate request, offer HTTPS and a second challenge that is considered more trustworthy (DNS? out-of-band?). * Default to attempting HTTPS, fail if the certificate chain is not following the stricter policy. * The remaining challenge is DNS/out-of-band. It would introduce a stricter policy, but would not require changing any language in the current draft, but only require adding two sub-sections: 1. HTTPS challenge 2. How and why to use a stricter policy Furthermore, a CA could default to HTTPS over HTTP if it has issued a certificate to the same domain in the past. Best, Kevin On Thu, Jul 20, 2017 at 11:46 AM, Jacob Hoffman-Andrews wrote: > On 07/20/2017 12:18 AM, Kevin Borgolte wrote: >> we are currently conducting a measurement study about DNS staleness >> issues with a focus on IP address churning. > Excellent, I look forward to reading it! >> We encountered the issue that Let's Encrypt (and ACME in general) can >> be (ab)used to request and receive a valid certificate for a domain, >> as long as the attacker obtains access to the IP address to which the >> DNS record points. > This is true of HTTP and TLS based validation in general. I think the > place to address these issues is not in the ACME standard, but > potentially as a separate IETF draft with the goal of later adoption by > the CA/Browser Forum. For instance, if HTTP and TLS validation were > required to contact every IP address they found in DNS, that would > mitigate the stale DNS issue you raise. On the other hand, it would hurt > usability and reliability. And my intuition is that truly "high risk" > domains (those with lots of users, or important data) do not tend to > leave stale entries in DNS, because it would harm performance. Hopefully > your study will shed light on that assumption! >> We also propose, focusing on high-risk targets, a stricter issuance >> policy: >> >> If a valid certificate (e.g., issued by the same operator or a set of >> operators, checked via CT logs) exists for the requested domain, then >> the current challenge should be signed by the key. If the last >> certificate has expired, a grace period set by operators could apply >> (e.g., 1 month or 3 months). If the expiration date has passed a long >> time ago, or if no grace period is used by the operator, then a second >> channel should be used to verify the request (e.g., DNS CRP). > As Ilari mentioned, this was originally in the plan for ACME, but we > removed it because it was not fully baked. I think it's definitely > valuable to consider a successor as a separate document. Currently the > idea I have running around my head is to specify an HTTPS challenge > alongside the HTTP challenge, where the server expects to receive a > currently valid certificate that chains either to its own roots or to > some other roots it chooses to trust. This would be an optional extra > level of validation that CAs could apply to domains they consider high > risk. Upsides: Easy to implement for the both the CA and the Subscriber. > Downsides: If all certificate keys are lost, issuance would be blocked; > HTTPS validation still assumes that it's hard for third parties to > upload unauthorized files to certain paths on the web server. > From nobody Fri Jul 21 00:52:59 2017 Return-Path: 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 463111316E2 for ; Fri, 21 Jul 2017 00:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 j3Ua4OWod9hj for ; Fri, 21 Jul 2017 00:52:56 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA6C12783A for ; Fri, 21 Jul 2017 00:52:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 498AA66749; Fri, 21 Jul 2017 10:52:54 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id 3mXo8brUSiN8; Fri, 21 Jul 2017 10:52:53 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 9680427B; Fri, 21 Jul 2017 10:52:47 +0300 (EEST) Date: Fri, 21 Jul 2017 10:52:47 +0300 From: Ilari Liusvaara To: Kevin Borgolte Cc: Christopher Kruegel , Shuang Hao , acme@ietf.org, Tobias Fiebig , Giovanni Vigna Message-ID: <20170721075247.3bltlc4lib6xy4no@LK-Perkele-VII> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [Acme] Stale DNS and high-risk issuance X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 07:52:58 -0000 On Thu, Jul 20, 2017 at 11:20:58PM -0700, Kevin Borgolte wrote: > Hi Ilari, > > > > The methods in base spec just fundamentially rely on security of DNS. > > The only way to remove dependence on routing would be: > > > > 1) Deploy DNSSEC and > > 2) Add acme-CAA record restricting validation to DNS. > > This would indeed be an alternative solution to our proposal, as it > would similarly solve the problem of DNS-related issues. However, a > DNS-based solution would not be as practical for most ACME users (yet) > because they might not have full control over their nameservers (the > web interface of their registrar that they might have to use might not > even support CAA), or it might require manual work to renew the > certificate. Further considering regular key renewals, a DNS-based > solution appears to be less practical and could hamper adoption. Yes, requiring this would have very large impact, so it would be nonstarter. There are substantial amount of DNS APIs that can be used to automate DNS updates for DNS validation, making DNS validation totally automatic (and most of the time DNS validation is used, it is totally automatic). The nasty part would be requiring DNSSec, which is substantially more difficult than automated record updates. > > > For example: Consider that Let's Encrypt is used by a service running > > > a.example.com, where the A record of a.example.com points to 192.0.2.1 and > > > 198.51.100.1, with the record pointing to 198.51.100.1 being a stale DNS > > > record, and 198.51.100.1 being an address for a VM instance in a cloud > > > provider's pool. If an attacker now finds a way to allocate 198.51.100.1, > > > she might also use Let's Encrypt to obtain a valid certificate. The > > > certificate request by the attacker is indistinguishable from the outside > > > and from interpreting the certificate transparency logs from what the > > > legitimate operator would do to fix the service behind 198.51.100.1, which > > > previously went stale. > > > Stale IP addresses cause problems when renewing (however, that does not > > occur that often). Also, due to recent "fixes", IPv6 stale addresses can > > be missed (there are just so many folks with busted DNS configuraiton). > > > > And I think that would also cause large amounts of problems for users > > if the stale record is IPv4 (if it is IPv6, then "happy eyeballs" hides > > the problem). > > We are not 100% sure what you mean exactly here, but for us, the > problem with stale DNS records is not with renewing itself, but with > an attacker exploiting the stale DNS information combined with the > high IP address churn (which we see particularly for cloud providers). I would think that having any stale IPv4 addresses in the RRset would cause major issues for users accessing the site. > > In the "order flow" change, did put the CSR first so one can look up > > the requested key first. However, this would cause major problems if > > trying to change keys (and many (I am not among them) believe that > > rotating private keys often is important). > > Would you mind elaborate where this would cause major problems exactly > when changing keys? The ACME server can detect if the key requested is the same as the last time. > > This would also complicate "disaster recovery" where the previous keys > > are lost (usually due to admin mistake, and backups being AWOL like > > usual). You would not believe how often that happens (and I hear just > > a small subset). > > Correct, disaster recovery would be made slightly more manual by > requiring a second channel to verify the request (e.g., setting a DNS > record in addition to HTTPS). Although this might happen quite > frequently, we strongly believe that we should opt for secure by > default, instead of allowing a practical attack because of disaster > recovery eventualities. The burden of our solution is not significant > in that case (see below) and what is to be expected for recovering > lost credentials (e.g., your email account): a second channel. "slightly"? You obviously have very different definition of "slightly" thn me. At scale like LE, this would have large impact. There would be huge amount of users locked out. They can't (mostly skill) to validate using DNS or any othe second factor. If I knew I was dealing with anything like that, I would basically take HPKP-level precauntions (which are far beyond most users). And which will lock the key in place (well, the key would be locked for me anyway) Basically, I think this would cause huge amount of problems for users without much gain, hurting HTTPS adoption greatly. -Ilari From nobody Fri Jul 21 01:39:20 2017 Return-Path: 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 248541317A1 for ; Fri, 21 Jul 2017 01:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNkC0PZUyFGp for ; Fri, 21 Jul 2017 01:39:17 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::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 7922C12EC51 for ; Fri, 21 Jul 2017 01:39:17 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id g6so22378117qkf.5 for ; Fri, 21 Jul 2017 01:39:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=iCbVOZ/aX1l3hg7aejwQNJ4ICvCD3fcVmgIeNQ/Eb4k=; b=SbO1UHm7pZV0Vk57jN7wY8NywGLdIMjBTIgcjYvGbSa6w9QYaQ7fW0/TP1R6ze9zhE oa3NaBREgf0x/jQHFHPibNmVURQu8MxxMIIjIGEVngSS7BnODR29DnFNOpqey0HBy5Gf SdQzGPzKTqdw1A7iIBABCRNJMUiV8LwKLv11GCLUfbp9RzqeQE39cxGLshq1f4tDcv/A oxUfGdtQRHx5ehWdYCkjyvPRQ2m6pdkPqmQZKMi4PiUo2a44GYkgEy/IOBkE5fh/gXnv yXN0TpyCQqbF6s8POiFMRwpYA6JrE9ijhG+SfK2FFbLneL2wdQ/rxhm/hpsbFKORMB1y /9Vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=iCbVOZ/aX1l3hg7aejwQNJ4ICvCD3fcVmgIeNQ/Eb4k=; b=G9s5x3aY3r9Gt/VRILyvcL91jc1C+JHxzbz+7o6cckkcONB4FXx33EKvulHFu85Cwp sjZBiUg5YOb1jQInZbUo/JR+Gd4gB9LkmXnCo5so22qqeQICbhrZiY/zDR4ABKP1aOXC +VeuEABuxeAJC/OtgyS2q+iv6JJaIuvEXJ0wudKCk7kdpfyYvKD4QcFVTMoeZYsjFriN a93B6l8ZlEuMk0LixgKanLEHLOuCF/HI56loeB4Pq6Sfg7OXpauLkp6MvjHrq5H3bU2g 8nG40UAFwNnFIBjFK9GIHm7Q2CuUurGn51gaKKre24a2Ax2ZWDTc07MyjeSTvJbffA5o KCRA== X-Gm-Message-State: AIVw113lJdsvsiJmUifOMPBetejUTr/By7EkLsTMrEf0UKuRNxVIUbNw 1EHt5Tti94aM2wlozdAj8SeYC+oCRVdt X-Received: by 10.55.160.135 with SMTP id j129mr7937236qke.341.1500626356276; Fri, 21 Jul 2017 01:39:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.43.54 with HTTP; Fri, 21 Jul 2017 01:39:15 -0700 (PDT) From: Mary Barnes Date: Fri, 21 Jul 2017 03:39:15 -0500 Message-ID: To: ACME WG Content-Type: multipart/alternative; boundary="001a114fd7c4e810d50554cfcc24" Archived-At: Subject: [Acme] ATIS/SIP Forum NNI documents for SHAKEN X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 08:39:19 -0000 --001a114fd7c4e810d50554cfcc24 Content-Type: text/plain; charset="UTF-8" HI all, Per the discussion during this ACME WG session, here are the documents related to draft-ietf-acme-service-provider and here's a general overview of the activity: https://www.sipforum.org/activities/nni-task-force-introduction/ SHAKEN (describes the use of STIR in the context of VoIP Service Provider networks): https://www.sipforum.org/download/sip-forum-twg-10-signature-based-handling-of-asserted-information-using-tokens-shaken-pdf/?wpdmdl=2813 SHAKEN: Governance Model and Certificate Management: https://www.sipforum.org/download/joint-atissip-forum-standard-signature-based-handling-asserted-information-using-tokens-shaken-governance-model-certificate-management-atis-1000080/?wpdmdl=3360 Regards, Mary --001a114fd7c4e810d50554cfcc24 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
--001a114fd7c4e810d50554cfcc24-- From nobody Fri Jul 21 04:23:36 2017 Return-Path: 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 7542F12F290 for ; Fri, 21 Jul 2017 04:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.71 X-Spam-Level: X-Spam-Status: No, score=-0.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5xrOwegfWB0L for ; Fri, 21 Jul 2017 04:23:33 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BEF012ECB7 for ; Fri, 21 Jul 2017 04:23:33 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v6LBHSU3025361 for ; Fri, 21 Jul 2017 12:23:31 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : mime-version; s=jan2016.eng; bh=7LoJamaEE8+zT5KokIusITC2oBbILgk4d6fSGSmb66c=; b=mYkIRCam4ZzVxyLym+hM6i9CfR9jpjSBpPsl4/rGfY93uPn5/Sk9a1+NpLDIsxFJjswT etkuNmOo292DIrCKBjf0hDfAQk5fcK1z0MlpnkfLsiuS3t2C5CAnns5ExTLSyvhf6/Dt 38/AATGPKyWBoSJ2+tADioDqcTJAQn135/yc4gvXyYWRylIbDzwS+pP5/uecYwkYaEkD UMH1n0UBJQkjnsPTu/hlQXu7vIm1whBu9rKk7gic1KMWnsIKUz0HrCW8tTN+Lg4jyYGi cmNBWZxukDZFxEsZM3P2zKrS58REEektpDSy6bSt6uW+BCJxafpnJ6E5CuyVbpF1h4A1 uA== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2bt1ac2p3g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 21 Jul 2017 12:23:31 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v6LBKt28004957 for ; Fri, 21 Jul 2017 07:23:30 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 2bqecv3sx4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Fri, 21 Jul 2017 07:23:30 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 21 Jul 2017 07:23:29 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Fri, 21 Jul 2017 07:23:29 -0400 From: "Salz, Rich" To: "acme@ietf.org" Thread-Topic: Minutes from IEtf 99 Thread-Index: AdMCE7AQtGH18UnpSrir5nm8k/ol8g== Date: Fri, 21 Jul 2017 11:23:28 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.152.111] Content-Type: multipart/alternative; boundary="_000_d721cc735d7e4ec4b16d3f23090df7ecusma1exdag1mb1msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-21_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707210179 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-21_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707210179 Archived-At: Subject: [Acme] Minutes from IEtf 99 X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 11:23:35 -0000 --_000_d721cc735d7e4ec4b16d3f23090df7ecusma1exdag1mb1msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGxlYXNlIHRha2UgYSBsb29rIGF0IHRoZSBtaW51dGVzL21lbWVzIGFuZCBwb3N0IGNvcnJlY3Rp b25zIGJ5IHRoZSBuZXh0IHdlZWsuDQoNCk1pbnV0ZS10YWtlciBnZXRzIHRvIGNob29zZSBpZiBo ZSBhY2NlcHRzIGNoYW5nZWQgcGljdHVyZXMgb3Igbm90IOKYug0KDQotLQ0KU2VuaW9yIEFyY2hp dGVjdCwgQWthbWFpIFRlY2hub2xvZ2llcw0KTWVtYmVyLCBPcGVuU1NMIERldiBUZWFtDQpJTTog cmljaHNhbHpAamFiYmVyLmF0IFR3aXR0ZXI6IFJpY2hTYWx6DQoNCkZyb206IFJpY2hhcmQgQmFy bmVzIFttYWlsdG86cmxiQGlwdi5zeF0NClNlbnQ6IEZyaWRheSwgSnVseSAyMSwgMjAxNyAxMTow MiBBTQ0KVG86IGFjbWUtY2hhaXJzQHRvb2xzLmlldGYub3JnDQpTdWJqZWN0OiBNZW1lcw0KDQpo dHRwczovL2RvY3MuZ29vZ2xlLmNvbS9kb2N1bWVudC9kLzE4ekIzWmlQR3BxVWkyM3FCLVR3V0Q4 MnJkN1Fkd0RDbzVXTmZrWDQxYWU4L2VkaXQ8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQu Y29tL3YyL3VybD91PWh0dHBzLTNBX19kb2NzLmdvb2dsZS5jb21fZG9jdW1lbnRfZF8xOHpCM1pp UEdwcVVpMjNxQi0yRFR3V0Q4MnJkN1Fkd0RDbzVXTmZrWDQxYWU4X2VkaXQmZD1Ed01CYVEmYz05 NlpiWlpjYU1GNHcwRjRqcE42TFpnJnI9NExNMEdiUjBoOUZ2eDg2RnRzS0ktdyZtPWFya2NYUGJD XzYtNmNsZ3g2NHh4Qk9oekNSeFFBbTdDQVFuV3RRWDdCT1Emcz1xWVc5QV9qaXQyR0hscDFVcGdT SWVRU005SkhPLW1qOGVrUHpFUGVuZTlNJmU9Pg0K --_000_d721cc735d7e4ec4b16d3f23090df7ecusma1exdag1mb1msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bh bi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+UGxlYXNlIHRha2UgYSBsb29rIGF0 IHRoZSBtaW51dGVzL21lbWVzIGFuZCBwb3N0IGNvcnJlY3Rpb25zIGJ5IHRoZSBuZXh0IHdlZWsu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPk1pbnV0ZS10YWtlciBnZXRzIHRvIGNob29zZSBpZiBoZSBhY2NlcHRz IGNoYW5nZWQgcGljdHVyZXMgb3Igbm90DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzIj5KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPi0tJm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlNlbmlvciBBcmNoaXRlY3QsIEFrYW1haSBUZWNo bm9sb2dpZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPk1lbWJlciwgT3BlblNTTCBEZXYgVGVhbTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SU06IHJpY2hzYWx6QGph YmJlci5hdCBUd2l0dGVyOiBSaWNoU2FsejxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4gUmljaGFyZCBCYXJuZXMgW21haWx0bzpybGJAaXB2LnN4XQ0K PGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgSnVseSAyMSwgMjAxNyAxMTowMiBBTTxicj4NCjxi PlRvOjwvYj4gYWNtZS1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g TWVtZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRw czovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX2RvY3MuZ29v Z2xlLmNvbV9kb2N1bWVudF9kXzE4ekIzWmlQR3BxVWkyM3FCLTJEVHdXRDgycmQ3UWR3RENvNVdO ZmtYNDFhZThfZWRpdCZhbXA7ZD1Ed01CYVEmYW1wO2M9OTZaYlpaY2FNRjR3MEY0anBONkxaZyZh bXA7cj00TE0wR2JSMGg5RnZ4ODZGdHNLSS13JmFtcDttPWFya2NYUGJDXzYtNmNsZ3g2NHh4Qk9o ekNSeFFBbTdDQVFuV3RRWDdCT1EmYW1wO3M9cVlXOUFfaml0MkdIbHAxVXBnU0llUVNNOUpITy1t ajhla1B6RVBlbmU5TSZhbXA7ZT0iPmh0dHBzOi8vZG9jcy5nb29nbGUuY29tL2RvY3VtZW50L2Qv MTh6QjNaaVBHcHFVaTIzcUItVHdXRDgycmQ3UWR3RENvNVdOZmtYNDFhZTgvZWRpdDwvYT48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_d721cc735d7e4ec4b16d3f23090df7ecusma1exdag1mb1msgcorpak_-- From nobody Fri Jul 21 04:24:16 2017 Return-Path: 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 799F1129B7F for ; Fri, 21 Jul 2017 04:24:13 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PSKm4uJQ1AXj for ; Fri, 21 Jul 2017 04:24:11 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B72C7131600 for ; Fri, 21 Jul 2017 04:24:09 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v6LBHRxE015573; Fri, 21 Jul 2017 12:24:08 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=ie174ypJ67/L/krv0bvirMycRWbLKqqaJOtIh/OwaFE=; b=o72kVPVIthXetm0uRXWD0G160KSHcc2sEQYuINMssYgJPY1QyN2FVBgHa70HREiMOPV+ zDC2kZLg+CcGV9lKXir2IRNX0hWww43+S7y5evf4gCMeMCgrZkGM8v72X3TNsv9aaD4k ei7FQnsUhj+jHkENGpoPs4uM8x37c7aCo/hh//6n9ChNJeQvbITMckTMwEsaybCqJUYf ufLEExuU4DfNDO0xa9KbtX5gfs0JRVRsKNNkf2Baw32+3erK+fKnL5v09gh8aPlKSsOa DePKisPGN87WPo0Eb4Lr12Ued01tq+i1nmEp2wJyd2ihP//qaNDOJjMMw64Pika7P7xH Wg== Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2btsmmw775-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 21 Jul 2017 12:24:08 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v6LBKt3g025757; Fri, 21 Jul 2017 07:24:07 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint1.akamai.com with ESMTP id 2bqecukw3k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 21 Jul 2017 07:24:07 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 21 Jul 2017 04:24:06 -0700 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Fri, 21 Jul 2017 07:24:06 -0400 From: "Salz, Rich" To: Sean Leonard , ACME WG Thread-Topic: [Acme] I-D Action: draft-ietf-acme-acme-07.txt Thread-Index: AQHTAXv8VnDNKfDGFky8Yvem7le2rKJeJJ0w Date: Fri, 21 Jul 2017 11:24:06 +0000 Message-ID: <0ddd0049ae604d018ee485e3c135dd1f@usma1ex-dag1mb1.msg.corp.akamai.com> References: <149807165247.15932.14866158682370663408@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.152.111] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-21_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707210179 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-21_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707210179 Archived-At: Subject: Re: [Acme] I-D Action: draft-ietf-acme-acme-07.txt X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 11:24:13 -0000 U2VhbiwgYXQgdGhlIG1lZXRpbmcgd2UgYWdyZWVkIHRvIGRvIG1vcmUgaW4gdGhpcyBhcmVhOyBs b29rIGZvciBuZXcgY29udGVudCBmcm9tIHRoZSBlZGl0b3JzLg0KDQoNCi0tICANClNlbmlvciBB cmNoaXRlY3QsIEFrYW1haSBUZWNobm9sb2dpZXMNCk1lbWJlciwgT3BlblNTTCBEZXYgVGVhbQ0K SU06IHJpY2hzYWx6QGphYmJlci5hdCBUd2l0dGVyOiBSaWNoU2Fseg0KDQo+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFNlYW4gTGVvbmFyZCBbbWFpbHRvOmRlditpZXRmQHNl YW50ZWsuY29tXQ0KPiBTZW50OiBUaHVyc2RheSwgSnVseSAyMCwgMjAxNyA3OjE3IFBNDQo+IFRv OiBBQ01FIFdHIDxhY21lQGlldGYub3JnPg0KPiBTdWJqZWN0OiBSZTogW0FjbWVdIEktRCBBY3Rp b246IGRyYWZ0LWlldGYtYWNtZS1hY21lLTA3LnR4dA0KPiANCj4gSSByZXZpZXdlZCB0aGlzIGRy YWZ0Lg0KPiANCj4gVGhlIGNvbmNlcm5zIHJhaXNlZCBhYm91dCB0aGUgdGV4dHVhbCB0cmFuc21p c3Npb24gb2YgY2VydGlmaWNhdGVzLCBoYXZlIG5vdA0KPiBiZWVuIGZ1bGx5IGFkZHJlc3NlZC4g QnV0IGF0IGxlYXN0IHRoZXkgaGF2ZSBiZWVuIHBhcnRpYWxseSBhZGRyZXNzZWQsIHNvIHRoYXQN Cj4gcHJvZ3Jlc3MgaXMgYXBwcmVjaWF0ZWQuDQo+IA0KPiBIb3dldmVyIHNpbmNlIGl04oCZcyBt eSBiYWQgdGhhdCBJIGhhdmUgbm90IGhhZCB0aGUgdGltZSB0byBmbGVzaCBvdXQgYQ0KPiByZXNw b25zZSwgd2UgY2FuIGxldCB0aGlzIGdvIGlmIHRoZSBjZXJ0aWZpY2F0ZXMgYXJlIGp1c3QgdHJh bnNtaXR0ZWQg4oCcYWNjb3JkaW5nDQo+IHRvIFtSRkM3NDY4XeKAnSwgYW5kIGFzIHRleHQvcGxh aW4uIEkgd291bGQgYWxzbyBhZHZvY2F0ZSBzdHJvbmdlciBsYW5ndWFnZQ0KPiBhYm91dCB0aGUg Zm9ybWF0LCBuYW1lbHksIHRoYXQgaXQgaXMganVzdCAtLS0tLUJFR0lOIENFUlRJRklDQVRFLS0t LS0gYW5kIC0tLS0tDQo+IEVORCBDRVJUSUZJQ0FURS0tLS0tLCBzZXBhcmF0ZWQgb25seSBieSBu ZXdsaW5lcyAobm8gb3RoZXIgdGV4dCwNCj4gc3VwcGxlbWVudGFsIG9yIG90aGVyd2lzZSkuIEkg YWxzbyBkb27igJl0IHNlZSB3aHkgYSBjbGllbnQg4oCc4oCYU0hPVUxE4oCZIHZlcmlmeQ0KPiB0 aGF0IHRoZSDigJhmaWxl4oCZIGNvbnRhaW5zIG9ubHkgZW5jb2RlZCBjZXJ0aWZpY2F0ZXMuIOKA nE1VU1TigJ0gd291bGQgYmUgYmV0dGVyLA0KPiBhbmQgY2xvc2VzIHNlY3VyaXR5IGhvbGVzLiAo TVVTVCBpcyBhbHNvIGVzc2VudGlhbGx5IHN0YXRlZCBieSB0aGUgc2VudGVuY2UNCj4gdGhhdCBm b2xsb3dzLikgSWYgdGhlcmUgaXMgYW55IOKAnFNIT1VMROKAnSwgdGhlIGNsaWVudCDigJxTSE9V TETigJ0gdmVyaWZ5IHRoYXQgdGhlDQo+IHB1YmxpYyBrZXkgb2YgdGhlIGNlcnRpZmljYXRlIG1h dGNoZXMgdGhlIHB1YmxpYyBrZXkgb2YgdGhlIHN1Ym1pc3Npb24uIEFsc28NCj4gaXTigJlzIG5v dCBhIOKAmGZpbGXigJksIGl04oCZcyB1bm5hbWVkIGNvbnRlbnQuDQo+IA0KPiBHaXZlbiB0aGF0 IHRoZSBwYXlsb2FkIGlzIHRleHQgKGFuZCwgaW4gcGFydGljdWxhciwgbm8gc3VwcGxlbWVudGFy eSB0ZXh0KSwgeW91DQo+IG1heSB3YW50IHRvIG5vdGUgdGhhdCBpdOKAmXMgY2hhcnNldD11cy1h c2NpaS4gSG93ZXZlciB0aGF0IGlzIHRoZSBkZWZhdWx0DQo+IGFueXdheS4NCj4gDQo+IEkgY2Fu IHN1cHBseSBkcmFmdCB0ZXh0IGlmIGRlc2lyYWJsZS4NCj4gDQo+IFJlZ2FyZHMsDQo+IA0KPiBT ZWFuDQo+IA0KPiA+IE9uIEp1biAyMSwgMjAxNywgYXQgMTI6MDAgUE0sIGludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZyB3cm90ZToNCj4gPg0KPiA+DQo+ID4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMg YXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzDQo+IGRpcmVjdG9yaWVz Lg0KPiA+IFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIEF1dG9tYXRlZCBDZXJ0aWZp Y2F0ZSBNYW5hZ2VtZW50DQo+IEVudmlyb25tZW50IG9mIHRoZSBJRVRGLg0KPiA+DQo+ID4gICAg ICAgIFRpdGxlICAgICAgICAgICA6IEF1dG9tYXRpYyBDZXJ0aWZpY2F0ZSBNYW5hZ2VtZW50IEVu dmlyb25tZW50IChBQ01FKQ0KPiA+ICAgICAgICBBdXRob3JzICAgICAgICAgOiBSaWNoYXJkIEJh cm5lcw0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICBKYWNvYiBIb2ZmbWFuLUFuZHJld3MN Cj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgSmFtZXMgS2FzdGVuDQo+ID4gCUZpbGVuYW1l ICAgICAgICA6IGRyYWZ0LWlldGYtYWNtZS1hY21lLTA3LnR4dA0KPiA+IAlQYWdlcyAgICAgICAg ICAgOiA3NA0KPiA+IAlEYXRlICAgICAgICAgICAgOiAyMDE3LTA2LTIxDQo+ID4NCj4gPiBBYnN0 cmFjdDoNCj4gPiAgIENlcnRpZmljYXRlcyBpbiBQS0kgdXNpbmcgWC41MDkgKFBLSVgpIGFyZSB1 c2VkIGZvciBhIG51bWJlciBvZg0KPiA+ICAgcHVycG9zZXMsIHRoZSBtb3N0IHNpZ25pZmljYW50 IG9mIHdoaWNoIGlzIHRoZSBhdXRoZW50aWNhdGlvbiBvZg0KPiA+ICAgZG9tYWluIG5hbWVzLiAg VGh1cywgY2VydGlmaWNhdGUgYXV0aG9yaXRpZXMgaW4gdGhlIFdlYiBQS0kgYXJlDQo+ID4gICB0 cnVzdGVkIHRvIHZlcmlmeSB0aGF0IGFuIGFwcGxpY2FudCBmb3IgYSBjZXJ0aWZpY2F0ZSBsZWdp dGltYXRlbHkNCj4gPiAgIHJlcHJlc2VudHMgdGhlIGRvbWFpbiBuYW1lKHMpIGluIHRoZSBjZXJ0 aWZpY2F0ZS4gIFRvZGF5LCB0aGlzDQo+ID4gICB2ZXJpZmljYXRpb24gaXMgZG9uZSB0aHJvdWdo IGEgY29sbGVjdGlvbiBvZiBhZCBob2MgbWVjaGFuaXNtcy4gIFRoaXMNCj4gPiAgIGRvY3VtZW50 IGRlc2NyaWJlcyBhIHByb3RvY29sIHRoYXQgYSBjZXJ0aWZpY2F0aW9uIGF1dGhvcml0eSAoQ0Ep IGFuZA0KPiA+ICAgYW4gYXBwbGljYW50IGNhbiB1c2UgdG8gYXV0b21hdGUgdGhlIHByb2Nlc3Mg b2YgdmVyaWZpY2F0aW9uIGFuZA0KPiA+ICAgY2VydGlmaWNhdGUgaXNzdWFuY2UuICBUaGUgcHJv dG9jb2wgYWxzbyBwcm92aWRlcyBmYWNpbGl0aWVzIGZvcg0KPiA+ICAgb3RoZXIgY2VydGlmaWNh dGUgbWFuYWdlbWVudCBmdW5jdGlvbnMsIHN1Y2ggYXMgY2VydGlmaWNhdGUNCj4gPiAgIHJldm9j YXRpb24uDQo+ID4NCj4gPg0KPiA+IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZv ciB0aGlzIGRyYWZ0IGlzOg0KPiA+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWlldGYtYWNtZS1hY21lLw0KPiA+DQo+ID4gVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVy c2lvbnMgYXZhaWxhYmxlIGF0Og0KPiA+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLWFjbWUtYWNtZS0wNw0KPiA+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2h0bWwvZHJhZnQtaWV0Zi1hY21lLWFjbWUtMDcNCj4gPg0KPiA+IEEgZGlmZiBmcm9tIHRoZSBw cmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCj4gPiBodHRwczovL3d3dy5pZXRmLm9y Zy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1hY21lLWFjbWUtMDcNCj4gPg0KPiA+DQo+ID4gUGxl YXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRp bWUgb2YNCj4gPiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZm IGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+ID4NCj4gPiBJbnRlcm5ldC1EcmFm dHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+ID4gZnRwOi8vZnRw LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gQWNtZSBtYWlsaW5nIGxpc3QNCj4gPiBB Y21lQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9h Y21lDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiBBY21lIG1haWxpbmcgbGlzdA0KPiBBY21lQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNtZQ0K From nobody Fri Jul 21 06:32:20 2017 Return-Path: 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 DF329131E08 for ; Fri, 21 Jul 2017 06:32:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.71 X-Spam-Level: X-Spam-Status: No, score=-0.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=letsencrypt.org 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 a4KAag0bPgj5 for ; Fri, 21 Jul 2017 06:32:16 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (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 70A4A131DFF for ; Fri, 21 Jul 2017 06:32:16 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id a62so1437402itd.0 for ; Fri, 21 Jul 2017 06:32:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=letsencrypt.org; s=google; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=4XQdJfNJHAy/OzLRt3oz7VJNrNa8vFcaR9OxH90x33w=; b=VVnvSnkqtgPG3G+8t2EtWteU/eTRGDsf0IpsgHjX1UkU5DL1BCBPkZPoKxI51zIbX6 Iir5yQ9poNy/ajtdAyWKyyEwzvwnxeeKP+8DZSfF9RmtUD+EUPm93LeWa2w2sQoa9Rr3 gETbDkrAk3YDxxR5pe6JYur/6vgBkIhywoqzM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=4XQdJfNJHAy/OzLRt3oz7VJNrNa8vFcaR9OxH90x33w=; b=qLkYmWRQ70x6uOA1Nb1T9lbVvlt0FOKiZkpz+D4vMswXjCIbMzd9VIraz3+5UqQ+7Q eQBzfrNdd4BMoOexUS+5B7WcjciGtDfXVDv134oRBip9rbvQN81UgPFW6B56Ki8U1Aug 38ueVBRg3hyxnsp4WCK3ckzDO00FHIAhsiHT8gmryTMp2lw7QKo3nHFYi8lrxZbXYaWj FUm/H5lABa8CbPGtOQ0M1115vRNW0suFBlSOhTVuoKsMIHvEWBliw2gBu4ltD5Zye53E /JxTThOl21zMUuB+oRSxxZ38xLpnI2xfgnq51VrjD7IXHgf0jCC3Xg1SdpNGTZLr7Pkp YTSg== X-Gm-Message-State: AIVw113MdGL8UxDqLS0C6RkXqV8prDEkhyIowlS7WXbChWoL9xDbGi+c LXsH8M+2W+wwaxkCEtBq86QCo8Iq+Hd8 X-Received: by 10.36.64.209 with SMTP id n200mr6396401ita.63.1500643935703; Fri, 21 Jul 2017 06:32:15 -0700 (PDT) MIME-Version: 1.0 Reply-To: cpu@letsencrypt.org Received: by 10.107.162.65 with HTTP; Fri, 21 Jul 2017 06:32:14 -0700 (PDT) In-Reply-To: References: From: Daniel McCarney Date: Fri, 21 Jul 2017 09:32:14 -0400 Message-ID: To: "Salz, Rich" Cc: "acme@ietf.org" Content-Type: multipart/alternative; boundary="001a1134ff7eb8ef1d0554d3e424" Archived-At: Subject: Re: [Acme] Minutes from IEtf 99 X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 13:32:19 -0000 --001a1134ff7eb8ef1d0554d3e424 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think this is the second time (in my memory) the WG notes have been distributed in "meme form". At the risk of being the stick in the mud I want to express an opinion that "meme notes" are distracting and I think the time spent producing the memes would have been better spent capturing the content of discussions during the working group. I was unable to attend physically and the timezone delta made it difficult to attend virtually. Looking at these notes as they exist presently hasn't given me much understanding of the topics discussed. In the future could the WG consider returning to plain old ASCII for meeting notes and sticking to the content instead of punchlines? Thanks! On Fri, Jul 21, 2017 at 7:23 AM, Salz, Rich wrote: > Please take a look at the minutes/memes and post corrections by the next > week. > > > > Minute-taker gets to choose if he accepts changed pictures or not J > > > > -- > > Senior Architect, Akamai Technologies > > Member, OpenSSL Dev Team > > IM: richsalz@jabber.at Twitter: RichSalz > > > > *From:* Richard Barnes [mailto:rlb@ipv.sx] > *Sent:* Friday, July 21, 2017 11:02 AM > *To:* acme-chairs@tools.ietf.org > *Subject:* Memes > > > > https://docs.google.com/document/d/18zB3ZiPGpqUi23qB- > TwWD82rd7QdwDCo5WNfkX41ae8/edit > > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > > --001a1134ff7eb8ef1d0554d3e424 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think this is the second time (in my memory) the WG note= s have been distributed in "meme form". At the risk of being the = stick in the mud I want to express an opinion that "meme notes" a= re distracting and I think the time spent producing the memes would have be= en better spent capturing the content of discussions during the working gro= up.

I was unable to attend physically and the timezone delta made it= difficult to attend virtually. Looking at these notes as they exist presen= tly hasn't given me much understanding of the topics discussed. In the = future could the WG consider returning to plain old ASCII for meeting notes= and sticking to the content instead of punchlines?

Than= ks!

On= Fri, Jul 21, 2017 at 7:23 AM, Salz, Rich <rsalz@akamai.com> = wrote:

Please take a look at the minutes/memes and post co= rrections by the next week.

=C2=A0

Minute-taker gets to choose if he accepts changed p= ictures or not J<= /u>

=C2=A0

--=C2=A0

Senior Architect, Akamai Technologies=

Member, OpenSSL Dev Team

IM: richsalz@jabber.at Twitter: RichSalz

=C2=A0

From: Richard Barnes [mailto:rlb@ipv.sx]
Sent: Friday, July 21, 2017 11:02 AM
To: = acme-chairs@tools.ietf.org
Subject: Memes

=C2=A0


_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme


--001a1134ff7eb8ef1d0554d3e424-- From nobody Fri Jul 21 06:38:47 2017 Return-Path: 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 A36BA131E17 for ; Fri, 21 Jul 2017 06:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.091 X-Spam-Level: X-Spam-Status: No, score=0.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMkbzdmUW-41 for ; Fri, 21 Jul 2017 06:38:38 -0700 (PDT) Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::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 280B91317A9 for ; Fri, 21 Jul 2017 06:38:38 -0700 (PDT) Received: by mail-wr0-x22d.google.com with SMTP id v105so52414374wrb.0 for ; Fri, 21 Jul 2017 06:38:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QMslzJNOYWiiKSKfa9GzoY1U0hjrvJEmlN2znv9EFn8=; b=JdO4kDZeBP2AnVnzxYEIqylmv5DtR4zqBBQqMOqp10pgwZyAnMpv6uQ+edExwR//b/ 4QdOvS5hLlf42W3cGufcPK3xg92xN6ZlCFDWYXNpUUVyepluG6+Q9wVifWlsjpC2Z5M3 SPXmmTLENWMEGLcMO6CTR8rRb6I1t8D/ZvhNRT/i/eU21A4JiRbEC1Qt++H+7rnDhl8X U41mBRAorK+n5cEpRAe1mHxvxcvZUKAgfEKBr24TFVq5kwBJT9KaiURJUFPEzqGk6iKf sentv1Jyj7lINNl6OKaoTO5C6TeLN5jaYYC8Wj5lyFyH6AxwO/QNkGEOebuna2r8ugyA M2jQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QMslzJNOYWiiKSKfa9GzoY1U0hjrvJEmlN2znv9EFn8=; b=jESzZeUnC2UIS+avSJvm5BN/p5zcTvWxwGl0SLx6EoEH6d2eyRDsicJlf9jPsykgiV 8N9iAqFbA85ekPHmqrvd87xMQJXnHgQn0EFidOpxTvRHy+kn5GiFxF72kNQqBmmIKw6T qFwrson85Ji1oVxQ3yreGlB8Irwdlylo7UkwNmn1tl99Th217VH7dI5NtD8+N4KnINtq qSZKzQjADAK9mU0BKmTNspeQfztiIs/MaDpgYu0L8kE4HK5QI8X67cffx5fiAqxoYI6B Lqt7Qc+Zux+aynC/EbghG/yOLIQ+3RypKuqUQ6VF+G2ggoKSM759O/Xmf69miuhQB8/u MfOw== X-Gm-Message-State: AIVw110O9kxVVBJPkpXEejSD/CSq3uxNLLh0ZDyYi6D1jwpCdEEXSzwz YMf3jlLCfeDdutGo++AQC+0Y/Bom7pxJAp4= X-Received: by 10.223.179.13 with SMTP id j13mr5698460wrd.228.1500644316446; Fri, 21 Jul 2017 06:38:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.94.5 with HTTP; Fri, 21 Jul 2017 06:38:35 -0700 (PDT) Received: by 10.28.94.5 with HTTP; Fri, 21 Jul 2017 06:38:35 -0700 (PDT) In-Reply-To: References: From: Richard Barnes Date: Fri, 21 Jul 2017 15:38:35 +0200 Message-ID: To: Daniel McCarney Cc: acme@ietf.org, "Salz, Rich" Content-Type: multipart/alternative; boundary="94eb2c1b4eb46a9cd20554d3fbdd" Archived-At: Subject: Re: [Acme] Minutes from IEtf 99 X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 13:38:41 -0000 --94eb2c1b4eb46a9cd20554d3fbdd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Of course you're right. I apologize. I will go through the audio recording and produce some proper notes. On Jul 21, 2017 3:32 PM, "Daniel McCarney" wrote: > I think this is the second time (in my memory) the WG notes have been > distributed in "meme form". At the risk of being the stick in the mud I > want to express an opinion that "meme notes" are distracting and I think > the time spent producing the memes would have been better spent capturing > the content of discussions during the working group. > > I was unable to attend physically and the timezone delta made it difficul= t > to attend virtually. Looking at these notes as they exist presently hasn'= t > given me much understanding of the topics discussed. In the future could > the WG consider returning to plain old ASCII for meeting notes and sticki= ng > to the content instead of punchlines? > > Thanks! > > On Fri, Jul 21, 2017 at 7:23 AM, Salz, Rich wrote: > >> Please take a look at the minutes/memes and post corrections by the next >> week. >> >> >> >> Minute-taker gets to choose if he accepts changed pictures or not J >> >> >> >> -- >> >> Senior Architect, Akamai Technologies >> >> Member, OpenSSL Dev Team >> >> IM: richsalz@jabber.at Twitter: RichSalz >> >> >> >> *From:* Richard Barnes [mailto:rlb@ipv.sx] >> *Sent:* Friday, July 21, 2017 11:02 AM >> *To:* acme-chairs@tools.ietf.org >> *Subject:* Memes >> >> >> >> https://docs.google.com/document/d/18zB3ZiPGpqUi23qB-TwWD82r >> d7QdwDCo5WNfkX41ae8/edit >> >> >> _______________________________________________ >> 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 > > --94eb2c1b4eb46a9cd20554d3fbdd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Of course you're right. =C2=A0 I apologize.=C2=A0 I w= ill go through the audio recording and produce some proper notes. =C2=A0

On Jul 21, 201= 7 3:32 PM, "Daniel McCarney" <cpu@letsencrypt.org> wrote:
I think this is the second time (in = my memory) the WG notes have been distributed in "meme form". At = the risk of being the stick in the mud I want to express an opinion that &q= uot;meme notes" are distracting and I think the time spent producing t= he memes would have been better spent capturing the content of discussions = during the working group.

I was unable to attend physically and the = timezone delta made it difficult to attend virtually. Looking at these note= s as they exist presently hasn't given me much understanding of the top= ics discussed. In the future could the WG consider returning to plain old A= SCII for meeting notes and sticking to the content instead of punchlines?
Thanks!

On Fri, Jul 21, 2017 at 7:23 AM, Salz, Rich <rsalz@ak= amai.com> wrote:

Please take a look at the minutes/memes and post co= rrections by the next week.

=C2=A0

Minute-taker gets to choose if he accepts changed p= ictures or not J<= /u>

=C2=A0

--=C2=A0

Senior Architect, Akamai Technologies=

Member, OpenSSL Dev Team

IM: richsalz@jabber.at Twitter: RichSalz

=C2=A0

From: Richard Barnes [mailto:rlb@ipv.sx]
Sent: Friday, July 21, 2017 11:02 AM
To: = acme-chairs@tools.ietf.org
Subject: Memes

=C2=A0


_______________________________________________
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

--94eb2c1b4eb46a9cd20554d3fbdd-- From nobody Fri Jul 21 07:00:17 2017 Return-Path: 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 F03DF131E16 for ; Fri, 21 Jul 2017 07:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.71 X-Spam-Level: X-Spam-Status: No, score=-0.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=letsencrypt.org 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 pGVu83Ouqu0v for ; Fri, 21 Jul 2017 07:00:14 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::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 E8EB2131DFF for ; Fri, 21 Jul 2017 07:00:13 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id j32so2137862iod.0 for ; Fri, 21 Jul 2017 07:00:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=letsencrypt.org; s=google; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=E9gHnvgnc7TQiMVCeuAAva2iArzAwL4sVJlNjnWGa04=; b=bx0HTjXF2MgdrlhMzChDEMAagf8tjQM1R9sWw91HHJenA+Y8TcNtYQugLmCYvqrGbk oSB4B0t38W2VkEOEVnZV2KofC1SbcJUQBEKQO/zf9NHwcV3jnczDUJNsXx72uujiEPLZ +4rTesu5Zg35Xm8BqGwPwT5WPZz018ncxbl8g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=E9gHnvgnc7TQiMVCeuAAva2iArzAwL4sVJlNjnWGa04=; b=Gg4MfohHwk2tsc32B0kgy2O2HJ2U5BXUVjrEN5mKsxv9C6A8VIT0AckCPJyKERp8nz GDsRuHuvy9gCdRIVC4jelGyt6OZAE+BJAscGKjG4TVW+6fw6wHXk3fKo596w9ZRbplF0 G+I+WtBkzJ0085CEFMILWPxClHfMCl2dzFqUWdUYFB9j+NId7Jyozb0O98UdVOPdRyYx NVkBHS9AvsvOxQMh3vQs7wHyM1Wngj19VUXRIWicuJr+ReKeWOurzCN57jd6qE+LGoK7 yr1k6D/j5FMeRDcb93oLBdSwtnFSk45e+NYQDNoUEePTIl2iiX0xj2Fiu8KRJJP7ESfb 6K8Q== X-Gm-Message-State: AIVw111s17JOPIO32so1sTe/b+4FizpWJOf4Eb/IZi/o37mK3EunKcTT ZQQD84/hA0OSLNAPg9XDoBGGbpFSpF7q1Egcig== X-Received: by 10.107.12.197 with SMTP id 66mr7231252iom.273.1500645613182; Fri, 21 Jul 2017 07:00:13 -0700 (PDT) MIME-Version: 1.0 Reply-To: cpu@letsencrypt.org Received: by 10.107.162.65 with HTTP; Fri, 21 Jul 2017 07:00:12 -0700 (PDT) In-Reply-To: References: From: Daniel McCarney Date: Fri, 21 Jul 2017 10:00:12 -0400 Message-ID: To: Richard Barnes Cc: IETF ACME , "Salz, Rich" Content-Type: multipart/alternative; boundary="001a113f9bb0b542610554d448f0" Archived-At: Subject: Re: [Acme] Minutes from IEtf 99 X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 14:00:16 -0000 --001a113f9bb0b542610554d448f0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Richard, Thank you! No need to apologize. On Fri, Jul 21, 2017 at 9:38 AM, Richard Barnes wrote: > Of course you're right. I apologize. I will go through the audio > recording and produce some proper notes. > > On Jul 21, 2017 3:32 PM, "Daniel McCarney" wrote: > >> I think this is the second time (in my memory) the WG notes have been >> distributed in "meme form". At the risk of being the stick in the mud I >> want to express an opinion that "meme notes" are distracting and I think >> the time spent producing the memes would have been better spent capturin= g >> the content of discussions during the working group. >> >> I was unable to attend physically and the timezone delta made it >> difficult to attend virtually. Looking at these notes as they exist >> presently hasn't given me much understanding of the topics discussed. In >> the future could the WG consider returning to plain old ASCII for meetin= g >> notes and sticking to the content instead of punchlines? >> >> Thanks! >> >> On Fri, Jul 21, 2017 at 7:23 AM, Salz, Rich wrote: >> >>> Please take a look at the minutes/memes and post corrections by the nex= t >>> week. >>> >>> >>> >>> Minute-taker gets to choose if he accepts changed pictures or not J >>> >>> >>> >>> -- >>> >>> Senior Architect, Akamai Technologies >>> >>> Member, OpenSSL Dev Team >>> >>> IM: richsalz@jabber.at Twitter: RichSalz >>> >>> >>> >>> *From:* Richard Barnes [mailto:rlb@ipv.sx] >>> *Sent:* Friday, July 21, 2017 11:02 AM >>> *To:* acme-chairs@tools.ietf.org >>> *Subject:* Memes >>> >>> >>> >>> https://docs.google.com/document/d/18zB3ZiPGpqUi23qB-TwWD82r >>> d7QdwDCo5WNfkX41ae8/edit >>> >>> >>> _______________________________________________ >>> 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 >> >> --001a113f9bb0b542610554d448f0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Richard,

Thank you! No need to apologize.
<= div class=3D"gmail_extra">
On Fri, Jul 21, 20= 17 at 9:38 AM, Richard Barnes <rlb@ipv.sx> wrote:
Of course you're right. =C2=A0 I apo= logize.=C2=A0 I will go through the audio recording and produce some proper= notes. =C2=A0

On Jul 21, 2017 3:32 PM, "D= aniel McCarney" <cpu@letsencrypt.org> wrote:
I think this is the second time (in = my memory) the WG notes have been distributed in "meme form". At = the risk of being the stick in the mud I want to express an opinion that &q= uot;meme notes" are distracting and I think the time spent producing t= he memes would have been better spent capturing the content of discussions = during the working group.

I was unable to attend physically and the = timezone delta made it difficult to attend virtually. Looking at these note= s as they exist presently hasn't given me much understanding of the top= ics discussed. In the future could the WG consider returning to plain old A= SCII for meeting notes and sticking to the content instead of punchlines?
Thanks!

On Fri, Jul 21, 2017 at 7:23 AM, Salz, Rich <rsalz@ak= amai.com> wrote:

Please take a look at the minutes/memes and post co= rrections by the next week.

=C2=A0

Minute-taker gets to choose if he accepts changed p= ictures or not J<= /u>

=C2=A0

--=C2=A0

Senior Architect, Akamai Technologies=

Member, OpenSSL Dev Team

IM: richsalz@jabber.at Twitter: RichSalz

=C2=A0

From: Richard Barnes [mailto:rlb@ipv.sx]
Sent: Friday, July 21, 2017 11:02 AM
To: = acme-chairs@tools.ietf.org
Subject: Memes

=C2=A0


_______________________________________________
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


--001a113f9bb0b542610554d448f0-- From nobody Fri Jul 21 08:25:16 2017 Return-Path: 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 91EFA1317A4 for ; Fri, 21 Jul 2017 08:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.709 X-Spam-Level: X-Spam-Status: No, score=-0.709 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5LRKZ6gobLL for ; Fri, 21 Jul 2017 08:25:11 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::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 AB8CD131B42 for ; Fri, 21 Jul 2017 08:25:10 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id w191so16991838wmw.1 for ; Fri, 21 Jul 2017 08:25:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:mime-version:to:cc:from:subject:date:importance :in-reply-to:references; bh=So2UXZT2Qf5HyvB0yOKdP1RIFEAE7Vv3L9Wk7tg6csg=; b=RX+lOF/tZ6TolNYCZBvuMmtUQC83lkDk/h1nimn4CPPVE8yyxPA1ZL6skDzFZ9DofF g0nnIF+I7NrVwYux0ZeShTBFdItDuBL5X8prJKsvLh8VMJctxEXKNAct7ox/MZQaJkcd YEiZcIXLlV5YPzdoQWFmP6ctlEJog3gFq6gXd6Tq3mUl8UqWXfXsCaUBJ6YLpciewmCT yTFkFXtM0TN3zKYzmfnlDCx5FNY4FW1hImEXW2GuXPcMtdmDKZrXv4CR6M4YC9GVpVJQ /ARb3cmXxlCf9o83pg9Upix4mypWad3NO7ddfuYbVeSBtrMWsTx8BawaHaPImZMmJOz6 e/lA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:mime-version:to:cc:from:subject:date :importance:in-reply-to:references; bh=So2UXZT2Qf5HyvB0yOKdP1RIFEAE7Vv3L9Wk7tg6csg=; b=b3860XoE0TPFdefPhLxE5gnK1b9E2ynjX+nG0Qgm0iY0VGEBlEy41qirX422AmqssA 7RUOxBbogyJ6AxRZwh3XndFMeOd5eLgxOGDo5/EgGPzVgEneRS8T26PVYP/dbkmWkGKv Z2vWpZD2kN+Ey+EVHckzO8Y0YBsrAxf1EW06pZ7mShx4hT1mEqAFCi66CI58CdUS5QXE WNTZzyEvMQCsF+AubKtR8AipaEufJsBTfo+PuBrtoNR110a3yFzakn2G8EscOhMT0NJ3 eI9JfTgd24I3gfBwQD2I8SqSOeN0we3h9IUkNMYbENgHqbmEdDHc3bmqIEDm+3JqSezp 1gvg== X-Gm-Message-State: AIVw1113wmwfEDgDpo+Wfj3XbHiVSJ91MGYbce9LrnLIxHiPce2W+fnv 9vmUSfBjqNO0vg== X-Received: by 10.28.91.138 with SMTP id p132mr4950269wmb.92.1500650709095; Fri, 21 Jul 2017 08:25:09 -0700 (PDT) Received: from ?IPv6:::ffff:10.164.199.141? (cst-prg-76-12.cust.vodafone.cz. [46.135.76.12]) by smtp.gmail.com with ESMTPSA id k75sm1344616wmh.10.2017.07.21.08.25.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Jul 2017 08:25:08 -0700 (PDT) Message-ID: <59721cd4.4eec1c0a.fce35.8ce0@mx.google.com> MIME-Version: 1.0 To: "cpu@letsencrypt.org" , Richard Barnes Cc: "Salz, Rich" , IETF ACME From: Yoav Nir Date: Fri, 21 Jul 2017 17:25:07 +0200 Importance: normal X-Priority: 3 In-Reply-To: References: Content-Type: multipart/alternative; boundary="_1FE62E09-1318-46E9-A3DC-98A4B1BEFB4E_" Archived-At: Subject: Re: [Acme] Minutes from IEtf 99 X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 15:25:14 -0000 --_1FE62E09-1318-46E9-A3DC-98A4B1BEFB4E_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Hi, Daniel It should be noted that Richard=E2=80=99s notes are just an aid to the chai= rs (that's Rich and me now that Ted is moving on) The real minutes are what we will upload in a few days or weeks, and they a= re usually in plaintext form. Sent from my Windows 10 phone From: Daniel McCarney Sent: Friday, July 21, 2017 16:00 To: Richard Barnes Cc: Salz, Rich; IETF ACME Subject: Re: [Acme] Minutes from IEtf 99 Hi Richard, Thank you! No need to apologize. On Fri, Jul 21, 2017 at 9:38 AM, Richard Barnes wrote: Of course you're right. =C2=A0 I apologize.=C2=A0 I will go through the aud= io recording and produce some proper notes. =C2=A0 On Jul 21, 2017 3:32 PM, "Daniel McCarney" wrote: I think this is the second time (in my memory) the WG notes have been distr= ibuted in "meme form". At the risk of being the stick in the mud I want to = express an opinion that "meme notes" are distracting and I think the time s= pent producing the memes would have been better spent capturing the content= of discussions during the working group. I was unable to attend physically and the timezone delta made it difficult = to attend virtually. Looking at these notes as they exist presently hasn't = given me much understanding of the topics discussed. In the future could th= e WG consider returning to plain old ASCII for meeting notes and sticking t= o the content instead of punchlines? Thanks! On Fri, Jul 21, 2017 at 7:23 AM, Salz, Rich wrote: Please take a look at the minutes/memes and post corrections by the next we= ek. =C2=A0 Minute-taker gets to choose if he accepts changed pictures or not =E2=98=BA =C2=A0 --=C2=A0=20 Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richsalz@jabber.at Twitter: RichSalz =C2=A0 From: Richard Barnes [mailto:rlb@ipv.sx]=20 Sent: Friday, July 21, 2017 11:02 AM To: acme-chairs@tools.ietf.org Subject: Memes =C2=A0 https://docs.google.com/document/d/18zB3ZiPGpqUi23qB-TwWD82rd7QdwDCo5WNfkX4= 1ae8/edit _______________________________________________ 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 --_1FE62E09-1318-46E9-A3DC-98A4B1BEFB4E_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

Hi, Daniel

<= o:p> 

It should be noted that Richard=E2= =80=99s notes are just an aid to the chairs=C2=A0 (that's Rich and me now t= hat Ted is moving on)

 

The real minutes are what we will upload in a few days or week= s, and they are usually in plaintext form.

&nb= sp;

Sent from my Windows 10 phone

 

From: Daniel McCarney
Sent: Friday, Jul= y 21, 2017 16:00
To: Richard Barnes=
Cc: Salz, Rich; IETF ACME
Subject: Re: [Acme] Mi= nutes from IEtf 99

 

=

Hi Richard,

Thank you! No need to apologize.

 

On Fri, Jul 21, 2017 at 9:38 AM, Richard Barnes <rlb@ipv.sx> wrote:

Of course you= 're right.   I apologize.  I will go through the audio recording = and produce some proper notes.  

 

On Jul 21, 2017 3:32= PM, "Daniel McCarney" <cpu@letsencrypt.org> wrote:

I think this i= s the second time (in my memory) the WG notes have been distributed in &quo= t;meme form". At the risk of being the stick in the mud I want to expr= ess an opinion that "meme notes" are distracting and I think the = time spent producing the memes would have been better spent capturing the c= ontent of discussions during the working group.

I was unable to atte= nd physically and the timezone delta made it difficult to attend virtually.= Looking at these notes as they exist presently hasn't given me much unders= tanding of the topics discussed. In the future could the WG consider return= ing to plain old ASCII for meeting notes and sticking to the content instea= d of punchlines?

 

Thanks!

 

On Fri, Jul 21, 2017 at 7:23 A= M, Salz, Rich <rsa= lz@akamai.com> wrote:

Please take a look at the minutes/m= emes and post corrections by the next week.

 <= /p>

Minute-taker gets to choose if he accepts changed p= ictures or not J

 

-- 

Senior Architect, Akamai Technologies

Member, Op= enSSL Dev Team

IM: richsalz@jabber.at Twitter: RichSalz

 

From: Richard Barnes [m= ailto:rlb@ipv.sx]
<= b>Sent: Friday, July 21, 2017 11:02 AM
To: acme-chairs@tools.ietf.org
Subject: Memes

 


_______________________________________________
Acme mailing lis= t
Acme@ietf.org= https://www.ietf.org/mailman/listinfo/acme

 


_______________________________________________
A= cme mailing list
Acme= @ietf.org
https://www.ietf.org/mailman/listinfo/acme

 

 

<= /html>= --_1FE62E09-1318-46E9-A3DC-98A4B1BEFB4E_-- From nobody Fri Jul 21 08:34:42 2017 Return-Path: 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 7A37E131692 for ; Fri, 21 Jul 2017 08:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.71 X-Spam-Level: X-Spam-Status: No, score=-0.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=letsencrypt.org 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 cWmZsAX_00yr for ; Fri, 21 Jul 2017 08:34:38 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::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 EA50612EC57 for ; Fri, 21 Jul 2017 08:34:37 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id q2so23621481ioe.3 for ; Fri, 21 Jul 2017 08:34:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=letsencrypt.org; s=google; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=JECcfTypq/9O9YyNGrXJcf5pdVC7jrCVjHlTtYSnuqg=; b=OkmLAAEZXV3W9zLORidRNSqyRdiyTfemkgWd8MH6h0t7aIcxJ00yCEQT95fG6l7fsm bvPqgdx6ckcJV6+0KainzoSJie6cOdSbsBongQ1A2Rgt5QpK8XhIXPkd00Kr4v0j2uYR pKvhGbPrPDWfVdRS5s5mnS7rRf7oemGqSncC8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=JECcfTypq/9O9YyNGrXJcf5pdVC7jrCVjHlTtYSnuqg=; b=Px47MufNQRNEg9vF3VVO3GkfyqM78SCEW9h0f5nBe5cKEHSKNsyXGZ5HB0gV7io8os iWrFnPoM4yZLdDoRgEOF+kuDQ6KNlO9wORySZQ1XACRdL7OQsuQ4K5lmG3wcBRgrIe/l KmFiahnZ4swlXCsqZL+JqTGboWzlL6Q1hohgQ9XFcCRuMVhThnwHcVJGvqwIVDSVx6Tr y48681ojXaprQtYIMfB3+HYzEP3FFQboAxkR/fTwmL1xF+nGxaEjMncd5hj4/1CYeGiG zO72VJ0muOEnd2vFihmnrOa0adzxjI3oMdRXxADccyO/AXtO1gbFV6ksPm+GQz4LFYpW 8xQA== X-Gm-Message-State: AIVw112cMEw2+Wf09cahkESX9lClPSzrzAiNN8GImIqUsZNuJG8bu2/6 2UcN1hMdlvftcClLnQ8i33J7Q4prw6Fc X-Received: by 10.107.12.197 with SMTP id 66mr7579590iom.273.1500651277026; Fri, 21 Jul 2017 08:34:37 -0700 (PDT) MIME-Version: 1.0 Reply-To: cpu@letsencrypt.org Received: by 10.107.162.65 with HTTP; Fri, 21 Jul 2017 08:34:36 -0700 (PDT) In-Reply-To: <59721cd4.4eec1c0a.fce35.8ce0@mx.google.com> References: <59721cd4.4eec1c0a.fce35.8ce0@mx.google.com> From: Daniel McCarney Date: Fri, 21 Jul 2017 11:34:36 -0400 Message-ID: To: Yoav Nir Cc: Richard Barnes , "Salz, Rich" , IETF ACME Content-Type: multipart/alternative; boundary="001a113f9bb04ca7bb0554d59ac6" Archived-At: Subject: Re: [Acme] Minutes from IEtf 99 X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 15:34:40 -0000 --001a113f9bb04ca7bb0554d59ac6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Yoav, Thanks for clarifying. I still think that the notes would be a better aid for both the chairs and everyone else if they we're a closer representation of the meeting contents and not memes. I think it's safe to drop the discussion here. If the chairs want meme notes for their aid I won't make a fuss about it. Thanks for engaging with my feedback. - Daniel On Fri, Jul 21, 2017 at 11:25 AM, Yoav Nir wrote: > Hi, Daniel > > > > It should be noted that Richard=E2=80=99s notes are just an aid to the ch= airs > (that's Rich and me now that Ted is moving on) > > > > The real minutes are what we will upload in a few days or weeks, and they > are usually in plaintext form. > > > > Sent from my Windows 10 phone > > > > *From: *Daniel McCarney > *Sent: *Friday, July 21, 2017 16:00 > *To: *Richard Barnes > *Cc: *Salz, Rich ; IETF ACME > *Subject: *Re: [Acme] Minutes from IEtf 99 > > > > Hi Richard, > > Thank you! No need to apologize. > > > > On Fri, Jul 21, 2017 at 9:38 AM, Richard Barnes wrote: > > Of course you're right. I apologize. I will go through the audio > recording and produce some proper notes. > > > > On Jul 21, 2017 3:32 PM, "Daniel McCarney" wrote: > > I think this is the second time (in my memory) the WG notes have been > distributed in "meme form". At the risk of being the stick in the mud I > want to express an opinion that "meme notes" are distracting and I think > the time spent producing the memes would have been better spent capturing > the content of discussions during the working group. > > I was unable to attend physically and the timezone delta made it difficul= t > to attend virtually. Looking at these notes as they exist presently hasn'= t > given me much understanding of the topics discussed. In the future could > the WG consider returning to plain old ASCII for meeting notes and sticki= ng > to the content instead of punchlines? > > > > Thanks! > > > > On Fri, Jul 21, 2017 at 7:23 AM, Salz, Rich wrote: > > Please take a look at the minutes/memes and post corrections by the next > week. > > > > Minute-taker gets to choose if he accepts changed pictures or not J > > > > -- > > Senior Architect, Akamai Technologies > > Member, OpenSSL Dev Team > > IM: richsalz@jabber.at Twitter: RichSalz > > > > *From:* Richard Barnes [mailto:rlb@ipv.sx] > *Sent:* Friday, July 21, 2017 11:02 AM > *To:* acme-chairs@tools.ietf.org > *Subject:* Memes > > > > https://docs.google.com/document/d/18zB3ZiPGpqUi23qB- > TwWD82rd7QdwDCo5WNfkX41ae8/edit > > > > _______________________________________________ > 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 > > > > > --001a113f9bb04ca7bb0554d59ac6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Yoav,

Thanks for clarifying. I still think that = the notes would be a better aid for both the chairs and everyone else if th= ey we're a closer representation of the meeting contents and not memes.=

I think it's safe to drop the discussion here. If the chairs wa= nt meme notes for their aid I won't make a fuss about it. Thanks for en= gaging with my feedback.

- Daniel


On Fri, Jul 21, 2017 at 11:25 AM, Yoav= Nir <ynir.ietf@gmail.com> wrote:

Hi, Daniel

<= p class=3D"MsoNormal">=C2=A0

It sho= uld be noted that Richard=E2=80=99s notes are just an aid to the chairs=C2= =A0 (that's Rich and me now that Ted is moving on)

=C2=A0

The real minutes are w= hat we will upload in a few days or weeks, and they are usually in plaintex= t form.

=C2=A0

Sent from my Windows 10 phone

=C2=A0=

From: Dan= iel McCarney
Sent: Friday, July 21, 2017 16:00
To: = Richard Barnes
Cc= : Salz, Rich;= IETF ACME
Sub= ject: Re: [Acme] Minutes from IEtf 99

<= p class=3D"MsoNormal">=C2=A0

H= i Richard,

Thank you! No need to apologize.

=C2=A0

On Fri, = Jul 21, 2017 at 9:38 AM, Richard Barnes <rlb@ipv.sx> wrote:

Of course you're rig= ht. =C2=A0 I apologize.=C2=A0 I will go through the audio recording and pro= duce some proper notes. =C2=A0

=C2=A0

On Jul 21, 2017 3:32= PM, "Daniel McCarney" <cpu@letsencrypt.org> wrote:

I think this= is the second time (in my memory) the WG notes have been distributed in &q= uot;meme form". At the risk of being the stick in the mud I want to ex= press an opinion that "meme notes" are distracting and I think th= e time spent producing the memes would have been better spent capturing the= content of discussions during the working group.

I was unable to at= tend physically and the timezone delta made it difficult to attend virtuall= y. Looking at these notes as they exist presently hasn't given me much = understanding of the topics discussed. In the future could the WG consider = returning to plain old ASCII for meeting notes and sticking to the content = instead of punchlines?

=C2=A0<= /p>

Thanks!

=C2=A0

On Fri, = Jul 21, 2017 at 7:23 AM, Salz, Rich <rsalz@akamai.com> wrote:

Please take= a look at the minutes/memes and post corrections by the next week.

=C2=A0

Minute-taker gets to ch= oose if he accepts changed pictures or not J

=C2=A0

-= -=C2=A0

Senior Architect, Akamai Technologies

Member, OpenSSL Dev Team

= IM: richsalz@jabber= .at Twitter: RichSalz

=C2=A0

From: Richard Barnes [mailto:rlb@ipv.sx]
Sent: Friday, July 21, 2017 1= 1:02 AM
To: acme-chairs@tools.ietf.org
Subject: Memes

=C2=A0

<= /div>


______= _________________________________________
Acme mailing list
Acme@ietf.org
https://w= ww.ietf.org/mailman/listinfo/acme

=C2=A0


________________________________________= _______
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme<= /a>

=C2=A0

=C2= =A0


--001a113f9bb04ca7bb0554d59ac6-- From nobody Sat Jul 22 09:45:54 2017 Return-Path: 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 27CC7131B3A for ; Sat, 22 Jul 2017 09:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eO-W6He88TKu for ; Sat, 22 Jul 2017 09:45:50 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAFAC131667 for ; Sat, 22 Jul 2017 09:45:50 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v6MGfegu006318; Sat, 22 Jul 2017 17:45:47 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=lgTGv1vaNBIFqkQn+bV12boB2hHnxcyzty6oVBDqBfU=; b=aRsvaOHEKazWYvhfAfmJ/j3DjTb8TtIZWGXdv2s72+/RcxjxckmidU3oj2Kgxv55f9sv OkiSB/4kf1eBcv/91UUB5/GubLL/8PpcbfhkYNVhpVutcsT/mnugN2SYOq/QTBE8bEx3 YqUf2vtqE6mzrjY0n8k/OHrVTJ42KDYqp7IqfHVdQ9OHTOHtfyHbWyYCPy38inkUV2AJ MatREpdo1X93RX4LrkgjoWhiLqURJZrdg6GY+PuHVESRPCzovpLXkb+d5WbYzDvN1veu OaCLHejfB9y6dmi7W0wHlql4acGE2cT5/PQxdY7i0iVPUOMqU5qzGfLRv30doj7hlrau TQ== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2buy49sn4f-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 22 Jul 2017 17:45:47 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v6MGjkvq032227; Sat, 22 Jul 2017 12:45:46 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 2bv21u90b6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sat, 22 Jul 2017 12:45:46 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 22 Jul 2017 09:45:45 -0700 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Sat, 22 Jul 2017 12:45:45 -0400 From: "Salz, Rich" To: Richard Barnes , Daniel McCarney CC: "acme@ietf.org" Thread-Topic: [Acme] Minutes from IEtf 99 Thread-Index: AdMCE7AQtGH18UnpSrir5nm8k/ol8gAM5p0AAAA4xoAAMGiOEA== Date: Sat, 22 Jul 2017 16:45:44 +0000 Message-ID: <4cd04ca9dbc7423991c75898523cbe1a@usma1ex-dag1mb1.msg.corp.akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.45.210] Content-Type: multipart/alternative; boundary="_000_4cd04ca9dbc7423991c75898523cbe1ausma1exdag1mb1msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-22_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707220271 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-22_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707220270 Archived-At: Subject: Re: [Acme] Minutes from IEtf 99 X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jul 2017 16:45:53 -0000 --_000_4cd04ca9dbc7423991c75898523cbe1ausma1exdag1mb1msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmsgeW91IQ0KDQpTaW5jZSB0aGUgbWludXRlcyBmb3IgbW9zdCBXR+KAmXMgaGF2ZSBiZWNv bWUganVzdCBhIHJlY29yZCBvZiBhY3Rpb25zIGFuZCBodW1zLCBub3QgbXVjaCB3YXMgbWlzc2Vk LiAgQnV0IEkgYWdyZWUgdGhhdCB0aGUgam9rZSBoYXMgZ290dGVuIGEgbGl0dGxlIHN0YWxlIG5v dy4NCg0KQXBwcmVjaWF0ZSB0aGUgZmVlZGJhY2ssIERhbmllbCENCg0KLS0NClNlbmlvciBBcmNo aXRlY3QsIEFrYW1haSBUZWNobm9sb2dpZXMNCk1lbWJlciwgT3BlblNTTCBEZXYgVGVhbQ0KSU06 IHJpY2hzYWx6QGphYmJlci5hdCBUd2l0dGVyOiBSaWNoU2Fseg0KDQpGcm9tOiBSaWNoYXJkIEJh cm5lcyBbbWFpbHRvOnJsYkBpcHYuc3hdDQpTZW50OiBGcmlkYXksIEp1bHkgMjEsIDIwMTcgOToz OSBBTQ0KVG86IERhbmllbCBNY0Nhcm5leSA8Y3B1QGxldHNlbmNyeXB0Lm9yZz4NCkNjOiBhY21l QGlldGYub3JnOyBTYWx6LCBSaWNoIDxyc2FsekBha2FtYWkuY29tPg0KU3ViamVjdDogUmU6IFtB Y21lXSBNaW51dGVzIGZyb20gSUV0ZiA5OQ0KDQpPZiBjb3Vyc2UgeW91J3JlIHJpZ2h0LiAgIEkg YXBvbG9naXplLiAgSSB3aWxsIGdvIHRocm91Z2ggdGhlIGF1ZGlvIHJlY29yZGluZyBhbmQgcHJv ZHVjZSBzb21lIHByb3BlciBub3Rlcy4NCg0KT24gSnVsIDIxLCAyMDE3IDM6MzIgUE0sICJEYW5p ZWwgTWNDYXJuZXkiIDxjcHVAbGV0c2VuY3J5cHQub3JnPG1haWx0bzpjcHVAbGV0c2VuY3J5cHQu b3JnPj4gd3JvdGU6DQpJIHRoaW5rIHRoaXMgaXMgdGhlIHNlY29uZCB0aW1lIChpbiBteSBtZW1v cnkpIHRoZSBXRyBub3RlcyBoYXZlIGJlZW4gZGlzdHJpYnV0ZWQgaW4gIm1lbWUgZm9ybSIuIEF0 IHRoZSByaXNrIG9mIGJlaW5nIHRoZSBzdGljayBpbiB0aGUgbXVkIEkgd2FudCB0byBleHByZXNz IGFuIG9waW5pb24gdGhhdCAibWVtZSBub3RlcyIgYXJlIGRpc3RyYWN0aW5nIGFuZCBJIHRoaW5r IHRoZSB0aW1lIHNwZW50IHByb2R1Y2luZyB0aGUgbWVtZXMgd291bGQgaGF2ZSBiZWVuIGJldHRl ciBzcGVudCBjYXB0dXJpbmcgdGhlIGNvbnRlbnQgb2YgZGlzY3Vzc2lvbnMgZHVyaW5nIHRoZSB3 b3JraW5nIGdyb3VwLg0KDQpJIHdhcyB1bmFibGUgdG8gYXR0ZW5kIHBoeXNpY2FsbHkgYW5kIHRo ZSB0aW1lem9uZSBkZWx0YSBtYWRlIGl0IGRpZmZpY3VsdCB0byBhdHRlbmQgdmlydHVhbGx5LiBM b29raW5nIGF0IHRoZXNlIG5vdGVzIGFzIHRoZXkgZXhpc3QgcHJlc2VudGx5IGhhc24ndCBnaXZl biBtZSBtdWNoIHVuZGVyc3RhbmRpbmcgb2YgdGhlIHRvcGljcyBkaXNjdXNzZWQuIEluIHRoZSBm dXR1cmUgY291bGQgdGhlIFdHIGNvbnNpZGVyIHJldHVybmluZyB0byBwbGFpbiBvbGQgQVNDSUkg Zm9yIG1lZXRpbmcgbm90ZXMgYW5kIHN0aWNraW5nIHRvIHRoZSBjb250ZW50IGluc3RlYWQgb2Yg cHVuY2hsaW5lcz8NCg0KVGhhbmtzIQ0KDQpPbiBGcmksIEp1bCAyMSwgMjAxNyBhdCA3OjIzIEFN LCBTYWx6LCBSaWNoIDxyc2FsekBha2FtYWkuY29tPG1haWx0bzpyc2FsekBha2FtYWkuY29tPj4g d3JvdGU6DQpQbGVhc2UgdGFrZSBhIGxvb2sgYXQgdGhlIG1pbnV0ZXMvbWVtZXMgYW5kIHBvc3Qg Y29ycmVjdGlvbnMgYnkgdGhlIG5leHQgd2Vlay4NCg0KTWludXRlLXRha2VyIGdldHMgdG8gY2hv b3NlIGlmIGhlIGFjY2VwdHMgY2hhbmdlZCBwaWN0dXJlcyBvciBub3Qg4pi6DQoNCi0tDQpTZW5p b3IgQXJjaGl0ZWN0LCBBa2FtYWkgVGVjaG5vbG9naWVzDQpNZW1iZXIsIE9wZW5TU0wgRGV2IFRl YW0NCklNOiByaWNoc2FsekBqYWJiZXIuYXQ8bWFpbHRvOnJpY2hzYWx6QGphYmJlci5hdD4gVHdp dHRlcjogUmljaFNhbHoNCg0KRnJvbTogUmljaGFyZCBCYXJuZXMgW21haWx0bzpybGJAaXB2LnN4 PG1haWx0bzpybGJAaXB2LnN4Pl0NClNlbnQ6IEZyaWRheSwgSnVseSAyMSwgMjAxNyAxMTowMiBB TQ0KVG86IGFjbWUtY2hhaXJzQHRvb2xzLmlldGYub3JnPG1haWx0bzphY21lLWNoYWlyc0B0b29s cy5pZXRmLm9yZz4NClN1YmplY3Q6IE1lbWVzDQoNCmh0dHBzOi8vZG9jcy5nb29nbGUuY29tL2Rv Y3VtZW50L2QvMTh6QjNaaVBHcHFVaTIzcUItVHdXRDgycmQ3UWR3RENvNVdOZmtYNDFhZTgvZWRp dDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX2Rv Y3MuZ29vZ2xlLmNvbV9kb2N1bWVudF9kXzE4ekIzWmlQR3BxVWkyM3FCLTJEVHdXRDgycmQ3UWR3 RENvNVdOZmtYNDFhZThfZWRpdCZkPUR3TUJhUSZjPTk2WmJaWmNhTUY0dzBGNGpwTjZMWmcmcj00 TE0wR2JSMGg5RnZ4ODZGdHNLSS13Jm09YXJrY1hQYkNfNi02Y2xneDY0eHhCT2h6Q1J4UUFtN0NB UW5XdFFYN0JPUSZzPXFZVzlBX2ppdDJHSGxwMVVwZ1NJZVFTTTlKSE8tbWo4ZWtQekVQZW5lOU0m ZT0+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpB Y21lIG1haWxpbmcgbGlzdA0KQWNtZUBpZXRmLm9yZzxtYWlsdG86QWNtZUBpZXRmLm9yZz4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNtZTxodHRwczovL3VybGRlZmVu c2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFu X2xpc3RpbmZvX2FjbWUmZD1Ed01GYVEmYz05NlpiWlpjYU1GNHcwRjRqcE42TFpnJnI9NExNMEdi UjBoOUZ2eDg2RnRzS0ktdyZtPVpQZWIzcU1LNzc3eE56MmJHRlo4ai0taGNFZkF1T05sVXl0a25x eDJYMGMmcz1JUHMyanZXdDhzZGRqcFUxcTdyMFZxNmoySHk1U19WZV9Zam0yWWxMd2NvJmU9Pg0K DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpBY21l IG1haWxpbmcgbGlzdA0KQWNtZUBpZXRmLm9yZzxtYWlsdG86QWNtZUBpZXRmLm9yZz4NCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNtZTxodHRwczovL3VybGRlZmVuc2Uu cHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xp c3RpbmZvX2FjbWUmZD1Ed01GYVEmYz05NlpiWlpjYU1GNHcwRjRqcE42TFpnJnI9NExNMEdiUjBo OUZ2eDg2RnRzS0ktdyZtPVpQZWIzcU1LNzc3eE56MmJHRlo4ai0taGNFZkF1T05sVXl0a25xeDJY MGMmcz1JUHMyanZXdDhzZGRqcFUxcTdyMFZxNmoySHk1U19WZV9Zam0yWWxMd2NvJmU9Pg0K --_000_4cd04ca9dbc7423991c75898523cbe1ausma1exdag1mb1msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bh bi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VGhhbmsgeW91ITxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5TaW5jZSB0aGUgbWludXRlcyBmb3IgbW9zdCBXR+KAmXMgaGF2ZSBiZWNvbWUganVzdCBh IHJlY29yZCBvZiBhY3Rpb25zIGFuZCBodW1zLCBub3QgbXVjaCB3YXMgbWlzc2VkLiZuYnNwOyBC dXQgSSBhZ3JlZSB0aGF0IHRoZSBqb2tlIGhhcyBnb3R0ZW4gYSBsaXR0bGUgc3RhbGUgbm93Ljxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5BcHByZWNpYXRlIHRoZSBmZWVkYmFjaywgRGFuaWVsITxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj4tLSZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj5TZW5pb3IgQXJjaGl0ZWN0LCBBa2FtYWkgVGVjaG5vbG9naWVz PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5NZW1iZXIsIE9wZW5TU0wgRGV2IFRlYW08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPklNOiByaWNoc2FsekBqYWJiZXIuYXQg VHdpdHRlcjogUmljaFNhbHo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzow aW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj4gUmljaGFyZCBCYXJuZXMgW21haWx0bzpybGJAaXB2LnN4XQ0KPGJyPg0K PGI+U2VudDo8L2I+IEZyaWRheSwgSnVseSAyMSwgMjAxNyA5OjM5IEFNPGJyPg0KPGI+VG86PC9i PiBEYW5pZWwgTWNDYXJuZXkgJmx0O2NwdUBsZXRzZW5jcnlwdC5vcmcmZ3Q7PGJyPg0KPGI+Q2M6 PC9iPiBhY21lQGlldGYub3JnOyBTYWx6LCBSaWNoICZsdDtyc2FsekBha2FtYWkuY29tJmd0Ozxi cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0FjbWVdIE1pbnV0ZXMgZnJvbSBJRXRmIDk5PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9mIGNvdXJz ZSB5b3UncmUgcmlnaHQuICZuYnNwOyBJIGFwb2xvZ2l6ZS4mbmJzcDsgSSB3aWxsIGdvIHRocm91 Z2ggdGhlIGF1ZGlvIHJlY29yZGluZyBhbmQgcHJvZHVjZSBzb21lIHByb3BlciBub3Rlcy4gJm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBKdWwg MjEsIDIwMTcgMzozMiBQTSwgJnF1b3Q7RGFuaWVsIE1jQ2FybmV5JnF1b3Q7ICZsdDs8YSBocmVm PSJtYWlsdG86Y3B1QGxldHNlbmNyeXB0Lm9yZyI+Y3B1QGxldHNlbmNyeXB0Lm9yZzwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JIHRoaW5rIHRoaXMgaXMgdGhlIHNlY29uZCB0aW1lIChpbiBteSBtZW1vcnkpIHRo ZSBXRyBub3RlcyBoYXZlIGJlZW4gZGlzdHJpYnV0ZWQgaW4gJnF1b3Q7bWVtZSBmb3JtJnF1b3Q7 LiBBdCB0aGUgcmlzayBvZiBiZWluZyB0aGUgc3RpY2sgaW4gdGhlIG11ZCBJIHdhbnQgdG8gZXhw cmVzcyBhbiBvcGluaW9uIHRoYXQgJnF1b3Q7bWVtZSBub3RlcyZxdW90OyBhcmUgZGlzdHJhY3Rp bmcgYW5kIEkgdGhpbmsgdGhlIHRpbWUgc3BlbnQgcHJvZHVjaW5nDQogdGhlIG1lbWVzIHdvdWxk IGhhdmUgYmVlbiBiZXR0ZXIgc3BlbnQgY2FwdHVyaW5nIHRoZSBjb250ZW50IG9mIGRpc2N1c3Np b25zIGR1cmluZyB0aGUgd29ya2luZyBncm91cC48YnI+DQo8YnI+DQpJIHdhcyB1bmFibGUgdG8g YXR0ZW5kIHBoeXNpY2FsbHkgYW5kIHRoZSB0aW1lem9uZSBkZWx0YSBtYWRlIGl0IGRpZmZpY3Vs dCB0byBhdHRlbmQgdmlydHVhbGx5LiBMb29raW5nIGF0IHRoZXNlIG5vdGVzIGFzIHRoZXkgZXhp c3QgcHJlc2VudGx5IGhhc24ndCBnaXZlbiBtZSBtdWNoIHVuZGVyc3RhbmRpbmcgb2YgdGhlIHRv cGljcyBkaXNjdXNzZWQuIEluIHRoZSBmdXR1cmUgY291bGQgdGhlIFdHIGNvbnNpZGVyIHJldHVy bmluZyB0byBwbGFpbg0KIG9sZCBBU0NJSSBmb3IgbWVldGluZyBub3RlcyBhbmQgc3RpY2tpbmcg dG8gdGhlIGNvbnRlbnQgaW5zdGVhZCBvZiBwdW5jaGxpbmVzPzxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzITxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGcmksIEp1bCAyMSwgMjAxNyBhdCA3 OjIzIEFNLCBTYWx6LCBSaWNoICZsdDs8YSBocmVmPSJtYWlsdG86cnNhbHpAYWthbWFpLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPnJzYWx6QGFrYW1haS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5QbGVhc2UgdGFrZSBhIGxvb2sgYXQgdGhlIG1pbnV0ZXMvbWVtZXMg YW5kIHBvc3QgY29ycmVjdGlvbnMgYnkgdGhlIG5leHQgd2Vlay48L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi Pk1pbnV0ZS10YWtlciBnZXRzIHRvIGNob29zZSBpZiBoZSBhY2NlcHRzIGNoYW5nZWQgcGljdHVy ZXMgb3Igbm90DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6V2luZ2RpbmdzIj5KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4tLSZuYnNwOw0KPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlNlbmlv ciBBcmNoaXRlY3QsIEFrYW1haSBUZWNobm9sb2dpZXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+TWVtYmVyLCBPcGVuU1NMIERl diBUZWFtPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPklNOg0KPGEgaHJlZj0ibWFpbHRvOnJpY2hzYWx6QGphYmJlci5hdCIgdGFy Z2V0PSJfYmxhbmsiPnJpY2hzYWx6QGphYmJlci5hdDwvYT4gVHdpdHRlcjogUmljaFNhbHo8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBSaWNo YXJkIEJhcm5lcyBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpybGJAaXB2LnN4IiB0YXJnZXQ9Il9i bGFuayI+cmxiQGlwdi5zeDwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBKdWx5IDIx LCAyMDE3IDExOjAyIEFNPGJyPg0KPGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86YWNtZS1jaGFp cnNAdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5hY21lLWNoYWlyc0B0b29scy5pZXRm Lm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gTWVtZXM8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9p bnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19kb2NzLmdvb2dsZS5jb21fZG9jdW1lbnRfZF8xOHpC M1ppUEdwcVVpMjNxQi0yRFR3V0Q4MnJkN1Fkd0RDbzVXTmZrWDQxYWU4X2VkaXQmYW1wO2Q9RHdN QmFRJmFtcDtjPTk2WmJaWmNhTUY0dzBGNGpwTjZMWmcmYW1wO3I9NExNMEdiUjBoOUZ2eDg2RnRz S0ktdyZhbXA7bT1hcmtjWFBiQ182LTZjbGd4NjR4eEJPaHpDUnhRQW03Q0FRbld0UVg3Qk9RJmFt cDtzPXFZVzlBX2ppdDJHSGxwMVVwZ1NJZVFTTTlKSE8tbWo4ZWtQekVQZW5lOU0mYW1wO2U9IiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kb2NzLmdvb2dsZS5jb20vZG9jdW1lbnQvZC8xOHpCM1pp UEdwcVVpMjNxQi1Ud1dEODJyZDdRZHdEQ281V05ma1g0MWFlOC9lZGl0PC9hPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCkFjbWUgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0i bWFpbHRvOkFjbWVAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5BY21lQGlldGYub3JnPC9hPjxi cj4NCjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1o dHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fYWNtZSZhbXA7ZD1Ed01GYVEm YW1wO2M9OTZaYlpaY2FNRjR3MEY0anBONkxaZyZhbXA7cj00TE0wR2JSMGg5RnZ4ODZGdHNLSS13 JmFtcDttPVpQZWIzcU1LNzc3eE56MmJHRlo4ai0taGNFZkF1T05sVXl0a25xeDJYMGMmYW1wO3M9 SVBzMmp2V3Q4c2RkanBVMXE3cjBWcTZqMkh5NVNfVmVfWWptMllsTHdjbyZhbXA7ZT0iIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FjbWU8L2E+ PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KQWNtZSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBo cmVmPSJtYWlsdG86QWNtZUBpZXRmLm9yZyI+QWNtZUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVm PSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3 dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2FjbWUmYW1wO2Q9RHdNRmFRJmFtcDtjPTk2WmJa WmNhTUY0dzBGNGpwTjZMWmcmYW1wO3I9NExNMEdiUjBoOUZ2eDg2RnRzS0ktdyZhbXA7bT1aUGVi M3FNSzc3N3hOejJiR0ZaOGotLWhjRWZBdU9ObFV5dGtucXgyWDBjJmFtcDtzPUlQczJqdld0OHNk ZGpwVTFxN3IwVnE2ajJIeTVTX1ZlX1lqbTJZbEx3Y28mYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hY21lPC9hPjxvOnA+PC9vOnA+ PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_4cd04ca9dbc7423991c75898523cbe1ausma1exdag1mb1msgcorpak_-- From nobody Fri Jul 28 10:01:31 2017 Return-Path: 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 869DF132172 for ; Fri, 28 Jul 2017 10:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.002 X-Spam-Level: X-Spam-Status: No, score=-7.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org 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 33yAjQBGXlUy for ; Fri, 28 Jul 2017 10:01:28 -0700 (PDT) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3516131CDD for ; Fri, 28 Jul 2017 10:01:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:References:Cc:To:From:Subject; bh=pHrhBqVoNX/i4SIC3aC0krIWZnHViThffD+ia08Am7g=; b=CSRgxnSbfVqgsfREPCliPWbkNlYG1ogYD301uTV0Sp+set2NNMflAckbOvhbWITwWJSIfyx4m+9dXM4ZRjuddzVNFOBMjdZRD/vBkssDQukCYxxqi7Bq/te2rQD58/+w7uPcnCm0iACZqEaLNI7xD7q8yYTHttC+SQTCyI4iV7A=; Received: ; Fri, 28 Jul 2017 10:01:25 -0700 From: Jacob Hoffman-Andrews To: Richard Barnes Cc: "Salz, Rich" , Ilari Liusvaara , "acme@ietf.org" , "Dunning, John" References: <0896b144e7e942b1ac68db9ead4c42bb@usma1ex-dag1mb1.msg.corp.akamai.com> <20170619184423.wtpj2qtq6awk3rju@LK-Perkele-VII> <53c76454-56ac-dde7-6cf8-94a6e39a89fc@eff.org> <30977E7E-FD36-4FB1-A7CF-1390095E1EB2@akamai.com> <76e97edb-f652-02e4-b05b-c8ad6b5f89fc@eff.org> <8fa19fb2-6298-e882-1d23-3a409abaa247@eff.org> Message-ID: Date: Fri, 28 Jul 2017 10:01:26 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <8fa19fb2-6298-e882-1d23-3a409abaa247@eff.org> Content-Type: multipart/alternative; boundary="------------D3B0ACCC3590AC5F8245DF23" Content-Language: en-US Archived-At: Subject: Re: [Acme] Rolling keys and pending validations X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 17:01:30 -0000 This is a multi-part message in MIME format. --------------D3B0ACCC3590AC5F8245DF23 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Any further thoughts on whether keyAuthorizations should be bound at challenge creation time vs challenge submission time? On 07/07/2017 03:09 PM, Jacob Hoffman-Andrews wrote: > On 07/07/2017 12:35 PM, Richard Barnes wrote: >> Whether clients will notice depends on how we change the syntax to >> express the "binding". You seem to be assuming that we'll keep the >> syntax the same. That would mean that the server would note the >> keyAuthorization to be used with the challenge at creation time, in a >> way that's invisible to the client > Yep, I am assuming we'll keep the syntax the same. I don't see a > reason to change. >> So you'll break clients in the following scenario: >> >> 1. Server creates challenge bound to keyAuthorization_oldkey, sends >> to client >> 2. Client rolls keys >> 3. Client computes keyAuthorization_newkey >> 4. Client provisions the validation response with keyAuthorization_newkey >> 5. Client sends keyAuthorization_newkey in a response to the >> challenge, signed with newkey > Yep, this was the scenario I was describing when I said: > > > It only makes a different when key rollover and long-term pending > challenges are in > play, which is pretty uncommon. > > Thanks for spelling it out in more detail, that makes it clearer. > Essentially, I am saying that it is very rare for clients to hold onto > pending authorizations while rolling keys. The most common clients > (Cerbot, dehydrated, lego, etc) treat "get authorization; provision > validation response; request validation" as a single automated steps, > taking seconds or minutes. Those clients generally don't keep > authorizations around between runs, and would be rotating keys between > runs. So no problem. > > The only clients that would have to change are those that (a) cannot > be fully automated, and therefore hold onto pending authorizations for > days, and (b) rotate their keys regularly. As far as I'm aware, Akamai > is the only client doing that, and they are the ones asking for "bind > at creation time." I believe that most other clients would not notice > a difference. > > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme --------------D3B0ACCC3590AC5F8245DF23 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Any further thoughts on whether keyAuthorizations should be bound at challenge creation time vs challenge submission time?

On 07/07/2017 03:09 PM, Jacob Hoffman-Andrews wrote:
On 07/07/2017 12:35 PM, Richard Barnes wrote:
Whether clients will notice depends on how we change the syntax to express the "binding".  You seem to be assuming that we'll keep the syntax the same.  That would mean that the server would note the keyAuthorization to be used with the challenge at creation time, in a way that's invisible to the client
Yep, I am assuming we'll keep the syntax the same. I don't see a reason to change.
So you'll break clients in the following scenario:

1. Server creates challenge bound to keyAuthorization_oldkey, sends to client
2. Client rolls keys
3. Client computes keyAuthorization_newkey
4. Client provisions the validation response with keyAuthorization_newkey
5. Client sends keyAuthorization_newkey in a response to the challenge, signed with newkey
Yep, this was the scenario I was describing when I said:

> It only makes a different when key rollover and long-term pending challenges are in
play, which is pretty uncommon.

Thanks for spelling it out in more detail, that makes it clearer. Essentially, I am saying that it is very rare for clients to hold onto pending authorizations while rolling keys. The most common clients (Cerbot, dehydrated, lego, etc) treat "get authorization; provision validation response; request validation" as a single automated steps, taking seconds or minutes. Those clients generally don't keep authorizations around between runs, and would be rotating keys between runs. So no problem.

The only clients that would have to change are those that (a) cannot be fully automated, and therefore hold onto pending authorizations for days, and (b) rotate their keys regularly. As far as I'm aware, Akamai is the only client doing that, and they are the ones asking for "bind at creation time." I believe that most other clients would not notice a difference.


_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

--------------D3B0ACCC3590AC5F8245DF23-- From nobody Mon Jul 31 11:26:18 2017 Return-Path: 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 4470B132751 for ; Mon, 31 Jul 2017 11:26:16 -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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DqR38DtXNI2T for ; Mon, 31 Jul 2017 11:26:14 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC655127869 for ; Mon, 31 Jul 2017 11:26:14 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v6VIMsms011930 for ; Mon, 31 Jul 2017 19:26:12 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : mime-version; s=jan2016.eng; bh=fSpwm8rkCO7ceFff/mk2SGO53OunE3stpMvLmjtVe3k=; b=bOYHt+SeihfYv9yXFNGgJrxkFORTtStgAo6PQSvW78OKOhi0s+s7XQD24axocB/cwxxo 4bl2zrlZ3+loVAbDlS1Ngz/x2C/ebo0d+ZKRc5EBjADtRKDUy6yBe+aQ9ICedC9BY+Da 0N2tcRtgYNhb8jUaa/W7Zec7KnEurgQucF1akT+Aw0YbDwEmAoH8VWZzP1HBB3QvkVFE xivgP+E7jxWuYl1j5W4TossEFpoHgnGkxR/6QZW87e4y8M2Ymp8+HHGHhnFCsMVRZV5s xXcWQrxi1fk91LuRzoD9L0a4VICeMTiP7MluDfS/xg9vM7uucxhMJVnzHmdr5gO3PZ6F vQ== Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2c0fecbdfd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 31 Jul 2017 19:26:12 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v6VILLJI010228 for ; Mon, 31 Jul 2017 14:26:12 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint1.akamai.com with ESMTP id 2c0npuqmm1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Mon, 31 Jul 2017 14:26:11 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 31 Jul 2017 14:26:11 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Mon, 31 Jul 2017 14:26:11 -0400 From: "Salz, Rich" To: "acme@ietf.org" Thread-Topic: Confirming consensus Thread-Index: AdMKKkoHzSzwePSMQ4+5Rw2Wd9fJPA== Date: Mon, 31 Jul 2017 18:26:11 +0000 Message-ID: <9fe1aaf940f14b50b2505424b1f0d340@usma1ex-dag1mb1.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.34.207] Content-Type: multipart/alternative; boundary="_000_9fe1aaf940f14b50b2505424b1f0d340usma1exdag1mb1msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-31_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707310308 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-31_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707310308 Archived-At: Subject: [Acme] Confirming consensus X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 18:26:16 -0000 --_000_9fe1aaf940f14b50b2505424b1f0d340usma1exdag1mb1msgcorpak_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At the IETF last week we had unanimous consensus to change the CAA draft so= that it used the term "validation-methods" and not "acme-methods" Does anyone disagree? Please speak up in the next couple of days if you do= not agree. -- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richsalz@jabber.at Twitter: RichSalz --_000_9fe1aaf940f14b50b2505424b1f0d340usma1exdag1mb1msgcorpak_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

At the IETF last week we had unanimous consensus to = change the CAA draft so that it used the term “validation-methodsR= 21; and not “acme-methods”

 

Does anyone disagree?  Please speak up in the n= ext couple of days if you do not agree.

 

 

-- 

Senior Architect, Akamai Technologies

Member, OpenSSL Dev Team

IM: richsalz@jabber.at Twitter: RichSalz<= /p>

 

--_000_9fe1aaf940f14b50b2505424b1f0d340usma1exdag1mb1msgcorpak_--