From nobody Fri Mar 3 04:12:03 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 B9BFE12984B for ; Fri, 3 Mar 2017 04:12:01 -0800 (PST) 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=azet.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 CPxBl5nDX73k for ; Fri, 3 Mar 2017 04:12:00 -0800 (PST) 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 E101C12984A for ; Fri, 3 Mar 2017 04:11:59 -0800 (PST) Received: by mail-wm0-x229.google.com with SMTP id i17so7842171wmf.0 for ; Fri, 03 Mar 2017 04:11:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=IJKXxPMyOI3Ds4Ei4/ZxyQs7jpNa939FVx8SxUIpFv4=; b=Dc4TpIEf9QpUiYkb2lUBcN+UMDFdSOWsNevezvucSBbTJmaw44VsZs6DpCmcjey6sO 6hPpSLisVnvptNEB2qZUahzDTC4sXv/U72UnwdaEy3xm8tXF102P4zAL70A0R8yTZ24e +N6sFHTvPWuwZKr2mf4vi/iyLZaZvualZ8hU8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=IJKXxPMyOI3Ds4Ei4/ZxyQs7jpNa939FVx8SxUIpFv4=; b=X0uxde0I4kDh73I78Z+CvCNYLgUcMcgKx4qqXaESmN2/e/2hbyzxdrLA2CcHYpnfBr YrzAJOGrODMKOcU3u9yXMfuX8PHvRNU3PKzFNALEoTM/3cTwGfDPYUewsq3pvYpVQomp k6nWZ1tEGpIaDgWsyKwBk42557uBUYsRRBICoKxERjg53ho629IgqT0lMh0ZghEpfeKw 3fvNCD1AbEajCkvYGxMCQ9/QmvHJbSExBrR2cJKrVyOAPQZezaJsIlxDqxM/acx8CBB1 0Pb0GNACE6PkKB9/2TcMC7h3uC6XWhTSPGE9FxCShcJkZCYoJdb/78ZjXMetkvKQiTt7 51Bw== X-Gm-Message-State: AMke39mM0ob9u96KBExcLv6I/bglQ6FrOczbq4vQdSBvnyEFwZARp5imNxhwyhJg/kumhQ== X-Received: by 10.28.47.7 with SMTP id v7mr2624574wmv.138.1488543118372; Fri, 03 Mar 2017 04:11:58 -0800 (PST) Received: from [192.168.1.120] ([41.141.101.73]) by smtp.gmail.com with ESMTPSA id u198sm2842629wmf.9.2017.03.03.04.11.55 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 03 Mar 2017 04:11:57 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_31F0B4FE-6FA6-4034-BCA0-2FA5D8F7E979"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Aaron Zauner In-Reply-To: <81377754-e24d-269d-0f48-ba37e55f8942@eff.org> Date: Fri, 3 Mar 2017 11:53:49 +0000 Message-Id: <22DB918C-015D-48C8-9A5E-1D4BDC57DC84@azet.org> References: <81377754-e24d-269d-0f48-ba37e55f8942@eff.org> To: Jacob Hoffman-Andrews X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "acme@ietf.org" , Martin Thomson Subject: Re: [Acme] HPKP in ACME X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 12:12:02 -0000 --Apple-Mail=_31F0B4FE-6FA6-4034-BCA0-2FA5D8F7E979 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 13 Feb 2017, at 19:33, Jacob Hoffman-Andrews wrote: >=20 > Martin brought up a section I've been considering removing: >=20 >> Clients SHOULD support HTTP public key pinning [RFC7469], and servers > SHOULD emit pinning headers. >=20 > Here's my reasoning: >=20 > - Public key pinning isn't implemented in most HTTPS libraries outside > of browsers, so this is a considerable burden on implementers. > - Public key pinning carries a fairly high risk of footgunning. The > consequence of a failed pin for a CA that serves many ACME clients = would > be that some of those clients would fail to renew their certs, causing > cascading breakage. > - There is relatively little confidential information conveyed in = ACME, > and there are other defenses built into ACME (like including the = account > key as part of the challenge data), so HPKP is not strongly necessary. >=20 > Any objections? I was the person who initially suggested adding HPKP, that was more than = two years ago. People get HPKP headers wrong constantly and thus lock = themselves or their users out of services, missing library support is - = as you point out - a problem and I don't see much interest within the = community to add HPKP. By now I consider HPKP failed tech. to be honest. +1 on removing the section entirely. Aaron >=20 > PR to remove: https://github.com/ietf-wg-acme/acme/pull/244 >=20 > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme --Apple-Mail=_31F0B4FE-6FA6-4034-BCA0-2FA5D8F7E979 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYuVlNAAoJEOTbZJL9ubXV7zUP/A1v75BwK/NnrPIccv8F5tb5 lFRy3r3ZdxGmep3TIS/W/8VR1PPrHVvh4jVuRCFTuShGx1eTjFNY32YqfuOTiQEr L8QOrghYqB11Rw3gvSi61ayKW2WshaYIJw4Nr0jeAQzPt5jxxyBoulilF6R1p4wy hYK3SfeW7swPaadXJ8EUE0FoGui9/ZCDQDOI5p3EEtk6R5fBdTstVeDirUao4ewM EMwy32r2cLV6/hmqMd+RLlSEVVZr18tF2C4QlH1vW6XwmiP2PdWuD7KRlPv+lXqk Og2zYp2oCAPBBzAzVwGJbjZMUe9CSJAUzvXQYCHlOYnWJtE66QJ85IYqGct1mxUJ EI5yl2vZhi6yO7cTdOXP7vq+yg8sPZr1ftUh4GIxCg/Y4xRRGOqEJhnwWxof2p0q MtmwETdpYFSHuwQtFzojZI8I5SRVXppwTGFWtB8FYkQ1SS1yyU3B3qtNnCnapt7Q n6c7Spz9dwqYLVxpfuP5BEiYg8DSfP5/B5DTOpA94VsxnHESfKUP+Aqgvzsd27ZW nt9l4DL5bAhdROc4GNtEjK+L3+FTL1AW8QpNI3RpO7jCe/CXRHCKN04V+zBbglrY YN4zfvpEE/0F+z8u4DizfJbLeL+SPMtLC5LrAkIL1GFO4/y+NtedURjmA+uGWOe2 pAyT9aaILLl6TjkI3FDS =9BAE -----END PGP SIGNATURE----- --Apple-Mail=_31F0B4FE-6FA6-4034-BCA0-2FA5D8F7E979-- From nobody Fri Mar 3 14:25: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 3E315129642 for ; Fri, 3 Mar 2017 14:25:08 -0800 (PST) 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, RCVD_IN_MSPIKE_H2=-0.001, 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 XKJRGvGRhNoD for ; Fri, 3 Mar 2017 14:25:05 -0800 (PST) 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 EF244129644 for ; Fri, 3 Mar 2017 14:25:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Sender:In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=/kwXv5nmqbQfrVmXqbQcgvMlYoHZSBDTUX4F5OeNB3I=; b=0JgOhhbMbAg4q4CFESKmKSWrMGuKvbA90HHcH//w/ffOpJdVNXw8Xbnbx80uDKaBRz0OMb+iYTiZ11KTwMBGCLKAC9X8+hSWFnwxjJlyXQ92eRhdJzSxn9IM4Q5xjjzpwElKu8AEL4zSoq6Yf4kWsqqjm5viqCFWG/TNldOeIzM=; Received: ; Fri, 03 Mar 2017 14:25:06 -0800 Date: Fri, 3 Mar 2017 14:25:02 -0800 From: Peter Eckersley To: Aaron Zauner Message-ID: <20170303222502.GD31407@eff.org> References: <81377754-e24d-269d-0f48-ba37e55f8942@eff.org> <22DB918C-015D-48C8-9A5E-1D4BDC57DC84@azet.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <22DB918C-015D-48C8-9A5E-1D4BDC57DC84@azet.org> Sender: pde@eff.org User-Agent: Mutt/1.5.24 (2015-08-30) Received-SPF: skipped for local relay Archived-At: Cc: "acme@ietf.org" , Martin Thomson , Jacob Hoffman-Andrews Subject: Re: [Acme] HPKP in ACME X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 22:25:08 -0000 On Fri, Mar 03, 2017 at 11:53:49AM +0000, Aaron Zauner wrote: > > > On 13 Feb 2017, at 19:33, Jacob Hoffman-Andrews wrote: > > > > Martin brought up a section I've been considering removing: > > > >> Clients SHOULD support HTTP public key pinning [RFC7469], and servers > > SHOULD emit pinning headers. > > > > Here's my reasoning: > > > > - Public key pinning isn't implemented in most HTTPS libraries outside > > of browsers, so this is a considerable burden on implementers. > > - Public key pinning carries a fairly high risk of footgunning. The > > consequence of a failed pin for a CA that serves many ACME clients would > > be that some of those clients would fail to renew their certs, causing > > cascading breakage. > > - There is relatively little confidential information conveyed in ACME, > > and there are other defenses built into ACME (like including the account > > key as part of the challenge data), so HPKP is not strongly necessary. > > > > Any objections? > > I was the person who initially suggested adding HPKP, that was more than two > years ago. People get HPKP headers wrong constantly and thus lock themselves > or their users out of services, missing library support is - as you point > out - a problem and I don't see much interest within the community to add > HPKP. By now I consider HPKP failed tech. to be honest. I don't think we should give up on HPKP completely just yet; the thing that's missing for site operators is a better toolchain for getting it right that protects against errors by humans in the loop. As for how much it's useful for ACME itself -- I think the big gating variable would be getting better support for it into various languages' HTTP libraries. It would make sense to have it built into Go, Python's requests module, etc. If that happened, ACME servers SHOULD use it. It probably doesn't make sense for ACME clients to be trying to bolt their own HPKP logic onto their language's HTTP library. I'm agnostic about whether the wording should be struck from the draft or changed to be "clients SHOULD support HTTP public key pinning if the libraries they depend on can provide it". -- Peter Eckersley pde@eff.org Chief Computer Scientist Tel +1 415 436 9333 x131 Electronic Frontier Foundation Fax +1 415 436 9993 From nobody Fri Mar 3 16:04:01 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 613B9129A88; Fri, 3 Mar 2017 15:55:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148858534039.15846.12474188555403349294.idtracker@ietfa.amsl.com> Date: Fri, 03 Mar 2017 15:55:40 -0800 Archived-At: Cc: Kathleen.Moriarty.ietf@gmail.com, acme@ietf.org Subject: [Acme] acme - Requested session has been scheduled for IETF 98 X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.17 List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 23:55:40 -0000 Dear Ted Hardie, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. acme Session 1 (2:00:00) Thursday, Afternoon Session I 1300-1500 Room Name: Zurich G size: 115 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Automated Certificate Management Environment Area Name: Security Area Session Requester: Ted Hardie Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 80 Conflicts to Avoid: First Priority: httpauth httpbis sidr rtcweb tls perc Second Priority: dprive tcpinc uta dispatch netvc cfrg ace Third Priority: maprg hrpc irtfopen opsec People who must be present: Eric Rescorla Rich Salz Stephen Farrell Kathleen Moriarty Martin Thomson Richard Barnes Ted Hardie Resources Requested: Meetecho support in room Special Requests: --------------------------------------------------------- From nobody Sat Mar 4 03:26: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 3010712942F for ; Sat, 4 Mar 2017 03:26:10 -0800 (PST) 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=azet.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 HCNKLa_6I84o for ; Sat, 4 Mar 2017 03:26:09 -0800 (PST) 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 07DEF129459 for ; Sat, 4 Mar 2017 03:26:08 -0800 (PST) Received: by mail-wr0-x233.google.com with SMTP id l37so88673781wrc.1 for ; Sat, 04 Mar 2017 03:26:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=c667+XbU+2n9o78CHU+Jzf8qRgcepO6KDHD3/sWWHac=; b=GErAETRe2N9Yk77dl0KJkE4MPZx65zU8rhPFsiCWUI/iRWJEacddFMGODh2faxjFZt rPE7QK4D/1EaNyWigj0W/PnWodCiYArK6focxlFB7ZnX84aFMyfGb2GjRxFgS8gzgXJu gWdqUUleR9a80dbSZSr34DEOE4uNCYEJ0L9tE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=c667+XbU+2n9o78CHU+Jzf8qRgcepO6KDHD3/sWWHac=; b=OnjhdcNeOis6m8zwDB+6cNk4xflUKuEz7QLywex2yEAPUph0kHD8koGI+Dw2UvZqCA K1lbgUam0I1zEBRq4D69rvJ2MoXbmFoor9wfnGK5ZnxX7A7zTy+RiakigiW8vInkSRBO S8H3szEQO7i/FS5IxlVYD2f+JrDEBWWmZzdJ4U9Q7/7sHrY7Spsp7DtZJqeg3rz2ncZI fQeVuLwY9QWIfuJuJIgotj8rSmO2rpVMVnyloQXEeRf75AQpBLwdcYhCR48Ilca9+vGb DKvazd9cxH4rUO070U0TNgkA+iorqQDjC0LynWcythwQzAnhJ94YsxTl+vV+T7xgLENk tYeA== X-Gm-Message-State: AMke39mEK/Shy2ke0Bn9Yj3MnnjFq3RbMcp0UkqxKEOoSe5tfA4QCkFRjVT1Y8/wqmiLXg== X-Received: by 10.223.134.157 with SMTP id 29mr6388216wrx.33.1488626766494; Sat, 04 Mar 2017 03:26:06 -0800 (PST) Received: from [192.168.1.165] ([41.141.97.81]) by smtp.gmail.com with ESMTPSA id 10sm18838459wrw.13.2017.03.04.03.25.50 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 04 Mar 2017 03:26:05 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_350CBD97-1DBD-4F2A-99CC-D71E3DF4D863"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Aaron Zauner In-Reply-To: <20170303222502.GD31407@eff.org> Date: Sat, 4 Mar 2017 11:24:36 +0000 Message-Id: <4816CEB7-A2A6-4DA2-800B-EBEFE8B3472F@azet.org> References: <81377754-e24d-269d-0f48-ba37e55f8942@eff.org> <22DB918C-015D-48C8-9A5E-1D4BDC57DC84@azet.org> <20170303222502.GD31407@eff.org> To: Peter Eckersley X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "acme@ietf.org" , Martin Thomson , Jacob Hoffman-Andrews Subject: Re: [Acme] HPKP in ACME X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Mar 2017 11:26:10 -0000 --Apple-Mail=_350CBD97-1DBD-4F2A-99CC-D71E3DF4D863 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 03 Mar 2017, at 22:25, Peter Eckersley wrote: >=20 > On Fri, Mar 03, 2017 at 11:53:49AM +0000, Aaron Zauner wrote: >>=20 >>> On 13 Feb 2017, at 19:33, Jacob Hoffman-Andrews = wrote: >>>=20 >>> Martin brought up a section I've been considering removing: >>>=20 >>>> Clients SHOULD support HTTP public key pinning [RFC7469], and = servers >>> SHOULD emit pinning headers. >>>=20 >>> Here's my reasoning: >>>=20 >>> - Public key pinning isn't implemented in most HTTPS libraries = outside >>> of browsers, so this is a considerable burden on implementers. >>> - Public key pinning carries a fairly high risk of footgunning. The >>> consequence of a failed pin for a CA that serves many ACME clients = would >>> be that some of those clients would fail to renew their certs, = causing >>> cascading breakage. >>> - There is relatively little confidential information conveyed in = ACME, >>> and there are other defenses built into ACME (like including the = account >>> key as part of the challenge data), so HPKP is not strongly = necessary. >>>=20 >>> Any objections? >>=20 >> I was the person who initially suggested adding HPKP, that was more = than two >> years ago. People get HPKP headers wrong constantly and thus lock = themselves >> or their users out of services, missing library support is - as you = point >> out - a problem and I don't see much interest within the community to = add >> HPKP. By now I consider HPKP failed tech. to be honest. >=20 > I don't think we should give up on HPKP completely just yet; the thing = that's > missing for site operators is a better toolchain for getting it right = that > protects against errors by humans in the loop. It be cool if e.g. Certbot would reliably do that for Let's Encrypt = users, I agree. But in general it seems that there's little interest by = site operators (except really big ones) to actually deploy HPKP and, = even more, maintain it. It seems to me that this isn't a knowledge gap, = sys admins are well aware what the consequences are if they get pins = wrong. I'm not aware of any project that automates this reliably at this = time. >=20 > As for how much it's useful for ACME itself -- I think the big gating = variable > would be getting better support for it into various languages' HTTP = libraries. > It would make sense to have it built into Go, Python's requests = module, etc. > If that happened, ACME servers SHOULD use it. It probably doesn't make = sense > for ACME clients to be trying to bolt their own HPKP logic onto their > language's HTTP library. >=20 > I'm agnostic about whether the wording should be struck from the draft = or > changed to be "clients SHOULD support HTTP public key pinning if the = libraries > they depend on can provide it". That's very specific for a spec. Maybe OPTIONAL? Aaron --Apple-Mail=_350CBD97-1DBD-4F2A-99CC-D71E3DF4D863 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYuqP1AAoJEOTbZJL9ubXVIAcQAOU5tu915wp2iKYlcPXrrk9g zr6LqpRR/b2GfCmMYmqGD9H9MDESw7W3AKguiuvacQdvjhSEzTSySiaVX1An2aub uNv8hN2gWKwxxP8sbyn9Q/1EqjC0CXD25jJmRHl1pCcW5U7cGx2cDfJB01Bupxvz ohryMQ8BSJ3rDCnn7rMt/+HKOvLJ4tgXXP+MPFJLzLGnSYjZ35JbW7ztV8z3hDtD Jm/9FpVCojdqb+NESv2WSXwC6Y8gwwHxy84H+xo8BQsG8cXtAwkE2plMtcuVHF4d WTwzvjdY5hC8NQdYlyua3qIx/oTCduMr+qin2hSb7Ra4MNvEEbrTp5jnzzhGVPow ryDmnBOX+FpNZ/BLLlt2t+exBPmYSJiD+GzxNw8Zi60g4Ww54n1xXQ44wtY0OF/V YVS8Jb0OHk9BcykZbIzmXQcLSPEsFMovn3bepflGj+aWsfp7o06s90foX7hnbekP QNQVWlw4fZIdNPCZj7+wk0HMGkaOUuCOlmAQJCAhocphYXNx7xNjoGT9+n79v6A0 0TzUs4lbQUW6RBV7+qHjgr8ts2BRp6EWLSkj5Lw/qraj2YaKZQ5G/2n6ehSYiZ65 2xjx4WCKqcdBQVz3ohJdi/YTnSfUHVJ0hbyAdqDc13kXHiZ41F0nlnjxjBnJUVrh ykp22UQLCN5ze30I4Qc9 =NSZD -----END PGP SIGNATURE----- --Apple-Mail=_350CBD97-1DBD-4F2A-99CC-D71E3DF4D863-- From nobody Mon Mar 6 10:32:12 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 A476C129498 for ; Mon, 6 Mar 2017 10:32:11 -0800 (PST) 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 4KhPy9aaVeaS for ; Mon, 6 Mar 2017 10:32:09 -0800 (PST) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::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 74EC612995D for ; Mon, 6 Mar 2017 10:32:08 -0800 (PST) Received: by mail-wr0-x235.google.com with SMTP id l37so123155176wrc.1 for ; Mon, 06 Mar 2017 10:32:08 -0800 (PST) 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=fyohVFKnKOJfFsxAx0qa5FdupYmnsRL2i7mncrUn1jA=; b=qbc+FAbPAvqGq9i1BY/Suep8SPrmeul0WWY1bDvCEnKH5FYKbwrlpn83zVx8Y71hVa 3XxYN9SC0H918lB6iWWE90+D+A2dQuXsQxPF9+bv3kFzpAsrZy6axPHGa5imibFNZV7w 8cSMwdrl+5AYl2xHHRQykrBmFiB5uaJuYe7D4yA1dKaLWQjS4SY2W486TKUZDdq2N5FX 3+Dd82uR6GzVWpeywxmeWvjS7A+osAUFP0J0CHnyBj4ZUbQSS5S6oxYpcVqQWmro5Pxs kyRsgynAR1KzRL1/a+69Fr0m7pVlFpnTmqBsV6L6LJfXU1tCEg5pKIEkrzA709Agp7qY dkgg== 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=fyohVFKnKOJfFsxAx0qa5FdupYmnsRL2i7mncrUn1jA=; b=DtWLWgMGO0FD4S/IoT1tBtEg/lyP/3+jUy9P4gB5lLgl3e4j/SnYffNc5vTimsURvO 5Ra1LquFVRtB+KdNScg2kR8qOYtNXFfcPN220DtiOX3J5URXoT06E909+epWR31bR3Bz XvI04IJ+Z1ILDzyuIK3zIc3FFcfWosqKv6QAC/BgYi+kFyLoYcyjuzUV0D2+kOSDAC/L fwYhMqs3jLZPHCDlkh+SGNE3azZRGDeQouPx8q9LjHu8CGiGpEIzOV3rc87w/foTmLVq 4M2inafHkFwzlb/ScPWtIJh/j5/VEFLufDJ1eeJaE6DAkH/V5VPpJYoL8CpGmLM9vHuh qG5Q== X-Gm-Message-State: AMke39njoBPf3RBOKD2U3J8Es5GYTUBVyYCHSGKt3xq4Uk8gkAwU8rtdAOz8cciJEKpQKE5gfTRqi+W/FRST6g== X-Received: by 10.223.139.152 with SMTP id o24mr15660068wra.61.1488825126549; Mon, 06 Mar 2017 10:32:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.31.2 with HTTP; Mon, 6 Mar 2017 10:32:05 -0800 (PST) In-Reply-To: References: From: Richard Barnes Date: Mon, 6 Mar 2017 13:32:05 -0500 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=f403045e9acecd10d6054a141c14 Archived-At: Cc: "acme@ietf.org" Subject: Re: [Acme] Just the technical comments (was: ACME draft is now in WGLC.) X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 18:32:11 -0000 --f403045e9acecd10d6054a141c14 Content-Type: text/plain; charset=UTF-8 On Mon, Feb 13, 2017 at 5:02 PM, Martin Thomson wrote: > At Rich's request, here are the technical parts. I assume that the > editors will be trawling through the entirety of the original mail > (for which I apologize). > > These are just the headline items, I pulled two forward because I > think they are more important. The others are small beans. Of course > I'm happy to be wrong about any of these. > > S6.3.2 > > [...] and MUST reflect [the?] value of the > "external-account-binding" field in the resulting account object > > Is this a direct copy of the MAC that was provided? Do you realize > that this enables a user with access to any account that was created > with a binding to replay the binding in new accounts without actually > having the MAC key? How would that work? ISTM that since the MAC is calculated over the JWK representation of the account public key, you couldn't re-use the MAC to convey this authorization to another key. If there is an issue here, we do need to fix it, since the major purpose of external account binding is to convey authorization, e.g., for EV. It is probably overkill to reflect the whole object. I think my preferred solution would be to just reflect the "kid" value as you suggest. Would it be acceptable to just reflect that the > binding exists? (Potentially bad idea: just include the key id; if > the CA wants, that key identifier could be a URL to the external > account details page and do double-duty.) > > Note that this would be a violation of the stated security goal of not > having integrity compromised by a TLS MitM or CDN. It doesn't > necessarily permit misissuance unless the binding to the account > carries authorizations across, or things like that. > > S6.3.4 > > It is up to server policy > how long to retain data related to that account, whether to revoke > certificates issued by that account, and whether to send email to > that account's contacts. > > This is terrible. If I wish to decommission an account key, then I > can't because I might find that my certificates are all suddenly > revoked. Think about a large organization that has a pool of > authorized accounts used for managing certificates. If one of those > needs to fall out of the pool (the machine hosting the key is being > scrapped or rebuilt, for instance), then you don't want to have all > the certificates that it issued disappearing suddenly. > > If there are good reasons to revoke certificates, then be definite > about it and say that they go away, at least then people can plan > around the problem. > As with all server behaviors here, we can't really be too prescriptive; CAs will have compliance needs dictated by things like customers or root programs that will be will override voluntary protocol specifications. Some cautionary text might be warranted. > S5.2 > > Servers MUST NOT respond to GET > requests for resources that might be considered sensitive. > > Since this is a requirement, it might pay to do a little due diligence > on what might be sensitive. I'm not sure that all implementers will > have the same view (or same motivations) when it comes to this. > The only thing that comes to mind is accounts, though some CAs might also consider authorizations sensitive. We note that. > S5.7 > > In a couple of places, a specific error URN is mandated (with MUST), > but this section only uses SHOULD for the error description. > > Authorization and challenge objects can also contain error > information to indicate why the server was unable to validate > authorization. > > Where and how would this appear? This needs more definition (I > looked, but I didn't find anything further down). > Challenge objects have an "error" field, defined in S7. I think the authorization one is a stale reference. But it looks like this para has been deleted in the latest master anyway https://github.com/ietf-wg-acme/acme/commit/9414fafdee308bdd2faa34abd93ebb78fa8a5d24 S6.1.4 > > [[ Open issue: More flexible scoping? ]] > > Red flag. In my view, the simple approach is fine. New authorization > resources are cheap. They can even be cloned easily, even allowing > one challenge to fulfill multiple. > This was already removed. https://github.com/ietf-wg-acme/acme/pull/246/files > S6.4.1 > > The server can also provide the client with direct access to an SCT > for a certificate using a Link relation header field with relation > "ct-sct". > > Where is this link relation type registered? It isn't in either the > IANA considerations section or in the registry: > http://www.iana.org/assignments/link-relations/link-relations.xhtml > > The same goes for the other link relation types that are used in the > example. I see neither "revoke" nor "directory" being registered. > BTW, "index" would probably do well instead of "directory", "revoke" > seems specific enough to this usage - like "ct-sct" that using a URI > for the relation type would probably be better than registering a link > relation. > Already addressed: https://github.com/ietf-wg-acme/acme/pull/250 > S6.5.1 > > In responding to poll requests while > the validation is still in progress, the server MUST return a 202 > (Accepted) response > > The 202 is an odd choice here. The resource exists and has content, > so 200 works perfectly well for this purpose. > WFM. 200 + Retry-After is OK? > S6.6 > > The server MAY disallow a subset of reasonCodes from > being used by the user. > > Does a server ignore the reasonCode, or does it reject the request > when an impermissible code is chosen by the client? > Already addressed (in the "fail" direction): https://github.com/ietf-wg-acme/acme/pull/251/files > S9.2 > > For identifiers > where the server already has some public key associated with the > domain this attack can be prevented by requiring the client to prove > control of the corresponding private key. > > This doesn't seem right. I believe that the model permits multiple > accounts to act for a single domain. Not doing so would represent a > pretty big operational burden. What public key does this then refer > to? Or is this promise not valid? > Agreed. We should just delete this suggestion. > > S9.3 > > You should also recommend rate limits on account creation, or your > other mitigations might be weakened. > Yep. > S9.4 > > Does an ACME server send Referer[sic]? What should it set it to? > You mean as an SSRF mitigation? In that case, the real question is what headers the ACME server should send in order to minimize the probability that an attacked resource would respond to the request. I'm not sure Referer is great for that; wouldn't Origin be better? And in the Origin case, I would think the right thing to set it to would be the origin for the server. > S10.2 > > A CA that accepts TLS-based proof of domain control should attempt to > check whether a domain is hosted on a domain with a default virtual > host before allowing an authorization request for this host to use a > TLS-based challenge. A default virtual host can be detected by > initiating TLS connections to the host with random SNI values within > the namespace used for the TLS-based challenge (the "acme.invalid" > namespace for "tls-sni-02"). > > This doesn't seem right. If the default vhost is an attacker, then > they can generate the answers the server expects. Based on this text, > I don't actually know what the right answer might be, is it a TLS > unrecognized_name alert? > While in principle, you're correct that the attacker can provide whatever he wants, in practice, I don't think these systems are quite that agile. Instead, I think they just let you configure fairly static parameters, so e.g., the certificate would be constant over short time-scales. I don't think you can defend against the fully general case, but we can be more precise here. Proposed edits for this and others above in this PR: https://github.com/ietf-wg-acme/acme/pull/271 Thanks, --Richard --f403045e9acecd10d6054a141c14 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Feb 13, 2017 at 5:02 PM, Martin Thomson <<= a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson= @gmail.com> wrote:
At Rich's request, here are the technical parts.=C2=A0 I ass= ume that the
editors will be trawling through the entirety of the original mail
(for which I apologize).

These are just the headline items, I pulled two forward because I
think they are more important.=C2=A0 The others are small beans.=C2=A0 Of c= ourse
I'm happy to be wrong about any of these.

S6.3.2

=C2=A0 =C2=A0[...] and MUST reflect [the?] value of the
=C2=A0 =C2=A0"external-account-binding" field in the resulting ac= count object

Is this a direct copy of the MAC that was provided?=C2=A0 Do you realize that this enables a user with access to any account that was created
with a binding to replay the binding in new accounts without actually
having the MAC key?

How would that work?=C2= =A0 ISTM that since the MAC is calculated over the JWK representation of th= e account public key, you couldn't re-use the MAC to convey this author= ization to another key.
=C2=A0
If there is an issue her= e, we do need to fix it, since the major purpose of external account bindin= g is to convey authorization, e.g., for EV.

It is = probably overkill to reflect the whole object.=C2=A0 I think my preferred s= olution would be to just reflect the "kid" value as you suggest.<= /div>


=C2=A0 Would it be acceptable to just reflect that the
binding exists?=C2=A0 (Potentially bad idea: just include the key id; if the CA wants, that key identifier could be a URL to the external
account details page and do double-duty.)

Note that this would be a violation of the stated security goal of not
having integrity compromised by a TLS MitM or CDN.=C2=A0 It doesn't
necessarily permit misissuance unless the binding to the account
carries authorizations across, or things like that.

S6.3.4

=C2=A0 =C2=A0It is up to server policy
=C2=A0 =C2=A0how long to retain data related to that account, whether to re= voke
=C2=A0 =C2=A0certificates issued by that account, and whether to send email= to
=C2=A0 =C2=A0that account's contacts.

This is terrible.=C2=A0 If I wish to decommission an account key, then I can't because I might find that my certificates are all suddenly
revoked.=C2=A0 Think about a large organization that has a pool of
authorized accounts used for managing certificates.=C2=A0 If one of those needs to fall out of the pool (the machine hosting the key is being
scrapped or rebuilt, for instance), then you don't want to have all
the certificates that it issued disappearing suddenly.

If there are good reasons to revoke certificates, then be definite
about it and say that they go away, at least then people can plan
around the problem.

As with all server = behaviors here, we can't really be too prescriptive; CAs will have comp= liance needs dictated by things like customers or root programs that will b= e will override voluntary protocol specifications.=C2=A0 Some cautionary te= xt might be warranted.

=C2=A0
S5.2

=C2=A0 =C2=A0Servers MUST NOT respond to GET
=C2=A0 =C2=A0requests for resources that might be considered sensitive.

Since this is a requirement, it might pay to do a little due diligence
on what might be sensitive.=C2=A0 I'm not sure that all implementers wi= ll
have the same view (or same motivations) when it comes to this.

The only thing that comes to mind is accounts, tho= ugh some CAs might also consider authorizations sensitive.=C2=A0 We note th= at.

=C2=A0
S5.7

In a couple of places, a specific error URN is mandated (with MUST),
but this section only uses SHOULD for the error description.

=C2=A0 =C2=A0Authorization and challenge objects can also contain error
=C2=A0 =C2=A0information to indicate why the server was unable to validate<= br> =C2=A0 =C2=A0authorization.

Where and how would this appear?=C2=A0 This needs more definition (I
looked, but I didn't find anything further down).
=
Challenge objects have an "error" field, defined i= n S7.=C2=A0 I think the authorization one is a stale reference.

But it looks like this para has been deleted in the latest master an= yway

https://github.com/ietf-wg-acm= e/acme/commit/9414fafdee308bdd2faa34abd93ebb78fa8a5d24



<= /div>
S6.1.4

=C2=A0 =C2=A0[[ Open issue: More flexible scoping? ]]

Red flag.=C2=A0 In my view, the simple approach is fine.=C2=A0 New authoriz= ation
resources are cheap.=C2=A0 They can even be cloned easily, even allowing one challenge to fulfill multiple.


=C2=A0
S6.4.1

=C2=A0 =C2=A0The server can also provide the client with direct access to a= n SCT
=C2=A0 =C2=A0for a certificate using a Link relation header field with rela= tion
=C2=A0 =C2=A0"ct-sct".

Where is this link relation type registered?=C2=A0 It isn't in either t= he
IANA considerations section or in the registry:
http://www.iana.org/assignments/link-relations/link-relations.xhtml

The same goes for the other link relation types that are used in the
example.=C2=A0 I see neither "revoke" nor "directory" b= eing registered.
BTW, "index" would probably do well instead of "directory&qu= ot;, "revoke"
seems specific enough to this usage - like "ct-sct" that using a = URI
for the relation type would probably be better than registering a link
relation.

Already addressed:
<= div>
https://github.com/ietf-wg-acme/acme/pull/250
=

=C2=A0
S6.5.1

=C2=A0 =C2=A0In responding to poll requests while
=C2=A0 =C2=A0the validation is still in progress, the server MUST return a = 202
=C2=A0 =C2=A0(Accepted) response

The 202 is an odd choice here.=C2=A0 The resource exists and has content, so 200 works perfectly well for this purpose.

WFM.=C2=A0 200 + Retry-After is OK?

=C2=A0
S6.6

=C2=A0 =C2=A0The server MAY disallow a subset of reasonCodes from
=C2=A0 =C2=A0 =C2=A0 being used by the user.

Does a server ignore the reasonCode, or does it reject the request
when an impermissible code is chosen by the client?
Already addressed (in the "fail" direction):

= https://git= hub.com/ietf-wg-acme/acme/pull/251/files

=C2=A0
=
S9.2

=C2=A0 =C2=A0For identifiers
=C2=A0 =C2=A0where the server already has some public key associated with t= he
=C2=A0 =C2=A0domain this attack can be prevented by requiring the client to= prove
=C2=A0 =C2=A0control of the corresponding private key.

This doesn't seem right.=C2=A0 I believe that the model permits multipl= e
accounts to act for a single domain.=C2=A0 Not doing so would represent a pretty big operational burden.=C2=A0 What public key does this then refer to?=C2=A0 Or is this promise not valid?

Agreed.=C2=A0 We should just delete this suggestion.

=C2= =A0

S9.3

You should also recommend rate limits on account creation, or your
other mitigations might be weakened.

Ye= p.

=C2=A0
S9.4

Does an ACME server send Referer[sic]?=C2=A0 What should it set it to?
<= /blockquote>

You mean as an SSRF mitigation?=C2=A0 In th= at case, the real question is what headers the ACME server should send in o= rder to minimize the probability that an attacked resource would respond to= the request.=C2=A0 I'm not sure Referer is great for that; wouldn'= t Origin be better?=C2=A0 And in the Origin case, I would think the right t= hing to set it to would be the origin for the server.

=C2= =A0
S10.2

=C2=A0 =C2=A0A CA that accepts TLS-based proof of domain control should att= empt to
=C2=A0 =C2=A0check whether a domain is hosted on a domain with a default vi= rtual
=C2=A0 =C2=A0host before allowing an authorization request for this host to= use a
=C2=A0 =C2=A0TLS-based challenge.=C2=A0 A default virtual host can be detec= ted by
=C2=A0 =C2=A0initiating TLS connections to the host with random SNI values = within
=C2=A0 =C2=A0the namespace used for the TLS-based challenge (the "acme= .invalid"
=C2=A0 =C2=A0namespace for "tls-sni-02").

This doesn't seem right.=C2=A0 If the default vhost is an attacker, the= n
they can generate the answers the server expects.=C2=A0 Based on this text,=
I don't actually know what the right answer might be, is it a TLS
unrecognized_name alert?

While in princ= iple, you're correct that the attacker can provide whatever he wants, i= n practice, I don't think these systems are quite that agile.=C2=A0 Ins= tead, I think they just let you configure fairly static parameters, so e.g.= , the certificate would be constant over short time-scales.=C2=A0 I don'= ;t think you can defend against the fully general case, but we can be more = precise here.

Proposed edits for this and othe= rs above in this PR:

Thanks,
--Richard
--f403045e9acecd10d6054a141c14-- From nobody Mon Mar 6 16:21: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 BD11A129876 for ; Mon, 6 Mar 2017 16:21:29 -0800 (PST) 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 2X78BDtgoLgO for ; Mon, 6 Mar 2017 16:21:28 -0800 (PST) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::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 F304612946D for ; Mon, 6 Mar 2017 16:21:27 -0800 (PST) Received: by mail-qk0-x22d.google.com with SMTP id 1so182864485qkl.3 for ; Mon, 06 Mar 2017 16:21:27 -0800 (PST) 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=sFvXiM7YArQDZBEFj8p+9xgPS+L682tYPKpDaqs86Bk=; b=NVmGaPTX/QPJQpqPt2MTYzi8eOz7LPdMxRGfFlVd8I4Gm7LV/Bk2Qkj66Dha/fYwKo 4JcZkUhItbpE+zwjbpvzGh3Ssw1FHlv/SKZ6B/Us1syvpi+EvQHt+x1hf9uTi4wyUemy hDYk5ZBcMZSjcwnya+cnpWmkFJ7Xd2q02uARB+CcydWuPAbCmfz8g7PB5M9ZttQ+nptz hr8udBlV6mh9SJ8MHGonfRCnZ4HFxl7oOoFbJw2WP49bOqfYCDKaTLBbIfF+eKjt/1sz b/rnhrm/qPmCxwgItkLNV83XxxpE+W3mhHCAVf+qYyNWg5q0DyE9iW804AtLA0gJON3X lqtg== 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=sFvXiM7YArQDZBEFj8p+9xgPS+L682tYPKpDaqs86Bk=; b=Re8iRe0snf8y7OpoRlgxCLVkB8lHj6bvArnE6iuE7Uf2HjixM+tm18gP8+IVwNzPM1 z4UsR3dCZ7LTMLQR0tHZcb9qxLIVpt2yYSZsDybI/zpzEL1aUqg/CSS5xzTRiWdRV+t6 yLMZNvH3P01xZa5XBynrO0kBzbxRlXw1E++qVMuynctO6RaWOTySSkYRZhpMm51+Mkev 14cdnSdqFsYPf3uwOYqvWeOfigq0yrj+1Kb9tloDpZ9oJ6dGOAqLErigvcjOf4PP1EPV 1PL32DbXHVRXFjPTOl+TCV0ZYwPYAng+aclbMP/7uwBa9opCj61WyXQ4AFZADd3QgQMx 4hlw== X-Gm-Message-State: AMke39n+tGMM+DbuTdTuY2F21900pyl95BXrjFd7hWER7cWHuf09CkvaAVrjbwC6pP6TJopk9pBeg1I8RQ9xFQ== X-Received: by 10.237.51.5 with SMTP id u5mr20375828qtd.247.1488846087090; Mon, 06 Mar 2017 16:21:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Mon, 6 Mar 2017 16:21:26 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Tue, 7 Mar 2017 11:21:26 +1100 Message-ID: To: Richard Barnes Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "acme@ietf.org" Subject: Re: [Acme] Just the technical comments (was: ACME draft is now in WGLC.) X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 00:21:30 -0000 Yes, many of these things were already addressed by Jacob and others. On 7 March 2017 at 05:32, Richard Barnes wrote: >> S6.3.2 >> >> [...] and MUST reflect [the?] value of the >> "external-account-binding" field in the resulting account object >> >> Is this a direct copy of the MAC that was provided? Do you realize >> that this enables a user with access to any account that was created >> with a binding to replay the binding in new accounts without actually >> having the MAC key? > > > How would that work? ISTM that since the MAC is calculated over the JWK > representation of the account public key, you couldn't re-use the MAC to > convey this authorization to another key. Yeah, that is a detail I missed (that the MAC has a very specific form isn't established by this point in the doc). > If there is an issue here, we do need to fix it, since the major purpose of > external account binding is to convey authorization, e.g., for EV. > > It is probably overkill to reflect the whole object. I think my preferred > solution would be to just reflect the "kid" value as you suggest. That would be fine. >> [re: Revocation on account deletion] > > > As with all server behaviors here, we can't really be too prescriptive; CAs > will have compliance needs dictated by things like customers or root > programs that will be will override voluntary protocol specifications. Some > cautionary text might be warranted. I realize that there might be cases where termination of an account might result in revocation, but the protocol doesn't need to require it. (I think that this was discussed and resolved by saying that the certificates will not be directly affected by this action.) >> S6.5.1 >> >> In responding to poll requests while >> the validation is still in progress, the server MUST return a 202 >> (Accepted) response >> >> The 202 is an odd choice here. The resource exists and has content, >> so 200 works perfectly well for this purpose. > > > WFM. 200 + Retry-After is OK? Probably. It's a little odd to include Retry-After on a successful response, (503 being more common), but I can't think of anything better. >> S9.4 >> >> Does an ACME server send Referer[sic]? What should it set it to? > > You mean as an SSRF mitigation? In that case, the real question is what > headers the ACME server should send in order to minimize the probability > that an attacked resource would respond to the request. I'm not sure > Referer is great for that; wouldn't Origin be better? And in the Origin > case, I would think the right thing to set it to would be the origin for the > server. I don't mean as anything. The question is simply whether it does or not. It might make it easier to construct a valid response, though I'm not sure that has reads on the ability of an attacker to generate a valid response given the challenge structure. It would set the value to some part of the URL that referred it. Origin is very specific to the web security model. It refers to the origin that is making a request. I wouldn't use it here. > Proposed edits [...] > > https://github.com/ietf-wg-acme/acme/pull/271 I'll review that, thanks. From nobody Mon Mar 6 17:10:33 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 7759D1299EF for ; Mon, 6 Mar 2017 17:10:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.004 X-Spam-Level: X-Spam-Status: No, score=-7.004 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, RCVD_IN_MSPIKE_H2=-0.001, 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 9hPbKbcuTyfi for ; Mon, 6 Mar 2017 17:10:30 -0800 (PST) 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 C900012956C for ; Mon, 6 Mar 2017 17:10:30 -0800 (PST) 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:Cc:References:To:Subject; bh=A4EEufb6dPFi6Mf7ulFRuOHyiLhZDf5l0FahrgyQWLA=; b=HkDYp9IKe2QnM835wtnWqe2pePcvdvsCflM7f3J3N3w8BNyLZSIdvrk+uHoT6nxdZY21Ias9ojrjGEW6cFJ1hAXD6Ve0MOI1aHSELp8EziHqkhz6hfomk/wGfPSy8CW8gH+nlTwg9EbJnN3sG3uoqIx04IQOHvapvly/f2OzSTo=; Received: ; Mon, 06 Mar 2017 17:10:32 -0800 To: Martin Thomson , Richard Barnes References: From: Jacob Hoffman-Andrews Message-ID: Date: Mon, 6 Mar 2017 17:10:29 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Received-SPF: skipped for local relay Archived-At: Cc: "acme@ietf.org" Subject: Re: [Acme] Just the technical comments (was: ACME draft is now in WGLC.) X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 01:10:32 -0000 On 03/06/2017 04:21 PM, Martin Thomson wrote: > I don't mean as anything. The question is simply whether it does or > not. It might make it easier to construct a valid response, though > I'm not sure that has reads on the ability of an attacker to generate > a valid response given the challenge structure. No, the server is not defined to send a Referer header. I think it's not needed. From nobody Mon Mar 6 19:15:14 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 8BEC5129AAF for ; Mon, 6 Mar 2017 19:15:13 -0800 (PST) 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, 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 Xc7bqjUp8s0a for ; Mon, 6 Mar 2017 19:15:12 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E778412948A for ; Mon, 6 Mar 2017 19:15:11 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 13A4D7A3309; Tue, 7 Mar 2017 03:15:11 +0000 (UTC) Date: Tue, 7 Mar 2017 03:15:11 +0000 From: Viktor Dukhovni To: "acme@ietf.org" Message-ID: <20170307031510.GN7733@mournblade.imrryr.org> References: <8473d9ba84894d49b2f2232370d66b46@usma1ex-dag1mb3.msg.corp.akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8473d9ba84894d49b2f2232370d66b46@usma1ex-dag1mb3.msg.corp.akamai.com> User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [Acme] ACME draft is now in WGLC. X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: acme@ietf.org List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 03:15:13 -0000 On Tue, Feb 07, 2017 at 05:27:48PM +0000, Salz, Rich wrote: > I put the time period as six weeks, which takes us to just around IETF-98... > > PLEASE reply on list if you will review and/or are interested in working on interop. I see there's no reference to use of DNSSEC resolvers by CAs that implement DNS challenges. Just a suggestion to send probes from multiple networks to avoid MiTM attacks, which seems rather weak to me. The MiTM might be collocated near the victim rather than the CA. There was some brief discussion of DNSSEC back in Oct/2015: https://www.ietf.org/mail-archive/web/acme/current/thrd3.html#00561 https://www.ietf.org/mail-archive/web/acme/current/msg00561.html https://www.ietf.org/mail-archive/web/acme/current/msg00562.html https://www.ietf.org/mail-archive/web/acme/current/msg00563.html https://www.ietf.org/mail-archive/web/acme/current/msg00564.html https://www.ietf.org/mail-archive/web/acme/current/msg00565.html https://www.ietf.org/mail-archive/web/acme/current/msg00729.html but no further action. Is there a compellng reason to avoid requiring acme CAs to spin up a validating resolver? It does not seem like a lot to ask. If a domain is DNSSEC-signed then its ACME challenge should IMHO be validated via DNSSEC. -- Viktor. From nobody Mon Mar 6 19:20: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 88B42129AC5 for ; Mon, 6 Mar 2017 19:20:29 -0800 (PST) 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, 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 2cQnXAajiw0b for ; Mon, 6 Mar 2017 19:20:28 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8953C129AC7 for ; Mon, 6 Mar 2017 19:20:24 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 8F68C7A3309; Tue, 7 Mar 2017 03:20:23 +0000 (UTC) Date: Tue, 7 Mar 2017 03:20:23 +0000 From: Viktor Dukhovni To: "acme@ietf.org" Message-ID: <20170307032023.GO7733@mournblade.imrryr.org> References: <8473d9ba84894d49b2f2232370d66b46@usma1ex-dag1mb3.msg.corp.akamai.com> <20170307031510.GN7733@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170307031510.GN7733@mournblade.imrryr.org> User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [Acme] ACME draft is now in WGLC. X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: acme@ietf.org List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 03:20:29 -0000 On Tue, Mar 07, 2017 at 03:15:10AM +0000, Viktor Dukhovni wrote: > On Tue, Feb 07, 2017 at 05:27:48PM +0000, Salz, Rich wrote: > > > I put the time period as six weeks, which takes us to just around IETF-98... > > > > PLEASE reply on list if you will review and/or are interested in working on interop. > > I see there's no reference to use of DNSSEC resolvers by CAs that > implement DNS challenges. Just a suggestion to send probes from > multiple networks to avoid MiTM attacks, which seems rather weak > to me. The MiTM might be collocated near the victim rather than > the CA. > > There was some brief discussion of DNSSEC back in Oct/2015: > > https://www.ietf.org/mail-archive/web/acme/current/thrd3.html#00561 > > https://www.ietf.org/mail-archive/web/acme/current/msg00561.html > https://www.ietf.org/mail-archive/web/acme/current/msg00562.html > https://www.ietf.org/mail-archive/web/acme/current/msg00563.html > https://www.ietf.org/mail-archive/web/acme/current/msg00564.html > https://www.ietf.org/mail-archive/web/acme/current/msg00565.html > https://www.ietf.org/mail-archive/web/acme/current/msg00729.html > > but no further action. Is there a compellng reason to avoid > requiring acme CAs to spin up a validating resolver? It does not > seem like a lot to ask. If a domain is DNSSEC-signed then its ACME > challenge should IMHO be validated via DNSSEC. Specifically, it 10.3 use of DNSSEC is a RECOMMENDATION, not a requirement: https://tools.ietf.org/html/draft-ietf-acme-acme-05#section-10.3 I would have expected a requirement here. -- Viktor. From nobody Mon Mar 6 19:46: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 B49B3128BA2 for ; Mon, 6 Mar 2017 19:46:03 -0800 (PST) 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, 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 (1024-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 X_-OsIfyPXgG for ; Mon, 6 Mar 2017 19:46:02 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 81772129AC2 for ; Mon, 6 Mar 2017 19:46:02 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id E2ED7433413 for ; Tue, 7 Mar 2017 03:46:01 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id AAB25433412 for ; Tue, 7 Mar 2017 03:46:01 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1488858361; bh=laVfkmzeaAC4Vo4sz2WpSqfdB+LqyIOq4njCqJWzkfY=; l=256; h=From:To:Date:References:In-Reply-To:From; b=s6El47VbWmMOMoF1CiWNrAOHDeaENybsoUH17MkjK1ZBHOqeNkMBXo/e6LcC+uqJt /4v7l1hY7W7UT1YfHI1KUW+Fte2S2XMwfE+AEf75w6cbvrFhS1i/W/aLGgFsOtPnFj CREdnKhWfuscxm6CBvOqQLsI0qp6oOyEnGDjNCAk= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.34]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id A65E01FC8E for ; Tue, 7 Mar 2017 03:46:01 +0000 (GMT) Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 6 Mar 2017 22:46:01 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1178.000; Mon, 6 Mar 2017 22:46:01 -0500 From: "Salz, Rich" To: "acme@ietf.org" Thread-Topic: [Acme] ACME draft is now in WGLC. Thread-Index: AdKBZ2LP4XWB1i0uR++KFKjfHhNLwgVs43eAAAAufoAACZkPwA== Date: Tue, 7 Mar 2017 03:46:00 +0000 Message-ID: <9471a5323a98405eaf0ee111fb0350b0@usma1ex-dag1mb3.msg.corp.akamai.com> References: <8473d9ba84894d49b2f2232370d66b46@usma1ex-dag1mb3.msg.corp.akamai.com> <20170307031510.GN7733@mournblade.imrryr.org> <20170307032023.GO7733@mournblade.imrryr.org> In-Reply-To: <20170307032023.GO7733@mournblade.imrryr.org> 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.142] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Acme] ACME draft is now in WGLC. X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 03:46:04 -0000 > Specifically, it 10.3 use of DNSSEC is a RECOMMENDATION, not a > requirement: >=20 > https://tools.ietf.org/html/draft-ietf-acme-acme-05#section-10.3 >=20 > I would have expected a requirement here. The WG consensus has been for recommendation. From nobody Tue Mar 7 04:13: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 14786129461 for ; Tue, 7 Mar 2017 04:13:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 EWk12xfiTQxh for ; Tue, 7 Mar 2017 04:13:15 -0800 (PST) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (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 755891293E9 for ; Tue, 7 Mar 2017 04:13:15 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.35,258,1484002800"; d="scan'208";a="215869090" Received: from unknown (HELO [128.93.82.197]) ([128.93.82.197]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Mar 2017 13:13:13 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Nadim Kobeissi In-Reply-To: <4816CEB7-A2A6-4DA2-800B-EBEFE8B3472F@azet.org> Date: Tue, 7 Mar 2017 13:13:12 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <59A14FBC-9208-42D5-9A1F-86DC7F665C5F@inria.fr> References: <81377754-e24d-269d-0f48-ba37e55f8942@eff.org> <22DB918C-015D-48C8-9A5E-1D4BDC57DC84@azet.org> <20170303222502.GD31407@eff.org> <4816CEB7-A2A6-4DA2-800B-EBEFE8B3472F@azet.org> To: Aaron Zauner X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Peter Eckersley , Martin Thomson , Jacob Hoffman-Andrews , "acme@ietf.org" Subject: Re: [Acme] HPKP in ACME X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 12:13:18 -0000 > On Mar 4, 2017, at 12:24 PM, Aaron Zauner wrote: >=20 >=20 >> On 03 Mar 2017, at 22:25, Peter Eckersley wrote: >>=20 >> On Fri, Mar 03, 2017 at 11:53:49AM +0000, Aaron Zauner wrote: >>>=20 >>>> On 13 Feb 2017, at 19:33, Jacob Hoffman-Andrews = wrote: >>>>=20 >>>> Martin brought up a section I've been considering removing: >>>>=20 >>>>> Clients SHOULD support HTTP public key pinning [RFC7469], and = servers >>>> SHOULD emit pinning headers. >>>>=20 >>>> Here's my reasoning: >>>>=20 >>>> - Public key pinning isn't implemented in most HTTPS libraries = outside >>>> of browsers, so this is a considerable burden on implementers. >>>> - Public key pinning carries a fairly high risk of footgunning. The >>>> consequence of a failed pin for a CA that serves many ACME clients = would >>>> be that some of those clients would fail to renew their certs, = causing >>>> cascading breakage. >>>> - There is relatively little confidential information conveyed in = ACME, >>>> and there are other defenses built into ACME (like including the = account >>>> key as part of the challenge data), so HPKP is not strongly = necessary. >>>>=20 >>>> Any objections? >>>=20 >>> I was the person who initially suggested adding HPKP, that was more = than two >>> years ago. People get HPKP headers wrong constantly and thus lock = themselves >>> or their users out of services, missing library support is - as you = point >>> out - a problem and I don't see much interest within the community = to add >>> HPKP. By now I consider HPKP failed tech. to be honest. >>=20 >> I don't think we should give up on HPKP completely just yet; the = thing that's >> missing for site operators is a better toolchain for getting it right = that >> protects against errors by humans in the loop. >=20 > It be cool if e.g. Certbot would reliably do that for Let's Encrypt = users, I agree. But in general it seems that there's little interest by = site operators (except really big ones) to actually deploy HPKP and, = even more, maintain it. It seems to me that this isn't a knowledge gap, = sys admins are well aware what the consequences are if they get pins = wrong. I'm not aware of any project that automates this reliably at this = time. The nice thing about HPKP is that it allows site operators to do a = strong assert on the authenticity of a bunch of certificates aside from = the current one. As far as I know, this is the only simple currently available mechanism = that would allow site operators to suddenly switch certificate and even = certificate authorities without that switch being sudden and not backed = up by some publicly verifiable chain of authenticity. Another cool = side-note is that this chain of authenticity, if maintained throughout a = bunch of HPKP-backed certificate rotations, becomes controlled more by = the site operator themselves than the CA, which is interesting. Specifically since it is possibly the unique mechanism in which this can = be accomplished, I think it deserves being kept for future integration, = or at least not discounted so early on. In my mind, HPKP integration into ACME is a matter of pooling = engineering time. Integration can wait until, say, Let=E2=80=99s Encrypt = engineers feel they have time on their hands, but the entire idea of = HPKP shouldn=E2=80=99t be put down prematurely. It has unique potential. Nadim >=20 >>=20 >> As for how much it's useful for ACME itself -- I think the big gating = variable >> would be getting better support for it into various languages' HTTP = libraries. >> It would make sense to have it built into Go, Python's requests = module, etc. >> If that happened, ACME servers SHOULD use it. It probably doesn't = make sense >> for ACME clients to be trying to bolt their own HPKP logic onto their >> language's HTTP library. >>=20 >> I'm agnostic about whether the wording should be struck from the = draft or >> changed to be "clients SHOULD support HTTP public key pinning if the = libraries >> they depend on can provide it". >=20 > That's very specific for a spec. Maybe OPTIONAL? >=20 > Aaron > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme From nobody Tue Mar 7 14:40: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 D154B127058 for ; Tue, 7 Mar 2017 14:40:53 -0800 (PST) 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 c9cMpbgMqGB7 for ; Tue, 7 Mar 2017 14:40:50 -0800 (PST) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::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 BCCC4120726 for ; Tue, 7 Mar 2017 14:40:50 -0800 (PST) Received: by mail-pg0-x22b.google.com with SMTP id 187so5461444pgb.3 for ; Tue, 07 Mar 2017 14:40:50 -0800 (PST) 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=tQTQTCLcQ9iViWq10Bqxj6f0xuzxwaoinceM/83voew=; b=lAe+hmXLS4NZuH2LjsD4oStwqOHqsYamSjFb04EFrJZAxv2e+6xoAEQtGfQMuq8Ech wbyQ8QErTkL0YukC4Pj3/tUEa30by7gGGVUHtsSWoSwRTlp5U26Y8F7unPw5LBakU14u bV23g5S+sN0j6rhQoE5uSn/qj5St9tZztF2vk8wZrflMLH+gnSPEAxzvvIwbs9VZYH/c kFfR62fkr29O47YNczfzb+EA66+DfDuSt79ZEqdf9WLCu/H98OjyVsU1aXQka6ywEtil 0CAAilRIsd5G1Ip12EfJotSgvmM022xwh5VYfygGA+91YvZUAW+H7xEvDcvczE8V4xR+ xf+w== 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=tQTQTCLcQ9iViWq10Bqxj6f0xuzxwaoinceM/83voew=; b=R2/I7B1vF/lIaCpxmuBGvYn79W9xNQibhC5FnCbsiUZGIBNAw5EJywgo1+xSWK0ryR CjsPUf6po8frzIVTeIiTPWUTBfqjb84lgZpFCzqdUjmLzIMxOzV61lX9QHzOTyReQ4dY vVirWsM0WER5INGv9DTOn+D/PtFAjSwsyboIAj5HRPAGtECuUvB48uc8vHRwCc+mpJPy 4S2EN+iN2UqjAag0WctMi2JUlZsuoqBraTjWNr8jv9Pqa/1OeyWBw2Qlzh7zXmoq8rtZ 8LcNGklGCxlejIlmPV47jlriFOrtDYtE2WgL3BiG4lIU+5sFTGBRawjGD1k5MotqPdu2 sU+g== X-Gm-Message-State: AMke39kh/PxUKaSXgleuGCr06EYA6V+YTQGQ1QdEdqTmFR9pcMtd6AKJ6xZmjPox12y5Z0ecM0UgwiDaFdNCKg== X-Received: by 10.98.51.70 with SMTP id z67mr3112954pfz.68.1488926449950; Tue, 07 Mar 2017 14:40:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.130.129 with HTTP; Tue, 7 Mar 2017 14:40:49 -0800 (PST) From: Logan Widick Date: Tue, 7 Mar 2017 16:40:49 -0600 Message-ID: To: acme@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Acme] Hash algorithms for challenges X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 22:40:54 -0000 I noticed that the challenges in the draft seem to be tied to the same hash algorithm (SHA-256). Would it be possible to have the the server include an array of supported hash algorithms, and then have the client specify which one of the server's supported algorithms is used in the response? This way, the hash algorithms can be changed when needed without changing the challenges themselves. For example, consider the following directory, modified to include the server's supported hash algorithms: { "new-nonce": "https://example.com/acme/new-nonce", //other standard URIs here "meta": { "terms-of-service": "https://example.com/acme/terms", "website": "https://www.example.com/", "caa-identities": ["example.com"], "hash-algorithms": ["SHA-256", "SHA-512"] }, Alternatively, the server's hash algorithms could be included in the challenges, like this: { "type": "http-01", "url": "https://example.com/authz/1234/0", "token": "DGyRejmCefe7v4NfDGDKfA", "hash-algorithms":["SHA-256", "SHA-512"] } Then, the client indicates the preferred hash algorithm (from the server's list) in the response: { "protected": base64url({ "alg": "ES256", "kid": "https://example.com/acme/acct/1", "nonce": "Q_s3MWoqT05TrdkM2MTDcw", "url": "https://example.com/acme/authz/asdf/0" }), "payload": base64url({ "type": "http-01", "keyAuthorization": "IlirfxKKXA...vb29HhjjLPSggwiE", "hash-algorithm": "SHA-256" }), "signature": "9cbg5JO1Gf5YLjjz...SpkUfcdPai9uVYYQ" } For compatibility with existing implementations, the default hash algorithm if none is specified could be SHA-256. Sincerely, Logan Widick From nobody Tue Mar 7 19:57: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 C99F7129418 for ; Tue, 7 Mar 2017 19:57:29 -0800 (PST) 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 xrj1m91d7OdI for ; Tue, 7 Mar 2017 19:57:28 -0800 (PST) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::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 12895124281 for ; Tue, 7 Mar 2017 19:57:28 -0800 (PST) Received: by mail-qk0-x232.google.com with SMTP id p64so43031432qke.1 for ; Tue, 07 Mar 2017 19:57:28 -0800 (PST) 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=KStkK98iTycmeXK5G1y6AUODZfhMA/9sYAN244JEFmk=; b=G5T+v6wMs0LLFJ3rETjNkDeOFuyplRvWrNwqkOn9ZbaqYQ4pz3TMHLviTEJywFadzs 4SGYjoaiKMMLdj4jmBebVmHOVcGtpbJkBLKAJyJbZ0WxGhTtpO6nDXU0ispZWfLeqZah ifqGfgnpfql668oEba9zLWLZTm45EBxQPoMmiRyipb0MFj2NCjBEaTzPV7Yrhfnztisa TH5/+G3Hz2600vgvpB4AphUj82dzQvr3JcYkP2ffm0nIYhm6Tx14P/AVRGqaKaOx9gy0 IbdLHaYyDzktlaVqx2GMs/ouKvaGk/9Bb/lPCqqLMWhxFSiXx319NgX+UCrYoS1QkVvI HzFw== 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=KStkK98iTycmeXK5G1y6AUODZfhMA/9sYAN244JEFmk=; b=M2bm8e8g3zO4CwFhE6yDrUjkkLZMukzCD/J9VqfOZjRoSjqWMdGn7vDbX9536sRH3V r/q7Xbzh/KAsWtbLGwajh9O3maGIFWozhExsffVe82+DxTyvcGua8aZNxGMnnF/YrT8k kzD228uGwic1XUvSOE3mURqdHtFGm/UvwlSyK31mVH29+wvgWJLv5w+JquutjHlXxlrN ORiJLX5LbwiVWMXF/no0EN0TyyBA9TDljgmAzwj3CNNUAGv9DgkQxMIpdb7o8rc3RXeP xG+e79ga4osQnv2N8mb69p4e2WV1Y6A7o2CtGQaxnxzCG/B3hgSIq9mrbe3G30D/r5hS 4KGg== X-Gm-Message-State: AMke39m+26VUpXp5SwpiPCAZDupooVsb2L9XXxq35PhXhz3aj65ZDKvi/OemMvUij25aCWyxiFUtE0bzn00EBA== X-Received: by 10.237.34.250 with SMTP id q55mr5241626qtc.144.1488945447200; Tue, 07 Mar 2017 19:57:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Tue, 7 Mar 2017 19:57:26 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Wed, 8 Mar 2017 14:57:26 +1100 Message-ID: To: Logan Widick Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "acme@ietf.org" Subject: Re: [Acme] Hash algorithms for challenges X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 03:57:30 -0000 I would rather see new challenges defined with a new hash function than introduce orthogonal hash negotiation. On 8 March 2017 at 09:40, Logan Widick wrote: > I noticed that the challenges in the draft seem to be tied to the same > hash algorithm (SHA-256). Would it be possible to have the the server > include an array of supported hash algorithms, and then have the > client specify which one of the server's supported algorithms is used > in the response? This way, the hash algorithms can be changed when > needed without changing the challenges themselves. > > For example, consider the following directory, modified to include the > server's supported hash algorithms: > { > "new-nonce": "https://example.com/acme/new-nonce", > //other standard URIs here > "meta": { > "terms-of-service": "https://example.com/acme/terms", > "website": "https://www.example.com/", > "caa-identities": ["example.com"], > "hash-algorithms": ["SHA-256", "SHA-512"] > }, > > Alternatively, the server's hash algorithms could be included in the > challenges, like this: > { > "type": "http-01", > "url": "https://example.com/authz/1234/0", > "token": "DGyRejmCefe7v4NfDGDKfA", > "hash-algorithms":["SHA-256", "SHA-512"] > } > > Then, the client indicates the preferred hash algorithm (from the > server's list) in the response: > { > "protected": base64url({ > "alg": "ES256", > "kid": "https://example.com/acme/acct/1", > "nonce": "Q_s3MWoqT05TrdkM2MTDcw", > "url": "https://example.com/acme/authz/asdf/0" > }), > "payload": base64url({ > "type": "http-01", > "keyAuthorization": "IlirfxKKXA...vb29HhjjLPSggwiE", > "hash-algorithm": "SHA-256" > }), > "signature": "9cbg5JO1Gf5YLjjz...SpkUfcdPai9uVYYQ" > } > > For compatibility with existing implementations, the default hash > algorithm if none is specified could be SHA-256. > > Sincerely, > > Logan Widick > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme From nobody Wed Mar 8 05:00: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 1F686129665 for ; Wed, 8 Mar 2017 05:00:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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, RP_MATCHES_RCVD=-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=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 S_oB_sXe72A3 for ; Wed, 8 Mar 2017 05:00:28 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 53ED6129655 for ; Wed, 8 Mar 2017 05:00:28 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 76AB7433406; Wed, 8 Mar 2017 13:00:27 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 4DC6C4F09E; Wed, 8 Mar 2017 13:00:27 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1488978027; bh=Q9lg0b9LurEp8KfS3Fs5HqiIiDJ5Ex88jC7mdl/3n9g=; l=175; h=From:To:CC:Date:References:In-Reply-To:From; b=gkoDw+K4cxM5AwYlie0Pw316izNbJ1yclEX8w47H7N4rp/1pD1VNmXEDxenAYcLfL 3gvOWB5SuTUo79rP+UO9bOW5+tyGmmbehzuYKCzV/5bJr1XbofQ+WgtKG8ndNKGjrZ nymtgLeK7Vdwt96EfplwOVlSpxCPkz+9mw6+YbO0= Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 487551FC88; Wed, 8 Mar 2017 13:00:27 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 8 Mar 2017 08:00:26 -0500 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.1178.000; Wed, 8 Mar 2017 08:00:26 -0500 From: "Salz, Rich" To: Martin Thomson , Logan Widick Thread-Topic: [Acme] Hash algorithms for challenges Thread-Index: AQHSl5PlV1KnxZ8WyUGUN/+numVw96GKpNwAgABD0MA= Date: Wed, 8 Mar 2017 13:00:26 +0000 Message-ID: <73bf64eceade46f896da9ad077ccc0bf@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.40.230] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "acme@ietf.org" Subject: Re: [Acme] Hash algorithms for challenges X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 13:00:34 -0000 > I would rather see new challenges defined with a new hash function than > introduce orthogonal hash negotiation. Speaking as an individual, I strongly agree with this. From nobody Wed Mar 8 05:46:53 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 7A516129465 for ; Wed, 8 Mar 2017 05:46:51 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=azet.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 Swkv_J234Nfq for ; Wed, 8 Mar 2017 05:46:50 -0800 (PST) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::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 EC6C012943C for ; Wed, 8 Mar 2017 05:46:49 -0800 (PST) Received: by mail-wm0-x22f.google.com with SMTP id n11so115259668wma.1 for ; Wed, 08 Mar 2017 05:46:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=6zrZs0QjBQFZ7ZWvn4mBx39HhAy5CtujBj6vwKOsaPE=; b=dQrco/qjTg/6AlEx2sTgoyDMLyrcTD9/+vjdGUbNApYyDLiYL4WrU0dMpNmjOSJf0A 5fsK4vCCtbsba9Y6siTUt+Nq5VsWzkdKtrSpYqLMPYs199hQmmE0kuIchLLohlDwlEUU 15dX7b3qJvKAoMC+sxxXFyyKUFWmU74II/mt4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=6zrZs0QjBQFZ7ZWvn4mBx39HhAy5CtujBj6vwKOsaPE=; b=Hf8ygk49KWpxXY3p77+zUmY0BRruwsRK0hx7KhRdmvCygA1kpfegVOaiGEF53MHWWS CdViOjH1WGFPqgrNq85V5aWjnLvFkAYI/O7MYl0YCFqVQVzrR3j2Xmyv9eHw9ZMSRF8Y R9X7OzcALvOrXJN+OkUULkyy9iGAD81WZNt5VusSgm0OJOHvt0OdTQNTLVWVIyZMEKf1 MLjiq9vo5LXB0dlUKhrkdmUQq0oraNUAkke4lZVBIfVARKlbQBPxwDwu5H7+/8v7N6Ip 59CxriXrsmzT1WxkykEu+MMYYKSLfZv1tjNVdfHpN2/8jgc0vtpBf6hts3npsjiNXYNH gPhw== X-Gm-Message-State: AMke39kib1wxVJDd2RKTrquUIz4UJ9rSlj/oxXkQBE/rpv/eWIe3KRLvuE0wPyE0L90qOg== X-Received: by 10.28.62.144 with SMTP id l138mr5597527wma.50.1488980808275; Wed, 08 Mar 2017 05:46:48 -0800 (PST) Received: from [192.168.1.101] ([41.251.2.162]) by smtp.gmail.com with ESMTPSA id v3sm4264325wrb.39.2017.03.08.05.46.38 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 08 Mar 2017 05:46:46 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_C3471FC4-429A-4404-8078-3D48D6A704F9"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Aaron Zauner In-Reply-To: <59A14FBC-9208-42D5-9A1F-86DC7F665C5F@inria.fr> Date: Wed, 8 Mar 2017 13:46:34 +0000 Message-Id: <3BABC7EA-37F3-4043-8BBF-04B7D3882909@azet.org> References: <81377754-e24d-269d-0f48-ba37e55f8942@eff.org> <22DB918C-015D-48C8-9A5E-1D4BDC57DC84@azet.org> <20170303222502.GD31407@eff.org> <4816CEB7-A2A6-4DA2-800B-EBEFE8B3472F@azet.org> <59A14FBC-9208-42D5-9A1F-86DC7F665C5F@inria.fr> To: Nadim Kobeissi X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Peter Eckersley , Martin Thomson , Jacob Hoffman-Andrews , "acme@ietf.org" Subject: Re: [Acme] HPKP in ACME X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 13:46:51 -0000 --Apple-Mail=_C3471FC4-429A-4404-8078-3D48D6A704F9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 07 Mar 2017, at 12:13, Nadim Kobeissi = wrote: >=20 >>=20 >> On Mar 4, 2017, at 12:24 PM, Aaron Zauner wrote: >>=20 >>=20 >>> On 03 Mar 2017, at 22:25, Peter Eckersley wrote: >>>=20 >>> On Fri, Mar 03, 2017 at 11:53:49AM +0000, Aaron Zauner wrote: >>>>=20 >>>>> On 13 Feb 2017, at 19:33, Jacob Hoffman-Andrews = wrote: >>>>>=20 >>>>> Martin brought up a section I've been considering removing: >>>>>=20 >>>>>> Clients SHOULD support HTTP public key pinning [RFC7469], and = servers >>>>> SHOULD emit pinning headers. >>>>>=20 >>>>> Here's my reasoning: >>>>>=20 >>>>> - Public key pinning isn't implemented in most HTTPS libraries = outside >>>>> of browsers, so this is a considerable burden on implementers. >>>>> - Public key pinning carries a fairly high risk of footgunning. = The >>>>> consequence of a failed pin for a CA that serves many ACME clients = would >>>>> be that some of those clients would fail to renew their certs, = causing >>>>> cascading breakage. >>>>> - There is relatively little confidential information conveyed in = ACME, >>>>> and there are other defenses built into ACME (like including the = account >>>>> key as part of the challenge data), so HPKP is not strongly = necessary. >>>>>=20 >>>>> Any objections? >>>>=20 >>>> I was the person who initially suggested adding HPKP, that was more = than two >>>> years ago. People get HPKP headers wrong constantly and thus lock = themselves >>>> or their users out of services, missing library support is - as you = point >>>> out - a problem and I don't see much interest within the community = to add >>>> HPKP. By now I consider HPKP failed tech. to be honest. >>>=20 >>> I don't think we should give up on HPKP completely just yet; the = thing that's >>> missing for site operators is a better toolchain for getting it = right that >>> protects against errors by humans in the loop. >>=20 >> It be cool if e.g. Certbot would reliably do that for Let's Encrypt = users, I agree. But in general it seems that there's little interest by = site operators (except really big ones) to actually deploy HPKP and, = even more, maintain it. It seems to me that this isn't a knowledge gap, = sys admins are well aware what the consequences are if they get pins = wrong. I'm not aware of any project that automates this reliably at this = time. >=20 > The nice thing about HPKP is that it allows site operators to do a = strong assert on the authenticity of a bunch of certificates aside from = the current one. Yea, again: I was the person that proposed adding HPKP in the first = place. > As far as I know, this is the only simple currently available = mechanism that would allow site operators to suddenly switch certificate = and even certificate authorities without that switch being sudden and = not backed up by some publicly verifiable chain of authenticity. Another = cool side-note is that this chain of authenticity, if maintained = throughout a bunch of HPKP-backed certificate rotations, becomes = controlled more by the site operator themselves than the CA, which is = interesting. I think you're confusing HPKP with TACK. TACK had unique potential = (especially for having more control on [perceived] trust for site = operators). HPKP is a dummbed-down version of TACK fitted for HTTP = headers, which turns out to have almost zero deployment. I'm not saying = that TACK would have been the ultimate thing that would have gotten = wide-spread deployment, but it would certainly have been easier to = integrate that from the beginning with -- say -- server daemons and just = deploy it via package upgrades. It's also much less likely that = operators will DoS their services by mis-using pins with TACK. >=20 > Specifically since it is possibly the unique mechanism in which this = can be accomplished, I think it deserves being kept for future = integration, or at least not discounted so early on. >=20 > In my mind, HPKP integration into ACME is a matter of pooling = engineering time. Integration can wait until, say, Let=E2=80=99s Encrypt = engineers feel they have time on their hands, but the entire idea of = HPKP shouldn=E2=80=99t be put down prematurely. It has unique potential. Anyway, I feel that discussion on the whole topic isn't really = productive anymore here. We all agree that HPKP has it's problems and = there doesn't seem to be a timeline for integration in Certbot. As for = the ACME spec.: I think we could go with OPTIONAL, but I have no = problems with removing the paragraph. Aaron --Apple-Mail=_C3471FC4-429A-4404-8078-3D48D6A704F9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYwAs7AAoJEOTbZJL9ubXVj/cP/ibbK8lYl9or6cG+I7sa7jGR 9bxPyY+ki7rbOjCZfCbLNFQEU4U+Pt4LcxEZgPuO2KqU6koopH7zSOHMj+Ib9VyI QhaOj/6tKB7MM938/NR3k+LBENP5mZL01XFcS+NXodFpvl6E162PJEJjBfStCoVb BOY2LJhMKqXfXHVDjDe2gVQ7iupnJA2gj8NPxr1yMLVYJ5r5l/zUikI7kN6+ik0K h260eyXL8X6nkH2ZABh9/RSxERqRx2Fs5uIb1sgiMiu63fF12S32iv4n8+2uPTsj hLlLHWe2fxqdO9EDTK/jFxCUr0INfkfk7tpOd90UzWha+E4+UqfPIvNlXEDXAqPM buWsQMVvhsf/zbeJkqmmdtb520pOWBEtrIa/dkjCev5UgzUFK+mNIcFl6kNwttAI pF4KX0gkiRFqCskznpbaZEc63K54YqgpIhOsBCKCZvIAJI3gFWefvO866KT7DjQ5 PC8s7pdSC1u/EJsxGEAu+NUOdJlbmU01+yszVtsnHxKm9au2/ww6rO2exQ+8cknk N3hlv9xf9U/86ImX+bozpxx8svgF7kVantmXEyZjNSMOdRcKsXdtA5DUMt4Txhan C+iQcobgVDTrRYH4bHDni2IH4HvVcOBreapYp3/CrlC84dA/fY8f2Pdig4Xdcd3G u/PKmBAc8K4Y1yYpmGi+ =kTjM -----END PGP SIGNATURE----- --Apple-Mail=_C3471FC4-429A-4404-8078-3D48D6A704F9-- From nobody Sun Mar 12 08:53: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 DA917129491 for ; Sun, 12 Mar 2017 08:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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] 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 kmG0UDEkNCoJ for ; Sun, 12 Mar 2017 08:53:16 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::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 757BD129519 for ; Sun, 12 Mar 2017 08:53:16 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id v203so4834667wmg.0 for ; Sun, 12 Mar 2017 08:53:16 -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=WnwrE5xR2x6PSRuuzXyouriMtNDM9xolzeLMi0D0aNc=; b=vYYma0v0ejZ+m21PG9yyYIzoLUwpfDQs3EvXCFtpr6VNLgSR1DMA8ddbNhndNj5G+D 9m/SfvNvXzu00MnPNORUivEYfBVCP/AGfyBmiRm1VYCQ17BVDcR+9uZgJoPHlEOXb7bZ t43c6B82AFlgpzKTy3xCyKneDtDe6iz82EH2F4F2NFoA2FHy1aQ2dn7K5AMSvKKrINwr 5bJSOMGkVG6M1jYP+XqyEY2WEKeZ/BJH86l+GMwxTYDMMOOES4kxDWqqY6F31OO7vveT nc+xEiPaD7MAQ6f64ARjzT39WSVnEQ8/B9k1TlYmjk1feK2t2OrOYOhVUY8Ij5+29vdT FG/w== 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=WnwrE5xR2x6PSRuuzXyouriMtNDM9xolzeLMi0D0aNc=; b=dqS24JdJJK+u5lkEH78sbUM2npoQmctaSL3Pl1is0Y2mra9dx3Q9rt6jD0WBy3D56Y DFYDlhJX+5qSWbvPXrEFu4PVYWNHreP36wB9Y4ShJb1G+zOprud+eo+ckkwdWZt6p8of got3hNT5dsUtWhQljuzcPFfIrkOYDKfb8V+jOgcaR7mTdKPWxhb6+kCy3ReG710PeX2S vYk869H9uJafp5K+V+y+s0zKseT2auFJT/lWKQS7zLg3Fh/ELzxS38s0rs1sHC2gZWC+ zndQFLIZRm4hWIFz4un7tWzkObY809hEsU4C4XL8IMEPsmFZUEUCzR2aoULzB57bosDX zzcQ== X-Gm-Message-State: AFeK/H2AFDeyub8TzTyyLiNlkirEehNDl1C+rxw5Yph+H54E49suAC8YV/HhxCpn+s77B/a2XyuxJ7p/8vP6aA== X-Received: by 10.28.156.69 with SMTP id f66mr6577747wme.56.1489333994405; Sun, 12 Mar 2017 08:53:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.31.2 with HTTP; Sun, 12 Mar 2017 08:53:13 -0700 (PDT) In-Reply-To: <73bf64eceade46f896da9ad077ccc0bf@usma1ex-dag1mb1.msg.corp.akamai.com> References: <73bf64eceade46f896da9ad077ccc0bf@usma1ex-dag1mb1.msg.corp.akamai.com> From: Richard Barnes Date: Sun, 12 Mar 2017 11:53:13 -0400 Message-ID: To: "Salz, Rich" Content-Type: multipart/alternative; boundary=001a114b7e2ab05867054a8a97b7 Archived-At: Cc: Logan Widick , "acme@ietf.org" , Martin Thomson Subject: Re: [Acme] Hash algorithms for challenges X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 15:53:18 -0000 --001a114b7e2ab05867054a8a97b7 Content-Type: text/plain; charset=UTF-8 +1 On Wed, Mar 8, 2017 at 8:00 AM, Salz, Rich wrote: > > I would rather see new challenges defined with a new hash function than > > introduce orthogonal hash negotiation. > > Speaking as an individual, I strongly agree with this. > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > --001a114b7e2ab05867054a8a97b7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1

On Wed, Mar 8, 2017 at 8:00 AM, Salz, Rich &l= t;rsalz@akamai.com> wrote:
>= I would rather see new challenges defined with a new hash function than > introduce orthogonal hash negotiation.

Speaking as an individual, I strongly agree with this.

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

--001a114b7e2ab05867054a8a97b7-- From nobody Sun Mar 12 12:11: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 AA19C129430 for ; Sun, 12 Mar 2017 12:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.004 X-Spam-Level: X-Spam-Status: No, score=-7.004 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, RCVD_IN_MSPIKE_H2=-0.001, 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 SE4q3iWxpQey for ; Sun, 12 Mar 2017 12:11:21 -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 D8D81128B38 for ; Sun, 12 Mar 2017 12:11:21 -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=7tw37pmGXvAGkmCymMFJXA+6CfzChb5j9oheiyHvKJw=; b=ehs90DxaeSzxJOSTeDirVUJA4rcOkPabHOI4AoLzGILOUJUCt/GkDuV1o9ZFGohxEkEnRqKLVEw9lmO6KTYjZSXUh85eHzdxxlzUoaMQ3QeXqJ6Ia0+q5yFEg1OKzJUOCpyVrggtYAa3ilU86YQughm5m1q+8+iRGNUETEGb1hM=; Received: ; Sun, 12 Mar 2017 12:11:23 -0700 To: Hugo Landau , acme@ietf.org References: <20170208051557.GA1383@andover.lhh.devever.net> From: Jacob Hoffman-Andrews Message-ID: Date: Sun, 12 Mar 2017 12:11:19 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <20170208051557.GA1383@andover.lhh.devever.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Received-SPF: skipped for local relay Archived-At: Subject: Re: [Acme] Final thoughts on draft-ietf-acme-acme-05 X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 19:11:23 -0000 Thanks for the feedback, Hugo! And sorry I've taken so long to reply. I think most of your comments have been addressed in merged or active PRs. On 02/07/2017 09:15 PM, Hugo Landau wrote: > Finally, I may as well mention wildcard domains again. I don't really > get the aversion to standardizing this. I previously proposed that thes= e > be validated by n verification requests from a server to > randomly-generated, unguessable labels substituting for a wildcard. Thi= s > adequately proves that a wildcard is actually configured and that the > service located by it is under account control. These would be blind; > the hostnames used for the requests wouldn't be shown in the > authorization or challenge objects, so the client wouldn't know what > names would be used until the verification request comes in. Arguably, > though, even this is overkill, and just creating authorization objects > for unblinded, randomly generated names substituting for the wildcard > would suffice. (In fact, as far as I can tell, nothing in the current > spec actually prohibits doing this.) > > There are real applications for wildcard domains. For example, the > ability to create unlimited numbers of secure origins has real value to= > some classes of web application. Yep, I also think it would be nice to standardize wildcard issuance! Richard's introduction of the "new-order" flow was intended to make wildcard issuance at least possible, but there's still a big question mark about what authorizations a server *should* create. To some extent that is up to server policy, but I think it's worthwhile to recommend on option. Note that the CA/Browser Forum Ballot 169 validation rules indicated that validating the base domain is sufficient to issue a wildcard certificate, so we could just echo that. But my feeling of the group is that folks would like to define a standard way of validating wildcards that is better than that baseline. Also: I think wildcards are a big enough topic that it probably doesn't make sense to try and land any significant changes before the spec is finalized, but they would be a good follow-on spec. From nobody Sun Mar 12 12:11:53 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 9E9AF12949D for ; Sun, 12 Mar 2017 12:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.004 X-Spam-Level: X-Spam-Status: No, score=-7.004 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, RCVD_IN_MSPIKE_H2=-0.001, 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 VYXlQLcdRAld for ; Sun, 12 Mar 2017 12:11:50 -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 B1D25129484 for ; Sun, 12 Mar 2017 12:11:50 -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:MIME-Version:Date:Message-ID:Subject:From:To; bh=nJQko/qtH9TH/0njyVO7t63wRVPjTCt1eWo+qjYaxLM=; b=QDpT7Iz0N2WNUI7NrVRWRzgmgOR/07iKn0mx2rDuDo5PEBF3rIXT7mO9zgkdpgdQmUFusy5IskhhWtWbsJZGib/WG4cloU2Sf++EOmSlW1TdLjQnRADfFtjP55x4eI96uJcY2n/8ekPk9Ukk4SJ4sglzebmHkDwtpvA6Zu506fA=; Received: ; Sun, 12 Mar 2017 12:11:52 -0700 To: "acme@ietf.org" From: Jacob Hoffman-Andrews Message-ID: <7f7ec33f-0c84-d1df-c5b3-1016445f2f37@eff.org> Date: Sun, 12 Mar 2017 12:11:50 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Received-SPF: skipped for local relay Archived-At: Subject: [Acme] Remove new-authz fields "existing" and "accept". #275 X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 19:11:51 -0000 https://github.com/ietf-wg-acme/acme/pull/275 Remove new-authz fields "existing" and "accept". #275 I believe they are unnecessary. The server can set its own policy on whether to give back an existing or a new authz, and the client can choose to accept or reject that. Hugo also pointed out on-list that the status codes for these are inconsistent with the status codes for new-account. If we keep these, we'd want to fix that. But simpler to delete, I think. From nobody Sun Mar 12 12:35: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 1AE9E1293F4 for ; Sun, 12 Mar 2017 12:35:55 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, 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 b1-kxF8AmVZq for ; Sun, 12 Mar 2017 12:35:53 -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 9B2781293D6 for ; Sun, 12 Mar 2017 12:35:53 -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:Cc:References:To:Subject; bh=PvtSeScL3bSgr377OvbkU+i8ybbl4zG71f/4O8UI0dY=; b=KjolZoSz5yivya9i29XnvvR8lmhiOBSIvsH0kQS1Ir74jJqqMP2PSp2+v9apvr+cEw/hg1ejK+YQUnvs3xqd1McYA/A+rzu0DpACLuQPbdTMEsMDMkpZZb47YhEqEwbCXYA/HgKKNh+6qReMTzdj8yvkZ9lXAJubiE4+8UEBm8E=; Received: ; Sun, 12 Mar 2017 12:35:54 -0700 To: Clint Wilson , "Salz, Rich" , Richard Barnes , Daniel McCarney References: <9baa4aca-120c-4ce8-b118-68dca3917f57@eff.org> <937ffb4e61f745fd844e2c5a04ce26b5@usma1ex-dag1mb3.msg.corp.akamai.com> From: Jacob Hoffman-Andrews Message-ID: <7224f87c-996a-1ab4-1656-204d8067f885@eff.org> Date: Sun, 12 Mar 2017 12:35:50 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------DBFFC8AC9166ED620F7B6C39" Received-SPF: skipped for local relay Archived-At: Cc: "acme@ietf.org" Subject: Re: [Acme] Registering a PEM Content-Type X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 19:35:55 -0000 This is a multi-part message in MIME format. --------------DBFFC8AC9166ED620F7B6C39 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit I've got a PR adding application/pem-certificate-chain: https://github.com/ietf-wg-acme/acme/pull/276. Note that I chose "pem-certificate-chain" rather than "pem-cert-list", because it has different semantics. A certificate chain MUST start with an end-entity certificate, while a certificate list (which has no MIME type defined at present) can have any type of certificates in any order. For instance, it's common to have a list of trust anchors in PEM format concatenated in a single file. That would be considered a "certificate list" but not a "certificate chain." What do you all think? Thanks, Jacob On 02/16/2017 06:57 PM, Clint Wilson wrote: > > +1 for application/pem-cert-list. > > > On Thu, Feb 16, 2017, 5:11 PM Salz, Rich > wrote: > > I think you need application/pem-cert-list, which is a collection > of PEM certificates as defined in RFC 7468. > > Should be easy to add that as an appendix to the draft. > > I suggest cert-list not chain, to show that no ordering is implied. > > _______________________________________________ > 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 --------------DBFFC8AC9166ED620F7B6C39 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit I've got a PR adding application/pem-certificate-chain: https://github.com/ietf-wg-acme/acme/pull/276.

Note that I chose "pem-certificate-chain" rather than "pem-cert-list", because it has different semantics. A certificate chain MUST start with an end-entity certificate, while a certificate list (which has no MIME type defined at present) can have any type of certificates in any order. For instance, it's common to have a list of trust anchors in PEM format concatenated in a single file. That would be considered a "certificate list" but not a "certificate chain."

What do you all think?

Thanks,
Jacob

On 02/16/2017 06:57 PM, Clint Wilson wrote:

+1 for application/pem-cert-list.


On Thu, Feb 16, 2017, 5:11 PM Salz, Rich <rsalz@akamai.com> wrote:
I think you need application/pem-cert-list, which is a collection of PEM certificates as defined in RFC 7468.

Should be easy to add that as an appendix to the draft.

I suggest cert-list not chain, to show that no ordering is implied.

_______________________________________________
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

--------------DBFFC8AC9166ED620F7B6C39-- From nobody Sun Mar 12 12:50: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 5179B1294DD for ; Sun, 12 Mar 2017 12:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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, RP_MATCHES_RCVD=-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=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 Sietj79rNBZv for ; Sun, 12 Mar 2017 12:50:42 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 60F461294C7 for ; Sun, 12 Mar 2017 12:50:42 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 17BBE16C5A0; Sun, 12 Mar 2017 19:50:42 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 0237B16C3DA; Sun, 12 Mar 2017 19:50:42 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1489348242; bh=zaRtVswYGG3ol6+B3rGcLxXNvKA5UyJ1z6v+c9IHtj4=; l=203; h=From:To:CC:Date:References:From; b=mpLgKcHzrWZwV4++nKRsZWMTxJwGDiqtkEX7zKWPtA41gU271Y7njds4tiAcxK6lH 0NGq6X8y97K6r3dGaokSzNKb59wu6r3FP/rzJlz+wxOQALvrH6ojQgGY+Ikf3Cjnbg cAD3QLg4Kw4xkIxypKz/DDUiHaGVtjEvgkgo4lso= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.33]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id DAFA91E07C; Sun, 12 Mar 2017 19:50:41 +0000 (GMT) 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.1178.4; Sun, 12 Mar 2017 15:50:41 -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.1178.000; Sun, 12 Mar 2017 15:50:41 -0400 From: "Salz, Rich" To: Jacob Hoffman-Andrews , Richard Barnes , "Daniel McCarney" Thread-Topic: [Acme] Registering a PEM Content-Type Thread-Index: AQHShkNQI/CXO86iJ0icYl1s5L6d5aFsgPAAgAAR3oCAAAWdAP//v3KQgCVvVUA= Date: Sun, 12 Mar 2017 19:50:40 +0000 Message-ID: <0af75256fcfd40b580b8e5696d8b0e00@usma1ex-dag1mb1.msg.corp.akamai.com> References: <9baa4aca-120c-4ce8-b118-68dca3917f57@eff.org> 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.38.189] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "acme@ietf.org" Subject: Re: [Acme] Registering a PEM Content-Type X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 19:50:43 -0000 What about saying each certificate SHOULD be a signer on *A* preceding cert= ificate? This allows us to serve a single cert chain for both MD5 and SHA= 1, for example. (Contrived examples of course.) From nobody Sun Mar 12 12:54: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 15B131294EC for ; Sun, 12 Mar 2017 12:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.004 X-Spam-Level: X-Spam-Status: No, score=-7.004 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, RCVD_IN_MSPIKE_H2=-0.001, 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 7i9K8F2nrpee for ; Sun, 12 Mar 2017 12:54: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 54D2B1294C7 for ; Sun, 12 Mar 2017 12:54: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:Cc:References:To:Subject; bh=AvQok9m4hKjZ0sON0vd4OYsnoxrCeWQNh3XPT8f81uM=; b=Izgovha28WWpnVF7HTLDbwTQV/xDGEs6Y7Vp+exMTs2hQfGN2+vacWFsd4YVtLjRqS69M8yRE1IELEjw+QIfncv7ENdzuNhvwmBwQoKjkdNoBxfC7YYrn3PfqxQwVhBOmsE5XALA859u1ZJGKj0Yn+Er62tYAYWo+C9aVGinVBM=; Received: ; Sun, 12 Mar 2017 12:54:28 -0700 To: "Salz, Rich" , Richard Barnes , Daniel McCarney References: <9baa4aca-120c-4ce8-b118-68dca3917f57@eff.org> <0af75256fcfd40b580b8e5696d8b0e00@usma1ex-dag1mb1.msg.corp.akamai.com> From: Jacob Hoffman-Andrews Message-ID: <5a413c90-e2d6-12c8-174f-540fed9b7a58@eff.org> Date: Sun, 12 Mar 2017 12:54:25 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <0af75256fcfd40b580b8e5696d8b0e00@usma1ex-dag1mb1.msg.corp.akamai.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Received-SPF: skipped for local relay Archived-At: Cc: "acme@ietf.org" Subject: Re: [Acme] Registering a PEM Content-Type X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 19:54:28 -0000 On 03/12/2017 12:50 PM, Salz, Rich wrote: > What about saying each certificate SHOULD be a signer on *A* preceding certificate? This allows us to serve a single cert chain for both MD5 and SHA1, for example. (Contrived examples of course.) I think the current language (copied from TLS 1.3) conveys that, though it's a bit subtle: > Each following certificate SHOULD directly certify one preceding it. From nobody Sun Mar 12 13:11:14 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 68368129503 for ; Sun, 12 Mar 2017 13:11:13 -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 QLanhPT3hzmh for ; Sun, 12 Mar 2017 13:11:11 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id F0AFE12941C for ; Sun, 12 Mar 2017 13:11:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id DFDA21E72B; Sun, 12 Mar 2017 22:11:08 +0200 (EET) 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-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id 3PwFPrZFtg6J; Sun, 12 Mar 2017 22:11:08 +0200 (EET) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 7FCB22310; Sun, 12 Mar 2017 22:11:08 +0200 (EET) Date: Sun, 12 Mar 2017 22:11:01 +0200 From: Ilari Liusvaara To: Jacob Hoffman-Andrews Message-ID: <20170312201101.GA14981@LK-Perkele-V2.elisa-laajakaista.fi> References: <20170208051557.GA1383@andover.lhh.devever.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Cc: acme@ietf.org, Hugo Landau Subject: Re: [Acme] Final thoughts on draft-ietf-acme-acme-05 X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 20:11:13 -0000 On Sun, Mar 12, 2017 at 12:11:19PM -0700, Jacob Hoffman-Andrews wrote: > Thanks for the feedback, Hugo! And sorry I've taken so long to reply. I > think most of your comments have been addressed in merged or active PRs. > > On 02/07/2017 09:15 PM, Hugo Landau wrote: > > Finally, I may as well mention wildcard domains again. I don't really > > get the aversion to standardizing this. I previously proposed that these > > be validated by n verification requests from a server to > > randomly-generated, unguessable labels substituting for a wildcard. This > > adequately proves that a wildcard is actually configured and that the > > service located by it is under account control. These would be blind; > > the hostnames used for the requests wouldn't be shown in the > > authorization or challenge objects, so the client wouldn't know what > > names would be used until the verification request comes in. Arguably, > > though, even this is overkill, and just creating authorization objects > > for unblinded, randomly generated names substituting for the wildcard > > would suffice. (In fact, as far as I can tell, nothing in the current > > spec actually prohibits doing this.) > > > > There are real applications for wildcard domains. For example, the > > ability to create unlimited numbers of secure origins has real value to > > some classes of web application. > Yep, I also think it would be nice to standardize wildcard issuance! > Richard's introduction of the "new-order" flow was intended to make > wildcard issuance at least possible, but there's still a big question > mark about what authorizations a server *should* create. To some extent > that is up to server policy, but I think it's worthwhile to recommend on > option. > > Note that the CA/Browser Forum Ballot 169 validation rules indicated > that validating the base domain is sufficient to issue a wildcard > certificate, so we could just echo that. But my feeling of the group is > that folks would like to define a standard way of validating wildcards > that is better than that baseline. Actually, AFAICT, Ballot 169 rules say something stronger for connection-based methods: Wildcards are validated via base domain. And all ACME methods are connection-based. So from viewpoint of ACME, wildcards are validated by contacting the name identified by stripping the '*.' from beginning. And when it comes to interaction with PSL, the resulting name can be 'PRIVATE' but not 'ICANN'. One pretty obvious thing is strongly splitting challenge responses, so that there is no way wildcard and non-wildcard challenge responses can be mixed up (I think TLS-SNI is the hardest here, as DNS and HTTP are just dumb textual fields)... -Ilari From nobody Sun Mar 12 14:20:14 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 9F911129415 for ; Sun, 12 Mar 2017 14:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.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 bqMnBZoRtuO9 for ; Sun, 12 Mar 2017 14:20:09 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::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 88B171293FB for ; Sun, 12 Mar 2017 14:20:09 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id v198so49305591ywc.2 for ; Sun, 12 Mar 2017 14:20:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kPBbVGkD6kFhiF1Knzgtcl8sWEPnApRWRYdHknElY8Q=; b=n0xc9H8UQT2V6UoF/U5/q2yclqgRHfF8kIwZFmDt1AtgQVg9UT//GIhe2BxkbW8DYy JErwzCVW+UeikJvBv1bj7Uw8xLLyJ2Z8W/UKf/e+iHnCH5Gq2xvT0WnWH1gSoAlWUI5g qtSjDUTGZ1B0RB9SagbKsm5sLqBc3Nut4a0b8wtNOqpYuc76Z0DljKAXC/yoFQTgKDft mHiVluOmnk6SKQe8WmNJt96ltjv2hN9LTkkbXzKxPSnmphMVy8PXyGULhs1Rsa2Tb58X upiI2XqXzdc0xYkKpMgJbI/lGZ7wCmUlXsuDv25QePgKh5IHi6jXekQmzCU+Rl0mQauA IY/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=kPBbVGkD6kFhiF1Knzgtcl8sWEPnApRWRYdHknElY8Q=; b=s1p7SYQ+O5hm1SZ/hnLBtG3/EUJfht+G6hbq8j3usxanPYBGhiy89a6dkDZA0itVRC j641Qd2sgUpFbEwE/IkzntrsMP1xX+g02P0WQuCgvFIrZ4R05qLbmaILvj4krqDl3/vB H/VmAiS3ODRuVby6fCTpmWMJwUF8xDKgD0cwqcMr3QDDiFrXrh+jkG73yLB0vEkhXLLU XAhGsARt9V95M9ZHil+Q2bDX8dTfCkcc01izvsk6x4cnYjD17TX92Y3QF30jmO0rvWOm LYj5bF3Py6wQO+IuVAFlGiRqjpDOylTF03J8rnPV/NY2fgyLL4iiO4oOfB2LpW1ebypw zX4Q== X-Gm-Message-State: AMke39mjr+po1jSBXcx5UXXABNm6VdL6TCeLDbZJcwCOTZyDlAUINsoVt7VGgeK551mL6iJE01RwkFJOKu06OA== X-Received: by 10.129.125.5 with SMTP id y5mr14868299ywc.120.1489353608717; Sun, 12 Mar 2017 14:20:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Sun, 12 Mar 2017 14:19:28 -0700 (PDT) In-Reply-To: <5a413c90-e2d6-12c8-174f-540fed9b7a58@eff.org> References: <9baa4aca-120c-4ce8-b118-68dca3917f57@eff.org> <0af75256fcfd40b580b8e5696d8b0e00@usma1ex-dag1mb1.msg.corp.akamai.com> <5a413c90-e2d6-12c8-174f-540fed9b7a58@eff.org> From: Eric Rescorla Date: Sun, 12 Mar 2017 14:19:28 -0700 Message-ID: To: Jacob Hoffman-Andrews Content-Type: multipart/alternative; boundary=001a11493644cb359b054a8f2852 Archived-At: Cc: Richard Barnes , "Salz, Rich" , "acme@ietf.org" , Daniel McCarney Subject: Re: [Acme] Registering a PEM Content-Type X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 21:20:13 -0000 --001a11493644cb359b054a8f2852 Content-Type: text/plain; charset=UTF-8 On Sun, Mar 12, 2017 at 12:54 PM, Jacob Hoffman-Andrews wrote: > On 03/12/2017 12:50 PM, Salz, Rich wrote: > > What about saying each certificate SHOULD be a signer on *A* preceding > certificate? This allows us to serve a single cert chain for both MD5 and > SHA1, for example. (Contrived examples of course.) > I think the current language (copied from TLS 1.3) conveys that, though > it's a bit subtle: > > > Each following certificate SHOULD directly certify one preceding it. > Note: this used to be a MUST-level requirement, but due to the complexities of the deployed PKI, in 1.3 it was relaxed to be a SHOULD. -Ekr > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > --001a11493644cb359b054a8f2852 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Mar 12, 2017 at 12:54 PM, Jacob Hoffman-Andrews <jsha@eff.org&g= t; wrote:
On 03/1= 2/2017 12:50 PM, Salz, Rich wrote:
> What about saying each certificate SHOULD be a signer on *A* preceding= certificate?=C2=A0 This allows us to serve a single cert chain for both MD= 5=C2=A0 and SHA1, for example.=C2=A0 (Contrived examples of course.)
I think the current language (copied from TLS 1.3) conveys that, tho= ugh
it's a bit subtle:

> Each following certificate SHOULD directly certify one preceding it.

Note: this used to be a MUST-level requi= rement, but due to the complexities of the deployed
PKI, in 1.3 i= t was relaxed to be a SHOULD.

-Ekr

<= /div>

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

--001a11493644cb359b054a8f2852-- From nobody Sun Mar 12 15: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 185E0129468 for ; Sun, 12 Mar 2017 15:03:16 -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, SPF_FAIL=0.001, SPF_HELO_PASS=-0.001] autolearn=no 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 Gw4Ot9wWO61S for ; Sun, 12 Mar 2017 15:03:14 -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 4222812945F for ; Sun, 12 Mar 2017 15:03:14 -0700 (PDT) Received: from host249.freudenhaus.alandoherty.net ([193.120.128.249]:4193 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 1cnBZz-0007x3-Vo ; Sun, 12 Mar 2017 22:03:09 +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: Sun, 12 Mar 2017 22:03:05 +0000 To: Jacob Hoffman-Andrews ,Hugo Landau , acme@ietf.org From: Alan Doherty In-Reply-To: References: <20170208051557.GA1383@andover.lhh.devever.net> 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] Final thoughts on draft-ietf-acme-acme-05 X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 22:03:16 -0000 i think to issue wildcards (with minimal issues for validation, but direct owner allow/dissalow) some well-known-subdomain could be used example acme-wildcard-auth.parent.tld must exist for *.parent.tld to be applied for or acme-wildcard-CAuniquestring-auth.parent.tld if you want to make it possible to pre allow 1 or more acme-CA(s) only the ip it points to can then be used in http/tls-sni and dns-based auth obviously can use same (but requires no ip) thus domains without this sub-domain cant (as by not creating it they do not wish to use acme to register wildcards) as the domain would then require the admin of domain.tld to set it up in advance (but once) for the use by an acme-client thats using http auth for example (as this would match both real wildcards in dns, and those like myself wanting to use wildcards to cut down on oversize san certs where 90 sites are from 1 parent domain and the others are all unique (as it cuts the names in the san by 89 leaving room for more unique sites) At 19:11 12/03/2017 Sunday, Jacob Hoffman-Andrews wrote: >Thanks for the feedback, Hugo! And sorry I've taken so long to reply. I >think most of your comments have been addressed in merged or active PRs. > >On 02/07/2017 09:15 PM, Hugo Landau wrote: >> Finally, I may as well mention wildcard domains again. I don't really >> get the aversion to standardizing this. I previously proposed that these >> be validated by n verification requests from a server to >> randomly-generated, unguessable labels substituting for a wildcard. This >> adequately proves that a wildcard is actually configured and that the >> service located by it is under account control. These would be blind; >> the hostnames used for the requests wouldn't be shown in the >> authorization or challenge objects, so the client wouldn't know what >> names would be used until the verification request comes in. Arguably, >> though, even this is overkill, and just creating authorization objects >> for unblinded, randomly generated names substituting for the wildcard >> would suffice. (In fact, as far as I can tell, nothing in the current >> spec actually prohibits doing this.) >> >> There are real applications for wildcard domains. For example, the >> ability to create unlimited numbers of secure origins has real value to >> some classes of web application. >Yep, I also think it would be nice to standardize wildcard issuance! >Richard's introduction of the "new-order" flow was intended to make >wildcard issuance at least possible, but there's still a big question >mark about what authorizations a server *should* create. To some extent >that is up to server policy, but I think it's worthwhile to recommend on >option. > >Note that the CA/Browser Forum Ballot 169 validation rules indicated >that validating the base domain is sufficient to issue a wildcard >certificate, so we could just echo that. But my feeling of the group is >that folks would like to define a standard way of validating wildcards >that is better than that baseline. > >Also: I think wildcards are a big enough topic that it probably doesn't >make sense to try and land any significant changes before the spec is >finalized, but they would be a good follow-on spec. > >_______________________________________________ >Acme mailing list >Acme@ietf.org >https://www.ietf.org/mailman/listinfo/acme From nobody Sun Mar 12 15:46: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 DF97C1293E3 for ; Sun, 12 Mar 2017 15:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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, RP_MATCHES_RCVD=-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=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 X-_p2bjXkRBO for ; Sun, 12 Mar 2017 15:46:07 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 026A8126D74 for ; Sun, 12 Mar 2017 15:46:06 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 70E1020001F; Sun, 12 Mar 2017 22:46:06 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 59ABE200010; Sun, 12 Mar 2017 22:46:06 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1489358766; bh=g7WaxL7vuQRLi0DZatJzk3AzVaBJ5bUQFkjkSxKbK0g=; l=108; h=From:To:CC:Date:References:In-Reply-To:From; b=vKwereXJbstRtNO9RHl7HGRzB75z3LX9nwxv75Q9q8C+JuMRcmN5iznLPdt7Govi9 p657w96kHPD+F/qX3/FQHHx+CUNb4s6lPPK40KEAxMAbgJQUdQ5ApCJ0ySw8RJoZCk hkipJArILWelpcPzP2GpmhvagG8TBtMvgXzy8H4c= Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 3F0A31E07C; Sun, 12 Mar 2017 22:46:06 +0000 (GMT) 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.1178.4; Sun, 12 Mar 2017 18:46:05 -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.1178.000; Sun, 12 Mar 2017 18:46:05 -0400 From: "Salz, Rich" To: Jacob Hoffman-Andrews , Richard Barnes , "Daniel McCarney" Thread-Topic: [Acme] Registering a PEM Content-Type Thread-Index: AQHShkNQI/CXO86iJ0icYl1s5L6d5aFsgPAAgAAR3oCAAAWdAP//v3KQgCVvVUCAAEQ8gP//7MSg Date: Sun, 12 Mar 2017 22:46:05 +0000 Message-ID: <68043b5d81a54b58a63081e8b558e5bc@usma1ex-dag1mb1.msg.corp.akamai.com> References: <9baa4aca-120c-4ce8-b118-68dca3917f57@eff.org> <0af75256fcfd40b580b8e5696d8b0e00@usma1ex-dag1mb1.msg.corp.akamai.com> <5a413c90-e2d6-12c8-174f-540fed9b7a58@eff.org> In-Reply-To: <5a413c90-e2d6-12c8-174f-540fed9b7a58@eff.org> 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.38.189] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "acme@ietf.org" Subject: Re: [Acme] Registering a PEM Content-Type X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 22:46:08 -0000 > > Each following certificate SHOULD directly certify one preceding it. Okay. Overly terse but fine.:) From nobody Mon Mar 13 11:26: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 680151299FE for ; Mon, 13 Mar 2017 11:26:37 -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, RCVD_IN_MSPIKE_H2=-0.001, 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 zDoVxbh-32-M for ; Mon, 13 Mar 2017 11:26:31 -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 9A8A41299F1 for ; Mon, 13 Mar 2017 11:26:31 -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:MIME-Version:Date:Message-ID:Subject:From:To; bh=LqjESu6RGBmITndiME1rgsmzTTnu7EE8aXcIubJtq80=; b=RLqPQzX3T5dGXx+yC7V5dD4qGG5wldGUMMFdhx7S8rR/4EnxeTjHS0u2XU62kB+AjXTCR0qjEbCeL41T04I4vVKFkrkDErxaX3xwiSSHrlYPTdv42JMRkZ705UWtcKjxS31iQn78XhDExqFwyWEPfu7TpgRSvbz+YvElpfPDA2s=; Received: ; Mon, 13 Mar 2017 11:26:33 -0700 To: "acme@ietf.org" From: Jacob Hoffman-Andrews Message-ID: Date: Mon, 13 Mar 2017 11:26:30 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Received-SPF: skipped for local relay Archived-At: Subject: [Acme] Challenge names in final RFC X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 18:26:37 -0000 Roland posted a PR tweaking the challenge names for the final RFC: https://github.com/ietf-wg-acme/acme/pull/272. This raised the question: What do we want the challenge names to be in the final RFC? I think we've been assuming that "http-01" would become "http" once the RFC is published. However, this does create a slightly deployment headache, in that draft-compatible implementations have to use one name, and RFC-compatible implementations have to use another, so it's hard to test working code with the final names before the RFC is really finalized. I don't have a strong opinion on this one way or another. What do folks on this list think? From nobody Mon Mar 13 11:47:13 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 7A614129A5C; Mon, 13 Mar 2017 11:47:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148943083148.20272.5486065219597679474@ietfa.amsl.com> Date: Mon, 13 Mar 2017 11:47:11 -0700 Archived-At: Cc: acme@ietf.org Subject: [Acme] I-D Action: draft-ietf-acme-acme-06.txt X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.17 List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 18:47:11 -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 : Automatic Certificate Management Environment (ACME) Authors : Richard Barnes Jacob Hoffman-Andrews James Kasten Filename : draft-ietf-acme-acme-06.txt Pages : 71 Date : 2017-03-13 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's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-acme-acme-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-acme-06 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 Mon Mar 13 11:56: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 42050129A73 for ; Mon, 13 Mar 2017 11:56:52 -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 jOx1UuoFzWoa for ; Mon, 13 Mar 2017 11:56:49 -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 4C4B3129A6F for ; Mon, 13 Mar 2017 11:56:48 -0700 (PDT) Received: by mail-wr0-x22e.google.com with SMTP id l37so109983407wrc.1 for ; Mon, 13 Mar 2017 11:56:48 -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=PC/4acurmz0hSFq3Ycysin9gAzkmB0MxA/FoivJM8+E=; b=n+gKo5Yvbf297vZp42FfRannC+jYQhYsCnJMyBlt8OSS4yIEDEcWPTSdvv0xV3NI+E 1/jEz9+SSV0+Ihq6az4Z7xJ4H+qgpt9Uiy2VAsBKvKOyVrlqfa+YbyDVVZzVqZYvcs44 skJet3cZsnAGFezaCrm3drdX7yeDfVHAzGXd1i568EDGDfvCPJMhHdZBXEf5nf+Twc4s zT7eDzXdl8ZXByrAamJcNG2+pegCdcCWlrMxAlJ4Vs5WdC03GhG5JHPF8M0OivFVANGN gKyzyg6hBEDw/KaxcOnp3vOPSTp0dl4QHkSafd8ekhTI8MhawTTvFWE5KucwqywnjeLF tkCQ== 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=PC/4acurmz0hSFq3Ycysin9gAzkmB0MxA/FoivJM8+E=; b=FsJD67wfsGgCN5S5OgdJ31MGIQOTXSKHaSbXLDc37qLL/fGWfPdYCfAXEDEBXtSw93 DldbtPM7K4DEEJ/0cX5hZ+sxXeHpGVCbp4LyDbyDqDYfEFhc4K4sX73/PzIqQ4hOBrtk gCCQiFOkWkwYpuvmtv0ZjZlJezdnw+bbiqB7gHHpcmVfboJ5bYkSnUtuQZopMH3a1DEZ WJUBbORkqGLlWkh+HUxhzwcdpdEisQglK3Yr/X5Ytk+CouGcEJzMdVFy8zVBYaw9+tjp OdbEY4ae5xitsjSxWwFgGOS7YOkOZ22O9uazWs0+sKZQJPFvrlOu56kvSXdqTY1jnN9A NgFA== X-Gm-Message-State: AMke39nOgVmP9zwvMPVx5eNEIbsd1uwUsHtfb6W9TGUJv5CgNNcji7JcLkb66ywU4++hjn9uIynJU9KTsNzS1Q== X-Received: by 10.223.162.130 with SMTP id s2mr32259536wra.149.1489431406487; Mon, 13 Mar 2017 11:56:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.31.2 with HTTP; Mon, 13 Mar 2017 11:56:45 -0700 (PDT) Received: by 10.28.31.2 with HTTP; Mon, 13 Mar 2017 11:56:45 -0700 (PDT) In-Reply-To: References: From: Richard Barnes Date: Mon, 13 Mar 2017 14:56:45 -0400 Message-ID: To: Jacob Hoffman-Andrews Content-Type: multipart/alternative; boundary=f403045ea688e6bf13054aa145a3 Archived-At: Cc: acme@ietf.org Subject: Re: [Acme] Challenge names in final RFC X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 18:56:52 -0000 --f403045ea688e6bf13054aa145a3 Content-Type: text/plain; charset=UTF-8 I would prefer we stick with dropping the version number, just because it's cleaner and the future is bigger than the past. On Mar 13, 2017 2:27 PM, "Jacob Hoffman-Andrews" wrote: > Roland posted a PR tweaking the challenge names for the final RFC: > https://github.com/ietf-wg-acme/acme/pull/272. > > This raised the question: What do we want the challenge names to be in > the final RFC? I think we've been assuming that "http-01" would become > "http" once the RFC is published. However, this does create a slightly > deployment headache, in that draft-compatible implementations have to > use one name, and RFC-compatible implementations have to use another, so > it's hard to test working code with the final names before the RFC is > really finalized. > > I don't have a strong opinion on this one way or another. What do folks > on this list think? > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > --f403045ea688e6bf13054aa145a3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I would prefer we stick with dropping the version number,= just because it's cleaner and the future is bigger than the past. =C2= =A0


On Mar 13, 2017 2:27 PM, "Jacob Hoffman-Andrews&qu= ot; <jsha@eff.org> wrote:
Roland posted a PR tweaking= the challenge names for the final RFC:
https://github.com/ietf-wg-acme/acme/pull/272.=

This raised the question: What do we want the challenge names to be in
the final RFC? I think we've been assuming that "http-01" wou= ld become
"http" once the RFC is published. However, this does create a sli= ghtly
deployment headache, in that draft-compatible implementations have to
use one name, and RFC-compatible implementations have to use another, so it's hard to test working code with the final names before the RFC is really finalized.

I don't have a strong opinion on this one way or another. What do folks=
on this list think?

_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
--f403045ea688e6bf13054aa145a3-- From nobody Mon Mar 13 13:14:14 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 E14BD1294D2 for ; Mon, 13 Mar 2017 13:14:12 -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, 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 NHQuoPlsQvNW for ; Mon, 13 Mar 2017 13:14:11 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 514631294AC for ; Mon, 13 Mar 2017 13:14:11 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 8FE167A3309; Mon, 13 Mar 2017 20:14:10 +0000 (UTC) Date: Mon, 13 Mar 2017 20:14:10 +0000 From: Viktor Dukhovni To: "acme@ietf.org" Message-ID: <20170313201410.GG4095@mournblade.imrryr.org> References: <8473d9ba84894d49b2f2232370d66b46@usma1ex-dag1mb3.msg.corp.akamai.com> <20170307031510.GN7733@mournblade.imrryr.org> <20170307032023.GO7733@mournblade.imrryr.org> <9471a5323a98405eaf0ee111fb0350b0@usma1ex-dag1mb3.msg.corp.akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9471a5323a98405eaf0ee111fb0350b0@usma1ex-dag1mb3.msg.corp.akamai.com> User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [Acme] ACME draft is now in WGLC. X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: acme@ietf.org List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 20:14:13 -0000 On Tue, Mar 07, 2017 at 03:46:00AM +0000, Salz, Rich wrote: > > Specifically, it 10.3 use of DNSSEC is a RECOMMENDATION, not a > > requirement: > > > > https://tools.ietf.org/html/draft-ietf-acme-acme-05#section-10.3 > > > > I would have expected a requirement here. > > The WG consensus has been for recommendation. I've had complete disinterest in CAA which initially was accepted by CA/B forum as a "recommendation", which meant that the constraint was meaningless. Rumour has it that CAA will soon be a requirement, so I've now published CAA records. The CAA check is/was easy to make and crippling it by not making it a requirement was IMNSHO a mistake. Similarly, using a DNSSEC-capable resolver is by no means rocket science, much of the world is doing just that via Google's, Verisign's, ... open resolvers. Leaving the CAs wiggle-room to avoid what should be standard practice by now makes no sense. I urge the WG to reconsider. -- Viktor. From nobody Mon Mar 13 13:17: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 6388A129497 for ; Mon, 13 Mar 2017 13:17:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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, RP_MATCHES_RCVD=-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=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 wfuD6DZkZsLj for ; Mon, 13 Mar 2017 13:17:07 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id E92F512944F for ; Mon, 13 Mar 2017 13:17:06 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 4636A433434 for ; Mon, 13 Mar 2017 20:17:06 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 2F79D433431 for ; Mon, 13 Mar 2017 20:17:06 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1489436226; bh=YRqZMgurloRQNVCYaDCKF05iUJLNP7E5ctrXpktXXoU=; l=405; h=From:To:Date:References:In-Reply-To:From; b=lNBu5fgjYurgEbQOjgOla3GEr95P/9sZUYLPvsLxaZTEvvpZoYuTY1ULJxnOYQpsU U5JFcrexdKqw0/2KLJcTgWu6LWnqlUSJ3eL9X6rYE2OCvFBjQc5+mbGEFc1Pfs2in3 7Nm5gJG61c/P7afxaN1TTJ1N4HPLlLgCkXXPn6Qw= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.34]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 2B7181FC8D for ; Mon, 13 Mar 2017 20:17:06 +0000 (GMT) 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.1178.4; Mon, 13 Mar 2017 16:17:05 -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.1178.000; Mon, 13 Mar 2017 16:17:05 -0400 From: "Salz, Rich" To: "acme@ietf.org" Thread-Topic: [Acme] ACME draft is now in WGLC. Thread-Index: AdKBZ2LP4XWB1i0uR++KFKjfHhNLwgVs43eAAAAufoAACZkPwAFFdgwAAAhZUVA= Date: Mon, 13 Mar 2017 20:17:05 +0000 Message-ID: <12461433fb264865972e9ddafab1c511@usma1ex-dag1mb1.msg.corp.akamai.com> References: <8473d9ba84894d49b2f2232370d66b46@usma1ex-dag1mb3.msg.corp.akamai.com> <20170307031510.GN7733@mournblade.imrryr.org> <20170307032023.GO7733@mournblade.imrryr.org> <9471a5323a98405eaf0ee111fb0350b0@usma1ex-dag1mb3.msg.corp.akamai.com> <20170313201410.GG4095@mournblade.imrryr.org> In-Reply-To: <20170313201410.GG4095@mournblade.imrryr.org> 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.33.17] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Acme] ACME draft is now in WGLC. X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 20:17:08 -0000 > Rumour has it that CAA will soon be a requirement It just passed their balloting so CA/B forum now requires it. See the LAMP= S WG thread(s) on CAA erratum 4515. > The CAA check is/was easy to make and crippling it > by not making it a requirement was IMNSHO a mistake. ... > I urge the WG to reconsider. Does anyone else agree with Viktor? Please speak up on the list this week = if so. From nobody Mon Mar 13 13:28: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 6650E129B20 for ; Mon, 13 Mar 2017 13:28:18 -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, 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 (1024-bit key) header.d=kelunik.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 Dabth1bi9Ddf for ; Mon, 13 Mar 2017 13:28:16 -0700 (PDT) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::7]) (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 0948C129B1E for ; Mon, 13 Mar 2017 13:28:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1489436894; l=2017; s=domk; d=kelunik.com; h=Content-Type:To:Subject:Date:From:References:In-Reply-To: MIME-Version; bh=p07vk+6Ybock2bEv7hTeOJ+TrTnBglnmGUAVK5pSP+Y=; b=G6JQbPAmdQYxXnQu5rGosdmiQ9q5OCgGPX2+R+Gx1a1FUUwcvlMYluLAGI81UQw9k8 G0Ac91j3HClpF5fscr1VYee9/TLCIYgurl4xeok2VNe0bw3qRhp4Mldtl8QvjQ2S2zJI vsRzJptJ/tZo5ciPa9ewhfKSVCxQtkJ0IKRj4= X-RZG-AUTH: :IWkkfkWkbvHsXQGmRYmUo9mls2vWuiu+7SLDup6E67mzuoBPBqD/sz4= X-RZG-CLASS-ID: mo00 Received: by mail-qk0-f173.google.com with SMTP id 1so232019547qkl.3 for ; Mon, 13 Mar 2017 13:28:12 -0700 (PDT) X-Gm-Message-State: AFeK/H2uDxe1Z+420eZjF64Ry9gvWHczZ40itVch8JmgB/wxRpIyjcesSpVZV2mgPI2PYZ22ghBQT6vlgzrOaA== X-Received: by 10.55.87.198 with SMTP id l189mr32101428qkb.106.1489436892277; Mon, 13 Mar 2017 13:28:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.144.167 with HTTP; Mon, 13 Mar 2017 13:28:11 -0700 (PDT) In-Reply-To: References: From: Niklas Keller Date: Mon, 13 Mar 2017 21:28:11 +0100 X-Gmail-Original-Message-ID: Message-ID: To: IETF ACME , "Salz, Rich" Content-Type: multipart/alternative; boundary=001a114dbb78e17c57054aa28cf8 Archived-At: Subject: [Acme] Fwd: Inconsistent abbreviations for resource names X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 20:28:18 -0000 --001a114dbb78e17c57054aa28cf8 Content-Type: text/plain; charset=UTF-8 I'm resending this message as there were no responses and nothing changed. ---------- Forwarded message ---------- Morning, the current draft contains a few inconsistencies in the resource naming. 1) https://ietf-wg-acme.github.io/acme/#rfc.section.6.1 mentions "revoke-certificate", while it's called "revoke-cert" in the rest of the document. 2) There's "new-account", but the account resource is called "acct", I think it should be "account" everywhere. We don't gain anything by saving a few keystrokes / bytes there. Maybe we should then also rename "authz" to "authorization" and "cert" to "certificate" everywhere. Regards, Niklas --001a114dbb78e17c57054aa28cf8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm resending this message as there were no respo= nses and nothing changed.

---------- Fo= rwarded message ----------

Morning,

<= div>the current draft contains a few inconsistencies in the resource naming= .

1)=C2=A0https://ietf-wg-acme.github= .io/acme/#rfc.section.6.1 mentions "revoke-certificate",= while it's called "revoke-cert" in the rest of the document.=

2) There's "new-account", but the a= ccount resource is called "acct", I think it should be "acco= unt" everywhere. We don't gain anything by saving a few keystrokes= / bytes there.

Maybe we should then also rename &= quot;authz" to "authorization" and "cert" to "= ;certificate" everywhere.

Regards, Niklas

--001a114dbb78e17c57054aa28cf8-- From nobody Mon Mar 13 14:00: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 43C31129B78 for ; Mon, 13 Mar 2017 14:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.004 X-Spam-Level: X-Spam-Status: No, score=-7.004 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, RCVD_IN_MSPIKE_H2=-0.001, 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 q-o1YmYd1VLM for ; Mon, 13 Mar 2017 14:00: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 97340129B64 for ; Mon, 13 Mar 2017 14:00:41 -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=N31v0PE0m/QAwAVwg58kI/6redvCCD0eFBgBErYF0M4=; b=JPtF8op1O+fAmqWwOIg87n5+d5GnfWv5RKgyBnSdopKmGyoQ2HJG8K1qVixUpGb/ZUA2Mz7tdtxfhUqQIBy+8FPUQRF7YGE6k7IjYFgjUyX7jhJ7UEWuuiucz6Flb/qe4AtdRVCvBMEBqfDT0+svS7e/AjFAatX4ZXjsxJumatA=; Received: ; Mon, 13 Mar 2017 14:00:43 -0700 To: acme@ietf.org References: <8473d9ba84894d49b2f2232370d66b46@usma1ex-dag1mb3.msg.corp.akamai.com> <20170307031510.GN7733@mournblade.imrryr.org> <20170307032023.GO7733@mournblade.imrryr.org> <9471a5323a98405eaf0ee111fb0350b0@usma1ex-dag1mb3.msg.corp.akamai.com> <20170313201410.GG4095@mournblade.imrryr.org> From: Jacob Hoffman-Andrews Message-ID: <3b319b98-64f2-5ed9-fa2e-460c574459d1@eff.org> Date: Mon, 13 Mar 2017 14:00:40 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <20170313201410.GG4095@mournblade.imrryr.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Received-SPF: skipped for local relay Archived-At: Subject: Re: [Acme] ACME draft is now in WGLC. X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 21:00:43 -0000 As Rich said, the CA/Browser Forum has indeed voted to mandate CAA. Hoora= y! On 03/13/2017 01:14 PM, Viktor Dukhovni wrote: > I've had complete disinterest in CAA which initially was accepted > by CA/B forum as a "recommendation", which meant that the constraint > was meaningless. Rumour has it that CAA will soon be a requirement, > so I've now published CAA records. The CAA check is/was easy to > make and crippling it by not making it a requirement was IMNSHO a > mistake. I think by this you mean that the CA/Browser Forum should have mandated CAA support in its Baseline Requirements, back when it first adopted CAA as "recommended." Is that right? I think the analogous goal here is that you'd like the CA/Browser Forum to mandate use of a DNSSEC-validating recursive resolver during DNS-based validation procedures. That's great! However, I don't think mandating use of a DNSSEC-validating resolver in the ACME spec will achieve that goal, since the CA/Browser Forum is not planning to mandate use of the ACME spec. I realize that the CA/Browser Forum seems relatively opaque and hard to participate in, but if you check their bylaws it is possible for any member of the public (not just a CA or a Browser) to directly participate in the mailing list by submitting a simple form. I'd encourage you to get involved! From nobody Mon Mar 13 21:28: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 DFE0A1294D3 for ; Mon, 13 Mar 2017 21:28:55 -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 0Wl20NAcyCWk for ; Mon, 13 Mar 2017 21:28:54 -0700 (PDT) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::230]) (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 19BC2129436 for ; Mon, 13 Mar 2017 21:28:53 -0700 (PDT) Received: by mail-pg0-x230.google.com with SMTP id b129so78111173pgc.2 for ; Mon, 13 Mar 2017 21:28:53 -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-transfer-encoding; bh=Fj6dp922FcZG/rDt55rK58WEMuhdj9HDe5xVq/3E8kw=; b=UuOazvOcXMCyc8NEEm94f0IVWDcgUbu+dMYAfI+1tRU54HlMp3Ksw/F9yQFrEWzz/9 VhRnhEHFcJvwxT3IuxEesShNaNbbx06uTiaM6g91XjMPYzRr2j6T2025Cb55Fs8uqXbt wwb+STJQBvBJmsmUvtItivgBVlKh6/B2TaJho= 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; bh=Fj6dp922FcZG/rDt55rK58WEMuhdj9HDe5xVq/3E8kw=; b=OxZogjjhFlqAGKx66B7H+Cdze5TnCSaSPyCOfZ/KWwQYEBW1y+B+jIBSi4m8faz80i +4KmuXcSqI+TuMyE4uavE5916afxuytkGioodBW2OM1o40jGrlu9dYtIoO+JmjUaomHJ qWg62eIhHmBrsgt2dwNZ5jVOlFrQpwukhL30JMRG9ULl3vOtLFhXdaDG/3STi4ItZsSz 2gRi/Xuo7LtvI/YqCLhWyLirCe6NLaYB95Ri55n1DeGKEMeNTlMCZW8kuMZgkOlhMK4d 82Ut81BP3xNuhOKWIIJUcIBXKGJFO6v0o248s4uZ/j2bNJ4wjlmGII/ZwV2dJQdzTN1e fcvQ== X-Gm-Message-State: AMke39nJK1eUalZ/PkN0/yJLCv5gFmUGZfm3EceXOYuP0ImrMotwmPMGjMyA5uAHqiOIhUKN X-Received: by 10.84.197.131 with SMTP id n3mr52380159pld.43.1489465731473; Mon, 13 Mar 2017 21:28:51 -0700 (PDT) Received: from [172.16.131.149] ([66.126.158.85]) by smtp.gmail.com with ESMTPSA id y9sm35325741pfi.39.2017.03.13.21.28.50 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Mar 2017 21:28:50 -0700 (PDT) To: acme@ietf.org References: From: Roland Shoemaker Message-ID: <4918dfd6-6b4c-6a92-1767-a2876af8dd73@letsencrypt.org> Date: Mon, 13 Mar 2017 21:28:50 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Acme] Challenge names in final RFC X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 04:28:56 -0000 I'd argue that removing the challenge version numbers adds unnecessary complexity to the specification and any existing implementations going forward. Existing servers and clients will need to have some kind of mapping from the draft names to the final un-versioned names and any protocol revisions going forward will need to know about both the versioned and un-versioned names so that they don't name a new version of a challenge using one of the draft version numbers, leading to existing implementations thinking an older version is actually being used. I agree dropping the version numbers is somewhat more aesthetically pleasing but I can't really see any actual technical reasons to do so, while keeping them seems like it'd save a lot of headaches down the road. On 03/13/2017 11:56 AM, Richard Barnes wrote: > I would prefer we stick with dropping the version number, just because > it's cleaner and the future is bigger than the past. > > > On Mar 13, 2017 2:27 PM, "Jacob Hoffman-Andrews" > wrote: > > Roland posted a PR tweaking the challenge names for the final RFC: > https://github.com/ietf-wg-acme/acme/pull/272 > . > > This raised the question: What do we want the challenge names to be in > the final RFC? I think we've been assuming that "http-01" would become > "http" once the RFC is published. However, this does create a slightly > deployment headache, in that draft-compatible implementations have to > use one name, and RFC-compatible implementations have to use another, so > it's hard to test working code with the final names before the RFC is > really finalized. > > I don't have a strong opinion on this one way or another. What do folks > on this list think? > > _______________________________________________ > 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 > -- Roland Bracewell Shoemaker Software Engineer Linux Foundation / Internet Security Research Group From nobody Mon Mar 13 21:54: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 794F91294AA for ; Mon, 13 Mar 2017 21:54:02 -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 Vb6pnZB6xTf0 for ; Mon, 13 Mar 2017 21:54:01 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::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 C26DA129443 for ; Mon, 13 Mar 2017 21:54:00 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id x35so47719651qtc.2 for ; Mon, 13 Mar 2017 21:54:00 -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=8efXNd/2/b6q99etSheoaC92V+lV1hmrOTA+dHiFO+o=; b=i/adfTVZ5mhqZZ/IpO/A/X4DttYvtDBd3eQ3MOR7S9FCOspHW6iMIsCXT6dYIQMMGp YwNYqKH5rMMmbaYfwNwvFdPLgDGxPUEWvFZr5OXRsLWSWbjNgvwchdIV6VpoOuJ+xu5k gqQZ1fbrtv3jriMOajslOXgDKX3rfwn/Ii4IdpTDIPRa+R4ntKDwHcXTtrEZeBXNBRT0 oGDJPkKOVgOGejOZBcIqC4oW89KcN+xw4D5mzLia6XUEcy8Ep3UKah4yRJ49zS5nR+vy mfOlP/GJ+zAKH6/quqw3jyBaXYaoUA1iyr/izHCYl1Fzb+eidrwrkAHBFuYOhbZjB4Qt sCBQ== 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=8efXNd/2/b6q99etSheoaC92V+lV1hmrOTA+dHiFO+o=; b=j70gfrMkTfV9chjtccLoCWEL8qFqZejOFi8LTloEmdTtbhQpctykJZlCdj7eXP52fv WVMN9fCE5hDCCPdsYTR7G6nI12SbcjwylDch2GsrwyIV5UabJ662Q2dhMIcYDCBsWPXU TnsEH2U3NRixurxNXYd69nJsDSwfPaw3GmwPpgRh3+QHynWkF/7KZ9NnvYzQddPFTxIF Nqaqevr9BywUeAs9c2Cyb6ztK3GTV27Il6AY6FiuDcH6bgYT/G6OPIGzibgILsx6ttlS bwiSo7rcTOCAtKnLUH/4BCtl+7OpKGj+ZeINgoGeMk0JjaliAWaIEfokvYIeggleaG51 YcBQ== X-Gm-Message-State: AMke39kRNd+MXdKxhnyYCuLboGg8f7gO0iw8Ah4UGppnmD/ZzvMz4CNhgR8hMhWbOMsLr0SRzJOtgJf8vei22g== X-Received: by 10.200.3.214 with SMTP id z22mr38197778qtg.3.1489467239846; Mon, 13 Mar 2017 21:53:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.27.194 with HTTP; Mon, 13 Mar 2017 21:53:59 -0700 (PDT) In-Reply-To: <4918dfd6-6b4c-6a92-1767-a2876af8dd73@letsencrypt.org> References: <4918dfd6-6b4c-6a92-1767-a2876af8dd73@letsencrypt.org> From: Martin Thomson Date: Tue, 14 Mar 2017 15:53:59 +1100 Message-ID: To: Roland Shoemaker Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "acme@ietf.org" Subject: Re: [Acme] Challenge names in final RFC X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 04:54:02 -0000 Consider this a dry run for eventually rolling out variants that use SHA-3-?? instead of SHA-256. The code for aliasing should give you confidence that you can ship new challenges without disrupting usability. In a way, it's a shame that the challenges didn't change more often during development. Testing concurrent support for old and new versions is pretty valuable. On 14 March 2017 at 15:28, Roland Shoemaker wrote: > I'd argue that removing the challenge version numbers adds unnecessary > complexity to the specification and any existing implementations going > forward. > > Existing servers and clients will need to have some kind of mapping from > the draft names to the final un-versioned names and any protocol > revisions going forward will need to know about both the versioned and > un-versioned names so that they don't name a new version of a challenge > using one of the draft version numbers, leading to existing > implementations thinking an older version is actually being used. > > I agree dropping the version numbers is somewhat more aesthetically > pleasing but I can't really see any actual technical reasons to do so, > while keeping them seems like it'd save a lot of headaches down the road. > > On 03/13/2017 11:56 AM, Richard Barnes wrote: >> I would prefer we stick with dropping the version number, just because >> it's cleaner and the future is bigger than the past. >> >> >> On Mar 13, 2017 2:27 PM, "Jacob Hoffman-Andrews" > > wrote: >> >> Roland posted a PR tweaking the challenge names for the final RFC: >> https://github.com/ietf-wg-acme/acme/pull/272 >> . >> >> This raised the question: What do we want the challenge names to be in >> the final RFC? I think we've been assuming that "http-01" would become >> "http" once the RFC is published. However, this does create a slightly >> deployment headache, in that draft-compatible implementations have to >> use one name, and RFC-compatible implementations have to use another, so >> it's hard to test working code with the final names before the RFC is >> really finalized. >> >> I don't have a strong opinion on this one way or another. What do folks >> on this list think? >> >> _______________________________________________ >> 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 >> > > -- > Roland Bracewell Shoemaker > Software Engineer > Linux Foundation / Internet Security Research Group > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme From nobody Mon Mar 13 22:13: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 7462A1294A1 for ; Mon, 13 Mar 2017 22:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 oMxd1ZkvXofC for ; Mon, 13 Mar 2017 22:13:11 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F25FD129443 for ; Mon, 13 Mar 2017 22:13:10 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 2B87E7A3309; Tue, 14 Mar 2017 05:13:10 +0000 (UTC) Date: Tue, 14 Mar 2017 05:13:10 +0000 From: Viktor Dukhovni To: acme@ietf.org Message-ID: <20170314051309.GR7733@mournblade.imrryr.org> References: <8473d9ba84894d49b2f2232370d66b46@usma1ex-dag1mb3.msg.corp.akamai.com> <20170307031510.GN7733@mournblade.imrryr.org> <20170307032023.GO7733@mournblade.imrryr.org> <9471a5323a98405eaf0ee111fb0350b0@usma1ex-dag1mb3.msg.corp.akamai.com> <20170313201410.GG4095@mournblade.imrryr.org> <3b319b98-64f2-5ed9-fa2e-460c574459d1@eff.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3b319b98-64f2-5ed9-fa2e-460c574459d1@eff.org> User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [Acme] ACME draft is now in WGLC. X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: acme@ietf.org List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 05:13:12 -0000 On Mon, Mar 13, 2017 at 02:00:40PM -0700, Jacob Hoffman-Andrews wrote: > > by CA/B forum as a "recommendation", which meant that the constraint > > was meaningless. Rumour has it that CAA will soon be a requirement, > > so I've now published CAA records. The CAA check is/was easy to > > make and crippling it by not making it a requirement was IMNSHO a > > mistake. > > I think by this you mean that the CA/Browser Forum should have mandated > CAA support in its Baseline Requirements, back when it first adopted CAA > as "recommended." Is that right? Yes. > I think the analogous goal here is that you'd like the CA/Browser Forum > to mandate use of a DNSSEC-validating recursive resolver during > DNS-based validation procedures. No, dragging the CA/B forum into this discussion (by way of analogy) was perhaps a mistake. I am trying to say is that wiggle room to not do DNSSEC ACME serves no purpose. ACME should *require* DNSSEC resolvers in *ACME conformant CAs. > That's great! However, I don't think mandating use of a DNSSEC-validating > resolver in the ACME spec will achieve that goal, since the CA/Browser > Forum is not planning to mandate use of the ACME spec. Convincing non-ACME CAs that issue DV certs do use DNSSEC for DNS challenges is a separate issue (windmill for my Quixotic battles) and is out of scope for this group. So one thing at a time, I urge the ACME WG to require DNSSEC for DNS challenges, so that security of DNSSEC signed domains is not downgraded by ACME CAs negligently running security-oblivious resolvers. -- Viktor. From nobody Mon Mar 13 23:26: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 C6C8912943B for ; Mon, 13 Mar 2017 23:26:48 -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, SPF_FAIL=0.001, SPF_HELO_PASS=-0.001] autolearn=no 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 5KcDTIkkrIwm for ; Mon, 13 Mar 2017 23:26:47 -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 483E11289B0 for ; Mon, 13 Mar 2017 23:26:47 -0700 (PDT) Received: from host249.freudenhaus.alandoherty.net ([193.120.128.249]:1047 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 1cnfut-0001J6-Ns ; Tue, 14 Mar 2017 06:26:45 +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: Tue, 14 Mar 2017 06:26:41 +0000 To: Roland Shoemaker ,acme@ietf.org From: Alan Doherty In-Reply-To: <4918dfd6-6b4c-6a92-1767-a2876af8dd73@letsencrypt.org> References: <4918dfd6-6b4c-6a92-1767-a2876af8dd73@letsencrypt.org> 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] Challenge names in final RFC X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 06:26:48 -0000 +1 At 04:28 14/03/2017 Tuesday, Roland Shoemaker wrote: >I'd argue that removing the challenge version numbers adds unnecessary >complexity to the specification and any existing implementations going >forward. > >Existing servers and clients will need to have some kind of mapping from >the draft names to the final un-versioned names and any protocol >revisions going forward will need to know about both the versioned and >un-versioned names so that they don't name a new version of a challenge >using one of the draft version numbers, leading to existing >implementations thinking an older version is actually being used. > >I agree dropping the version numbers is somewhat more aesthetically >pleasing but I can't really see any actual technical reasons to do so, >while keeping them seems like it'd save a lot of headaches down the road. > >On 03/13/2017 11:56 AM, Richard Barnes wrote: >> I would prefer we stick with dropping the version number, just because >> it's cleaner and the future is bigger than the past. >> >> >> On Mar 13, 2017 2:27 PM, "Jacob Hoffman-Andrews" > > wrote: >> >> Roland posted a PR tweaking the challenge names for the final RFC: >> https://github.com/ietf-wg-acme/acme/pull/272 >> . >> >> This raised the question: What do we want the challenge names to be in >> the final RFC? I think we've been assuming that "http-01" would become >> "http" once the RFC is published. However, this does create a slightly >> deployment headache, in that draft-compatible implementations have to >> use one name, and RFC-compatible implementations have to use another, so >> it's hard to test working code with the final names before the RFC is >> really finalized. >> >> I don't have a strong opinion on this one way or another. What do folks >> on this list think? >> >> _______________________________________________ >> 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 >> > >-- >Roland Bracewell Shoemaker >Software Engineer >Linux Foundation / Internet Security Research Group > >_______________________________________________ >Acme mailing list >Acme@ietf.org >https://www.ietf.org/mailman/listinfo/acme From nobody Tue Mar 14 09:24: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 97CD0129501 for ; Tue, 14 Mar 2017 09:24:30 -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 v093RNmBcvcf for ; Tue, 14 Mar 2017 09:24:29 -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 3D7C7129480 for ; Tue, 14 Mar 2017 09:24:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by umbriel.devever.net (Postfix) with ESMTP id 6A6D81D3FF; Tue, 14 Mar 2017 17:24:26 +0100 (CET) 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=1489508666; x=1507698027; bh=gYhazqbNbJmqLQb5rXlfvd8y+6VXJ9Kw5dNz/0SYHh8=; b= nX7tSPGzUlUvSLXRZ6d56juFFuuhA22Ngf1BGe8FLariK6XuBObOitIyevVb5mz4 36cZ16EijLZDL4sjpm3hoIdYMGAnKvYQrfSb4IElYKj8dBSWf4t61Az88rkiC05J sLTAsY93yWzsoPkLN0jC13gWewVeSYUcpMuVAOA7++BNV91/hK7603Awhma7ktfm yT+JhDfJ6m3XBh8wjNzOx0wg1l5z4l36i+WKbTWPae3X9ve/4ygW5LRepAy38uNj iXRYOl8qpmD4M+UBYMuJ1ysUqCu/sR3nmls3Q0GEoZ7bWDGbuD4eeY6uE0ocD9Hr s8n3gZn3EyteNm27aQcQNA== 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 Hq2AaAQc3m2I; Tue, 14 Mar 2017 17:24:26 +0100 (CET) Received: from andover.lhh.devever.net (localhost [127.0.0.1]) by umbriel.devever.net (Postfix) with SMTP id 2CA3C1D3FE; Tue, 14 Mar 2017 17:24:26 +0100 (CET) Date: Tue, 14 Mar 2017 16:24:26 +0000 From: Hugo Landau To: "Salz, Rich" Cc: acme@ietf.org Message-ID: <20170314162425.GA13868@andover.lhh.devever.net> References: <8473d9ba84894d49b2f2232370d66b46@usma1ex-dag1mb3.msg.corp.akamai.com> <20170307031510.GN7733@mournblade.imrryr.org> <20170307032023.GO7733@mournblade.imrryr.org> <9471a5323a98405eaf0ee111fb0350b0@usma1ex-dag1mb3.msg.corp.akamai.com> <20170313201410.GG4095@mournblade.imrryr.org> <12461433fb264865972e9ddafab1c511@usma1ex-dag1mb1.msg.corp.akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <12461433fb264865972e9ddafab1c511@usma1ex-dag1mb1.msg.corp.akamai.com> User-Agent: Mutt/1.8.0 (2017-02-23) Archived-At: Subject: Re: [Acme] ACME draft is now in WGLC. X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 16:24:30 -0000 > > The CAA check is/was easy to make and crippling it > > by not making it a requirement was IMNSHO a mistake. > ... > > I urge the WG to reconsider. > > Does anyone else agree with Viktor? Please speak up on the list this week if so. I'd agree that the CAA check should be made mandatory. At least, I can't think of any good reason why it shouldn't be. I'd also agree that the use of a DNSSEC-validating resolver accessed via a trusted network (preferably localhost) should be mandatory. From nobody Tue Mar 14 09:33: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 A2EA7129611 for ; Tue, 14 Mar 2017 09:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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, RP_MATCHES_RCVD=-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=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 dKGhHPqiRNw0 for ; Tue, 14 Mar 2017 09:32:58 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4161296FF for ; Tue, 14 Mar 2017 09:32:58 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 30294496C15; Tue, 14 Mar 2017 16:32:58 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 1A78D496C0B; Tue, 14 Mar 2017 16:32:58 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1489509178; bh=Jp7Coppqe+YcY9gOBKU+mbP9LAVMdudnkXmm4FQrTFM=; l=535; h=From:To:CC:Date:From; b=juDnIEhKYgZOUSvEblHVhV+ZW/Cd7JXAF2TwsPOaK5IsuVLNP7OFJwXDuWRVcGnjG IMkV1QHe0/H3WtcNYF5vbRSwph9Pz38HPZgnQd8/wQmJxlMsfl1lVoUUR+TC9UDd7b 75vEYXrHETBoLvxwghLt3GsFe0CpDcyY6yd1SgUI= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.33]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 018831E07C; Tue, 14 Mar 2017 16:32:58 +0000 (GMT) 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.1178.4; Tue, 14 Mar 2017 12:32:57 -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.1178.000; Tue, 14 Mar 2017 12:32:57 -0400 From: "Salz, Rich" To: Hugo Landau CC: "acme@ietf.org" Thread-Topic: [Acme] ACME draft is now in WGLC -- require CAA ? Thread-Index: AdKc4KLaA8INySUYRBK6HvacW05TjA== Date: Tue, 14 Mar 2017 16:32:57 +0000 Message-ID: <88f72c3c2be6435f8b4b5a4801207b51@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.35.10] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Acme] ACME draft is now in WGLC -- require CAA ? X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 16:33:00 -0000 =20 > I'd agree that the CAA check should be made mandatory. At least, I can't > think of any good reason why it shouldn't be. Have you seen the thread on the LAMPS (SPASM) mailing list, titled "CAA Err= atum 4515"? That raises some technical issues, which make me (as an indivi= dual at least) think it's premature. =20 > I'd also agree that the use of a DNSSEC-validating resolver accessed via = a > trusted network (preferably localhost) should be mandatory. This is a separate issue, please start a separate thread. From nobody Tue Mar 14 09:35: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 418F813293E for ; Tue, 14 Mar 2017 09:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 BEm4jjuw_m0k for ; Tue, 14 Mar 2017 09:35:00 -0700 (PDT) Received: from relais-inet.orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7B071296FF for ; Tue, 14 Mar 2017 09:34:59 -0700 (PDT) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 72E8BC026A for ; Tue, 14 Mar 2017 17:34:58 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.2]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 4CFB81A0082 for ; Tue, 14 Mar 2017 17:34:58 +0100 (CET) Received: from OPEXCLILMA1.corporate.adroot.infra.ftgroup ([fe80::95e2:eb4b:3053:fabf]) by OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06%19]) with mapi id 14.03.0319.002; Tue, 14 Mar 2017 17:34:58 +0100 From: To: "acme@ietf.org" Thread-Topic: [CDNi] New Version Notification for draft-fieau-cdni-https-delegation-01.txt Thread-Index: AQHSnKMDPHP16HwiKECK3pGgFVgGjKGUiHPg Date: Tue, 14 Mar 2017 16:34:57 +0000 Message-ID: <4907_1489509298_58C81BB2_4907_1732_1_1BD328329726EF4E91AE924BB1B4CB9E28AEA285@OPEXCLILMA1.corporate.adroot.infra.ftgroup> References: <148944127992.20329.10465338220109378651.idtracker@ietfa.amsl.com> <23443_1489482703_58C7B3CE_23443_12423_1_71d4eb70-5eb9-4b04-8b45-5ff331ccdf28@OPEXCLILM5E.corporate.adroot.infra.ftgroup> In-Reply-To: <23443_1489482703_58C7B3CE_23443_12423_1_71d4eb70-5eb9-4b04-8b45-5ff331ccdf28@OPEXCLILM5E.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [Acme] TR: [CDNi] New Version Notification for draft-fieau-cdni-https-delegation-01.txt X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 16:35:01 -0000 DQpEZWFyIGFsbCwNCg0KSSd2ZSBwb3N0ZWQgYW4gdXBkYXRlIG9mIHRoZSBkcmFmdCBmb2N1c2lu ZyBvbiBPdXQtb2YtQmFuZCAicmVkaXJlY3Rpb24iLCBTdWJDZXJ0cyBhbmQgU2hvcnQtTGl2ZWQg Y2VydHMgYXBwcm9hY2hlcyBmb3IgSFRUUFMgZGVsZWdhdGlvbiBpbiBDRE5JLg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWZpZWF1LWNkbmktaHR0cHMtZGVsZWdh dGlvbi0wMS50eHQNCg0KUGxlYXNlIHJldmlldyBhbmQgY29tbWVudC4NCg0KQmVzdCByZWdhcmRz LA0KRnLDqWTDqXJpYw0KDQoNCi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KRGXCoDogaW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSAN CkVudm95w6nCoDogbHVuZGkgMTMgbWFycyAyMDE3IDIyOjQxDQrDgMKgOiBTYW5qYXkgTWlzaHJh OyBTVEVQSEFOIEVtaWxlIElNVC9PTE47IFNURVBIQU4gRW1pbGUgSU1UL09MTjsgRklFQVUgRnLD qWTDqXJpYyBJTVQvT0xODQpPYmpldMKgOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRy YWZ0LWZpZWF1LWNkbmktaHR0cHMtZGVsZWdhdGlvbi0wMS50eHQNCg0KDQpBIG5ldyB2ZXJzaW9u IG9mIEktRCwgZHJhZnQtZmllYXUtY2RuaS1odHRwcy1kZWxlZ2F0aW9uLTAxLnR4dA0KaGFzIGJl ZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBGcmVkZXJpYyBGaWVhdSBhbmQgcG9zdGVkIHRv IHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC1maWVhdS1jZG5pLWh0dHBzLWRl bGVnYXRpb24NClJldmlzaW9uOgkwMQ0KVGl0bGU6CQlIVFRQUyBkZWxlZ2F0aW9uIGluIENETkkN CkRvY3VtZW50IGRhdGU6CTIwMTctMDMtMTMNCkdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9u DQpQYWdlczoJCTE0DQpVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzL2RyYWZ0LWZpZWF1LWNkbmktaHR0cHMtZGVsZWdhdGlvbi0wMS50eHQNClN0YXR1 czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1maWVhdS1j ZG5pLWh0dHBzLWRlbGVnYXRpb24vDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWZpZWF1LWNkbmktaHR0cHMtZGVsZWdhdGlvbi0wMQ0KRGlmZjogICAg ICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1maWVhdS1jZG5p LWh0dHBzLWRlbGVnYXRpb24tMDENCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IGV4YW1p bmVzIHByb2JhYmxlIHNvbHV0aW9ucyBmb3IgZGVsZWdhdGluZyBlbmNyeXB0ZWQNCiAgIGNvbnRl bnQgZGVsaXZlcnkgd2l0aGluIHRoZSBjb250ZXh0IG9mIENETiBpbnRlcmNvbm5lY3Rpb24uICBU aGUNCiAgIEhUVFBTIGRlbGVnYXRpb24gYWxzbyBleHBlY3RzIGRlbGl2ZXJpbmcgY29udGVudCB3 aXRob3V0IGNvbXByb21pc2luZw0KICAgc2VjdXJpdHksIGludGVncml0eSBhbmQgdXNlciBwcml2 YWN5Lg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBp dCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lv biB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRv b2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KQ2Ug bWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3Jt YXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25j DQpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlv bi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBz aWduYWxlcg0KYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVj ZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVz IGQnYWx0ZXJhdGlvbiwNCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNl IG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCg0KVGhp cyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9y IHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsNCnRo ZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRo b3Jpc2F0aW9uLg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxl YXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0 YWNobWVudHMuDQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxl IGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZp ZWQuDQpUaGFuayB5b3UuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpDRE5pIG1haWxpbmcgbGlzdA0KQ0ROaUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jZG5pDQoKX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBz ZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZp ZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRp ZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2 ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdl eHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExl cyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24s Ck9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUg YWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRz IGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9y bWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBk aXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3Ug aGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5k ZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxz IG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBo YXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= From nobody Tue Mar 14 11:25: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 F0AD312ACAE for ; Tue, 14 Mar 2017 11:25:00 -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] 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 fmrF8zA-jIPA for ; Tue, 14 Mar 2017 11:24:59 -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 53835128BA6 for ; Tue, 14 Mar 2017 11:24:59 -0700 (PDT) Received: by mail-wr0-x229.google.com with SMTP id l37so129784775wrc.1 for ; Tue, 14 Mar 2017 11:24:59 -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=eVfesGxbB31yLR3HPlodcl24rJeKnVivcFVqnZCpwJc=; b=a96uw+9GtNyoKRiu+0If4g6rhj8yzd1lEnSDWG2qkFoec1nPp4atB/hDnqiSQBibWa Agc4J6pKfoxxiVDI0mgqe+0PYr6mR7ZdriW1Lbsatz2L5HXLL0QGREu5fN01MzxKaB91 WKNjRPadG9WoiCJ2h0EiDjjCjempZWZTnDIg5qO/GZ2Ioo5Pu8JUECxBao1+s7IQdR45 HV+D4eqJ/67LX3otVYpyHE0GPHzAcogFLeZcXWn4JWZKNYgZEvyHYVHzON6FOo80PRHH MRQk8fIvzSO8gOCXgmbIx30l8zSKQfmzuV+qfRL257q0WJ1IQctX2lVXLzxDRSHRf4sk Fhmw== 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=eVfesGxbB31yLR3HPlodcl24rJeKnVivcFVqnZCpwJc=; b=OF4HfCwcezefT1rR8rlCfKLXj7njzoElV7HDhvH80x58WEnab9sD3kYoUU6Cnxf+/U teNhfmPQXwEXgkJIAhxt/DEIF4niA2Pr00SzR+n845DuqxSF7iScv/4RcCcTqMikQrGT V8TPJQP46oVvZuVXjk78dYkRVie9xcUqf9+bgp2lgiPYxoXncH9/7+auL4paLxTGaQA/ 7cFxh0NJLzoRp6OKdwSnNx26eK5zO4PDWC3CRUrGRHZajjqcPVElr+vLHedC4B5FwzvU 4eUatsinQ8Ot3+/dMdyCRxFAFU+4vnJwg4iMak/3ULEVPfsCwaUCPonZEPFjeqjVRpLD T+VA== X-Gm-Message-State: AMke39kGT4Zay2JsMFs73YPix6tinelKwym0THHt2kUMTO72u7rZukiFHIRoEqHCgE+QMwZ90go1gFB4ZKf8JA== X-Received: by 10.223.139.152 with SMTP id o24mr33928196wra.61.1489515897108; Tue, 14 Mar 2017 11:24:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.31.2 with HTTP; Tue, 14 Mar 2017 11:24:56 -0700 (PDT) In-Reply-To: <20170314162425.GA13868@andover.lhh.devever.net> References: <8473d9ba84894d49b2f2232370d66b46@usma1ex-dag1mb3.msg.corp.akamai.com> <20170307031510.GN7733@mournblade.imrryr.org> <20170307032023.GO7733@mournblade.imrryr.org> <9471a5323a98405eaf0ee111fb0350b0@usma1ex-dag1mb3.msg.corp.akamai.com> <20170313201410.GG4095@mournblade.imrryr.org> <12461433fb264865972e9ddafab1c511@usma1ex-dag1mb1.msg.corp.akamai.com> <20170314162425.GA13868@andover.lhh.devever.net> From: Richard Barnes Date: Tue, 14 Mar 2017 14:24:56 -0400 Message-ID: To: Hugo Landau Cc: "Salz, Rich" , "acme@ietf.org" Content-Type: multipart/alternative; boundary=f403045e9aceef5215054ab4f15e Archived-At: Subject: Re: [Acme] ACME draft is now in WGLC. X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 18:25:01 -0000 --f403045e9aceef5215054ab4f15e Content-Type: text/plain; charset=UTF-8 On Tue, Mar 14, 2017 at 12:24 PM, Hugo Landau wrote: > > > The CAA check is/was easy to make and crippling it > > > by not making it a requirement was IMNSHO a mistake. > > ... > > > I urge the WG to reconsider. > > > > Does anyone else agree with Viktor? Please speak up on the list this > week if so. > > I'd agree that the CAA check should be made mandatory. At least, I can't > think of any good reason why it shouldn't be. > I very strongly disagree. What checks the CA does before issuing is up to the CA's policy. This document provides tools for CAs to do those checks; it does not constrain what CAs do. > I'd also agree that the use of a DNSSEC-validating resolver accessed via > a trusted network (preferably localhost) should be mandatory. > Likewise. --Richard > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > --f403045e9aceef5215054ab4f15e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Mar 14, 2017 at 12:24 PM, Hugo Landau <hlandau@devever.net> wrote:
>= ; > The CAA check is/was easy to make and crippling it
> > by not making it a requirement was IMNSHO a mistake.
> ...
> > I urge the WG to reconsider.
>
> Does anyone else agree with Viktor?=C2=A0 Please speak up on the list = this week if so.

I'd agree that the CAA check should be made mandatory. At least,= I can't
think of any good reason why it shouldn't be.

=
I very strongly disagree.=C2=A0 What checks the CA does before i= ssuing is up to the CA's policy.=C2=A0 This document provides tools for= CAs to do those checks; it does not constrain what CAs do.
<= br>=C2=A0
I'd also agree that the use of a DNSSEC-validating resolver accessed vi= a
a trusted network (preferably localhost) should be mandatory.

Likewise.

--Richard
=
=C2=A0

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

--f403045e9aceef5215054ab4f15e-- From nobody Tue Mar 14 21:42: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 ED8D61293D9 for ; Tue, 14 Mar 2017 21:42: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, 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 ftJFYsLspmmz for ; Tue, 14 Mar 2017 21:42:23 -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 5DD3C129353 for ; Tue, 14 Mar 2017 21:42:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by umbriel.devever.net (Postfix) with ESMTP id 6D1401D401; Wed, 15 Mar 2017 05:42:21 +0100 (CET) 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=1489552941; x=1507742302; bh=rJK80WTQHRvukfAR1FkckTQs33Yf9zrKxoDLRnzAbRA=; b= SquYgISCOdkYX+64gV/AaNGSWELTTkYeyF/rVRevoNDUAQ8ChlwhFhjjdmY3WBHT w9yDaWvp978K7yJg8d1I88LsIxfVjh+fnvBF/pgr3unITiBNiO4ncyBSnMrKAuWP AOjzMYLZZPta0QYe5/fICDKxO2pQM1QwgEBF+yUpvlMeNlLFXwXzxJRuW6lB2Ikp iUczNDcFct+b0QOcX/KJaZ3nMD74PUDSzU+GTXMj9GBZFfd6Jc3Pv5fi2ycw6A/R yhuc63+kLh5ak6kQPS2m+I97MRP1K2poBEZgKCU+r8iapA5na/RhJvFp/jt8B6mu uCFhkIpL3JhB+4s0algQLQ== 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 e5AiaAwFwk10; Wed, 15 Mar 2017 05:42:21 +0100 (CET) Received: from andover.lhh.devever.net (localhost [127.0.0.1]) by umbriel.devever.net (Postfix) with SMTP id 2D9C41D3FF; Wed, 15 Mar 2017 05:42:21 +0100 (CET) Date: Wed, 15 Mar 2017 04:42:21 +0000 From: Hugo Landau To: "Salz, Rich" Cc: acme@ietf.org Message-ID: <20170315044220.GA29588@andover.lhh.devever.net> References: <88f72c3c2be6435f8b4b5a4801207b51@usma1ex-dag1mb1.msg.corp.akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <88f72c3c2be6435f8b4b5a4801207b51@usma1ex-dag1mb1.msg.corp.akamai.com> User-Agent: Mutt/1.8.0 (2017-02-23) Archived-At: Subject: Re: [Acme] ACME draft is now in WGLC -- require CAA ? 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, 15 Mar 2017 04:42:25 -0000 > Have you seen the thread on the LAMPS (SPASM) mailing list, titled > "CAA Erratum 4515"? That raises some technical issues, which make me > (as an individual at least) think it's premature. I wasn't aware of this. However, as far as I'm aware mandatory CAA checking is now a done deal: https://cabforum.org/pipermail/public/2017-March/009988.html I'd therefore argue it isn't premature, a) because CAs are going to have to implement it by September anyway, b) because it's already used in production (Let's Encrypt) successfully. In light of the CAB Forum resolution, the additional utility of adding a normative requirement to the ACME RFC is marginal, so I'm no longer terribly bothered either way, though still ultimately in favour. From nobody Wed Mar 15 16:29: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 77BE2129C62 for ; Wed, 15 Mar 2017 16:29:12 -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, HTML_MESSAGE=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=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 MyvP98zcE-ZF for ; Wed, 15 Mar 2017 16:29:07 -0700 (PDT) Received: from mx0b-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 35A5512E852 for ; Wed, 15 Mar 2017 16:29:07 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.20/8.16.0.20) with SMTP id v2FNNHQa028067 for ; Wed, 15 Mar 2017 23:29:06 GMT 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=Kc7TXyLyo8mH6ehITNduZOSG8HLgahZfzF/Bf64yjhI=; b=hIzXzwF7EtgYwTfsNMKDR267l2R/Np4DpWNbKaaWU7gKe5qISyF/Kf6EvzHcRemxYKca W66JV1JBqYJyFsvGV/2J9ESHEIl/Ih5S9LUu6vfnVwPQaxJz6u7nfejOxM4vzMFKjYEo 5Bj7lUnWINuJFKQAeLvEEfp1BRd/yd+i5kubZ9rZ5h99G27GiUghjB/2oTpj/4lnwX/s KfhcuKaDRVWSKKdUIguqjWevIIgcWUi2ubqihSPdD7sQPKzt30Atz1rSTO+IGNeCAbS2 cTv+PoABGEjJUaoRoTjjil71c+JHekjah6mJWypdvtnL4AzZ+ZLbSiYUUTWogLlCW9zZ sw== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050093.ppops.net-00190b01. with ESMTP id 297ejgr5t6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 15 Mar 2017 23:29:06 +0000 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v2FNL0Bf002456 for ; Wed, 15 Mar 2017 19:29:05 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint4.akamai.com with ESMTP id 294deywrs4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Wed, 15 Mar 2017 19:29:05 -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.1178.4; Wed, 15 Mar 2017 16:29:04 -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.1178.000; Wed, 15 Mar 2017 19:29:04 -0400 From: "Salz, Rich" To: "acme@ietf.org" Thread-Topic: Agenda Thread-Index: AdKd4+7jns50iJAwSbm9QgirvKMs5A== Date: Wed, 15 Mar 2017 23:29:03 +0000 Message-ID: <3423d803df754a5a8329be56e5b3845f@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.32.160] Content-Type: multipart/alternative; boundary="_000_3423d803df754a5a8329be56e5b3845fusma1exdag1mb1msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-15_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-1702020001 definitions=main-1703150178 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-15_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=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1703150178 Archived-At: Subject: [Acme] Agenda 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, 15 Mar 2017 23:29:12 -0000 --_000_3423d803df754a5a8329be56e5b3845fusma1exdag1mb1msgcorpak_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Agenda ACME Working Group IETF 98 Chairs: Rich Salz, Ted hardie AD: Kathleen Moriarty Administrivia: 10 minutes Changes in draft-ietf-acme-acme: 20 minutes Ongoing discussions: CAA requirement: 15 minutes DNSsec requirement: 15 minutes Next steps and recharter: 40 minutes --_000_3423d803df754a5a8329be56e5b3845fusma1exdag1mb1msgcorpak_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Agenda

ACME Working Group

IETF 98

 

Chairs:  Rich Salz, Ted hardie

AD: Kathleen Moriarty

 

Administrivia:      &n= bsp;            = ;            &n= bsp;      10 minutes

Changes in draft-ietf-acme-acme:  20 minutes

Ongoing discussions:

        &nbs= p;       CAA requirement:   &n= bsp;         15 minutes

        &nbs= p;       DNSsec requirement:   = ;   15 minutes

 

Next steps and recharter:    &nb= sp;         40 minutes

--_000_3423d803df754a5a8329be56e5b3845fusma1exdag1mb1msgcorpak_-- From nobody Sat Mar 18 10:08: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 1DD07128990 for ; Sat, 18 Mar 2017 10:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 LWozvIsmjgq6 for ; Sat, 18 Mar 2017 10:08:22 -0700 (PDT) Received: from mail-ot0-x235.google.com (mail-ot0-x235.google.com [IPv6:2607:f8b0:4003:c0f::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 4618512896F for ; Sat, 18 Mar 2017 10:08:22 -0700 (PDT) Received: by mail-ot0-x235.google.com with SMTP id a12so42917555ota.0 for ; Sat, 18 Mar 2017 10:08:22 -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=uDDL3uszJT7oTsSbN3391Ou60AExx7HdApQX+EDimeo=; b=TkZNtzgr95swhbZuuKj8kcPF6LsEqrEQbCxHb+ThoH7ifG19zIKsA2uqKW4DIJuP6q WdUDmA/sT/Ut5gkuq+9bc2ptEgyb2tU3BTGPqN7GMeKJijNcNFHPwo1BsR6OYc8RKHDb yMBJJ9wOlIe+YTR4YwWq1Z99lVYqI7Kb4SHsclwnEuLegnixWh5D3NaEgiP99EpeqN2n SIZk1DTPCdma6Kp6skLqcAvYK6NpI2K8AnVON+pGmFtlgDT1+3gIz6UZKl3vevVAgX6x FEJzOMmiAGa6BV9fJwhCgABzf1INrHFMdHYHHZomouZBZW59QX7QdET7fk583y6dVc+t DJuw== 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=uDDL3uszJT7oTsSbN3391Ou60AExx7HdApQX+EDimeo=; b=XKo8x3SpOyUew9EumPv8smOmwux6yCSBAmI4ovLaXu+izZuDixlg5VvJe6rnAsy5ZT VAr328+8aFihPzGrPrmcTcl8DN+rNMBpC6LItWD41N0h15N10BuofE94fyt8P6+qAQkC KvDCk5CXZiZbR4bmrnfLq53kkrRyT/tIUUr2byAaIvlKaWNlAmD+P3sHv+KrFfVqnHwy Z1ESat86IYdTwxHeGzegk/uSCZub1ixcWUWDCtYgxjbA2JRymykXIjU2/t59iIfUrST6 tWD9OlDeldn50+AfnVhc3QreNPwITJseQRaQEJlUqjRrwQ75H/gMYdZKyGp5PqD6CJkm hHtA== X-Gm-Message-State: AFeK/H0jcCmN88eVhcp+8gfaLLK0vqHKm66BOGUtSzerV5UdAV3QuXYYVzxc4qprA/2Rhs2MummxIz7ienMJwg== X-Received: by 10.157.4.141 with SMTP id 13mr12106061otm.243.1489856901710; Sat, 18 Mar 2017 10:08:21 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.14.123 with HTTP; Sat, 18 Mar 2017 10:08:21 -0700 (PDT) In-Reply-To: References: <8473d9ba84894d49b2f2232370d66b46@usma1ex-dag1mb3.msg.corp.akamai.com> <20170307031510.GN7733@mournblade.imrryr.org> <20170307032023.GO7733@mournblade.imrryr.org> <9471a5323a98405eaf0ee111fb0350b0@usma1ex-dag1mb3.msg.corp.akamai.com> <20170313201410.GG4095@mournblade.imrryr.org> <12461433fb264865972e9ddafab1c511@usma1ex-dag1mb1.msg.corp.akamai.com> <20170314162425.GA13868@andover.lhh.devever.net> From: Phillip Hallam-Baker Date: Sat, 18 Mar 2017 13:08:21 -0400 X-Google-Sender-Auth: BzOZyWRXzkiQKotpo9XOo3H0ONg Message-ID: To: Richard Barnes Cc: Hugo Landau , "Salz, Rich" , "acme@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c0956806487de054b04578d Archived-At: Subject: Re: [Acme] ACME draft is now in 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, 18 Mar 2017 17:08:24 -0000 --94eb2c0956806487de054b04578d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Mar 14, 2017 at 2:24 PM, Richard Barnes wrote: > > > On Tue, Mar 14, 2017 at 12:24 PM, Hugo Landau wrote= : > >> > > The CAA check is/was easy to make and crippling it >> > > by not making it a requirement was IMNSHO a mistake. >> > ... >> > > I urge the WG to reconsider. >> > >> > Does anyone else agree with Viktor? Please speak up on the list this >> week if so. >> >> I'd agree that the CAA check should be made mandatory. At least, I can't >> think of any good reason why it shouldn't be. >> > > I very strongly disagree. What checks the CA does before issuing is up t= o > the CA's policy. This document provides tools for CAs to do those checks= ; > it does not constrain what CAs do. > > > >> I'd also agree that the use of a DNSSEC-validating resolver accessed via >> a trusted network (preferably localhost) should be mandatory. >> > > Likewise. > > =E2=80=8B=E2=80=8B > --Richard > =E2=80=8BIf that were so, why does ACME have any support for DNS validat=E2= =80=8Bion? It is merely CA policy after all. The point of CAA is that it is the one mechanism that is provided to allow domain owners to signal to third parties what parties they authorize to issue certs. In my view CAA should be mandatory for the reasons above. The other reason for making CAA mandatory is that if we are going to fully automate the issue process, we might well want to use information in the CAA records to facilitate that. That was the reason I thought Paul Hoffman's idea of using the DNS name rather than a policy oid or some PKIX identifier was the right approach. --94eb2c0956806487de054b04578d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tue, Ma= r 14, 2017 at 2:24 PM, Richard Barnes <rlb@ipv.sx> wrote:


On Tue, Ma= r 14, 2017 at 12:24 PM, Hugo Landau <hlandau@devever.net> = wrote:
> > The CAA check is/w= as easy to make and crippling it
> > by not making it a requirement was IMNSHO a mistake.
> ...
> > I urge the WG to reconsider.
>
> Does anyone else agree with Viktor?=C2=A0 Please speak up on the list = this week if so.

I'd agree that the CAA check should be made mandatory. At least,= I can't
think of any good reason why it shouldn't be.

=
I very strongly disagree.=C2=A0 What checks the CA does b= efore issuing is up to the CA's policy.=C2=A0 This document provides to= ols for CAs to do those checks; it does not constrain what CAs do.

=C2=A0
I'd also agree that the use of a DNSSEC-validating resolver accessed vi= a
a trusted network (preferably localhost) should be mandatory.

Likewise.

=E2=80=8B=E2=80=8B
--Richard

=E2=80=8BIf that were so, why does ACME have any supp= ort for DNS validat=E2=80=8Bion? It is merely CA policy after all.

The point of CAA is that it is th= e one mechanism that is provided to allow domain owners to signal to third = parties what parties they authorize to issue certs.

In my view CAA should be mandatory for the reaso= ns above.

<= /div>
The other reaso= n for making CAA mandatory is that if we are going to fully automate the is= sue process, we might well want to use information in the CAA records to fa= cilitate that. That was the reason I thought Paul Hoffman's idea of usi= ng the DNS name rather than a policy oid or some PKIX identifier was the ri= ght approach.

=C2=A0
--94eb2c0956806487de054b04578d-- From nobody Mon Mar 20 01:50:50 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 6FD711296DA for ; Mon, 20 Mar 2017 01:50:48 -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, 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 NwEyPto25bP0 for ; Mon, 20 Mar 2017 01:50:46 -0700 (PDT) Received: from mail.hemio.de (mail.hemio.de [144.76.93.186]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10C521243F3 for ; Mon, 20 Mar 2017 01:50:45 -0700 (PDT) Received: from user.client.invalid (localhost [144.76.93.186]) by mail.hemio.de (Postfix) with ESMTPSA id 29E2872 for ; Mon, 20 Mar 2017 09:50:43 +0100 (CET) To: acme@ietf.org References: <96d31ef7-0dda-019c-4072-165fcd57e34f@hemio.de> From: Sophie Herold Message-ID: Date: Mon, 20 Mar 2017 09:50:43 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0 MIME-Version: 1.0 In-Reply-To: <96d31ef7-0dda-019c-4072-165fcd57e34f@hemio.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Acme] Missing structure and unspecified parts in "Account Creation" 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, 20 Mar 2017 08:50:48 -0000 PR for 1.-3. PR for 4. Issue related to 4. On 20/02/17 16:17, Sophie Herold wrote: > 1. > I cannot find where the response to account updates is specified. > > Boulder replies with "202 Accepted" and an account object. Since > updates with trivial payload should be used for account information, > it seems to be expected that an account object is returned. The > specified response status for "Account deactivation" is "200 OK". > It would be consistent to specify the same response status for > account updates I guess? > > 2. > The client should be able to choose between "Account URI recovery" > and "Account Creation", if needed. A possible way would be to clarify > that account creations with trivial payload MUST be rejected. However, > if an account exists, the "Content-Location" header and "200 OK" is > returned, independent of the payloads content. Therefore a trivial > payload could be used to check if an account with the used key exists, > without creating it. > > 3. > As "6.3.4. Account deactivation", other queries should get their own > sub-sub sections. Something like > - "6.3.x Account URI recovery" ("new-account", maybe trivial payload) > - "6.3.x Account update" > - "6.3.x Account information" (update with trivial payload) > > 4. > Is it really an account URI or rather an account URL? Some fields > changed from "uri" to "url". I guess, all occurrences of URIs should > be URLs. The only exception that I see is the "type" field in the > "Problem Details" responses. > From nobody Mon Mar 20 09:10: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 1B24F1294D0 for ; Mon, 20 Mar 2017 09:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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] 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 RMxrVbpdtmF2 for ; Mon, 20 Mar 2017 09:10:23 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::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 09C41127076 for ; Mon, 20 Mar 2017 09:10:23 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id v203so19526693wmg.0 for ; Mon, 20 Mar 2017 09:10: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=uoQx9Ln83blVRSuIN7tJrdBZtPhTfPouar/9bByB6w8=; b=VDXLBy34KXV83V3zru5Ra2qh1oWbnYPk6c7AhsywqfZTeDyjgYIeOyEknmOsf8TGhe R/+q6xVtuGLLccNtaXyVZe/hoKe2RXgVoHVS2nEAMjKHHZekRKdWCbxO4Qd/Exy9Y/4Y aNLhxHy5Dqd2tLjgAeP3p1W9YIg+uIZ8TMDrA/4iM7ducLIXnL5nICwbSxO8Tsmb7qDx UGTY0sOTk2IdKkAFh02+scJrONzFcBvoYb8G9iyVqCBSwJAmADqSeey035kOOvNDv9ib opeMlTJDzdzlk+Lj3K55zc4WNl3HSxeUcBpsVvAgqPhYpdeRsPWQL0IgiHCi7lvYfSPa Gezg== 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=uoQx9Ln83blVRSuIN7tJrdBZtPhTfPouar/9bByB6w8=; b=VRAlZa/ZVZ0YzEOF2F4dz7f0ABA37DqmJTOw6eS4fclGFdqXdVY+rHcOMKLSNlVj/k nSivGfP1ZL3h4CIYSmVoEEqHfrbp9L3z1ptupfpY5YU2cPnhH8bIok0C4dX0+lQYXNNQ Bk+b+V3QN6CcBFoDlYaHtq8ipZEU4wqGB0r3GsMWicxVQBBu562BSQ+ZsIt3MoIEG8Ka 1fgRgLuXzHaTlObIKGdPSvv6K330hyHmNFtr6fZsmSKM/wMKWyo6j4yMG1OOjAEgKnPN u4xaVAj9TTddCLQreUwQ0O2pfAL/pUHdkdh5c+3R8DnAOuZrZJNmDGbvaNstmP24hrSc E8Tw== X-Gm-Message-State: AFeK/H1z8Wy9dumFZQtw2jP5Kb3btKzVmcBnm1Lj3/7zwLbWC9MrvmuU3UYaeMDF33eGImJBaSVEId4k4WEmew== X-Received: by 10.28.156.69 with SMTP id f66mr10456913wme.56.1490026221360; Mon, 20 Mar 2017 09:10:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.31.2 with HTTP; Mon, 20 Mar 2017 09:10:20 -0700 (PDT) In-Reply-To: References: <8473d9ba84894d49b2f2232370d66b46@usma1ex-dag1mb3.msg.corp.akamai.com> <20170307031510.GN7733@mournblade.imrryr.org> <20170307032023.GO7733@mournblade.imrryr.org> <9471a5323a98405eaf0ee111fb0350b0@usma1ex-dag1mb3.msg.corp.akamai.com> <20170313201410.GG4095@mournblade.imrryr.org> <12461433fb264865972e9ddafab1c511@usma1ex-dag1mb1.msg.corp.akamai.com> <20170314162425.GA13868@andover.lhh.devever.net> From: Richard Barnes Date: Mon, 20 Mar 2017 12:10:20 -0400 Message-ID: To: Phillip Hallam-Baker Cc: Hugo Landau , "Salz, Rich" , "acme@ietf.org" Content-Type: multipart/alternative; boundary=001a114b7e2aa174fe054b2bc390 Archived-At: Subject: Re: [Acme] ACME draft is now in 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: Mon, 20 Mar 2017 16:10:26 -0000 --001a114b7e2aa174fe054b2bc390 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Mar 18, 2017 at 1:08 PM, Phillip Hallam-Baker wrote: > > > On Tue, Mar 14, 2017 at 2:24 PM, Richard Barnes wrote: > >> >> >> On Tue, Mar 14, 2017 at 12:24 PM, Hugo Landau >> wrote: >> >>> > > The CAA check is/was easy to make and crippling it >>> > > by not making it a requirement was IMNSHO a mistake. >>> > ... >>> > > I urge the WG to reconsider. >>> > >>> > Does anyone else agree with Viktor? Please speak up on the list this >>> week if so. >>> >>> I'd agree that the CAA check should be made mandatory. At least, I can'= t >>> think of any good reason why it shouldn't be. >>> >> >> I very strongly disagree. What checks the CA does before issuing is up >> to the CA's policy. This document provides tools for CAs to do those >> checks; it does not constrain what CAs do. >> >> >> >>> I'd also agree that the use of a DNSSEC-validating resolver accessed vi= a >>> a trusted network (preferably localhost) should be mandatory. >>> >> >> Likewise. >> >> =E2=80=8B=E2=80=8B >> --Richard >> > > =E2=80=8BIf that were so, why does ACME have any support for DNS validat= =E2=80=8Bion? It > is merely CA policy after all. > > The point of CAA is that it is the one mechanism that is provided to allo= w > domain owners to signal to third parties what parties they authorize to > issue certs. > > In my view CAA should be mandatory for the reasons above. > > The other reason for making CAA mandatory is that if we are going to full= y > automate the issue process, we might well want to use information in the > CAA records to facilitate that. That was the reason I thought Paul > Hoffman's idea of using the DNS name rather than a policy oid or some PKI= X > identifier was the right approach. > This specification has always been focused on providing tools for CAs, *not* on constraining what CAs must do. What MUSTs there are in the specification are to make clear the mechanisms that the specifications define, not to specify CA policy. CAA is clearly on the other side of that line -- it's not a part of the mechanisms we define in this specification, but a totally separate mechanism that CAs apply to vet requests. It's much more like high-value name checking than DNS validation. I would be fine adding a line to the "CA Policy Considerations" section [1], which is where other similar things have gone. To be clear: I think CAA checking is a good idea, and I'm delighted that CABF recently decided to require it [2]. I just don't think it's appropriate for ACME to require it. --Richard [1] https://ietf-wg-acme.github.io/acme/#rfc.section.10.5 [2] https://cabforum.org/pipermail/public/2017-March/009988.html --001a114b7e2aa174fe054b2bc390 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Mar 18, 2017 at 1:08 PM, Phillip Hallam-Baker <phill@halla= mbaker.com> wrote:


= On Tue, Mar 14, 2017 at 2:24 PM, Richard Barnes <rlb@ipv.sx> wrote:=

=

On Tue, Mar= 14, 2017 at 12:24 PM, Hugo Landau <hlandau@devever.net> w= rote:
> > = The CAA check is/was easy to make and crippling it
> > by not making it a requirement was IMNSHO a mistake.
> ...
> > I urge the WG to reconsider.
>
> Does anyone else agree with Viktor?=C2=A0 Please speak up on the list = this week if so.

I'd agree that the CAA check should be made mandatory. At least,= I can't
think of any good reason why it shouldn't be.

=
I very strongly disagree.=C2=A0 What checks the CA does b= efore issuing is up to the CA's policy.=C2=A0 This document provides to= ols for CAs to do those checks; it does not constrain what CAs do.

=C2=A0
I'd also agree that the use of a DNSSEC-validating resolver accessed vi= a
a trusted network (preferably localhost) should be mandatory.

Likewise.

=E2=80=8B=E2=80=8B
--Richar= d

<= div>
=E2=80=8BIf that were so, why does ACME = have any support for DNS validat=E2=80=8Bion? It is merely CA policy after = all.

The point of CAA is that it is the one mechanism that is provided to= allow domain owners to signal to third parties what parties they authorize= to issue certs.

In my view CAA should be mandatory for the reasons abo= ve.

The other reason for making CAA mandatory is that if we are going to = fully automate the issue process, we might well want to use information in = the CAA records to facilitate that. That was the reason I thought Paul Hoff= man's idea of using the DNS name rather than a policy oid or some PKIX = identifier was the right approach.

This specification has always been focused on providi= ng tools for CAs, *not* on constraining what CAs must do.=C2=A0 What MUSTs = there are in the specification are to make clear the mechanisms that the sp= ecifications define, not to specify CA policy.

CAA= is clearly on the other side of that line -- it's not a part of the me= chanisms we define in this specification, but a totally separate mechanism = that CAs apply to vet requests.=C2=A0 It's much more like high-value na= me checking than DNS validation.

I would be fine a= dding a line to the "CA Policy Considerations" section [1], which= is where other similar things have gone.

To be cl= ear: I think CAA checking is a good idea, and I'm delighted that CABF r= ecently decided to require it [2].=C2=A0 I just don't think it's ap= propriate for ACME to require it.

--Richard
<= div>

--001a114b7e2aa174fe054b2bc390-- From nobody Tue Mar 21 12:07:32 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 B82371270A0 for ; Tue, 21 Mar 2017 12:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.798 X-Spam-Level: X-Spam-Status: No, score=-9.798 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, RCVD_IN_MSPIKE_H2=-2.796, 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 wqbP_RNWJpD1 for ; Tue, 21 Mar 2017 12:07: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 C36151289B5 for ; Tue, 21 Mar 2017 12:07: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:To:Subject; bh=Fgt415Yjc9gAX8BO8cYIA0IOpigcI6w1YMDPPff5Hec=; b=pcYpV+WcIjq42d6nMozYGBzeHSli+Krk7uCWPf9PdadesKR2ka8IDWe/udlQhUmNyqKZVgCq9EYbvFQBvmGcPGtvRNu1XhI8MIJFWPVNwSSTE/2ws84TDKcHsmMSGVWoNs5TtVPWjC2dED6yZRUQoJasRugPA0fsD4ivhpqdSNw=; Received: ; Tue, 21 Mar 2017 12:07:29 -0700 To: acme@ietf.org References: <4918dfd6-6b4c-6a92-1767-a2876af8dd73@letsencrypt.org> From: Brad Warren Message-ID: <72f2da7b-2a75-3215-11ee-7498284a91f3@eff.org> Date: Tue, 21 Mar 2017 12:07:27 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Received-SPF: skipped for local relay Archived-At: Subject: Re: [Acme] Challenge names in final RFC 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, 21 Mar 2017 19:07:31 -0000 After talking about this with the rest of the Certbot team, we agree with Roland as well. While certainly either approach is doable, dropping the version number adds additional complexity for the many dozens of existing implementations for no real technical benefit. On 03/13/2017 11:26 PM, Alan Doherty wrote: > +1 > > At 04:28 14/03/2017 Tuesday, Roland Shoemaker wrote: >> I'd argue that removing the challenge version numbers adds unnecessary= >> complexity to the specification and any existing implementations going= >> forward. >> >> Existing servers and clients will need to have some kind of mapping fr= om >> the draft names to the final un-versioned names and any protocol >> revisions going forward will need to know about both the versioned and= >> un-versioned names so that they don't name a new version of a challeng= e >> using one of the draft version numbers, leading to existing >> implementations thinking an older version is actually being used. >> >> I agree dropping the version numbers is somewhat more aesthetically >> pleasing but I can't really see any actual technical reasons to do so,= >> while keeping them seems like it'd save a lot of headaches down the ro= ad. >> >> On 03/13/2017 11:56 AM, Richard Barnes wrote: >>> I would prefer we stick with dropping the version number, just becaus= e >>> it's cleaner and the future is bigger than the past. =20 >>> >>> >>> On Mar 13, 2017 2:27 PM, "Jacob Hoffman-Andrews" >> > wrote: >>> >>> Roland posted a PR tweaking the challenge names for the final RFC= : >>> https://github.com/ietf-wg-acme/acme/pull/272 >>> . >>> >>> This raised the question: What do we want the challenge names to = be in >>> the final RFC? I think we've been assuming that "http-01" would b= ecome >>> "http" once the RFC is published. However, this does create a sli= ghtly >>> deployment headache, in that draft-compatible implementations hav= e to >>> use one name, and RFC-compatible implementations have to use anot= her, so >>> it's hard to test working code with the final names before the RF= C is >>> really finalized. >>> >>> I don't have a strong opinion on this one way or another. What do= folks >>> on this list think? >>> >>> _______________________________________________ >>> 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 >>> >> --=20 >> Roland Bracewell Shoemaker >> Software Engineer >> Linux Foundation / Internet Security Research Group >> >> _______________________________________________ >> 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 shepherdz@vmware.com Tue Mar 21 22:14: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 B861112943B for ; Tue, 21 Mar 2017 22:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=onevmw.onmicrosoft.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 ceftDQsR_H9Z for ; Tue, 21 Mar 2017 22:14:38 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0068.outbound.protection.outlook.com [104.47.33.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7BD5126B7F for ; Tue, 21 Mar 2017 22:14:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onevmw.onmicrosoft.com; s=selector1-vmware-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=AqHi5RDjBuVabagH20xJSKYtQmJ5GMXyD5EzrpaqMFM=; b=F2PmkwM/5+KrY7ysisIhFrEtrWJDSHVCaGZ8rI2MHM3I+vGQYzXvAkYZEegsbcgOVXuhwiyKB4BM+HNdqkZYbojZgw+UrOADQyxYN7N+ntCd1A9mauC8I4CEtblVWgM5ZoUEhp7Bx4Lr6z0EgQpTg5X6K3F6kU1I9d+TPO39bOM= Received: from CY4PR05MB3045.namprd05.prod.outlook.com (10.172.155.135) by CY4PR05MB3046.namprd05.prod.outlook.com (10.172.155.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4; Wed, 22 Mar 2017 05:14:36 +0000 Received: from CY4PR05MB3045.namprd05.prod.outlook.com ([10.172.155.135]) by CY4PR05MB3045.namprd05.prod.outlook.com ([10.172.155.135]) with mapi id 15.01.0991.013; Wed, 22 Mar 2017 05:14:36 +0000 From: Zach Shepherd To: "acme@ietf.org" Thread-Topic: Use of "shortly" in normative language of Section 7.4, Applying for Certificate Issuance Thread-Index: AQHSossyXOSrxuUNyk6P1Tz/VfaYiQ== Date: Wed, 22 Mar 2017 05:14:36 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=vmware.com; x-originating-ip: [76.14.92.26] x-microsoft-exchange-diagnostics: 1; CY4PR05MB3046; 7:dXD+Y3ZhKAUOusBVSVZ6OLaycdEHOnQputKKTK6W00SCNIkQt9wme8FBpy68Wrjxeh4U6MfblnleK92K7K7M4Bciy9dz0NnULfZkZHNuF8uj8GPo04JLa9d1NR8Srh9bcP7vJTxhpERLMU2YROKpyOoJGwyAoR+KvGlV14qCR3MLfJqcqlHDmREi8yz4smSPdeObp9tujcC8+6qpYhQ/wlz0yjX3ebf/kW4ixluuApBBoYn+ieFZnGk/t54XIgcFxKSuQMqRy6f26ccGJKkxCW6AALZl23Z8R089I7np3VFDj36Q1uIclcRPIx3O/cSAr59OC5pgBfC/+h1tetYo9w==; 20:ENEIAciC5mbzFHp3nMMDow/GLoJHrF1CiUdYazE9V/jGyEZRdworRjxGl+TyocSpO+p/whFU0PeybJX6TPmQsdS0lQHnPayIHjLVQARyP2WzQ08h6m0G7Xi1npp43kKNbcsh1u6bZ5ioEQ5Ut+7gCptHYnRyar3fIRRimK9Tm44= x-ms-office365-filtering-correlation-id: bf86c43f-7872-437b-31c8-08d470e25567 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075); SRVR:CY4PR05MB3046; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123558025)(20161123564025)(20161123562025)(20161123560025)(20161123555025)(6072148); SRVR:CY4PR05MB3046; BCL:0; PCL:0; RULEID:; SRVR:CY4PR05MB3046; x-forefront-prvs: 02543CD7CD x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39410400002)(39830400002)(50986999)(54356999)(38730400002)(110136004)(66066001)(2501003)(2351001)(6916009)(5660300001)(19627405001)(8936002)(6606003)(3280700002)(3660700001)(7696004)(2900100001)(74316002)(2906002)(7736002)(6506006)(81166006)(6436002)(5640700003)(8676002)(1730700003)(102836003)(6116002)(3846002)(77096006)(189998001)(33656002)(9686003)(54896002)(122556002)(86362001)(53936002)(25786009)(55016002)(99286003); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR05MB3046; H:CY4PR05MB3045.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR05MB3045E18E69F2E536B9BFA8A4C03C0CY4PR05MB3045namp_" MIME-Version: 1.0 X-OriginatorOrg: vmware.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2017 05:14:36.0726 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR05MB3046 Archived-At: Subject: [Acme] Use of "shortly" in normative language of Section 7.4, Applying for Certificate 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: Wed, 22 Mar 2017 05:15:39 -0000 --_000_CY4PR05MB3045E18E69F2E536B9BFA8A4C03C0CY4PR05MB3045namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The following feedback is based on 8010a31 (current HEAD of master). Section 7.4, Applying for Certificate Issuance, states "The server MUST iss= ue the requested certificate and update the order resource with a URL for t= he certificate shortly after the client has fulfilled the server=92s requir= ements." Per RFC 2119 Section 6, the imperative MUST should be used with care and sp= aringly. The use of "shortly" in the above sentence is imprecise. It is not possible= for a server author to know, with confidence, that they are adhering to th= is requirement. It is not possible fore a client author to make design or i= mplementation decisions based on this requirement. I would propose either: a) Replacing "shortly" with a more precise expectation. b) Replacing "MUST" with "should". I believe there are advantages for setting expectations as to the turn-arou= nd time for certificate issuance and would therefore prefer option (a), ass= uming agreement could be reached on more precise language. Regards, Zach Shepherd --_000_CY4PR05MB3045E18E69F2E536B9BFA8A4C03C0CY4PR05MB3045namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

The following feedback is based on 8010a31 (current HEAD of master).
Section 7.4, Applying for Certificate Issuance, states "The server MUS= T issue the requested certificate and update the order resource with a URL = for the certificate shortly after the client has fulfilled the server=92s r= equirements."

Per RFC 2119 Section 6, the imperative MUST should be used with care and sp= aringly.

The use of "shortly" in the above sentence is imprecise. It is no= t possible for a server author to know, with confidence, that they are adhe= ring to this requirement. It is not possible fore a client author to make d= esign or implementation decisions based on this requirement.

I would propose either:
a) Replacing "shortly" with a more precise expectation.
b) Replacing "MUST" with "should".

I believe there are advantages for setting expectations as to the turn-arou= nd time for certificate issuance and would therefore prefer option (a), ass= uming agreement could be reached on more precise language.

Regards,
Zach Shepherd

--_000_CY4PR05MB3045E18E69F2E536B9BFA8A4C03C0CY4PR05MB3045namp_-- From shepherdz@vmware.com Tue Mar 21 22:14: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 7A15212943C for ; Tue, 21 Mar 2017 22:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=onevmw.onmicrosoft.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 zlo8zGx7rR8C for ; Tue, 21 Mar 2017 22:14:08 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0080.outbound.protection.outlook.com [104.47.33.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 600D4126B7F for ; Tue, 21 Mar 2017 22:14:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onevmw.onmicrosoft.com; s=selector1-vmware-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=FuS4rAGTYymhkV1yrSiRlRCUxQuM8/hQ+kFVlrHyRMk=; b=XY6wVMPj+rm0HEZYLLvdVyQjE3fHcMwnXpBgLXXFlUjsAqxgY60ehV/NUkJb8pkcj4N90biwCsikzB/dzI36Z9eALmTS7KJwGQ27N2NqvZxNLZ9BWwcjgw9V9dAQx/jA5j7JF24b02IMIWSwauVzsT97j7BYP3toeCSeP4cw608= Received: from CY4PR05MB3045.namprd05.prod.outlook.com (10.172.155.135) by CY4PR05MB3046.namprd05.prod.outlook.com (10.172.155.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4; Wed, 22 Mar 2017 05:14:05 +0000 Received: from CY4PR05MB3045.namprd05.prod.outlook.com ([10.172.155.135]) by CY4PR05MB3045.namprd05.prod.outlook.com ([10.172.155.135]) with mapi id 15.01.0991.013; Wed, 22 Mar 2017 05:14:05 +0000 From: Zach Shepherd To: "acme@ietf.org" Thread-Topic: Effects of the account recovery process described in Section 7.3, Account Creation Thread-Index: AQHSossgD1909vfK3U+BK7EhsBxgpQ== Date: Wed, 22 Mar 2017 05:14:05 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=vmware.com; x-originating-ip: [76.14.92.26] x-microsoft-exchange-diagnostics: 1; CY4PR05MB3046; 7:yNY0OegWb4C+IQl4+dEwhOYhLrJ/FhZSf5YWYRf1YJ6v1CniOsWmFi9xHG33PRDqofnP1DtBV0ybqm4WWTHSj+8gPIK2k9DikonI7EMESQPNu2PkwZxs7EW8g1VQ/L462EUmf4tdrdMYBQM2ZozufiZTpKV8vy2wj4Z4jqrfWWk+wy9fg5vb2XLe8NDRaHe6IsYX8Cni3XDn3javoh2Db9+0NWjL6UAJr7q4XwuZ3r81x+GEFx/qPU+yrFqlrAxtIUGnN7o7O3dry/igQ4KXGbIzamNfid052fwo6syHhNbihaL2WoRcSMurng3lhKFepq15w7qtC2/11TlXTJDMiQ==; 20:VYQR2Oj68okRSAxwMbRyKYHkdjFLG11vvSXng8FwtWJlNUdknJqE6t7YYmkIG39Gx5uTzee37VIUc+/Lsn3OQdQ4uBdNClzM39RW8WvmOXukWcru15tOEW4rpXIhaappb1tfctZnAKczy0SzyHj9ZajK7v3uFDj25Jeinl2Dkbg= x-ms-office365-filtering-correlation-id: 968a0650-8671-499e-4d63-08d470e242eb x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075); SRVR:CY4PR05MB3046; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123558025)(20161123564025)(20161123562025)(20161123560025)(20161123555025)(6072148); SRVR:CY4PR05MB3046; BCL:0; PCL:0; RULEID:; SRVR:CY4PR05MB3046; x-forefront-prvs: 02543CD7CD x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39410400002)(39830400002)(50986999)(54356999)(15650500001)(38730400002)(110136004)(66066001)(2501003)(2351001)(6916009)(5660300001)(19627405001)(8936002)(6606003)(3280700002)(3660700001)(7696004)(2900100001)(74316002)(2906002)(7736002)(6506006)(81166006)(6436002)(5640700003)(8676002)(1730700003)(102836003)(6116002)(3846002)(77096006)(189998001)(33656002)(9686003)(54896002)(122556002)(86362001)(53936002)(25786009)(55016002)(99286003); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR05MB3046; H:CY4PR05MB3045.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR05MB3045AA5245DAE2DDE34B2DA4C03C0CY4PR05MB3045namp_" MIME-Version: 1.0 X-OriginatorOrg: vmware.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2017 05:14:05.2178 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR05MB3046 Archived-At: Subject: [Acme] Effects of the account recovery process described in Section 7.3, Account Creation 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, 22 Mar 2017 05:15:44 -0000 --_000_CY4PR05MB3045AA5245DAE2DDE34B2DA4C03C0CY4PR05MB3045namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The following feedback is based on 8010a31 (current HEAD of master). Section 7.3, Account Creation, states "If the server already has an account= registered with the provided account key, then it MUST return a response w= ith a 200 (OK) status code and provide the URI of that account in the Locat= ion header field. This allows a client that has an account key but not the = corresponding account URI to recover the account URI." This section does not specify what the server should do with the data in th= e request payload, such as contact information. Ignoring the data from the = request, using the data from the request to update the registered account, = and union-ing the data from the two sources each seem like sane implementat= ion decisions. This may lead to significant behavioral differences between = server implementations, complicating client implementation. I would propose either: a) Indicating that the server must discard the information from the account= creation request in this case. b) Indicating that the server must treat the request as an account update o= peration. Given that updating the account as a part of the recovery operation could b= e perceived as a surprising side effect and given that there is already a w= ell-defined way to perform an update to an account, I would prefer option (= a). Regards, Zach Shepherd --_000_CY4PR05MB3045AA5245DAE2DDE34B2DA4C03C0CY4PR05MB3045namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

The following feedback is based on 8010a31 (current HEAD of master).
Section 7.3, Account Creation, states "If the server already has an ac= count registered with the provided account key, then it MUST return a respo= nse with a 200 (OK) status code and provide the URI of that account in the = Location header field. This allows a client that has an account key but not the corresponding account URI to re= cover the account URI."

This section does not specify what the server should do with the data in th= e request payload, such as contact information. Ignoring the data from the = request, using the data from the request to update the registered account, = and union-ing the data from the two sources each seem like sane implementation decisions. This may lead to= significant behavioral differences between server implementations, complic= ating client implementation.

I would propose either:
a) Indicating that the server must discard the information from the account= creation request in this case.
b) Indicating that the server must treat the request as an account update o= peration.

Given that updating the account as a part of the recovery operation could b= e perceived as a surprising side effect and given that there is already a w= ell-defined way to perform an update to an account, I would prefer option (= a).

Regards,
Zach Shepherd

--_000_CY4PR05MB3045AA5245DAE2DDE34B2DA4C03C0CY4PR05MB3045namp_-- From shepherdz@vmware.com Tue Mar 21 22:13: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 9E01C129455 for ; Tue, 21 Mar 2017 22:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=onevmw.onmicrosoft.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 gD9jyop7o4cr for ; Tue, 21 Mar 2017 22:13:18 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0044.outbound.protection.outlook.com [104.47.33.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FD2F12943B for ; Tue, 21 Mar 2017 22:13:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onevmw.onmicrosoft.com; s=selector1-vmware-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Gqv7qvjoSo4Oar/Bo7+eNSrWtnXzqnibYrIoE+e76nQ=; b=GbA/XHN09Ye5iCoTKvpt01RXEA49fJw0RuHcRacGlSrA7cDgoDX1w97XGdElk4HQgxWGBjaFpcUsH7rlR5RsYY+/+sY1lrUaA5v8HExHxZKsidx04lBBTwiiWP4WvAtdzL7q8P8eZipifaGdBsnYPaksDCT9fGrT4Wk2VYNpKSI= Received: from CY4PR05MB3045.namprd05.prod.outlook.com (10.172.155.135) by CY4PR05MB3046.namprd05.prod.outlook.com (10.172.155.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4; Wed, 22 Mar 2017 05:13:16 +0000 Received: from CY4PR05MB3045.namprd05.prod.outlook.com ([10.172.155.135]) by CY4PR05MB3045.namprd05.prod.outlook.com ([10.172.155.135]) with mapi id 15.01.0991.013; Wed, 22 Mar 2017 05:13:16 +0000 From: Zach Shepherd To: "acme@ietf.org" Thread-Topic: Allowing clients to understand the account creation functionality supported by a server Thread-Index: AQHSossDe/ZDvpfKg0uDSiRpCfMQsw== Date: Wed, 22 Mar 2017 05:13:16 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=vmware.com; x-originating-ip: [76.14.92.26] x-microsoft-exchange-diagnostics: 1; CY4PR05MB3046; 7:sClNgTAIvtI8dAKANnBfrxp7QQJrvYexE7U7NOe1PpN3ztQCg3M+G647kxR2KfqZmuGsSIApCXVK6djrv/wVvXganYr0n24+t4UzOjhmPitpikIGEEG7sF5riKcUIlJ+d4NgtACoZuXWb0+n7nV9tFsU4mWnVI+253M3cDJp2PGSG9GfW3+RmRwTDbuw2SAyZi3hRp5dyRKNSRhwVXzmwzqq2zXc0IF60IOcO1S8g0e7wiNwPDpI2usXQblpTZMOUMxToLXw/0Wke70MQTUCifmOy235BNprOqgwzJ2XT+C3WlLGxwPgcoFsBggXas1bLgxH+sPP+VF4dBt/wjIERg==; 20:u7lChSlHyjNAfGO0/Q2072MkbvF/3onDZlkehbf62worUAXJ6/eXEKu60UncH604F0BmzgeDMS1G65xIfMbUucTGHCw2+yDdWbkAOYbNHMoz8oFpTHpUuLjO4WkG/rb9wDwQQvz+EouVk3xe3xMrePSqUGDBNaTIwIGv/WXZ44w= x-ms-office365-filtering-correlation-id: 46aeaaa5-b8c8-4183-af19-08d470e225d1 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075); SRVR:CY4PR05MB3046; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123558025)(20161123564025)(20161123562025)(20161123560025)(20161123555025)(6072148); SRVR:CY4PR05MB3046; BCL:0; PCL:0; RULEID:; SRVR:CY4PR05MB3046; x-forefront-prvs: 02543CD7CD x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39410400002)(39830400002)(50986999)(54356999)(15650500001)(38730400002)(110136004)(66066001)(2501003)(2351001)(6916009)(5660300001)(19627405001)(8936002)(6606003)(3280700002)(3660700001)(7696004)(2900100001)(74316002)(2906002)(7736002)(6506006)(81166006)(6436002)(5640700003)(8676002)(1730700003)(102836003)(6116002)(3846002)(77096006)(189998001)(33656002)(9686003)(54896002)(122556002)(86362001)(53936002)(25786009)(55016002)(99286003); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR05MB3046; H:CY4PR05MB3045.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR05MB30452868280B78056B4D44FCC03C0CY4PR05MB3045namp_" MIME-Version: 1.0 X-OriginatorOrg: vmware.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2017 05:13:16.3139 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR05MB3046 Archived-At: Subject: [Acme] Allowing clients to understand the account creation functionality supported by a server 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, 22 Mar 2017 05:15:55 -0000 --_000_CY4PR05MB30452868280B78056B4D44FCC03C0CY4PR05MB3045namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The following feedback is based on 8010a31 (current HEAD of master). Section 7.3, Account Creation, states "The server SHOULD validate that the = contact URLs in the =93contact=94 field are valid and supported by the serv= er. If the client provides the server with an invalid or unsupported contac= t URL, then the server MUST return an error of type =93invalidContact=94, w= ith a description describing the error and what types of contact URL the se= rver considers acceptable." It is undesirable that a client can only determine the supported schemes fo= r contact URLs by attempting to submit an unsupported URL. This makes it di= fficult to implement a general-purpose client which can work with a variety= of servers which might each support a different set of contact schemes. I would propose including information about the supported contact schemes i= n a machine readable format as a part of some GET request. Section 7.3, Account Creation, also states "A client creates a new account = with the server by sending a POST request to the server=92s new-account URI= . The body of the request is a stub account object containing the =93contac= t=94 field and optionally the =93terms-of-service-agreed=94 field. ... The = server MUST ignore any values provided in the =93orders=94 fields in accoun= t bodies sent by the client, as well as any other fields that it does not r= ecognize. If new fields are specified in the future, the specification of t= hose fields MUST describe whether they can be provided by the client." Similarly, it would be beneficial for a client to be able to determine the = set of fields that a server does recognize so that it does not prompt the u= ser for information which the server will not make use of. I would propose including information about the fields which may be specifi= ed as a part of account creation in a machine readable format as a part of = some GET request. Together, these proposals could be addressed by responding to GET requests = on the server's new-account URI with an object describing the client-specif= iable account creation fields and applicable restrictions on each, such as = the supported schemes for contacts URLs. Regards, Zach Shepherd --_000_CY4PR05MB30452868280B78056B4D44FCC03C0CY4PR05MB3045namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

The following feedback is based on 8010a31 (current HEAD of master).
Section 7.3, Account Creation, states "The server SHOULD validate that= the contact URLs in the =93contact=94 field are valid and supported by the= server. If the client provides the server with an invalid or unsupported c= ontact URL, then the server MUST return an error of type =93invalidContact=94, with a description describing the erro= r and what types of contact URL the server considers acceptable."

It is undesirable that a client can only determine the supported schemes fo= r contact URLs by attempting to submit an unsupported URL. This makes it di= fficult to implement a general-purpose client which can work with a variety= of servers which might each support a different set of contact schemes.

I would propose including information about the supported contact schemes i= n a machine readable format as a part of some GET request.


Section 7.3, Account Creation, also states "A client creates a new acc= ount with the server by sending a POST request to the server=92s new-accoun= t URI. The body of the request is a stub account object containing the =93c= ontact=94 field and optionally the =93terms-of-service-agreed=94 field. ... The server MUST ignore any values provided in the =93orders=94 = fields in account bodies sent by the client, as well as any other fields th= at it does not recognize. If new fields are specified in the future, the sp= ecification of those fields MUST describe whether they can be provided by the client."

Similarly, it would be beneficial for a client to be able to determine the = set of fields that a server does recognize so that it does not prompt the u= ser for information which the server will not make use of.

I would propose including information about the fields which may be specifi= ed as a part of account creation in a machine readable format as a part of = some GET request.


Together, these proposals could be addressed by responding to GET requests = on the server's new-account URI with an object describing the client-specif= iable account creation fields and applicable restrictions on each, such as = the supported schemes for contacts URLs.

Regards,
Zach Shepherd

--_000_CY4PR05MB30452868280B78056B4D44FCC03C0CY4PR05MB3045namp_-- From shepherdz@vmware.com Tue Mar 21 22:12: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 DD8C0129459 for ; Tue, 21 Mar 2017 22:12:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.697 X-Spam-Level: X-Spam-Status: No, score=-4.697 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, RCVD_IN_MSPIKE_H2=-2.796, 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=onevmw.onmicrosoft.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 1aySuDWk_-u9 for ; Tue, 21 Mar 2017 22:12:47 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0078.outbound.protection.outlook.com [104.47.34.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22E94129455 for ; Tue, 21 Mar 2017 22:12:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onevmw.onmicrosoft.com; s=selector1-vmware-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8NsPA0oCtBDyqYB6dSK8Y4+GqjsYoJeNzpLYWB0umyo=; b=haYLBzQN20Pl+4XK5xJ3cWWjEkaRtnu+CrwRFtPJIqdl7LQ4SziIH5/RZ1nioMokLhU24peXaqJs/ukMfFip4GdNSbAg2z0IOFRldt7/jq5zI7yXM+D74AIyxEnPqdn0qIZ6S7eNuH44wtj20Z5Vqe8lg56MC2FqkTDyUdh/tdY= Received: from CY4PR05MB3045.namprd05.prod.outlook.com (10.172.155.135) by CY4PR05MB3046.namprd05.prod.outlook.com (10.172.155.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4; Wed, 22 Mar 2017 05:12:46 +0000 Received: from CY4PR05MB3045.namprd05.prod.outlook.com ([10.172.155.135]) by CY4PR05MB3045.namprd05.prod.outlook.com ([10.172.155.135]) with mapi id 15.01.0991.013; Wed, 22 Mar 2017 05:12:46 +0000 From: Zach Shepherd To: "acme@ietf.org" Thread-Topic: Entropy requirement for challenge token Thread-Index: AQHSosrwWAuBjkBA9EKmndMTvxHqPg== Date: Wed, 22 Mar 2017 05:12:45 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=vmware.com; x-originating-ip: [76.14.92.26] x-microsoft-exchange-diagnostics: 1; CY4PR05MB3046; 7:qH+cn+OsFocGuEv1mH6abxXnIayiSupGtjL7uwld7xpe8umY3bEDsF202kZSSEF67OmlDnhPRCd0/+VCn7oJwieEBr19Y21b+CXOIziGR4eNbOi8lmuAPYIdL+kMg2hFxxDc8ZCGkNvLLupFe+CWPLc19zm0nx3QDmopVOJzXS7LO/+TwqKReyODlAIUn9MQ3GnMNg0dqy491RgVU9HLBlGKS/XvJ8sc147JqDAM/wCQtvqiX9h0z00ZUwi7u14w4jKcCynTMQenV3D/h/VqlvgWdW6q1YPIczICi7jjjF19xskbkwHZ3Z20dsgMhH5wZTE7S0ywnT95ENUQg3Xbgw==; 20:DmMh8YWqe/CzEBZNPL1tu2gRTIvni6Z7IMkuT5dkB9QfPCReooqCe5n1wXp6z5GY8L/JnhoynnGR4AtL2/Z3PUJonl5ligyuqEGzslnHPKKbjmi8SIKIi7J+eXmAJL6MJKlhVj+8vihqxMCUhfdb/3/1NEAZ4/3hRVEuEkRw5Y0= x-ms-office365-filtering-correlation-id: 5df49c5c-5426-4bca-4b0d-08d470e213b8 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075); SRVR:CY4PR05MB3046; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123558025)(20161123564025)(20161123562025)(20161123560025)(20161123555025)(6072148); SRVR:CY4PR05MB3046; BCL:0; PCL:0; RULEID:; SRVR:CY4PR05MB3046; x-forefront-prvs: 02543CD7CD x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39410400002)(39830400002)(50986999)(54356999)(38730400002)(110136004)(66066001)(2501003)(2351001)(6916009)(5660300001)(19627405001)(8936002)(6606003)(3280700002)(3660700001)(7696004)(2900100001)(74316002)(2906002)(7736002)(6506006)(81166006)(6436002)(5640700003)(8676002)(1730700003)(102836003)(6116002)(3846002)(77096006)(189998001)(33656002)(9686003)(54896002)(122556002)(86362001)(53936002)(25786009)(55016002)(99286003); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR05MB3046; H:CY4PR05MB3045.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR05MB3045ECEBE933A57E2399C91DC03C0CY4PR05MB3045namp_" MIME-Version: 1.0 X-OriginatorOrg: vmware.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2017 05:12:45.7623 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR05MB3046 Archived-At: Subject: [Acme] Entropy requirement for challenge token 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, 22 Mar 2017 05:16:00 -0000 --_000_CY4PR05MB3045ECEBE933A57E2399C91DC03C0CY4PR05MB3045namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The following feedback is based on 8010a31 (current HEAD of master). Section 6.2, Request Authentication, states "Note that authentication via s= igned JWS request bodies implies that GET requests are not authenticated. S= ervers MUST NOT respond to GET requests for resources that might be conside= red sensitive. Account resources are the only sensitive resources defined i= n this specification." Sections 8.2, HTTP; 8.3, TLS with Server Name Indication (TLS SNI); and 8.4= , DNS, each describe a GET request and specify a "token" value which "MUST = have at least 128 bits of entropy, in order to prevent an attacker from gue= ssing it." This seems incongruous. If the token must be kept secret an attacker, it sh= ould not be served via an unauthenticated channel. Assuming secrecy of the token is not important, I would propose removing th= e entropy requirement and including some discussion of the token in Section= 10, Security Considerations. Regards, Zach Shepherd --_000_CY4PR05MB3045ECEBE933A57E2399C91DC03C0CY4PR05MB3045namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

The following feedback is based on 8010a31 (current HEAD of master).
Section 6.2, Request Authentication, states "Note that authentication = via signed JWS request bodies implies that GET requests are not authenticat= ed. Servers MUST NOT respond to GET requests for resources that might be co= nsidered sensitive. Account resources are the only sensitive resources defined in this specification."

Sections 8.2, HTTP; 8.3, TLS with Server Name Indication (TLS SNI); and 8.4= , DNS, each describe a GET request and specify a "token" value wh= ich "MUST have at least 128 bits of entropy, in order to prevent an at= tacker from guessing it."

This seems incongruous. If the token must be kept secret an attacker, it sh= ould not be served via an unauthenticated channel.

Assuming secrecy of the token is not important, I would propose removing th= e entropy requirement and including some discussion of the token in Section= 10, Security Considerations.

Regards,
Zach Shepherd

--_000_CY4PR05MB3045ECEBE933A57E2399C91DC03C0CY4PR05MB3045namp_-- From nobody Wed Mar 22 09:35: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 113C6129AAD for ; Wed, 22 Mar 2017 09:35:23 -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 GAo12ovW26Hf for ; Wed, 22 Mar 2017 09:35:20 -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 6AFA1129AD5 for ; Wed, 22 Mar 2017 09:35:15 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id n11so42854551wma.0 for ; Wed, 22 Mar 2017 09:35:15 -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=9Nk5vvuqGkFDa7OVP1i7Lvr/HFp1cR9G3e+weCxJJ1Q=; b=N+F35SU0NZdLN0/MifKABS81ma0yzwEuT9yDiutiYVM8q0tMO7YbmXD4Vo2ISUj9ui jvhCzybwj7Znn2FozDAkH++qHPi9zjjiBGiINA1MOsx8NjVHxvcKqIYQ34SXtTiWnkIT iRjAejWQhrMiYMEd/dJDHXygjPBy9jmewihX8= 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=9Nk5vvuqGkFDa7OVP1i7Lvr/HFp1cR9G3e+weCxJJ1Q=; b=VF3auudjnA35pMwRxhZeVZ70vdkKBwOG/PgNfTiZw4dXJD4GIfV6UM6eMmM3KQTz50 EixKLCF7b2KHqliFpvUSWBEi1uhRUuI1yqMtbQAyRH1bf7hQHFRR9WmkWAUqlY3SaccW vSF+PmQYzolE3NYjMW7qXE7QjUkqnsL48/aape1TNfd2Zyglm8eTljUmnrBxonIrBp5K k54FQT4Jyu8xG3UZ68Vo6UXGnpS8QOkYKi8OHUPND/dwPwafzV60qCjEVsnGcZPMjD5X 25qz3FSTn23Pwesx2FMB/OT43Z97vN9MphlMQ4JlbStFwE0aHRbWoesL+xzg0nb2/mHi EejA== X-Gm-Message-State: AFeK/H3B3K+MkRjGyFuaMS7CEOAjHllwiLo8UVhFhpPVrN1a/XpwTYGLoO3F9MS8CR8mAE9xeQ8rjnH8TIMOrM5F X-Received: by 10.25.92.25 with SMTP id q25mr11578554lfb.121.1490200513886; Wed, 22 Mar 2017 09:35:13 -0700 (PDT) MIME-Version: 1.0 Reply-To: cpu@letsencrypt.org Received: by 10.25.21.211 with HTTP; Wed, 22 Mar 2017 09:35:13 -0700 (PDT) In-Reply-To: References: <96d31ef7-0dda-019c-4072-165fcd57e34f@hemio.de> From: Daniel McCarney Date: Wed, 22 Mar 2017 12:35:13 -0400 Message-ID: To: Sophie Herold Cc: IETF ACME Content-Type: multipart/alternative; boundary=94eb2c0db380465dd9054b5458dc Archived-At: Subject: Re: [Acme] Missing structure and unspecified parts in "Account Creation" 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, 22 Mar 2017 16:35:23 -0000 --94eb2c0db380465dd9054b5458dc Content-Type: text/plain; charset=UTF-8 Thanks for following up on your initial message with PR's Sophie. For PR 281 I left a small comment but otherwise LGTM. For PR 280 - I think the proposed changes are great with the exception of one question I have RE: the mechanism to differentiate the account URI recovery POSTs from account creation POSTs. Do you think it would be clearer to separate the account URI recovery to a new endpoint? It seems like the empty JWS payload approach would work, but we're adding more complexity to the account creation endpoint to allow it to double as the account URI recovery endpoint. Maybe it's time to separate it properly. What does the list think? On Mon, Mar 20, 2017 at 4:50 AM, Sophie Herold wrote: > PR for 1.-3. > > > PR for 4. > > > Issue related to 4. > > > On 20/02/17 16:17, Sophie Herold wrote: > > 1. > > I cannot find where the response to account updates is specified. > > > > Boulder replies with "202 Accepted" and an account object. Since > > updates with trivial payload should be used for account information, > > it seems to be expected that an account object is returned. The > > specified response status for "Account deactivation" is "200 OK". > > It would be consistent to specify the same response status for > > account updates I guess? > > > > 2. > > The client should be able to choose between "Account URI recovery" > > and "Account Creation", if needed. A possible way would be to clarify > > that account creations with trivial payload MUST be rejected. However, > > if an account exists, the "Content-Location" header and "200 OK" is > > returned, independent of the payloads content. Therefore a trivial > > payload could be used to check if an account with the used key exists, > > without creating it. > > > > 3. > > As "6.3.4. Account deactivation", other queries should get their own > > sub-sub sections. Something like > > - "6.3.x Account URI recovery" ("new-account", maybe trivial payload) > > - "6.3.x Account update" > > - "6.3.x Account information" (update with trivial payload) > > > > 4. > > Is it really an account URI or rather an account URL? Some fields > > changed from "uri" to "url". I guess, all occurrences of URIs should > > be URLs. The only exception that I see is the "type" field in the > > "Problem Details" responses. > > > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > --94eb2c0db380465dd9054b5458dc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for following up on your initial message with PR= 9;s Sophie.

For PR 281 I left a small comment but otherwise LGTM.
For PR 280 - I think the proposed changes are great with the exception= of one question I have RE: the mechanism to differentiate the account URI = recovery POSTs from account creation POSTs.
Do you think it would be cl= earer to separate the account URI recovery to a new endpoint?
It seems l= ike the empty JWS payload approach would work, but we're adding more co= mplexity to the account creation endpoint to allow it to double as the acco= unt URI recovery endpoint. Maybe it's time to separate it properly. Wha= t does the list think?

On Mon, Mar 20, 2017 at 4:50 AM, Sophie Herold <sophie_her= old@hemio.de> wrote:
PR for= 1.-3.
<https://github.com/ietf-wg-acme/acme/pull/280<= /a>>

PR for 4.
<https://github.com/ietf-wg-acme/acme/pull/281<= /a>>

Issue related to 4.
<https://github.com/ietf-wg-acme/acme/issues/= 278>

On 20/02/17 16:17, Sophie Herold wrote:
> 1.
>=C2=A0 =C2=A0I cannot find where the response to account updates is spe= cified.
>
>=C2=A0 =C2=A0Boulder replies with "202 Accepted" and an accou= nt object. Since
>=C2=A0 =C2=A0updates with trivial payload should be used for account in= formation,
>=C2=A0 =C2=A0it seems to be expected that an account object is returned= . The
>=C2=A0 =C2=A0specified response status for "Account deactivation&q= uot; is "200 OK".
>=C2=A0 =C2=A0It would be consistent to specify the same response status= for
>=C2=A0 =C2=A0account updates I guess?
>
> 2.
>=C2=A0 =C2=A0The client should be able to choose between "Account = URI recovery"
>=C2=A0 =C2=A0and "Account Creation", if needed. A possible wa= y would be to clarify
>=C2=A0 =C2=A0that account creations with trivial payload MUST be reject= ed. However,
>=C2=A0 =C2=A0if an account exists, the "Content-Location" hea= der and "200 OK" is
>=C2=A0 =C2=A0returned, independent of the payloads content. Therefore a= trivial
>=C2=A0 =C2=A0payload could be used to check if an account with the used= key exists,
>=C2=A0 =C2=A0without creating it.
>
> 3.
>=C2=A0 =C2=A0As "6.3.4.=C2=A0 Account deactivation", other qu= eries should get their own
>=C2=A0 =C2=A0sub-sub sections. Something like
>=C2=A0 =C2=A0 - "6.3.x Account URI recovery" ("new-accou= nt", maybe trivial payload)
>=C2=A0 =C2=A0 - "6.3.x Account update"
>=C2=A0 =C2=A0 - "6.3.x Account information" (update with triv= ial payload)
>
> 4.
>=C2=A0 =C2=A0Is it really an account URI or rather an account URL? Some= fields
>=C2=A0 =C2=A0changed from "uri" to "url". I guess, = all occurrences of URIs should
>=C2=A0 =C2=A0be URLs. The only exception that I see is the "type&q= uot; field in the
>=C2=A0 =C2=A0"Problem Details" responses.
>

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

--94eb2c0db380465dd9054b5458dc-- From nobody Wed Mar 22 09:40: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 988901294C3 for ; Wed, 22 Mar 2017 09:39:58 -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 SIiIC7IuiZm9 for ; Wed, 22 Mar 2017 09:39:56 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::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 01509129B4B for ; Wed, 22 Mar 2017 09:39:24 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id u132so41958527wmg.0 for ; Wed, 22 Mar 2017 09:39:24 -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=Mm10KVMCaB141Jsx9bxATn56L2BtThtQRxbbLvXVSUo=; b=aqkvM4jo04bOW5JXh+flVG+COIoZxstufssi+vEANhQ/VqYHOXjSEIM3c/ifFkrULH 5OORSIdL7iOVXD2DOqzEr2K92QHoKNzdhxOc1Uw76itoFq1GLp+dIdq4Gd1mYIO1ZU4N bTSH+QoVS0eULIc+V4QMwhcA4BjSNA8v5UDrY= 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=Mm10KVMCaB141Jsx9bxATn56L2BtThtQRxbbLvXVSUo=; b=ZkbpaFY6k3cuqaRXWuF9dqPRntJ5/sMe9jIIkOjJ12+1K+72/wYsnQsNdEFPmjjzGd DGBe48SxJ2Rhepm/MoDAdTYj0gWBYKPDZu7VGt2aOt1jf/dvB02OecWoa7Jk7OEpAJZR en+uNCNIQGixfXuS8lZdbIEvq+CuqjBDsetcfW4JPmvk/bvRszucl7c3hlsZBAUURCgN wjlLArrVPMr7N0Nhh6KU5370bfPI/BitXZeFtFYC8pyahqCgKzzTR35QAO3VrRcZC0U3 f0lJrZVV5AVdwbt0wAAPjlYACDxkixmJvxrKnv/Wb6EupHuNm/pFh97uyc4XGd6g7VqN MWIA== X-Gm-Message-State: AFeK/H3TR9elF+DTLSX+aYNS/zFevxscwxWsygNPdMGEeeMv3eIOHG9q2g4NW6azZYo/m2tTgTFZ9xG/HEiaQB1r X-Received: by 10.25.211.2 with SMTP id k2mr12337061lfg.61.1490200763542; Wed, 22 Mar 2017 09:39:23 -0700 (PDT) MIME-Version: 1.0 Reply-To: cpu@letsencrypt.org Received: by 10.25.21.211 with HTTP; Wed, 22 Mar 2017 09:39:22 -0700 (PDT) In-Reply-To: References: From: Daniel McCarney Date: Wed, 22 Mar 2017 12:39:22 -0400 Message-ID: To: Zach Shepherd Cc: "acme@ietf.org" Content-Type: multipart/alternative; boundary=001a11417b0827c94d054b5467b9 Archived-At: Subject: Re: [Acme] Use of "shortly" in normative language of Section 7.4, Applying for Certificate 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: Wed, 22 Mar 2017 16:39:59 -0000 --001a11417b0827c94d054b5467b9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Zach, For background I think this MUST originated out of this thread: https://mailarchive.ietf.org/arch/msg/acme/0lVmGl8e-rmSH0x7ycDW5dj6GAY I would prefer option A) as well. It seems better to clear up the non-normative language than to step backwards to a place where proactive issuance may or may not happen without a clear signalling to the client of which a server will do. I think the use of "shortly" here is to allow the server some grace to determine that the order is completed and issuance can be performed. Perhaps we could change the language to say "The server MUST issue the requested certificate and update the order resource with a URL for the certificate after it has determined the client has fulfilled the server's requirements" and not impose any specific mention of the time between the client completing the challenges and the server noticing. Thoughts? On Wed, Mar 22, 2017 at 1:14 AM, Zach Shepherd wrote= : > The following feedback is based on 8010a31 (current HEAD of master). > > Section 7.4, Applying for Certificate Issuance, states "The server MUST > issue the requested certificate and update the order resource with a URL > for the certificate shortly after the client has fulfilled the server=E2= =80=99s > requirements." > > Per RFC 2119 Section 6, the imperative MUST should be used with care and > sparingly. > > The use of "shortly" in the above sentence is imprecise. It is not > possible for a server author to know, with confidence, that they are > adhering to this requirement. It is not possible fore a client author to > make design or implementation decisions based on this requirement. > > I would propose either: > a) Replacing "shortly" with a more precise expectation. > b) Replacing "MUST" with "should". > > I believe there are advantages for setting expectations as to the > turn-around time for certificate issuance and would therefore prefer opti= on > (a), assuming agreement could be reached on more precise language. > > Regards, > Zach Shepherd > > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > > --001a11417b0827c94d054b5467b9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Zach,

For background I think this MUST originate= d out of this thread:=C2=A0https://mailarchive.ietf.org/arch/msg/ac= me/0lVmGl8e-rmSH0x7ycDW5dj6GAY=C2=A0

I would prefer option A) as= well. It seems better to clear up the non-normative language than to step = backwards to a place where proactive issuance may or may not happen without= a clear signalling to the client of which a server will do.

I think= the use of "shortly" here is to allow the server some grace to d= etermine that the order is completed and issuance can be performed.
Per= haps we could change the language to say "The server MUST issue the re= quested certificate and update the order resource with a URL for the certif= icate after it has determined the client has fulfilled the server's req= uirements" and not impose any specific mention of the time between the= client completing the challenges and the server noticing. Thoughts?
<= div class=3D"gmail_extra">
On Wed, Mar 22, 20= 17 at 1:14 AM, Zach Shepherd <shepherdz@vmware.com> wrote= :

The following feedback is based on 8010a31 (current HEAD of master).
Section 7.4, Applying for Certificate Issuance, states "The server MUS= T issue the requested certificate and update the order resource with a URL = for the certificate shortly after the client has fulfilled the server=E2=80= =99s requirements."

Per RFC 2119 Section 6, the imperative MUST should be used with care and sp= aringly.

The use of "shortly" in the above sentence is imprecise. It is no= t possible for a server author to know, with confidence, that they are adhe= ring to this requirement. It is not possible fore a client author to make d= esign or implementation decisions based on this requirement.

I would propose either:
a) Replacing "shortly" with a more precise expectation.
b) Replacing "MUST" with "should".

I believe there are advantages for setting expectations as to the turn-arou= nd time for certificate issuance and would therefore prefer option (a), ass= uming agreement could be reached on more precise language.

Regards,
Zach Shepherd


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


--001a11417b0827c94d054b5467b9-- From nobody Wed Mar 22 09:42:50 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 E143B129B35 for ; Wed, 22 Mar 2017 09:42:47 -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 T2P95Ur2CaAx for ; Wed, 22 Mar 2017 09:42:45 -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 09B95129B74 for ; Wed, 22 Mar 2017 09:42:09 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id u132so42027589wmg.0 for ; Wed, 22 Mar 2017 09:42:09 -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=qJ1tVWmG7SgctF6LcI0LCz3/8AzRv8YrKQUCrZ6wCjA=; b=OG/fO4HcOnEFOrIZxGZjkog3vCEFIf4xoHUmoMrE2UmomRPaceg7d1aExIIxWCfxyt 5mfW0egHzpQI3uEkx9bFjWH+/X04DUXuf88A+ddAnNNLJSJUP55BhOIg5hUcBbBOqyPc +yRkxwdM7O6A92VzJen9/jdJFpOcZQACw4Nfs= 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=qJ1tVWmG7SgctF6LcI0LCz3/8AzRv8YrKQUCrZ6wCjA=; b=r87HNwDiiAxoYd/yw47dlwOYtxeqb6dA+BdoLHkk6u4CpPrN+heGhy+p1PajxuiNJz I9G9s/8CjluaPaZ5uNiQ4zguBGtKm3/P4btlL2giExKMt4zb4WQTTk309SI2nD4GLAjA 4mBwNLUucJPKZggZy/FYHhu5XO38mw1bVt/ZcpW6ceBbRXYXDQST+H9jGL7TYLVitpwB iqXMCdjC2Qi4+e4H9Zl+JcQfi3V6aaJp4DzoH4DaCh+GfocwCEHpX5WihImPU3Igqrtb LFsyoyvGJatorGHTgpvzN4IXvVODxHGmVruWOBJZWASVGA+h6x/IJxPYESzBjGJpMpME p8vg== X-Gm-Message-State: AFeK/H2S8hiMEC+ayKu9t5WhnPVrB24B2auVnDuALcxufC6q7ZnszsilwnyPlSIvno+lTyHuhFurQvwBEzDp6LZG X-Received: by 10.25.211.2 with SMTP id k2mr12341862lfg.61.1490200928479; Wed, 22 Mar 2017 09:42:08 -0700 (PDT) MIME-Version: 1.0 Reply-To: cpu@letsencrypt.org Received: by 10.25.21.211 with HTTP; Wed, 22 Mar 2017 09:42:07 -0700 (PDT) In-Reply-To: References: From: Daniel McCarney Date: Wed, 22 Mar 2017 12:42:07 -0400 Message-ID: To: Zach Shepherd Cc: "acme@ietf.org" Content-Type: multipart/alternative; boundary=001a11417b08fc8109054b547019 Archived-At: Subject: Re: [Acme] Effects of the account recovery process described in Section 7.3, Account Creation 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, 22 Mar 2017 16:42:48 -0000 --001a11417b08fc8109054b547019 Content-Type: text/plain; charset=UTF-8 Hi Zach, I agree with your assessment. I think adding language specifying that the server not treat the account creation request as an update to the existing account is the best option. - Daniel On Wed, Mar 22, 2017 at 1:14 AM, Zach Shepherd wrote: > The following feedback is based on 8010a31 (current HEAD of master). > > Section 7.3, Account Creation, states "If the server already has an > account registered with the provided account key, then it MUST return a > response with a 200 (OK) status code and provide the URI of that account in > the Location header field. This allows a client that has an account key but > not the corresponding account URI to recover the account URI." > > This section does not specify what the server should do with the data in > the request payload, such as contact information. Ignoring the data from > the request, using the data from the request to update the registered > account, and union-ing the data from the two sources each seem like sane > implementation decisions. This may lead to significant behavioral > differences between server implementations, complicating client > implementation. > > I would propose either: > a) Indicating that the server must discard the information from the > account creation request in this case. > b) Indicating that the server must treat the request as an account update > operation. > > Given that updating the account as a part of the recovery operation could > be perceived as a surprising side effect and given that there is already a > well-defined way to perform an update to an account, I would prefer option > (a). > > Regards, > Zach Shepherd > > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > > --001a11417b08fc8109054b547019 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Zach,

I agree with your assessment. I think addi= ng language specifying that the server not treat the account creation reque= st as an update to the existing account is the best option.

- Daniel=

On Wed, Mar= 22, 2017 at 1:14 AM, Zach Shepherd <shepherdz@vmware.com> wrote:

The following feedback is based on 8010a31 (current HEAD of master).
Section 7.3, Account Creation, states "If the server already has an ac= count registered with the provided account key, then it MUST return a respo= nse with a 200 (OK) status code and provide the URI of that account in the = Location header field. This allows a client that has an account key but not the corresponding account URI to re= cover the account URI."

This section does not specify what the server should do with the data in th= e request payload, such as contact information. Ignoring the data from the = request, using the data from the request to update the registered account, = and union-ing the data from the two sources each seem like sane implementation decisions. This may lead to= significant behavioral differences between server implementations, complic= ating client implementation.

I would propose either:
a) Indicating that the server must discard the information from the account= creation request in this case.
b) Indicating that the server must treat the request as an account update o= peration.

Given that updating the account as a part of the recovery operation could b= e perceived as a surprising side effect and given that there is already a w= ell-defined way to perform an update to an account, I would prefer option (= a).

Regards,
Zach Shepherd


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


--001a11417b08fc8109054b547019-- From nobody Wed Mar 22 09:59:40 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 44026129706 for ; Wed, 22 Mar 2017 09:59:36 -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 e9cDTqw87doT for ; Wed, 22 Mar 2017 09:59:34 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (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 7FDFC129A8C for ; Wed, 22 Mar 2017 09:59:31 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id t189so43703337wmt.1 for ; Wed, 22 Mar 2017 09:59:31 -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=2ozVp3L+WvQG0EQBJNSw9A0UAnnBkC6rhlrKk5QDW4w=; b=eDkjROFNvZsGsfp+4Fmz3ZGoN4lX61V+2OqR0hdfw494kjU5jUBEZ86HqRxE4ZWZf5 VukPHtG1/zLpSDFSmiqkwaRwVj6zs3Hk0TvbakdBhbnbiSNufXe0L/VCd8f/t7W8bCBe JzFMQVB/LAsPcGOrDO1iai9B3z68tEOhb4dtk= 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=2ozVp3L+WvQG0EQBJNSw9A0UAnnBkC6rhlrKk5QDW4w=; b=HG54ND7ezS23DKbo7ucCutDfaPYVL9YD5aYtVXE5cw/LfdnSSqtURjsj3G2HXmTj1f cAhOfkw30zVGvPee7IUonhoRck1+TMBC66etmQoe6WjdQNN81Q1tJVKxzTJHo9u1AfYf EH5MkcRrpvGAjGi9blCJRCTTHOnZ6PILMRXJkt1kZQPXJRUYXMC59L5aXWnTgAHcb+JP AnXr/54hcxuDdwckbLNik0e904Bx8EJYEjWEn4PEc0dhQFnKATBb5GsCkcz8BG4Hxgar N9N3HhzR7TOlg/0VHz7L0EjZXoLmoGZG1Ghzsz9LUGe12h7JooMsLTB4eGQrj0XwS7Kg XYfA== X-Gm-Message-State: AFeK/H2jkTUG04ptYDC4xJ5F5Y/wCizZF7tPJn06J20W7Hq7PNljqrH1trNZdtDV0TqQdHgbRiucXTk9q5+WxGzf X-Received: by 10.25.211.2 with SMTP id k2mr12377346lfg.61.1490201970046; Wed, 22 Mar 2017 09:59:30 -0700 (PDT) MIME-Version: 1.0 Reply-To: cpu@letsencrypt.org Received: by 10.25.21.211 with HTTP; Wed, 22 Mar 2017 09:59:29 -0700 (PDT) In-Reply-To: References: From: Daniel McCarney Date: Wed, 22 Mar 2017 12:59:29 -0400 Message-ID: To: Niklas Keller Cc: IETF ACME , "Salz, Rich" Content-Type: multipart/alternative; boundary=001a11417b08118639054b54af3c Archived-At: Subject: Re: [Acme] Fwd: Inconsistent abbreviations for resource names 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, 22 Mar 2017 16:59:36 -0000 --001a11417b08118639054b54af3c Content-Type: text/plain; charset=UTF-8 Hi Niklas, I've submitted a PR to fix the inconsistencies you found: https://github.com/ietf-wg-acme/acme/pull/282 > 2) There's "new-account", but the account resource is called "acct", I think it should be "account" everywhere. We don't gain anything by saving a few keystrokes / bytes there. The only place I could find the usage of "acct" that wasn't in a URL in example JSON was the Section 7.1 diagram. I think having "acct" in URL returned by the ACME server in examples is fine - the spec calls these resources "accounts" but the server is free to use whatever it chooses for the URL and clients shouldn't make assumptions about the content. On Mon, Mar 13, 2017 at 4:28 PM, Niklas Keller wrote: > I'm resending this message as there were no responses and nothing changed. > > ---------- Forwarded message ---------- > > Morning, > > the current draft contains a few inconsistencies in the resource naming. > > 1) https://ietf-wg-acme.github.io/acme/#rfc.section.6.1 mentions > "revoke-certificate", while it's called "revoke-cert" in the rest of the > document. > > 2) There's "new-account", but the account resource is called "acct", I > think it should be "account" everywhere. We don't gain anything by saving a > few keystrokes / bytes there. > > Maybe we should then also rename "authz" to "authorization" and "cert" to > "certificate" everywhere. > > Regards, Niklas > > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > > --001a11417b08118639054b54af3c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Niklas,

I've submitted a PR to fix the incon= sistencies you found:=C2=A0https://github.com/ietf-wg-acme/acme/pull/282

>=C2= =A02) There's "new-account",= but the account resource is called "acct", I think it should be = "account" everywhere. We don't gain anything by saving a few = keystrokes / bytes there.

The only place I could find the usage of &= quot;acct" that wasn't in a URL in example JSON was the Section 7.= 1 diagram. I think having "acct" in URL returned by the ACME serv= er in examples is fine - the spec calls these resources "accounts"= ; but the server is free to use whatever it chooses for the URL and clients= shouldn't make assumptions about the content.


On Mon, Mar 13, 2017 at 4:28 PM, Niklas Keller = <me@kelunik.com&= gt; wrote:
I= 'm resending this message as there were no responses and nothing change= d.

---------- Fo= rwarded message ----------

Morning,

<= div>the current draft contains a few inconsistencies in the resource naming= .

1)=C2=A0https://ietf-wg-acme.github= .io/acme/#rfc.section.6.1 mentions "revoke-certificate", whil= e it's called "revoke-cert" in the rest of the document.

2) There's "new-account", but the accoun= t resource is called "acct", I think it should be "account&q= uot; everywhere. We don't gain anything by saving a few keystrokes / by= tes there.

Maybe we should then also rename "= authz" to "authorization" and "cert" to "cert= ificate" everywhere.

Regards, Niklas


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


--001a11417b08118639054b54af3c-- From nobody Wed Mar 22 10:01: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 88A2C12422F for ; Wed, 22 Mar 2017 10:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.798 X-Spam-Level: X-Spam-Status: No, score=-9.798 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, RCVD_IN_MSPIKE_H2=-2.796, 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 sZ6LcugZ3CJP for ; Wed, 22 Mar 2017 10:01:40 -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 28056129887 for ; Wed, 22 Mar 2017 10:01:39 -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:To:Subject; bh=wEVqoQr/ZJdK8fwOsx6yvZe7A7bUHBEfHFgT6j2PjwQ=; b=fU0epOjGj1QGY9P6oTLx1z5Y6JfYMwZ/rPYdAvRB93hvUns1gO4WBL1VcwNvur9MxarwHEREUN0P6SRA7TKev0KqYdhviQWgWUo8MdQX58m9OAbpCunHvu/0l31vECTSlU6aLHyG2lTnOjkcJCzyhk8DoyfoDBmQNp/yM3rswTc=; Received: ; Wed, 22 Mar 2017 10:01:40 -0700 To: Niklas Keller , IETF ACME , "Salz, Rich" References: From: Jacob Hoffman-Andrews Message-ID: Date: Wed, 22 Mar 2017 10:01:37 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------5BABB4CD0955CFD9B27CC4DC" Received-SPF: skipped for local relay Archived-At: Subject: Re: [Acme] Fwd: Inconsistent abbreviations for resource names 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, 22 Mar 2017 17:01:47 -0000 This is a multi-part message in MIME format. --------------5BABB4CD0955CFD9B27CC4DC Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Hi Niklas, Sorry for the delay in getting back to you. On 03/13/2017 01:28 PM, Niklas Keller wrote: > 1) https://ietf-wg-acme.github.io/acme/#rfc.section.6.1 > mentions > "revoke-certificate", while it's called "revoke-cert" in the rest of > the document. I created a PR to change this to match the rest of the document: https://github.com/ietf-wg-acme/acme/pull/283. > 2) There's "new-account", but the account resource is called "acct", I > think it should be "account" everywhere. We don't gain anything by > saving a few keystrokes / bytes there. The only thing the protocol specifies is the "new-account" name. In the examples, we show the created resource as /acme/acct/1, but it's up to the ACME server what path to use for those. I don't think it's necessary for this name to match. > Maybe we should then also rename "authz" to "authorization" and "cert" > to "certificate" everywhere. I'm not sure the value here is worth the extra changes to clients (though I could be convinced otherwise). --------------5BABB4CD0955CFD9B27CC4DC Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Niklas,

Sorry for the delay in getting back to you.

On 03/13/2017 01:28 PM, Niklas Keller wrote:
1) https://ietf-wg-acme.github.io/acme/#rfc.section.6.1 mentions "revoke-certificate", while it's called "revoke-cert" in the rest of the document.
I created a PR to change this to match the rest of the document: https://github.com/ietf-wg-acme/acme/pull/283.

2) There's "new-account", but the account resource is called "acct", I think it should be "account" everywhere. We don't gain anything by saving a few keystrokes / bytes there.
The only thing the protocol specifies is the "new-account" name. In the examples, we show the created resource as /acme/acct/1, but it's up to the ACME server what path to use for those. I don't think it's necessary for this name to match.
Maybe we should then also rename "authz" to "authorization" and "cert" to "certificate" everywhere.
I'm not sure the value here is worth the extra changes to clients (though I could be convinced otherwise).
--------------5BABB4CD0955CFD9B27CC4DC-- From nobody Wed Mar 22 10:13:58 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 A3A4F129B45 for ; Wed, 22 Mar 2017 10:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.798 X-Spam-Level: X-Spam-Status: No, score=-9.798 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, RCVD_IN_MSPIKE_H2=-2.796, 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 LgPSAuec_901 for ; Wed, 22 Mar 2017 10:13:54 -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 56E55129A96 for ; Wed, 22 Mar 2017 10:13:52 -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:Cc:References:To:Subject; bh=67jZ61teKu5vfAfDvgNXUdzLaGsIy4Y21445a5fd3qI=; b=bkUNAPYJ43tasFzoL5TpjGtElvv9MW4G+TX0JAG2YGGsebCTbugWByCdhSgH5U5KeUALGpEihBXDlnvIKEPWvfSG3HuewtaSmIvwAz8IalRTEYxP+kuHDxQiVvCCwzf693h1iaoo3AIORX6/FYJq0T2G390UbcfOaJiFT4gcUU0=; Received: ; Wed, 22 Mar 2017 10:13:54 -0700 To: cpu@letsencrypt.org, Zach Shepherd References: Cc: "acme@ietf.org" From: Jacob Hoffman-Andrews Message-ID: Date: Wed, 22 Mar 2017 10:13:51 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------A1B39B18E118FF66101B7795" Received-SPF: skipped for local relay Archived-At: Subject: Re: [Acme] Use of "shortly" in normative language of Section 7.4, Applying for Certificate 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: Wed, 22 Mar 2017 17:13:57 -0000 This is a multi-part message in MIME format. --------------A1B39B18E118FF66101B7795 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit We could say "MUST begin the issuance process" The main things on my mind that could delay issuance slightly: - Submitting to CT - Checking CAA - Internal queuing for available capacity - Manual vetting I think "MUST begin" covers for all of those, while allowing some vagueness as to how long they will take. On 03/22/2017 09:39 AM, Daniel McCarney wrote: > Hi Zach, > > For background I think this MUST originated out of this > thread: https://mailarchive.ietf.org/arch/msg/acme/0lVmGl8e-rmSH0x7ycDW5dj6GAY > > I would prefer option A) as well. It seems better to clear up the > non-normative language than to step backwards to a place where > proactive issuance may or may not happen without a clear signalling to > the client of which a server will do. > > I think the use of "shortly" here is to allow the server some grace to > determine that the order is completed and issuance can be performed. > Perhaps we could change the language to say "The server MUST issue the > requested certificate and update the order resource with a URL for the > certificate after it has determined the client has fulfilled the > server's requirements" and not impose any specific mention of the time > between the client completing the challenges and the server noticing. > Thoughts? > > On Wed, Mar 22, 2017 at 1:14 AM, Zach Shepherd > wrote: > > The following feedback is based on 8010a31 (current HEAD of master). > > Section 7.4, Applying for Certificate Issuance, states "The server > MUST issue the requested certificate and update the order resource > with a URL for the certificate shortly after the client has > fulfilled the server’s requirements." > > Per RFC 2119 Section 6, the imperative MUST should be used with > care and sparingly. > > The use of "shortly" in the above sentence is imprecise. It is not > possible for a server author to know, with confidence, that they > are adhering to this requirement. It is not possible fore a client > author to make design or implementation decisions based on this > requirement. > > I would propose either: > a) Replacing "shortly" with a more precise expectation. > b) Replacing "MUST" with "should". > > I believe there are advantages for setting expectations as to the > turn-around time for certificate issuance and would therefore > prefer option (a), assuming agreement could be reached on more > precise language. > > Regards, > Zach Shepherd > > _______________________________________________ > 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 --------------A1B39B18E118FF66101B7795 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit We could say "MUST begin the issuance process"

The main things on my mind that could delay issuance slightly:
 - Submitting to CT
 - Checking CAA
 - Internal queuing for available capacity
 - Manual vetting

I think "MUST begin" covers for all of those, while allowing some vagueness as to how long they will take.

On 03/22/2017 09:39 AM, Daniel McCarney wrote:
Hi Zach,

For background I think this MUST originated out of this thread: https://mailarchive.ietf.org/arch/msg/acme/0lVmGl8e-rmSH0x7ycDW5dj6GAY 

I would prefer option A) as well. It seems better to clear up the non-normative language than to step backwards to a place where proactive issuance may or may not happen without a clear signalling to the client of which a server will do.

I think the use of "shortly" here is to allow the server some grace to determine that the order is completed and issuance can be performed.
Perhaps we could change the language to say "The server MUST issue the requested certificate and update the order resource with a URL for the certificate after it has determined the client has fulfilled the server's requirements" and not impose any specific mention of the time between the client completing the challenges and the server noticing. Thoughts?

On Wed, Mar 22, 2017 at 1:14 AM, Zach Shepherd <shepherdz@vmware.com> wrote:
The following feedback is based on 8010a31 (current HEAD of master).

Section 7.4, Applying for Certificate Issuance, states "The server MUST issue the requested certificate and update the order resource with a URL for the certificate shortly after the client has fulfilled the server’s requirements."

Per RFC 2119 Section 6, the imperative MUST should be used with care and sparingly.

The use of "shortly" in the above sentence is imprecise. It is not possible for a server author to know, with confidence, that they are adhering to this requirement. It is not possible fore a client author to make design or implementation decisions based on this requirement.

I would propose either:
a) Replacing "shortly" with a more precise expectation.
b) Replacing "MUST" with "should".

I believe there are advantages for setting expectations as to the turn-around time for certificate issuance and would therefore prefer option (a), assuming agreement could be reached on more precise language.

Regards,
Zach Shepherd

_______________________________________________
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

--------------A1B39B18E118FF66101B7795-- From nobody Wed Mar 22 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 05047129B21 for ; Wed, 22 Mar 2017 10:17:04 -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, 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 T2RyUpr8HOb3 for ; Wed, 22 Mar 2017 10:17:01 -0700 (PDT) Received: from mail.hemio.de (mail.hemio.de [144.76.93.186]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 647B4127011 for ; Wed, 22 Mar 2017 10:17:01 -0700 (PDT) Received: from user.client.invalid (localhost [144.76.93.186]) by mail.hemio.de (Postfix) with ESMTPSA id D45AF72; Wed, 22 Mar 2017 18:16:59 +0100 (CET) To: cpu@letsencrypt.org, IETF ACME References: <96d31ef7-0dda-019c-4072-165fcd57e34f@hemio.de> From: Sophie Herold Message-ID: <90bff3df-297d-3cfc-8526-4f92a56c4a22@hemio.de> Date: Wed, 22 Mar 2017 18:16:59 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Acme] Missing structure and unspecified parts in "Account Creation" 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, 22 Mar 2017 17:17:04 -0000 Hi Daniel, I thought that there shouldn't be extra complexity arising from my PR, because a "stub account object" contains a "contact" field anyways. Hence, a server implementation should check if it is contained in the payload. I think I was implicitly reading a MUST for the "contact" field which is not there (yet). On 22/03/17 17:35, Daniel McCarney wrote: > Thanks for following up on your initial message with PR's Sophie. > > For PR 281 I left a small comment but otherwise LGTM. > > For PR 280 - I think the proposed changes are great with the exception of > one question I have RE: the mechanism to differentiate the account URI > recovery POSTs from account creation POSTs. > Do you think it would be clearer to separate the account URI recovery to a > new endpoint? > It seems like the empty JWS payload approach would work, but we're adding > more complexity to the account creation endpoint to allow it to double as > the account URI recovery endpoint. Maybe it's time to separate it properly. > What does the list think? > > On Mon, Mar 20, 2017 at 4:50 AM, Sophie Herold > wrote: > >> PR for 1.-3. >> >> >> PR for 4. >> >> >> Issue related to 4. >> >> >> On 20/02/17 16:17, Sophie Herold wrote: >>> 1. >>> I cannot find where the response to account updates is specified. >>> >>> Boulder replies with "202 Accepted" and an account object. Since >>> updates with trivial payload should be used for account information, >>> it seems to be expected that an account object is returned. The >>> specified response status for "Account deactivation" is "200 OK". >>> It would be consistent to specify the same response status for >>> account updates I guess? >>> >>> 2. >>> The client should be able to choose between "Account URI recovery" >>> and "Account Creation", if needed. A possible way would be to clarify >>> that account creations with trivial payload MUST be rejected. However, >>> if an account exists, the "Content-Location" header and "200 OK" is >>> returned, independent of the payloads content. Therefore a trivial >>> payload could be used to check if an account with the used key exists, >>> without creating it. >>> >>> 3. >>> As "6.3.4. Account deactivation", other queries should get their own >>> sub-sub sections. Something like >>> - "6.3.x Account URI recovery" ("new-account", maybe trivial payload) >>> - "6.3.x Account update" >>> - "6.3.x Account information" (update with trivial payload) >>> >>> 4. >>> Is it really an account URI or rather an account URL? Some fields >>> changed from "uri" to "url". I guess, all occurrences of URIs should >>> be URLs. The only exception that I see is the "type" field in the >>> "Problem Details" responses. >>> >> >> _______________________________________________ >> 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 Mar 22 10:30: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 BBB1F129B2A for ; Wed, 22 Mar 2017 10:30:16 -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 n-VBcZpir3Ww for ; Wed, 22 Mar 2017 10:30:14 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::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 6A1D11294E6 for ; Wed, 22 Mar 2017 10:30:13 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id n11so44222865wma.0 for ; Wed, 22 Mar 2017 10:30: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=2X6B/zeX/MUqCJrahy1qyIRXc3x4fmFwvDUFCvDy8hk=; b=CPOnlw44fUDawOssygvy3FAb1rvz56EmfECP79iHiyW6f/XOe5WqnYzxGhGAix8EVB WAkOIBM5I7NKm21CuXcQsyraO07Je5sPn375QMb9d13fKuOp9Cklo2x/padvgX+u9Sdw CTJDE1yqvRyDA6bVWRILDgZzOWbIWw6eKHYA4= 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=2X6B/zeX/MUqCJrahy1qyIRXc3x4fmFwvDUFCvDy8hk=; b=caMyXLy7Q6BDJPWgvFyJFUQ/rqYYdA0d8vZa9NPPuyRIHofGJxL6rc7rBaKA9rtb7i Lk35UzSThrPzLMoJfiEVqRtQ1y04158I7zQgFxAlbc09QoNbljdFpjf5wo3Isqrg2jA9 j19RVqKR8HwlC5UV17sjAKvQYEmFp7RjExB1Q3I047VV2kq8uyGg/smtJRfbZjhqWROx Gx91HFYKdOWKL8NHIEvFqUN1mBXCF+k+UZBqyxvFa7nn96/aqNaVFMfNbl084k6wyxy4 4UEQnWqaPUbPXX+k/LPNiBrqZaajyWn38N/t/ocXG2bZU/HXbmmNCrcI75bDNzX5p5bV sCSg== X-Gm-Message-State: AFeK/H2zncWvcKXDlS85gRLFUI7McKL5uIIm3EbZlVwwfg43VKym74tlmmY7XWzZ+q5qhyEmScO04kW8HHBzfPGs X-Received: by 10.25.211.2 with SMTP id k2mr12443032lfg.61.1490203811793; Wed, 22 Mar 2017 10:30:11 -0700 (PDT) MIME-Version: 1.0 Reply-To: cpu@letsencrypt.org Received: by 10.25.21.211 with HTTP; Wed, 22 Mar 2017 10:30:11 -0700 (PDT) In-Reply-To: References: From: Daniel McCarney Date: Wed, 22 Mar 2017 13:30:11 -0400 Message-ID: To: Zach Shepherd Cc: "acme@ietf.org" Content-Type: multipart/alternative; boundary=001a11417b08d85b71054b551cc8 Archived-At: Subject: Re: [Acme] Entropy requirement for challenge token 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, 22 Mar 2017 17:30:17 -0000 --001a11417b08d85b71054b551cc8 Content-Type: text/plain; charset=UTF-8 Hi Zach, > This seems incongruous. If the token must be kept secret an attacker, it > should not be served via an unauthenticated channel. I agree the wording makes it incongruous, I was caught up on this the other week until it was clarified for me by Jacob. The token is random not to prevent a guessing attack but to prevent the implementation of a server that can automatically reply to challenges without being a party to the authorization creation (e.g. knowing the token). It's OK for the token to be served via an unauthenticated channel, it just can't be predictable. I took a crack at rewording this in https://github.com/ietf-wg-acme/acme/pull/284 - Hopefully if I'm completely off-base someone can correct it to be accurate & understandable. On Wed, Mar 22, 2017 at 1:12 AM, Zach Shepherd wrote: > The following feedback is based on 8010a31 (current HEAD of master). > > Section 6.2, Request Authentication, states "Note that authentication via > signed JWS request bodies implies that GET requests are not authenticated. > Servers MUST NOT respond to GET requests for resources that might be > considered sensitive. Account resources are the only sensitive resources > defined in this specification." > > Sections 8.2, HTTP; 8.3, TLS with Server Name Indication (TLS SNI); and > 8.4, DNS, each describe a GET request and specify a "token" value which > "MUST have at least 128 bits of entropy, in order to prevent an attacker > from guessing it." > > This seems incongruous. If the token must be kept secret an attacker, it > should not be served via an unauthenticated channel. > > Assuming secrecy of the token is not important, I would propose removing > the entropy requirement and including some discussion of the token in > Section 10, Security Considerations. > > Regards, > Zach Shepherd > > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > > --001a11417b08d85b71054b551cc8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Zach,

> This seems incongruous. If the token must be kept secret an at= tacker, it should not be served via an unauthenticated channel.

I agree the wording makes it incongruous, I was caught up on this= the other week until it was clarified for me by Jacob.

The token i= s random not to prevent a guessing attack but to prevent the implementation= of a server that can automatically reply to challenges without being a par= ty to the authorization creation (e.g. knowing the token). It's OK for = the token to be served via an unauthenticated channel, it just can't be= predictable.

I took a crack at rewording this in=C2=A0https://github.com/ietf-wg-acm= e/acme/pull/284 - Hopefully if I'm completely off-base someone can = correct it to be accurate & understandable.

On Wed, Mar 22, 2017 at 1:12 AM, = Zach Shepherd <shepherdz@vmware.com> wrote:

The following feedback is based on 8010a31 (current HEAD of master).
Section 6.2, Request Authentication, states "Note that authentication = via signed JWS request bodies implies that GET requests are not authenticat= ed. Servers MUST NOT respond to GET requests for resources that might be co= nsidered sensitive. Account resources are the only sensitive resources defined in this specification."

Sections 8.2, HTTP; 8.3, TLS with Server Name Indication (TLS SNI); and 8.4= , DNS, each describe a GET request and specify a "token" value wh= ich "MUST have at least 128 bits of entropy, in order to prevent an at= tacker from guessing it."

This seems incongruous. If the token must be kept secret an attacker, it sh= ould not be served via an unauthenticated channel.

Assuming secrecy of the token is not important, I would propose removing th= e entropy requirement and including some discussion of the token in Section= 10, Security Considerations.

Regards,
Zach Shepherd


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


--001a11417b08d85b71054b551cc8-- From nobody Wed Mar 22 10:31: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 88711129B7A for ; Wed, 22 Mar 2017 10:31:28 -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 z2J5PzQiLydq for ; Wed, 22 Mar 2017 10:31:26 -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 69211129B56 for ; Wed, 22 Mar 2017 10:31:26 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id n11so44253005wma.0 for ; Wed, 22 Mar 2017 10:31:26 -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=gdtl+SSuwceca4AVZXZCgeQacWkYOdOzGEnstdNtSoY=; b=ST0A8dldDfelFdGDQCtux8dCUGNsPTNG6i2UkDfxybRLQ9QSBOyU0ICe+E8GGpPldx Kv1z7kf7md5F0Cjoo1OA0cF4ra4xz54SBOgAjL+6jUXphTN5lB6i17Eu2yZS8vumovWz gVsx/WoeP0knyarv9KyCWAe1O0QwRxz7HEhMI= 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=gdtl+SSuwceca4AVZXZCgeQacWkYOdOzGEnstdNtSoY=; b=Dc+5+tX47OsbP/SkZt4Px8p5gflTUMpS9uocjpS4qiuPoFjuc6XV0jr0FGmn4caeBB NwW///Gm0QQPXpbccyZLKrdip3MvI9gV/6ODmcoseW1NCtJknt4k2C5arPjdCwXgQqNM c9tFAlf4RqkFN0nV/NqFFsuRwSCGf3T3UYIuNG4m0wXfmwzzshvcX/vsznDmW7hvGnir ydqyxRoAiBVMuA4r+RqXlZkMFDLmznuvW/kzD8u4qstAZFvjJkBlgo23cBlIUUFWpOLc Dn3a+8fQ+JNsmInNe0Pr/DS5vogt3k3h7rRiHGHiQD03TmN+/UPGlIlEv4Jsd7NNVM3Y e+yg== X-Gm-Message-State: AFeK/H1NAmrJxCSTV/TIlRDAKOCrBET/CU3f2TeHBpnP6tzPpz262DENtcK1RIZwEAR6b++zzY+n1V6gvXbHoa6+ X-Received: by 10.25.93.86 with SMTP id p22mr11865763lfj.9.1490203884971; Wed, 22 Mar 2017 10:31:24 -0700 (PDT) MIME-Version: 1.0 Reply-To: cpu@letsencrypt.org Received: by 10.25.21.211 with HTTP; Wed, 22 Mar 2017 10:31:24 -0700 (PDT) In-Reply-To: References: From: Daniel McCarney Date: Wed, 22 Mar 2017 13:31:24 -0400 Message-ID: To: Jacob Hoffman-Andrews Cc: Niklas Keller , IETF ACME , "Salz, Rich" Content-Type: multipart/alternative; boundary=f403045e315e34ff99054b552175 Archived-At: Subject: Re: [Acme] Fwd: Inconsistent abbreviations for resource names 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, 22 Mar 2017 17:31:29 -0000 --f403045e315e34ff99054b552175 Content-Type: text/plain; charset=UTF-8 Oops! RFC editing is not thread safe and Jacob and I have encountered a data race. One of our PRs can be closed. I'm not particular about which :-) On Wed, Mar 22, 2017 at 1:01 PM, Jacob Hoffman-Andrews wrote: > Hi Niklas, > > Sorry for the delay in getting back to you. > > On 03/13/2017 01:28 PM, Niklas Keller wrote: > > 1) https://ietf-wg-acme.github.io/acme/#rfc.section.6.1 mentions > "revoke-certificate", while it's called "revoke-cert" in the rest of the > document. > > I created a PR to change this to match the rest of the document: > https://github.com/ietf-wg-acme/acme/pull/283. > > 2) There's "new-account", but the account resource is called "acct", I > think it should be "account" everywhere. We don't gain anything by saving a > few keystrokes / bytes there. > > The only thing the protocol specifies is the "new-account" name. In the > examples, we show the created resource as /acme/acct/1, but it's up to the > ACME server what path to use for those. I don't think it's necessary for > this name to match. > > Maybe we should then also rename "authz" to "authorization" and "cert" to > "certificate" everywhere. > > I'm not sure the value here is worth the extra changes to clients (though > I could be convinced otherwise). > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > > --f403045e315e34ff99054b552175 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Oops! RFC editing is not thread safe and Jacob and I have = encountered a data race.

One of our PRs can be closed. I'm not p= articular about which :-)

On Wed, Mar 22, 2017 at 1:01 PM, Jacob Hoffman-Andrews <jsha@eff.= org> wrote:
=20 =20 =20
Hi Niklas,

Sorry for the delay in getting back to you.

On 03/13/2017 01:2= 8 PM, Niklas Keller wrote:
1)=C2=A0https://ietf-wg-acme.github.io/= acme/#rfc.section.6.1 mentions "revoke-certificate", while it's called &quo= t;revoke-cert" in the rest of the document.
 I created a PR to change this to match the rest of the document: https://github.c= om/ietf-wg-acme/acme/pull/283.

2) There's "new-account", but the account re= source is called "acct", I think it should be "account&q= uot; everywhere. We don't gain anything by saving a few keystrokes / bytes there.
 The only thing the protocol specifies is the "new-account" na= me. In the examples, we show the created resource as /acme/acct/1, but it'= s up to the ACME server what path to use for those. I don't think it&= #39;s necessary for this name to match.
Maybe we should then also rename "authz" to "authorization" and "cert" to "certi= ficate" everywhere.
 I'm not sure the value here is worth the extra changes to clients (though I could be convinced otherwise).

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


--f403045e315e34ff99054b552175-- From nobody Wed Mar 22 10:43: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 43484129BC5 for ; Wed, 22 Mar 2017 10:43:14 -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 XciFp3cEgLd8 for ; Wed, 22 Mar 2017 10:43: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 3A0E5129BAF for ; Wed, 22 Mar 2017 10:43:09 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id t189so44781517wmt.1 for ; Wed, 22 Mar 2017 10:43:09 -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=dx5KiCsOdtPJHI2rwks3KqdftzMFdjrblI0wgZqtMds=; b=KOel516NoodC05qCmwJsxbwH3JWhfEwTB0ndA15ZQutJFy9od8WTE2R9O/3+fEL6zJ FVn9lxyQOo+MZ+tDIAb1QQUKgShQfuwtJzTQr1+k1oPnGAOq+9i23mFLzp4dQmHpFnut pkIlvcDXvsS7ylFI2PflXtM1dkgiQnEeQdMZk= 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=dx5KiCsOdtPJHI2rwks3KqdftzMFdjrblI0wgZqtMds=; b=MLa/tQrq9+5KZvTyQ5so2RFd3npzWovcXUZfg6WSGUGTl1ef4X2gxeO4stK3kc7LpW 1lvw5iFHCf/yRX0Ql4T+80RzpydEk7eEkSVPCLuj7XaDteIKWdCyi70YfAe80V5vLL1p MAg3tf0LOb4qh9XWXJ04SsTZdUUcCfFIqDgiHNox3yWtAbaQXOTqfTQnFW8dENLa4tPg 9R6DR0h9hQYSUnqIdzWymozvkxcrkiz0gLdwSjA5fE36uC8bXpD9O6TlOHtj4oNsnCsy zYwGNZPG5KFbFy0UsQkxHvbFMfC1vmtvXRiKd4JQNPmIXmkx0ZCbs8UsxxuRK8sEMmrb D6Ig== X-Gm-Message-State: AFeK/H09UNdZgf8b4QQLHf7tJIvTZC/rhr3Pnmkcr1+t/4oUyngMRXp7TiN9hZqz3l7cgRmgJcU7+gBxxfFbydHs X-Received: by 10.25.156.206 with SMTP id f197mr12344740lfe.77.1490204587760; Wed, 22 Mar 2017 10:43:07 -0700 (PDT) MIME-Version: 1.0 Reply-To: cpu@letsencrypt.org Received: by 10.25.21.211 with HTTP; Wed, 22 Mar 2017 10:43:07 -0700 (PDT) In-Reply-To: References: From: Daniel McCarney Date: Wed, 22 Mar 2017 13:43:07 -0400 Message-ID: To: Zach Shepherd Cc: "acme@ietf.org" Content-Type: multipart/alternative; boundary=001a114032a818b644054b554b2c Archived-At: Subject: Re: [Acme] Allowing clients to understand the account creation functionality supported by a server 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, 22 Mar 2017 17:43:14 -0000 --001a114032a818b644054b554b2c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Zach, > It is undesirable that a client can only determine the supported schemes for contact URLs by attempting to submit an unsupported URL. This makes it difficult to implement a general-purpose client which can work with a variety of servers which might each support a different set of contact schemes. I feel your pain, but I'm hesitant to see more metadata/complexity put into the /directory (I think the "meta" field of the directory resource would be the best place if anywhere). My gut says it will be unlikely many servers will allow contact URLs outside of "mailto:" and "tel:" and it seems reasonably easy to handle the unsupported contact type error. For the account fields we'd be adding complexity to simplify UI and I'm not convinced yet its justified. Another note: If consensus is that we need a machine-readable way for clients to know ahead of time what contact methods & account fields a server supports we should also give the same consideration to identifier types for Section 7.4.1's Pre-Authorization mechanism. A client may want to know what types of identifiers a server would pre-authorize. On Wed, Mar 22, 2017 at 1:13 AM, Zach Shepherd wrote= : > The following feedback is based on 8010a31 (current HEAD of master). > > Section 7.3, Account Creation, states "The server SHOULD validate that th= e > contact URLs in the =E2=80=9Ccontact=E2=80=9D field are valid and support= ed by the server. > If the client provides the server with an invalid or unsupported contact > URL, then the server MUST return an error of type =E2=80=9CinvalidContact= =E2=80=9D, with a > description describing the error and what types of contact URL the server > considers acceptable." > > It is undesirable that a client can only determine the supported schemes > for contact URLs by attempting to submit an unsupported URL. This makes i= t > difficult to implement a general-purpose client which can work with a > variety of servers which might each support a different set of contact > schemes. > > I would propose including information about the supported contact schemes > in a machine readable format as a part of some GET request. > > > Section 7.3, Account Creation, also states "A client creates a new accoun= t > with the server by sending a POST request to the server=E2=80=99s new-acc= ount URI. > The body of the request is a stub account object containing the =E2=80=9C= contact=E2=80=9D > field and optionally the =E2=80=9Cterms-of-service-agreed=E2=80=9D field.= ... The server > MUST ignore any values provided in the =E2=80=9Corders=E2=80=9D fields in= account bodies > sent by the client, as well as any other fields that it does not recogniz= e. > If new fields are specified in the future, the specification of those > fields MUST describe whether they can be provided by the client." > > Similarly, it would be beneficial for a client to be able to determine th= e > set of fields that a server does recognize so that it does not prompt the > user for information which the server will not make use of. > > I would propose including information about the fields which may be > specified as a part of account creation in a machine readable format as a > part of some GET request. > > > Together, these proposals could be addressed by responding to GET request= s > on the server's new-account URI with an object describing the > client-specifiable account creation fields and applicable restrictions on > each, such as the supported schemes for contacts URLs. > > Regards, > Zach Shepherd > > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > > --001a114032a818b644054b554b2c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Zach,

> It is undesirable that a client can o= nly determine the supported schemes for contact URLs by attempting to submi= t an unsupported URL. This makes it difficult to implement a general-purpos= e client which can work with a variety of servers which might each support = a different set of contact schemes.

I feel your pain, but I'm he= sitant to see more metadata/complexity put into the /directory (I think the= "meta" field of the directory resource would be the best place i= f anywhere).=C2=A0My gut says it will be unlikely many servers will allow c= ontact URLs outside of "mailto:" and "tel:" and it seem= s reasonably easy to handle the unsupported contact type error. For the acc= ount fields we'd be adding complexity to simplify UI and I'm not co= nvinced yet its justified.

Another note: If consensus is that we nee= d a machine-readable way for clients to know ahead of time what contact met= hods & account fields a server supports we should also give the same co= nsideration to identifier types for Section 7.4.1's Pre-Authorization m= echanism. A client may want to know what types of identifiers a server woul= d pre-authorize.

On Wed, Mar 22, 2017 at 1:13 AM, Zach Shepherd &= lt;shepherdz@vmwa= re.com> wrote:

The following feedback is based on 8010a31 (current HEAD of master).
Section 7.3, Account Creation, states "The server SHOULD validate that= the contact URLs in the =E2=80=9Ccontact=E2=80=9D field are valid and supp= orted by the server. If the client provides the server with an invalid or u= nsupported contact URL, then the server MUST return an error of type =E2=80=9CinvalidContact=E2=80=9D, with a description describ= ing the error and what types of contact URL the server considers acceptable= ."

It is undesirable that a client can only determine the supported schemes fo= r contact URLs by attempting to submit an unsupported URL. This makes it di= fficult to implement a general-purpose client which can work with a variety= of servers which might each support a different set of contact schemes.

I would propose including information about the supported contact schemes i= n a machine readable format as a part of some GET request.


Section 7.3, Account Creation, also states "A client creates a new acc= ount with the server by sending a POST request to the server=E2=80=99s new-= account URI. The body of the request is a stub account object containing th= e =E2=80=9Ccontact=E2=80=9D field and optionally the =E2=80=9Cterms-of-serv= ice-agreed=E2=80=9D field. ... The server MUST ignore any values provided in the =E2=80=9Corde= rs=E2=80=9D fields in account bodies sent by the client, as well as any oth= er fields that it does not recognize. If new fields are specified in the fu= ture, the specification of those fields MUST describe whether they can be provided by the client."

Similarly, it would be beneficial for a client to be able to determine the = set of fields that a server does recognize so that it does not prompt the u= ser for information which the server will not make use of.

I would propose including information about the fields which may be specifi= ed as a part of account creation in a machine readable format as a part of = some GET request.


Together, these proposals could be addressed by responding to GET requests = on the server's new-account URI with an object describing the client-sp= ecifiable account creation fields and applicable restrictions on each, such= as the supported schemes for contacts URLs.

Regards,
Zach Shepherd


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


--001a114032a818b644054b554b2c-- From nobody Wed Mar 22 11:44:52 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 76F2B1294FD for ; Wed, 22 Mar 2017 11:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.068 X-Spam-Level: X-Spam-Status: No, score=0.068 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=onevmw.onmicrosoft.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 HBCn_Zw7fx-4 for ; Wed, 22 Mar 2017 11:44:45 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0067.outbound.protection.outlook.com [104.47.34.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 164C21294E1 for ; Wed, 22 Mar 2017 11:44:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onevmw.onmicrosoft.com; s=selector1-vmware-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jfg5zazbCq22kQPRZrHzcK2oqIZjDqCSd0vzd7MUwCI=; b=BLR4GpnuK95hQVYKaOrXAhiBG4pVX+igx/izl29aP5FNpj0ZcU3Fkwuvm0TTPknBnlZMTIxncTHoUMBCpA13qwcdVeteDXT3SOLaZu5wzE6wuJ8Xw85k9Lt3y5kTF5rTF8oIu5wlQA8Fvr9KYyCUrkpJR9DnEvv3RZjcjqhw2bg= Received: from CY4PR05MB3045.namprd05.prod.outlook.com (10.172.155.135) by CY4PR05MB3046.namprd05.prod.outlook.com (10.172.155.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4; Wed, 22 Mar 2017 18:44:44 +0000 Received: from CY4PR05MB3045.namprd05.prod.outlook.com ([10.172.155.135]) by CY4PR05MB3045.namprd05.prod.outlook.com ([10.172.155.135]) with mapi id 15.01.0991.013; Wed, 22 Mar 2017 18:44:44 +0000 From: Zach Shepherd To: Jacob Hoffman-Andrews , "cpu@letsencrypt.org" CC: "acme@ietf.org" Thread-Topic: [Acme] Use of "shortly" in normative language of Section 7.4, Applying for Certificate Issuance Thread-Index: AQHSossyXOSrxuUNyk6P1Tz/VfaYiaGhECEAgAAJooCAABeJIw== Date: Wed, 22 Mar 2017 18:44:44 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=vmware.com; x-originating-ip: [208.90.213.162] x-microsoft-exchange-diagnostics: 1; CY4PR05MB3046; 7:fk4pfSOWE1HQDIcN2nBRsPIh4FOCd84h7bg5Twgnd2obUfMy26cf/rjuyQenkRhhnULySvQgg4CRfhWoBBuaJcyNOwIY7Ml8gZXSqy6KmNLHsLcHPn9FU5ImThgqXoIEu6qBkqb2tblGl6ImdjUScc6e7G0q+2sW+GUdhNK8jXs7Fstc/HoBzxw2HzYbmLXFrVx0TaQNmL8UKv1IEmnWrU0AITvjWlcNmETy2ztsKGaTkw+x8iW+sAM8+GQfF4pZG6sdQBhDaWneB4WZ1cnOn9A6I7nIIPAOAztQj96j/nLEdEgs9JfJUvODAZUsN3jxGxGx+cTh+l5K1EGElrX3ZA==; 20:enHsaxQ+ax2uxUzGL7IksRMzxFsW4ufAI1/UfWy3/eEQNopsxAVaPSsNF64MIdtjmKF1PCH648BTtSBGNOVfXpSzBFGiBhMdSnvk12xEHqhognAIo6HM6iwdIMuTs4Dv0Ilj3JBNRSrxov1IpJAbzifJM0LOssG6MlG82nBwRVQ= x-ms-office365-filtering-correlation-id: 95cb14af-83db-48b6-2772-08d4715381ff x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075); SRVR:CY4PR05MB3046; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(61668805478150)(158342451672863)(10436049006162); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123564025)(20161123555025)(20161123558025)(20161123560025)(20161123562025)(6072148); SRVR:CY4PR05MB3046; BCL:0; PCL:0; RULEID:; SRVR:CY4PR05MB3046; x-forefront-prvs: 02543CD7CD x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39450400003)(39830400002)(39410400002)(377454003)(24454002)(38730400002)(54356999)(4326008)(6246003)(66066001)(2501003)(76176999)(50986999)(2950100002)(6606003)(3280700002)(8936002)(3660700001)(7696004)(5660300001)(2906002)(7736002)(74316002)(19627405001)(7906003)(81166006)(606005)(8676002)(53546009)(6506006)(229853002)(102836003)(6116002)(6436002)(9686003)(3846002)(77096006)(189998001)(33656002)(6306002)(236005)(54896002)(25786009)(86362001)(122556002)(575784001)(53936002)(55016002)(99286003); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR05MB3046; H:CY4PR05MB3045.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR05MB30454E2F1697CED075A5D2D8C03C0CY4PR05MB3045namp_" MIME-Version: 1.0 X-OriginatorOrg: vmware.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2017 18:44:44.1087 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR05MB3046 Archived-At: Subject: Re: [Acme] Use of "shortly" in normative language of Section 7.4, Applying for Certificate 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: Wed, 22 Mar 2017 18:44:48 -0000 --_000_CY4PR05MB30454E2F1697CED075A5D2D8C03C0CY4PR05MB3045namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I think "MUST begin the issuance process" addresses my concerns and is in l= ine with the discussions around preferring "proactive" issuance. ________________________________ From: Jacob Hoffman-Andrews Sent: Wednesday, March 22, 2017 10:13 AM To: cpu@letsencrypt.org; Zach Shepherd Cc: acme@ietf.org Subject: Re: [Acme] Use of "shortly" in normative language of Section 7.4, = Applying for Certificate Issuance We could say "MUST begin the issuance process" The main things on my mind that could delay issuance slightly: - Submitting to CT - Checking CAA - Internal queuing for available capacity - Manual vetting I think "MUST begin" covers for all of those, while allowing some vagueness= as to how long they will take. On 03/22/2017 09:39 AM, Daniel McCarney wrote: Hi Zach, For background I think this MUST originated out of this thread: https://mai= larchive.ietf.org/arch/msg/acme/0lVmGl8e-rmSH0x7ycDW5dj6GAY I would prefer option A) as well. It seems better to clear up the non-norma= tive language than to step backwards to a place where proactive issuance ma= y or may not happen without a clear signalling to the client of which a ser= ver will do. I think the use of "shortly" here is to allow the server some grace to dete= rmine that the order is completed and issuance can be performed. Perhaps we could change the language to say "The server MUST issue the requ= ested certificate and update the order resource with a URL for the certific= ate after it has determined the client has fulfilled the server's requireme= nts" and not impose any specific mention of the time between the client com= pleting the challenges and the server noticing. Thoughts? On Wed, Mar 22, 2017 at 1:14 AM, Zach Shepherd > wrote: The following feedback is based on 8010a31 (current HEAD of master). Section 7.4, Applying for Certificate Issuance, states "The server MUST iss= ue the requested certificate and update the order resource with a URL for t= he certificate shortly after the client has fulfilled the server=92s requir= ements." Per RFC 2119 Section 6, the imperative MUST should be used with care and sp= aringly. The use of "shortly" in the above sentence is imprecise. It is not possible= for a server author to know, with confidence, that they are adhering to th= is requirement. It is not possible fore a client author to make design or i= mplementation decisions based on this requirement. I would propose either: a) Replacing "shortly" with a more precise expectation. b) Replacing "MUST" with "should". I believe there are advantages for setting expectations as to the turn-arou= nd time for certificate issuance and would therefore prefer option (a), ass= uming agreement could be reached on more precise language. Regards, Zach Shepherd _______________________________________________ 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 --_000_CY4PR05MB30454E2F1697CED075A5D2D8C03C0CY4PR05MB3045namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

I think "MUST begin the issuance process" addresses my concern= s and is in line with the discussions around preferring "proactiv= e" issuance.


From: Jacob Hoffman-Andre= ws <jsha@eff.org>
Sent: Wednesday, March 22, 2017 10:13 AM
To: cpu@letsencrypt.org; Zach Shepherd
Cc: acme@ietf.org
Subject: Re: [Acme] Use of "shortly" in normative language= of Section 7.4, Applying for Certificate Issuance
 
We could say "MUST begin the issuance process"

The main things on my mind that could delay issuance slightly:
 - Submitting to CT
 - Checking CAA
 - Internal queuing for available capacity
 - Manual vetting

I think "MUST begin" covers for all of those, while allowing some= vagueness as to how long they will take.

On 03/22/2017 09:39 AM, Daniel McCarney wrot= e:
Hi Zach,

For background I think this MUST originated out of this thread: https://mailarchive.ietf.org/arch/msg/= acme/0lVmGl8e-rmSH0x7ycDW5dj6GAY 

I would prefer option A) as well. It seems better to clear up the non-norma= tive language than to step backwards to a place where proactive issuance ma= y or may not happen without a clear signalling to the client of which a ser= ver will do.

I think the use of "shortly" here is to allow the server some gra= ce to determine that the order is completed and issuance can be performed.
Perhaps we could change the language to say "The server MUST issue the= requested certificate and update the order resource with a URL for the cer= tificate after it has determined the client has fulfilled the server's requ= irements" and not impose any specific mention of the time between the client completing the challenges and the s= erver noticing. Thoughts?

On Wed, Mar 22, 2017 at 1:14 AM, Zach Shepherd <= span dir=3D"ltr"> <shepherdz@vmw= are.com> wrote:
The following feedback is based on 8010a31 (current HEAD of master).
Section 7.4, Applying for Certificate Issuance, states "The server MUS= T issue the requested certificate and update the order resource with a URL = for the certificate shortly after the client has fulfilled the server=92s r= equirements."

Per RFC 2119 Section 6, the imperative MUST should be used with care and sp= aringly.

The use of "shortly" in the above sentence is imprecise. It is no= t possible for a server author to know, with confidence, that they are adhe= ring to this requirement. It is not possible fore a client author to make d= esign or implementation decisions based on this requirement.

I would propose either:
a) Replacing "shortly" with a more precise expectation.
b) Replacing "MUST" with "should".

I believe there are advantages for setting expectations as to the turn-arou= nd time for certificate issuance and would therefore prefer option (a), ass= uming agreement could be reached on more precise language.

Regards,
Zach Shepherd

_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mail= man/listinfo/acme




_______________________________________________=0A=
Acme mailing list=0A=
Acme@ie=
tf.org=0A=
https://www.ietf.org/mailman/l=
istinfo/acme=0A=

--_000_CY4PR05MB30454E2F1697CED075A5D2D8C03C0CY4PR05MB3045namp_-- From nobody Wed Mar 22 11:55: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 E63DE129473 for ; Wed, 22 Mar 2017 11:55:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 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] 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 kxYXoYPbTxTi for ; Wed, 22 Mar 2017 11:55:02 -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 30C28128796 for ; Wed, 22 Mar 2017 11:55:01 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id n11so46156236wma.0 for ; Wed, 22 Mar 2017 11:55:01 -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=lm7/jlSg4rHTAM8PZHqjjFCsj9jA0Z86zVhtt991UWY=; b=XroPB7gYXyP37DHu3gsdZaoybIhV5F2nxRnT+j4zcJwNuRPbBnMGBwXdUisxYl8QG3 LenCqdhKFxrMzalgfcxwuevfsMuzAQ5R26Ky9l6HTDocPWEc3CtYqlNY6noZsWePqioQ Vfwbu1R/HwoxfSXq3Tzn8JMgsLjYeSs2BYBFI= 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=lm7/jlSg4rHTAM8PZHqjjFCsj9jA0Z86zVhtt991UWY=; b=b6LlZKAW/wMN67ecMaNBH6pYurVVIIexy3QLkhdKyKHtxbcvjrDeQVJ/XNmoHE90Vs JQ/zAmUpje5w0lb/3nXXfWVTSr6trNBCDhEMzbzB/9NNSwtKnxg6ssDlpTu2l6acQfc7 DX9L2unmqd2qE8Htjzux9L383DULRMrb3yD04EaF2XZQOcxMOa8F5SJGImoI/IPh6gI5 heJFT8yjFe6QeCpMx1JMK/+YDndyENQEtLbExCsgtbpZk8UDxo6V3+/o1WotEtfnY19u CcLTr2CFg6YyZmvGuni+jROv4/0hVaGH7azhvQAmtDVlAStliYBTGqSQDqQv6ibDctEP K4vQ== X-Gm-Message-State: AFeK/H3VbSPVlneCt0nl2UVBbdOP8zeI7FYty/whS0vkIP44vUqTMdcdZnb9PnFhNJBXjgSY677unghIuVH6TwNu X-Received: by 10.25.115.19 with SMTP id o19mr1599582lfc.162.1490208899553; Wed, 22 Mar 2017 11:54:59 -0700 (PDT) MIME-Version: 1.0 Reply-To: cpu@letsencrypt.org Received: by 10.25.21.211 with HTTP; Wed, 22 Mar 2017 11:54:58 -0700 (PDT) In-Reply-To: References: From: Daniel McCarney Date: Wed, 22 Mar 2017 14:54:58 -0400 Message-ID: To: Zach Shepherd Cc: Jacob Hoffman-Andrews , "acme@ietf.org" Content-Type: multipart/alternative; boundary=001a113c0ac219830d054b564ca4 Archived-At: Subject: Re: [Acme] Use of "shortly" in normative language of Section 7.4, Applying for Certificate 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: Wed, 22 Mar 2017 18:55:07 -0000 --001a113c0ac219830d054b564ca4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 for "MUST begin the issuance process" - thanks for the suggestion Jacob. On Wed, Mar 22, 2017 at 2:44 PM, Zach Shepherd wrote= : > I think "MUST begin the issuance process" addresses my concerns and is in > line with the discussions around preferring "proactive" issuance. > > ------------------------------ > *From:* Jacob Hoffman-Andrews > *Sent:* Wednesday, March 22, 2017 10:13 AM > *To:* cpu@letsencrypt.org; Zach Shepherd > *Cc:* acme@ietf.org > *Subject:* Re: [Acme] Use of "shortly" in normative language of Section > 7.4, Applying for Certificate Issuance > > We could say "MUST begin the issuance process" > > The main things on my mind that could delay issuance slightly: > - Submitting to CT > - Checking CAA > - Internal queuing for available capacity > - Manual vetting > > I think "MUST begin" covers for all of those, while allowing some > vagueness as to how long they will take. > > On 03/22/2017 09:39 AM, Daniel McCarney wrote: > > Hi Zach, > > For background I think this MUST originated out of this thread: > https://mailarchive.ietf.org/arch/msg/acme/0lVmGl8e-rmSH0x7ycDW5dj6GAY > > > > I would prefer option A) as well. It seems better to clear up the > non-normative language than to step backwards to a place where proactive > issuance may or may not happen without a clear signalling to the client o= f > which a server will do. > > I think the use of "shortly" here is to allow the server some grace to > determine that the order is completed and issuance can be performed. > Perhaps we could change the language to say "The server MUST issue the > requested certificate and update the order resource with a URL for the > certificate after it has determined the client has fulfilled the server's > requirements" and not impose any specific mention of the time between the > client completing the challenges and the server noticing. Thoughts? > > On Wed, Mar 22, 2017 at 1:14 AM, Zach Shepherd > wrote: > >> The following feedback is based on 8010a31 (current HEAD of master). >> >> Section 7.4, Applying for Certificate Issuance, states "The server MUST >> issue the requested certificate and update the order resource with a URL >> for the certificate shortly after the client has fulfilled the server=E2= =80=99s >> requirements." >> >> Per RFC 2119 Section 6, the imperative MUST should be used with care and >> sparingly. >> >> The use of "shortly" in the above sentence is imprecise. It is not >> possible for a server author to know, with confidence, that they are >> adhering to this requirement. It is not possible fore a client author to >> make design or implementation decisions based on this requirement. >> >> I would propose either: >> a) Replacing "shortly" with a more precise expectation. >> b) Replacing "MUST" with "should". >> >> I believe there are advantages for setting expectations as to the >> turn-around time for certificate issuance and would therefore prefer opt= ion >> (a), assuming agreement could be reached on more precise language. >> >> Regards, >> Zach Shepherd >> >> _______________________________________________ >> Acme mailing list >> Acme@ietf.org >> https://www.ietf.org/mailman/listinfo/acme >> >> >> > > > _______________________________________________ > Acme mailing listAcme@ietf.orghttps://www.ietf.org/mailman/listinfo/acme = > > > --001a113c0ac219830d054b564ca4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1 for "MUST begin the issuance process" - thank= s for the suggestion Jacob.

On Wed, Mar 22, 2017 at 2:44 PM, Zach Shepherd <shep= herdz@vmware.com> wrote:

I think "MUST begin the issuance process" addresses my concern= s and is in line with the discussions around preferring=C2=A0"proactiv= e" issuance.


From: = Jacob Hoffman-Andrews <jsha@eff.org>
Sent: Wednesday, March 22, 2017 10:13 AM
To: cpu@let= sencrypt.org; Zach Shepherd
Cc: acme@ietf.org=
Subject: Re: [Acme] Use of "shortly" in normative language= of Section 7.4, Applying for Certificate Issuance
=C2=A0
We could say "MUST begin the issuance process"

The main things on my mind that could delay issuance slightly:
=C2=A0- Submitting to CT
=C2=A0- Checking CAA
=C2=A0- Internal queuing for available capacity
=C2=A0- Manual vetting

I think "MUST begin" covers for all of those, while allowing some= vagueness as to how long they will take.

On 03/22/2017 09:39 AM,= Daniel McCarney wrote:
Hi Zach,

For background I think this MUST originated out of this thread:=C2=A0https://mailarchive.= ietf.org/arch/msg/acme/0lVmGl8e-rmSH0x7ycDW5dj6GAY=C2=A0

I would prefer option A) as well. It seems better to clear up the non-norma= tive language than to step backwards to a place where proactive issuance ma= y or may not happen without a clear signalling to the client of which a ser= ver will do.

I think the use of "shortly" here is to allow the server some gra= ce to determine that the order is completed and issuance can be performed.
Perhaps we could change the language to say "The server MUST issue the= requested certificate and update the order resource with a URL for the cer= tificate after it has determined the client has fulfilled the server's = requirements" and not impose any specific mention of the time between the client completing the challenges and the s= erver noticing. Thoughts?

On Wed, Mar 22, 2017 at 1:14 AM, Zach Shepherd <= span dir=3D"ltr"> <shepherdz@vmw= are.com> wrote:
The following feedback is based on 8010a31 (current HEAD of master).
Section 7.4, Applying for Certificate Issuance, states "The server MUS= T issue the requested certificate and update the order resource with a URL = for the certificate shortly after the client has fulfilled the server=E2=80= =99s requirements."

Per RFC 2119 Section 6, the imperative MUST should be used with care and sp= aringly.

The use of "shortly" in the above sentence is imprecise. It is no= t possible for a server author to know, with confidence, that they are adhe= ring to this requirement. It is not possible fore a client author to make d= esign or implementation decisions based on this requirement.

I would propose either:
a) Replacing "shortly" with a more precise expectation.
b) Replacing "MUST" with "should".

I believe there are advantages for setting expectations as to the turn-arou= nd time for certificate issuance and would therefore prefer option (a), ass= uming agreement could be reached on more precise language.

Regards,
Zach Shepherd

_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mail= man/listinfo/acme



<= br> 
_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme


--001a113c0ac219830d054b564ca4-- From nobody Wed Mar 22 14:08: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 C69731294A2 for ; Wed, 22 Mar 2017 14:08:08 -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 34h_fbVGR8EQ for ; Wed, 22 Mar 2017 14:08:05 -0700 (PDT) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::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 CD0A2128BBB for ; Wed, 22 Mar 2017 14:08:05 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id o190so14876998pfo.0 for ; Wed, 22 Mar 2017 14:08:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=letsencrypt.org; s=google; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=O541RzKGERTTDbz0pXLDk/WKwK7XLB7fLxKt3FMNJu0=; b=RRIYhX72UqeJjP8AF206nL4+9EVKHhdBoliJv5/9K4OfvD0y743ovpGBUrtb/uLu6x WiAEjc2G47poo4dMUhx6cPMqOHnP1+7cd7rFma/ta3U5dtSxD6i8oxkOhwnmuQ3FzzyW q9L7VBA5F/8azkdlD/7iCuwznZSqnWkLkqCO0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=O541RzKGERTTDbz0pXLDk/WKwK7XLB7fLxKt3FMNJu0=; b=oexVc0ggiS8va4DIq0WqMGwSQ5+I8m5LjOOikYwSMh7TjUetNP2WG0FCyHobmIPHtr Go88c99shoxRwQkqgYJWIw+MEtNPW28cg3Hyr7RzMX/oKf/k6tJ5ao0ST8bFAeNTmLUA Z0ZmUerBgdDKEDnDewbiLh/cj2JpoYeWj4WqZ1cBssmOn5x35gKkUsxdWyqUgNUp+gMJ p3HwvBJImc7qY/mwNRfdzvh4eSZ1z0AVc5uGwvwxezMeP2mVpM03mJ6AMZrLbFj1uVSS t4i2HqUfouglNj/JPcAKQqU/b03nsCY8p/2mStBy7cvGHIAPwaHWPcTnxGQbvXPRwyRB TT4Q== X-Gm-Message-State: AFeK/H0Mpjqx57Eu+PD5NgwvJerA6n457rE3zVDoB2YTu/HxyoKy83QDTlLw4MKXUNzeY+2g X-Received: by 10.98.50.5 with SMTP id y5mr29949951pfy.169.1490216885376; Wed, 22 Mar 2017 14:08:05 -0700 (PDT) Received: from [10.120.0.195] (eff.static.monkeybrains.net. [208.90.213.162]) by smtp.gmail.com with ESMTPSA id e70sm5678803pfh.84.2017.03.22.14.08.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Mar 2017 14:08:04 -0700 (PDT) To: "acme@ietf.org" , "Salz, Rich" , Ted Hardie From: Roland Shoemaker Message-ID: Date: Wed, 22 Mar 2017 14:08:04 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Acme] Possible IETF meeting agenda item: reducing effects of key-compromise 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, 22 Mar 2017 21:08:09 -0000 Internally at LE we have been having discussions around how the spec can most effectively reduce the harm of account key compromise and it seems like it could be a good topic to bring up at the upcoming IETF meeting. We've come up with two distinct but not mutually exclusive ideas on this topic: * Deactivating authorizations on key roll-over, summarized here: https://www.ietf.org/mail-archive/web/acme/current/msg01747.html * Only allowing a single valid authorization per name to exist at the same time, summarized here: https://www.ietf.org/mail-archive/web/acme/current/msg01661.html Both of these proposals would be relatively large changes to the current follow and introduce certain issues for both individual users and large service integrators and could definitely use some public discussion before the spec is finalized. It would also be good to hear if there are any other thoughts from other implementors/contributors as to how we can best reduce the damage done by key compromise in general. -- Roland Bracewell Shoemaker Software Engineer Linux Foundation / Internet Security Research Group From nobody Wed Mar 22 15:19:33 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 0B30D128CFF for ; Wed, 22 Mar 2017 15:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.697 X-Spam-Level: X-Spam-Status: No, score=-4.697 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, RCVD_IN_MSPIKE_H2=-2.796, 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=onevmw.onmicrosoft.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 ss38JXfCtbmz for ; Wed, 22 Mar 2017 15:19:29 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0069.outbound.protection.outlook.com [104.47.37.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16AF0127735 for ; Wed, 22 Mar 2017 15:19:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onevmw.onmicrosoft.com; s=selector1-vmware-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ZAqPcrL01nhWobsvzEwMZ6HDQoFzlHejOClGTZzNuUE=; b=S5uyEhIF9OsNGsQtQLWg/duAJZvLgUSTA7sXLRMcpBhhbD9dRihpcMSYrgeCFVncM0iBYQhoirS5d/1eVF+8PP3uOF7YyCKS123E7CQteRBhO5JciPZVeSeD6TeXCgO6DubCvjob5XSiC6b1lqJ4qx5G+LmufbxTmlw83K0xIGc= Received: from CY4PR05MB3045.namprd05.prod.outlook.com (10.172.155.135) by CY4PR05MB3045.namprd05.prod.outlook.com (10.172.155.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4; Wed, 22 Mar 2017 22:19:27 +0000 Received: from CY4PR05MB3045.namprd05.prod.outlook.com ([10.172.155.135]) by CY4PR05MB3045.namprd05.prod.outlook.com ([10.172.155.135]) with mapi id 15.01.0991.013; Wed, 22 Mar 2017 22:19:27 +0000 From: Zach Shepherd To: "acme@ietf.org" Thread-Topic: Allowing for consistent handling of ToS re-agreement Thread-Index: AQHSo1paG6nts1xKlkyDAWcAc9npLA== Date: Wed, 22 Mar 2017 22:19:27 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=vmware.com; x-originating-ip: [208.90.213.162] x-microsoft-exchange-diagnostics: 1; CY4PR05MB3045; 7:C8uzpGMXD9NFbz9DTfNdEArQc10o2GTUpxTktLvR77Le9zTAnpBKUrNvbMWeuQ7Ur+EpJ7gQFfXKCj4SnxRvOP2+QZVR1CDznghTVzjnnMV0n1jsbFVzwe4+xruOeSDE/sV8yxm8z3vhI4NEt5Oij3rIXwSxhoZ9aaIHuHmkJHXdOh/KoJ4IJUEJxPZXuEfVbyQZhul2b2TL6OKXaVsMjSYnmdZknRaV+v8k6MYqsET7MF+6pxyz58knnEylFewjbU3K4lRM/KYniFG0IPc+Ucm3kNiM8xPJ/81fWkA2jgkAtI8rc1V4sjhwADRFOV+95yq9Cs6CjK4WurydrIu0kA==; 20:jgywRO77xp/a89raSd1nozmwQjtDnYoOMUSp21cZIN9sMHtqAvK2QHmLEVjwRfE356EG82EXjDWBVjIrryeuRUbQIMkXYQwo303xCZzu0rb/TrtWJJxBszBrC9Hqd4yYAyyw4ak+wGD6SZanNlp0pcY+ZjwpLr07OHz2ccC5pFE= x-ms-office365-filtering-correlation-id: f0e27e0b-585f-4d57-251f-08d4717180f8 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075); SRVR:CY4PR05MB3045; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123558025)(20161123560025)(6072148); SRVR:CY4PR05MB3045; BCL:0; PCL:0; RULEID:; SRVR:CY4PR05MB3045; x-forefront-prvs: 02543CD7CD x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39410400002)(39830400002)(39450400003)(99286003)(7696004)(5660300001)(81166006)(8676002)(3280700002)(1730700003)(2906002)(5640700003)(8936002)(55016002)(50986999)(7736002)(9686003)(74316002)(2351001)(6606003)(6306002)(122556002)(33656002)(66066001)(6506006)(19627405001)(77096006)(54896002)(54356999)(3660700001)(6436002)(2501003)(53936002)(6916009)(110136004)(2900100001)(6116002)(102836003)(38730400002)(3846002)(575784001)(189998001)(53336002)(25786009)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR05MB3045; H:CY4PR05MB3045.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR05MB3045E2C3059BC5209FA438AAC03C0CY4PR05MB3045namp_" MIME-Version: 1.0 X-OriginatorOrg: vmware.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2017 22:19:27.3260 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR05MB3045 Archived-At: Subject: [Acme] Allowing for consistent handling of ToS re-agreement 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, 22 Mar 2017 22:19:32 -0000 --_000_CY4PR05MB3045E2C3059BC5209FA438AAC03C0CY4PR05MB3045namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The following feedback is based on 8010a31 (current HEAD of master). Section 7.3.1, Changes of Terms of Service, states the following: "As described above, a client can indicate its agreement with the CA=92s te= rms of service by setting the =93terms-of-service-agreed=94 field in its ac= count object to =93true=94. "If the server has changed its terms of service since a client initially ag= reed, and the server is unwilling to process a request without explicit agr= eement to the new terms, then it MUST return an error response with status = code 403 (Forbidden) and type =93urn:ietf:params:acme:error:userActionRequi= red=94. This response MUST include a Link header with link relation =93term= s-of-service=94 and the latest terms-of-service URL. "The problem document returned with the error MUST also include an =93insta= nce=94 field, indicating a URL that the client should direct a human user t= o visit in order for instructions on how to agree to the terms." I realize that this has been debated extensively and largely agree with the= conclusions from [1], but I think there are disadvantages to having the To= S URL provide instructions for the human user to agree to the new term. The= main concern I have with [1] is that there may not be a clear way for the = human user to authenticate with the CA to click an "Accept" button if the A= CME server hasn't needed to use the external-account-binding functionality = for some other reason. I think a relatively small change could address this: associate a timestamp= with terms-of-service-agreed, and include it as a read-only part of the ac= count object. In this way, it is easy for a client to allow the human user to re-accept t= erms in a standard way (following the same pattern the client would use for= any other account update), causing the server to update the associated tim= estamp. This provides consistency between ACME servers. This requires that the server track when clients have agreed to updated ter= ms of service, which is only incrementally more work than storing a boolean= (and is something a server may want to track anyway). This still fully supports the notion of "auto updating" terms of service. This could still support a human user clicking an "Accept" button, which co= uld trigger an out-of-band update to the timestamp (and the permissibility = of this could be emphasized with a MAY). This adds minimal additional complexity to the protocol. Regards, Zach Shepherd 1 - https://mailarchive.ietf.org/arch/msg/acme/c-wycMyvyX0Jkk7NS0Lfxj6Z0GY --_000_CY4PR05MB3045E2C3059BC5209FA438AAC03C0CY4PR05MB3045namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

The following feedback is based on 8010a31 (current HEAD of master).

Section 7.3.1, Changes of Terms of Service, states the following:

"As described above, a client can indicate its agreement with the CA= =92s terms of service by setting the =93terms-of-service-agreed=94 field in= its account object to =93true=94.

"If the server has changed its terms of service since a client initial= ly agreed, and the server is unwilling to process a request without explici= t agreement to the new terms, then it MUST return an error response with st= atus code 403 (Forbidden) and type =93urn:ietf:params:acme:error:userAction= Required=94. This response MUST include a Link header with link relation =93terms-of-se= rvice=94 and the latest terms-of-service URL.

"The problem document returned with the error MUST also include an =93= instance=94 field, indicating a URL that the client should direct a human u= ser to visit in order for instructions on how to agree to the terms."<= br>

I realize that this has been debated extensively and largely agree with the= conclusions from [1], but I think there are disadvantages to having the To= S URL provide instructions for the human user to agree to the new term. The= main concern I have with [1] is that there may not be a clear way for the human user to authenticate with = the CA to click an "Accept" button if the ACME server hasn't need= ed to use the external-account-binding functionality for some other reason.=


I think a relatively small change could address this: associate a timestamp= with terms-of-service-agreed, and include it as a read-only part of the ac= count object.

In this way, it is easy for a client to allow the human user to re-accept t= erms in a standard way (following the same pattern the client would use for= any other account update), causing the server to update the associated tim= estamp. This provides consistency between ACME servers.

This requires that the server track when clients have agreed to updated ter= ms of service, which is only incrementally more work than storing a boolean= (and is something a server may want to track anyway).


This still fully supports the notion of "auto updating" terms of = service.

This could still support a human user clicking an "Accept" button= , which could trigger an out-of-band update to the timestamp (and the permi= ssibility of this could be emphasized with a MAY).

This adds minimal additional complexity to the protocol.

Regards,
Zach Shepherd

1 - https://mailarchive.ietf.org/arch/msg/acme/c-wycMyvyX0Jkk7NS0Lfxj6Z0GY<= /div>

--_000_CY4PR05MB3045E2C3059BC5209FA438AAC03C0CY4PR05MB3045namp_-- From nobody Wed Mar 22 17:16: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 7728E1293EC for ; Wed, 22 Mar 2017 17:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.697 X-Spam-Level: X-Spam-Status: No, score=-4.697 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, RCVD_IN_MSPIKE_H2=-2.796, 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=onevmw.onmicrosoft.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 h7icqaSAg5jF for ; Wed, 22 Mar 2017 17:16:37 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0047.outbound.protection.outlook.com [104.47.42.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20000128AB0 for ; Wed, 22 Mar 2017 17:16:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onevmw.onmicrosoft.com; s=selector1-vmware-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=3idRPg17gW6ect18hOcv9pJR9nCrlrmW7LDWFUqverg=; b=MpW0KKZZ1UI/6Z3uvatuxYeGl2JFh5EL0xizixNcROH+su2/J/VNKqGr3DY+pJ8Te05J60ydi1oHdQZxOFnCutQkf1Tan7/7C7jPhGk2jRKqZhdHrnqsa4/J+f/jbYObK5lsXZrBMtaZNvZpEZOejnPQ+6yGmKUfPY+bwjcHct0= Received: from CY4PR05MB3045.namprd05.prod.outlook.com (10.172.155.135) by CY4PR05MB3048.namprd05.prod.outlook.com (10.172.156.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4; Thu, 23 Mar 2017 00:16:35 +0000 Received: from CY4PR05MB3045.namprd05.prod.outlook.com ([10.172.155.135]) by CY4PR05MB3045.namprd05.prod.outlook.com ([10.172.155.135]) with mapi id 15.01.0991.013; Thu, 23 Mar 2017 00:16:36 +0000 From: Zach Shepherd To: "acme@ietf.org" Thread-Topic: Inconsistent use of URL and URI Thread-Index: AQHSo2iO+Xe9xgovSEOxyu+eGnWLBQ== Date: Thu, 23 Mar 2017 00:16:36 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=vmware.com; x-originating-ip: [25.173.128.132] x-microsoft-exchange-diagnostics: 1; CY4PR05MB3048; 7:g8F7T7uar4RRO6fb1TXYnwhjhfmDTbxr6IMWWeN30CD4o/6MER+ohaRnCwrsks9QNd/1qFqsYJx7WbxMYOEdmR2e6edtpasNIFDU/g/ps1plz7CYIb2tmhgZdXv+M8vFHu6LTjiPHIn6SgwatS2kCmvaAIBnEy+wuQ9LDFKwFPpY6h8Ifmr+qJmOhM+2tzpkyrTVZmEpRmEr3N3oTNSEC8rg/PbE6rUsf0KTdnnyN87bH0r+Qz17S1NPTIKALXLeOjB//ceRkddzRrRxlcMl3727P6KxpPXgpMW4/6LedHAM0BKTS5Yj3h1/lXV0IsphE7G9+yrspm3pYkqyLw70YQ==; 20:Dn40VR9uzSBd7U5gLoW0fBTgd/39YHWAQN1MZWtBg/UMj5Vw1F6guD2mBq7K44LNtYmPaCEkTTgc06zI8vBP7v2Vk3QhksBUCo6n67DIoun3TjN4PIaJyZdksqHuwTf2+qm6I+q8dQBBPiYJeJGlMJZDIKf2pCqLzyXhoLlcCA4= x-ms-office365-filtering-correlation-id: 7c1cf125-69d9-424d-3fd6-08d47181de6e x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075); SRVR:CY4PR05MB3048; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123564025)(20161123560025)(20161123558025)(20161123555025)(20161123562025)(6072148); SRVR:CY4PR05MB3048; BCL:0; PCL:0; RULEID:; SRVR:CY4PR05MB3048; x-forefront-prvs: 0255DF69B9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39830400002)(39450400003)(39410400002)(54896002)(9686003)(54356999)(189998001)(3660700001)(99286003)(38730400002)(66066001)(50986999)(55016002)(81166006)(7696004)(110136004)(2906002)(77096006)(6506006)(25786009)(3280700002)(6436002)(1730700003)(122556002)(74316002)(5640700003)(8936002)(7736002)(2351001)(53336002)(102836003)(3846002)(6916009)(6116002)(19627405001)(5660300001)(6606003)(2900100001)(86362001)(2501003)(8676002)(33656002)(53936002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR05MB3048; H:CY4PR05MB3045.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR05MB304578A933F55C44D9BEFF30C03F0CY4PR05MB3045namp_" MIME-Version: 1.0 X-OriginatorOrg: vmware.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Mar 2017 00:16:36.1358 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR05MB3048 Archived-At: Subject: [Acme] Inconsistent use of URL and URI 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, 23 Mar 2017 00:16:39 -0000 --_000_CY4PR05MB304578A933F55C44D9BEFF30C03F0CY4PR05MB3045namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The following feedback is based on 8010a31 (current HEAD of master). The document seems to prefer URI, but uses URL at various points, somewhat = interchangeably. Section 1.1.3 of RFC 3986 (STD 66) states: "Future specifications and relat= ed documentation should use the general term 'URI' rather than the more res= trictive terms 'URL' and 'URN' [RFC3305]." Based on this, it seems like URI= should be preferred to URL throughout the document. I would propose either: (a) Updating all sections of the document to use URI in place of URL, excep= t for the "url" JWS header parameter and directly related documentation. (b) Updating all sections of the document to use URI in place of URL. Given the implications of changing the "url" JWS header parameter, (a) seem= s preferable. Regards, Zach Shepherd --_000_CY4PR05MB304578A933F55C44D9BEFF30C03F0CY4PR05MB3045namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

The following feedback is based on 8010a31 (current HEAD of master).
The document seems to prefer URI, but uses URL at various points= , somewhat interchangeably.

Section 1.1.3 of RFC 3986 (STD 66) states: "Future specifications and = related documentation should use the general term 'URI' rather than the mor= e restrictive terms 'URL' and 'URN' [RFC3305]." Based on this, it seem= s like URI should be preferred to URL throughout the document.

I would propose either:
(a) Updating all sections of the document to use URI in place of URL, excep= t for the "url" JWS header parameter and directly related documenta= tion.
(b) Updating all sections of the document to use URI in place of URL.=

Given the implications of changing the "url" JWS header parameter= , (a) seems preferable.

Regards,
Zach Shepherd

--_000_CY4PR05MB304578A933F55C44D9BEFF30C03F0CY4PR05MB3045namp_-- From nobody Wed Mar 22 18:39: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 C677F128AB0 for ; Wed, 22 Mar 2017 18:39:39 -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, 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 (1024-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 3yHGDCR1DnXQ for ; Wed, 22 Mar 2017 18:39:38 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 1E99912422F for ; Wed, 22 Mar 2017 18:39:38 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id BE91720001A; Thu, 23 Mar 2017 01:39:37 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 8CA6A200004; Thu, 23 Mar 2017 01:39:37 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1490233177; bh=I6KwZw49Qf1YQJeX8pT4Aec3XTVrixFApLmOcd7WyPM=; l=2440; h=From:To:Date:References:In-Reply-To:From; b=hcIvDt6/+DTvcgvr2QVisOB5iv3ELnBYYuslgxCFPmspEt8zSwV1O75JABiFCthKM ibJHpNP5pN9kTRVjY/kt+qquFtgN2+bEdPJJsMUC2w6C2dsJ9MiV9sbq1DFDoZ855y RID0TwYfyz++hsEiuH/qYVh8o5huoXav2k6We2nw= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.33]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 39F5C1E07C; Thu, 23 Mar 2017 01:39:37 +0000 (GMT) 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.1178.4; Wed, 22 Mar 2017 21:39:36 -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.1178.000; Wed, 22 Mar 2017 21:39:36 -0400 From: "Salz, Rich" To: Roland Shoemaker , "acme@ietf.org" , Ted Hardie Thread-Topic: Possible IETF meeting agenda item: reducing effects of key-compromise Thread-Index: AQHSo1BoLAJUOwfCQk2aJOKVENLNhKGhpayg Date: Thu, 23 Mar 2017 01:39:35 +0000 Message-ID: <9102f546711a4456aee5912e4de7fed4@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.47.116] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Acme] Possible IETF meeting agenda item: reducing effects of key-compromise 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, 23 Mar 2017 01:39:40 -0000 SSB0aGluayBkb2luZyB0aGlzIHdvdWxkIHJlc2V0IHRoZSBXR0xDIGNsb2NrOyBuZWl0aGVyIHNl ZW0gbGlrZSBtaW5vciBjaGFuZ2VzLiAgV2UgY2FuIGRpc2N1c3MgaW4gQ2hpY2FnbywgSSBob3Bl IHdlIGNhbiBtYWtlIHRpbWUsIGJ1dCB0aGUgV0cgd291bGQgZGVmaW5pdGVseSBoYXZlIHRvIGhh dmUgY29uc2Vuc3VzIG9uIHRoZSBtYWlsaW5nIGxpc3QuDQoNCi0tICANClNlbmlvciBBcmNoaXRl Y3QsIEFrYW1haSBUZWNobm9sb2dpZXMNCk1lbWJlciwgT3BlblNTTCBEZXYgVGVhbQ0KSU06IHJp Y2hzYWx6QGphYmJlci5hdCBUd2l0dGVyOiBSaWNoU2Fseg0KDQoNCj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gRnJvbTogUm9sYW5kIFNob2VtYWtlciBbbWFpbHRvOnJvbGFuZEBsZXRz ZW5jcnlwdC5vcmddDQo+IFNlbnQ6IFdlZG5lc2RheSwgTWFyY2ggMjIsIDIwMTcgNTowOCBQTQ0K PiBUbzogYWNtZUBpZXRmLm9yZzsgU2FseiwgUmljaDsgVGVkIEhhcmRpZQ0KPiBTdWJqZWN0OiBQ b3NzaWJsZSBJRVRGIG1lZXRpbmcgYWdlbmRhIGl0ZW06IHJlZHVjaW5nIGVmZmVjdHMgb2Yga2V5 LQ0KPiBjb21wcm9taXNlDQo+IA0KPiBJbnRlcm5hbGx5IGF0IExFIHdlIGhhdmUgYmVlbiBoYXZp bmcgZGlzY3Vzc2lvbnMgYXJvdW5kIGhvdyB0aGUgc3BlYyBjYW4NCj4gbW9zdCBlZmZlY3RpdmVs eSByZWR1Y2UgdGhlIGhhcm0gb2YgYWNjb3VudCBrZXkgY29tcHJvbWlzZSBhbmQgaXQgc2VlbXMN Cj4gbGlrZSBpdCBjb3VsZCBiZSBhIGdvb2QgdG9waWMgdG8gYnJpbmcgdXAgYXQgdGhlIHVwY29t aW5nIElFVEYgbWVldGluZy4NCj4gDQo+IFdlJ3ZlIGNvbWUgdXAgd2l0aCB0d28gZGlzdGluY3Qg YnV0IG5vdCBtdXR1YWxseSBleGNsdXNpdmUgaWRlYXMgb24gdGhpcw0KPiB0b3BpYzoNCj4gDQo+ ICogRGVhY3RpdmF0aW5nIGF1dGhvcml6YXRpb25zIG9uIGtleSByb2xsLW92ZXIsIHN1bW1hcml6 ZWQgaGVyZToNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9hY21lL2N1 cnJlbnQvbXNnMDE3NDcuaHRtbA0KPiAqIE9ubHkgYWxsb3dpbmcgYSBzaW5nbGUgdmFsaWQgYXV0 aG9yaXphdGlvbiBwZXIgbmFtZSB0byBleGlzdCBhdCB0aGUgc2FtZQ0KPiB0aW1lLCBzdW1tYXJp emVkIGhlcmU6DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvYWNtZS9j dXJyZW50L21zZzAxNjYxLmh0bWwNCj4gDQo+IEJvdGggb2YgdGhlc2UgcHJvcG9zYWxzIHdvdWxk IGJlIHJlbGF0aXZlbHkgbGFyZ2UgY2hhbmdlcyB0byB0aGUgY3VycmVudA0KPiBmb2xsb3cgYW5k IGludHJvZHVjZSBjZXJ0YWluIGlzc3VlcyBmb3IgYm90aCBpbmRpdmlkdWFsIHVzZXJzIGFuZCBs YXJnZSBzZXJ2aWNlDQo+IGludGVncmF0b3JzIGFuZCBjb3VsZCBkZWZpbml0ZWx5IHVzZSBzb21l IHB1YmxpYyBkaXNjdXNzaW9uIGJlZm9yZSB0aGUgc3BlYyBpcw0KPiBmaW5hbGl6ZWQuDQo+IA0K PiBJdCB3b3VsZCBhbHNvIGJlIGdvb2QgdG8gaGVhciBpZiB0aGVyZSBhcmUgYW55IG90aGVyIHRo b3VnaHRzIGZyb20gb3RoZXINCj4gaW1wbGVtZW50b3JzL2NvbnRyaWJ1dG9ycyBhcyB0byBob3cg d2UgY2FuIGJlc3QgcmVkdWNlIHRoZSBkYW1hZ2UgZG9uZQ0KPiBieSBrZXkgY29tcHJvbWlzZSBp biBnZW5lcmFsLg0KPiANCj4gLS0NCj4gUm9sYW5kIEJyYWNld2VsbCBTaG9lbWFrZXINCj4gU29m dHdhcmUgRW5naW5lZXINCj4gTGludXggRm91bmRhdGlvbiAvIEludGVybmV0IFNlY3VyaXR5IFJl c2VhcmNoIEdyb3VwDQo= From nobody Thu Mar 23 05:44: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 E181D128CDC for ; Thu, 23 Mar 2017 05:44:44 -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, SPF_FAIL=0.001, SPF_HELO_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 5pJx0Co1eqev for ; Thu, 23 Mar 2017 05:44:43 -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 D1D471293F8 for ; Thu, 23 Mar 2017 05:44:42 -0700 (PDT) Received: from host249.freudenhaus.alandoherty.net ([193.120.128.249]:3113 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 1cr26W-0003o7-Uv ; Thu, 23 Mar 2017 12:44:38 +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: Thu, 23 Mar 2017 12:44:33 +0000 To: Roland Shoemaker , "acme@ietf.org" ,"Salz, Rich" , Ted Hardie From: Alan Doherty In-Reply-To: References: 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] Possible IETF meeting agenda item: reducing effects of key-compromise 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, 23 Mar 2017 12:44:45 -0000 At 21:08 22/03/2017 Wednesday, Roland Shoemaker wrote: >Internally at LE we have been having discussions around how the spec can >most effectively reduce the harm of account key compromise and it seems >like it could be a good topic to bring up at the upcoming IETF meeting. > >We've come up with two distinct but not mutually exclusive ideas on this >topic: > >* Deactivating authorizations on key roll-over, summarized here: >https://www.ietf.org/mail-archive/web/acme/current/msg01747.html >* Only allowing a single valid authorization per name to exist at the >same time, summarized here: >https://www.ietf.org/mail-archive/web/acme/current/msg01661.html i could see potential issues with the second one (for example name.example.tld is used in both https and smtp-tls, https server(reverse proxy) runs its own LE client and obtains a SAN for this and other https names smtp server(mx) runs its own LE client and obtains a different SAN for this and other names used in smtp-tls as both could be running in different parts of an org by different departments (behind the one NAT device) so i would be more in favor of possibly adding (despite the fact it will likely be a LOT more work) an exclusive(y/n) toggle to the name authorization system eg a client account can authorize a name exclusively or non-exclusively (to allow exclusivity for those with only one account, and non-exclusivity for those with other needs) but that said maybe im overthining >Both of these proposals would be relatively large changes to the current >follow and introduce certain issues for both individual users and large >service integrators and could definitely use some public discussion >before the spec is finalized. > >It would also be good to hear if there are any other thoughts from other >implementors/contributors as to how we can best reduce the damage done >by key compromise in general. > >-- >Roland Bracewell Shoemaker >Software Engineer >Linux Foundation / Internet Security Research Group > >_______________________________________________ >Acme mailing list >Acme@ietf.org >https://www.ietf.org/mailman/listinfo/acme From nobody Thu Mar 23 10:11: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 62038129ABE for ; Thu, 23 Mar 2017 10:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.696 X-Spam-Level: X-Spam-Status: No, score=-4.696 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, RCVD_IN_MSPIKE_H2=-2.796, 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=onevmw.onmicrosoft.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 BseAJOWzGeO9 for ; Thu, 23 Mar 2017 10:11:48 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0082.outbound.protection.outlook.com [104.47.34.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F979129ACD for ; Thu, 23 Mar 2017 10:11:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onevmw.onmicrosoft.com; s=selector1-vmware-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=1bcUWontB0Odf96CJ6QnLvkxRXYjjphR1XdWbk+ACJc=; b=U48WbukxrrxT3ST+T9AbH2uRBDY0RbYhS3BVEzR1sc5gpSufQoqj1tCUPeImgmBbvmhzPi46DenruNztpCN4CelX3d+Hxko4rO+WITuGOmif71Nvqg0h9ha71G9ucSSV11icAuAnIG3aiI+ufKA/3qNMK4PjPQsOb1CbzNbBRIw= Received: from CY4PR05MB3045.namprd05.prod.outlook.com (10.172.155.135) by CY4PR05MB3045.namprd05.prod.outlook.com (10.172.155.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4; Thu, 23 Mar 2017 17:11:32 +0000 Received: from CY4PR05MB3045.namprd05.prod.outlook.com ([10.172.155.135]) by CY4PR05MB3045.namprd05.prod.outlook.com ([10.172.155.135]) with mapi id 15.01.0991.017; Thu, 23 Mar 2017 17:11:32 +0000 From: Zach Shepherd To: Roland Shoemaker , "acme@ietf.org" , "Salz, Rich" , Ted Hardie Thread-Topic: [Acme] Possible IETF meeting agenda item: reducing effects of key-compromise Thread-Index: AQHSo1BtTCSVhd4910eq7uBFtwAn0aGionYE Date: Thu, 23 Mar 2017 17:11:32 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: letsencrypt.org; dkim=none (message not signed) header.d=none; letsencrypt.org; dmarc=none action=none header.from=vmware.com; x-originating-ip: [25.173.128.132] x-microsoft-exchange-diagnostics: 1; CY4PR05MB3045; 7:HWzkxmKVdCe2+lzYuRbuDIn5WuG+cH1+69XWj47uM7UXgr9FlP1sxSvOqigmnmqWamhxVIrwoApI7QyOUWwbBlHdxRnfWfyNlxfzmPSazMF6p3S/dswdKTggQus5GVq664esRzzeDAiZW8Sbdqry+zbJdfIYsSTsp0b5ciUhr02O7/aG6ml6eJ5eu2rHcutpcBdmntANU7EEyS3jJaxLNrvu5SlUupww8WoF+Sph/2VOnIFQoXv0OS4juF+bfLURkAIh9OfCgyrh7mD5Pu3l5GSvDulMnZRxxyY81H+FOu/oifSGTT+uOgPIfkaDk75eaz7XzxwLp6seF/wmCJW/AQ==; 20:FuoSEGdxlwCnX4Qobd9s2mYFkJU9fWjms631LYCimiNVpzuemL6UHQymMWzWWeEvywcCJHe94breFku8h7AKESTqmGLfh4LkxBWEkdjrQKV04sq7lp4ZmiOSyJb2hdP/IIFDBpVhKGoOH7QM4H3ztcz4JLAnkltUkSkGLwniuSs= x-ms-office365-filtering-correlation-id: 206cd74c-f30b-4da4-f336-08d4720fa767 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075); SRVR:CY4PR05MB3045; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(60795455431006)(158342451672863)(10436049006162)(192374486261705)(788757137089); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123562025)(20161123558025)(20161123564025)(20161123555025)(20161123560025)(6072148); SRVR:CY4PR05MB3045; BCL:0; PCL:0; RULEID:; SRVR:CY4PR05MB3045; x-forefront-prvs: 0255DF69B9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39410400002)(39830400002)(39450400003)(377454003)(22804003)(236005)(6246003)(122556002)(38730400002)(39060400002)(9686003)(53936002)(5660300001)(2900100001)(2950100002)(66066001)(3660700001)(6306002)(54896002)(7696004)(575784001)(86362001)(2501003)(55016002)(99286003)(3280700002)(6606003)(74316002)(77096006)(19627405001)(189998001)(50986999)(76176999)(54356999)(81166006)(8676002)(229853002)(25786009)(6116002)(53546009)(33656002)(3846002)(2906002)(606005)(7906003)(102836003)(6506006)(7736002)(6436002)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR05MB3045; H:CY4PR05MB3045.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR05MB30454C4D983985EFF2E631E5C03F0CY4PR05MB3045namp_" MIME-Version: 1.0 X-OriginatorOrg: vmware.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Mar 2017 17:11:32.2474 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR05MB3045 Archived-At: Subject: Re: [Acme] Possible IETF meeting agenda item: reducing effects of key-compromise 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, 23 Mar 2017 17:11:52 -0000 --_000_CY4PR05MB30454C4D983985EFF2E631E5C03F0CY4PR05MB3045namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Section 7.6, Certificate Revocation, states: "Before revoking a certificate= , the server MUST verify that the key used to sign the request is authorize= d to revoke the certificate. The server SHOULD consider at least the follow= ing accounts authorized for a given certificate: ... an account that holds = authorizations for all of the identifiers in the certificate." One way to address this issue would be to replace "all" with "any". That is= , allow an account holding authorization for an identifier to revoke any ce= rtificate issued for that identifier, even if the certificate is also valid= for other identifiers. Conceptually, I think this makes sense: the purpose of challenges is to ver= ify that the an account is authorized for an identifier only if the account= holder is in control of the identifier, and if the account holder is in co= ntrol of the identifier, they should be able to revoke certificates issued = for that identifier. This does, obviously, have consequences on the security model: * Currently, an attacker which gains control of an identifier is able to c= reate or revoke certificates issued for only that identifier. With this cha= nge, they would also be able to revoke multi-identifier certificates which = include the identifier they have gained control of. * This successfully reduces the impact of account key compromise; if an at= tacker gains control of an account key, any certificates they create can be= revoked. * This also addresses an additional issue: if an identifier changes owners= hip, the new owner can revoke existing certificates for that identifier, in= cluding multi-identifier certificates. This would, essentially, be prioritizing confidentiality of each identifier= over availability of all identifiers on a multi-identifier certificate. By= creating a multi-identifier certificate, users would be "opting in" to thi= s trade-off. To me, this seems like a reasonable trade-off (especially beca= use compromise of an identifier is already catastrophic), but perhaps there= are use cases for multi-identifier certificates that I'm not considering. This seems to have minimal impact on the protocol as well as both client an= d server implementations. Regards, Zach Shepherd ________________________________ From: Acme on behalf of Roland Shoemaker Sent: Wednesday, March 22, 2017 2:08 PM To: acme@ietf.org; Salz, Rich; Ted Hardie Subject: [Acme] Possible IETF meeting agenda item: reducing effects of key-= compromise Internally at LE we have been having discussions around how the spec can most effectively reduce the harm of account key compromise and it seems like it could be a good topic to bring up at the upcoming IETF meeting. We've come up with two distinct but not mutually exclusive ideas on this topic: * Deactivating authorizations on key roll-over, summarized here: https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail-2D= archive_web_acme_current_msg01747.html&d=3DDwICAg&c=3DuilaK90D4TOVoH58JNXRg= Q&r=3DZ9jmRNJFc0_mrYgZ7k4FWDuC1AsqA1UJKUYIM6ZnnNk&m=3DBmiI-FcQEZIzAmQ9cl9VV= p_QYsKukJB0PtSfizZuYdY&s=3DiGd1H6LLa6yZ1eailcLMJAatf_sYvR9g1BIAcBmsQig&e=3D * Only allowing a single valid authorization per name to exist at the same time, summarized here: https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail-2D= archive_web_acme_current_msg01661.html&d=3DDwICAg&c=3DuilaK90D4TOVoH58JNXRg= Q&r=3DZ9jmRNJFc0_mrYgZ7k4FWDuC1AsqA1UJKUYIM6ZnnNk&m=3DBmiI-FcQEZIzAmQ9cl9VV= p_QYsKukJB0PtSfizZuYdY&s=3DUbH6UN-99PK6TbADeVA6J3Yvf72wYVyKd7NoK5IKNEk&e=3D Both of these proposals would be relatively large changes to the current follow and introduce certain issues for both individual users and large service integrators and could definitely use some public discussion before the spec is finalized. It would also be good to hear if there are any other thoughts from other implementors/contributors as to how we can best reduce the damage done by key compromise in general. -- Roland Bracewell Shoemaker Software Engineer Linux Foundation / Internet Security Research Group _______________________________________________ Acme mailing list Acme@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_acme&d=3DDwICAg&c=3DuilaK90D4TOVoH58JNXRgQ&r=3DZ9jmRNJFc0_mrYgZ7k= 4FWDuC1AsqA1UJKUYIM6ZnnNk&m=3DBmiI-FcQEZIzAmQ9cl9VVp_QYsKukJB0PtSfizZuYdY&s= =3DDIKow_UF52PW12xZNcT5yhSFtlsjhnjM4W1wNPgMOvc&e=3D --_000_CY4PR05MB30454C4D983985EFF2E631E5C03F0CY4PR05MB3045namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Section 7.6, Certificate Revocation, states: "Before revoking a c= ertificate, the server MUST verify that the key used to sign the request is= authorized to revoke the certificate. The server SHOULD consider at least = the following accounts authorized for a given certificate: ... an account that holds authorizations for all of t= he identifiers in the certificate."

One way to address this issue would be to replace "all" with &quo= t;any". That is, allow an account holding authorization for an identif= ier to revoke any certificate issued for that identifier, even if the certi= ficate is also valid for other identifiers.

Conceptually, I think this makes sense: the purpose of challenges is to ver= ify that the an account is authorized for an identifier only if the account= holder is in control of the identifier, and if the account holder is in co= ntrol of the identifier, they should be able to revoke certificates issued for that identifier.

This does, obviously, have consequences on the security model:
 * Currently, an attacker which gains control of an identifier is able= to create or revoke certificates issued for only that identifier. With thi= s change, they would also be able to revoke multi-identifier certificates w= hich include the identifier they have gained control of.
 * This successfully reduces the impact of account key compromise; if = an attacker gains control of an account key, any certificates they create c= an be revoked.
 * This also addresses an additional issue: if an identifier changes o= wnership, the new owner can revoke existing certificates for that identifie= r, including multi-identifier certificates.

This would, essentially, be prioritizing confidentiality of each identifier= over availability of all identifiers on a multi-identifier certificate. By= creating a multi-identifier certificate, users would be "opting in&qu= ot; to this trade-off. To me, this seems like a reasonable trade-off (especially because com= promise of an identifier is already catastrophic), but perhaps there are us= e cases for multi-identifier certificates that I'm not considering.<= br>
This seems to have minimal impact on the protocol as well as both client an= d server implementations.

Regards,

Zach Shepherd


From: Acme <acme-bounc= es@ietf.org> on behalf of Roland Shoemaker <roland@letsencrypt.org>= ;
Sent: Wednesday, March 22, 2017 2:08 PM
To: acme@ietf.org; Salz, Rich; Ted Hardie
Subject: [Acme] Possible IETF meeting agenda item: reducing effects = of key-compromise
 
Internally at LE we have been having discussions a= round how the spec can
most effectively reduce the harm of account key compromise and it seems
like it could be a good topic to bring up at the upcoming IETF meeting.

We've come up with two distinct but not mutually exclusive ideas on this topic:

* Deactivating authorizations on key roll-over, summarized here:
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_ma= il-2Darchive_web_acme_current_msg01747.html&d=3DDwICAg&c=3DuilaK90D= 4TOVoH58JNXRgQ&r=3DZ9jmRNJFc0_mrYgZ7k4FWDuC1AsqA1UJKUYIM6ZnnNk&m=3D= BmiI-FcQEZIzAmQ9cl9VVp_QYsKukJB0PtSfizZuYdY&s=3DiGd1H6LLa6yZ1eailcLMJAa= tf_sYvR9g1BIAcBmsQig&e=3D
* Only allowing a single valid authorization per name to exist at the
same time, summarized here:
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_ma= il-2Darchive_web_acme_current_msg01661.html&d=3DDwICAg&c=3DuilaK90D= 4TOVoH58JNXRgQ&r=3DZ9jmRNJFc0_mrYgZ7k4FWDuC1AsqA1UJKUYIM6ZnnNk&m=3D= BmiI-FcQEZIzAmQ9cl9VVp_QYsKukJB0PtSfizZuYdY&s=3DUbH6UN-99PK6TbADeVA6J3Y= vf72wYVyKd7NoK5IKNEk&e=3D

Both of these proposals would be relatively large changes to the current follow and introduce certain issues for both individual users and large
service integrators and could definitely use some public discussion
before the spec is finalized.

It would also be good to hear if there are any other thoughts from other implementors/contributors as to how we can best reduce the damage done
by key compromise in general.

--
Roland Bracewell Shoemaker
Software Engineer
Linux Foundation / Internet Security Research Group

_______________________________________________
Acme mailing list
Acme@ietf.org
https://urldefense= .proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_acme&= ;d=3DDwICAg&c=3DuilaK90D4TOVoH58JNXRgQ&r=3DZ9jmRNJFc0_mrYgZ7k4FWDuC= 1AsqA1UJKUYIM6ZnnNk&m=3DBmiI-FcQEZIzAmQ9cl9VVp_QYsKukJB0PtSfizZuYdY&= ;s=3DDIKow_UF52PW12xZNcT5yhSFtlsjhnjM4W1wNPgMOvc&e=3D
--_000_CY4PR05MB30454C4D983985EFF2E631E5C03F0CY4PR05MB3045namp_-- From nobody Thu Mar 23 10:34: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 17DB3129AA3 for ; Thu, 23 Mar 2017 10:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.707 X-Spam-Level: X-Spam-Status: No, score=-2.707 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, RCVD_IN_MSPIKE_H2=-2.796, 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=onevmw.onmicrosoft.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 ZWpe__EcyhGs for ; Thu, 23 Mar 2017 10:34:31 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0076.outbound.protection.outlook.com [104.47.37.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81372129A67 for ; Thu, 23 Mar 2017 10:34:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onevmw.onmicrosoft.com; s=selector1-vmware-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=KrOKC7jcLxgLTku4VpTC6jNapFT7gzJrhk5VF4iLL1M=; b=C2gveY6mpqv0We1GjP0VShDQhbX+bOg+gQq8th4lT0ZjLGadXxhoYQPCQG9FBzu0wmHMTD/kIsLCFJ8gBkgjIhKPdGENpnt/Lgklvn5Np3Z4gkamP4WiHspCsoDbhYbCa+nnpytf84BwB+tTOn8hOLmD+2+FT7wFak/ZIYuU8D8= Received: from CY4PR05MB3045.namprd05.prod.outlook.com (10.172.155.135) by CY4PR05MB3045.namprd05.prod.outlook.com (10.172.155.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4; Thu, 23 Mar 2017 17:34:28 +0000 Received: from CY4PR05MB3045.namprd05.prod.outlook.com ([10.172.155.135]) by CY4PR05MB3045.namprd05.prod.outlook.com ([10.172.155.135]) with mapi id 15.01.0991.017; Thu, 23 Mar 2017 17:34:28 +0000 From: Zach Shepherd To: "cpu@letsencrypt.org" , "acme@ietf.org" Thread-Topic: [Acme] Entropy requirement for challenge token Thread-Index: AQHSosrwWAuBjkBA9EKmndMTvxHqPqGhHlSAgAGQn1c= Date: Thu, 23 Mar 2017 17:34:28 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: letsencrypt.org; dkim=none (message not signed) header.d=none; letsencrypt.org; dmarc=none action=none header.from=vmware.com; x-originating-ip: [25.173.128.132] x-microsoft-exchange-diagnostics: 1; CY4PR05MB3045; 7:JtSqleYtz3IylOcVYVqrIxNs+1RbDAikiJAEY8URaDW+1ClcO4A2Crc2/dcIK1Nw6d4luUw1PxMs1RXxMEc+oxOJH48QVR5wWXtDiQ0qWECcWIeZ0famonMx8mzo/kBFnW7UGrSMvFdakhHZR1FES9OnJq5P0Kg+ynT3BTQH65O0StGBvZQhiz58QmBE3KDk7BlhFKljX4EIC/SAsAHedESkKMmxbZ3Km3lXvwB+T9i/UrCkD+kwVWM5Fi0fqOb6m7RC7EUQ0HPxTbAywUzYUIgVoYsg2OrBvb1T0uftW7oPxCDTJKg+8vYvRTd7CvZs4APbtmUQ8wwtCVnQ9+NuzQ==; 20:J5PcBzOwy7FxhWmaBvEL6bdYonMQ9ZA5xM841g3oGCLra4RTuZoPLc2bKlIVwkILnvVGnGMJtGt5JYyqCV43af/6XeOvbeGr6OVN8QngTk936L9J3B9hEj9V9NfZkaXwge8iOHLLRYlF5oPQ4UkmPhWsQH4+HH4kSJqxCQR0nAw= x-ms-office365-filtering-correlation-id: 37e80c34-8e12-4253-7bf0-08d47212db9d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075); SRVR:CY4PR05MB3045; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(61668805478150)(158342451672863)(10436049006162)(166708455590820)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123560025)(20161123555025)(20161123558025)(20161123564025)(20161123562025)(6072148); SRVR:CY4PR05MB3045; BCL:0; PCL:0; RULEID:; SRVR:CY4PR05MB3045; x-forefront-prvs: 0255DF69B9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39410400002)(39830400002)(39450400003)(24454002)(377454003)(189998001)(50986999)(54356999)(76176999)(74316002)(19627405001)(77096006)(3846002)(2906002)(33656002)(7736002)(8936002)(6436002)(6506006)(7906003)(606005)(102836003)(8676002)(81166006)(53546009)(6116002)(25786009)(229853002)(2900100001)(53936002)(5660300001)(9686003)(6306002)(66066001)(3660700001)(54896002)(7696004)(2950100002)(6246003)(122556002)(236005)(38730400002)(55016002)(99286003)(6606003)(3280700002)(2501003)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR05MB3045; H:CY4PR05MB3045.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR05MB304570A2064DEBB09E3E44CEC03F0CY4PR05MB3045namp_" MIME-Version: 1.0 X-OriginatorOrg: vmware.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Mar 2017 17:34:28.3219 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR05MB3045 Archived-At: Subject: Re: [Acme] Entropy requirement for challenge token 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, 23 Mar 2017 17:34:35 -0000 --_000_CY4PR05MB304570A2064DEBB09E3E44CEC03F0CY4PR05MB3045namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It seems like the goal of this is to ensure that the ACME client is not abl= e to control (or, perhaps, even influence) the choice of token and requirin= g that the token be sufficiently random is one way to achieve this. This pr= events an attacker from "tricking" the ACME server into using a verificatio= n performed by the owner of an identifier as proof that the attacker contro= ls the identifier. Is this accurate? If so, it seems like some version of this explanation sho= uld be included in the Security Considerations section. ________________________________ From: Daniel McCarney Sent: Wednesday, March 22, 2017 10:30 AM To: Zach Shepherd Cc: acme@ietf.org Subject: Re: [Acme] Entropy requirement for challenge token Hi Zach, > This seems incongruous. If the token must be kept secret an attacker, it = should not be served via an unauthenticated channel. I agree the wording makes it incongruous, I was caught up on this the other= week until it was clarified for me by Jacob. The token is random not to prevent a guessing attack but to prevent the imp= lementation of a server that can automatically reply to challenges without = being a party to the authorization creation (e.g. knowing the token). It's = OK for the token to be served via an unauthenticated channel, it just can't= be predictable. I took a crack at rewording this in https://github.com/ietf-wg-acme/acme/pu= ll/284 - Hopefu= lly if I'm completely off-base someone can correct it to be accurate & unde= rstandable. On Wed, Mar 22, 2017 at 1:12 AM, Zach Shepherd > wrote: The following feedback is based on 8010a31 (current HEAD of master). Section 6.2, Request Authentication, states "Note that authentication via s= igned JWS request bodies implies that GET requests are not authenticated. S= ervers MUST NOT respond to GET requests for resources that might be conside= red sensitive. Account resources are the only sensitive resources defined i= n this specification." Sections 8.2, HTTP; 8.3, TLS with Server Name Indication (TLS SNI); and 8.4= , DNS, each describe a GET request and specify a "token" value which "MUST = have at least 128 bits of entropy, in order to prevent an attacker from gue= ssing it." This seems incongruous. If the token must be kept secret an attacker, it sh= ould not be served via an unauthenticated channel. Assuming secrecy of the token is not important, I would propose removing th= e entropy requirement and including some discussion of the token in Section= 10, Security Considerations. Regards, Zach Shepherd _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme --_000_CY4PR05MB304570A2064DEBB09E3E44CEC03F0CY4PR05MB3045namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

It seems like the goal of this is to ensure that the ACME client is not = able to control (or, perhaps, even influence) the choice of token and requiring that the token be sufficiently random is one way to achieve this= . This prevents an attacker from "tricking" the ACME server into using a verification perfor= med by the owner of an identifier as proof that the attacker controls the i= dentifier.


Is this accurate? If so, it seems like some version of this explanation = should be included in the Security Considerations section.


From: Daniel McCarney <= ;cpu@letsencrypt.org>
Sent: Wednesday, March 22, 2017 10:30 AM
To: Zach Shepherd
Cc: acme@ietf.org
Subject: Re: [Acme] Entropy requirement for challenge token
 
Hi Zach,

> This seems incongruous. If the token must be kept secret an attacker, = it should not be served via an unauthenticated channel.

I agree the wording makes it incongruous, I was caught up on this the other= week until it was clarified for me by Jacob.

The token is random not to prevent a guessing attack but to prevent the imp= lementation of a server that can automatically reply to challenges without = being a party to the authorization creation (e.g. knowing the token). It's = OK for the token to be served via an unauthenticated channel, it just can't be predictable.

I took a crack at rewording this in https://github= .com/ietf-wg-acme/acme/pull/284 - Hopefully if I'm completely off-base someone can correct it to be accura= te & understandable.

On Wed, Mar 22, 2017 at 1:12 AM, Zach Shepherd <= span dir=3D"ltr"> <shepherdz@vmw= are.com> wrote:

The following feedback is based on 8010a31 (current HEAD of master).
Section 6.2, Request Authentication, states "Note that authentication = via signed JWS request bodies implies that GET requests are not authenticat= ed. Servers MUST NOT respond to GET requests for resources that might be co= nsidered sensitive. Account resources are the only sensitive resources defined in this specification."

Sections 8.2, HTTP; 8.3, TLS with Server Name Indication (TLS SNI); and 8.4= , DNS, each describe a GET request and specify a "token" value wh= ich "MUST have at least 128 bits of entropy, in order to prevent an at= tacker from guessing it."

This seems incongruous. If the token must be kept secret an attacker, it sh= ould not be served via an unauthenticated channel.

Assuming secrecy of the token is not important, I would propose removing th= e entropy requirement and including some discussion of the token in Section= 10, Security Considerations.

Regards,
Zach Shepherd


_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mail= man/listinfo/acme


--_000_CY4PR05MB304570A2064DEBB09E3E44CEC03F0CY4PR05MB3045namp_-- From nobody Thu Mar 23 11:04:52 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 3EEA8129B49 for ; Thu, 23 Mar 2017 11:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 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, RCVD_IN_SORBS_SPAM=0.5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kelunik.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 drGFIFB4UUKX for ; Thu, 23 Mar 2017 11:04:48 -0700 (PDT) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::5]) (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 9741A127011 for ; Thu, 23 Mar 2017 11:04:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1490292286; l=6875; s=domk; d=kelunik.com; h=Content-Type:Cc:To:Subject:Date:From:References:In-Reply-To: MIME-Version; bh=nSbKzlFX42+hki4Gqkd3H6Gnlt4DLaMaChhcfEui2OQ=; b=vxsrIQT9W5zGlkoPcHs+30Cvi8JxgI3Q8nsZAcIBiPZUJJWy7pJ5FZl5gZTvOJdyKL 9lYXF0yrEPAkR35SGyjCCKDHIhBN6HK+yxlyLY8Ug7xT0yMusiKVqJYmB+RhFjLZ58Fi L8cb0DG7ozhddR2ANoKxIHA9Hz8qY5pt2EKv4= X-RZG-AUTH: :IWkkfkWkbvHsXQGmRYmUo9mls2vWuiu+7SLDup6E67mzuoBPBqD+ud8= X-RZG-CLASS-ID: mo00 Received: from mail-qk0-f169.google.com ([209.85.220.169]) by smtp.strato.de (RZmta 40.1 AUTH) with ESMTPSA id e0b5ddt2NI4jwRA (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp384r1 with 384 ECDH bits, eq. 7680 bits RSA)) (Client did not present a certificate) for ; Thu, 23 Mar 2017 19:04:45 +0100 (CET) Received: by mail-qk0-f169.google.com with SMTP id v127so187455575qkb.2 for ; Thu, 23 Mar 2017 11:04:45 -0700 (PDT) X-Gm-Message-State: AFeK/H2lJm7B5sdKXOF7RK29syALCsP5eDP6kApkMc7eK4LlHDc8W+mnLTh+TQT4bP+vZqzsKy+NQea+XBW7Kg== X-Received: by 10.55.81.193 with SMTP id f184mr2955418qkb.142.1490292285110; Thu, 23 Mar 2017 11:04:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.144.167 with HTTP; Thu, 23 Mar 2017 11:04:44 -0700 (PDT) In-Reply-To: References: From: Niklas Keller Date: Thu, 23 Mar 2017 19:04:44 +0100 X-Gmail-Original-Message-ID: Message-ID: To: Zach Shepherd Cc: Roland Shoemaker , "acme@ietf.org" , "Salz, Rich" , Ted Hardie Content-Type: multipart/alternative; boundary=001a114a8d8a440e8a054b69b6b1 Archived-At: Subject: Re: [Acme] Possible IETF meeting agenda item: reducing effects of key-compromise 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, 23 Mar 2017 18:04:51 -0000 --001a114a8d8a440e8a054b69b6b1 Content-Type: text/plain; charset=UTF-8 2017-03-23 18:11 GMT+01:00 Zach Shepherd : > Section 7.6, Certificate Revocation, states: "Before revoking a > certificate, the server MUST verify that the key used to sign the request > is authorized to revoke the certificate. The server SHOULD consider at > least the following accounts authorized for a given certificate: ... an > account that holds authorizations for all of the identifiers in the > certificate." > > One way to address this issue would be to replace "all" with "any". That > is, allow an account holding authorization for an identifier to revoke any > certificate issued for that identifier, even if the certificate is also > valid for other identifiers. > > Conceptually, I think this makes sense: the purpose of challenges is to > verify that the an account is authorized for an identifier only if the > account holder is in control of the identifier, and if the account holder > is in control of the identifier, they should be able to revoke certificates > issued for that identifier. > > This does, obviously, have consequences on the security model: > * Currently, an attacker which gains control of an identifier is able to > create or revoke certificates issued for only that identifier. With this > change, they would also be able to revoke multi-identifier certificates > which include the identifier they have gained control of. > * This successfully reduces the impact of account key compromise; if an > attacker gains control of an account key, any certificates they create can > be revoked. > * This also addresses an additional issue: if an identifier changes > ownership, the new owner can revoke existing certificates for that > identifier, including multi-identifier certificates. > > This would, essentially, be prioritizing confidentiality of each > identifier over availability of all identifiers on a multi-identifier > certificate. By creating a multi-identifier certificate, users would be > "opting in" to this trade-off. To me, this seems like a reasonable > trade-off (especially because compromise of an identifier is already > catastrophic), but perhaps there are use cases for multi-identifier > certificates that I'm not considering. > > This seems to have minimal impact on the protocol as well as both client > and server implementations. > > Regards, > > Zach Shepherd > This might be problematic for services like Cloudflare which use one certificate for multiple customers. One of them might authorize for their own domain as well and could then revoke the Cloudflare certificate, affecting multiple customers. On the other hand, requiring all identifiers to be authorized could result in an attacker with a compromised key to request a certificate with additional SANs which the original owner doesn't have any control of, then it's impossible for the original owner to revoke these. Regards, Niklas --001a114a8d8a440e8a054b69b6b1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
2017= -03-23 18:11 GMT+01:00 Zach Shepherd <shepherdz@vmware.com>:

Section 7.6, Certificate Revocation, states: "Before revoking a c= ertificate, the server MUST verify that the key used to sign the request is= authorized to revoke the certificate. The server SHOULD consider at least = the following accounts authorized for a given certificate: ... an account that holds authorizations for all of t= he identifiers in the certificate."

One way to address this issue would be to replace "all" with &quo= t;any". That is, allow an account holding authorization for an identif= ier to revoke any certificate issued for that identifier, even if the certi= ficate is also valid for other identifiers.

Conceptually, I think this makes sense: the purpose of challenges is to ver= ify that the an account is authorized for an identifier only if the account= holder is in control of the identifier, and if the account holder is in co= ntrol of the identifier, they should be able to revoke certificates issued for that identifier.

This does, obviously, have consequences on the security model:
=C2=A0* Currently, an attacker which gains control of an identifier is able= to create or revoke certificates issued for only that identifier. With thi= s change, they would also be able to revoke multi-identifier certificates w= hich include the identifier they have gained control of.
=C2=A0* This successfully reduces the impact of account key compromise; if = an attacker gains control of an account key, any certificates they create c= an be revoked.
=C2=A0* This also addresses an additional issue: if an identifier changes o= wnership, the new owner can revoke existing certificates for that identifie= r, including multi-identifier certificates.

This would, essentially, be prioritizing confidentiality of each identifier= over availability of all identifiers on a multi-identifier certificate. By= creating a multi-identifier certificate, users would be "opting in&qu= ot; to this trade-off. To me, this seems like a reasonable trade-off (especially because com= promise of an identifier is already catastrophic), but perhaps there are us= e cases for multi-identifier certificates that I'm not considering.

This seems to have minimal impact on the protocol as well as both client an= d server implementations.

Regards,

Zach Shepherd


This might= be problematic for services like Cloudflare which use one certificate for = multiple customers. One of them might authorize for their own domain as wel= l and could then revoke the Cloudflare certificate, affecting multiple cust= omers.

On the other hand, requiring all identifier= s to be authorized could result in an attacker with a compromised key to re= quest a certificate with additional SANs which the original owner doesn'= ;t have any control of, then it's impossible for the original owner to = revoke these.

Regards, Niklas =C2=A0
--001a114a8d8a440e8a054b69b6b1-- From nobody Thu Mar 23 11:06: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 E3027129B1B for ; Thu, 23 Mar 2017 11:06:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.069 X-Spam-Level: X-Spam-Status: No, score=0.069 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=onevmw.onmicrosoft.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 MuzDBv710CoO for ; Thu, 23 Mar 2017 11:06:05 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0065.outbound.protection.outlook.com [104.47.34.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31807129B08 for ; Thu, 23 Mar 2017 11:06:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onevmw.onmicrosoft.com; s=selector1-vmware-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=iEb8futIZ/LX/FxkCNLy7l5xyAafV7nznHH8XcelSHQ=; b=bIknGaAEC7cKAT8SJyJY4HtG/P5DjcUq7tx31wJ6wYObDrSICgfg6koiA/vlgJeP5YxcG3BQhO++LA2+4yzneOOMyBdxb07EfiFYWjg9uTx7KEANjO0ooy6rtXicihKZKxK3tG8W3WBs0EAq2fsTqiBBcW4R+ZJwNbKIYbd130E= Received: from CY4PR05MB3045.namprd05.prod.outlook.com (10.172.155.135) by CY4PR05MB3046.namprd05.prod.outlook.com (10.172.155.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4; Thu, 23 Mar 2017 18:06:04 +0000 Received: from CY4PR05MB3045.namprd05.prod.outlook.com ([10.172.155.135]) by CY4PR05MB3045.namprd05.prod.outlook.com ([10.172.155.135]) with mapi id 15.01.0991.017; Thu, 23 Mar 2017 18:06:04 +0000 From: Zach Shepherd To: "cpu@letsencrypt.org" CC: "acme@ietf.org" Thread-Topic: [Acme] Allowing clients to understand the account creation functionality supported by a server Thread-Index: AQHSossDe/ZDvpfKg0uDSiRpCfMQs6GhIfGAgAASDb4= Date: Thu, 23 Mar 2017 18:06:04 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=vmware.com; x-originating-ip: [25.173.128.132] x-microsoft-exchange-diagnostics: 1; CY4PR05MB3046; 7:BR7agA/8QNFWvpxGno7XI83A1/8sVxtIbAw9nxLoOfNJdwlxtAQYYVOm6nWebDlJ5VxkBrVT+dIt2b8s4u2eYME70qc54VRQoDxoidMQeAKrdUy1T/aen69p7lowN5ZzEh4Lwgrkn4VE+6oWGKpY1VvHzYtWFzIY1zFQT+kB+vWVUHTBk64BKlT0wGNl+CXzmG/r9zV384v+1TqKwsQNAHUpGwHt1bBJgY4FxfOd3b6z8GPz6AuWKyVkWt9v5TgEPH52wn6g5F0eDqck4Y7O4DjZl9pBOAgFYsQXyYOHWGRM68J09AuMltZKQ+i+YhlKMcH/Vw045IaYXuM+kzPD1w==; 20:+wSJ0YiFZT2+EpyXE57YYIeNCUSlBnvIlrM8ttenctvpQK1DEYOO8YFi4nn316hgmgvOl3J5iivHwZb1l5p3XFqpidQHS1KtZHH2R4ufgE0lh6CUHTBKEdaWZhGxBNpcr6BerxEbiVo0Z3J4OBPZPMG6evx4PYoZr8eDDYKJP/M= x-ms-office365-filtering-correlation-id: 9c4ada11-eaa6-4b02-a522-08d472174581 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075); SRVR:CY4PR05MB3046; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(61668805478150)(158342451672863)(10436049006162)(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123564025)(20161123558025)(20161123555025)(20161123562025)(20161123560025)(6072148); SRVR:CY4PR05MB3046; BCL:0; PCL:0; RULEID:; SRVR:CY4PR05MB3046; x-forefront-prvs: 0255DF69B9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39830400002)(39450400003)(39410400002)(377454003)(24454002)(8676002)(1730700003)(8936002)(3660700001)(7696004)(81166006)(6116002)(2906002)(3280700002)(53546009)(102836003)(25786009)(3846002)(74316002)(2351001)(6916009)(6606003)(2950100002)(5660300001)(7736002)(7906003)(19627405001)(76176999)(54356999)(6436002)(9686003)(6306002)(236005)(5640700003)(55016002)(99286003)(77096006)(606005)(122556002)(54896002)(4326008)(50986999)(86362001)(2900100001)(15650500001)(33656002)(66066001)(110136004)(189998001)(2501003)(38730400002)(6246003)(6506006)(53936002)(229853002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR05MB3046; H:CY4PR05MB3045.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR05MB304570B42812A527D87A4D65C03C0CY4PR05MB3045namp_" MIME-Version: 1.0 X-OriginatorOrg: vmware.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Mar 2017 18:06:04.0389 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR05MB3046 Archived-At: Subject: Re: [Acme] Allowing clients to understand the account creation functionality supported by a server 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, 23 Mar 2017 18:06:09 -0000 --_000_CY4PR05MB304570B42812A527D87A4D65C03C0CY4PR05MB3045namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Let's consider a simple world where all ACME servers support mailto and som= e ACME servers support tel. To create an account, the user provides the necessary information to their = AMCE client: one or more email addresses and zero or more phone numbers. Th= e ACME client then attempts to supply all of this information to in an acco= unt creation request. Some of the time, this will result in an error becaus= e the ACME server does not support tel. When the ACME client receives this error, it could: 1. Display it to the user and ask the user to adjust their input accordingl= y. (A poor user experience.) 2. Attempt to parse to the error message to confirm that the problem was th= e tel. (Hacky.) 3. Assume that the problem was the tel and retry without that. (Very hacky.= ) A new ACME server could come along that requires at least one tel or that d= oesn't support mailto. As a result, ACME clients may chose to attempt #2 an= d/or #3 before falling back to #1. This means that ACME clients have one of six different behaviors (#1, #2, #= 3, #2 falling back to #1, #3 falling back to #1, #2 falling back to #3 fall= ing back to #1), some of which add a non-trivial amount of complexity to at= tempt to parse error messages (yuck.) and some of which end up pushing the = complexity onto the end-user in end anyways. (Or worse, ACME clients wind u= p with hard-coded assumptions based on a specific ACME server implementatio= n and become less portable.) Providing information about the supported contact schemes in a machine read= able format (e.g., in response to a GET requests on the server's new-accoun= t URI) does add work for ACME server implementors, but not so much that it'= s worth complicating the end-user experience. Regards, Zach ________________________________ From: Daniel McCarney Sent: Wednesday, March 22, 2017 10:43 AM To: Zach Shepherd Cc: acme@ietf.org Subject: Re: [Acme] Allowing clients to understand the account creation fun= ctionality supported by a server Hi Zach, > It is undesirable that a client can only determine the supported schemes = for contact URLs by attempting to submit an unsupported URL. This makes it = difficult to implement a general-purpose client which can work with a varie= ty of servers which might each support a different set of contact schemes. I feel your pain, but I'm hesitant to see more metadata/complexity put into= the /directory (I think the "meta" field of the directory resource would b= e the best place if anywhere). My gut says it will be unlikely many servers= will allow contact URLs outside of "mailto:" and "tel:" and it seems reaso= nably easy to handle the unsupported contact type error. For the account fi= elds we'd be adding complexity to simplify UI and I'm not convinced yet its= justified. Another note: If consensus is that we need a machine-readable way for clien= ts to know ahead of time what contact methods & account fields a server sup= ports we should also give the same consideration to identifier types for Se= ction 7.4.1's Pre-Authorization mechanism. A client may want to know what t= ypes of identifiers a server would pre-authorize. On Wed, Mar 22, 2017 at 1:13 AM, Zach Shepherd > wrote: The following feedback is based on 8010a31 (current HEAD of master). Section 7.3, Account Creation, states "The server SHOULD validate that the = contact URLs in the =93contact=94 field are valid and supported by the serv= er. If the client provides the server with an invalid or unsupported contac= t URL, then the server MUST return an error of type =93invalidContact=94, w= ith a description describing the error and what types of contact URL the se= rver considers acceptable." It is undesirable that a client can only determine the supported schemes fo= r contact URLs by attempting to submit an unsupported URL. This makes it di= fficult to implement a general-purpose client which can work with a variety= of servers which might each support a different set of contact schemes. I would propose including information about the supported contact schemes i= n a machine readable format as a part of some GET request. Section 7.3, Account Creation, also states "A client creates a new account = with the server by sending a POST request to the server=92s new-account URI= . The body of the request is a stub account object containing the =93contac= t=94 field and optionally the =93terms-of-service-agreed=94 field. ... The = server MUST ignore any values provided in the =93orders=94 fields in accoun= t bodies sent by the client, as well as any other fields that it does not r= ecognize. If new fields are specified in the future, the specification of t= hose fields MUST describe whether they can be provided by the client." Similarly, it would be beneficial for a client to be able to determine the = set of fields that a server does recognize so that it does not prompt the u= ser for information which the server will not make use of. I would propose including information about the fields which may be specifi= ed as a part of account creation in a machine readable format as a part of = some GET request. Together, these proposals could be addressed by responding to GET requests = on the server's new-account URI with an object describing the client-specif= iable account creation fields and applicable restrictions on each, such as = the supported schemes for contacts URLs. Regards, Zach Shepherd _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme --_000_CY4PR05MB304570B42812A527D87A4D65C03C0CY4PR05MB3045namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Let's consider a simple world where all ACME servers support mailto an= d some ACME servers support tel.

To create an account, the user provides the necessary information to their = AMCE client: one or more email addresses and zero or more phone numbers. Th= e ACME client then attempts to supply all of this information to in an acco= unt creation request. Some of the time, this will result in an error because the ACME server does not suppor= t tel.

When the ACME client receives this error, it could:
1. Display it to the user and ask the user to adjust their input accordingl= y. (A poor user experience.)
2. Attempt to parse to the error message to confirm that the problem was th= e tel. (Hacky.)
3. Assume that the problem was the tel and retry without that. (Very hacky.= )

A new ACME server could come along that requires at least one tel or that d= oesn't support mailto. As a result, ACME clients may chose to attempt #2 an= d/or #3 before falling back to #1.

This means that ACME clients have one of six different behaviors (#1, #2, #= 3, #2 falling back to #1, #3 falling back to #1, #2 falling back to #3 fall= ing back to #1), some of which add a non-trivial amount of complexity to at= tempt to parse error messages (yuck.) and some of which end up pushing the complexity onto the end-user in end a= nyways. (Or worse, ACME clients wind up with hard-coded assumptions based o= n a specific ACME server implementation and become less portable.)

Providing information about the supported contact schemes in a machine read= able format (e.g., in response to a GET requests on the server's new-accoun= t URI) does add work for ACME server implementors, but not so much that it'= s worth complicating the end-user experience.

Regards,
Zach

From: Daniel McCarney <= ;cpu@letsencrypt.org>
Sent: Wednesday, March 22, 2017 10:43 AM
To: Zach Shepherd
Cc: acme@ietf.org
Subject: Re: [Acme] Allowing clients to understand the account creat= ion functionality supported by a server
 
Hi Zach,

> It is undesirable that a client can only determine the supported schem= es for contact URLs by attempting to submit an unsupported URL. This makes = it difficult to implement a general-purpose client which can work with a va= riety of servers which might each support a different set of contact schemes.

I feel your pain, but I'm hesitant to see more metadata/complexity put into= the /directory (I think the "meta" field of the directory resour= ce would be the best place if anywhere). My gut says it will be unlike= ly many servers will allow contact URLs outside of "mailto:" and "tel:" and it seems reasonably easy t= o handle the unsupported contact type error. For the account fields we'd be= adding complexity to simplify UI and I'm not convinced yet its justified.<= br>
Another note: If consensus is that we need a machine-readable way for clien= ts to know ahead of time what contact methods & account fields a server= supports we should also give the same consideration to identifier types fo= r Section 7.4.1's Pre-Authorization mechanism. A client may want to know what types of identifiers a server wo= uld pre-authorize.

On Wed, Mar 22, 2017 at 1:13 AM, Zach Shepherd <= span dir=3D"ltr"> <shepherdz@vmw= are.com> wrote:

The following feedback is based on 8010a31 (current HEAD of master).
Section 7.3, Account Creation, states "The server SHOULD validate that= the contact URLs in the =93contact=94 field are valid and supported by the= server. If the client provides the server with an invalid or unsupported c= ontact URL, then the server MUST return an error of type =93invalidContact=94, with a description describing the erro= r and what types of contact URL the server considers acceptable."

It is undesirable that a client can only determine the supported schemes fo= r contact URLs by attempting to submit an unsupported URL. This makes it di= fficult to implement a general-purpose client which can work with a variety= of servers which might each support a different set of contact schemes.

I would propose including information about the supported contact schemes i= n a machine readable format as a part of some GET request.


Section 7.3, Account Creation, also states "A client creates a new acc= ount with the server by sending a POST request to the server=92s new-accoun= t URI. The body of the request is a stub account object containing the =93c= ontact=94 field and optionally the =93terms-of-service-agreed=94 field. ... The server MUST ignore any values provided in the =93orders=94 = fields in account bodies sent by the client, as well as any other fields th= at it does not recognize. If new fields are specified in the future, the sp= ecification of those fields MUST describe whether they can be provided by the client."

Similarly, it would be beneficial for a client to be able to determine the = set of fields that a server does recognize so that it does not prompt the u= ser for information which the server will not make use of.

I would propose including information about the fields which may be specifi= ed as a part of account creation in a machine readable format as a part of = some GET request.


Together, these proposals could be addressed by responding to GET requests = on the server's new-account URI with an object describing the client-specif= iable account creation fields and applicable restrictions on each, such as = the supported schemes for contacts URLs.

Regards,
Zach Shepherd


_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mail= man/listinfo/acme


--_000_CY4PR05MB304570B42812A527D87A4D65C03C0CY4PR05MB3045namp_-- From nobody Thu Mar 23 11:41: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 C6F17128792 for ; Thu, 23 Mar 2017 11:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.069 X-Spam-Level: X-Spam-Status: No, score=0.069 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=onevmw.onmicrosoft.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 dcEMAMzagUIZ for ; Thu, 23 Mar 2017 11:41:26 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0087.outbound.protection.outlook.com [104.47.33.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A14B1294E8 for ; Thu, 23 Mar 2017 11:41:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onevmw.onmicrosoft.com; s=selector1-vmware-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Wp3V+byApq67w77DmkRFkSIHRd6RZmoEXMRVFfaiGFQ=; b=GRmN9oKhCNG/2KbArU223h/6x2unGvs39LJLXggVWItLUU/m0sKvXrlpxpvf4I9OSc4jwKM7Jp+hF1QAGLQv7dARip7K7S/Ht1MguK0gg/q5sGGzw1oni/iWpuqLzS8y3+DG9xm2CNpGqwXWMnTZ1OaYZ9LgOKWxf+2Jr9pHW+c= Received: from CY4PR05MB3045.namprd05.prod.outlook.com (10.172.155.135) by CY4PR05MB3048.namprd05.prod.outlook.com (10.172.156.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4; Thu, 23 Mar 2017 18:41:23 +0000 Received: from CY4PR05MB3045.namprd05.prod.outlook.com ([10.172.155.135]) by CY4PR05MB3045.namprd05.prod.outlook.com ([10.172.155.135]) with mapi id 15.01.0991.017; Thu, 23 Mar 2017 18:41:23 +0000 From: Zach Shepherd To: "acme@ietf.org" CC: "cpu@letsencrypt.org" , Jacob Hoffman-Andrews Thread-Topic: [Acme] Use of "shortly" in normative language of Section 7.4, Applying for Certificate Issuance Thread-Index: AQHSossyXOSrxuUNyk6P1Tz/VfaYiaGhECEAgAAJooCAABeJI4AABLgAgAGOQPY= Date: Thu, 23 Mar 2017 18:41:23 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: letsencrypt.org; dkim=none (message not signed) header.d=none; letsencrypt.org; dmarc=none action=none header.from=vmware.com; x-originating-ip: [25.173.128.132] x-microsoft-exchange-diagnostics: 1; CY4PR05MB3048; 7:4KUZW8RV4eeHaf7yY6r9HY2Vd/1yxVTPpZwWfihl/kSnBjjiMEo9EZxw+IKf2+GctNem/ex6v63x3Mrmr0U6I4KMtTh3H2xradLaTewnExdQrLG+lwZ7JrmMhtuDdAkUh6kNW/c6ZYbBDh4AEIn1dfmfrW8qhYxaAlhZ6+N5LvnjjHKayjNeLH9Hvj/SQI3OrDazMJFO9B0JD/t89fMZeuuO0nl5MOXmgou68mnqxqRuYX4vQf9nLAaVdmrQ6wu/NA54iDbrG4mWV+bQO6dX73w/dm4hE1Phy7FigE81w5kmMDW2y98Kj1EuWykVvgr2XbDfH6J2iCyRAPL1KtAs3A==; 20:X7YwF9e1uGep7dSaRBl5v4ACHqEd9DHNObBqHP5SP+PD9CeRumx1JuRqjMPBAmouDrp8oUgpvwmJrahtwAeyI0pJAGt+vW5reiUUncWtO/gmWZo+V+uOD7RuqhapCSOmQzBg8m0CGVG+8vGKorBvtffRsl82jcTtvcr/vh2nLNg= x-ms-office365-filtering-correlation-id: 546523ee-fbe1-4757-9e57-08d4721c34aa x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075); SRVR:CY4PR05MB3048; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(61668805478150)(158342451672863)(10436049006162)(166708455590820); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123562025)(20161123560025)(20161123558025)(20161123555025)(20161123564025)(6072148); SRVR:CY4PR05MB3048; BCL:0; PCL:0; RULEID:; SRVR:CY4PR05MB3048; x-forefront-prvs: 0255DF69B9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39410400002)(39450400003)(39830400002)(24454002)(51914003)(377454003)(19627405001)(2351001)(122556002)(2501003)(3280700002)(2906002)(33656002)(53546009)(3660700001)(7736002)(50986999)(25786009)(6606003)(7696004)(3846002)(93886004)(76176999)(5660300001)(7906003)(6116002)(54356999)(102836003)(2950100002)(6916009)(6246003)(66066001)(54906002)(236005)(189998001)(5640700003)(99286003)(55016002)(6306002)(54896002)(229853002)(9686003)(86362001)(110136004)(4326008)(38730400002)(575784001)(8676002)(81166006)(1730700003)(74316002)(8936002)(6436002)(6506006)(77096006)(2900100001)(606005)(53936002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR05MB3048; H:CY4PR05MB3045.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR05MB3045AC1DA2355880257AF2A1C03F0CY4PR05MB3045namp_" MIME-Version: 1.0 X-OriginatorOrg: vmware.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Mar 2017 18:41:23.2388 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR05MB3048 Archived-At: Subject: Re: [Acme] Use of "shortly" in normative language of Section 7.4, Applying for Certificate 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, 23 Mar 2017 18:41:30 -0000 --_000_CY4PR05MB3045AC1DA2355880257AF2A1C03F0CY4PR05MB3045namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I've submitted a PR for this change: https://github.com/ietf-wg-acme/acme/p= ull/286 Regards, Zach ________________________________ From: Daniel McCarney Sent: Wednesday, March 22, 2017 11:54 AM To: Zach Shepherd Cc: Jacob Hoffman-Andrews; acme@ietf.org Subject: Re: [Acme] Use of "shortly" in normative language of Section 7.4, = Applying for Certificate Issuance +1 for "MUST begin the issuance process" - thanks for the suggestion Jacob. On Wed, Mar 22, 2017 at 2:44 PM, Zach Shepherd > wrote: I think "MUST begin the issuance process" addresses my concerns and is in l= ine with the discussions around preferring "proactive" issuance. ________________________________ From: Jacob Hoffman-Andrews > Sent: Wednesday, March 22, 2017 10:13 AM To: cpu@letsencrypt.org; Zach Shepherd Cc: acme@ietf.org Subject: Re: [Acme] Use of "shortly" in normative language of Section 7.4, = Applying for Certificate Issuance We could say "MUST begin the issuance process" The main things on my mind that could delay issuance slightly: - Submitting to CT - Checking CAA - Internal queuing for available capacity - Manual vetting I think "MUST begin" covers for all of those, while allowing some vagueness= as to how long they will take. On 03/22/2017 09:39 AM, Daniel McCarney wrote: Hi Zach, For background I think this MUST originated out of this thread: https://mai= larchive.ietf.org/arch/msg/acme/0lVmGl8e-rmSH0x7ycDW5dj6GAY I would prefer option A) as well. It seems better to clear up the non-norma= tive language than to step backwards to a place where proactive issuance ma= y or may not happen without a clear signalling to the client of which a ser= ver will do. I think the use of "shortly" here is to allow the server some grace to dete= rmine that the order is completed and issuance can be performed. Perhaps we could change the language to say "The server MUST issue the requ= ested certificate and update the order resource with a URL for the certific= ate after it has determined the client has fulfilled the server's requireme= nts" and not impose any specific mention of the time between the client com= pleting the challenges and the server noticing. Thoughts? On Wed, Mar 22, 2017 at 1:14 AM, Zach Shepherd > wrote: The following feedback is based on 8010a31 (current HEAD of master). Section 7.4, Applying for Certificate Issuance, states "The server MUST iss= ue the requested certificate and update the order resource with a URL for t= he certificate shortly after the client has fulfilled the server=92s requir= ements." Per RFC 2119 Section 6, the imperative MUST should be used with care and sp= aringly. The use of "shortly" in the above sentence is imprecise. It is not possible= for a server author to know, with confidence, that they are adhering to th= is requirement. It is not possible fore a client author to make design or i= mplementation decisions based on this requirement. I would propose either: a) Replacing "shortly" with a more precise expectation. b) Replacing "MUST" with "should". I believe there are advantages for setting expectations as to the turn-arou= nd time for certificate issuance and would therefore prefer option (a), ass= uming agreement could be reached on more precise language. Regards, Zach Shepherd _______________________________________________ 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 --_000_CY4PR05MB3045AC1DA2355880257AF2A1C03F0CY4PR05MB3045namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

I've submitted a PR for this change: https://github.com/ietf-wg-acme/acme/pull/286


Regards,

Zach


From: Daniel McCarney <= ;cpu@letsencrypt.org>
Sent: Wednesday, March 22, 2017 11:54 AM
To: Zach Shepherd
Cc: Jacob Hoffman-Andrews; acme@ietf.org
Subject: Re: [Acme] Use of "shortly" in normative language= of Section 7.4, Applying for Certificate Issuance
 
+1 for "MUST begin the issuance process" - t= hanks for the suggestion Jacob.

On Wed, Mar 22, 2017 at 2:44 PM, Zach Shepherd <= span dir=3D"ltr"> <shepherdz@vmw= are.com> wrote:

I think "MUST begin the issuance process" addresses my concern= s and is in line with the discussions around preferring "proactiv= e" issuance.


From: = Jacob Hoffman-Andrews <jsha@eff.org>
Sent: Wednesday, March 22, 2017 10:13 AM
To: cpu@let= sencrypt.org; Zach Shepherd
Cc: acme@ietf.org=
Subject: Re: [Acme] Use of "shortly" in normative language= of Section 7.4, Applying for Certificate Issuance
 
We could say "MUST begin the issuance process"

The main things on my mind that could delay issuance slightly:
 - Submitting to CT
 - Checking CAA
 - Internal queuing for available capacity
 - Manual vetting

I think "MUST begin" covers for all of those, while allowing some= vagueness as to how long they will take.

On 03/22/2017 09:39 AM,= Daniel McCarney wrote:
Hi Zach,

For background I think this MUST originated out of this thread: https://mailarchive.= ietf.org/arch/msg/acme/0lVmGl8e-rmSH0x7ycDW5dj6GAY 

I would prefer option A) as well. It seems better to clear up the non-norma= tive language than to step backwards to a place where proactive issuance ma= y or may not happen without a clear signalling to the client of which a ser= ver will do.

I think the use of "shortly" here is to allow the server some gra= ce to determine that the order is completed and issuance can be performed.
Perhaps we could change the language to say "The server MUST issue the= requested certificate and update the order resource with a URL for the cer= tificate after it has determined the client has fulfilled the server's requ= irements" and not impose any specific mention of the time between the client completing the challenges and the s= erver noticing. Thoughts?

On Wed, Mar 22, 2017 at 1:14 AM, Zach Shepherd <= span dir=3D"ltr"> <shepherdz@vmw= are.com> wrote:
The following feedback is based on 8010a31 (current HEAD of master).
Section 7.4, Applying for Certificate Issuance, states "The server MUS= T issue the requested certificate and update the order resource with a URL = for the certificate shortly after the client has fulfilled the server=92s r= equirements."

Per RFC 2119 Section 6, the imperative MUST should be used with care and sp= aringly.

The use of "shortly" in the above sentence is imprecise. It is no= t possible for a server author to know, with confidence, that they are adhe= ring to this requirement. It is not possible fore a client author to make d= esign or implementation decisions based on this requirement.

I would propose either:
a) Replacing "shortly" with a more precise expectation.
b) Replacing "MUST" with "should".

I believe there are advantages for setting expectations as to the turn-arou= nd time for certificate issuance and would therefore prefer option (a), ass= uming agreement could be reached on more precise language.

Regards,
Zach Shepherd

_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mail= man/listinfo/acme



<= br> 
_______________________________________________=0A=
Acme mailing list=0A=
Acme@ietf.org=0A=
https://www.ietf.org/mailman/listinfo/acme=0A=


--_000_CY4PR05MB3045AC1DA2355880257AF2A1C03F0CY4PR05MB3045namp_-- From nobody Thu Mar 23 12:24: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 B9802131636 for ; Thu, 23 Mar 2017 12:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.808 X-Spam-Level: X-Spam-Status: No, score=-7.808 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_HI=-5, RCVD_IN_MSPIKE_H2=-2.796, 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 PtckA8x6rc1T for ; Thu, 23 Mar 2017 12:24:25 -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 41D0F131635 for ; Thu, 23 Mar 2017 12:24:22 -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:To:Subject; bh=uk0jpofCdv0OTTkXzjiMq8bXol86tvzLdT8Qht3V6bs=; b=2Y5BmHCI/QAdcGuLM13rNjxtb+NBkpOWL/HL7kCG56pWrt3YovTeW9DQ5VW2zrTnpiWcM5efBjkOyoQXPvHcB72iYNJ/DaJgC/e37WjQYpIS3aLtMgOfoXu1uYR5whGvAK3lnyZ1ABCGGpzvVKJJ9xD3KmX8z0nMmxjb0kOGhsY=; Received: ; Thu, 23 Mar 2017 12:24:21 -0700 To: Zach Shepherd , "cpu@letsencrypt.org" , "acme@ietf.org" References: From: Jacob Hoffman-Andrews Message-ID: Date: Thu, 23 Mar 2017 12:24:20 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------BD45211584D976AC5A955790" Archived-At: Subject: Re: [Acme] Entropy requirement for challenge token 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, 23 Mar 2017 19:24:33 -0000 This is a multi-part message in MIME format. --------------BD45211584D976AC5A955790 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Yep, I think there are two ways of thinking about this, though it's effectively a single problem: 1. Prevent attackers from tricking a validation endpoint into serving a valid challenge response. 2. Prevent ACME clients from implementing a "naive" validation method that would make (1) trivial. I think Daniel's change at https://github.com/ietf-wg-acme/acme/pull/284/files is a nice quick fix to the issue, but I agree it could use a few extra sentences explaining it in security considerations. On 03/23/2017 10:34 AM, Zach Shepherd wrote: > > It seems like the goal of this is to ensure that the ACME client is > not able to control (or, perhaps, even influence) the choice of token > and requiring that the token be sufficiently random is one way to > achieve this. This prevents an attacker from "tricking" the ACME > server into using a verification performed by the owner of an > identifier as proof that the attacker controls the identifier. > > > Is this accurate? If so, it seems like some version of this > explanation should be included in the Security Considerations section. > > > ------------------------------------------------------------------------ > *From:* Daniel McCarney > *Sent:* Wednesday, March 22, 2017 10:30 AM > *To:* Zach Shepherd > *Cc:* acme@ietf.org > *Subject:* Re: [Acme] Entropy requirement for challenge token > > Hi Zach, > > > This seems incongruous. If the token must be kept secret an > attacker, it should not be served via an unauthenticated channel. > > > I agree the wording makes it incongruous, I was caught up on this the > other week until it was clarified for me by Jacob. > > The token is random not to prevent a guessing attack but to prevent > the implementation of a server that can automatically reply to > challenges without being a party to the authorization creation (e.g. > knowing the token). It's OK for the token to be served via an > unauthenticated channel, it just can't be predictable. > > I took a crack at rewording this > in https://github.com/ietf-wg-acme/acme/pull/284 > > - Hopefully if I'm completely off-base someone can correct it to be > accurate & understandable. > > On Wed, Mar 22, 2017 at 1:12 AM, Zach Shepherd > wrote: > > The following feedback is based on 8010a31 (current HEAD of master). > > Section 6.2, Request Authentication, states "Note that > authentication via signed JWS request bodies implies that GET > requests are not authenticated. Servers MUST NOT respond to GET > requests for resources that might be considered sensitive. Account > resources are the only sensitive resources defined in this > specification." > > Sections 8.2, HTTP; 8.3, TLS with Server Name Indication (TLS > SNI); and 8.4, DNS, each describe a GET request and specify a > "token" value which "MUST have at least 128 bits of entropy, in > order to prevent an attacker from guessing it." > > This seems incongruous. If the token must be kept secret an > attacker, it should not be served via an unauthenticated channel. > > Assuming secrecy of the token is not important, I would propose > removing the entropy requirement and including some discussion of > the token in Section 10, Security Considerations. > > Regards, > Zach Shepherd > > > _______________________________________________ > 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 --------------BD45211584D976AC5A955790 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Yep, I think there are two ways of thinking about this, though it's effectively a single problem:

 1. Prevent attackers from tricking a validation endpoint into serving a valid challenge response.
 2. Prevent ACME clients from implementing a "naive" validation method that would make (1) trivial.

I think Daniel's change at https://github.com/ietf-wg-acme/acme/pull/284/files is a nice quick fix to the issue, but I agree it could use a few extra sentences explaining it in security considerations.

On 03/23/2017 10:34 AM, Zach Shepherd wrote:

It seems like the goal of this is to ensure that the ACME client is not able to control (or, perhaps, even influence) the choice of token and requiring that the token be sufficiently random is one way to achieve this. This prevents an attacker from "tricking" the ACME server into using a verification performed by the owner of an identifier as proof that the attacker controls the identifier.


Is this accurate? If so, it seems like some version of this explanation should be included in the Security Considerations section.


From: Daniel McCarney <cpu@letsencrypt.org>
Sent: Wednesday, March 22, 2017 10:30 AM
To: Zach Shepherd
Cc: acme@ietf.org
Subject: Re: [Acme] Entropy requirement for challenge token
 
Hi Zach,

> This seems incongruous. If the token must be kept secret an attacker, it should not be served via an unauthenticated channel.

I agree the wording makes it incongruous, I was caught up on this the other week until it was clarified for me by Jacob.

The token is random not to prevent a guessing attack but to prevent the implementation of a server that can automatically reply to challenges without being a party to the authorization creation (e.g. knowing the token). It's OK for the token to be served via an unauthenticated channel, it just can't be predictable.

I took a crack at rewording this in https://github.com/ietf-wg-acme/acme/pull/284 - Hopefully if I'm completely off-base someone can correct it to be accurate & understandable.

On Wed, Mar 22, 2017 at 1:12 AM, Zach Shepherd <shepherdz@vmware.com> wrote:
The following feedback is based on 8010a31 (current HEAD of master).

Section 6.2, Request Authentication, states "Note that authentication via signed JWS request bodies implies that GET requests are not authenticated. Servers MUST NOT respond to GET requests for resources that might be considered sensitive. Account resources are the only sensitive resources defined in this specification."

Sections 8.2, HTTP; 8.3, TLS with Server Name Indication (TLS SNI); and 8.4, DNS, each describe a GET request and specify a "token" value which "MUST have at least 128 bits of entropy, in order to prevent an attacker from guessing it."

This seems incongruous. If the token must be kept secret an attacker, it should not be served via an unauthenticated channel.

Assuming secrecy of the token is not important, I would propose removing the entropy requirement and including some discussion of the token in Section 10, Security Considerations.

Regards,
Zach Shepherd


_______________________________________________
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

--------------BD45211584D976AC5A955790-- From nobody Thu Mar 23 12:54: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 33D7D131636 for ; Thu, 23 Mar 2017 12:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.697 X-Spam-Level: X-Spam-Status: No, score=-4.697 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, RCVD_IN_MSPIKE_H2=-2.796, 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=onevmw.onmicrosoft.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 TTtWIKJkTa_F for ; Thu, 23 Mar 2017 12:54:26 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0054.outbound.protection.outlook.com [104.47.34.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F9D4129BB0 for ; Thu, 23 Mar 2017 12:54:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onevmw.onmicrosoft.com; s=selector1-vmware-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=TwHGELs9E1VGVoIAop3DW1omS3jgO83+IR/sNP0I8k8=; b=O2g9HMdyTdLePD64lWRFqYYi6NFuj4P+v3Vijjrk0qEAFWEEby0xsBWYsrSyGFFJbQPRHYsluGe8zG3yiPQ8nuB3ki1Y+CMVQB2COvhgmZEMkpmFa6OeTw2AguiGXQrShIuMniSp6hfEpLF36BqrQJKVMfaCAIDgA76ydJKGPtw= Received: from CY4PR05MB3045.namprd05.prod.outlook.com (10.172.155.135) by CY4PR05MB3046.namprd05.prod.outlook.com (10.172.155.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4; Thu, 23 Mar 2017 19:54:23 +0000 Received: from CY4PR05MB3045.namprd05.prod.outlook.com ([10.172.155.135]) by CY4PR05MB3045.namprd05.prod.outlook.com ([10.172.155.135]) with mapi id 15.01.0991.017; Thu, 23 Mar 2017 19:54:23 +0000 From: Zach Shepherd To: "acme@ietf.org" Thread-Topic: Consolidating API theory/principle/pattern information Thread-Index: AQHSpA7KfyyYOlhSn0mYXEPGrTWtIg== Date: Thu, 23 Mar 2017 19:54:23 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=vmware.com; x-originating-ip: [25.173.128.132] x-microsoft-exchange-diagnostics: 1; CY4PR05MB3046; 7:7iY0ZhLYvRzOTOFp9RQyDVcJNUwn0Z1ofMEewW/dLRCvlvVc/QfPBFuRyfJboCQFU6y0YBdxTPAJIubZxC/3YGiOyUNHA3kohdABLrjkUBTFf5P4ZD6qrJyO2lc0CrPOTJsoq7X6hc7r+RqoPgle1FoA9J8OI+7O1K1vtEwX10S906VYOSaqvm6Biqpe2GCBZ6ddB90cmyo5dLuSh5WTST4gN2odq43v5hA15+h7VSnNKCj9B+SIsJzkSOk6dzsA3ShcS/5dtBs+2kl1X622b4xy+i9p3Epm4s5vLg+M3UKWHpu8MKqc7u0yF87kOb17RHYjwlBjlDDEH9ujMqjDEw==; 20:AZMzCRQ1mNtsTNSwJeneDQ0JvHr+t5BPYuIzdfp6K3JXRU0150Q4yku/u2bzS9KR+YibYOy8eYNVUD/ISQ5LIyvFv9Zxh8rTvcU3e/OLHWokBtAguizUyYG4hIc9dfpDIOTvBCyaFRYfsUTYViaIzl1lKzZHgekCcCQyhCRufVg= x-ms-office365-filtering-correlation-id: 7b7f718d-f1be-4bf7-440c-08d4722667a6 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075); SRVR:CY4PR05MB3046; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123564025)(20161123555025)(20161123560025)(20161123558025)(20161123562025)(6072148); SRVR:CY4PR05MB3046; BCL:0; PCL:0; RULEID:; SRVR:CY4PR05MB3046; x-forefront-prvs: 0255DF69B9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39410400002)(39830400002)(39450400003)(2900100001)(86362001)(50986999)(54356999)(53336002)(77096006)(122556002)(54896002)(55016002)(6436002)(9686003)(5640700003)(99286003)(6506006)(2501003)(189998001)(38730400002)(53936002)(33656002)(66066001)(110136004)(25786009)(102836003)(3846002)(81166006)(6116002)(1730700003)(7696004)(8936002)(8676002)(3660700001)(3280700002)(2906002)(5660300001)(19627405001)(7736002)(74316002)(6606003)(6916009)(2351001); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR05MB3046; H:CY4PR05MB3045.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR05MB3045D2D84936024A8A9986BCC03F0CY4PR05MB3045namp_" MIME-Version: 1.0 X-OriginatorOrg: vmware.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Mar 2017 19:54:23.6923 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR05MB3046 Archived-At: Subject: [Acme] Consolidating API theory/principle/pattern information 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, 23 Mar 2017 19:54:29 -0000 --_000_CY4PR05MB3045D2D84936024A8A9986BCC03F0CY4PR05MB3045namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The following feedback is based on 5acf62b (current HEAD of master). Section 6, Message Transport, covers two distinct types of information: * Information about Message Transport. * High-level information about messages, but not their transport. Section 7, Certificate Management, also covers two distinct types of inform= ation: * Theory, guiding principles, and general patterns for the API. * Definition of the concrete Certificate Management APIs. I propose restructuring this document to extract a new section between Mess= age Transport and Certificate Management containing the non-transport infor= mation from the Message Transport section and theory/principle/pattern info= rmation from the Certificate Management section. This new section might contain subsections for: * Section 6.5, Rate limits * Section 6.6, Errors * The directory pattern and high-level information about the use of link re= lations from Section 7.1, Resources * The pagination pattern from Section 7.1.2.1, Orders List * The requirement from Section 7.3, Account Creation, that "In general, the= server MUST ignore any fields in the request object that it does not recog= nize." (Which seems related to the requirement from Section 7.5.1, Respondi= ng to Challenge, that "The server MUST ignore any fields in the response ob= ject that are not specified as response fields for this type of challenge."= ) * The polling pattern used in Sections 7.4 and 7.5.1 This would give the overall document a flow along the lines of: Overview, E= ncoding, Transport, [New Section], Management, Challenges. I believe this will improve the overall flow of the document, reduce duplic= ation, and ensure consistency. Separating this information out is especiall= y useful for ensuring that future extensions/additions/changes can easily r= efer to and follow existing theory/principles/patterns. Providing this info= rmation in its own section instead of in a "just in time" fashion is also u= seful for helping new readers build a correct mental model up front, before= diving into the Certificate Management information. I have chosen not to propose a name for this new section; I believe that it= would be hard to select an appropriate name without consensus on the scope= /content of the section. Regards, Zach Shepherd --_000_CY4PR05MB3045D2D84936024A8A9986BCC03F0CY4PR05MB3045namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

The following feedback is based on 5acf62b (current HEAD = of master).

Section 6, Message Transport, covers two distinct types of information:
* Information about Message Transport.
* High-level information about messages, but not their transport.

Section 7, Certificate Management, also covers two distinct types of inform= ation:
* Theory, guiding principles, and general patterns for the API.
* Definition of the concrete Certificate Management APIs.

I propose restructuring this document to extract a new section between Mess= age Transport and Certificate Management containing the non-transport infor= mation from the Message Transport section and theory/principle/pattern info= rmation from the Certificate Management section.

This new section might contain subsections for:
* Section 6.5, Rate limits
* Section 6.6, Errors
* The directory pattern and high-level information about the use of link re= lations from Section 7.1, Resources
* The pagination pattern from Section 7.1.2.1, Orders List
* The requirement from Section 7.3, Account Creation, that "In general= , the server MUST ignore any fields in the request object that it does not = recognize." (Which seems related to the requirement from Section 7.5.1= , Responding to Challenge, that "The server MUST ignore any fields in the response object that are not specified as re= sponse fields for this type of challenge.")
* The polling pattern used in Sections 7.4 and 7.5.1

This would give the overall document a flow along the lines of: Overvi= ew, Encoding, Transport, [New Section], Management, Challenges.

I believe this will improve the overall flow of the document, reduce = duplication, and ensure consistency. Separating this information out= is especially useful for ensuring that future extensions/additions/changes= can easily refer to and follow existing theory/principles/patterns. Providing this information in its own= section instead of in a "just in time" fashion is also useful fo= r helping new readers build a correct mental model up front, before diving = into the Certificate Management information.

I have chosen not to propose a name for this new section; I believe that it= would be hard to select an appropriate name without consensus on the scope= /content of the section.

Regards,
Zach Shepherd

--_000_CY4PR05MB3045D2D84936024A8A9986BCC03F0CY4PR05MB3045namp_-- From nobody Thu Mar 23 13:56: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 0657713166F for ; Thu, 23 Mar 2017 13:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.797 X-Spam-Level: X-Spam-Status: No, score=-9.797 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, RCVD_IN_MSPIKE_H2=-2.796, 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 WjfQdxNzTC4I for ; Thu, 23 Mar 2017 13:55: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 43D32129AA2 for ; Thu, 23 Mar 2017 13:55:58 -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:Cc:References:To:Subject; bh=Js8+QFBG32shLbcPq0xg9I8PuqfPVlJa1Z/5M7Kxz4g=; b=0cqjIK5PiYec6deHxs2sDWyjcKiWDZJQc/B8gow5vGU9PAhKHliEP5NTePQgX2pEdh25LUxgtQo0jBO/WUM1UodRoeLCGWUrGXNUTYqF1gZPGCHJkn6dw6vGsBV4HhNnUj9uDJiR996OdMPTeFWCTTD4jvLHW6Ayv3LUq/MJD4M=; Received: ; Thu, 23 Mar 2017 13:55:56 -0700 To: Niklas Keller , Zach Shepherd References: Cc: "Salz, Rich" , Ted Hardie , "acme@ietf.org" , Roland Shoemaker From: Jacob Hoffman-Andrews Message-ID: <79c93971-c9fb-4e37-4e90-63c137cfe1ef@eff.org> Date: Thu, 23 Mar 2017 13:55:54 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------BECD40761D588FA97A10287A" Archived-At: Subject: Re: [Acme] Possible IETF meeting agenda item: reducing effects of key-compromise 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, 23 Mar 2017 20:56:01 -0000 This is a multi-part message in MIME format. --------------BECD40761D588FA97A10287A Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I think Zach raises a really interesting point, and I think Niklas' response is spot on. To rephrase it a bit: If ACME allowed "any" hostname on a cert to revoke it, a multi-SAN certificate could be revoked by the owner of any domain name on that certificate. That would effectively prevent hosting providers and CDNs from using multi-SAN certificates with ACME, because it would allow one customer to revoke a certificate in active use by other customers. In theory this problem could be solved by using only single-SAN certificates, but since several hosting providers and CDNs are already using ACME successfully in a multi-SAN use case, that would be a step backwards. Probably it's best to just document this as an issue: An attacker who compromises a web server can request a cert for that web server's hostname, plus an attacker-controlled hostname, preventing automated revocation. In that case, the owner of the web server will need to rely on the CA's certificate problem reporting system to get the certificate revoked. Not ideal, but I don't see a lot of other choices. On 03/23/2017 11:04 AM, Niklas Keller wrote: > 2017-03-23 18:11 GMT+01:00 Zach Shepherd >: > > Section 7.6, Certificate Revocation, states: "Before revoking a > certificate, the server MUST verify that the key used to sign the > request is authorized to revoke the certificate. The server SHOULD > consider at least the following accounts authorized for a given > certificate: ... an account that holds authorizations for all of > the identifiers in the certificate." > > One way to address this issue would be to replace "all" with > "any". That is, allow an account holding authorization for an > identifier to revoke any certificate issued for that identifier, > even if the certificate is also valid for other identifiers. > > Conceptually, I think this makes sense: the purpose of challenges > is to verify that the an account is authorized for an identifier > only if the account holder is in control of the identifier, and if > the account holder is in control of the identifier, they should be > able to revoke certificates issued for that identifier. > > This does, obviously, have consequences on the security model: > * Currently, an attacker which gains control of an identifier is > able to create or revoke certificates issued for only that > identifier. With this change, they would also be able to revoke > multi-identifier certificates which include the identifier they > have gained control of. > * This successfully reduces the impact of account key compromise; > if an attacker gains control of an account key, any certificates > they create can be revoked. > * This also addresses an additional issue: if an identifier > changes ownership, the new owner can revoke existing certificates > for that identifier, including multi-identifier certificates. > > This would, essentially, be prioritizing confidentiality of each > identifier over availability of all identifiers on a > multi-identifier certificate. By creating a multi-identifier > certificate, users would be "opting in" to this trade-off. To me, > this seems like a reasonable trade-off (especially because > compromise of an identifier is already catastrophic), but perhaps > there are use cases for multi-identifier certificates that I'm not > considering. > > This seems to have minimal impact on the protocol as well as both > client and server implementations. > > Regards, > > Zach Shepherd > > > This might be problematic for services like Cloudflare which use one > certificate for multiple customers. One of them might authorize for > their own domain as well and could then revoke the Cloudflare > certificate, affecting multiple customers. > > On the other hand, requiring all identifiers to be authorized could > result in an attacker with a compromised key to request a certificate > with additional SANs which the original owner doesn't have any control > of, then it's impossible for the original owner to revoke these. > > Regards, Niklas =20 > > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme --------------BECD40761D588FA97A10287A Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit I think Zach raises a really interesting point, and I think Niklas' response is spot on. To rephrase it a bit: If ACME allowed "any" hostname on a cert to revoke it, a multi-SAN certificate could be revoked by the owner of any domain name on that certificate.

That would effectively prevent hosting providers and CDNs from using multi-SAN certificates with ACME, because it would allow one customer to revoke a certificate in active use by other customers.

In theory this problem could be solved by using only single-SAN certificates, but since several hosting providers and CDNs are already using ACME successfully in a multi-SAN use case, that would be a step backwards.

Probably it's best to just document this as an issue: An attacker who compromises a web server can request a cert for that web server's hostname, plus an attacker-controlled hostname, preventing automated revocation. In that case, the owner of the web server will need to rely on the CA's certificate problem reporting system to get the certificate revoked. Not ideal, but I don't see a lot of other choices.

On 03/23/2017 11:04 AM, Niklas Keller wrote:
2017-03-23 18:11 GMT+01:00 Zach Shepherd <shepherdz@vmware.com>:
Section 7.6, Certificate Revocation, states: "Before revoking a certificate, the server MUST verify that the key used to sign the request is authorized to revoke the certificate. The server SHOULD consider at least the following accounts authorized for a given certificate: ... an account that holds authorizations for all of the identifiers in the certificate."

One way to address this issue would be to replace "all" with "any". That is, allow an account holding authorization for an identifier to revoke any certificate issued for that identifier, even if the certificate is also valid for other identifiers.

Conceptually, I think this makes sense: the purpose of challenges is to verify that the an account is authorized for an identifier only if the account holder is in control of the identifier, and if the account holder is in control of the identifier, they should be able to revoke certificates issued for that identifier.

This does, obviously, have consequences on the security model:
 * Currently, an attacker which gains control of an identifier is able to create or revoke certificates issued for only that identifier. With this change, they would also be able to revoke multi-identifier certificates which include the identifier they have gained control of.
 * This successfully reduces the impact of account key compromise; if an attacker gains control of an account key, any certificates they create can be revoked.
 * This also addresses an additional issue: if an identifier changes ownership, the new owner can revoke existing certificates for that identifier, including multi-identifier certificates.

This would, essentially, be prioritizing confidentiality of each identifier over availability of all identifiers on a multi-identifier certificate. By creating a multi-identifier certificate, users would be "opting in" to this trade-off. To me, this seems like a reasonable trade-off (especially because compromise of an identifier is already catastrophic), but perhaps there are use cases for multi-identifier certificates that I'm not considering.

This seems to have minimal impact on the protocol as well as both client and server implementations.

Regards,

Zach Shepherd


This might be problematic for services like Cloudflare which use one certificate for multiple customers. One of them might authorize for their own domain as well and could then revoke the Cloudflare certificate, affecting multiple customers.

On the other hand, requiring all identifiers to be authorized could result in an attacker with a compromised key to request a certificate with additional SANs which the original owner doesn't have any control of, then it's impossible for the original owner to revoke these.

Regards, Niklas  


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

--------------BECD40761D588FA97A10287A-- From nobody Thu Mar 23 17:34: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 D3F46129A78 for ; Thu, 23 Mar 2017 17:34:29 -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 wbh6D92D2Jl4 for ; Thu, 23 Mar 2017 17:34:27 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::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 D56CA129A0A for ; Thu, 23 Mar 2017 17:34:27 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id p189so89304144pfp.1 for ; Thu, 23 Mar 2017 17:34:27 -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 :content-transfer-encoding; bh=4Pk+XMRvkEabHC0XBdftqvo6KWFXnvnG55wroXu7q+s=; b=ZXRcuRoRU6D1hyVYoWcVIK+GBIXRMfexsCmyoIRyrSvGOcmdKAjlwweJjAvRorWanA 4qq2iTmDi2VLSC9Lsw/PkiovwB+FrgUkEe3DMsafG4STs1orwn20tVonSHit9nVAi3Gf 3+wG0dUj5BRjpzZKYXrk03m9oR6fRN5Q+Uo/jF4UlSSqwD0B/Na7ijNpmXSjzyn1QucV Zx89AnB+AXZ0Nu2TIRTJ0doaS3SVVECoIhFjsdoRXZlwD3ulse8fsMREOcLxofp3eIaL UjN8HR8JDnlcLROw6oxMtg5QZnuRTkzzoWryF/FmqFFY5BzrwDsnzpSzZFFVs+2WYeua bt9w== 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 :content-transfer-encoding; bh=4Pk+XMRvkEabHC0XBdftqvo6KWFXnvnG55wroXu7q+s=; b=DNUSDfHyg07+C7Bg3mCWfDfEwqKC+CfLjBtTMyD9aAq9zl4cxRQYu598/1TirKOYaF cWe+X+G4fjn7Q2+iu6N2Y/ZKx0W7z9JY/8pwntzkglnWfV0zSB4P1uiNnjDgEEOUuNGX gidXZy1v8a1ldjD0R43ScO3eW2o4ytCG17poHG0tBng0Qvs4j5f858f+EiAdUO3lXc4L cJv3Dkev/BgNhfP6W/hi+Rwv6sHAd7UtxzerjsLWggzpwDuteFBEagX1OX7d/aFseOEi F0myDIROSLt/z49THuZNix/y1/Bxx0/3rU2XttWweV/rZjEfa03W2E7d9TpMISDdYF1V 03cQ== X-Gm-Message-State: AFeK/H25qE14gKH7dfj6zz/hPauK0hS82RC0W6117/TPnasBJLBEpIX82igo+Ah9/6FvbJ+3/mmwnh2SoGHlsA== X-Received: by 10.99.225.5 with SMTP id z5mr5733119pgh.145.1490315667008; Thu, 23 Mar 2017 17:34:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.130.129 with HTTP; Thu, 23 Mar 2017 17:34:26 -0700 (PDT) From: Logan Widick Date: Thu, 23 Mar 2017 19:34:26 -0500 Message-ID: To: acme@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Acme] Allowing clients to understand the account creation functionality supported by a server 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, 24 Mar 2017 00:34:30 -0000 I think that there should be a way for servers to tell clients what types of contact information and what types of identifiers are supported. Perhaps some part of the directory object could have an array of dummy contacts to show off the URI schemes. For example: contactTypes: ["mailto:example@example.com", "tel:000-000-0000"] Alternatively, the contactTypes may be a list of schemes. For example: contactTypes: ["mailto", "tel"] Another part of the directory object could have information on supported identifiers. For example: identifierTypes: ["dns"] Alternatively, the identifierTypes could include possible challenge types that the server may issue. For example: identifierTypes: [ {"identifierType": "dns", "challengeTypes": ["http", "tls-sni", "dns"]} ] Or, the identifierTypes may include information on possible authorizations. For example, consider an ACME server that requires 2 authorizations for a domain. One of the two authorizations must require a successful "http" or "tls-sni" challenge, while the other authorization requires a successful "dns" challenge. Then, the identifierTypes may look like (with // lines as comments only): identifierTypes: [ {"identifierType": "dns", "authorizationTypes": [ //first authorization: client must complete either HTTP or TLS-SNI challenge ["http", "tls-sni"], //second authorization: client must complete DNS challenge ["dns"] ]} ] I have three options above for identifiers as I am not sure if broadcasting the challenges and/or authorizations may be a security issue or if it may be too complicated for the client or server. Consensus would have to be reached around one of the three identifier options, some other way to include supported identifier info in the directory, or excluding the supported identifier info from the directory. Similar consensus would need to be reached for the contacts. Sincerely, Logan Widick ---------- Forwarded message ---------- > From: Zach Shepherd > To: "cpu@letsencrypt.org" > Cc: "acme@ietf.org" > Bcc: > Date: Thu, 23 Mar 2017 18:06:04 +0000 > Subject: Re: [Acme] Allowing clients to understand the account creation f= unctionality supported by a server > Let's consider a simple world where all ACME servers support mailto and s= ome ACME servers support tel. > > To create an account, the user provides the necessary information to thei= r AMCE client: one or more email addresses and zero or more phone numbers. = The ACME client then attempts to supply all of this information to in an ac= count creation request. Some of the time, this will result in an error beca= use the ACME server does not support tel. > > When the ACME client receives this error, it could: > 1. Display it to the user and ask the user to adjust their input accordin= gly. (A poor user experience.) > 2. Attempt to parse to the error message to confirm that the problem was = the tel. (Hacky.) > 3. Assume that the problem was the tel and retry without that. (Very hack= y.) > > A new ACME server could come along that requires at least one tel or that= doesn't support mailto. As a result, ACME clients may chose to attempt #2 = and/or #3 before falling back to #1. > > This means that ACME clients have one of six different behaviors (#1, #2,= #3, #2 falling back to #1, #3 falling back to #1, #2 falling back to #3 fa= lling back to #1), some of which add a non-trivial amount of complexity to = attempt to parse error messages (yuck.) and some of which end up pushing th= e complexity onto the end-user in end anyways. (Or worse, ACME clients wind= up with hard-coded assumptions based on a specific ACME server implementat= ion and become less portable.) > > Providing information about the supported contact schemes in a machine re= adable format (e.g., in response to a GET requests on the server's new-acco= unt URI) does add work for ACME server implementors, but not so much that i= t's worth complicating the end-user experience. > > Regards, > Zach From nobody Sat Mar 25 09:40: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 7E129129416 for ; Sat, 25 Mar 2017 09:40:28 -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 rV-YJPFXiDfe for ; Sat, 25 Mar 2017 09:40:26 -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 560611293E3 for ; Sat, 25 Mar 2017 09:40:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by umbriel.devever.net (Postfix) with ESMTP id 70BB11D442 for ; Sat, 25 Mar 2017 17:40:24 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=devever.net; h= user-agent:content-disposition:content-type:content-type :mime-version:message-id:subject:subject:from:from:date:date :received:received; s=mimas; t=1490460024; x=1508649385; bh=DDRM 840CV4tlc365f0IWNfc5fa8O+7tJNiyBj/6MDPc=; b=BXUdoYtMe9QB3uu2QzY3 1SIzXv2P27A3oDQOk4Ia+i82wtXlOZIbJi9SX3REO/3/KtWHTvHwuxAAuVTOKJcV 1HtNj+DZCCu7VNzzPoMvK2LDw83G5S0tzknYn4k9QoQ/3OrsGeDXAkNVvqRFAEm1 IHa9xRKEYyTvPhR2yORNNvctGCFGASIKAJe4XrOgPFibC9jW7+VEj/xZAmd8yPkE 0MQ2pHG3MksYEworxujARJ6oTK7l6QReSRAWaic1yZXx9fQiYwM8pYR7LNfqDPJd qWyusCHc8jmR7DFf8Xtkmy3VsX9uxpAx3W37JWRKDCJ2OEU9v6XGxgT0uj8Vrh9r sg== 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 01c8tY0TpAUb for ; Sat, 25 Mar 2017 17:40:24 +0100 (CET) Received: from andover.lhh.devever.net (localhost [127.0.0.1]) by umbriel.devever.net (Postfix) with SMTP id 3A00B1D43C for ; Sat, 25 Mar 2017 17:40:24 +0100 (CET) Date: Sat, 25 Mar 2017 16:40:24 +0000 From: Hugo Landau To: acme@ietf.org Message-ID: <20170325164023.GA7854@andover.lhh.devever.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.8.0 (2017-02-23) Archived-At: Subject: [Acme] Retrying failed authorizations 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, 25 Mar 2017 16:40:28 -0000 Currently, when an order is created, authorizations are created for it, and challenges are created for each of those authorizations. If a challenge is failed once, the challenge comes to have status "invalid", as does the authorization containing it. The order containing the authorization becomes unfulfillable. This is highly undesirable because it is not necessarily possible to discern ahead of time which challenges will succeed and which will fail for a given hostname. Moreover, random failures or failures due to differing viewpoints (e.g. DNS propagation for DNS challenges) increase the likelihood that a given challenge will fail. This is a particular problem for DNS challenges, where it can be unclear when propagation is complete, but also affects other challenge types. Where there is doubt as to the challenges which will be successful for a given hostname, different methods may be attempted by a client in sequence. If the failure of a challenge results in the failure of an entire order, this results in an excessively large number of failed and wasted order, authorization and challenge objects. For example, if a CA which allows up to 100 SANs in each certificate supports three challenge methods (e.g. HTTP, TLS-SNI, DNS), successful completion of the order could involve the creation of about 120,300 objects. (Assume that every time, only the last challenge method attempted of the three methods available is successful. For each attempt, 401 objects are created (1 order, 100 authorizations and 300 challenges). 300 attempts are required: 3 for each authorization.) Although this may be avoidable using new-authz, the intention is clearly to prefer the new-order workflow, support for the new-authz endpoint is not mandatory, and the new-authz endpoint may not be usable for some use cases, such as wildcard domains. The following resolutions are possible: 1. Allow challenges to be retried. Optionally, this could include the removal of the "invalid" status for challenges; there would be only "pending" and "valid". If audit trails are desired, challenge failures would be indicated by appending error objects to a "failedValidations" array, not by changing a status field. Challenge failures during polling would be detected by observing increases in the length of this array. 2. Allow challenges to be regenerated via request, in a fresh, pending state. The challenge URL is changed. The old challenge remains accessible at the old URL for auditing purposes, but the authorization is updated to reference the new challenge URL where previously it updated the old one. 3. Allow authorizations to be regenerated via request. Like challenge regeneration, the authorization URL in the order object would be replaced, and the old authorization would remain accessible at the old URL. 4. Don't change anything about the current specification. This is highly inefficient, insofar that it inflates the number of database objects which must be generated and stored by a CA. It also increases the time that the issuance process will take very substantially. I'd prefer option 1. Thoughts? Hugo Landau From nobody Mon Mar 27 13:38:23 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 95266129637 for ; Mon, 27 Mar 2017 13:38:21 -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 ax9agT8_ILEI for ; Mon, 27 Mar 2017 13:38:19 -0700 (PDT) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::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 130C312964B for ; Mon, 27 Mar 2017 13:38:13 -0700 (PDT) Received: by mail-pg0-x234.google.com with SMTP id 81so36447372pgh.2 for ; Mon, 27 Mar 2017 13:38:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=letsencrypt.org; s=google; h=subject:references:to:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=VMsBRZ5COnD53/AMQXLZlAIbUdP4bLaanqAIA/pON6c=; b=gEKkm2KrpbQSKd2FcoUyxWJ7OkZiWH5SYKOBN5QPArPTU2Maw35kklkKP/exrb43wh SvneqrFSGiqJCkhJvb8VBsX75+Wfkgl0cQCrs668ZeBcmJMla+cJEIAx75UPd25uDjUw rO/0VQwTPi9JJ+STBrpDqVkykF7yvNRlsnNOs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:to:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=VMsBRZ5COnD53/AMQXLZlAIbUdP4bLaanqAIA/pON6c=; b=nCKHq/HRUf70HDbnZH7kea/tssuwh42twayoAEtWCPKZOOlhQ2KE8v6z6HxrPMRFtK W0/zt+0VTzCzj+oOZujl2tfxLG1pgVaQTxFt+V05imActLCMiPNTtXcu/9IQtJnkXbM/ 9O3LdwkeGBBjdyxz6+fli+bB9DlXW0/kBkDU99MjD0DL7yg0ECX8Pqo6BBbJcs8Rc+Og lVn9i6ckAae1g4zeOAOmY9hmE2WiCi3EiX503NyAiig/G2ojBmYj4GuazUMX57iuah7S fTTqiKznKnYi5NjZiHAkEwZMOfsJRxwi1bfq66+cJ2ec8/1OnMs6F1dfIXpltvyJYrkd MCbA== X-Gm-Message-State: AFeK/H1/8ry0cgUnZmhF9NtgDHNXcE67vcqMxOyZ2tE2NHnUJOxGVTaQhomqn56DEkm4ImhX X-Received: by 10.84.225.17 with SMTP id t17mr15928507plj.153.1490647092489; Mon, 27 Mar 2017 13:38:12 -0700 (PDT) Received: from [192.168.42.69] ([50.1.57.147]) by smtp.gmail.com with ESMTPSA id z19sm2834099pfd.81.2017.03.27.13.38.11 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Mar 2017 13:38:12 -0700 (PDT) References: <149064661967.30603.4913027353921499080.idtracker@ietfa.amsl.com> To: "acme@ietf.org" From: Roland Shoemaker X-Forwarded-Message-Id: <149064661967.30603.4913027353921499080.idtracker@ietfa.amsl.com> Message-ID: Date: Mon, 27 Mar 2017 13:38:11 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <149064661967.30603.4913027353921499080.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Acme] Fwd: New Version Notification for draft-shoemaker-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, 27 Mar 2017 20:38:22 -0000 Probably of interesting to some people here, would love to hear your thoughts. -------- Forwarded Message -------- Subject: New Version Notification for draft-shoemaker-acme-ip-00.txt Date: Mon, 27 Mar 2017 13:30:19 -0700 From: internet-drafts@ietf.org To: Roland Bracewell Shoemaker , Roland Shoemaker A new version of I-D, draft-shoemaker-acme-ip-00.txt has been successfully submitted by Roland Bracewell Shoemaker and posted to the IETF repository. Name: draft-shoemaker-acme-ip Revision: 00 Title: ACME IP Identifier Validation Extension Document date: 2017-03-27 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/internet-drafts/draft-shoemaker-acme-ip-00.txt Status: https://datatracker.ietf.org/doc/draft-shoemaker-acme-ip/ Htmlized: https://tools.ietf.org/html/draft-shoemaker-acme-ip-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-shoemaker-acme-ip-00 Abstract: This document specifies identifiers and challenges required to enable the Automated Certificate Management Environment (ACME) to issue certificates for IP addresses. 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. The IETF Secretariat From nobody Mon Mar 27 14:46: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 3A7B9129639 for ; Mon, 27 Mar 2017 14:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.798 X-Spam-Level: X-Spam-Status: No, score=-9.798 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, RCVD_IN_MSPIKE_H2=-2.796, 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 LFHQQCfdhT8o for ; Mon, 27 Mar 2017 14:46:21 -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 CCF55126DEE for ; Mon, 27 Mar 2017 14:46:21 -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:To:References:Subject; bh=fqyxogpisFeX/kOYfCxp+i3WoIl2OtZkRVl6NgD78UU=; b=iIh/lb81YJjxxtf9pTUlKOGvdo2mQmorhNQyX6Ke7RXwelQSxAVYlfrSUUP5ltnUoNlYWy+VVeae2lz6cLcf9/QNXyM7qfV2izX8VsSpp9/Nkdn/4FPaaVRyQNU5MZD6aIj1KFvYLYUdi7EX/7jl7rteWLAZ98Xkm/hvT4g1YgQ=; Received: ; Mon, 27 Mar 2017 14:46:21 -0700 References: To: "acme@ietf.org" From: Jacob Hoffman-Andrews X-Forwarded-Message-Id: Message-ID: <053ecf7e-d5c0-2a78-45d7-6ae387e1a4c8@eff.org> Date: Mon, 27 Mar 2017 14:46:18 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [Acme] Generating nonces probabilistically in 6.4.1. Replay-Nonce 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, 27 Mar 2017 21:46:28 -0000 Forwarding on behalf of Erica Portnoy. I agree, the uniqueness should be a MUST, but I think "high probability" should stay so random generation of nonces is acceptable. PR: https://github.com/ietf-wg-acme/acme/pull/289 -------- Forwarded Message -------- Subject: Generating nonces probabilistically in 6.4.1. Replay-Nonce Resent-Date: Fri, 24 Mar 2017 18:19:35 -0700 (PDT) Resent-From: alias-bounces@ietf.org Resent-To: rlb@ipv.sx, jsha@eff.org, jdkasten@umich.edu Date: Fri, 24 Mar 2017 18:03:53 -0700 From: erica To: draft-ietf-acme-acme@ietf.org In section 6.4.1. Replay-Nonce, it states: "The server should generate=20 the value provided in Replay-Nonce in such a way that they are unique to = each message, with high probability." Should this not be: "The server MUST generate the value provided in=20 Replay-Nonce in such a way that they are unique to each message." This is actually two separate items: - First, that the server must, not should, generate a unique=20 Replay-Nonce. I can't imagine that we're ok with the spec allowing a=20 server to come under replay attacks, so this should probably be MUST. - Second, do Replay-Nonces need to be certainly unique to each message?=20 Or are we merely attempting to mostly rule out replay attacks? If we=20 want to disable them completely, not just with extremely high=20 probability, then we should remove "with high probability". Best, Erica Portnoy From nobody Mon Mar 27 16:29: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 970CB126BF6 for ; Mon, 27 Mar 2017 16:28:59 -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 rB1M9evUXZKv for ; Mon, 27 Mar 2017 16:28:57 -0700 (PDT) Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::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 B002F1296B1 for ; Mon, 27 Mar 2017 16:28:55 -0700 (PDT) Received: by mail-wr0-x22f.google.com with SMTP id w43so66241858wrb.0 for ; Mon, 27 Mar 2017 16:28:55 -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=dl/CR22d1gR9aBX9I4onlbA0PNELw69SzP/76IpoiLw=; b=iZN7w4/kvkfsqO+Rx7Oi9r+cMmVsYHJ0HgrzpP3xE2fpFbZegSAbRE+jHkLE/C/FD1 mDomlbwYydHf4V/7Z9zLf/SRRby0nEkS+uvfTLGVxTPPuktshSXokIWMyuPF1QTZM6u6 XqOsFyr1TFfMrPNQKTCaofiqyJDhzOX5Qup1IF5ocH/MAgfEB/HLe9mfgOL/bpHqEJ8U j6jDoRmIRh/e5JqpIujaKQONdlLAmo3pQVo/SdIjwd8Soz+fEenQSUz248EXVD2EYuI5 WchEPlIo6MOvr9bjgl6vXqF3d2jSx3TyPnXrw8N+M5BfQCjyJNsa/Rb9h6LmA3xg949r xRmg== 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=dl/CR22d1gR9aBX9I4onlbA0PNELw69SzP/76IpoiLw=; b=XtH9bEPCeZpRgQD9BRUfYfaOmlSNMHHFEs5e6PZ9/DGSII1EQN9BxImCeGn4pHd7Q4 caILIis3vzp2vbk27d2jVOx7/Wp3UmhXryUhBNgZPwwBQT+vidNB6tultUJbm0T5a6Hd E2k9j+DiDSFl8e7anLxjPkWG7bgM5s+2dSCZ1XhkeVKFHXiCZlKpEJ46UxK5Ok7aBSM9 jKEvfXD6oTj+fg6Hf0VusEBPYu9uZKCfKSJ1CPiehcDfq/k5tGPnbSps/kA/LXIcXfwK ISH/4WmYL5x6DUw4lT6OnmnQT7XdRELhm+LGZC6+a1+mYT0puhKAeoJ8K/DMQDcomgqb x7KQ== X-Gm-Message-State: AFeK/H04h/7+Y364tx9xoDgWGoAvzCmYFHYya5BjrQcnwbgu6/Ckgu5zOLAd40+7hyHmWDIungf4GvktlbieQw== X-Received: by 10.28.153.20 with SMTP id b20mr6611159wme.76.1490657334061; Mon, 27 Mar 2017 16:28:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.40.69 with HTTP; Mon, 27 Mar 2017 16:28:53 -0700 (PDT) Received: by 10.28.40.69 with HTTP; Mon, 27 Mar 2017 16:28:53 -0700 (PDT) In-Reply-To: References: <149064661967.30603.4913027353921499080.idtracker@ietfa.amsl.com> From: Richard Barnes Date: Mon, 27 Mar 2017 19:28:53 -0400 Message-ID: To: Roland Shoemaker Cc: acme@ietf.org Content-Type: multipart/alternative; boundary=001a114b42ece0fe81054bbeb48f Archived-At: Subject: Re: [Acme] Fwd: New Version Notification for draft-shoemaker-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, 27 Mar 2017 23:29:00 -0000 --001a114b42ece0fe81054bbeb48f Content-Type: text/plain; charset=UTF-8 Thanks, Roland. Interesting draft. Couple of first reactions: - Why use the target of the PTR instead of just provisioning the TXT record directly in the reverse DNS. (Is there some restriction in the spec for reverse DNS that says it's only PTR?) It seems like by using the PTR target, your security analysis gets much more complicated. - For the re-use of "http-01", you should probably specify the contents of the Host header. (Main ACME should probably clarify that for DNS, if it's not clear already.) On Mon, Mar 27, 2017 at 4:38 PM, Roland Shoemaker wrote: > Probably of interesting to some people here, would love to hear your > thoughts. > > -------- Forwarded Message -------- > Subject: New Version Notification for draft-shoemaker-acme-ip-00.txt > Date: Mon, 27 Mar 2017 13:30:19 -0700 > From: internet-drafts@ietf.org > To: Roland Bracewell Shoemaker , Roland > Shoemaker > > > A new version of I-D, draft-shoemaker-acme-ip-00.txt > has been successfully submitted by Roland Bracewell Shoemaker and posted > to the > IETF repository. > > Name: draft-shoemaker-acme-ip > Revision: 00 > Title: ACME IP Identifier Validation Extension > Document date: 2017-03-27 > Group: Individual Submission > Pages: 6 > URL: > https://www.ietf.org/internet-drafts/draft-shoemaker-acme-ip-00.txt > Status: https://datatracker.ietf.org/doc/draft-shoemaker-acme-ip/ > Htmlized: https://tools.ietf.org/html/draft-shoemaker-acme-ip-00 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-shoemaker-acme-ip-00 > > > Abstract: > This document specifies identifiers and challenges required to enable > the Automated Certificate Management Environment (ACME) to issue > certificates for IP addresses. > > > > > 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. > > The IETF Secretariat > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > --001a114b42ece0fe81054bbeb48f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks, Roland.=C2=A0 Interesting draft.=

Couple of first reactions:

- W= hy use the target of the PTR instead of just provisioning the TXT record di= rectly in the reverse DNS. =C2=A0(Is there some restriction in the spec for= reverse DNS that says it's only PTR?) =C2=A0It seems like by using the= PTR target, your security analysis gets much more complicated.
<= br>
- For the re-use of "http-01", you should probably = specify the contents of the Host header. =C2=A0(Main ACME should probably c= larify that for DNS, if it's not clear already.)

On Mon, Mar 27, 2017 a= t 4:38 PM, Roland Shoemaker <roland@letsencrypt.org> wr= ote:
Probably of interesting to some peop= le here, would love to hear your
thoughts.

-------- Forwarded Message --------
Subject: New Version Notification for draft-shoemaker-acme-ip-00.txt
Date: Mon, 27 Mar 2017 13:30:19 -0700
From: interne= t-drafts@ietf.org
To: Roland Bracewell Shoemaker <roland@letsencrypt.org>, Roland
Shoemaker <r= oland@letsencrypt.org>


A new version of I-D, draft-shoemaker-acme-ip-00.txt
has been successfully submitted by Roland Bracewell Shoemaker and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-shoemaker-acme-ip
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ACME IP Identifier Validation Exte= nsion
Document date:=C2=A0 2017-03-27
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 6
URL:
https://www.ietf.org/internet-drafts/draft-shoemaker-acme-ip-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ht= tps://datatracker.ietf.org/doc/draft-shoemaker-acme-ip/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://to= ols.ietf.org/html/draft-shoemaker-acme-ip-00
Htmlized:
https://datatracker.ietf.org/do= c/html/draft-shoemaker-acme-ip-00


Abstract:
=C2=A0 =C2=A0This document specifies identifiers and challenges required to= enable
=C2=A0 =C2=A0the Automated Certificate Management Environment (ACME) to iss= ue
=C2=A0 =C2=A0certificates for IP addresses.




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.

The IETF Secretariat

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

--001a114b42ece0fe81054bbeb48f-- From nobody Mon Mar 27 17:31: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 34A2A1296D5 for ; Mon, 27 Mar 2017 17:31:04 -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 t7D6XAPBntx5 for ; Mon, 27 Mar 2017 17:31:01 -0700 (PDT) Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e:c05::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 86C111296D4 for ; Mon, 27 Mar 2017 17:31:01 -0700 (PDT) Received: by mail-pg0-x22c.google.com with SMTP id g2so55272601pge.3 for ; Mon, 27 Mar 2017 17:31:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=letsencrypt.org; s=google; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=jW0pCbcbFOSY18fTDGNmGga9UuMjownXuzwiw6ktGbE=; b=c/IdyvgMJpy5D0HVO9ScdkKihn0EBtFwx1diopcYEOQW6E+fXdT7Mmb4W2ZDaaKMs1 cUdkwKynM3cqu1auUgy3LaEb0Mu7iZAUTYYlbx1SazdqmbUJMdKye88/Cp/D5XFzdRiq 4KAkshOD04Vwno3q9swxeqefnWTXlu/kfzB0Y= 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:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=jW0pCbcbFOSY18fTDGNmGga9UuMjownXuzwiw6ktGbE=; b=s6lg5LGoVV0AOCaIHwhTYeiOFRfV2v82RDNMuPD7s/eJ7o7lC2MrnPwDXbl5os++nz z+SVQvrhlScdeS7rmSD9qxhI7FNQCvuYnFm8czCw6sopQxoElhDA+wZPkKxd/uWO+Laq f3dcpA1gq3/SfEzmuxBekZhfxT53yzDV9FPjUd0DFlM+6oaqYYgsFFxkp+EgXCiDd+vA auHcQqLmOg6WBdXx4NV6797n0v72utW4CKVGv4VlYTfBGkuLC4cUYRtjR5uSc5u8qYag DySdLWOTNU4JscFQRPq7SX9wV2V2NwAc56aC11Hya106Khdp6xfu0+3KnymcLHi9SLQt AVww== X-Gm-Message-State: AFeK/H2frUiGMOBXRY8hsg9Cy3KJi/tcabpVGebircJnL1W1dHQMiZrB2DEU/YmD/A2KgHY2 X-Received: by 10.98.46.130 with SMTP id u124mr27992158pfu.204.1490661060617; Mon, 27 Mar 2017 17:31:00 -0700 (PDT) Received: from [192.168.42.101] ([50.1.57.147]) by smtp.gmail.com with ESMTPSA id j19sm3338724pfk.4.2017.03.27.17.30.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Mar 2017 17:31:00 -0700 (PDT) To: Richard Barnes References: <149064661967.30603.4913027353921499080.idtracker@ietfa.amsl.com> Cc: acme@ietf.org From: Roland Bracewell Shoemaker Message-ID: <49876e96-8276-7d93-9e13-8854e94d5050@letsencrypt.org> Date: Mon, 27 Mar 2017 17:30:58 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Acme] Fwd: New Version Notification for draft-shoemaker-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, 28 Mar 2017 00:31:04 -0000 On 03/27/2017 04:28 PM, Richard Barnes wrote: > Thanks, Roland. Interesting draft. > > Couple of first reactions: > > - Why use the target of the PTR instead of just provisioning the TXT > record directly in the reverse DNS. (Is there some restriction in the > spec for reverse DNS that says it's only PTR?) It seems like by using > the PTR target, your security analysis gets much more complicated. > The original reason for this was that I held the belief that there was an RFC that set restrictions on the record types that should exist in the reverse zones (i.e. PTR/CNAME/NS/SOA) only. After looking through relevant documents for the last hour though I can't actually find anything that states this and a number of example zones do seem to contain other types, notably TXTs. Based on this I think it does makes sense to remove the use of the PTR target and just require the provisioning of a TXT record at the reverse mapping node. > - For the re-use of "http-01", you should probably specify the contents > of the Host header. (Main ACME should probably clarify that for DNS, if > it's not clear already.) > Good point. > On Mon, Mar 27, 2017 at 4:38 PM, Roland Shoemaker > > wrote: > > Probably of interesting to some people here, would love to hear your > thoughts. > > -------- Forwarded Message -------- > Subject: New Version Notification for draft-shoemaker-acme-ip-00.txt > Date: Mon, 27 Mar 2017 13:30:19 -0700 > From: internet-drafts@ietf.org > To: Roland Bracewell Shoemaker >, Roland > Shoemaker > > > > A new version of I-D, draft-shoemaker-acme-ip-00.txt > has been successfully submitted by Roland Bracewell Shoemaker and posted > to the > IETF repository. > > Name: draft-shoemaker-acme-ip > Revision: 00 > Title: ACME IP Identifier Validation Extension > Document date: 2017-03-27 > Group: Individual Submission > Pages: 6 > URL: > https://www.ietf.org/internet-drafts/draft-shoemaker-acme-ip-00.txt > > Status: > https://datatracker.ietf.org/doc/draft-shoemaker-acme-ip/ > > Htmlized: > https://tools.ietf.org/html/draft-shoemaker-acme-ip-00 > > Htmlized: > https://datatracker.ietf.org/doc/html/draft-shoemaker-acme-ip-00 > > > > Abstract: > This document specifies identifiers and challenges required to enable > the Automated Certificate Management Environment (ACME) to issue > certificates for IP addresses. > > > > > 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 > . > > The IETF Secretariat > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > > > From nobody Mon Mar 27 18:27: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 2D29312984B for ; Mon, 27 Mar 2017 18:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.799 X-Spam-Level: X-Spam-Status: No, score=-9.799 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, RCVD_IN_MSPIKE_H2=-2.796, 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 qKfy8Yt3B4Ji for ; Mon, 27 Mar 2017 18:27:22 -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 353D81296D1 for ; Mon, 27 Mar 2017 18:27:22 -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:MIME-Version:Date:Message-ID:Subject:From:To; bh=gFCKmM12DZl2B8VNjVvJYqa7GBiAbzB7hI0SaZi6s0M=; b=nCRLEtwFSb0PMpAVz5ACCbDJ8smrbbwMxim2dVXsMxGO3X4aiJdhmQ5TbCp9hcpCK+SL1owHx1cs5HKDgMBua6K/bzC8NdoYlWzq2/EKrOKOwJCwz1EG2KGV3wmdnWZXxkzySV8tU0+r3TeIMJEldpzSJf0d6zDWasuPGWzvyhw=; Received: ; Mon, 27 Mar 2017 18:27:22 -0700 To: acme@ietf.org From: Erica Portnoy Message-ID: <03a7d33b-b857-ff3d-6010-73566dc3698f@eff.org> Date: Mon, 27 Mar 2017 18:27:21 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: skipped for local relay Archived-At: Subject: [Acme] Generating nonces probabilistically in 6.4.1. Replay-Nonce 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, 28 Mar 2017 01:27:24 -0000 In section 6.4.1. Replay-Nonce, it states: "The server should generate the value provided in Replay-Nonce in such a way that they are unique to each message, with high probability." Should this not be: "The server MUST generate the value provided in Replay-Nonce in such a way that they are unique to each message." This is actually two separate items: - First, that the server must, not should, generate a unique Replay-Nonce. I can't imagine that we're ok with the spec allowing a server to come under replay attacks, so this should probably be MUST. - Second, do Replay-Nonces need to be certainly unique to each message? Or are we merely attempting to mostly rule out replay attacks? If we want to disable them completely, not just with extremely high probability, then we should remove "with high probability". Best, Erica Portnoy From nobody Tue Mar 28 03:46: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 207CE1287A3 for ; Tue, 28 Mar 2017 03:46:43 -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 mYNo0bnmsExQ for ; Tue, 28 Mar 2017 03:46:41 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::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 79FDB129409 for ; Tue, 28 Mar 2017 03:46:41 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id r45so60084577qte.3 for ; Tue, 28 Mar 2017 03:46:41 -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=E+Uw58it+WW5IfXP8820O7nkPPnCeELQoCQgn54e9uY=; b=u66ECsNKGrljgC7Y59zhWIjaABHL/2SkWJA387y2B23N5AULFgCPqRf/EoZKrwC/go gthD/081broK47Zmd0pzrx3jNV1h8dc/36EnFV4s7UVF52PKuKQtJcFMXJNDE3LUxhO3 6kCx5WJXYZe83Vkcs1eKuEp/OVjjVt3a3w0Huz1wmPVzBD98q8otQw9QcLZWLDVlt6dr 2HYC3ZqmLw7/jk3JP+2UjKQ/Ki1XKhAT3y1QVMfIiFRLoLp5hmLbush1hloylS7C12YA sIdc4vGHZPq5c6DAmtqlU7d1+/P8PqA1J8bzNKxczsmC5nYRs2ytwNsrjTV/99rCNFmL TjpQ== 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=E+Uw58it+WW5IfXP8820O7nkPPnCeELQoCQgn54e9uY=; b=YJ85z5k3hzPNXSaorpfn/T6b2XB2DABZqLkpDRpKo3IIdK3KAMaMk7N5FBUCDXLAON thM5vIMIZjx+aCZ1TqfWbWvL8/W53tOzu2EKZl9aEHkwWjHqCq0QctoYuDt77o5eoHxy 91dgbdR48bhLHCqOsj/n7SBkvFq5D3CI2YBmviHqJbf0YzwoGZufm1cDSBvhb0qjGkx6 z6Ew+8EGpGbFD2gYHKWveF+ojXYUnywL8ipcXFOxl4zPomo0c2bboRaQKQ6C+o0JtSa2 vwD+UsErt3+7bz8FYXzUzkTxhkXieMZ+UKHcEyd3v4zzVxiWSv7O5pvMt03KtNhQe+LX claw== X-Gm-Message-State: AFeK/H2o8E0D2wXxeiyWFfTLkPbr7o6imiLSIfSbzNodI2/501xEm+4TgbKXaoh0C5OIrbIZ0wDF1PrUMc8Cuw== X-Received: by 10.200.46.91 with SMTP id s27mr28017885qta.278.1490698000580; Tue, 28 Mar 2017 03:46:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.27.194 with HTTP; Tue, 28 Mar 2017 03:46:40 -0700 (PDT) In-Reply-To: <053ecf7e-d5c0-2a78-45d7-6ae387e1a4c8@eff.org> References: <053ecf7e-d5c0-2a78-45d7-6ae387e1a4c8@eff.org> From: Martin Thomson Date: Tue, 28 Mar 2017 05:46:40 -0500 Message-ID: To: Jacob Hoffman-Andrews Cc: "acme@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Acme] Generating nonces probabilistically in 6.4.1. Replay-Nonce 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, 28 Mar 2017 10:46:43 -0000 I agree with Jacob here. MUST seems appropriate, but requiring uniqueness absolutely imposes a constraint on server design that is so onerous that I would see it as impractical. (Also, the document doesn't really identify a scope for this uniqueness, which would probably be necessary if you had to avoid random generation.) On 27 March 2017 at 16:46, Jacob Hoffman-Andrews wrote: > Forwarding on behalf of Erica Portnoy. > > I agree, the uniqueness should be a MUST, but I think "high probability" > should stay so random generation of nonces is acceptable. PR: > https://github.com/ietf-wg-acme/acme/pull/289 > > > -------- Forwarded Message -------- > Subject: Generating nonces probabilistically in 6.4.1. Replay-Nonce > Resent-Date: Fri, 24 Mar 2017 18:19:35 -0700 (PDT) > Resent-From: alias-bounces@ietf.org > Resent-To: rlb@ipv.sx, jsha@eff.org, jdkasten@umich.edu > Date: Fri, 24 Mar 2017 18:03:53 -0700 > From: erica > To: draft-ietf-acme-acme@ietf.org > > > > In section 6.4.1. Replay-Nonce, it states: "The server should generate > the value provided in Replay-Nonce in such a way that they are unique to > each message, with high probability." > > Should this not be: "The server MUST generate the value provided in > Replay-Nonce in such a way that they are unique to each message." > > This is actually two separate items: > - First, that the server must, not should, generate a unique > Replay-Nonce. I can't imagine that we're ok with the spec allowing a > server to come under replay attacks, so this should probably be MUST. > - Second, do Replay-Nonces need to be certainly unique to each message? > Or are we merely attempting to mostly rule out replay attacks? If we > want to disable them completely, not just with extremely high > probability, then we should remove "with high probability". > > Best, > Erica Portnoy > > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme From nobody Tue Mar 28 05:04: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 EA569129417 for ; Tue, 28 Mar 2017 05:04: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, SPF_FAIL=0.001, SPF_HELO_PASS=-0.001] autolearn=no 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 HNA4NgHGQN76 for ; Tue, 28 Mar 2017 05:04:31 -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 14DD6129431 for ; Tue, 28 Mar 2017 05:04:29 -0700 (PDT) Received: from host249.freudenhaus.alandoherty.net ([193.120.128.249]:2395 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 1csprN-0005hC-D0 ; Tue, 28 Mar 2017 12:04:27 +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: Tue, 28 Mar 2017 13:04:22 +0100 To: Richard Barnes ,Roland Shoemaker From: Alan Doherty Cc: acme@ietf.org In-Reply-To: References: <149064661967.30603.4913027353921499080.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-Id: X-VIRUS: NONE {no virus found, This is no guarentee} Archived-At: Subject: Re: [Acme] Fwd: New Version Notification for draft-shoemaker-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, 28 Mar 2017 12:04:34 -0000 At 00:28 28/03/2017 Tuesday, Richard Barnes wrote: >Thanks, Roland. Interesting draft. > >Couple of first reactions: > >- Why use the target of the PTR instead of just provisioning the TXT record directly in the reverse DNS.  (Is there some restriction in the spec for reverse DNS that says it's only PTR?)  It seems like by using the PTR target, your security analysis gets much more complicated. i can see sense here as getting an isp to point a customers ptrs at a set of names is easy (getting many to put anything else in a in-addr.arpa zone is non-simple as many use horrible front ends with limited options) as smaller customers have no direct control over ptr-zones but achieve control via isp (or cname as ptr to zone they can control) such as mine 106.238.120.193.ptr.narrowpoint.com >- For the re-use of "http-01", you should probably specify the contents of the Host header.  (Main ACME should probably clarify that for DNS, if it's not clear already.) i would hope the host header would be the ip as its the ip being authenticated so a cert covering https://xxx.xxx.xxx.xxx can be genereated (as personally id like to be able to add the ips to the san cert (even though the ip normally just serves an impolite error suggesting the 'bot-usually' try probing elsewhere ;) >On Mon, Mar 27, 2017 at 4:38 PM, Roland Shoemaker <roland@letsencrypt.org> wrote: >Probably of interesting to some people here, would love to hear your >thoughts. > >-------- Forwarded Message -------- >Subject: New Version Notification for draft-shoemaker-acme-ip-00.txt >Date: Mon, 27 Mar 2017 13:30:19 -0700 >From: internet-drafts@ietf.org >To: Roland Bracewell Shoemaker <roland@letsencrypt.org>, Roland >Shoemaker <roland@letsencrypt.org> > > >A new version of I-D, draft-shoemaker-acme-ip-00.txt >has been successfully submitted by Roland Bracewell Shoemaker and posted >to the >IETF repository. > >Name:      draft-shoemaker-acme-ip >Revision:    00 >Title:     ACME IP Identifier Validation Extension >Document date: 2017-03-27 >Group:     Individual Submission >Pages:     6 >URL: >https://www.ietf.org/internet-drafts/draft-shoemaker-acme-ip-00.txt >Status:     https://datatracker.ietf.org/doc/draft-shoemaker-acme-ip/ >Htmlized:    https://tools.ietf.org/html/draft-shoemaker-acme-ip-00 >Htmlized: >https://datatracker.ietf.org/doc/html/draft-shoemaker-acme-ip-00 > > >Abstract: >  This document specifies identifiers and challenges required to enable >  the Automated Certificate Management Environment (ACME) to issue >  certificates for IP addresses. > > > > >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. > >The IETF Secretariat > >_______________________________________________ >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 Mar 28 05:16: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 B6CCE1294F3 for ; Tue, 28 Mar 2017 05:16:43 -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, SPF_FAIL=0.001, SPF_HELO_PASS=-0.001] autolearn=no 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 0jQ2A4HDSCn0 for ; Tue, 28 Mar 2017 05:16:42 -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 B7CA7129582 for ; Tue, 28 Mar 2017 05:16:35 -0700 (PDT) Received: from host249.freudenhaus.alandoherty.net ([193.120.128.249]:2405 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 1csq34-0005sL-EE ; Tue, 28 Mar 2017 12:16:32 +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: Tue, 28 Mar 2017 13:16:28 +0100 To: Martin Thomson , Jacob Hoffman-Andrews From: Alan Doherty Cc: "acme@ietf.org" In-Reply-To: References: <053ecf7e-d5c0-2a78-45d7-6ae387e1a4c8@eff.org> 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] Generating nonces probabilistically in 6.4.1. Replay-Nonce 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, 28 Mar 2017 12:16:44 -0000 At 11:46 28/03/2017 Tuesday, Martin Thomson wrote: >I agree with Jacob here. MUST seems appropriate, but requiring >uniqueness absolutely imposes a constraint on server design that is so >onerous that I would see it as impractical. (Also, the document >doesn't really identify a scope for this uniqueness, which would >probably be necessary if you had to avoid random generation.) i think given a large enough set of transactions unique is impossible (and guaranteeing a previous use in identical circumstances impossible, unlikely but not guaranteeing) thus as its impossible mathematically (unless using sequential numbers of infinite length) its better to keep 'high probability' as the possibility of random generating a sequence twice is always there, if its truly random improbable can be done, impossible is infinitely more work (as would require keeping all previous and negative matching an ever growing list before use) >On 27 March 2017 at 16:46, Jacob Hoffman-Andrews wrote: >> Forwarding on behalf of Erica Portnoy. >> >> I agree, the uniqueness should be a MUST, but I think "high probability" >> should stay so random generation of nonces is acceptable. PR: >> https://github.com/ietf-wg-acme/acme/pull/289 >> >> >> -------- Forwarded Message -------- >> Subject: Generating nonces probabilistically in 6.4.1. Replay-Nonce >> Resent-Date: Fri, 24 Mar 2017 18:19:35 -0700 (PDT) >> Resent-From: alias-bounces@ietf.org >> Resent-To: rlb@ipv.sx, jsha@eff.org, jdkasten@umich.edu >> Date: Fri, 24 Mar 2017 18:03:53 -0700 >> From: erica >> To: draft-ietf-acme-acme@ietf.org >> >> >> >> In section 6.4.1. Replay-Nonce, it states: "The server should generate >> the value provided in Replay-Nonce in such a way that they are unique to >> each message, with high probability." >> >> Should this not be: "The server MUST generate the value provided in >> Replay-Nonce in such a way that they are unique to each message." >> >> This is actually two separate items: >> - First, that the server must, not should, generate a unique >> Replay-Nonce. I can't imagine that we're ok with the spec allowing a >> server to come under replay attacks, so this should probably be MUST. >> - Second, do Replay-Nonces need to be certainly unique to each message? >> Or are we merely attempting to mostly rule out replay attacks? If we >> want to disable them completely, not just with extremely high >> probability, then we should remove "with high probability". >> >> Best, >> Erica Portnoy >> >> >> _______________________________________________ >> 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 Mar 28 11:08: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 AF4951297C1 for ; Tue, 28 Mar 2017 11:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.798 X-Spam-Level: X-Spam-Status: No, score=-9.798 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, RCVD_IN_MSPIKE_H2=-2.796, 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 TGweb8_ryJo3 for ; Tue, 28 Mar 2017 11:08:39 -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 457A61297A5 for ; Tue, 28 Mar 2017 11:08:39 -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:Cc:References:To:Subject; bh=Wpdr6RLxbw5MniziWhjjPx11hms9r7hLTfGx5LxAHCI=; b=csWgaw/w6rTfcApBogb404slP1aDH7QzBNGLeO90w33YsZ6naIxzcX/oW2yB7c5LsKSCuzwZD3lCXgpGt1l10jkUSmsxHk8IDyQrcRZj9BWQSJPHEB+AZlFuwPkwRWKjhbDe9vTm/RR2ZnBhA3Sc+O/rUuaXr9tNz6sj7DuiAPw=; Received: ; Tue, 28 Mar 2017 11:08:39 -0700 To: Roland Bracewell Shoemaker , Richard Barnes References: <149064661967.30603.4913027353921499080.idtracker@ietfa.amsl.com> <49876e96-8276-7d93-9e13-8854e94d5050@letsencrypt.org> Cc: acme@ietf.org From: Jacob Hoffman-Andrews Message-ID: <27dec402-7325-953d-bd74-40407baec5da@eff.org> Date: Tue, 28 Mar 2017 11:08:38 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <49876e96-8276-7d93-9e13-8854e94d5050@letsencrypt.org> Content-Type: multipart/alternative; boundary="------------6DD827041884F567BB3EF233" Received-SPF: skipped for local relay Archived-At: Subject: Re: [Acme] Fwd: New Version Notification for draft-shoemaker-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, 28 Mar 2017 18:08:42 -0000 This is a multi-part message in MIME format. --------------6DD827041884F567BB3EF233 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 03/27/2017 05:30 PM, Roland Bracewell Shoemaker wrote: > The original reason for this was that I held the belief that there was > an RFC that set restrictions on the record types that should exist in > the reverse zones (i.e. PTR/CNAME/NS/SOA) only. After looking through > relevant documents for the last hour though I can't actually find > anything that states this and a number of example zones do seem to > contain other types, notably TXTs. I think you were probably thinking of https://tools.ietf.org/html/rfc3172= : This domain is termed an "infrastructure domain", as its role is to support the operating infrastructure of the Internet. In particular, the "arpa" domain is not to be used in the same manner (e.g., for naming hosts) as other generic Top Level Domains are commonly used. I think Roland's approach is reasonable given the above constraint. Richa= rd, you mentioned this complicates the risk analysis. Could you go into more = detail? --------------6DD827041884F567BB3EF233 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit On 03/27/2017 05:30 PM, Roland Bracewell Shoemaker wrote:
The original reason for this was that I held the belief that there was
an RFC that set restrictions on the record types that should exist in
the reverse zones (i.e. PTR/CNAME/NS/SOA) only. After looking through
relevant documents for the last hour though I can't actually find
anything that states this and a number of example zones do seem to
contain other types, notably TXTs.
I think you were probably thinking of https://tools.ietf.org/html/rfc3172:

   This domain is termed an "infrastructure domain", as its role is to
   support the operating infrastructure of the Internet.  In particular,
   the "arpa" domain is not to be used in the same manner (e.g., for
   naming hosts) as other generic Top Level Domains are commonly used.

I think Roland's approach is reasonable given the above constraint. Richard,
you mentioned this complicates the risk analysis. Could you go into more detail?
--------------6DD827041884F567BB3EF233-- From nobody Tue Mar 28 11:35: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 2C46C12944B for ; Tue, 28 Mar 2017 11:35:19 -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, 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 JqWzo54xY3xz for ; Tue, 28 Mar 2017 11:35:17 -0700 (PDT) Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E72261293DF for ; Tue, 28 Mar 2017 11:35:16 -0700 (PDT) Received: from dhcp-8770.meeting.ietf.org (dhcp-8770.meeting.ietf.org [31.133.135.112]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id D43C0242102F; Tue, 28 Mar 2017 18:35:14 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Jim Reid In-Reply-To: <49876e96-8276-7d93-9e13-8854e94d5050@letsencrypt.org> Date: Tue, 28 Mar 2017 19:30:28 +0100 Cc: Richard Barnes , acme@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <8CF09EFA-F243-43DF-BD57-471592DF6BBD@rfc1035.com> References: <149064661967.30603.4913027353921499080.idtracker@ietfa.amsl.com> <49876e96-8276-7d93-9e13-8854e94d5050@letsencrypt.org> To: Roland Bracewell Shoemaker X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Acme] New Version Notification for draft-shoemaker-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, 28 Mar 2017 18:35:19 -0000 > On 28 Mar 2017, at 01:30, Roland Bracewell Shoemaker = wrote: >=20 > The original reason for this was that I held the belief that there was > an RFC that set restrictions on the record types that should exist in > the reverse zones (i.e. PTR/CNAME/NS/SOA) only. After looking through > relevant documents for the last hour though I can't actually find > anything that states this and a number of example zones do seem to > contain other types, notably TXTs. No such restriction exists. Any RRtype can appear in any zone/domain. = The DNS protocol does not impose any constraints on which RRtypes can go = where. There are some corner cases arising from policy, not protocol, matters = however. For example, a zone signed with DNSSEC-bis probably won't have = NSEC3 or NSEC3PARAM records while one using DNSSEC-ter probably won't = contain NSEC records. From nobody Tue Mar 28 11:52: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 8D090129A0F for ; Tue, 28 Mar 2017 11:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.739 X-Spam-Level: X-Spam-Status: No, score=-1.739 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, HTML_OBFUSCATE_05_10=0.26, 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 XWNALTHNJEO5 for ; Tue, 28 Mar 2017 11:52:09 -0700 (PDT) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::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 4A3F6129A05 for ; Tue, 28 Mar 2017 11:52:08 -0700 (PDT) Received: by mail-qt0-x232.google.com with SMTP id r45so72264886qte.3 for ; Tue, 28 Mar 2017 11:52:08 -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=ChOMMP2C9//2E7t5VIhBLTHeByMarNguyZ3UsDrUOFc=; b=tHG940oCXM0T2P2NEA4m/18juTdaTl2Egllm8P2ZgCSyXsJ+2W/66b+Penql9xb1pA lQtKXK5MTZwhq9xQil0YtlGqz5JKIs3UfGpR0HUWTKapTY5x5Bd79eyLrDDJOy36cPnO pfRuGnJczJmrjENBZy3ZQx9G6t/2l4r9jA3khoXPAKYm0dk+fpNx40tcC/MKxUo89Dey vzAf5oKVrkE2VazKdgIxdEQDO/R1xP4KDQN7tPyBRaVp257KdY2fMNLLWRuA7P61g5TF zuuJzEtP5W8FiMf9BRgTPJSpSuF/MQYZuqlud5yF5+OeFZm5t2Bfqxt84A12JD/mDVUx 2tCw== 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=ChOMMP2C9//2E7t5VIhBLTHeByMarNguyZ3UsDrUOFc=; b=ZCwWEfnwKotZ//nItI0MkvKSCpCD+4mME2BOWImfXp4ab+H1wS4DnzGjIU9CEjUT3t MRztfUmUMF78OpaEuT4LxzmJfJHRWquQQHlcxGm2H+e0MmGQq4sUlht+eNvVtWK8ashq qz+yQAIqxrdsukY37fmKjvcuCd5IcoBfZmSUq15P7dKcodbTCX9iZuV4EuyRpv9r+pQZ efsX/BVKvHJ6c2pfGPNxiZVkERxabyP4EaWftPQMr3cSiMZlcJ0EslffHcxIVGe01bBM KikTGCOQcRavPDWf6KTEE4sz9Kx03u55/CLG2f/8SAOSdaNCj2NgHZLXtq4TULUFRRDv k0UA== X-Gm-Message-State: AFeK/H2ArISPWX2dmvj6Z90ribcKdy/inj6mCg6OHEY3jcACUS3w1xV+1BW5X4DPgTq8560WnfI+o6RpahWmng== X-Received: by 10.237.48.37 with SMTP id 34mr27187180qte.117.1490727127110; Tue, 28 Mar 2017 11:52:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.98.101 with HTTP; Tue, 28 Mar 2017 11:52:06 -0700 (PDT) In-Reply-To: <148944926626.20316.12234869376517390616@ietfa.amsl.com> References: <148944926626.20316.12234869376517390616@ietfa.amsl.com> From: Mary Barnes Date: Tue, 28 Mar 2017 13:52:06 -0500 Message-ID: To: acme@ietf.org Content-Type: multipart/alternative; boundary=94eb2c0c9bbede5ff4054bcef4d8 Archived-At: Subject: [Acme] Fwd: I-D Action: draft-barnes-acme-service-provider-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, 28 Mar 2017 18:52:15 -0000 --94eb2c0c9bbede5ff4054bcef4d8 Content-Type: text/plain; charset=UTF-8 Hi all, Chris and I put together this draft which has some extensions to support an ACME challenge based on a service provider identifer and token. This is based on the work in the ATIS/SIP Forum NNI task group. The document has not yet been approved so there isn't on a public server but can be accessed by joining the mailing lists, etc. But, likely folks in this group don't have a general interest in the work, so if you'd like the referenced ATIS documents, please let me know and I can forward to you separately. I'm not sure we need agenda time, but I'm happy to put a few slides together if folks would like some discussion. But, either way feedback from the WG and chairs, in particular, as to how the registrations can be progressed would be appreciated. Regards, Mary ---------- Forwarded message ---------- From: Date: Mon, Mar 13, 2017 at 6:54 PM Subject: I-D Action: draft-barnes-acme-service-provider-00.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : ACME Identifiers and Challenges for VoIP Service Providers Authors : Mary Barnes Chris Wendt Filename : draft-barnes-acme-service-provider-00.txt Pages : 8 Date : 2017-03-13 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-barnes-acme-service-provider/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-barnes-acme-service-provider-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/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --94eb2c0c9bbede5ff4054bcef4d8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

Chris and I put together this d= raft which has some extensions to support an ACME challenge based on a serv= ice provider identifer and token. =C2=A0 This is based on the work in the A= TIS/SIP Forum NNI task group.=C2=A0 The document has not yet been approved = so there isn't on a public server but can be accessed by joining the ma= iling lists, etc. But, likely folks in this group don't have a general = interest in the work, so if you'd like the referenced ATIS documents, p= lease let me know and I can forward to you separately. =C2=A0
I'm not sure we need agenda time, but I'm happy to put = a few slides together if folks would like some discussion. But, either way = feedback from the WG and chairs, in particular, as to how the registrations= can be progressed would be appreciated.=C2=A0

Reg= ards,
Mary



---------- Forwarded message ----------
From: <internet-drafts@ietf.org>=
Date: Mon, Mar 13, 2017 at 6:54 PM
Subject: I-D Action: draft-barnes= -acme-service-provider-00.txt
To: i-d-announce@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= ACME Identifiers and Challenges for VoIP Service Providers
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Mary= 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 Chris Wendt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-bar= nes-acme-service-provider-00.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 8
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-03-13

Abstract:
=C2=A0 =C2=A0This document specifies identifiers and challenges required to= enable
=C2=A0 =C2=A0the Automated Certificate Management Environment (ACME) to iss= ue
=C2=A0 =C2=A0certificates for VoIP service providers to support Secure Tele= phony
=C2=A0 =C2=A0Identity (STI).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-barnes-acme-service-provider/

There's also a htmlized version available at:
https://tools.ietf.org/html/dr= aft-barnes-acme-service-provider-00


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/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@iet= f.org
https://www.ietf.org/mailman/li= stinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html<= /a>
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--94eb2c0c9bbede5ff4054bcef4d8-- From nobody Tue Mar 28 12:08: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 02A1D129535 for ; Tue, 28 Mar 2017 12:08:09 -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 iCCN66pyEKvK for ; Tue, 28 Mar 2017 12:08:06 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 97B6B129486 for ; Tue, 28 Mar 2017 12:08:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 1FFEE25EAF; Tue, 28 Mar 2017 22:08:05 +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 t-j7rCQAvTh1; Tue, 28 Mar 2017 22:08:04 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id D563B283; Tue, 28 Mar 2017 22:08:04 +0300 (EEST) Date: Tue, 28 Mar 2017 22:08:03 +0300 From: Ilari Liusvaara To: Richard Barnes Cc: Roland Shoemaker , acme@ietf.org Message-ID: <20170328190803.GA6899@LK-Perkele-V2.elisa-laajakaista.fi> References: <149064661967.30603.4913027353921499080.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [Acme] Fwd: New Version Notification for draft-shoemaker-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, 28 Mar 2017 19:08:09 -0000 On Mon, Mar 27, 2017 at 07:28:53PM -0400, Richard Barnes wrote: > Thanks, Roland. Interesting draft. > > Couple of first reactions: > > - Why use the target of the PTR instead of just provisioning the TXT record > directly in the reverse DNS. (Is there some restriction in the spec for > reverse DNS that says it's only PTR?) It seems like by using the PTR > target, your security analysis gets much more complicated. Reading proposed IP validation rules in CABForum, using PTR target would certainly qualify, whereas putting TXT record on the name probably does not. The proposed rules have nothing on DNS apart from PTR lookups. (The current rules have "other equivalent method" clause.) So my reading is, that one has to do the PTR lookup in order to remain compliant with BRs after the proposed tighening of IP validation goes through (I expect it to). > - For the re-use of "http-01", you should probably specify the contents of > the Host header. (Main ACME should probably clarify that for DNS, if it's > not clear already.) Reading the proposed and current rules, the challenge is either invoked on IP address itself, or on reverse-DNS lookup of it. So if you don't do rDNS lookup, then the validation is invoked on IP address itself, which I think leads to empty Host-header. TLS-SNI-02 would work as usual (the proposed rules explicitly list method 10, which is what TLS-SNI-02 falls under). Existing rules don't say anything (but again, equivalent method clause exists). -Ilari From nobody Tue Mar 28 12:14:03 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 8767D129686 for ; Tue, 28 Mar 2017 12:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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] 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 5_s6nY5UN1Hv for ; Tue, 28 Mar 2017 12:13:58 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::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 CF9331297ED for ; Tue, 28 Mar 2017 12:13:45 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id x124so7051978wmf.0 for ; Tue, 28 Mar 2017 12:13: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=VHM7uveXdxTx8L0twDuqp+nBua/q4uOlbsbpo5WB4PU=; b=F7NK/JJ0tgdo6jTB/amtVDf3Gj4gIYW86DPrgPtD1o7wzfEjLS9wqcm9AsB1GdUoV4 hpSc9Hbem++j3SEPhH6SDNZgSRoNFb8oOwN2BWN2it2GUSBZbgAe4DvVhBBKJ46F/kWX /JRvycxsP93XugR5WfcDkCwqpk82UAN9minnYbSFJPEMUojgpe0gvtqheox2NLNxDdFl 2YTVD4ZOG1noUfsRXV6t9MZbbJbhYj42J4HsSprIJHCpN6f0gXL8aP5+Br/COMItpUa0 O1qr2iiWAv4oYMOnExBCkXoHFSkAVLapgP83pdCU6O062eUgYW0uFJxjGqePt/InJaNw I4Vg== 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=VHM7uveXdxTx8L0twDuqp+nBua/q4uOlbsbpo5WB4PU=; b=TMFByDxT3f1nNGA8VqfaM7jZJ6W5Ds0aClGUbeMmG8cMUqJJmVPpD7FRhuPYd5yFbW ZZEV8QlyYzC20kkGjjnhAkaHuEXk7uElYOa8D33UtptwAlN7WW6SAw6a7Skyf0miBQaI PgUDbfXy9s6mgxOevvwzA0+n9XHS0cvFUXZEkhvB4FSyetVDfV0GMX6w4U/9GJROR8AY JuF4nh9430WayXhsdnP1E+GzAxWACTq7NEUWtzExChnX+1UqMJIV+a1onhWCckOHPJb6 70V1VPwHXOWTYjegS3rJckcbiM5XVhJUWz2RTooLL/zegB40rxdC01W5Vmajz7KVWOeT DmrA== X-Gm-Message-State: AFeK/H3B7bw/Xzpa/bDOk5th4hqBA4DUdqw42bD42aUf9RN5S42lXkqApwDF7z+NzEWd2v2Z44AoZpKqymPftg== X-Received: by 10.28.102.86 with SMTP id a83mr15979723wmc.76.1490728424157; Tue, 28 Mar 2017 12:13:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.40.69 with HTTP; Tue, 28 Mar 2017 12:13:43 -0700 (PDT) In-Reply-To: <20170328190803.GA6899@LK-Perkele-V2.elisa-laajakaista.fi> References: <149064661967.30603.4913027353921499080.idtracker@ietfa.amsl.com> <20170328190803.GA6899@LK-Perkele-V2.elisa-laajakaista.fi> From: Richard Barnes Date: Tue, 28 Mar 2017 15:13:43 -0400 Message-ID: To: Ilari Liusvaara Cc: Roland Shoemaker , "acme@ietf.org" Content-Type: multipart/alternative; boundary=001a114b2ec42de656054bcf4278 Archived-At: Subject: Re: [Acme] Fwd: New Version Notification for draft-shoemaker-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, 28 Mar 2017 19:14:02 -0000 --001a114b2ec42de656054bcf4278 Content-Type: text/plain; charset=UTF-8 On Tue, Mar 28, 2017 at 3:08 PM, Ilari Liusvaara wrote: > On Mon, Mar 27, 2017 at 07:28:53PM -0400, Richard Barnes wrote: > > Thanks, Roland. Interesting draft. > > > > Couple of first reactions: > > > > - Why use the target of the PTR instead of just provisioning the TXT > record > > directly in the reverse DNS. (Is there some restriction in the spec for > > reverse DNS that says it's only PTR?) It seems like by using the PTR > > target, your security analysis gets much more complicated. > > Reading proposed IP validation rules in CABForum, using PTR target would > certainly qualify, whereas putting TXT record on the name probably does > not. > > The proposed rules have nothing on DNS apart from PTR lookups. > > (The current rules have "other equivalent method" clause.) > > So my reading is, that one has to do the PTR lookup in order to remain > compliant with BRs after the proposed tighening of IP validation goes > through (I expect it to). > > > - For the re-use of "http-01", you should probably specify the contents > of > > the Host header. (Main ACME should probably clarify that for DNS, if > it's > > not clear already.) > > Reading the proposed and current rules, the challenge is either invoked > on IP address itself, or on reverse-DNS lookup of it. So if you don't > do rDNS lookup, then the validation is invoked on IP address itself, > which I think leads to empty Host-header. > Au contraire! rbarnes$ nc -l 8080 >/dev/null & rbarnes$ curl -v http://127.0.0.1:8080 * Rebuilt URL to: http://127.0.0.1:8080/ * Trying 127.0.0.1... * TCP_NODELAY set * Connected to 127.0.0.1 (127.0.0.1) port 8080 (#0) > GET / HTTP/1.1 > Host: 127.0.0.1:8080 > User-Agent: curl/7.51.0 > Accept: */* > Guess this is good evidence that we should document this :) > > TLS-SNI-02 would work as usual (the proposed rules explicitly list > method 10, which is what TLS-SNI-02 falls under). Existing rules don't > say anything (but again, equivalent method clause exists). > > > > > > -Ilari > --001a114b2ec42de656054bcf4278 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Mar 28, 2017 at 3:08 PM, Ilari Liusvaara <= ilariliusvaar= a@welho.com> wrote:
On Mon, Mar 27, 2017 at 07:28:53PM -0400= , Richard Barnes wrote:
> Thanks, Roland.=C2=A0 Interesting draft.
>
> Couple of first reactions:
>
> - Why use the target of the PTR instead of just provisioning the TXT r= ecord
> directly in the reverse DNS.=C2=A0 (Is there some restriction in the s= pec for
> reverse DNS that says it's only PTR?)=C2=A0 It seems like by using= the PTR
> target, your security analysis gets much more complicated.

Reading proposed IP validation rules in CABForum, using PTR target w= ould
certainly qualify, whereas putting TXT record on the name probably does
not.

The proposed rules have nothing on DNS apart from PTR lookups.

(The current rules have "other equivalent method" clause.)

So my reading is, that one has to do the PTR lookup in order to remain
compliant with BRs after the proposed tighening of IP validation goes
through (I expect it to).

> - For the re-use of "http-01", you should probably specify t= he contents of
> the Host header.=C2=A0 (Main ACME should probably clarify that for DNS= , if it's
> not clear already.)

Reading the proposed and current rules, the challenge is either invo= ked
on IP address itself, or on reverse-DNS lookup of it. So if you don't do rDNS lookup, then the validation is invoked on IP address itself,
which I think leads to empty Host-header.

Au contraire!

rbarnes$ nc -l 8080 >/dev= /null &
rbarnes$ curl -v http://127.0.0.1:8080
* Rebuilt URL to: http://127.0.0.1:8080/
* =C2=A0 Trying 127.0= .0.1...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127= .0.0.1) port 8080 (#0)
> GET / HTTP/1.1
> Host: <= a href=3D"http://127.0.0.1:8080">127.0.0.1:8080
> User-Age= nt: curl/7.51.0
> Accept: */*
>=C2=A0
=

Guess this is good evidence that we should docume= nt this :)
=C2=A0

TLS-SNI-02 would work as usual (the proposed rules explicitly list
method 10, which is what TLS-SNI-02 falls under). Existing rules don't<= br> say anything (but again, equivalent method clause exists).





-Ilari

--001a114b2ec42de656054bcf4278-- From nobody Tue Mar 28 14:27: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 7E8591294B0 for ; Tue, 28 Mar 2017 14:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.799 X-Spam-Level: X-Spam-Status: No, score=-9.799 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, RCVD_IN_MSPIKE_H2=-2.796, 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 ANB9UDun2xoG for ; Tue, 28 Mar 2017 14:26: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 80459129611 for ; Tue, 28 Mar 2017 14:26: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:MIME-Version:Date:Message-ID:To:Subject:From; bh=5oa9x47MlrxvZogJDaDn0+0ECAnpLQBesPQBdc+r3EQ=; b=nKqmRTjdd3Ju4Sibnen8PpY2UjJ3P+isbjXaUQAJsd7qzJY331niJfCRK5pVl2sB1RNz4AtfZUOOCWSob88ndzF7dZVYV6gQlgd6HPcyUaqZbCe1QaCp+wtqjwo/Vo6WXJWfhoRk+ewVhg8LdtJjoXZPJ/fQ12jkaFV0l75otek=; Received: ; Tue, 28 Mar 2017 14:26:58 -0700 From: Erica Portnoy To: acme@ietf.org Message-ID: Date: Tue, 28 Mar 2017 14:26:57 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: skipped for local relay Archived-At: Subject: [Acme] Require servers to accept at least one automated revocation method 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, 28 Mar 2017 21:27:00 -0000 Section 7.6 reads: Revocation requests are different from other ACME requests in that they can be signed either with an account key pair or the key pair in the certificate. Before revoking a certificate, the server MUST verify that the key used to sign the request is authorized to revoke the certificate. The server SHOULD consider at least the following accounts authorized for a given certificate: - the account that issued the certificate. - an account that holds authorizations for all of the identifiers in the certificate. The server SHOULD also consider a revocation request valid if it is signed with the private key corresponding to the public key in the certificate. With this wording, the server is not required to accept any form of automated revocation request. It should be able to accept at least one form of revocation, even if only the account that issued the certification, or any of the described methods but at least one. Either of these would leave policy choices sufficiently flexible without removing important functionality. Best, Erica Portnoy From nobody Tue Mar 28 14:30: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 1E063129A1C for ; Tue, 28 Mar 2017 14:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 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] 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 G1AaCpOsFPDA for ; Tue, 28 Mar 2017 14:30:17 -0700 (PDT) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (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 D71281294B0 for ; Tue, 28 Mar 2017 14:30:14 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id y18so130395997itc.0 for ; Tue, 28 Mar 2017 14:30:14 -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=UmnAHTvo6OU0VZJmsnD6vSaovu+yE6tTKal4+0h7km8=; b=Ea+czUIFUwoRqUbf/f25FEpdS8CWEi5T/Y/ew83vUoPtS54TR1WxwJOOHAxjPi7WQU RBxwJMIt5c+l9x4q/Gf/xrY+TU3X+FOYJj2R4aC0UgAp585m7Bl5EZQXGWGEmtwjzg4D 8K6RSoFvmmKQdtq+lW1mO+RzucMA+vyH5vsRQ= 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=UmnAHTvo6OU0VZJmsnD6vSaovu+yE6tTKal4+0h7km8=; b=g55J4WfIDXb+NwQCs0p0LxcQPLjhDBKmNJhDDRz0Xmj6LuqoP294xtLVtYx1fkowLi minc22k7jRebyio+PBSKrKrDbPJ2B4sJVi/6YuSUC+whGd/SuZS4doFfnNMEwtpsGszs MyvkxRvRMtzMuEobaOjkq1iGGdv2YkDbVRVYZ5l70PwlLKfSYMIQQX62o/NNX9FbWH8I 9zL/p8G4hX8Kfjd4nij5pIQjaPaNobgIa1vg6iqbq90gASpRnPM3ICA6lw0dwBbDpz03 FVHGjcroU/WKniGS5ZHBJ+tqFRjXPnipJbhKAxBx/+FJsECnbWvYO7LIpxquyQj4Q1eE 8uRQ== X-Gm-Message-State: AFeK/H0Ou8J3MjFD6zpCAcTsLoVIeiShx3Pk1GiVS59m1JudTnMccvC1ImR7yTDIYZcnXNn7heukQPa8tN8D9CH3 X-Received: by 10.107.165.9 with SMTP id o9mr29048198ioe.73.1490736614191; Tue, 28 Mar 2017 14:30:14 -0700 (PDT) MIME-Version: 1.0 Reply-To: cpu@letsencrypt.org Received: by 10.107.9.147 with HTTP; Tue, 28 Mar 2017 14:30:13 -0700 (PDT) In-Reply-To: References: From: Daniel McCarney Date: Tue, 28 Mar 2017 17:30:13 -0400 Message-ID: To: Jacob Hoffman-Andrews Cc: Zach Shepherd , "acme@ietf.org" Content-Type: multipart/alternative; boundary=001a1141d06057debb054bd12a38 Archived-At: Subject: Re: [Acme] Entropy requirement for challenge token 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, 28 Mar 2017 21:30:26 -0000 --001a1141d06057debb054bd12a38 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > > I think Daniel's change at https://github.com/ietf-wg- > acme/acme/pull/284/files is a nice quick fix to the issue, but I agree it > could use a few extra sentences explaining it in security considerations. I will take a crack at amending this PR with a few sentences in the security considerations section. On Thu, Mar 23, 2017 at 3:24 PM, Jacob Hoffman-Andrews wrote= : > Yep, I think there are two ways of thinking about this, though it's > effectively a single problem: > > 1. Prevent attackers from tricking a validation endpoint into serving a > valid challenge response. > 2. Prevent ACME clients from implementing a "naive" validation method > that would make (1) trivial. > > I think Daniel's change at https://github.com/ietf-wg- > acme/acme/pull/284/files is a nice quick fix to the issue, but I agree it > could use a few extra sentences explaining it in security considerations. > > > On 03/23/2017 10:34 AM, Zach Shepherd wrote: > > It seems like the goal of this is to ensure that the ACME client is not > able to control (or, perhaps, even influence) the choice of token and req= uiring > that the token be sufficiently random is one way to achieve this. This > prevents an attacker from "tricking" the ACME server into using a > verification performed by the owner of an identifier as proof that the > attacker controls the identifier. > > Is this accurate? If so, it seems like some version of this explanation > should be included in the Security Considerations section. > > ------------------------------ > *From:* Daniel McCarney > *Sent:* Wednesday, March 22, 2017 10:30 AM > *To:* Zach Shepherd > *Cc:* acme@ietf.org > *Subject:* Re: [Acme] Entropy requirement for challenge token > > Hi Zach, > > > This seems incongruous. If the token must be kept secret an attacker, i= t >> should not be served via an unauthenticated channel. > > > I agree the wording makes it incongruous, I was caught up on this the > other week until it was clarified for me by Jacob. > > The token is random not to prevent a guessing attack but to prevent the > implementation of a server that can automatically reply to challenges > without being a party to the authorization creation (e.g. knowing the > token). It's OK for the token to be served via an unauthenticated channel= , > it just can't be predictable. > > I took a crack at rewording this in https://github.com/ietf-wg- > acme/acme/pull/284 > > - Hopefully if I'm completely off-base someone can correct it to be > accurate & understandable. > > On Wed, Mar 22, 2017 at 1:12 AM, Zach Shepherd > wrote: > >> The following feedback is based on 8010a31 (current HEAD of master). >> >> Section 6.2, Request Authentication, states "Note that authentication vi= a >> signed JWS request bodies implies that GET requests are not authenticate= d. >> Servers MUST NOT respond to GET requests for resources that might be >> considered sensitive. Account resources are the only sensitive resources >> defined in this specification." >> >> Sections 8.2, HTTP; 8.3, TLS with Server Name Indication (TLS SNI); and >> 8.4, DNS, each describe a GET request and specify a "token" value which >> "MUST have at least 128 bits of entropy, in order to prevent an attacker >> from guessing it." >> >> This seems incongruous. If the token must be kept secret an attacker, it >> should not be served via an unauthenticated channel. >> >> Assuming secrecy of the token is not important, I would propose removing >> the entropy requirement and including some discussion of the token in >> Section 10, Security Considerations. >> >> Regards, >> Zach Shepherd >> >> >> _______________________________________________ >> Acme mailing list >> Acme@ietf.org >> https://www.ietf.org/mailman/listinfo/acme >> >> >> > > > _______________________________________________ > Acme mailing listAcme@ietf.orghttps://www.ietf.org/mailman/listinfo/acme > > > --001a1141d06057debb054bd12a38 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think Daniel's change at=C2=A0https://github.com/ietf-wg-acme/acme/pull/284/files=C2=A0is a nice quick fix to the issue, but I= agree it could use a few extra sentences explaining it in security conside= rations.

I will take a crack at amending this P= R with a few sentences in the security considerations section.=C2=A0
<= div class=3D"gmail-yj6qo gmail-ajU" style=3D"font-size:12.8px">
=

On Thu, Mar 23, 2= 017 at 3:24 PM, Jacob Hoffman-Andrews <jsha@eff.org> wrote:
=20 =20 =20
Yep, I think there are two ways of thinking about this, though it's effectively a single problem:

=C2=A01. Prevent attackers from tricking a validation endpoint into serving a valid challenge response.
=C2=A02. Prevent ACME clients from implementing a "naive" val= idation method that would make (1) trivial.

I think Daniel's change at https://gi= thub.com/ietf-wg-acme/acme/pull/284/files is a nice quick fix to the issue, but I agree it could use a few extra sentences explaining it in security considerations.


On 03/23/2017 10:3= 4 AM, Zach Shepherd wrote:
=20 =20

It seems like the goal of this is to ensure that the ACME client is not able to control (or, perhaps, even influence) the choice of token and requiring that the token be sufficiently random is one way to achieve this. This prevents an attacker from "tricking" the ACME server in= to using a verification performed by the owner of an identifier as proof that the attacker controls the identifier.


Is this accurate? If so, it seems like some version of this explanation should be included in the Security Considerations section.


From: Daniel McCarney <cpu@l= etsencrypt.org>
Sent: Wednesday, March 22, 2017 10:30 AM
To: Zach Shepherd
Cc: acme@ietf.org=
Subject: Re: [Acme] Entropy requirement for challenge token
=C2=A0
Hi Zach,

> This seems incongruous. If the token must be kept secret an attacker, it should not be served via an unauthenticated channel.

I agree the wording makes it incongruous, I was caught up on this the other week until it was clarified for me by Jacob.

The token is random not to prevent a guessing attack but to prevent the implementation of a server that can automatically reply to challenges without being a party to the authorization creation (e.g. knowing the token). It's OK for the token to be served via an unauthenticated channel, it just can't be predictable.<= br>
I took a crack at rewording this in=C2=A0https://github.com/ietf-wg-acme/acme/pull/284 - Hopefully if I'm completely off-base someone can correct it to be accurate & understandable.

On Wed, Mar 22, 2017 at 1:12 AM, Zach Shepherd <shepherdz@vmware.com> wrote:
The following feedback is based on 8010a31 (current HEAD of master).

Section 6.2, Request Authentication, states "Note that authentication via signed JWS reque= st bodies implies that GET requests are not authenticated. Servers MUST NOT respond to GET requests for resources that might be considered sensitive. Account resources are the only sensitive resources defined in this specification."

Sections 8.2, HTTP; 8.3, TLS with Server Name Indication (TLS SNI); and 8.4, DNS, each describe a GET request and specify a "token&qu= ot; value which "MUST have at least 128 bits of entropy, in order to prevent an attacker from guessing it."

This seems incongruous. If the token must be kept secret an attacker, it should not be served via an unauthenticated channel.

Assuming secrecy of the token is not important, I would propose removing the entropy requirement and including some discussion of the token in Section 10, Security Considerations.

Regards,
Zach Shepherd


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




_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/ma=
ilman/listinfo/acme


--001a1141d06057debb054bd12a38-- From nobody Tue Mar 28 15:04: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 28BE312967B for ; Tue, 28 Mar 2017 15:04:24 -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 (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 Pd3zVuWOoptA for ; Tue, 28 Mar 2017 15:04:20 -0700 (PDT) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::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 A1A5912945B for ; Tue, 28 Mar 2017 15:04:20 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id e75so72550060itd.1 for ; Tue, 28 Mar 2017 15:04:20 -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=DFmLv4ar2d8p2GpzS0kv4fwWhGI5EV/VLFhiJq8tq50=; b=Mc5SKzxH4ilznhoLomvYgSlj0p+rLw4yF163EiWO4dyhKCNoacEt45eVSBL5UsGLuf CrC0mhbORZd76CKP2NLWZQBthjMdFllDB5PMKiICkNJ5QP80pRk9IS77ujAzLG2aJ7oi DKB6YArpam2f1lwNvY0pGvX18gE1HVQuT/SFw= 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=DFmLv4ar2d8p2GpzS0kv4fwWhGI5EV/VLFhiJq8tq50=; b=eQnUoHm/Ej02Wy4MbhPhcsQ9xSMhefK8BYVR7MyI5pf6I/w542+PxASWXY6AQknTVF rEqRm4SxzTHRhu/THnlmeP2aMoeMLj6hpJjyO0mRQCoOUAmPfO9VhW4RKLn/lGxMmeo+ CVUOmfYCWFvVlX4G7u3MtbbyfiOcSBCTal4JMgzzpAt5tKRLOEYgD6vB3HVfom2j5Cf1 nXZuFPb+Fu8H/PQ1/sMwrXKRI8uCvJbpBqES2+RIU1Q2s2P1tSGL9bKaMITgRiRmaYbL hB5C+k3m9sj1Oqf6xUsyxD8CVsUqX2qV5DpaYMZy5Vvu4rMiPApm2aSonLC3STVDtHoy MKpw== X-Gm-Message-State: AFeK/H1xKM1X6RFfjKOwNhX6YEHNfUOHRGW5OTvHXJm1J9kyICZuz88cu+uEMZZbieqDKkxElNkpPeMpiB0mAwDU X-Received: by 10.107.150.201 with SMTP id y192mr33672566iod.33.1490738659669; Tue, 28 Mar 2017 15:04:19 -0700 (PDT) MIME-Version: 1.0 Reply-To: cpu@letsencrypt.org Received: by 10.107.9.147 with HTTP; Tue, 28 Mar 2017 15:04:18 -0700 (PDT) In-Reply-To: References: From: Daniel McCarney Date: Tue, 28 Mar 2017 18:04:18 -0400 Message-ID: To: Zach Shepherd Cc: "acme@ietf.org" Content-Type: multipart/alternative; boundary=001a1140ed344375cb054bd1a414 Archived-At: Subject: Re: [Acme] Allowing clients to understand the account creation functionality supported by a server 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, 28 Mar 2017 22:04:24 -0000 --001a1140ed344375cb054bd1a414 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I still think this is the wrong layer to solve this problem. If the crux of the matter is that `urn:ietf:params:acme:error:invalidContact` isn't sufficient to distinguish between invalid vs unsupported without parsing we could add a `urn:ietf:params:acme:error:unsupportedContact` error type and remove the need for parsing the message of the invalidContact error. This seems cleaner to me. I believe there will always be cases where a general purpose ACME client will attempt to use a feature unsupported by a given server and will have to react accordingly. Rather than try to preempt all of these cases by supplying metadata on all of the available options I'd favour refining the errors the server returns and promoting flexibility in handling them client side. On Thu, Mar 23, 2017 at 2:06 PM, Zach Shepherd wrote= : > Let's consider a simple world where all ACME servers support mailto and > some ACME servers support tel. > > To create an account, the user provides the necessary information to thei= r > AMCE client: one or more email addresses and zero or more phone numbers. > The ACME client then attempts to supply all of this information to in an > account creation request. Some of the time, this will result in an error > because the ACME server does not support tel. > > When the ACME client receives this error, it could: > 1. Display it to the user and ask the user to adjust their input > accordingly. (A poor user experience.) > 2. Attempt to parse to the error message to confirm that the problem was > the tel. (Hacky.) > 3. Assume that the problem was the tel and retry without that. (Very > hacky.) > > A new ACME server could come along that requires at least one tel or that > doesn't support mailto. As a result, ACME clients may chose to attempt #2 > and/or #3 before falling back to #1. > > This means that ACME clients have one of six different behaviors (#1, #2, > #3, #2 falling back to #1, #3 falling back to #1, #2 falling back to #3 > falling back to #1), some of which add a non-trivial amount of complexity > to attempt to parse error messages (yuck.) and some of which end up pushi= ng > the complexity onto the end-user in end anyways. (Or worse, ACME clients > wind up with hard-coded assumptions based on a specific ACME server > implementation and become less portable.) > > Providing information about the supported contact schemes in a machine > readable format (e.g., in response to a GET requests on the server's > new-account URI) does add work for ACME server implementors, but not so > much that it's worth complicating the end-user experience. > > Regards, > Zach > > ------------------------------ > *From:* Daniel McCarney > *Sent:* Wednesday, March 22, 2017 10:43 AM > *To:* Zach Shepherd > *Cc:* acme@ietf.org > *Subject:* Re: [Acme] Allowing clients to understand the account creation > functionality supported by a server > > Hi Zach, > > > It is undesirable that a client can only determine the supported scheme= s > for contact URLs by attempting to submit an unsupported URL. This makes i= t > difficult to implement a general-purpose client which can work with a > variety of servers which might each support a different set of contact > schemes. > > I feel your pain, but I'm hesitant to see more metadata/complexity put > into the /directory (I think the "meta" field of the directory resource > would be the best place if anywhere). My gut says it will be unlikely man= y > servers will allow contact URLs outside of "mailto:" and "tel:" and it > seems reasonably easy to handle the unsupported contact type error. For t= he > account fields we'd be adding complexity to simplify UI and I'm not > convinced yet its justified. > > Another note: If consensus is that we need a machine-readable way for > clients to know ahead of time what contact methods & account fields a > server supports we should also give the same consideration to identifier > types for Section 7.4.1's Pre-Authorization mechanism. A client may want = to > know what types of identifiers a server would pre-authorize. > > On Wed, Mar 22, 2017 at 1:13 AM, Zach Shepherd > wrote: > >> The following feedback is based on 8010a31 (current HEAD of master). >> >> Section 7.3, Account Creation, states "The server SHOULD validate that >> the contact URLs in the =E2=80=9Ccontact=E2=80=9D field are valid and su= pported by the >> server. If the client provides the server with an invalid or unsupported >> contact URL, then the server MUST return an error of type =E2=80=9Cinval= idContact=E2=80=9D, >> with a description describing the error and what types of contact URL th= e >> server considers acceptable." >> >> It is undesirable that a client can only determine the supported schemes >> for contact URLs by attempting to submit an unsupported URL. This makes = it >> difficult to implement a general-purpose client which can work with a >> variety of servers which might each support a different set of contact >> schemes. >> >> I would propose including information about the supported contact scheme= s >> in a machine readable format as a part of some GET request. >> >> >> Section 7.3, Account Creation, also states "A client creates a new >> account with the server by sending a POST request to the server=E2=80=99= s >> new-account URI. The body of the request is a stub account object >> containing the =E2=80=9Ccontact=E2=80=9D field and optionally the =E2=80= =9Cterms-of-service-agreed=E2=80=9D >> field. ... The server MUST ignore any values provided in the =E2=80=9Cor= ders=E2=80=9D >> fields in account bodies sent by the client, as well as any other fields >> that it does not recognize. If new fields are specified in the future, t= he >> specification of those fields MUST describe whether they can be provided= by >> the client." >> >> Similarly, it would be beneficial for a client to be able to determine >> the set of fields that a server does recognize so that it does not promp= t >> the user for information which the server will not make use of. >> >> I would propose including information about the fields which may be >> specified as a part of account creation in a machine readable format as = a >> part of some GET request. >> >> >> Together, these proposals could be addressed by responding to GET >> requests on the server's new-account URI with an object describing the >> client-specifiable account creation fields and applicable restrictions o= n >> each, such as the supported schemes for contacts URLs. >> >> Regards, >> Zach Shepherd >> >> >> _______________________________________________ >> Acme mailing list >> Acme@ietf.org >> https://www.ietf.org/mailman/listinfo/acme >> >> >> > --001a1140ed344375cb054bd1a414 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I still think this is the wrong layer to solve this proble= m. If the crux of the matter is that `urn:ietf:params:acme:error:invalidContact` isn't s= ufficient to distinguish between invalid vs unsupported without parsing we = could add a `ur= n:ietf:params:acme:error:unsupportedContact` error type and remove the= need for parsing the message of the invalidContact error. This seems clean= er to me.

I believe there will always be cases where a genera= l purpose ACME client will attempt to use a feature unsupported by a given = server and will have to react accordingly. Rather than try to preempt all o= f these cases by supplying metadata on all of the available options I'd= favour refining the errors the server returns and promoting flexibility in= handling them client side.=C2=A0

On Thu, Mar 23, 2017 at 2:06 PM, Zach Shepherd <s= hepherdz@vmware.com> wrote:
Let's consider a simple world where all ACME servers support mailt= o and some ACME servers support tel.

To create an account, the user provides the necessary information to their = AMCE client: one or more email addresses and zero or more phone numbers. Th= e ACME client then attempts to supply all of this information to in an acco= unt creation request. Some of the time, this will result in an error because the ACME server does not suppor= t tel.

When the ACME client receives this error, it could:
1. Display it to the user and ask the user to adjust their input accordingl= y. (A poor user experience.)
2. Attempt to parse to the error message to confirm that the problem was th= e tel. (Hacky.)
3. Assume that the problem was the tel and retry without that. (Very hacky.= )

A new ACME server could come along that requires at least one tel or that d= oesn't support mailto. As a result, ACME clients may chose to attempt #= 2 and/or #3 before falling back to #1.

This means that ACME clients have one of six different behaviors (#1, #2, #= 3, #2 falling back to #1, #3 falling back to #1, #2 falling back to #3 fall= ing back to #1), some of which add a non-trivial amount of complexity to at= tempt to parse error messages (yuck.) and some of which end up pushing the complexity onto the end-user in end a= nyways. (Or worse, ACME clients wind up with hard-coded assumptions based o= n a specific ACME server implementation and become less portable.)

Providing information about the supported contact schemes in a machine read= able format (e.g., in response to a GET requests on the server's new-ac= count URI) does add work for ACME server implementors, but not so much that= it's worth complicating the end-user experience.

Regards,
Zach

From: = Daniel McCarney <cpu@letsencrypt.org>
Sent: Wednesday, March 22, 2017 10:43 AM
To: Zach Shepherd
Cc: acme@ietf.org=
Subject: Re: [Acme] Allowing clients to understand the account creat= ion functionality supported by a server
=C2=A0
Hi Zach,

> It is undesirable that a client can only determine the supported schem= es for contact URLs by attempting to submit an unsupported URL. This makes = it difficult to implement a general-purpose client which can work with a va= riety of servers which might each support a different set of contact schemes.

I feel your pain, but I'm hesitant to see more metadata/complexity put = into the /directory (I think the "meta" field of the directory re= source would be the best place if anywhere).=C2=A0My gut says it will be un= likely many servers will allow contact URLs outside of "mailto:" and "tel:" and it seems reasonably easy t= o handle the unsupported contact type error. For the account fields we'= d be adding complexity to simplify UI and I'm not convinced yet its jus= tified.

Another note: If consensus is that we need a machine-readable way for clien= ts to know ahead of time what contact methods & account fields a server= supports we should also give the same consideration to identifier types fo= r Section 7.4.1's Pre-Authorization mechanism. A client may want to know what types of identifiers a server wo= uld pre-authorize.

On Wed, Mar 22, 2017 at 1:13 AM, Zach Shepherd <= span dir=3D"ltr"> <shepherdz@vmw= are.com> wrote:

The following feedback is based on 8010a31 (current HEAD of master).
Section 7.3, Account Creation, states "The server SHOULD validate that= the contact URLs in the =E2=80=9Ccontact=E2=80=9D field are valid and supp= orted by the server. If the client provides the server with an invalid or u= nsupported contact URL, then the server MUST return an error of type =E2=80=9CinvalidContact=E2=80=9D, with a description describ= ing the error and what types of contact URL the server considers acceptable= ."

It is undesirable that a client can only determine the supported schemes fo= r contact URLs by attempting to submit an unsupported URL. This makes it di= fficult to implement a general-purpose client which can work with a variety= of servers which might each support a different set of contact schemes.

I would propose including information about the supported contact schemes i= n a machine readable format as a part of some GET request.


Section 7.3, Account Creation, also states "A client creates a new acc= ount with the server by sending a POST request to the server=E2=80=99s new-= account URI. The body of the request is a stub account object containing th= e =E2=80=9Ccontact=E2=80=9D field and optionally the =E2=80=9Cterms-of-serv= ice-agreed=E2=80=9D field. ... The server MUST ignore any values provided in the =E2=80=9Corde= rs=E2=80=9D fields in account bodies sent by the client, as well as any oth= er fields that it does not recognize. If new fields are specified in the fu= ture, the specification of those fields MUST describe whether they can be provided by the client."

Similarly, it would be beneficial for a client to be able to determine the = set of fields that a server does recognize so that it does not prompt the u= ser for information which the server will not make use of.

I would propose including information about the fields which may be specifi= ed as a part of account creation in a machine readable format as a part of = some GET request.


Together, these proposals could be addressed by responding to GET requests = on the server's new-account URI with an object describing the client-sp= ecifiable account creation fields and applicable restrictions on each, such= as the supported schemes for contacts URLs.

Regards,
Zach Shepherd


_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mail= man/listinfo/acme



--001a1140ed344375cb054bd1a414-- From nobody Tue Mar 28 15:05:33 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 1F86E129691 for ; Tue, 28 Mar 2017 15:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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] 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 alD-5CsVG-QZ for ; Tue, 28 Mar 2017 15:05:30 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::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 C4E3612967B for ; Tue, 28 Mar 2017 15:05:29 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id o81so9226326wmb.1 for ; Tue, 28 Mar 2017 15:05:29 -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=XfnQnL+5taLY2kZ8IpELFJ0XpFJdqbMzaWXeTfKY7Pw=; b=yMLZOGKVMdYS+4bpT143thlu9qhIFD+txTcExbbc4P/zSwQjeDgELg6mZT6OlsisFh MuTxW/8Xp8Ku6m5xzJ1altApCC4g+XwNN1lE/h9yyPyaASjxIBose6qr+IzYGATF43h6 j8XlXzF4aHDruaEh58wlVPwoVpDFnQcuY2wM23zDVW7rUphI9pz8vwxGtKNomtzFhw0E v1aTm/YNWzQhCvnjXkFqwAwhusNb9caP/7wRHHjXEolYlVX06lAsImU5E8eTLs2t8VQ6 Zyv9JCalOoHkz4fJB4yFiw93P3CChhnIbaxlKVrS9aNS+LBoLLGSzfft+wTK1Cxq7sNS ET/A== 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=XfnQnL+5taLY2kZ8IpELFJ0XpFJdqbMzaWXeTfKY7Pw=; b=YLKUwKrdd4NO4E0NScLixnw4PgrCBEjNyX3bLS1m1JjAbJyrSY5+tTW9yuatPW8hYu X1Pq13F4yNfTERIImzeBr93BUfwBF+tQPzv5UKBNpUBvPtcyOyRjFE/tQXyIgYqlB/8m 5OJIiOa9I0qDDnNGn8VGcVPi7SCYEyQ2O+PTGbdr7UOCfJsWwVrdP/ll+heIPZ0x5QUO psvd3Mqjf8Xm7UPGc6qS5+HPFM2EhhfK0FA1V8HYmV9W/Yq7NmL1xxsvdxUdgQD0RzwX M8xorIqc/Kc7j0Wc2aGcRi2w2hGd9GF0UbzgsihE/Ub7gti6ErmXsH+rH1adovXJGfdn IyjQ== X-Gm-Message-State: AFeK/H2G19TvJ7e9xJ/7H0pLoWBTzqd7QL3NJuZ322+sWJoMSFydaw1oahBhixWKAkX29hhtQwdvqrRyKpfB4A== X-Received: by 10.28.153.20 with SMTP id b20mr11230768wme.76.1490738728100; Tue, 28 Mar 2017 15:05:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.40.69 with HTTP; Tue, 28 Mar 2017 15:05:27 -0700 (PDT) In-Reply-To: References: From: Richard Barnes Date: Tue, 28 Mar 2017 18:05:27 -0400 Message-ID: To: Erica Portnoy Cc: "acme@ietf.org" Content-Type: multipart/alternative; boundary=001a114b42ec576fcc054bd1a8be Archived-At: Subject: Re: [Acme] Require servers to accept at least one automated revocation method 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, 28 Mar 2017 22:05:32 -0000 --001a114b42ec576fcc054bd1a8be Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable There's no requirement for the server to have a revocation endpoint at all! """ The server MUST provide =E2=80=9Cdirectory=E2=80=9D and =E2=80=9Cnew-nonce= =E2=80=9D resources. """ ... not "revoke-cert". It's up to the CA which parts of ACME they use. The only way this would make sense is if it were framed as "for the revocation mechanism defined in this document, you must..." And in that case, I would be inclined to just upgrade all those SHOULDs to MUSTs. On Tue, Mar 28, 2017 at 5:26 PM, Erica Portnoy wrote: > Section 7.6 reads: > > Revocation requests are different from other ACME requests in that they > can be signed either with an account key pair or the key pair in the > certificate. Before revoking a certificate, the server MUST verify that > the key used to sign the request is authorized to revoke the > certificate. The server SHOULD consider at least the following accounts > authorized for a given certificate: > - the account that issued the certificate. > - an account that holds authorizations for all of the identifiers in the > certificate. > The server SHOULD also consider a revocation request valid if it is > signed with the private key corresponding to the public key in the > certificate. > > With this wording, the server is not required to accept any form of > automated revocation request. It should be able to accept at least one > form of revocation, even if only the account that issued the > certification, or any of the described methods but at least one. Either > of these would leave policy choices sufficiently flexible without > removing important functionality. > > Best, > Erica Portnoy > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > --001a114b42ec576fcc054bd1a8be Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
There's no requirement for the server to have a revoca= tion endpoint at all!

"""
The server MUST provide =E2=80=9Cdirec= tory=E2=80=9D and =E2=80=9Cnew-nonce=E2=80=9D resources.
"""

... not "revoke-cert&qu= ot;.=C2=A0 It's up to the CA which parts of ACME they use.
The only way this would make sense is if it were framed as &qu= ot;for the revocation mechanism defined in this document, you must..."= =C2=A0And in that case, I would be inclined to just upgrade all those SHOU= LDs to MUSTs.




On Tue, Mar 28, 2017 a= t 5:26 PM, Erica Portnoy <erica@eff.org> wrote:
Section 7.6 reads:

Revocation requests are different from other ACME requests in that they
can be signed either with an account key pair or the key pair in the
certificate. Before revoking a certificate, the server MUST verify that
the key used to sign the request is authorized to revoke the
certificate. The server SHOULD consider at least the following accounts
authorized for a given certificate:
- the account that issued the certificate.
- an account that holds authorizations for all of the identifiers in the certificate.
The server SHOULD also consider a revocation request valid if it is
signed with the private key corresponding to the public key in the
certificate.

With this wording, the server is not required to accept any form of
automated revocation request. It should be able to accept at least one
form of revocation, even if only the account that issued the
certification, or any of the described methods but at least one. Either
of these would leave policy choices sufficiently flexible without
removing important functionality.

Best,
Erica Portnoy

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

--001a114b42ec576fcc054bd1a8be-- From nobody Tue Mar 28 15:14: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 9BD4B1271DF for ; Tue, 28 Mar 2017 15:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.61 X-Spam-Level: X-Spam-Status: No, score=-0.61 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_LOW=-0.7] 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 9rmS4O_2iHYe for ; Tue, 28 Mar 2017 15:14:51 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::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 D8958127076 for ; Tue, 28 Mar 2017 15:14:50 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id t189so10268300wmt.1 for ; Tue, 28 Mar 2017 15:14:50 -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=r/V3soUz69m6iik48CC7hVkn67Dj1AT7AJYtwcngmXI=; b=sZUNdgqDICrFiR9Aze5YrXCCSjamas0psy1SeFHzhKTr198kB4nMWN+J8/du38UezG RMpXAJuUZkHYI9ChrVtaN5WujR+TffWKr/cc6pNIqAQyp7wnS6d9M+VtLGa2LZMm+iko rLuE6j5Vd+XtLLecqX+ZFru3s44iVvrjQQEPrk3oTiRJnaQB/TB01oP/+0vyujoH1utk XonjmWnKNzOGcRXD5QOHoZf39GMK2pk4IF7RM32g2SOHdQPDNbH7+6b+HU5SaGbKzUSW 536/G98MBUoPKwUfIEMCl7fgGB8ug0jH7z3lrjSeOC4Fyws6TDJpOU8CuI9bylqwiUwt txpA== 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=r/V3soUz69m6iik48CC7hVkn67Dj1AT7AJYtwcngmXI=; b=Y3jnlt1OLGDDyaySx8vkaUyxkjIEWhk794ydVjmUMnFFaXJDuVWRmIKu0NMZ2BB/e8 JRqQClS9FuPxorUkDcZnb6rWYI8bJ6Jy2iPBQ9AQ/NzvxVM9FLBw4Ym4MhLD2QnjwUGR 44wzf+ujjY5BCa+irp6+AyZg/MWGlUUEffUMR2F2OzHDAFUWk4MnOp4ACh/4N5Lu32RL vdCKaCMUGIh595138vD1+Mxrl5XuRf7aIOx1vt3IPh0FHh0C5lxSbm4beQOZ6GTJPYwK l0ITmDRaIxhXhVODkHKOZX8hulsnasD8ck7lN1WblQ2AWP2post78rRrls/G9zFRI7xe CoOA== X-Gm-Message-State: AFeK/H17PIrmWqC3ObIepmInqJkqYlKYj0AWwW0vjVzuzWAaxdCwwbHUdVrww6kcZIGfTvZVVACb4wINIK6OEQ== X-Received: by 10.28.88.2 with SMTP id m2mr16675230wmb.12.1490739289107; Tue, 28 Mar 2017 15:14:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.40.69 with HTTP; Tue, 28 Mar 2017 15:14:48 -0700 (PDT) In-Reply-To: References: From: Richard Barnes Date: Tue, 28 Mar 2017 18:14:48 -0400 Message-ID: To: Daniel McCarney Cc: Zach Shepherd , "acme@ietf.org" Content-Type: multipart/alternative; boundary=001a11442c66c7dd59054bd1c91b Archived-At: Subject: Re: [Acme] Allowing clients to understand the account creation functionality supported by a server 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, 28 Mar 2017 22:14:55 -0000 --001a11442c66c7dd59054bd1c91b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dumping some of this info in `directory.meta` doesn't really seem that tragic to me. It's not that much information, and could avoid some errors. I would note, however, that we could also do this in an extension, rather than in the main spec. On Tue, Mar 28, 2017 at 6:04 PM, Daniel McCarney wrote: > I still think this is the wrong layer to solve this problem. If the crux > of the matter is that `urn:ietf:params:acme:error:invalidContact` isn't > sufficient to distinguish between invalid vs unsupported without parsing = we > could add a `urn:ietf:params:acme:error:unsupportedContact` error type > and remove the need for parsing the message of the invalidContact error. > This seems cleaner to me. > > I believe there will always be cases where a general purpose ACME client > will attempt to use a feature unsupported by a given server and will have > to react accordingly. Rather than try to preempt all of these cases by > supplying metadata on all of the available options I'd favour refining th= e > errors the server returns and promoting flexibility in handling them clie= nt > side. > > On Thu, Mar 23, 2017 at 2:06 PM, Zach Shepherd > wrote: > >> Let's consider a simple world where all ACME servers support mailto and >> some ACME servers support tel. >> >> To create an account, the user provides the necessary information to >> their AMCE client: one or more email addresses and zero or more phone >> numbers. The ACME client then attempts to supply all of this information= to >> in an account creation request. Some of the time, this will result in an >> error because the ACME server does not support tel. >> >> When the ACME client receives this error, it could: >> 1. Display it to the user and ask the user to adjust their input >> accordingly. (A poor user experience.) >> 2. Attempt to parse to the error message to confirm that the problem was >> the tel. (Hacky.) >> 3. Assume that the problem was the tel and retry without that. (Very >> hacky.) >> >> A new ACME server could come along that requires at least one tel or tha= t >> doesn't support mailto. As a result, ACME clients may chose to attempt #= 2 >> and/or #3 before falling back to #1. >> >> This means that ACME clients have one of six different behaviors (#1, #2= , >> #3, #2 falling back to #1, #3 falling back to #1, #2 falling back to #3 >> falling back to #1), some of which add a non-trivial amount of complexit= y >> to attempt to parse error messages (yuck.) and some of which end up push= ing >> the complexity onto the end-user in end anyways. (Or worse, ACME clients >> wind up with hard-coded assumptions based on a specific ACME server >> implementation and become less portable.) >> >> Providing information about the supported contact schemes in a machine >> readable format (e.g., in response to a GET requests on the server's >> new-account URI) does add work for ACME server implementors, but not so >> much that it's worth complicating the end-user experience. >> >> Regards, >> Zach >> >> ------------------------------ >> *From:* Daniel McCarney >> *Sent:* Wednesday, March 22, 2017 10:43 AM >> *To:* Zach Shepherd >> *Cc:* acme@ietf.org >> *Subject:* Re: [Acme] Allowing clients to understand the account >> creation functionality supported by a server >> >> Hi Zach, >> >> > It is undesirable that a client can only determine the supported >> schemes for contact URLs by attempting to submit an unsupported URL. Thi= s >> makes it difficult to implement a general-purpose client which can work >> with a variety of servers which might each support a different set of >> contact schemes. >> >> I feel your pain, but I'm hesitant to see more metadata/complexity put >> into the /directory (I think the "meta" field of the directory resource >> would be the best place if anywhere). My gut says it will be unlikely ma= ny >> servers will allow contact URLs outside of "mailto:" and "tel:" and it >> seems reasonably easy to handle the unsupported contact type error. For = the >> account fields we'd be adding complexity to simplify UI and I'm not >> convinced yet its justified. >> >> Another note: If consensus is that we need a machine-readable way for >> clients to know ahead of time what contact methods & account fields a >> server supports we should also give the same consideration to identifier >> types for Section 7.4.1's Pre-Authorization mechanism. A client may want= to >> know what types of identifiers a server would pre-authorize. >> >> On Wed, Mar 22, 2017 at 1:13 AM, Zach Shepherd >> wrote: >> >>> The following feedback is based on 8010a31 (current HEAD of master). >>> >>> Section 7.3, Account Creation, states "The server SHOULD validate that >>> the contact URLs in the =E2=80=9Ccontact=E2=80=9D field are valid and s= upported by the >>> server. If the client provides the server with an invalid or unsupporte= d >>> contact URL, then the server MUST return an error of type =E2=80=9Cinva= lidContact=E2=80=9D, >>> with a description describing the error and what types of contact URL t= he >>> server considers acceptable." >>> >>> It is undesirable that a client can only determine the supported scheme= s >>> for contact URLs by attempting to submit an unsupported URL. This makes= it >>> difficult to implement a general-purpose client which can work with a >>> variety of servers which might each support a different set of contact >>> schemes. >>> >>> I would propose including information about the supported contact >>> schemes in a machine readable format as a part of some GET request. >>> >>> >>> Section 7.3, Account Creation, also states "A client creates a new >>> account with the server by sending a POST request to the server=E2=80= =99s >>> new-account URI. The body of the request is a stub account object >>> containing the =E2=80=9Ccontact=E2=80=9D field and optionally the =E2= =80=9Cterms-of-service-agreed=E2=80=9D >>> field. ... The server MUST ignore any values provided in the =E2=80=9Co= rders=E2=80=9D >>> fields in account bodies sent by the client, as well as any other field= s >>> that it does not recognize. If new fields are specified in the future, = the >>> specification of those fields MUST describe whether they can be provide= d by >>> the client." >>> >>> Similarly, it would be beneficial for a client to be able to determine >>> the set of fields that a server does recognize so that it does not prom= pt >>> the user for information which the server will not make use of. >>> >>> I would propose including information about the fields which may be >>> specified as a part of account creation in a machine readable format as= a >>> part of some GET request. >>> >>> >>> Together, these proposals could be addressed by responding to GET >>> requests on the server's new-account URI with an object describing the >>> client-specifiable account creation fields and applicable restrictions = on >>> each, such as the supported schemes for contacts URLs. >>> >>> Regards, >>> Zach Shepherd >>> >>> >>> _______________________________________________ >>> 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 > > --001a11442c66c7dd59054bd1c91b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dumping some of this info in `directory.meta` doesn't = really seem that tragic to me.=C2=A0 It's not that much information, an= d could avoid some errors.

I would note, however, that w= e could also do this in an extension, rather than in the main spec.

On Tue, Mar 2= 8, 2017 at 6:04 PM, Daniel McCarney <cpu@letsencrypt.org> = wrote:
I still think thi= s is the wrong layer to solve this problem. If the crux of the matter is th= at `urn:ietf:params:ac= me:error:invalidContact` isn't sufficient to distinguish between i= nvalid vs unsupported without parsing we could add a `urn:ietf:params:acme:error:unsu= pportedContact` error type and remove the need for parsing the message of t= he invalidContact error. This seems cleaner to me.

I believe = there will always be cases where a general purpose ACME client will attempt= to use a feature unsupported by a given server and will have to react acco= rdingly. Rather than try to preempt all of these cases by supplying metadat= a on all of the available options I'd favour refining the errors the se= rver returns and promoting flexibility in handling them client side.=C2=A0<= /div>
On Thu, Mar 23, 2017 at 2:06 PM, Zach Shepherd = <shepherdz@vmware.com> wrote:
Let's consider a simple world where all ACME servers support mailt= o and some ACME servers support tel.

To create an account, the user provides the necessary information to their = AMCE client: one or more email addresses and zero or more phone numbers. Th= e ACME client then attempts to supply all of this information to in an acco= unt creation request. Some of the time, this will result in an error because the ACME server does not suppor= t tel.

When the ACME client receives this error, it could:
1. Display it to the user and ask the user to adjust their input accordingl= y. (A poor user experience.)
2. Attempt to parse to the error message to confirm that the problem was th= e tel. (Hacky.)
3. Assume that the problem was the tel and retry without that. (Very hacky.= )

A new ACME server could come along that requires at least one tel or that d= oesn't support mailto. As a result, ACME clients may chose to attempt #= 2 and/or #3 before falling back to #1.

This means that ACME clients have one of six different behaviors (#1, #2, #= 3, #2 falling back to #1, #3 falling back to #1, #2 falling back to #3 fall= ing back to #1), some of which add a non-trivial amount of complexity to at= tempt to parse error messages (yuck.) and some of which end up pushing the complexity onto the end-user in end a= nyways. (Or worse, ACME clients wind up with hard-coded assumptions based o= n a specific ACME server implementation and become less portable.)

Providing information about the supported contact schemes in a machine read= able format (e.g., in response to a GET requests on the server's new-ac= count URI) does add work for ACME server implementors, but not so much that= it's worth complicating the end-user experience.

Regards,
Zach

From: Daniel McCarney <cpu@letsencrypt.org>
Sent: Wednesday, March 22, 2017 10:43 AM
To: Zach Shepherd
Cc: acme@ietf.org=
Subject: Re: [Acme] Allowing clients to understand the account creat= ion functionality supported by a server
=C2=A0
Hi Zach,

> It is undesirable that a client can only determine the supported schem= es for contact URLs by attempting to submit an unsupported URL. This makes = it difficult to implement a general-purpose client which can work with a va= riety of servers which might each support a different set of contact schemes.

I feel your pain, but I'm hesitant to see more metadata/complexity put = into the /directory (I think the "meta" field of the directory re= source would be the best place if anywhere).=C2=A0My gut says it will be un= likely many servers will allow contact URLs outside of "mailto:" and "tel:" and it seems reasonably easy t= o handle the unsupported contact type error. For the account fields we'= d be adding complexity to simplify UI and I'm not convinced yet its jus= tified.

Another note: If consensus is that we need a machine-readable way for clien= ts to know ahead of time what contact methods & account fields a server= supports we should also give the same consideration to identifier types fo= r Section 7.4.1's Pre-Authorization mechanism. A client may want to know what types of identifiers a server wo= uld pre-authorize.

On Wed, Mar 22, 2017 at 1:13 AM, Zach Shepherd <= span dir=3D"ltr"> <shepherdz@vmw= are.com> wrote:

The following feedback is based on 8010a31 (current HEAD of master).
Section 7.3, Account Creation, states "The server SHOULD validate that= the contact URLs in the =E2=80=9Ccontact=E2=80=9D field are valid and supp= orted by the server. If the client provides the server with an invalid or u= nsupported contact URL, then the server MUST return an error of type =E2=80=9CinvalidContact=E2=80=9D, with a description describ= ing the error and what types of contact URL the server considers acceptable= ."

It is undesirable that a client can only determine the supported schemes fo= r contact URLs by attempting to submit an unsupported URL. This makes it di= fficult to implement a general-purpose client which can work with a variety= of servers which might each support a different set of contact schemes.

I would propose including information about the supported contact schemes i= n a machine readable format as a part of some GET request.


Section 7.3, Account Creation, also states "A client creates a new acc= ount with the server by sending a POST request to the server=E2=80=99s new-= account URI. The body of the request is a stub account object containing th= e =E2=80=9Ccontact=E2=80=9D field and optionally the =E2=80=9Cterms-of-serv= ice-agreed=E2=80=9D field. ... The server MUST ignore any values provided in the =E2=80=9Corde= rs=E2=80=9D fields in account bodies sent by the client, as well as any oth= er fields that it does not recognize. If new fields are specified in the fu= ture, the specification of those fields MUST describe whether they can be provided by the client."

Similarly, it would be beneficial for a client to be able to determine the = set of fields that a server does recognize so that it does not prompt the u= ser for information which the server will not make use of.

I would propose including information about the fields which may be specifi= ed as a part of account creation in a machine readable format as a part of = some GET request.


Together, these proposals could be addressed by responding to GET requests = on the server's new-account URI with an object describing the client-sp= ecifiable account creation fields and applicable restrictions on each, such= as the supported schemes for contacts URLs.

Regards,
Zach Shepherd


_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mail= man/listinfo/acme




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


--001a11442c66c7dd59054bd1c91b-- From nobody Tue Mar 28 15:48:58 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 C5EB3126DEE for ; Tue, 28 Mar 2017 15:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.799 X-Spam-Level: X-Spam-Status: No, score=-9.799 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, RCVD_IN_MSPIKE_H2=-2.796, 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 Dp4MeKwl6jQj for ; Tue, 28 Mar 2017 15:48:54 -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 ACB1E127011 for ; Tue, 28 Mar 2017 15:48:54 -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=wfT4jghdXw+Oq0LY9EqU4lemgefwqkvYhPmMlTE1kWg=; b=wZax3WCHozvrtcIxdY6tM95sG9BWeGCfLf6mqw/3hOvJ7K4vEcNSG1LcNelHZvdZiCj5HbRrlCcIS/6fxqFPXoSyGkpWz2dbcfFEko4nro3NeMHxshtRglnT6ScDL+jfAz13n3CXxMS0+Znfet7XpXLWluVKcSOUG/qiwLyzBjQ=; Received: ; Tue, 28 Mar 2017 15:48:52 -0700 To: Hugo Landau , acme@ietf.org References: <20170325164023.GA7854@andover.lhh.devever.net> From: Jacob Hoffman-Andrews Message-ID: Date: Tue, 28 Mar 2017 15:48:51 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170325164023.GA7854@andover.lhh.devever.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Received-SPF: skipped for local relay Archived-At: Subject: Re: [Acme] Retrying failed authorizations 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, 28 Mar 2017 22:48:57 -0000 On 03/25/2017 09:40 AM, Hugo Landau wrote: > Currently, when an order is created, authorizations are created for it,= > and challenges are created for each of those authorizations. > > If a challenge is failed once, the challenge comes to have status > "invalid", as does the authorization containing it. The order containin= g > the authorization becomes unfulfillable. I agree that this is an issue; You and I talked about it previously in the thread "New application flow and retries," but didn't get much feedback from the rest of the group. Note that authz's are recyclable, so the impact is not quite so bad as you describe. But even if you just consider the CSR, each new-order is fairly expensive. A minimum of 1k of storage for a CSR with a 2048-bit RSA key. Under the current model, a client that is having validation problems and retries repeatedly will consume at least 1k of database space per try. As a result, CAs will likely need to limit new-order creations rather strictly, which makes life harder for clients. I think the way CAs traditionally handle this is as you suggest: by making challenges retryable. Note that this implies that orders typically never get invalidated, they just expire after some period of time (or error out if there's a problem during issuance, like CAA). This also implies that clients would potentially need to keep state across invocations. Specifically, clients would need to store the private keys used for extant orders, so if a subsequent run completes an order, the client is able to use the resulting certificate. What's your thought on the additional burden on clients? What is the rest of the group's thoughts on whether we'd have to restart WGLC for this? From nobody Tue Mar 28 18:25:50 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 9D60412956B for ; Tue, 28 Mar 2017 18:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.797 X-Spam-Level: X-Spam-Status: No, score=-9.797 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, RCVD_IN_MSPIKE_H2=-2.796, 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 o3nppCqRteAO for ; Tue, 28 Mar 2017 18:25:46 -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 C856B1273B1 for ; Tue, 28 Mar 2017 18:25:46 -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:To:Subject; bh=p1fLy71hGzk0eSyLsQmBh8Bi6Vnzx8XBfBxeafKRlw0=; b=IKs0Tke1ZVoVP9nLF9Qe+MzVVGNHL67CPhmMbYab8B6xLEgo41hYrkLIno81h9uMXbhuTn5IFfSVKvN74QUt7wcKpSz6zkKR2rV792fN9LxCfCxYuFowBNhHYcinObAy3etKfMm5GC425HxB5zEd/jptY2p4VwfZHfqEms9IcbU=; Received: ; Tue, 28 Mar 2017 18:25:46 -0700 To: acme@ietf.org References: From: Erica Portnoy Message-ID: Date: Tue, 28 Mar 2017 18:25:46 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------56B9D9495955510C43DD8A2F" Received-SPF: skipped for local relay Archived-At: Subject: Re: [Acme] Require servers to accept at least one automated revocation method 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, 29 Mar 2017 01:25:50 -0000 This is a multi-part message in MIME format. --------------56B9D9495955510C43DD8A2F Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit The other endpoints' sections in the document are written using language assuming that that endpoint is implemented, so it makes sense to do the same thing here. So given that there's a revocation endpoint, you're saying that all of the revocation authorization methods mentioned must be considered valid? That seems like overkill. On 03/28/2017 03:05 PM, Richard Barnes wrote: > There's no requirement for the server to have a revocation endpoint at > all! > > """ > The server MUST provide “directory” and “new-nonce” resources. > """ > > ... not "revoke-cert". It's up to the CA which parts of ACME they use. > > The only way this would make sense is if it were framed as "for the > revocation mechanism defined in this document, you must..." And in > that case, I would be inclined to just upgrade all those SHOULDs to MUSTs. > > > > > On Tue, Mar 28, 2017 at 5:26 PM, Erica Portnoy > wrote: > > Section 7.6 reads: > > Revocation requests are different from other ACME requests in that > they > can be signed either with an account key pair or the key pair in the > certificate. Before revoking a certificate, the server MUST verify > that > the key used to sign the request is authorized to revoke the > certificate. The server SHOULD consider at least the following > accounts > authorized for a given certificate: > - the account that issued the certificate. > - an account that holds authorizations for all of the identifiers > in the > certificate. > The server SHOULD also consider a revocation request valid if it is > signed with the private key corresponding to the public key in the > certificate. > > With this wording, the server is not required to accept any form of > automated revocation request. It should be able to accept at least one > form of revocation, even if only the account that issued the > certification, or any of the described methods but at least one. > Either > of these would leave policy choices sufficiently flexible without > removing important functionality. > > Best, > Erica Portnoy > > _______________________________________________ > 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 --------------56B9D9495955510C43DD8A2F Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit The other endpoints' sections in the document are written using language assuming that that endpoint is implemented, so it makes sense to do the same thing here.

So given that there's a revocation endpoint, you're saying that all of the revocation authorization methods mentioned must be considered valid? That seems like overkill.

On 03/28/2017 03:05 PM, Richard Barnes wrote:
There's no requirement for the server to have a revocation endpoint at all!

"""
The server MUST provide “directory” and “new-nonce” resources.
"""

... not "revoke-cert".  It's up to the CA which parts of ACME they use.

The only way this would make sense is if it were framed as "for the revocation mechanism defined in this document, you must..."  And in that case, I would be inclined to just upgrade all those SHOULDs to MUSTs.




On Tue, Mar 28, 2017 at 5:26 PM, Erica Portnoy <erica@eff.org> wrote:
Section 7.6 reads:

Revocation requests are different from other ACME requests in that they
can be signed either with an account key pair or the key pair in the
certificate. Before revoking a certificate, the server MUST verify that
the key used to sign the request is authorized to revoke the
certificate. The server SHOULD consider at least the following accounts
authorized for a given certificate:
- the account that issued the certificate.
- an account that holds authorizations for all of the identifiers in the
certificate.
The server SHOULD also consider a revocation request valid if it is
signed with the private key corresponding to the public key in the
certificate.

With this wording, the server is not required to accept any form of
automated revocation request. It should be able to accept at least one
form of revocation, even if only the account that issued the
certification, or any of the described methods but at least one. Either
of these would leave policy choices sufficiently flexible without
removing important functionality.

Best,
Erica Portnoy

_______________________________________________
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

--------------56B9D9495955510C43DD8A2F-- From nobody Tue Mar 28 23:34:43 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 9F922127241 for ; Tue, 28 Mar 2017 23:34:42 -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, 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 (1024-bit key) header.d=kelunik.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 1gQsTre_b3YH for ; Tue, 28 Mar 2017 23:34:39 -0700 (PDT) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::11]) (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 5A90E1292D0 for ; Tue, 28 Mar 2017 23:34:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1490769277; l=9357; s=domk; d=kelunik.com; h=Content-Type:Cc:To:Subject:Date:From:In-Reply-To:References: MIME-Version; bh=+au2ztG/pwhanuPzhxtNwt767WCQ7vaS/ZpqlWqPv2A=; b=F3tk75iZCmDr2xC2zFtrvWPXaenO6v8f59WpdlzeAEk1GhystSIouXyRJd8CX8oerG vOQwNyYGi40jIjmWF9G3uIsQv5zEvV9rnvJg2ak7Tx3E3YBHpjUxxWj/MDh2kWrDC3PL 57tqTqI/wyFbrjGRk59Q69rLGgcIX7oO1MBm0= X-RZG-AUTH: :IWkkfkWkbvHsXQGmRYmUo9mls2vWuiu+7SLDup6E67mzuoNJBqDwskQ= X-RZG-CLASS-ID: mo00 Received: by mail-qt0-f182.google.com with SMTP id r45so4865568qte.3 for ; Tue, 28 Mar 2017 23:34:36 -0700 (PDT) X-Gm-Message-State: AFeK/H1INorpVlO9xjpm1pwJz+6z0WWHVimww6vtiBUtMW1Xiv2Wgnk5Vn4W7mG3/EmrDhL3RvUSQsUfoMleaQ== X-Received: by 10.200.42.151 with SMTP id b23mr29136530qta.163.1490769275761; Tue, 28 Mar 2017 23:34:35 -0700 (PDT) MIME-Version: 1.0 References: <149064661967.30603.4913027353921499080.idtracker@ietfa.amsl.com> <20170328190803.GA6899@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: From: Niklas Keller Date: Wed, 29 Mar 2017 06:34:25 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Richard Barnes , Ilari Liusvaara Cc: "acme@ietf.org" , Roland Shoemaker Content-Type: multipart/alternative; boundary=001a1142f5c21fec9b054bd8c556 Archived-At: Subject: Re: [Acme] Fwd: New Version Notification for draft-shoemaker-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, 29 Mar 2017 06:34:43 -0000 --001a1142f5c21fec9b054bd8c556 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable >From RFC 2616: A client MUST include a Host header field in all HTTP/1.1 request messages . If the requested URI does not include an Internet host name for the service being requested, then the Host header field MUST be given with an empty value. I guess an IP address is not considered an Internet host name and thus the Host header must be empty. Regards, Niklas Richard Barnes schrieb am Di., 28. M=C3=A4rz 2017, 21:13: > On Tue, Mar 28, 2017 at 3:08 PM, Ilari Liusvaara > wrote: > > On Mon, Mar 27, 2017 at 07:28:53PM -0400, Richard Barnes wrote: > > Thanks, Roland. Interesting draft. > > > > Couple of first reactions: > > > > - Why use the target of the PTR instead of just provisioning the TXT > record > > directly in the reverse DNS. (Is there some restriction in the spec fo= r > > reverse DNS that says it's only PTR?) It seems like by using the PTR > > target, your security analysis gets much more complicated. > > Reading proposed IP validation rules in CABForum, using PTR target would > certainly qualify, whereas putting TXT record on the name probably does > not. > > The proposed rules have nothing on DNS apart from PTR lookups. > > (The current rules have "other equivalent method" clause.) > > So my reading is, that one has to do the PTR lookup in order to remain > compliant with BRs after the proposed tighening of IP validation goes > through (I expect it to). > > > - For the re-use of "http-01", you should probably specify the contents > of > > the Host header. (Main ACME should probably clarify that for DNS, if > it's > > not clear already.) > > Reading the proposed and current rules, the challenge is either invoked > on IP address itself, or on reverse-DNS lookup of it. So if you don't > do rDNS lookup, then the validation is invoked on IP address itself, > which I think leads to empty Host-header. > > > Au contraire! > > rbarnes$ nc -l 8080 >/dev/null & > rbarnes$ curl -v http://127.0.0.1:8080 > * Rebuilt URL to: http://127.0.0.1:8080/ > * Trying 127.0.0.1... > * TCP_NODELAY set > * Connected to 127.0.0.1 (127.0.0.1) port 8080 (#0) > > GET / HTTP/1.1 > > Host: 127.0.0.1:8080 > > User-Agent: curl/7.51.0 > > Accept: */* > > > > Guess this is good evidence that we should document this :) > > > > TLS-SNI-02 would work as usual (the proposed rules explicitly list > method 10, which is what TLS-SNI-02 falls under). Existing rules don't > say anything (but again, equivalent method clause exists). > > > > > > -Ilari > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > --001a1142f5c21fec9b054bd8c556 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

From RFC 2616:

A client MUST include a Host header field in all HTTP/1.1 re= quest messages . If the requested URI does not include an Internet host nam= e for the service being requested, then the Host header field MUST be given= with an empty value.

I guess an IP address is not considered an Internet host nam= e and thus the Host header must be empty.

Regards, Niklas


Richard Barnes <rlb@ipv.= sx> schrieb am Di., 28. M=C3=A4rz 2017, 21:13:
On Tue, Mar 28, 2017 at = 3:08 PM, Ilari Liusvaara <= ilariliusvaara@welho.com> wrote:
On Mon, Mar 27, 2017 at 07:28:53PM -0400= , Richard Barnes wrote:
> Thanks, Roland.=C2=A0 Interesting draft.
>
> Couple of first reactions:
>
> - Why use the target of the PTR instead of just provisioning the TXT r= ecord
> directly in the reverse DNS.=C2=A0 (Is there some restriction in the s= pec for
> reverse DNS that says it's only PTR?)=C2=A0 It seems like by using= the PTR
> target, your security analysis gets much more complicated.

Reading proposed IP validation rules in CABForum, using PTR target w= ould
certainly qualify, whereas putting TXT record on the name probably does
not.

The proposed rules have nothing on DNS apart from PTR lookups.

(The current rules have "other equivalent method" clause.)

So my reading is, that one has to do the PTR lookup in order to remain
compliant with BRs after the proposed tighening of IP validation goes
through (I expect it to).

> - For the re-use of "http-01", you should probably specify t= he contents of
> the Host header.=C2=A0 (Main ACME should probably clarify that for DNS= , if it's
> not clear already.)

Reading the proposed and current rules, the challenge is either invo= ked
on IP address itself, or on reverse-DNS lookup of it. So if you don't do rDNS lookup, then the validation is invoked on IP address itself,
which I think leads to empty Host-header.

=
Au contraire!=

rbarnes$ nc -l 8080 >/dev/null &=
rbarnes$ curl -v http:= //127.0.0.1:8080
* Rebuilt URL to: http://1= 27.0.0.1:8080/
* =C2=A0 Trying 127.0.0.1.= ..
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 8080 (#0)
> GET / HTTP/1.1
> Host:= 12= 7.0.0.1:8080
> User-Agent: curl/7.51.0=
> Accept: */*
>=C2=A0

Guess this is good evidence that we sho= uld document this :)
=C2=A0

TLS-SNI-02 would work as usual (the proposed rules explicitly list
method 10, which is what TLS-SNI-02 falls under). Existing rules don't<= br class=3D"gmail_msg"> say anything (but again, equivalent method clause exists).





-Ilari
_______________________________________________
Acme mailing list
Acme= @ietf.org
https://www.ietf.org/mailman/listinfo/= acme
--001a1142f5c21fec9b054bd8c556-- From nobody Wed Mar 29 05:02: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 7695E1296BE for ; Wed, 29 Mar 2017 05:02:00 -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, SPF_FAIL=0.001, SPF_HELO_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 pwrdDL8uq0c1 for ; Wed, 29 Mar 2017 05:01:53 -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 62B93129477 for ; Wed, 29 Mar 2017 05:01:52 -0700 (PDT) Received: from host249.freudenhaus.alandoherty.net ([193.120.128.249]:3071 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 1ctCIN-0002cE-D1 ; Wed, 29 Mar 2017 12:01:49 +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, 29 Mar 2017 13:01:44 +0100 To: Niklas Keller ,Richard Barnes , Ilari Liusvaara From: Alan Doherty Cc: "acme@ietf.org" , Roland Shoemaker In-Reply-To: References: <149064661967.30603.4913027353921499080.idtracker@ietfa.amsl.com> <20170328190803.GA6899@LK-Perkele-V2.elisa-laajakaista.fi> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-Id: X-VIRUS: NONE {no virus found, This is no guarentee} Archived-At: Subject: Re: [Acme] Fwd: New Version Notification for draft-shoemaker-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, 29 Mar 2017 12:02:00 -0000 all i know is if i browse to http://the-ip-of-my-site i hit the vhost that matches the name the-ip-of-my-site not the default vhost for 'empty hostname' so i know that no http1.1 browser seen yet sends empty host header when browsing to an ip (as the empty/unmatched host header vhost responds with a page offering http1.0 links to all the sites, and http1.0 compatible links to download http1.1 compatible clients (amazingly few browsers can be downloaded with a http1.0 client btw) (tested with ncsa mosaic v1 ish) and gets extremely few hits ever but the ip as name vhost sees hundreds of hits an hour from probes/bots/attackers and logs/redirects or blacklists them based on attack type seen At 07:34 29/03/2017 Wednesday, Niklas Keller wrote: >From RFC 2616: > >A client MUST include a Host header field in all HTTP/1.1 request messages . If the requested URI does not include an Internet host name for the service being requested, then the Host header field MUST be given with an empty value. > >I guess an IP address is not considered an Internet host name and thus the Host header must be empty. > >Regards, Niklas > >Richard Barnes schrieb am Di., 28. März 2017, 21:13: >On Tue, Mar 28, 2017 at 3:08 PM, Ilari Liusvaara <ilariliusvaara@welho.com> wrote: >On Mon, Mar 27, 2017 at 07:28:53PM -0400, Richard Barnes wrote: >> Thanks, Roland. Interesting draft. >> >> Couple of first reactions: >> >> - Why use the target of the PTR instead of just provisioning the TXT record >> directly in the reverse DNS. (Is there some restriction in the spec for >> reverse DNS that says it's only PTR?) It seems like by using the PTR >> target, your security analysis gets much more complicated. > >Reading proposed IP validation rules in CABForum, using PTR target would >certainly qualify, whereas putting TXT record on the name probably does >not. > >The proposed rules have nothing on DNS apart from PTR lookups. > >(The current rules have "other equivalent method" clause.) > >So my reading is, that one has to do the PTR lookup in order to remain >compliant with BRs after the proposed tighening of IP validation goes >through (I expect it to). > >> - For the re-use of "http-01", you should probably specify the contents of >> the Host header. (Main ACME should probably clarify that for DNS, if it's >> not clear already.) > >Reading the proposed and current rules, the challenge is either invoked >on IP address itself, or on reverse-DNS lookup of it. So if you don't >do rDNS lookup, then the validation is invoked on IP address itself, >which I think leads to empty Host-header. > > >Au contraire! > >rbarnes$ nc -l 8080 >/dev/null & >rbarnes$ curl -v http://127.0.0.1:8080 >* Rebuilt URL to: http://127.0.0.1:8080/ >*  Trying 127.0.0.1... >* TCP_NODELAY set >* Connected to 127.0.0.1 (127.0.0.1) port 8080 (#0) >> GET / HTTP/1.1 >> Host: 127.0.0.1:8080 >> User-Agent: curl/7.51.0 >> Accept: */* >> > >Guess this is good evidence that we should document this :) > > >TLS-SNI-02 would work as usual (the proposed rules explicitly list >method 10, which is what TLS-SNI-02 falls under). Existing rules don't >say anything (but again, equivalent method clause exists). > > > > > >-Ilari > >_______________________________________________ >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 Mar 29 07:11:43 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 B72D8129532 for ; Wed, 29 Mar 2017 07:11:42 -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 RBg8kOMbGZ-g for ; Wed, 29 Mar 2017 07:11:37 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 2C608129513 for ; Wed, 29 Mar 2017 07:11:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 29E982523E; Wed, 29 Mar 2017 17:11:34 +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 3FlCkjbRZ72G; Wed, 29 Mar 2017 17:11:33 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id DE071C4; Wed, 29 Mar 2017 17:11:33 +0300 (EEST) Date: Wed, 29 Mar 2017 17:11:31 +0300 From: Ilari Liusvaara To: Niklas Keller Cc: Richard Barnes , "acme@ietf.org" , Roland Shoemaker Message-ID: <20170329141131.GA23157@LK-Perkele-V2.elisa-laajakaista.fi> References: <149064661967.30603.4913027353921499080.idtracker@ietfa.amsl.com> <20170328190803.GA6899@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [Acme] Fwd: New Version Notification for draft-shoemaker-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, 29 Mar 2017 14:11:43 -0000 On Wed, Mar 29, 2017 at 06:34:25AM +0000, Niklas Keller wrote: > >From RFC 2616: > > A client MUST include a Host header field in all HTTP/1.1 request messages > . If the requested URI does not include an Internet host name for the > service being requested, then the Host header field MUST be given with an > empty value. > > I guess an IP address is not considered an Internet host name and thus the > Host header must be empty. Actually, RFC 2616 has been obsoleted in relevant parts by RFC 7230, which says any kind of authority MUST be put into host (unless the URL is absolute) and kinds of authority also include IPv4 address literials, IP address literials (especially IPv6) and hostnames. So by RFC 7230, IP addresses are put into host header. -Ilari From nobody Wed Mar 29 09:50:03 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 72591129415 for ; Wed, 29 Mar 2017 09:50:01 -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 bZIhzbiKzkrc for ; Wed, 29 Mar 2017 09:49:58 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::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 DB533129329 for ; Wed, 29 Mar 2017 09:49:57 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id y18so35929739itc.1 for ; Wed, 29 Mar 2017 09:49:57 -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=bWBgSg90a5TThDENRrEocQt3SYH8+YngODJOo7OkkXI=; b=FJZyBHX5sYyMgeg2WTnqEP6p6qJ1/dKd4xG+TWrn0MrkMB0IT1/w3+E0IL+laR0K/g /QV2gqsJLVRVZlfHF3uEm6/sjpee+shC8VgV3jGOhUBFAblkZ/y8Qw05Ktev4nfDc8PH MjIiE2/Cp72lp/it5ohw7YgTWWQHUs1OCmjpk= 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=bWBgSg90a5TThDENRrEocQt3SYH8+YngODJOo7OkkXI=; b=Y6T6dLF5BFWsoRf5ZH79rVPWdYRqmglBxN/v4K+0sad+kL3vgYEoXFQj3eJuK1rJgF hdeTnrVfZJuPOSEQSqxm5O1QPphR8tV9gIoAOSR4U5i1bhXpj2AeNsRZWY++F3ufSYDV netgC1tXbC5PEI8QXKxHC3T0NRXh5wlSwgu7oNZ0pw4S/Qm4xlpWA5jDEW7cEYzHAZ4w wlB0GHfdMkJJsyJzkm/fw6M270MXNtg+w93PvizNGXXIl66L/3seWmOuFgAAJN1Om7y7 iYBobxMF+w5k454JmTOtV2V1ha1w+lXqfCGtyP5KfX5C1MQKMHlcQ97ADh4al6zWHGKm t6ZA== X-Gm-Message-State: AFeK/H1DZAFGw6Zvo+iDv3WuZ3W60ohTEqJ2zFvoPKSPtLVpTFO2GqUD6neXdCwoP4KFSaGYwMcHqOGD77nh8ihc X-Received: by 10.36.121.129 with SMTP id z123mr1914344itc.16.1490806197143; Wed, 29 Mar 2017 09:49:57 -0700 (PDT) MIME-Version: 1.0 Reply-To: cpu@letsencrypt.org Received: by 10.107.9.147 with HTTP; Wed, 29 Mar 2017 09:49:56 -0700 (PDT) In-Reply-To: References: From: Daniel McCarney Date: Wed, 29 Mar 2017 12:49:56 -0400 Message-ID: To: Richard Barnes Cc: Zach Shepherd , "acme@ietf.org" Content-Type: multipart/alternative; boundary=001a114ab47ecf87e4054be15dc8 Archived-At: Subject: Re: [Acme] Allowing clients to understand the account creation functionality supported by a server 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, 29 Mar 2017 16:50:01 -0000 --001a114ab47ecf87e4054be15dc8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > Dumping some of this info in `directory.meta` doesn't really seem that tragic to me. It's not that much information, and could avoid some errors. Do you feel strongly enough about it to make it a MUST? If it isn't a MUST it seems like we'd be back in the situation that Zach wants to avoid. On Tue, Mar 28, 2017 at 6:14 PM, Richard Barnes wrote: > Dumping some of this info in `directory.meta` doesn't really seem that > tragic to me. It's not that much information, and could avoid some error= s. > > I would note, however, that we could also do this in an extension, rather > than in the main spec. > > On Tue, Mar 28, 2017 at 6:04 PM, Daniel McCarney > wrote: > >> I still think this is the wrong layer to solve this problem. If the crux >> of the matter is that `urn:ietf:params:acme:error:invalidContact` isn't >> sufficient to distinguish between invalid vs unsupported without parsing= we >> could add a `urn:ietf:params:acme:error:unsupportedContact` error type >> and remove the need for parsing the message of the invalidContact error. >> This seems cleaner to me. >> >> I believe there will always be cases where a general purpose ACME client >> will attempt to use a feature unsupported by a given server and will hav= e >> to react accordingly. Rather than try to preempt all of these cases by >> supplying metadata on all of the available options I'd favour refining t= he >> errors the server returns and promoting flexibility in handling them cli= ent >> side. >> >> On Thu, Mar 23, 2017 at 2:06 PM, Zach Shepherd >> wrote: >> >>> Let's consider a simple world where all ACME servers support mailto and >>> some ACME servers support tel. >>> >>> To create an account, the user provides the necessary information to >>> their AMCE client: one or more email addresses and zero or more phone >>> numbers. The ACME client then attempts to supply all of this informatio= n to >>> in an account creation request. Some of the time, this will result in a= n >>> error because the ACME server does not support tel. >>> >>> When the ACME client receives this error, it could: >>> 1. Display it to the user and ask the user to adjust their input >>> accordingly. (A poor user experience.) >>> 2. Attempt to parse to the error message to confirm that the problem wa= s >>> the tel. (Hacky.) >>> 3. Assume that the problem was the tel and retry without that. (Very >>> hacky.) >>> >>> A new ACME server could come along that requires at least one tel or >>> that doesn't support mailto. As a result, ACME clients may chose to att= empt >>> #2 and/or #3 before falling back to #1. >>> >>> This means that ACME clients have one of six different behaviors (#1, >>> #2, #3, #2 falling back to #1, #3 falling back to #1, #2 falling back t= o #3 >>> falling back to #1), some of which add a non-trivial amount of complexi= ty >>> to attempt to parse error messages (yuck.) and some of which end up pus= hing >>> the complexity onto the end-user in end anyways. (Or worse, ACME client= s >>> wind up with hard-coded assumptions based on a specific ACME server >>> implementation and become less portable.) >>> >>> Providing information about the supported contact schemes in a machine >>> readable format (e.g., in response to a GET requests on the server's >>> new-account URI) does add work for ACME server implementors, but not so >>> much that it's worth complicating the end-user experience. >>> >>> Regards, >>> Zach >>> >>> ------------------------------ >>> *From:* Daniel McCarney >>> *Sent:* Wednesday, March 22, 2017 10:43 AM >>> *To:* Zach Shepherd >>> *Cc:* acme@ietf.org >>> *Subject:* Re: [Acme] Allowing clients to understand the account >>> creation functionality supported by a server >>> >>> Hi Zach, >>> >>> > It is undesirable that a client can only determine the supported >>> schemes for contact URLs by attempting to submit an unsupported URL. Th= is >>> makes it difficult to implement a general-purpose client which can work >>> with a variety of servers which might each support a different set of >>> contact schemes. >>> >>> I feel your pain, but I'm hesitant to see more metadata/complexity put >>> into the /directory (I think the "meta" field of the directory resource >>> would be the best place if anywhere). My gut says it will be unlikely m= any >>> servers will allow contact URLs outside of "mailto:" and "tel:" and it >>> seems reasonably easy to handle the unsupported contact type error. For= the >>> account fields we'd be adding complexity to simplify UI and I'm not >>> convinced yet its justified. >>> >>> Another note: If consensus is that we need a machine-readable way for >>> clients to know ahead of time what contact methods & account fields a >>> server supports we should also give the same consideration to identifie= r >>> types for Section 7.4.1's Pre-Authorization mechanism. A client may wan= t to >>> know what types of identifiers a server would pre-authorize. >>> >>> On Wed, Mar 22, 2017 at 1:13 AM, Zach Shepherd >>> wrote: >>> >>>> The following feedback is based on 8010a31 (current HEAD of master). >>>> >>>> Section 7.3, Account Creation, states "The server SHOULD validate that >>>> the contact URLs in the =E2=80=9Ccontact=E2=80=9D field are valid and = supported by the >>>> server. If the client provides the server with an invalid or unsupport= ed >>>> contact URL, then the server MUST return an error of type =E2=80=9Cinv= alidContact=E2=80=9D, >>>> with a description describing the error and what types of contact URL = the >>>> server considers acceptable." >>>> >>>> It is undesirable that a client can only determine the supported >>>> schemes for contact URLs by attempting to submit an unsupported URL. T= his >>>> makes it difficult to implement a general-purpose client which can wor= k >>>> with a variety of servers which might each support a different set of >>>> contact schemes. >>>> >>>> I would propose including information about the supported contact >>>> schemes in a machine readable format as a part of some GET request. >>>> >>>> >>>> Section 7.3, Account Creation, also states "A client creates a new >>>> account with the server by sending a POST request to the server=E2=80= =99s >>>> new-account URI. The body of the request is a stub account object >>>> containing the =E2=80=9Ccontact=E2=80=9D field and optionally the =E2= =80=9Cterms-of-service-agreed=E2=80=9D >>>> field. ... The server MUST ignore any values provided in the =E2=80=9C= orders=E2=80=9D >>>> fields in account bodies sent by the client, as well as any other fiel= ds >>>> that it does not recognize. If new fields are specified in the future,= the >>>> specification of those fields MUST describe whether they can be provid= ed by >>>> the client." >>>> >>>> Similarly, it would be beneficial for a client to be able to determine >>>> the set of fields that a server does recognize so that it does not pro= mpt >>>> the user for information which the server will not make use of. >>>> >>>> I would propose including information about the fields which may be >>>> specified as a part of account creation in a machine readable format a= s a >>>> part of some GET request. >>>> >>>> >>>> Together, these proposals could be addressed by responding to GET >>>> requests on the server's new-account URI with an object describing the >>>> client-specifiable account creation fields and applicable restrictions= on >>>> each, such as the supported schemes for contacts URLs. >>>> >>>> Regards, >>>> Zach Shepherd >>>> >>>> >>>> _______________________________________________ >>>> 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 >> >> > --001a114ab47ecf87e4054be15dc8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
>=C2=A0Dumping some of= this info in `directory.meta` doesn't really seem that tragic to me.= =C2=A0 It's not that much information, and could avoid some errors.

Do you feel strongly enough about it to make it a MUST? If it i= sn't a MUST it seems like we'd be back in the situation that Zach w= ants to avoid.

On Tue, Mar 28, 2017 at 6:14 PM, Richard Barnes = <rlb@ipv.sx> wrote:
Dumping some o= f this info in `directory.meta` doesn't really seem that tragic to me.= =C2=A0 It's not that much information, and could avoid some errors.
I would note, however, that we could also do this in an ext= ension, rather than in the main spec.

On = Tue, Mar 28, 2017 at 6:04 PM, Daniel McCarney <cpu@letsencrypt.org&g= t; wrote:
I still= think this is the wrong layer to solve this problem. If the crux of the ma= tter is that `urn:ietf= :params:acme:error:invalidContact` isn't sufficient to distinguish= between invalid vs unsupported without parsing we could add a `urn:ietf:params:acme:error= :unsupportedContact` error type and remove the need for parsing the me= ssage of the invalidContact error. This seems cleaner to me.

= I believe there will always be cases where a general purpose ACME client wi= ll attempt to use a feature unsupported by a given server and will have to = react accordingly. Rather than try to preempt all of these cases by supplyi= ng metadata on all of the available options I'd favour refining the err= ors the server returns and promoting flexibility in handling them client si= de.=C2=A0

On Thu, Mar 23, 2017 at 2:06 PM, Zach Shepherd <<= a href=3D"mailto:shepherdz@vmware.com" target=3D"_blank">shepherdz@vmware.c= om> wrote:
Let's consider a simple world where all ACME servers support mailt= o and some ACME servers support tel.

To create an account, the user provides the necessary information to their = AMCE client: one or more email addresses and zero or more phone numbers. Th= e ACME client then attempts to supply all of this information to in an acco= unt creation request. Some of the time, this will result in an error because the ACME server does not suppor= t tel.

When the ACME client receives this error, it could:
1. Display it to the user and ask the user to adjust their input accordingl= y. (A poor user experience.)
2. Attempt to parse to the error message to confirm that the problem was th= e tel. (Hacky.)
3. Assume that the problem was the tel and retry without that. (Very hacky.= )

A new ACME server could come along that requires at least one tel or that d= oesn't support mailto. As a result, ACME clients may chose to attempt #= 2 and/or #3 before falling back to #1.

This means that ACME clients have one of six different behaviors (#1, #2, #= 3, #2 falling back to #1, #3 falling back to #1, #2 falling back to #3 fall= ing back to #1), some of which add a non-trivial amount of complexity to at= tempt to parse error messages (yuck.) and some of which end up pushing the complexity onto the end-user in end a= nyways. (Or worse, ACME clients wind up with hard-coded assumptions based o= n a specific ACME server implementation and become less portable.)

Providing information about the supported contact schemes in a machine read= able format (e.g., in response to a GET requests on the server's new-ac= count URI) does add work for ACME server implementors, but not so much that= it's worth complicating the end-user experience.

Regards,
Zach

From: Daniel McCarney <cpu@letsencrypt.org>
Sent: Wednesday, March 22, 2017 10:43 AM
To: Zach Shepherd
Cc: acme@ietf.org=
Subject: Re: [Acme] Allowing clients to understand the account creat= ion functionality supported by a server
=C2=A0
Hi Zach,

> It is undesirable that a client can only determine the supported schem= es for contact URLs by attempting to submit an unsupported URL. This makes = it difficult to implement a general-purpose client which can work with a va= riety of servers which might each support a different set of contact schemes.

I feel your pain, but I'm hesitant to see more metadata/complexity put = into the /directory (I think the "meta" field of the directory re= source would be the best place if anywhere).=C2=A0My gut says it will be un= likely many servers will allow contact URLs outside of "mailto:" and "tel:" and it seems reasonably easy t= o handle the unsupported contact type error. For the account fields we'= d be adding complexity to simplify UI and I'm not convinced yet its jus= tified.

Another note: If consensus is that we need a machine-readable way for clien= ts to know ahead of time what contact methods & account fields a server= supports we should also give the same consideration to identifier types fo= r Section 7.4.1's Pre-Authorization mechanism. A client may want to know what types of identifiers a server wo= uld pre-authorize.

On Wed, Mar 22, 2017 at 1:13 AM, Zach Shepherd <= span dir=3D"ltr"> <shepherdz@vmw= are.com> wrote:

The following feedback is based on 8010a31 (current HEAD of master).
Section 7.3, Account Creation, states "The server SHOULD validate that= the contact URLs in the =E2=80=9Ccontact=E2=80=9D field are valid and supp= orted by the server. If the client provides the server with an invalid or u= nsupported contact URL, then the server MUST return an error of type =E2=80=9CinvalidContact=E2=80=9D, with a description describ= ing the error and what types of contact URL the server considers acceptable= ."

It is undesirable that a client can only determine the supported schemes fo= r contact URLs by attempting to submit an unsupported URL. This makes it di= fficult to implement a general-purpose client which can work with a variety= of servers which might each support a different set of contact schemes.

I would propose including information about the supported contact schemes i= n a machine readable format as a part of some GET request.


Section 7.3, Account Creation, also states "A client creates a new acc= ount with the server by sending a POST request to the server=E2=80=99s new-= account URI. The body of the request is a stub account object containing th= e =E2=80=9Ccontact=E2=80=9D field and optionally the =E2=80=9Cterms-of-serv= ice-agreed=E2=80=9D field. ... The server MUST ignore any values provided in the =E2=80=9Corde= rs=E2=80=9D fields in account bodies sent by the client, as well as any oth= er fields that it does not recognize. If new fields are specified in the fu= ture, the specification of those fields MUST describe whether they can be provided by the client."

Similarly, it would be beneficial for a client to be able to determine the = set of fields that a server does recognize so that it does not prompt the u= ser for information which the server will not make use of.

I would propose including information about the fields which may be specifi= ed as a part of account creation in a machine readable format as a part of = some GET request.


Together, these proposals could be addressed by responding to GET requests = on the server's new-account URI with an object describing the client-sp= ecifiable account creation fields and applicable restrictions on each, such= as the supported schemes for contacts URLs.

Regards,
Zach Shepherd


_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mail= man/listinfo/acme




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



--001a114ab47ecf87e4054be15dc8-- From nobody Wed Mar 29 11:59: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 55970129469 for ; Wed, 29 Mar 2017 11:59:45 -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 ev0FUzY7e9pk for ; Wed, 29 Mar 2017 11:59:41 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::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 16B7A128792 for ; Wed, 29 Mar 2017 11:59:41 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id z13so5139502iof.2 for ; Wed, 29 Mar 2017 11:59:41 -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=FTiQudmIJfAmHBYjT/H2hW5gr637hylUVFChnd+6rlI=; b=NJH/qBPCElKc4mPVOO+sNbQ39dYYNpBksFKtmWeIj45AMhzyzPmdkCc8SnNYxxZGUA ZhMGWs8SwKvXfcPLMBBm/YMq5GJU1BRZ+YHnntBcxq+Y1m9DnMTOJd8hTbJc0cNAAXE5 0sYJ4nAlyKDI6O4VTF490KPeaMLQHTmqcYpss= 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=FTiQudmIJfAmHBYjT/H2hW5gr637hylUVFChnd+6rlI=; b=FZPjMJ+jTenciMsAZg8VOBt+cvMVgh/+eSoC73Ypw5PzpRrislzVRIMGtmEz3+VFXJ ACprkTI5vUfhi/1EN5HStYU5yuN1051XZqVvAknnQyjt9jTbWT6J2kTUmzzuReVdiPfK eThALkPpC1ztNHzf4PjNuUqyPEiglrv3AKYIzOzr+mBxTAofX8xq7GTf0YjGkWWGlhUe mZdXX7QrAay7uDzV2XfQKvBJrc1PX5kHrWp6Li/6KMQO+ciJhi31abMsXSrkt38q3rcz XJcmGfqXZPVbMVyt/VEpe6Xx8EvBIqVHpBbauVWSG4z2dRiIOKGqvZhMxfgLU6x/BH/A TPGA== X-Gm-Message-State: AFeK/H1BSGwFzQaCNQMXno7rzkQhI6ADteWwgGnl6rn7sGT5sna0Qtj2NYGVxn2slLOIB4GTotlOpqNImSWOdSgT X-Received: by 10.107.165.9 with SMTP id o9mr2376319ioe.73.1490813980288; Wed, 29 Mar 2017 11:59:40 -0700 (PDT) MIME-Version: 1.0 Reply-To: cpu@letsencrypt.org Received: by 10.107.9.147 with HTTP; Wed, 29 Mar 2017 11:59:39 -0700 (PDT) In-Reply-To: References: From: Daniel McCarney Date: Wed, 29 Mar 2017 14:59:39 -0400 Message-ID: To: Jacob Hoffman-Andrews Cc: Zach Shepherd , "acme@ietf.org" Content-Type: multipart/alternative; boundary=001a1141d060b8eb1c054be32d2f Archived-At: Subject: Re: [Acme] Entropy requirement for challenge token 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, 29 Mar 2017 18:59:45 -0000 --001a1141d060b8eb1c054be32d2f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Updated #284 to clarify the token entropy requirement in the security considerations section. Thanks for the feedback. On Tue, Mar 28, 2017 at 5:30 PM, Daniel McCarney wrote: > I think Daniel's change at https://github.com/ietf-wg- >> acme/acme/pull/284/files is a nice quick fix to the issue, but I agree >> it could use a few extra sentences explaining it in security considerati= ons. > > > I will take a crack at amending this PR with a few sentences in the > security considerations section. > > On Thu, Mar 23, 2017 at 3:24 PM, Jacob Hoffman-Andrews > wrote: > >> Yep, I think there are two ways of thinking about this, though it's >> effectively a single problem: >> >> 1. Prevent attackers from tricking a validation endpoint into serving a >> valid challenge response. >> 2. Prevent ACME clients from implementing a "naive" validation method >> that would make (1) trivial. >> >> I think Daniel's change at https://github.com/ietf-wg-acm >> e/acme/pull/284/files is a nice quick fix to the issue, but I agree it >> could use a few extra sentences explaining it in security considerations= . >> >> >> On 03/23/2017 10:34 AM, Zach Shepherd wrote: >> >> It seems like the goal of this is to ensure that the ACME client is not >> able to control (or, perhaps, even influence) the choice of token and re= quiring >> that the token be sufficiently random is one way to achieve this. This >> prevents an attacker from "tricking" the ACME server into using a >> verification performed by the owner of an identifier as proof that the >> attacker controls the identifier. >> >> Is this accurate? If so, it seems like some version of this explanation >> should be included in the Security Considerations section. >> >> ------------------------------ >> *From:* Daniel McCarney >> *Sent:* Wednesday, March 22, 2017 10:30 AM >> *To:* Zach Shepherd >> *Cc:* acme@ietf.org >> *Subject:* Re: [Acme] Entropy requirement for challenge token >> >> Hi Zach, >> >> > This seems incongruous. If the token must be kept secret an attacker, >>> it should not be served via an unauthenticated channel. >> >> >> I agree the wording makes it incongruous, I was caught up on this the >> other week until it was clarified for me by Jacob. >> >> The token is random not to prevent a guessing attack but to prevent the >> implementation of a server that can automatically reply to challenges >> without being a party to the authorization creation (e.g. knowing the >> token). It's OK for the token to be served via an unauthenticated channe= l, >> it just can't be predictable. >> >> I took a crack at rewording this in https://github.com/ietf-wg- >> acme/acme/pull/284 >> >> - Hopefully if I'm completely off-base someone can correct it to be >> accurate & understandable. >> >> On Wed, Mar 22, 2017 at 1:12 AM, Zach Shepherd >> wrote: >> >>> The following feedback is based on 8010a31 (current HEAD of master). >>> >>> Section 6.2, Request Authentication, states "Note that authentication >>> via signed JWS request bodies implies that GET requests are not >>> authenticated. Servers MUST NOT respond to GET requests for resources t= hat >>> might be considered sensitive. Account resources are the only sensitive >>> resources defined in this specification." >>> >>> Sections 8.2, HTTP; 8.3, TLS with Server Name Indication (TLS SNI); and >>> 8.4, DNS, each describe a GET request and specify a "token" value which >>> "MUST have at least 128 bits of entropy, in order to prevent an attacke= r >>> from guessing it." >>> >>> This seems incongruous. If the token must be kept secret an attacker, i= t >>> should not be served via an unauthenticated channel. >>> >>> Assuming secrecy of the token is not important, I would propose removin= g >>> the entropy requirement and including some discussion of the token in >>> Section 10, Security Considerations. >>> >>> Regards, >>> Zach Shepherd >>> >>> >>> _______________________________________________ >>> Acme mailing list >>> Acme@ietf.org >>> https://www.ietf.org/mailman/listinfo/acme >>> >>> >>> >> >> >> _______________________________________________ >> Acme mailing listAcme@ietf.orghttps://www.ietf.org/mailman/listinfo/acme >> >> >> > --001a1141d060b8eb1c054be32d2f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Updated #284 to clarify the token entropy requirement in t= he security considerations section. Thanks for the feedback.

On Tue, Mar 28, 2017 at 5:= 30 PM, Daniel McCarney <cpu@letsencrypt.org> wrote:
I thi= nk Daniel's change at=C2=A0https://github.com/ietf-wg-acme/acme/pull/284/files=C2=A0is a nice quick fix to the issue, but I agree i= t could use a few extra sentences explaining it in security considerations.=

I will take a crack at amending this PR= with a few sentences in the security considerations section.=C2=A0

On Thu, M= ar 23, 2017 at 3:24 PM, Jacob Hoffman-Andrews <jsha@eff.org> wrot= e:
=20 =20 =20
Yep, I think there are two ways of thinking about this, though it's effectively a single problem:

=C2=A01. Prevent attackers from tricking a validation endpoint into serving a valid challenge response.
=C2=A02. Prevent ACME clients from implementing a "naive" val= idation method that would make (1) trivial.

I think Daniel's change at https://github.com/ietf-wg-acme/acme/pull/284/files is= a nice quick fix to the issue, but I agree it could use a few extra sentences explaining it in security considerations.


On 03/23/2017 10:34 AM, Zach Shepherd wrote:
=20 =20

It seems like the goal of this is to ensure that the ACME client is not able to control (or, perhaps, even influence) the choice of token and requiring that the token be sufficiently random is one way to achieve this. This prevents an attacker from "tricking" the ACME server in= to using a verification performed by the owner of an identifier as proof that the attacker controls the identifier.


Is this accurate? If so, it seems like some version of this explanation should be included in the Security Considerations section.


From: Daniel McCarney <cpu@letsencrypt.org>
Sent: Wednesday, March 22, 2017 10:30 AM
To: Zach Shepherd
Cc: acme@ietf.org
Subject: Re: [Acme] Entropy requirement for challenge token
=C2=A0
Hi Zach,

> This seems incongruous. If the token must be kept secret an attacker, it should not be served via an unauthenticated channel.

I agree the wording makes it incongruous, I was caught up on this the other week until it was clarified for me by Jacob.

The token is random not to prevent a guessing attack but to prevent the implementation of a server that can automatically reply to challenges without being a party to the authorization creation (e.g. knowing the token). It's OK for the token to be served via an unauthenticated channel, it just can't be predictable.<= br>
I took a crack at rewording this in=C2=A0https://github.com/ietf-wg-acme/acme/pull/284 - Hopefully if I'm completely off-base someone can correct it to be accurate & understandable.

On Wed, Mar 22, 2017 at 1:12 AM, Zach Shepherd <shepherdz@vmware.com> wrote:
The following feedback is based on 8010a31 (current HEAD of master).

Section 6.2, Request Authentication, states "Note that authentication via signed JWS reque= st bodies implies that GET requests are not authenticated. Servers MUST NOT respond to GET requests for resources that might be considered sensitive. Account resources are the only sensitive resources defined in this specification."

Sections 8.2, HTTP; 8.3, TLS with Server Name Indication (TLS SNI); and 8.4, DNS, each describe a GET request and specify a "token&qu= ot; value which "MUST have at least 128 bits of entropy, in order to prevent an attacker from guessing it."

This seems incongruous. If the token must be kept secret an attacker, it should not be served via an unauthenticated channel.

Assuming secrecy of the token is not important, I would propose removing the entropy requirement and including some discussion of the token in Section 10, Security Considerations.

Regards,
Zach Shepherd


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




_______________________________________________
Acme mailing list
Acme@ietf.org
ht=
tps://www.ietf.org/mailman/listinfo/acme



--001a1141d060b8eb1c054be32d2f-- From nobody Wed Mar 29 12:32: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 709B71296EF for ; Wed, 29 Mar 2017 12:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.897 X-Spam-Level: X-Spam-Status: No, score=-4.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.796, RCVD_IN_SORBS_SPAM=0.5, 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 CH9QmWRjaEov for ; Wed, 29 Mar 2017 12:32:20 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 238A91296DE for ; Wed, 29 Mar 2017 12:32:20 -0700 (PDT) Received: from dhcp-84d4.meeting.ietf.org (unknown [31.133.132.212]) (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 1B71D509B8 for ; Wed, 29 Mar 2017 15:32:18 -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\)) Message-Id: Date: Wed, 29 Mar 2017 14:32:17 -0500 To: ACME WG X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [Acme] draft-ietf-acme-acme-06: Don't call it PEM Certificate Chain 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, 29 Mar 2017 19:32:21 -0000 Hello, I reviewed draft-ietf-acme-acme-06. As the co-author of RFC 7468, I have = concerns. First of all as an editorial matter there is no such thing as =E2=80=9CPEM= encoding=E2=80=9D--that term is not defined in RFC 7468. The correct = term is =E2=80=9Ctextual encoding=E2=80=9D. PEM is dead: just because = some popular tools (i.e., OpenSSL) call it PEM doesn=E2=80=99t mean that = it=E2=80=99s PEM, which is a mail format from RFC 1421. Therefore the = text in Section 9.1.: =E2=80=9CFile should contain one or more = certificates encoded as PEM according to RFC 7468.=E2=80=9D is wrong = because RFC 7468 doesn=E2=80=99t define =E2=80=9Cencoded as PEM=E2=80=9D. Second of all, I see negative value in transmitting certificates in the = proposed =E2=80=9CPEM Certificate Chain=E2=80=9D format (Section 7.4.2., = Section 9.1). Again, I understand that some popular tools (i.e., = OpenSSL) dump out this format by default, but one command-line switch or = pipe can change it to a much better format. Don=E2=80=99t be lazy. A bunch of textually encoded certificates are *text* data, and text is = in a charset, so something like text/plain; charset=3Dus-ascii is = appropriate. Registering application/pem-certificate-chain is = counterproductive because it omits the charset (and if you really want = to omit the charset, then Section 9.1 is wrong because it needs to say = =E2=80=9CUS-ASCII ONLY=E2=80=9D or some such). A bunch of certificates as text data can include arbitrary text in = between the encapsulation boundaries, such as printouts of the = certificates (also OpenSSL options). This is superfluous and in my = opinion dangerous. If you want such arbitrary text as a design matter, = maybe for debugging purposes, that=E2=80=99s fine but that=E2=80=99s all = the more reason why the contents should be text/* contents rather than = application/* contents. It=E2=80=99s a lot cleaner to emit certificates in a blob as = application/pkcs7-mime; smime-type=3Dcerts-only. This is also a trivial = OpenSSL option. If you want to ASCII-armor it, you can put it in a = -----BEGIN CMS-----, -----BEGIN PKCS7----- , or if you really want, = -----BEGIN CERTIFICATE CHAIN----- (see Section 8 of RFC 7468). But you = gain 37% size reduction by letting it be binary CMS/binary PKCS #7 over = HTTP, and the certificate processing libraries can deal with the sorting = issues. If it=E2=80=99s so important to put the subject certificate = first, there are several other format choices to deal with that = (including a multipart response). I don=E2=80=99t see value in specifying an order to the certificates in = the text: =E2=80=9CEach following certificate SHOULD directly certify = one preceding it.=E2=80=9D Again I know what the tools out there do, but = a robust receiver still needs to handle out-of-order certificates, as = well as certificates that end up not being part of the chain. CMS/PKCS = #7 deals with this by just supplying an arbitrary set of certificates. Thank you, Sean= From nobody Wed Mar 29 12:54:40 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 B377512984A for ; Wed, 29 Mar 2017 12:54:38 -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 zSEUA6bq4lNb for ; Wed, 29 Mar 2017 12:54:36 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 0A007129490 for ; Wed, 29 Mar 2017 12:54:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id E045924E16; Wed, 29 Mar 2017 22:54:29 +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 dbkWzFBy7ygd; Wed, 29 Mar 2017 22:54:29 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 9652F21C; Wed, 29 Mar 2017 22:54:29 +0300 (EEST) Date: Wed, 29 Mar 2017 22:54:27 +0300 From: Ilari Liusvaara To: Sean Leonard Cc: ACME WG Message-ID: <20170329195427.GA23764@LK-Perkele-V2.elisa-laajakaista.fi> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [Acme] draft-ietf-acme-acme-06: Don't call it PEM Certificate Chain 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, 29 Mar 2017 19:54:39 -0000 On Wed, Mar 29, 2017 at 02:32:17PM -0500, Sean Leonard wrote: > Hello, > > Second of all, I see negative value in transmitting certificates in > the proposed “PEM Certificate Chain†format (Section 7.4.2., Section > 9.1). Again, I understand that some popular tools (i.e., OpenSSL) > dump out this format by default, but one command-line switch or > pipe can change it to a much better format. Don’t be lazy. AFAIK, the PEM format is intended for transporting the End-Entity and intermediate certificates at once, as incomplete chains are extremely common. > I don’t see value in specifying an order to the certificates > in the text: “Each following certificate SHOULD directly certify > one preceding it.†Again I know what the tools out there do, > but a robust receiver still needs to handle out-of-order > certificates, as well as certificates that end up not being > part of the chain. CMS/PKCS #7 deals with this by just supplying > an arbitrary set of certificates. TLS 1.2 has a MUST for ordering certificates. And nothing that doesn't build paths itself (and thus can fetch certiifcates itself) handles CMS/PKCS#7. This is way too much logic to expect from ACME client. And handling unordered certificates is quite a bit of extra attack surface. I took not just one but two vulns on that (one being auth bypass, which barring type safety bugs are just about the worst that can happen). -Ilari From nobody Wed Mar 29 13:48: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 489CE12947E for ; Wed, 29 Mar 2017 13:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.796, RCVD_IN_SORBS_SPAM=0.5, SPF_HELO_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 i-pC86aPeYI7 for ; Wed, 29 Mar 2017 13:48:41 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 AF14E129998 for ; Wed, 29 Mar 2017 13:48:04 -0700 (PDT) Received: from dhcp-84d4.meeting.ietf.org (unknown [31.133.132.212]) (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 990EE509BB; Wed, 29 Mar 2017 16:48:03 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sean Leonard In-Reply-To: <20170329195427.GA23764@LK-Perkele-V2.elisa-laajakaista.fi> Date: Wed, 29 Mar 2017 15:48:02 -0500 Cc: ACME WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170329195427.GA23764@LK-Perkele-V2.elisa-laajakaista.fi> To: Ilari Liusvaara X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Acme] draft-ietf-acme-acme-06: Don't call it PEM Certificate Chain 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, 29 Mar 2017 20:48:44 -0000 > On Mar 29, 2017, at 2:54 PM, Ilari Liusvaara = wrote: >=20 > On Wed, Mar 29, 2017 at 02:32:17PM -0500, Sean Leonard wrote: >> Hello, >>=20 >> Second of all, I see negative value in transmitting certificates in >> the proposed =E2=80=9CPEM Certificate Chain=E2=80=9D format (Section = 7.4.2., Section >> 9.1). Again, I understand that some popular tools (i.e., OpenSSL) >> dump out this format by default, but one command-line switch or >> pipe can change it to a much better format. Don=E2=80=99t be lazy. >=20 > AFAIK, the PEM format is intended for transporting the End-Entity > and intermediate certificates at once, as incomplete chains are > extremely common. >=20 [=E2=80=A6] >=20 > TLS 1.2 has a MUST for ordering certificates. Yes, TLS expects ordering. But this statement is inconsistent with the = statement above: =E2=80=9Ctransporting the End-Entity and intermediate = certificates at once, as incomplete chains are extremely common.=E2=80=9D My point is that if you have a valid chain of 5 certificates: SUBJECT -> intermediate A -> intermediate B -> intermediate C -> ROOT CA The first statement, =E2=80=9Cincomplete chains are extremely common=E2=80= =9D, means that you are expecting a transmission that is missing, e.g., = intermediate B, therefore: SUBJECT intermediate A intermediate C ROOT CA This example is not =E2=80=9Cordered=E2=80=9D according to TLS 1.2, = because RFC 5246 says: =E2=80=9CEach following certificate MUST directly = certify the one preceding it.=E2=80=9D My point is that even though {SUBJECT, A, C, ROOT} is in an order, it is = not TLS 1.2-ordered, therefore it is =E2=80=9Cunordered=E2=80=9D. So, a = receiver needs to deal with this unordered situation under the current = draft. Unless ACME expects all senders to transmit TLS 1.2-ordered certificates = in this part of the protocol? If so, the text needs to say that, as in = =E2=80=9CMUST=E2=80=9D, not =E2=80=9CSHOULD=E2=80=9D. >=20 > And nothing that doesn't build paths itself (and thus can fetch > certiifcates itself) handles CMS/PKCS#7. This is way too much logic > to expect from ACME client. Too many double-negatives for me to parse. Please clarify, thanks. >=20 >=20 > And handling unordered certificates is quite a bit of extra attack > surface. I took not just one but two vulns on that (one being auth > bypass, which barring type safety bugs are just about the worst that > can happen). If you are saying that the receiver is only expected to handle TLS = 1.2-ordered certificates: =E2=80=9CEach following certificate MUST = directly certify the one preceding it=E2=80=9D (MUST, not SHOULD) then = we have a different situation and PKCS #7/CMS certs-only may not be = appropriate. But the text does not currently say that, so I need = clarification before suggesting a better data format for the certificate = chain. Regards, Sean From nobody Wed Mar 29 20:31: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 B5BC7128896 for ; Wed, 29 Mar 2017 20:31:20 -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 YHIEQd3QLcwL for ; Wed, 29 Mar 2017 20:31:18 -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 7CBA2128E19 for ; Wed, 29 Mar 2017 20:31:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by umbriel.devever.net (Postfix) with ESMTP id 1077E1D471; Thu, 30 Mar 2017 05:31:17 +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=1490844677; x=1509034038; bh=rWVFuhAU+/p2X8JCGy5lN2DSIjWPIesfu/dQIzan5iw=; b= rJFPpaS8abkf97IP6Dv1U4AMXHrV0RJ4pcY+uTrqshZ66iOok+6bUWanrBJA/otE q32mx+mPesPF1q8ufez8QNvWU7Sqg17BlncTRIp5+Gz019mYr4OtNgWssRukQswt RAFhXTMb2j77UH53lGmpgjs1yzlxsSFnB5iSGCf15CEM6FruwUazXeIkkqVeUVVk I2tq5jaSKuFXMdk4ts86CUemNDaMaLeYUEFwcvpBLEFX4Z9Gp9d9/eWWdQBD+Cen nddbiIMZgFKCcmeEZqXEvBXpxNGRBswBy1OdYU9slO709vj6p3r8JTUwpmiQLSzt Img6RH2rSqpAUtLmEvB+oQ== 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 RqVxmkewlcW4; Thu, 30 Mar 2017 05:31:17 +0200 (CEST) Received: from andover.lhh.devever.net (localhost [127.0.0.1]) by umbriel.devever.net (Postfix) with SMTP id D06311D453; Thu, 30 Mar 2017 05:31:16 +0200 (CEST) Date: Thu, 30 Mar 2017 04:31:16 +0100 From: Hugo Landau To: Jacob Hoffman-Andrews Cc: acme@ietf.org Message-ID: <20170330033116.GA19951@andover.lhh.devever.net> References: <20170325164023.GA7854@andover.lhh.devever.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.0 (2017-02-23) Archived-At: Subject: Re: [Acme] Retrying failed authorizations 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, 30 Mar 2017 03:31:21 -0000 > I think the way CAs traditionally handle this is as you suggest: by > making challenges retryable. Note that this implies that orders > typically never get invalidated, they just expire after some period of > time (or error out if there's a problem during issuance, like CAA). This > also implies that clients would potentially need to keep state across > invocations. Specifically, clients would need to store the private keys > used for extant orders, so if a subsequent run completes an order, the > client is able to use the resulting certificate. > > What's your thought on the additional burden on clients? I don't think the additional burden is a problem. > What is the rest of the group's thoughts on whether we'd have to restart > WGLC for this? I'd hope that if the 'can retry individual challenges' option is chosen this is considered a minor enough change to avoid restarting WGLC. However, it also seems pointless to finalize the ACME specification as an RFC when we have the opportunity to wait until Let's Encrypt obtains operational experience in production with the revised specification. It's a little bizarre that a version of the specification that isn't going to be standardized as an RFC has a lot more deployment experience attached to it than a substantially different version with no current deployment experience. It would be a different story if this WG thought it was holding anything up by virtue of deferring standarization; if another WG was waiting on an RFC to cite, or so on. But the evidence is that the fact that ACME is still an I-D hasn't stopped real-world deployment of either CAs (Let's Encrypt) or a multitude of clients. In that regard, even though I can usually be as weary as anyone at how long it can take standards organizations to finalize things (C++ concepts comes to mind), in this case, I think it would make sense to postpone finalization of the ACME specification until such time as Let's Encrypt moves the new specification into production (or, alternatively, until another CA enters on the scene and implements ACME, and gains experience with it). I'm not sure what position this WG would take on tying a neutral standards process to the implementation timeline of a particular organization; potentially it is objectionable. At the same time, the fact that ACME has been field-tested before finalization has been valuable. From nobody Wed Mar 29 23:07: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 6D4A4127599 for ; Wed, 29 Mar 2017 23:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.799 X-Spam-Level: X-Spam-Status: No, score=-9.799 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, RCVD_IN_MSPIKE_H2=-2.796, 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 fYPBps00_6rb for ; Wed, 29 Mar 2017 23:07:08 -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 1B7A5127342 for ; Wed, 29 Mar 2017 23:07:08 -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:Cc:References:To:Subject; bh=rxdo5/GnFUU5iuhMzRl6SSWr+A/SjHY+tlW24aU439Y=; b=AeZ/UuhrHBzUwtXu13WeVa6HO2d1IZPrOWjCOwXv9DHQEdsUCybA5FfvJvTlAkh8JYXvRnUhJlgvyx6OLqQTCLogQOaCm0gYoRoVrmKm5Iuy2TN+B9EKVetq6GxMOu3CxivMVjj9v8Z1XKmqy8g4izHpLe4R4IkGsO4llSqG348=; Received: ; Wed, 29 Mar 2017 23:07:05 -0700 To: Sean Leonard , Ilari Liusvaara References: <20170329195427.GA23764@LK-Perkele-V2.elisa-laajakaista.fi> Cc: ACME WG From: Jacob Hoffman-Andrews Message-ID: <525f79bb-a2e6-bf09-30e5-e80e0bb80379@eff.org> Date: Wed, 29 Mar 2017 23:07:04 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Acme] draft-ietf-acme-acme-06: Don't call it PEM Certificate Chain 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, 30 Mar 2017 06:07:10 -0000 On 03/29/2017 01:48 PM, Sean Leonard wrote: > If you are saying that the receiver is only expected to handle TLS > 1.2-ordered certificates: =E2=80=9CEach following certificate MUST dire= ctly > certify the one preceding it=E2=80=9D (MUST, not SHOULD) then we have a= > different situation and PKCS #7/CMS certs-only may not be appropriate. > But the text does not currently say that, so I need clarification > before suggesting a better data format for the certificate chain. In general, the expectation is that the ACME client passes the certificate chain straight to a web server or other TLS server. Generally speaking, the TLS server will then pass along the chain in the same order to the TLS client during the handshake. So I assume by "receiver" you mean TLS client, right? My understanding of TLS deployment is that, even though TLS 1.2, 1.1, and 1.0 required strict ordering of certificates in the chain, deployed clients were actually tolerant of out-of-order certificates. I haven't followed TLS 1.3 standardization closely, but my guess is that that's the reason the ordering requirement was relaxed. So I think the answer to your question is: The receiver (TLS client) is expected to handle TLS 1.3-ordered certificates, and our belief is that that's reasonable given today's deployments. From nobody Thu Mar 30 00:58: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 244E1129522 for ; Thu, 30 Mar 2017 00:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.799 X-Spam-Level: X-Spam-Status: No, score=-9.799 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, RCVD_IN_MSPIKE_H2=-2.796, 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 rvp5jXTZcW6a for ; Thu, 30 Mar 2017 00:58: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 39B901294AC for ; Thu, 30 Mar 2017 00:58:28 -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:Cc:References:To:Subject; bh=96CVh8org5tShwplu2oJeAVyTv8QGimvK5HkZtfEVJI=; b=WqZjA2TR6mLBK5tzM5wF2mGabUnwFqD4IjPH1BWyT0EJgpQUx0atk2Lze0+Jcu+l6Xckpo940xgpP5POHj142wlX+YvzrRaD7x+fYjwmQ2NpvxrnXYDRgU9acxgAiJGNliN68II3KS8JmkvinKSPFxvTLCte25VghMlTbGGiSts=; Received: ; Thu, 30 Mar 2017 00:58:27 -0700 To: Hugo Landau References: <20170325164023.GA7854@andover.lhh.devever.net> <20170330033116.GA19951@andover.lhh.devever.net> Cc: acme@ietf.org From: Jacob Hoffman-Andrews Message-ID: Date: Thu, 30 Mar 2017 00:58:26 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170330033116.GA19951@andover.lhh.devever.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Acme] Retrying failed authorizations 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, 30 Mar 2017 07:58:30 -0000 On 03/29/2017 08:31 PM, Hugo Landau wrote: >> What is the rest of the group's thoughts on whether we'd have to resta= rt >> WGLC for this? > I'd hope that if the 'can retry individual challenges' option is chosen= > this is considered a minor enough change to avoid restarting WGLC. > > However, it also seems pointless to finalize the ACME specification as > an RFC when we have the opportunity to wait until Let's Encrypt obtains= > operational experience in production with the revised specification. > It's a little bizarre that a version of the specification that isn't > going to be standardized as an RFC has a lot more deployment experience= > attached to it than a substantially different version with no current > deployment experience. > > It would be a different story if this WG thought it was holding anythin= g > up by virtue of deferring standarization; if another WG was waiting on > an RFC to cite, or so on. But the evidence is that the fact that ACME i= s > still an I-D hasn't stopped real-world deployment of either CAs (Let's > Encrypt) or a multitude of clients. Thanks for expressing this; I tend to agree, but that makes sense given that I work on Let's Encrypt. The main countervailing pressure, in my mind, is that other CAs are starting to show interest in ACME, but of course the main reason to use ACME is interop with existing tools. So we want to have something reasonably final (and in production), so that new integrations are built against the final-ish version rather than Boulder's outdated variant as much as possible. However, I think the main gating factor there is, as you say, getting the latest spec into production in Boulder. Which we're working on. :-) From nobody Thu Mar 30 08:27: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 EDB9E1296CE for ; Thu, 30 Mar 2017 08:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.897 X-Spam-Level: X-Spam-Status: No, score=-4.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.796, RCVD_IN_SORBS_SPAM=0.5, 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 SgxLjJ2OphGK for ; Thu, 30 Mar 2017 08:27:43 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 6AB6912952F for ; Thu, 30 Mar 2017 08:27:40 -0700 (PDT) Received: from dhcp-84d4.meeting.ietf.org (unknown [31.133.132.212]) (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 3F108509BB; Thu, 30 Mar 2017 11:27:38 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sean Leonard In-Reply-To: <525f79bb-a2e6-bf09-30e5-e80e0bb80379@eff.org> Date: Thu, 30 Mar 2017 10:27:37 -0500 Cc: Ilari Liusvaara , Jacob Hoffman-Andrews Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170329195427.GA23764@LK-Perkele-V2.elisa-laajakaista.fi> <525f79bb-a2e6-bf09-30e5-e80e0bb80379@eff.org> To: ACME WG X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Acme] draft-ietf-acme-acme-06: Don't call it PEM Certificate Chain 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, 30 Mar 2017 15:27:45 -0000 > On Mar 30, 2017, at 1:07 AM, Jacob Hoffman-Andrews = wrote: >=20 > On 03/29/2017 01:48 PM, Sean Leonard wrote: >> If you are saying that the receiver is only expected to handle TLS >> 1.2-ordered certificates: =E2=80=9CEach following certificate MUST = directly >> certify the one preceding it=E2=80=9D (MUST, not SHOULD) then we have = a >> different situation and PKCS #7/CMS certs-only may not be = appropriate. >> But the text does not currently say that, so I need clarification >> before suggesting a better data format for the certificate chain. > In general, the expectation is that the ACME client passes the > certificate chain straight to a web server or other TLS server. > Generally speaking, the TLS server will then pass along the chain in = the > same order to the TLS client during the handshake. So I assume by > "receiver" you mean TLS client, right? >=20 > My understanding of TLS deployment is that, even though TLS 1.2, 1.1, > and 1.0 required strict ordering of certificates in the chain, = deployed > clients were actually tolerant of out-of-order certificates. I haven't > followed TLS 1.3 standardization closely, but my guess is that that's > the reason the ordering requirement was relaxed. >=20 > So I think the answer to your question is: The receiver (TLS client) = is > expected to handle TLS 1.3-ordered certificates, and our belief is = that > that's reasonable given today's deployments. Thank you. In the message above, the first sentence=E2=80=99s = =E2=80=9Creceiver=E2=80=9D was meant to be the receiver that is the HTTP = client in the ACME protocol that issues the GET /acme/cert request, and = receives back the certificate chain. Therefore the =E2=80=9Creceiver=E2=80= =9D is the ACME client, which also is the web/TLS server that = incorporates the chain into its operations. I spoke with Rich Salz in person about this yesterday, sorry that I = probably won=E2=80=99t be at the ACME meeting today due to a scheduling = conflict. But if your purpose is to communicate an ordered list of = certificates in TLS 1.2 order (according to Section 7.4.2 of RFC 5246), = I have a simple solution for you: application/tls-certificate-list [or tls-cert-list] Contents: DER-encoded certificates, concatenated in RFC 5246 Section = 7.4.2 order The end. This is very simple and makes it easy for both sides to deal with the = certificates. The first certificate is the end-entity/TLS subject = certificate. The remaining certificates are supposed to chain to some = root (use the appropriate RFC 5246 language). It is safe to concatenate = binary (X.690/BER/DER) certificates because the first TLV indicates the = full length of the certificate; therefore they are self-delimiting. This is easier and better than stringing the textual encoded versions = because you don=E2=80=99t have to deal with text metadata issues, = charsets, line endings, and extra processing. Specifically, an ACME = server is going to have to take the certificate bytes and base64-encode = each one, followed by ASCII armoring. Then the ACME client is going to = have to reverse this. No point and confusing. For those who don=E2=80=99t like binary, ACME is JSON-based, so you can = just have an application/json response that is just an array: [=E2=80=9CMIICAS...base64 of end-entity cert=E2=80=9D,=E2=80=9CMIICAS=E2=80= =A6base64 of second cert=E2=80=A6=E2=80=9D=E2=80=A6to root] This way you don=E2=80=99t have to register a media type and you can = ingest the response using the same JSON stack. Also, you can encapsulate = this very simple JSON structure in more articulated JSON entities if you = want to include other metadata or whatever down the line. Regards, Sean From nobody Thu Mar 30 08:47: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 75BCD1296CF for ; Thu, 30 Mar 2017 08:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.799 X-Spam-Level: X-Spam-Status: No, score=-9.799 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, RCVD_IN_MSPIKE_H2=-2.796, 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 PB0n7uTzOuHk for ; Thu, 30 Mar 2017 08:47:04 -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 231D712956D for ; Thu, 30 Mar 2017 08:47:04 -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:Cc:References:To:Subject; bh=eyN8kVvAxXebwr11r5zzegNhPnIoPpzfeKzWuPy2DNg=; b=YQ3K7Zj6PDgzcYRWlmXOtuUIOiU7AHI8U/Toy/Qjah3wVnoMMeziFO+S+wxaBtu2iLz+m50DnckaTsFUJax54zk9O1GZZrvovBmwgac+NGaGcRqCUkgRr25PjaDJ/DSOUHr1JgqkotQUpUDnDuQgVk7rHeoH7xapC8vGMs1vwb8=; Received: ; Thu, 30 Mar 2017 08:47:02 -0700 To: Sean Leonard , ACME WG References: <20170329195427.GA23764@LK-Perkele-V2.elisa-laajakaista.fi> <525f79bb-a2e6-bf09-30e5-e80e0bb80379@eff.org> Cc: Ilari Liusvaara From: Jacob Hoffman-Andrews Message-ID: <3a9aaca8-204c-2a6c-2fc5-f74870effc2e@eff.org> Date: Thu, 30 Mar 2017 08:47:01 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Acme] draft-ietf-acme-acme-06: Don't call it PEM Certificate Chain 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, 30 Mar 2017 15:47:05 -0000 > Therefore the =E2=80=9Creceiver=E2=80=9D is the ACME client, which also= is the web/TLS server that incorporates the chain into its operations. Note that in common deployment today, the ACME client is separate from the web server. On 03/30/2017 08:27 AM, Sean Leonard wrote: > Contents: DER-encoded certificates, concatenated in RFC 5246 Section > 7.4.2 order=20 Is there a straightforward OpenSSL command to convert this entity into a PEM file containing multiple certificates? I don't think there is but I could be wrong. > This is easier and better than stringing the textual encoded versions b= ecause you don=E2=80=99t have to deal with text metadata issues, charsets= , line endings, and extra processing. Specifically, an ACME server is goi= ng to have to take the certificate bytes and base64-encode each one, foll= owed by ASCII armoring. Then the ACME client is going to have to reverse = this. No point and confusing. Our expectation is that many ACME clients will *not* reverse the base64 and ASCII armoring, but will write out the entire contents to a file for ingestion by a web server. The two most popular web servers, Apache and Nginx, consume PEM-formatted certificate chains. You're right that an ACME client would have to decode this format if they wanted to change it to something else, but what we are seeing in practice is clients that simply convert the end-entity certificate from DER to PEM and don't bother with the intermediates, resulting in end-user pain. > For those who don=E2=80=99t like binary, ACME is JSON-based, so you can= just have an application/json response that is just an array: > > [=E2=80=9CMIICAS...base64 of end-entity cert=E2=80=9D,=E2=80=9CMIICAS=E2= =80=A6base64 of second cert=E2=80=A6=E2=80=9D=E2=80=A6to root] For me, "don't like binary" isn't the issue. If CMS were the most common certificate chain input format for web servers, I would be fine with returning binary CMS. Unfortunately, it is not. From nobody Thu Mar 30 09:04:58 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 13FB5126C3D for ; Thu, 30 Mar 2017 09:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.796, RCVD_IN_SORBS_SPAM=0.5, 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 ylb266g4o3on for ; Thu, 30 Mar 2017 09:04:53 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 8F3D0128ACA for ; Thu, 30 Mar 2017 09:04:53 -0700 (PDT) Received: from dhcp-84d4.meeting.ietf.org (unknown [31.133.132.212]) (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 380B7509BD; Thu, 30 Mar 2017 12:04:52 -0400 (EDT) From: Sean Leonard Message-Id: <72CD4CDB-51BD-410C-908D-478AFB4A9411@seantek.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_4BC4D2CD-F33B-4166-BAC6-39AC8CEAB6E6" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 30 Mar 2017 11:04:51 -0500 In-Reply-To: <3a9aaca8-204c-2a6c-2fc5-f74870effc2e@eff.org> Cc: ACME WG , Ilari Liusvaara To: Jacob Hoffman-Andrews References: <20170329195427.GA23764@LK-Perkele-V2.elisa-laajakaista.fi> <525f79bb-a2e6-bf09-30e5-e80e0bb80379@eff.org> <3a9aaca8-204c-2a6c-2fc5-f74870effc2e@eff.org> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Acme] draft-ietf-acme-acme-06: Don't call it PEM Certificate Chain 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, 30 Mar 2017 16:04:56 -0000 --Apple-Mail=_4BC4D2CD-F33B-4166-BAC6-39AC8CEAB6E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 30, 2017, at 10:47 AM, Jacob Hoffman-Andrews = wrote: >=20 >> Therefore the =E2=80=9Creceiver=E2=80=9D is the ACME client, which = also is the web/TLS > server that incorporates the chain into its operations. >=20 > Note that in common deployment today, the ACME client is separate from > the web server. Ok. >=20 > On 03/30/2017 08:27 AM, Sean Leonard wrote: >> Contents: DER-encoded certificates, concatenated in RFC 5246 Section >> 7.4.2 order=20 > Is there a straightforward OpenSSL command to convert this entity into = a > PEM file containing multiple certificates? I don't think there is but = I > could be wrong. It=E2=80=99s straightforward. I=E2=80=99ll research it later=E2=80=A6if = it=E2=80=99s not =E2=80=9Cstraightforward enough=E2=80=9D I can just = write a script for you all to take. >> This is easier and better than stringing the textual encoded versions = because you don=E2=80=99t have to deal with text metadata issues, = charsets, line endings, and extra processing. Specifically, an ACME = server is going to have to take the certificate bytes and base64-encode = each one, followed by ASCII armoring. Then the ACME client is going to = have to reverse this. No point and confusing. > Our expectation is that many ACME clients will *not* reverse the = base64 > and ASCII armoring, but will write out the entire contents to a file = for > ingestion by a web server. The two most popular web servers, Apache = and > Nginx, consume PEM-formatted certificate chains. Yeah, that=E2=80=99s a problem, you need to be #@($#@ sure that you are = validating the response from the ACME client. RFC 7468 discusses implementations considerations with multiple = textually encoded crypto items (Section 2, Section 14). If you are = ingesting a stream that has textually encoded items, you need to = =E2=80=9Chunt-and-pick=E2=80=9D exactly what you are looking for, and = validate the contents. IN PARTICULAR: both Apache and Ngnix may be subject to a private key = substitution attack with naive passing of the ACME response to the web = server! See: http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_certificate = http://httpd.apache.org/docs/current/mod/mod_ssl.html#sslcertificatefile = = The SSL Certificate option includes the option of including the private = key in the same input: =E2=80=9CA secret key in the PEM format may be = placed in the same file.=E2=80=9D=20 What this means is that a malicious ACME server can serve a certificate = per the client=E2=80=99s request, but substitute the server=E2=80=99s = specified private key with the ACME server=E2=80=99s own choice of = private key by including -----BEGIN RSA PRIVATE KEY----- in the = response. Then when put into production, the ACME server operator will = be able to decrypt all of the traffic. WHOOPS. (Obviously the ACME = server can impersonate the web/TLS server, since it=E2=80=99s a CA = component, but this is not what you want.) Different implementations may behave differently: the moral lesson is to = validate your inputs, and in this case, that means to deal with the = certificate chain response with a lot more finesse than is contemplated = with =E2=80=9Capplication/pem-certificate-chain=E2=80=9D. >=20 > You're right that an ACME client would have to decode this format if > they wanted to change it to something else, but what we are seeing in > practice is clients that simply convert the end-entity certificate = from > DER to PEM and don't bother with the intermediates, resulting in > end-user pain. Check out the above. :-) >=20 >> For those who don=E2=80=99t like binary, ACME is JSON-based, so you = can just have an application/json response that is just an array: >>=20 >> [=E2=80=9CMIICAS...base64 of end-entity cert=E2=80=9D,=E2=80=9CMIICAS=E2= =80=A6base64 of second cert=E2=80=A6=E2=80=9D=E2=80=A6to root] > For me, "don't like binary" isn't the issue. If CMS were the most = common > certificate chain input format for web servers, I would be fine with > returning binary CMS. Unfortunately, it is not. Right, but =E2=80=9CPEM=E2=80=9D is not the format that you are actually = looking for in this case, despite its apparent ease of use. What this = draft is calling application/pem-certificate-chain boils down to = text/plain, and at least text/plain makes the security issues more = obvious (because the ACME client is ingesting arbitrary inputs). Let=E2=80=99s address the issue raised above first=E2=80=A6 Sean= --Apple-Mail=_4BC4D2CD-F33B-4166-BAC6-39AC8CEAB6E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Mar 30, 2017, at 10:47 AM, Jacob Hoffman-Andrews <jsha@eff.org> = wrote:

Therefore the = =E2=80=9Creceiver=E2=80=9D is the ACME client, which also is the = web/TLS
server that incorporates the chain = into its operations.

Note that in common = deployment today, the ACME client is separate from
the web = server.

Ok.


On 03/30/2017 = 08:27 AM, Sean Leonard wrote:
Contents: DER-encoded certificates, concatenated in RFC 5246 = Section
7.4.2 order
Is there a = straightforward OpenSSL command to convert this entity into a
PEM file containing multiple certificates? I don't think = there is but I
could be wrong.

It=E2=80= =99s straightforward. I=E2=80=99ll research it later=E2=80=A6if it=E2=80=99= s not =E2=80=9Cstraightforward enough=E2=80=9D I can just write a script = for you all to take.

This is easier and better than stringing the textual encoded = versions because you don=E2=80=99t have to deal with text metadata = issues, charsets, line endings, and extra processing. Specifically, an = ACME server is going to have to take the certificate bytes and = base64-encode each one, followed by ASCII armoring. Then the ACME client = is going to have to reverse this. No point and confusing.
Our expectation is that many ACME clients will = *not* reverse the base64
and ASCII armoring, but will = write out the entire contents to a file for
ingestion by a = web server. The two most popular web servers, Apache and
Nginx, consume PEM-formatted certificate chains.

Yeah, = that=E2=80=99s a problem, you need to be #@($#@ sure that you are = validating the response from the ACME client.

RFC 7468 discusses implementations considerations = with multiple textually encoded crypto items (Section 2, Section 14). If = you are ingesting a stream that has textually encoded items, you need to = =E2=80=9Chunt-and-pick=E2=80=9D exactly what you are looking for, and = validate the contents.

IN = PARTICULAR: both Apache and Ngnix may be subject to a private key = substitution attack with naive passing of the ACME response to the web = server! See:

The SSL Certificate = option includes the option of including the private key in the same = input: =E2=80=9CA secret key in the PEM format may be placed in the same = file.=E2=80=9D 

What = this means is that a malicious ACME server can serve a certificate per = the client=E2=80=99s request, but substitute the server=E2=80=99s = specified private key with the ACME server=E2=80=99s own choice of = private key by including -----BEGIN RSA PRIVATE KEY----- in the = response. Then when put into production, the ACME server operator will = be able to decrypt all of the traffic. WHOOPS. (Obviously the ACME = server can impersonate the web/TLS server, since it=E2=80=99s a CA = component, but this is not what you want.)

Different implementations may behave differently: = the moral lesson is to validate your inputs, and in this case, that = means to deal with the certificate chain response with a lot more = finesse than is contemplated with = =E2=80=9Capplication/pem-certificate-chain=E2=80=9D.


You're right that an ACME client would have to = decode this format if
they wanted to change it to = something else, but what we are seeing in
practice is = clients that simply convert the end-entity certificate from
DER to PEM and don't bother with the intermediates, resulting = in
end-user pain.

Check = out the above. :-)


For those who don=E2=80=99t like binary, ACME = is JSON-based, so you can just have an application/json response that is = just an array:

[=E2=80=9CMIICAS...base64 of = end-entity cert=E2=80=9D,=E2=80=9CMIICAS=E2=80=A6base64 of second = cert=E2=80=A6=E2=80=9D=E2=80=A6to root]
For = me, "don't like binary" isn't the issue. If CMS were the most common
certificate chain input format for web servers, I would be = fine with
returning binary CMS. Unfortunately, it is = not.

Right, but =E2=80=9CPEM=E2=80=9D is not the format that you = are actually looking for in this case, despite its apparent ease of use. = What this draft is calling application/pem-certificate-chain boils down = to text/plain, and at least text/plain makes the security issues more = obvious (because the ACME client is ingesting arbitrary = inputs).

Let=E2=80= =99s address the issue raised above first=E2=80=A6

Sean
= --Apple-Mail=_4BC4D2CD-F33B-4166-BAC6-39AC8CEAB6E6-- From nobody Thu Mar 30 10:25: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 862921299E0 for ; Thu, 30 Mar 2017 10:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.798 X-Spam-Level: X-Spam-Status: No, score=-9.798 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, RCVD_IN_MSPIKE_H2=-2.796, 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 kKkn4ev8zWqT for ; Thu, 30 Mar 2017 10:25:26 -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 F16C5126DFB for ; Thu, 30 Mar 2017 10:25:25 -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:Cc:References:To:Subject; bh=TOxoVGZbuRyIbhCfggDtXo8Rq34eW5VPxJGJacOOtLI=; b=R80uXzBwPJKe5Um5A9BjIfbZgliUJx6QsuvtqqtMADvYsmi5RSlJFzPp/PPsfs60lPYtzbw6S1fvO6zmDROhj6l6PtPePZz5Jl6Vw12C6RPsO2P5PjCMyurq0yqoTexNG5vr2wvsnwNLhGsDiXHBimueO3Ox9WCPZlWg004IIFM=; Received: ; Thu, 30 Mar 2017 10:25:24 -0700 To: Sean Leonard References: <20170329195427.GA23764@LK-Perkele-V2.elisa-laajakaista.fi> <525f79bb-a2e6-bf09-30e5-e80e0bb80379@eff.org> <3a9aaca8-204c-2a6c-2fc5-f74870effc2e@eff.org> <72CD4CDB-51BD-410C-908D-478AFB4A9411@seantek.com> Cc: ACME WG , Ilari Liusvaara From: Jacob Hoffman-Andrews Message-ID: <27d57bd9-68a7-37c1-ae99-f199a974a0b5@eff.org> Date: Thu, 30 Mar 2017 10:25:24 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <72CD4CDB-51BD-410C-908D-478AFB4A9411@seantek.com> Content-Type: multipart/alternative; boundary="------------83C6DB4C3EA1B81905122879" Received-SPF: skipped for local relay Archived-At: Subject: Re: [Acme] draft-ietf-acme-acme-06: Don't call it PEM Certificate Chain 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, 30 Mar 2017 17:25:29 -0000 This is a multi-part message in MIME format. --------------83C6DB4C3EA1B81905122879 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit On 03/30/2017 09:04 AM, Sean Leonard wrote: > IN PARTICULAR: both Apache and Ngnix may be subject to a private key > substitution attack with naive passing of the ACME response to the web > server! See: > http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_certificate > http://httpd.apache.org/docs/current/mod/mod_ssl.html#sslcertificatefile > > The SSL Certificate option includes the option of including the > private key in the same input: “A secret key in the PEM format may be > placed in the same file.” > > What this means is that a malicious ACME server can serve a > certificate per the client’s request, but substitute the server’s > specified private key with the ACME server’s own choice of private key > by including -----BEGIN RSA PRIVATE KEY----- in the response. Then > when put into production, the ACME server operator will be able to > decrypt all of the traffic. WHOOPS. (Obviously the ACME server can > impersonate the web/TLS server, since it’s a CA component, but this is > not what you want.) This is a good point, and makes me more inclined towards the "concatenated DER" approach you suggested, if it looks like it would be straightforward for clients to implement. Specifically because any client transforming the DER into PEM would be responsible for adding the "-----BEGIN CERTIFICATE-----" delimiters, and would be very unlikely to output private key delimiters instead. --------------83C6DB4C3EA1B81905122879 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit On 03/30/2017 09:04 AM, Sean Leonard wrote:
IN PARTICULAR: both Apache and Ngnix may be subject to a private key substitution attack with naive passing of the ACME response to the web server! See:

The SSL Certificate option includes the option of including the private key in the same input: “A secret key in the PEM format may be placed in the same file.” 

What this means is that a malicious ACME server can serve a certificate per the client’s request, but substitute the server’s specified private key with the ACME server’s own choice of private key by including -----BEGIN RSA PRIVATE KEY----- in the response. Then when put into production, the ACME server operator will be able to decrypt all of the traffic. WHOOPS. (Obviously the ACME server can impersonate the web/TLS server, since it’s a CA component, but this is not what you want.)
This is a good point, and makes me more inclined towards the "concatenated DER" approach you suggested, if it looks like it would be straightforward for clients to implement. Specifically because any client transforming the DER into PEM would be responsible for adding the "-----BEGIN CERTIFICATE-----" delimiters, and would be very unlikely to output private key delimiters instead.
--------------83C6DB4C3EA1B81905122879-- From nobody Thu Mar 30 10:26: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 A04B1126DFB for ; Thu, 30 Mar 2017 10:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.891 X-Spam-Level: X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_HK_NAME_DR=0.01] 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 SRx5DUI0HV-1 for ; Thu, 30 Mar 2017 10:26:25 -0700 (PDT) Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id 765B01299F7 for ; Thu, 30 Mar 2017 10:26:18 -0700 (PDT) Received: from dhcp-938a.meeting.ietf.org (dhcp-938a.meeting.ietf.org [31.133.147.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id 349903740F9F for ; Thu, 30 Mar 2017 13:26:18 -0400 (EDT) From: "Dr. Pala" To: acme@ietf.org Organization: OpenCA Labs Message-ID: Date: Thu, 30 Mar 2017 12:26:17 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Acme] draft-shaffer-acme-star-lurk: key lifetime ? 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, 30 Mar 2017 17:26:26 -0000 Hi all, I have a small question about the I-D. In particular, it seems to me that this proposal circumvents any limitation on the effective lifetime of a short-lived-cert's keypair. From a cryptographic standpoint of view, it is good practice to impose strict lifetimes on keys (i.e., usually via validity periods in certificates) to limit the issue of successful attacks on the crypto scheme (e.g., key factorization). This proposal would de-facto remove this property by adopting re-issuing instead of re-keying when renewing a certificate. Although the CA might be able to track the usage of a key from the initial CSRs, the automatic issuance of the certificate itself without the constraints of the key longevity seems quite dangerous and possibly open to a policy of "set-and-forget" that might last for... years... (automatically not re-issuing the certificate based on key-size + CSR timestamp would, I think, create issues for CDNs as there would be no indication when a new LURK/CSR cycle is needed). Am I reading it wrong / missing something ? Cheers, Max -- Massimiliano Pala, PhD Director at OpenCA Labs twitter: @openca From nobody Thu Mar 30 10:52:03 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 F36DF12945C for ; Thu, 30 Mar 2017 10:52:00 -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=rtfm-com.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 opfs4jUkc5wl for ; Thu, 30 Mar 2017 10:51:58 -0700 (PDT) Received: from mail-yb0-x236.google.com (mail-yb0-x236.google.com [IPv6:2607:f8b0:4002:c09::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 3AF2E128616 for ; Thu, 30 Mar 2017 10:51:58 -0700 (PDT) Received: by mail-yb0-x236.google.com with SMTP id l201so685631ybf.0 for ; Thu, 30 Mar 2017 10:51:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xfPhxwWUOHaZzgVr6P8/T0l2LSUlcmCkiz4U/GuLrCQ=; b=rmGEeOME2rcc0O7Ze2IKjnHq6qmg93+YhzEGoN1ddTOM/FK31M67AHom1J+KKa3YJ6 eop5Tu1roxVmLkoPgjUK4VMPSXzT/r1q4YlKFdayFkrSn0PHMin7FGTvufADGOhbYo3g k7cHE/m8qFzehibw6Kn59gH5BCa/736xhqnc8ppyRCnF7SVyd8HlqrOxdoUA5nYaRtJz seEcxOKtrXLpaxdhZmSr3HVVVC3JRKjfyFO6pCpcPcI7symHZ11F2+4DM7Cojd37FpMK 8mleQ/y8fe9GVlC/dUk7Wvv0w+sWcqkc3ZVnvI0aO1P9T4wW6eQ+T9bbyhOw1x4hAC2x hrKg== 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=xfPhxwWUOHaZzgVr6P8/T0l2LSUlcmCkiz4U/GuLrCQ=; b=kn1TxAgYx8JhjjD2vetM4OjQNDU2sQ9h6rSvi9Fzk+lC9ceoGtc6xwC0yg6jpWSG38 A/Fg10TO/QqEd7H7gPqTx0qAzpZJ3CWfkh3segAy54KpNOIKhYpexwXj0DQAnZ/LGnQV QLKnscLTx7ssY6ZgIUiZ3LuQDGJA68NgEUwzZ9ARZGpybBGbSkPxq2vf5JferbHv3e0h 9R01KvtPopspboyp7xAsJHTXArpRnSOxXDPLOZgBVuAkrweoyOOo7K3JE0vCaRLqxZgP VSN48zOCkACEtj1i9FOtKr2kVB25B09wkkHaZNZUkLVtc4q6wjaUYvAVJgeCbEjiQYGd fckQ== X-Gm-Message-State: AFeK/H358PGbR7RzFscjFS3WCzL+n9iIcGqnUK4w5wDmCsoMa8tRGGb84eDAEhk0HOh34EWjZ31sXsREBFQwaQ== X-Received: by 10.37.53.138 with SMTP id c132mr740332yba.105.1490896317375; Thu, 30 Mar 2017 10:51:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Thu, 30 Mar 2017 10:51:16 -0700 (PDT) In-Reply-To: References: <053ecf7e-d5c0-2a78-45d7-6ae387e1a4c8@eff.org> From: Eric Rescorla Date: Thu, 30 Mar 2017 12:51:16 -0500 Message-ID: To: Alan Doherty Cc: Martin Thomson , Jacob Hoffman-Andrews , "acme@ietf.org" Content-Type: multipart/alternative; boundary=001a114bbb32651b62054bf65997 Archived-At: Subject: Re: [Acme] Generating nonces probabilistically in 6.4.1. Replay-Nonce 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, 30 Mar 2017 17:52:01 -0000 --001a114bbb32651b62054bf65997 Content-Type: text/plain; charset=UTF-8 As the veteran of many arguments about pseudorandomness and uniqueness, I think it's reasonable to consider a sufficiently long random string to be unique. "high probability" actually makes it worse, because 99.99 is actually a very high probability but not really a security boundary. If you want to provide more guidance, I would suggest instead giving a minimum length for the random string. -Ekr On Tue, Mar 28, 2017 at 7:16 AM, Alan Doherty wrote: > At 11:46 28/03/2017 Tuesday, Martin Thomson wrote: > >I agree with Jacob here. MUST seems appropriate, but requiring > >uniqueness absolutely imposes a constraint on server design that is so > >onerous that I would see it as impractical. (Also, the document > >doesn't really identify a scope for this uniqueness, which would > >probably be necessary if you had to avoid random generation.) > > > i think given a large enough set of transactions unique is impossible (and > guaranteeing a previous use in identical circumstances impossible, unlikely > but not guaranteeing) > thus as its impossible mathematically (unless using sequential numbers of > infinite length) > > its better to keep 'high probability' as the possibility of random > generating a sequence twice is always there, if its truly random > improbable can be done, impossible is infinitely more work (as would > require keeping all previous and negative matching an ever growing list > before use) > > > > >On 27 March 2017 at 16:46, Jacob Hoffman-Andrews wrote: > >> Forwarding on behalf of Erica Portnoy. > >> > >> I agree, the uniqueness should be a MUST, but I think "high probability" > >> should stay so random generation of nonces is acceptable. PR: > >> https://github.com/ietf-wg-acme/acme/pull/289 > >> > >> > >> -------- Forwarded Message -------- > >> Subject: Generating nonces probabilistically in 6.4.1. > Replay-Nonce > >> Resent-Date: Fri, 24 Mar 2017 18:19:35 -0700 (PDT) > >> Resent-From: alias-bounces@ietf.org > >> Resent-To: rlb@ipv.sx, jsha@eff.org, jdkasten@umich.edu > >> Date: Fri, 24 Mar 2017 18:03:53 -0700 > >> From: erica > >> To: draft-ietf-acme-acme@ietf.org > >> > >> > >> > >> In section 6.4.1. Replay-Nonce, it states: "The server should generate > >> the value provided in Replay-Nonce in such a way that they are unique to > >> each message, with high probability." > >> > >> Should this not be: "The server MUST generate the value provided in > >> Replay-Nonce in such a way that they are unique to each message." > >> > >> This is actually two separate items: > >> - First, that the server must, not should, generate a unique > >> Replay-Nonce. I can't imagine that we're ok with the spec allowing a > >> server to come under replay attacks, so this should probably be MUST. > >> - Second, do Replay-Nonces need to be certainly unique to each message? > >> Or are we merely attempting to mostly rule out replay attacks? If we > >> want to disable them completely, not just with extremely high > >> probability, then we should remove "with high probability". > >> > >> Best, > >> Erica Portnoy > >> > >> > >> _______________________________________________ > >> 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 > --001a114bbb32651b62054bf65997 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As the veteran of many arguments about pseudorandomness an= d uniqueness, I think
it's reasonable to consider a sufficiently lo= ng random string to be unique.

"high probabil= ity" actually makes it worse, because 99.99 is actually a very high
probability but not really a security boundary. If you want to prov= ide more guidance,
I would suggest instead giving a minimum lengt= h for the random string.

-Ekr

<= /div>

= On Tue, Mar 28, 2017 at 7:16 AM, Alan Doherty <ietf@alandoherty.net= > wrote:
At 11= :46 28/03/2017=C2=A0 Tuesday, Martin Thomson wrote:
>I agree with Jacob here.=C2=A0 MUST seems appropriate, but requiring >uniqueness absolutely imposes a constraint on server design that is so<= br> >onerous that I would see it as impractical.=C2=A0 (Also, the document >doesn't really identify a scope for this uniqueness, which would >probably be necessary if you had to avoid random generation.)


i think given a large enough set of transactions unique is impossibl= e (and guaranteeing a previous use in identical circumstances impossible, u= nlikely but not guaranteeing)
thus as its impossible mathematically (unless using sequential numbers of i= nfinite length)

its better to keep 'high probability' as the possibility of random = generating a sequence twice is always there, if its truly random
improbable can be done, impossible is infinitely more work (as would requir= e keeping all previous and negative matching an ever growing list before us= e)



>On 27 March 2017 at 16:46, Jacob Hoffman-Andrews <jsha@eff.org> wrote:
>> Forwarding on behalf of Erica Portnoy.
>>
>> I agree, the uniqueness should be a MUST, but I think "high p= robability"
>> should stay so random generation of nonces is acceptable. PR:
>> https://github.com/ietf-wg-acme/acme/pull= /289
>>
>>
>> -------- Forwarded Message --------
>> Subject:=C2=A0 =C2=A0 =C2=A0 =C2=A0 Generating nonces probabilisti= cally in 6.4.1. Replay-Nonce
>> Resent-Date:=C2=A0 =C2=A0 Fri, 24 Mar 2017 18:19:35 -0700 (PDT) >> Resent-From:=C2=A0 =C2=A0 alias-bounces@ietf.org
>> Resent-To:=C2=A0 =C2=A0 =C2=A0 rlb@ipv.sx, jsha@eff.org, jdkasten@u= mich.edu
>> Date:=C2=A0 =C2=A0Fri, 24 Mar 2017 18:03:53 -0700
>> From:=C2=A0 =C2=A0erica <erica= @eff.org>
>> To:=C2=A0 =C2=A0 =C2=A0draft-ietf-acme-acme@ietf.org
>>
>>
>>
>> In section 6.4.1. Replay-Nonce, it states: "The server should= generate
>> the value provided in Replay-Nonce in such a way that they are uni= que to
>> each message, with high probability."
>>
>> Should this not be: "The server MUST generate the value provi= ded in
>> Replay-Nonce in such a way that they are unique to each message.&q= uot;
>>
>> This is actually two separate items:
>> - First, that the server must, not should, generate a unique
>> Replay-Nonce. I can't imagine that we're ok with the spec = allowing a
>> server to come under replay attacks, so this should probably be MU= ST.
>> - Second, do Replay-Nonces need to be certainly unique to each mes= sage?
>> Or are we merely attempting to mostly rule out replay attacks? If = we
>> want to disable them completely, not just with extremely high
>> probability, then we should remove "with high probability&quo= t;.
>>
>> Best,
>> Erica Portnoy
>>
>>
>> _______________________________________________
>> 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

--001a114bbb32651b62054bf65997-- From nobody Thu Mar 30 10:54:23 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 C7758126557 for ; Thu, 30 Mar 2017 10:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.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 G-ZOfCcbECg7 for ; Thu, 30 Mar 2017 10:54:15 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::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 476611299F8 for ; Thu, 30 Mar 2017 10:54:15 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id p77so27948080ywg.1 for ; Thu, 30 Mar 2017 10:54:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IsRhZSe3LNffsDDzymvFrxpdH7PmmQ9as7kiPv0p9F0=; b=GGr1nlM1CoHg7m51Fe28M7p0V0qBnEp1MpriHGrGzvLVfvZAg3ICRiZoSF6VteT89N e34uyt7K+kIdLexWcCvOIscCpf4WzlHGzLsH+1NNDdolEmcDYSz2GmlRexD6x1soOjje 4lZMt2oZeUv6fOjWO5NT8vPKka7uxe38TMrS06Tx0wm3zE1X0PwKLSPdjK3pEwOqKaCL 3KUulKym1xGg1feVqtiMmfHLKh3JAzruNYbGOBcR0GPK/mYVvnJjNuUc1Lk8nTXSxnmm jfTfYk8Ab7NN4Gpz3lngIyJJK1fsdo3HtopyfGqekBAExJgzEWW97HmL97cGGx0VU9PN 6IGg== 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=IsRhZSe3LNffsDDzymvFrxpdH7PmmQ9as7kiPv0p9F0=; b=q72YPYmhNlyVm7H+kG32DpMgtVuVYs+/gCXjxrnwEsbiM/o5801pJfl7PQrblCeOdD LGe5DV8UhDNV+WMRosjXJEcVwBSCXLBzjv+2ktSv303wTx7gOeDVSkE7YYpTkdvNwgD6 rsjbu9myutTHmVzFTDIljVkWcXtr252hj6yglkIa16+YrBFlcDo9eZrgH0GfEQdI0bvd dwRJbELBwuPX5OEAj2b/DuRf3LIq6vZYpE/rA2xmsmYVVSv1nr08gZe0G/M/2NWvFZ8C mP3tqQw8r6EjLxVHhOnoZWlLqSSK/XRfd0JdZBd6WIMBXJ3SVol6es2djjxxvx1AAOOy 3k/w== X-Gm-Message-State: AFeK/H0pXdi5gHcvHRr1Vcgn9+avHFBnusOZzvC57kzHPwPy2NKp/4k8B8spADx2bKPlRBv/AyUlQ8TJskN5oA== X-Received: by 10.129.177.8 with SMTP id p8mr832811ywh.327.1490896454513; Thu, 30 Mar 2017 10:54:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Thu, 30 Mar 2017 10:53:34 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Thu, 30 Mar 2017 12:53:34 -0500 Message-ID: To: "Dr. Pala" Cc: IETF ACME Content-Type: multipart/alternative; boundary=94eb2c13ce3891ac37054bf661a5 Archived-At: Subject: Re: [Acme] draft-shaffer-acme-star-lurk: key lifetime ? 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, 30 Mar 2017 17:54:20 -0000 --94eb2c13ce3891ac37054bf661a5 Content-Type: text/plain; charset=UTF-8 I don't think it's the CA's job to dictate policy in this area. -Ekr On Thu, Mar 30, 2017 at 12:26 PM, Dr. Pala wrote: > Hi all, > > I have a small question about the I-D. In particular, it seems to me that > this proposal circumvents any limitation on the effective lifetime of a > short-lived-cert's keypair. From a cryptographic standpoint of view, it is > good practice to impose strict lifetimes on keys (i.e., usually via > validity periods in certificates) to limit the issue of successful attacks > on the crypto scheme (e.g., key factorization). This proposal would > de-facto remove this property by adopting re-issuing instead of re-keying > when renewing a certificate. > > Although the CA might be able to track the usage of a key from the initial > CSRs, the automatic issuance of the certificate itself without the > constraints of the key longevity seems quite dangerous and possibly open to > a policy of "set-and-forget" that might last for... years... (automatically > not re-issuing the certificate based on key-size + CSR timestamp would, I > think, create issues for CDNs as there would be no indication when a new > LURK/CSR cycle is needed). > > Am I reading it wrong / missing something ? > > Cheers, > Max > > -- > Massimiliano Pala, PhD > Director at OpenCA Labs > twitter: @openca > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > --94eb2c13ce3891ac37054bf661a5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I don't think it's the CA's job to dictate pol= icy in this area.

-Ekr


On Thu, Mar 30, 2017 at = 12:26 PM, Dr. Pala <director@openca.org> wrote:
Hi all,

I have a small question about the I-D. In particular, it seems to me that t= his proposal circumvents any limitation on the effective lifetime of a shor= t-lived-cert's keypair. From a cryptographic standpoint of view, it is = good practice to impose strict lifetimes on keys (i.e., usually via validit= y periods in certificates) to limit the issue of successful attacks on the = crypto scheme (e.g., key factorization). This proposal would de-facto remov= e this property by adopting re-issuing instead of re-keying when renewing a= certificate.

Although the CA might be able to track the usage of a key from the initial = CSRs, the automatic issuance of the certificate itself without the constrai= nts of the key longevity seems quite dangerous and possibly open to a polic= y of "set-and-forget" that might last for... years... (automatica= lly not re-issuing the certificate based on key-size + CSR timestamp would,= I think, create issues for CDNs as there would be no indication when a new= LURK/CSR cycle is needed).

Am I reading it wrong / missing something ?

Cheers,
Max

--
Massimiliano Pala, PhD
Director at OpenCA Labs
twitter: @openca

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

--94eb2c13ce3891ac37054bf661a5-- From nobody Thu Mar 30 11:00: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 8343C1293DA for ; Thu, 30 Mar 2017 11:00:24 -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, HTML_MESSAGE=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 3AL43oLtJbbD for ; Thu, 30 Mar 2017 11:00:21 -0700 (PDT) Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id 6B3B2129410 for ; Thu, 30 Mar 2017 11:00:20 -0700 (PDT) Received: from dhcp-88da.meeting.ietf.org (dhcp-88da.meeting.ietf.org [31.133.136.218]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id 163E03740F9F for ; Thu, 30 Mar 2017 14:00:20 -0400 (EDT) To: acme@ietf.org References: From: Max Organization: OpenCA Labs Message-ID: <0e98429f-7341-4af3-2b9f-3d518d054e9c@openca.org> Date: Thu, 30 Mar 2017 13:00:18 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------24C68837E7DC832506D2EEF1" Archived-At: Subject: Re: [Acme] draft-shaffer-acme-star-lurk: key lifetime ? 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, 30 Mar 2017 18:00:25 -0000 This is a multi-part message in MIME format. --------------24C68837E7DC832506D2EEF1 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Eric, I am not saying it is the CA job (although, good CAs will impose max life-times on keys), but it seems to me that this issue should be addressed since it would violate one of the basic security principles when it comes to crypto, i.e. key lifetime. Maybe adding something to this regard could be useful so that "TLS operators" and CDN operators do not shoot themselves in the foot :D Cheers, Max On 3/30/17 12:53 PM, Eric Rescorla wrote: > I don't think it's the CA's job to dictate policy in this area. > > -Ekr > > > On Thu, Mar 30, 2017 at 12:26 PM, Dr. Pala > wrote: > > Hi all, > > I have a small question about the I-D. In particular, it seems to > me that this proposal circumvents any limitation on the effective > lifetime of a short-lived-cert's keypair. From a cryptographic > standpoint of view, it is good practice to impose strict lifetimes > on keys (i.e., usually via validity periods in certificates) to > limit the issue of successful attacks on the crypto scheme (e.g., > key factorization). This proposal would de-facto remove this > property by adopting re-issuing instead of re-keying when renewing > a certificate. > > Although the CA might be able to track the usage of a key from the > initial CSRs, the automatic issuance of the certificate itself > without the constraints of the key longevity seems quite dangerous > and possibly open to a policy of "set-and-forget" that might last > for... years... (automatically not re-issuing the certificate > based on key-size + CSR timestamp would, I think, create issues > for CDNs as there would be no indication when a new LURK/CSR cycle > is needed). > > Am I reading it wrong / missing something ? > > Cheers, > Max > > -- > Massimiliano Pala, PhD > Director at OpenCA Labs > twitter: @openca > > _______________________________________________ > 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 -- Massimiliano Pala Director at OpenCA Labs twitter: @_mpala_ --------------24C68837E7DC832506D2EEF1 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit

Hi Eric,

I am not saying it is the CA job (although, good CAs will impose max life-times on keys), but it seems to me that this issue should be addressed since it would violate one of the basic security principles when it comes to crypto, i.e. key lifetime. Maybe adding something to this regard could be useful so that "TLS operators" and CDN operators do not shoot themselves in the foot :D

Cheers,
Max


On 3/30/17 12:53 PM, Eric Rescorla wrote:
I don't think it's the CA's job to dictate policy in this area.

-Ekr


On Thu, Mar 30, 2017 at 12:26 PM, Dr. Pala <director@openca.org> wrote:
Hi all,

I have a small question about the I-D. In particular, it seems to me that this proposal circumvents any limitation on the effective lifetime of a short-lived-cert's keypair. From a cryptographic standpoint of view, it is good practice to impose strict lifetimes on keys (i.e., usually via validity periods in certificates) to limit the issue of successful attacks on the crypto scheme (e.g., key factorization). This proposal would de-facto remove this property by adopting re-issuing instead of re-keying when renewing a certificate.

Although the CA might be able to track the usage of a key from the initial CSRs, the automatic issuance of the certificate itself without the constraints of the key longevity seems quite dangerous and possibly open to a policy of "set-and-forget" that might last for... years... (automatically not re-issuing the certificate based on key-size + CSR timestamp would, I think, create issues for CDNs as there would be no indication when a new LURK/CSR cycle is needed).

Am I reading it wrong / missing something ?

Cheers,
Max

--
Massimiliano Pala, PhD
Director at OpenCA Labs
twitter: @openca

_______________________________________________
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


-- 
Massimiliano Pala
Director at OpenCA Labs
twitter: @_mpala_
--------------24C68837E7DC832506D2EEF1-- From nobody Thu Mar 30 12:06: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 6135B129A2B for ; Thu, 30 Mar 2017 12:06:45 -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 W2AfYG5JGbYp for ; Thu, 30 Mar 2017 12:06:43 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 7D03B129A56 for ; Thu, 30 Mar 2017 12:06:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id EFE3624D5E; Thu, 30 Mar 2017 22:06:36 +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-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id JVQ7-U3exZ5e; Thu, 30 Mar 2017 22:06:36 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id C00D6289; Thu, 30 Mar 2017 22:06:36 +0300 (EEST) Date: Thu, 30 Mar 2017 22:06:34 +0300 From: Ilari Liusvaara To: "Dr. Pala" Cc: acme@ietf.org Message-ID: <20170330190634.GA26494@LK-Perkele-V2.elisa-laajakaista.fi> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [Acme] draft-shaffer-acme-star-lurk: key lifetime ? 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, 30 Mar 2017 19:06:45 -0000 On Thu, Mar 30, 2017 at 12:26:17PM -0500, Dr. Pala wrote: > > I have a small question about the I-D. In particular, it seems to me that > this proposal circumvents any limitation on the effective lifetime of a > short-lived-cert's keypair. From a cryptographic standpoint of view, it is > good practice to impose strict lifetimes on keys (i.e., usually via validity > periods in certificates) to limit the issue of successful attacks on the > crypto scheme (e.g., key factorization). This proposal would de-facto remove > this property by adopting re-issuing instead of re-keying when renewing a > certificate. I do not think that limiting key lifetime is necressarily a good idea. Usually, when you discover that your key is compromised (using the WebPKI definition), the attackers have been in position to compromise your keys for who knows how long. If you rotated keys, all (or at least a long list) the past keys are considered compromised too. The threat of using stolen keypairs to decrypt sessions is exactly what PFS is meant to defend against. There's also key rollovers for parameter updates, but those are quite rare, and are not emergency rollovers. There are already parameters where the time that happens is either: 1) Major cryptographical break- through, or 2) Large quantum computers are invented. So, I don't think CA should do anything with key lifetimes (outside obvious indications that key is not good, like revocation with KeyCompromise). -Ilari From nobody Thu Mar 30 13:36: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 21A6F12943C for ; Thu, 30 Mar 2017 13:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.891 X-Spam-Level: X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_HK_NAME_DR=0.01] 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 SI_wZU9WDbWJ for ; Thu, 30 Mar 2017 13:36:33 -0700 (PDT) Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id 38FD41293D9 for ; Thu, 30 Mar 2017 13:36:32 -0700 (PDT) Received: from dhcp-88da.meeting.ietf.org (dhcp-88da.meeting.ietf.org [31.133.136.218]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id CF7263740F9F for ; Thu, 30 Mar 2017 16:36:31 -0400 (EDT) To: acme@ietf.org References: <20170330190634.GA26494@LK-Perkele-V2.elisa-laajakaista.fi> From: "Dr. Pala" Organization: OpenCA Labs Message-ID: <32f6b34b-5784-93a6-b817-8e7662c011bb@openca.org> Date: Thu, 30 Mar 2017 15:36:30 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170330190634.GA26494@LK-Perkele-V2.elisa-laajakaista.fi> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Acme] draft-shaffer-acme-star-lurk: key lifetime ? 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, 30 Mar 2017 20:36:35 -0000 Hi Ilari, all, I strongly disagree with your statement. From a crypto standpoint, key rotation IS an important point and should be addressed. I think something could/should be added to the I-D to limit the number of renewal or the period where the same CSR can be used for certificate re-issuing. The solution might be as simple as set a validity in the CSR that is generated (if you want that to be in control of the requesting client). I am not suggesting the specifics of how to solve it, but I think that this is a point that should be addressed (possibly something that was in the mind of the original authors, but did not make it in the document... ?). What is the position of the I-D authors ? Just my 2 cents, of course :D Cheers, Max On 3/30/17 2:06 PM, Ilari Liusvaara wrote: > On Thu, Mar 30, 2017 at 12:26:17PM -0500, Dr. Pala wrote: >> I have a small question about the I-D. In particular, it seems to me that >> this proposal circumvents any limitation on the effective lifetime of a >> short-lived-cert's keypair. From a cryptographic standpoint of view, it is >> good practice to impose strict lifetimes on keys (i.e., usually via validity >> periods in certificates) to limit the issue of successful attacks on the >> crypto scheme (e.g., key factorization). This proposal would de-facto remove >> this property by adopting re-issuing instead of re-keying when renewing a >> certificate. > I do not think that limiting key lifetime is necressarily a good idea. > > Usually, when you discover that your key is compromised (using the > WebPKI definition), the attackers have been in position to compromise > your keys for who knows how long. If you rotated keys, all (or at least > a long list) the past keys are considered compromised too. > > The threat of using stolen keypairs to decrypt sessions is exactly > what PFS is meant to defend against. > > There's also key rollovers for parameter updates, but those are quite > rare, and are not emergency rollovers. There are already parameters > where the time that happens is either: 1) Major cryptographical break- > through, or 2) Large quantum computers are invented. > > > So, I don't think CA should do anything with key lifetimes (outside > obvious indications that key is not good, like revocation with > KeyCompromise). > > > > -Ilari > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme -- Massimiliano Pala, PhD Director at OpenCA Labs twitter: @openca From nobody Thu Mar 30 16:42: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 12F33126CC7 for ; Thu, 30 Mar 2017 16:42:28 -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, 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 (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 WO2DJOO2hvB4 for ; Thu, 30 Mar 2017 16:42:25 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::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 722EE129510 for ; Thu, 30 Mar 2017 16:42:25 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id o67so46246273oib.1 for ; Thu, 30 Mar 2017 16:42: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=kt0Hhdnw+eQ16eCAiVg3TtjhQWBdVDhOOT82HiaDC4I=; b=b3WNK7IyrvDdyYbSmyTbih9wejE+X9bzCKatRVHShhQdeW1hrnu4kejswYA7bvO/9z QaDjOo21XaVGKMLZmNxXjfwGzjTQMpCBU+gklZF/VvYxH92w43togGzpxPxdKWQ/zHf5 OX99LCCVbEsE0d6Uw4r/WE0b8JfYf5E0vZq+irrd6Km2BZO5Xs68k7NYJrtyL8re4riB apj+a8sgnmYXYjBZP5h2cOH+3rghwdTQ8xiyObGDyzYIMBkoNjvJHEVAmNwfyUPp5wwC vsbPvODz7m/DGGMzeKK0GtoTsoewRyCAP9bYABXeGHcV5cbxrxB+rKR/OPdWsC0WqRlA 0hOQ== 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=kt0Hhdnw+eQ16eCAiVg3TtjhQWBdVDhOOT82HiaDC4I=; b=G5PaaA8EtOLzUL3bqYIGD5qUp8vmVTB7EhYJBNhse/2yElO9R4TVIZuYZdWjiK2KZA +swayCnShoMQKG5UPj3I3ahgfHZirW7zQjAad1irR0J7gZVMLGgHF8wsis0lg3kCsIjl JZ2/fh0tokSyx9GU2EYmfbpanOyz1YC8O9e3z4jiaH1KZi5m5QYiKI08WT193PEukexx BF6lvPKr3P4qYhzXrILlCC04YCumzppgxFkiLWJ+Wt54NEdFdzn6FVrODj7yRmyQYhR+ h7cXJ7V4CTGir6f7X0BtE6ipz0z2gik2Y9M+r0FGMMX47H0RwGvdAzNzky3Pu8Gdflf6 kt6w== X-Gm-Message-State: AFeK/H0BSP9sYhhaq7gHYX7i5pfQgIrySQFziXPMAG7x+85P5apsjqK/2MxTAqgo2crE74qcyDps28F/AYvpSQ== X-Received: by 10.202.81.207 with SMTP id f198mr34756oib.136.1490917344906; Thu, 30 Mar 2017 16:42:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.47.171 with HTTP; Thu, 30 Mar 2017 16:42:23 -0700 (PDT) Received: by 10.157.47.171 with HTTP; Thu, 30 Mar 2017 16:42:23 -0700 (PDT) In-Reply-To: References: From: Josh Soref Date: Thu, 30 Mar 2017 19:42:23 -0400 Message-ID: To: cpu@letsencrypt.org Cc: IETF ACME Content-Type: multipart/alternative; boundary=001a1146b7f0bb92e5054bfb3e23 Archived-At: Subject: Re: [Acme] Allowing clients to understand the account creation functionality supported by a server 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, 30 Mar 2017 23:42:28 -0000 --001a1146b7f0bb92e5054bfb3e23 Content-Type: text/plain; charset=UTF-8 >From my perspective, the UX from not having this feature is pretty awful. And for clients to try to make the UX not awful, they'd have to add quite a bit of complexity. I'd much rather a must with a bit of extra information in the meta directory. --001a1146b7f0bb92e5054bfb3e23 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
From my perspective, the = UX from not having this feature is pretty awful. And for clients to try to = make the UX not awful, they'd have to add quite a bit of complexity.

I'd much rather a must with a bit of extra info= rmation in the meta directory.
--001a1146b7f0bb92e5054bfb3e23-- From nobody Thu Mar 30 23:07:23 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 A44941279EB for ; Thu, 30 Mar 2017 23:07:21 -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 Yb9K3_1spU5b for ; Thu, 30 Mar 2017 23:07:19 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 24B7A126B72 for ; Thu, 30 Mar 2017 23:07:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 40E3D2050D; Fri, 31 Mar 2017 09:07:16 +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-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id SslUrngq-Yz7; Fri, 31 Mar 2017 09:07:16 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 149B7C4; Fri, 31 Mar 2017 09:07:16 +0300 (EEST) Date: Fri, 31 Mar 2017 09:07:14 +0300 From: Ilari Liusvaara To: "Dr. Pala" Cc: acme@ietf.org Message-ID: <20170331060714.GA26933@LK-Perkele-V2.elisa-laajakaista.fi> References: <20170330190634.GA26494@LK-Perkele-V2.elisa-laajakaista.fi> <32f6b34b-5784-93a6-b817-8e7662c011bb@openca.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <32f6b34b-5784-93a6-b817-8e7662c011bb@openca.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [Acme] draft-shaffer-acme-star-lurk: key lifetime ? 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, 31 Mar 2017 06:07:22 -0000 On Thu, Mar 30, 2017 at 03:36:30PM -0500, Dr. Pala wrote: > Hi Ilari, all, > > I strongly disagree with your statement. From a crypto standpoint, key > rotation IS an important point and should be addressed. I think something > could/should be added to the I-D to limit the number of renewal or the > period where the same CSR can be used for certificate re-issuing. > > The solution might be as simple as set a validity in the CSR that is > generated (if you want that to be in control of the requesting client). I am > not suggesting the specifics of how to solve it, but I think that this is a > point that should be addressed (possibly something that was in the mind of > the original authors, but did not make it in the document... ?). I just read the draft. A facility to limit the private key period, assuming you want to do that, already exists. And there are a number of sane-looking metrics[1], where any timed key rotation strictly[2] decreases security. [1] Basically, anything that considers security issue duration. [2] Meaning you get '<' operator in comparision, not '<='. -Ilari From nobody Fri Mar 31 07: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 BF1EE12995F for ; Fri, 31 Mar 2017 07:53:06 -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 eZtW-q1B1--U for ; Fri, 31 Mar 2017 07:53:04 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::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 38117124281 for ; Fri, 31 Mar 2017 07:53:03 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id r45so67237919qte.3 for ; Fri, 31 Mar 2017 07:53:03 -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=9xqgiQYdCgXW4Got6hcz4t4QQ9YFLD/2SVVJpRkYc2Y=; b=Asv8G6yblcjgoKzHpStB3XFtB82rZD315jKstWWr/6YbdMhzmSH5Ftht9/fHtYZHcl DkC1cnGs5dUc8Dg6PsR5GUY0a+x0EDXOAhPKZRaivcbGD/JMOY5Beu6rvMjOZ2Wfw8RY Ng98cBE/k04oEPWkLiTikOpQ+S5Satm1BwJgvMEkyJ9m4v8AuuRJHfuXq0LDNR+RkTKu c4+Oi7jtR2krEZpu1xHxc6yLI+apMJ374OrmMq7sYTvDaNhBH9oj+CBdoxbbbHrbiTIu ZI9p11s94pwx60iX6xgvbqzYT0PtdLBQwytuB64b4IAFTTMprxnIXsZ/VQrXKjwpk0di eLuQ== 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=9xqgiQYdCgXW4Got6hcz4t4QQ9YFLD/2SVVJpRkYc2Y=; b=mYTjJywULfP1t47OADONketbsmZIkmkIpZVbFu/H4+xJi9PA3n15OXmcVYM34WVX2H kBIqMSsS4dAUaK5czmYFSxu+hTF2HjStyih3BK5LyMBBvRF/wHa4OYoNSO+4YtVJ0SeG 7PVmseQ+yn5Qj+ZX8hCNTyMkNc4DElBJWC/DckC+Q/0k6X35LdEKH0SsFmv8f4UXRLst LYTAkkKypG+8c+eHiiU9rJSxgviypp1Kk6o5P3g+OHWXR9Rmc/DlsCA7E056Z461bLZS 5cHSQniPkePJwVvXftUKNoD6Pkyl1O7TQ7QH6jB6vSCv0/ONayMz/lTIau4kgfuq6tly nsTw== X-Gm-Message-State: AFeK/H106sBErlPopVkQRTDonIXQXD8qDOua86+ZMxxdaLOjMHBnr4OdJKFnUxtYeexO9NcLZIxSq6cprwh5FQ== X-Received: by 10.200.39.97 with SMTP id h30mr3064131qth.18.1490971982023; Fri, 31 Mar 2017 07:53:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.54.2 with HTTP; Fri, 31 Mar 2017 07:52:31 -0700 (PDT) From: Ted Hardie Date: Fri, 31 Mar 2017 09:52:31 -0500 Message-ID: To: "acme@ietf.org" , "Salz, Rich" Content-Type: multipart/alternative; boundary=001a114042685bd4f7054c07f7e3 Archived-At: Subject: [Acme] Draft minutes 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, 31 Mar 2017 14:53:07 -0000 --001a114042685bd4f7054c07f7e3 Content-Type: text/plain; charset=UTF-8 Thanks to Thomas Fossati, here are draft minutes. Please review and comment on the list. thanks, Ted and Rich # ACME Working Group Chicago - Thu, March 30 2017 ## Slides - https://www.ietf.org/proceedings/98/slides/slides-98-acme-acme-chair-slides-ietf-98-01.pdf ## Meetecho recording - http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF98_ACME&chapter=chapter_1 ## Review of Open PRs - [#272 Use correct challenge names in the IANA list]( https://github.com/ietf-wg-acme/acme/pull/272) (slide 12) is an important one about which challenge names to use. - **Decision**: use existing explicit versioning (i.e., http-01, tls-sni-02 and dns-01) to avoid unnecessary churn. ## Review of Open Issues - [#242 Enable cleanup of "leaked" pending authorizations]( https://github.com/ietf-wg-acme/acme/issues/242) (slide 14) buggy client(s) creating authorizations that were not finalised. - **Decision** is to close this issue with no action. The rationale being there's no need to add protocol machinery to deal with what looks like a (mis-)implementation issue. Besides, `orders` already have an `expires` attribute that could be used exactly for this purpose. - [#237 Recommended polling Order vs. Authz]( https://github.com/ietf-wg-acme/acme/pull/232) (slide 15) - Proposal to change the poll for status to `GET order` instead of `GET authz`. - Jacob: based on Hugo's feedback on retriable challenges, this should not be changed. - [#236 ACME resource relations]( https://github.com/ietf-wg-acme/acme/issues/236) (slide 16) - Chairs ask if there exist implementations that rely on this link relation. No one has. - **Decision** is to get rid of `up` (i.e., third's third bullet in slide 16) ## Mailing list issues - **Require servers to accept at least one automated revocation method** (slide 18) - Discussion: server implementers confirm this matches CA revocation practices. - **Decision** is to change the 2 SHOULDs in slide 18 into 2 MUSTs - **Advertise server contact support** (slide 19) - Discussion: Ted highlights the risk of failure in negotiation (empty intersection) a single MTI scheme is necessary and sufficient for interop - **Decision** is to REQUIRE `mailto` as URL scheme so that it's always possible to fall back to it - **Retrying failed authorisations** (slide 20) - (in the slide, there's a nice write-up of the problem) - Discussion: - Jacob H / RLB propose to re-POST the authz on failure while keeping a list of failed attempts with an explicit error attached by the CA - and a way to correlate those errors with their corresponding attempt. - Chairs: this approach is big enough to require a further WGLC cycle - **Decision** is for editors to apply the proposed change, then we will run another WGLC - **Don't call it PEM certificate chain** (slide 21) - Proposal by Sean on the [mailing list]( https://www.ietf.org/mail-archive/web/acme/current/msg01857.html) - **Decision(s)**: - Editors to go and fix the terminology (change MIME type + some stuff related to the charset, etc.) as suggested in the first of Sean's messages according to the referenced RFC; - Add text to the security consideration sections about the private key insertion attack raised by Sean. - (Any resolution will be revised on the list.) - EKR from the floor: **Generating nonces probabilistically [#289]( https://github.com/ietf-wg-acme/acme/pull/289)** (not on any slide) - **Decision**: either nonces are constructed to be unique or, if generated randomly, it should sufficient to require enough entropy (120 bits or more) (Rich takes over from RLB) ## Other issues raised on the list - **Require CAA as part of validation?** - Discussion: - RLB: not at the protocol level. This is for the CA/B forum to prescribe, which, as Hugo pointed out, has in fact already specified this requirement in a recently published (March 2017) document. - **Decision**: add this to the CA consideration in document - **Require DNSSEC for name validation?** - Discussion: - Viktor: CA burden to do validation is minimal (just implement DNSSEC client / validator resolver and MUST do validation) - Ted: instead of framing this as a requirement, explain the threat and put into the security considerations with associated mitigations? - RB believes we already have that kind of text in the security consideration, which proposes doing the verification from multiple vantage points as a mitigation. - Discussion non-conclusive. Not enough consensus to even try the hum on this topic. Put this back to the mailing list. - **Changes are significant enough to require an interop round?** - Discussion - RB: no recent enough draft has been implemented - Let's Encrypt implemented -03 -- to catch up on -latest they think 2/3 months needed (optimistically); Digicert in the same ballpark. - Plan is to run WGLC and finish it before Prague -- that will inform the implementations. --001a114042685bd4f7054c07f7e3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks to Thomas Fossati, here are draft minutes= .=C2=A0 Please review and comment on the list.

thanks,

=
Ted and Rich

# ACME Working Group

Chicago - Thu, March = 30 2017

## Slides
- https://www.ietf.= org/proceedings/98/slides/slides-98-acme-acme-chair-slides-ietf-98-01.pdf

## Meetecho recording

- h= ttp://recs.conf.meetecho.com/Playout/watch.jsp?recording=3DIETF98_ACME&= chapter=3Dchapter_1

## Review of Open PRs

- [#272 Use cor= rect challenge names in the IANA list](https://github.com/ietf-wg-acme/acme/pull/272) (s= lide 12) is an important one about which challenge names to use.
=C2=A0-= **Decision**: use existing explicit versioning (i.e., http-01, tls-sni-02 = and dns-01) to avoid unnecessary churn.

## Review of Open Issues
=
- [#242 Enable cleanup of "leaked" pending authorizations](https://github.co= m/ietf-wg-acme/acme/issues/242) (slide 14) buggy client(s) creating aut= horizations that were not finalised.
=C2=A0 - **Decision** is to close t= his issue with no action.=C2=A0 The rationale being there's no need to = add protocol machinery to deal with what looks like a (mis-)implementation = issue.=C2=A0 Besides, `orders` already have an `expires` attribute that cou= ld be used exactly for this purpose.

- [#237 Recommended polling Ord= er vs. Authz](htt= ps://github.com/ietf-wg-acme/acme/pull/232) (slide 15)
=C2=A0 - Prop= osal to change the poll for status to `GET order` instead of `GET authz`.=C2=A0 - Jacob: based on Hugo's feedback on retriable challenges, thi= s should not be changed.

- [#236 ACME resource relations](https://github.com/ietf-w= g-acme/acme/issues/236) (slide 16)
=C2=A0 - Chairs ask if there exis= t implementations that rely on this link relation.=C2=A0 No one has.
=C2= =A0 - **Decision** is to get rid of `up` (i.e., third's third bullet in= slide 16)

## Mailing list issues

- **Require servers to acce= pt at least one automated revocation method** (slide 18)
=C2=A0 - Discus= sion: server implementers confirm this matches CA revocation practices.
= =C2=A0 - **Decision** is to change the 2 SHOULDs in slide 18 into 2 MUSTs
- **Advertise server contact support** (slide 19)
=C2=A0 - Discuss= ion: Ted highlights the risk of failure in negotiation (empty intersection)= a single MTI scheme is necessary and sufficient for interop
=C2=A0 - **= Decision** is to REQUIRE `mailto` as URL scheme so that it's always pos= sible to fall back to it

- **Retrying failed authorisations** (slide= 20)
=C2=A0 - (in the slide, there's a nice write-up of the problem)=
=C2=A0 - Discussion:
=C2=A0=C2=A0=C2=A0 - Jacob H / RLB propose to r= e-POST the authz on failure while keeping a list of failed attempts with an= explicit error attached by the CA - and a way to correlate those errors wi= th their corresponding attempt.
=C2=A0=C2=A0=C2=A0 - Chairs: this approa= ch is big enough to require a further WGLC cycle
=C2=A0 - **Decision** i= s for editors to apply the proposed change, then we will run another WGLC
- **Don't call it PEM certificate chain** (slide 21)
=C2=A0- P= roposal by Sean on the [mailing list](https://www.ietf.org/mail-archive/w= eb/acme/current/msg01857.html)
=C2=A0=C2=A0 - **Decision(s)**:
= =C2=A0=C2=A0=C2=A0 - Editors to go and fix the terminology (change MIME typ= e + some stuff related to the charset, etc.) as suggested in the first of S= ean's messages according to the referenced RFC;
=C2=A0=C2=A0=C2=A0 -= Add text to the security consideration sections about the private key inse= rtion attack raised by Sean.
=C2=A0 - (Any resolution will be revised on= the list.)

- EKR from the floor: **Generating nonces probabilistica= lly [#289](htt= ps://github.com/ietf-wg-acme/acme/pull/289)** (not on any slide)
= =C2=A0- **Decision**: either nonces are constructed to be unique or, if gen= erated randomly, it should sufficient to require enough entropy (120 bits o= r more)

(Rich takes over from RLB)

## Other issues raised on = the list

- **Require CAA as part of validation?**
=C2=A0- Discuss= ion:
=C2=A0=C2=A0=C2=A0 - RLB: not at the protocol level.=C2=A0 This is = for the CA/B forum to prescribe, which, as Hugo pointed out, has in fact al= ready specified this requirement in a recently published (March 2017) docum= ent.
=C2=A0- **Decision**: add this to the CA consideration in document<= br>
- **Require DNSSEC for name validation?**
=C2=A0- Discussion:
= =C2=A0=C2=A0=C2=A0 - Viktor: CA burden to do validation is minimal (just im= plement DNSSEC client / validator resolver and MUST do validation)
=C2= =A0=C2=A0=C2=A0 - Ted: instead of framing this as a requirement, explain th= e threat and put into the security considerations with associated mitigatio= ns?
=C2=A0=C2=A0=C2=A0 - RB believes we already have that kind of text i= n the security consideration, which proposes doing the verification from mu= ltiple vantage points as a mitigation.
=C2=A0 - Discussion non-conclusiv= e.=C2=A0 Not enough consensus to even try the hum on this topic.=C2=A0 Put = this back to the mailing list.

- **Changes are significant enough to= require an interop round?**
=C2=A0- Discussion
=C2=A0=C2=A0=C2=A0 - = RB: no recent enough draft has been implemented
=C2=A0=C2=A0=C2=A0 - Let= 's Encrypt implemented -03 -- to catch up on -latest they think 2/3 mon= ths needed (optimistically); Digicert in the same ballpark.

=C2=A0 -= Plan is to run WGLC and finish it before Prague -- that will inform the im= plementations.

--001a114042685bd4f7054c07f7e3-- From nobody Fri Mar 31 11:23:40 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 D093812969B for ; Fri, 31 Mar 2017 11:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 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, 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 PZ_yWjJWoJmf for ; Fri, 31 Mar 2017 11:23:37 -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 05055129450 for ; Fri, 31 Mar 2017 11:23:36 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.20/8.16.0.20) with SMTP id v2VILnWL024066 for ; Fri, 31 Mar 2017 19:23:34 +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 : mime-version; s=jan2016.eng; bh=eQ12co50wWy83CqKah0AZgr0motUS0a/KUI9dHVgPRY=; b=aD8FGLVEaGdaUBBjkmsBOorFnQvMXWli7F3czTCIVg+HPbQIKEy6E0Yx2799atZvP42+ nSoJerb7qSwc6PNwmq3dWD9Y230Ft2JjVb9bliXcU6AvqSIJYUurGYxkSzgUakMETgOa M3fHatJ6NbP62c+fsMWNNXezKWmimm5T9tzu4ZaY2OBwizGOj2lcO/lS5Vx1tj3EnzcP I6sSNbtn2trnsh2Gh7sNmct2EIe+e9TavXCURbivQmz++mmid4U6P5wFcbdcyUi5AEAH EmBmYBsViu++nD/weT28H3XyUHB7aPchLdUiW8QPPy95B02TPm5nW/OjoYqcOIWPQBtc /g== 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 29htqpgguv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 31 Mar 2017 19:23:34 +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 v2VILHQA016752 for ; Fri, 31 Mar 2017 14:23:32 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint2.akamai.com with ESMTP id 29fsx69tyy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Fri, 31 Mar 2017 14:23:32 -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.1178.4; Fri, 31 Mar 2017 14:23:31 -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.1178.000; Fri, 31 Mar 2017 14:23:31 -0400 From: "Salz, Rich" To: "acme@ietf.org" Thread-Topic: [ietf-wg-acme/acme] Add CAA text (per IETF98) (#290) Thread-Index: AQHSqkuy1tl59eUXi0OcGfBjeH7PRqGvQxrg Date: Fri, 31 Mar 2017 18:23:31 +0000 Message-ID: <79f8bdcbd54746fe830b5b192ce4e1cf@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.44.16] Content-Type: multipart/alternative; boundary="_000_79f8bdcbd54746fe830b5b192ce4e1cfusma1exdag1mb1msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-31_14:, , 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-1702020001 definitions=main-1703310169 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-31_14:, , 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-1702020001 definitions=main-1703310169 Archived-At: Subject: [Acme] FW: [ietf-wg-acme/acme] Add CAA text (per IETF98) (#290) 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, 31 Mar 2017 18:23:39 -0000 --_000_79f8bdcbd54746fe830b5b192ce4e1cfusma1exdag1mb1msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnVsZmlsbGluZyBteSBwcm9taXNlIG1hZGUgdGhlIG90aGVyIGRheSDimLogIEEgUFIgdG8gYWRk cmVzcyB0aGUgQ0FBIGlzc3VlLg0KDQotLQ0KU2VuaW9yIEFyY2hpdGVjdCwgQWthbWFpIFRlY2hu b2xvZ2llcw0KTWVtYmVyLCBPcGVuU1NMIERldiBUZWFtDQpJTTogcmljaHNhbHpAamFiYmVyLmF0 IFR3aXR0ZXI6IFJpY2hTYWx6DQoNCkZyb206IFJpY2ggU2FseiBbbWFpbHRvOm5vdGlmaWNhdGlv bnNAZ2l0aHViLmNvbV0NClNlbnQ6IEZyaWRheSwgTWFyY2ggMzEsIDIwMTcgMToyMiBQTQ0KVG86 IGlldGYtd2ctYWNtZS9hY21lDQpDYzogU2FseiwgUmljaDsgWW91ciBhY3Rpdml0eQ0KU3ViamVj dDogW2lldGYtd2ctYWNtZS9hY21lXSBBZGQgQ0FBIHRleHQgKHBlciBJRVRGOTgpICgjMjkwKQ0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KWW91IGNhbiB2aWV3LCBjb21tZW50 IG9uLCBvciBtZXJnZSB0aGlzIHB1bGwgcmVxdWVzdCBvbmxpbmUgYXQ6DQoNCiAgaHR0cHM6Ly9n aXRodWIuY29tL2lldGYtd2ctYWNtZS9hY21lL3B1bGwvMjkwPGh0dHBzOi8vdXJsZGVmZW5zZS5w cm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fZ2l0aHViLmNvbV9pZXRmLTJEd2ctMkRh Y21lX2FjbWVfcHVsbF8yOTAmZD1Ed01DYVEmYz05NlpiWlpjYU1GNHcwRjRqcE42TFpnJnI9NExN MEdiUjBoOUZ2eDg2RnRzS0ktdyZtPTRhYi1QTmhxemEyOTlYQW9QU0tfMHh2bFlQb0JaLWMwRmd5 bTJvT3d2cXMmcz1oOVFBVjU3WVBuNWV2YmJUS1hyS0xURGNPQVRsbG4tOTZPRUFMNC1XNTZFJmU9 Pg0KDQpDb21taXQgU3VtbWFyeQ0KDQogICogICBBZGQgQ0FBIHRleHQgKHBlciBJRVRGOTgpDQoN CkZpbGUgQ2hhbmdlcw0KDQogICogICBNIGRyYWZ0LWlldGYtYWNtZS1hY21lLm1kPGh0dHBzOi8v dXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fZ2l0aHViLmNvbV9p ZXRmLTJEd2ctMkRhY21lX2FjbWVfcHVsbF8yOTBfZmlsZXMtMjNkaWZmLTJEMCZkPUR3TUNhUSZj PTk2WmJaWmNhTUY0dzBGNGpwTjZMWmcmcj00TE0wR2JSMGg5RnZ4ODZGdHNLSS13Jm09NGFiLVBO aHF6YTI5OVhBb1BTS18weHZsWVBvQlotYzBGZ3ltMm9Pd3ZxcyZzPV82T0pvckpWTHNDaTFRdDly MUNDakZqNHludUNhUlh4elFaUjU4THNKdjAmZT0+ICg0KQ0KDQpQYXRjaCBMaW5rczoNCg0KICAq ICAgaHR0cHM6Ly9naXRodWIuY29tL2lldGYtd2ctYWNtZS9hY21lL3B1bGwvMjkwLnBhdGNoPGh0 dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fZ2l0aHVi LmNvbV9pZXRmLTJEd2ctMkRhY21lX2FjbWVfcHVsbF8yOTAucGF0Y2gmZD1Ed01DYVEmYz05Nlpi WlpjYU1GNHcwRjRqcE42TFpnJnI9NExNMEdiUjBoOUZ2eDg2RnRzS0ktdyZtPTRhYi1QTmhxemEy OTlYQW9QU0tfMHh2bFlQb0JaLWMwRmd5bTJvT3d2cXMmcz01ZS1BTldGUFg5ZllzRGdpNlRZYnVo ZWRZUFh6RmFKMkFzQWFyM2VFdTFVJmU9Pg0KICAqICAgaHR0cHM6Ly9naXRodWIuY29tL2lldGYt d2ctYWNtZS9hY21lL3B1bGwvMjkwLmRpZmY8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQu Y29tL3YyL3VybD91PWh0dHBzLTNBX19naXRodWIuY29tX2lldGYtMkR3Zy0yRGFjbWVfYWNtZV9w dWxsXzI5MC5kaWZmJmQ9RHdNQ2FRJmM9OTZaYlpaY2FNRjR3MEY0anBONkxaZyZyPTRMTTBHYlIw aDlGdng4NkZ0c0tJLXcmbT00YWItUE5ocXphMjk5WEFvUFNLXzB4dmxZUG9CWi1jMEZneW0yb093 dnFzJnM9NXNWa1ItZk5qSjRzMmxuTHpWdEtLTk9pQVJtQmI3Z2JHc1pnOE9OUzh4byZlPT4NCg0K 4oCUDQpZb3UgYXJlIHJlY2VpdmluZyB0aGlzIGJlY2F1c2UgeW91IGFyZSBzdWJzY3JpYmVkIHRv IHRoaXMgdGhyZWFkLg0KUmVwbHkgdG8gdGhpcyBlbWFpbCBkaXJlY3RseSwgdmlldyBpdCBvbiBH aXRIdWI8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNB X19naXRodWIuY29tX2lldGYtMkR3Zy0yRGFjbWVfYWNtZV9wdWxsXzI5MCZkPUR3TUNhUSZjPTk2 WmJaWmNhTUY0dzBGNGpwTjZMWmcmcj00TE0wR2JSMGg5RnZ4ODZGdHNLSS13Jm09NGFiLVBOaHF6 YTI5OVhBb1BTS18weHZsWVBvQlotYzBGZ3ltMm9Pd3ZxcyZzPWg5UUFWNTdZUG41ZXZiYlRLWHJL TFREY09BVGxsbi05Nk9FQUw0LVc1NkUmZT0+LCBvciBtdXRlIHRoZSB0aHJlYWQ8aHR0cHM6Ly91 cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19naXRodWIuY29tX25v dGlmaWNhdGlvbnNfdW5zdWJzY3JpYmUtMkRhdXRoX0FHLTVGaWxQSmZET1RJNFhKYVl0OXRqNUYy NFBwVkhvV0lrczVyclVSRmdhSnBaTTRNdi01RnV2JmQ9RHdNQ2FRJmM9OTZaYlpaY2FNRjR3MEY0 anBONkxaZyZyPTRMTTBHYlIwaDlGdng4NkZ0c0tJLXcmbT00YWItUE5ocXphMjk5WEFvUFNLXzB4 dmxZUG9CWi1jMEZneW0yb093dnFzJnM9Rl8wZ3hQWF9kTm5VREREMldDbTd6dlN1eTVXdFZLMDVN UzdObVFhUEN3NCZlPT4uDQo= --_000_79f8bdcbd54746fe830b5b192ce4e1cfusma1exdag1mb1msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAw O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAw IDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBh bm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmlu aXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21h cmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpoNA0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTsNCgltc28tc3R5bGUtbGluazoiSGVhZGluZyA0IENoYXIiOw0KCW1zby1tYXJn aW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCglmb250LXdlaWdodDpib2xkO30NCmE6 bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNv SHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBs ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZTox Mi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLkhl YWRpbmc0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiSGVhZGluZyA0IENoYXIiOw0KCW1zby1zdHls ZS1wcmlvcml0eTo5Ow0KCW1zby1zdHlsZS1saW5rOiJIZWFkaW5nIDQiOw0KCWZvbnQtZmFtaWx5 OiJDYW1icmlhIiwic2VyaWYiOw0KCWNvbG9yOiM0RjgxQkQ7DQoJZm9udC13ZWlnaHQ6Ym9sZDsN Cglmb250LXN0eWxlOml0YWxpYzt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K CWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlz dCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MzQ3MzcwNDY2Ow0KCW1z by1saXN0LXRlbXBsYXRlLWlkczotNDM4OTExNjI7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0K CW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVs Mw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K CW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0 IGwxDQoJe21zby1saXN0LWlkOjExOTc1NDU3NzE7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE5 ODAyNjc3MzY7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs MTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwx OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoz LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxl dmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyDQoJe21zby1saXN0LWlkOjE5 MjIzMzA3ODE7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjgwMTQyNDIxMjt9DQpAbGlzdCBsMjps ZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsMg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0K QGxpc3QgbDI6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDI6bGV2ZWw0 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDI6bGV2ZWw1DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDI6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDI6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDI6bGV2ZWw4DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDI6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTow aW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5GdWxmaWxsaW5nIG15 IHByb21pc2UgbWFkZSB0aGUgb3RoZXIgZGF5DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMxRjQ5N0QiPko8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyBBIFBSIHRvIGFk ZHJlc3MgdGhlIENBQSBpc3N1ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi0tJm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+U2VuaW9yIEFyY2hpdGVjdCwgQWthbWFpIFRlY2hub2xvZ2llczxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5NZW1iZXIsIE9wZW5TU0wgRGV2IFRlYW08bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SU06IHJpY2hzYWx6QGphYmJlci5hdCBUd2l0dGVyOiBS aWNoU2FsejxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gUmljaCBT YWx6IFttYWlsdG86bm90aWZpY2F0aW9uc0BnaXRodWIuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+ IEZyaWRheSwgTWFyY2ggMzEsIDIwMTcgMToyMiBQTTxicj4NCjxiPlRvOjwvYj4gaWV0Zi13Zy1h Y21lL2FjbWU8YnI+DQo8Yj5DYzo8L2I+IFNhbHosIFJpY2g7IFlvdXIgYWN0aXZpdHk8YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gW2lldGYtd2ctYWNtZS9hY21lXSBBZGQgQ0FBIHRleHQgKHBlciBJRVRG OTgpICgjMjkwKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVy IiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 Ij4NCjxociBzaXplPSIyIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+DQo8L3NwYW4+PC9k aXY+DQo8aDQ+WW91IGNhbiB2aWV3LCBjb21tZW50IG9uLCBvciBtZXJnZSB0aGlzIHB1bGwgcmVx dWVzdCBvbmxpbmUgYXQ6PG86cD48L286cD48L2g0Pg0KPHA+Jm5ic3A7Jm5ic3A7PGEgaHJlZj0i aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19naXRo dWIuY29tX2lldGYtMkR3Zy0yRGFjbWVfYWNtZV9wdWxsXzI5MCZhbXA7ZD1Ed01DYVEmYW1wO2M9 OTZaYlpaY2FNRjR3MEY0anBONkxaZyZhbXA7cj00TE0wR2JSMGg5RnZ4ODZGdHNLSS13JmFtcDtt PTRhYi1QTmhxemEyOTlYQW9QU0tfMHh2bFlQb0JaLWMwRmd5bTJvT3d2cXMmYW1wO3M9aDlRQVY1 N1lQbjVldmJiVEtYcktMVERjT0FUbGxuLTk2T0VBTDQtVzU2RSZhbXA7ZT0iPmh0dHBzOi8vZ2l0 aHViLmNvbS9pZXRmLXdnLWFjbWUvYWNtZS9wdWxsLzI5MDwvYT48bzpwPjwvbzpwPjwvcD4NCjxo ND5Db21taXQgU3VtbWFyeTxvOnA+PC9vOnA+PC9oND4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KQWRkIENBQSB0ZXh0 IChwZXIgSUVURjk4KTxvOnA+PC9vOnA+PC9saT48L3VsPg0KPGg0PkZpbGUgQ2hhbmdlczxvOnA+ PC9vOnA+PC9oND4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNv LWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPg0KPHN0cm9uZz5NPC9zdHJvbmc+IDxhIGhyZWY9Imh0dHBz Oi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fZ2l0aHViLmNv bV9pZXRmLTJEd2ctMkRhY21lX2FjbWVfcHVsbF8yOTBfZmlsZXMtMjNkaWZmLTJEMCZhbXA7ZD1E d01DYVEmYW1wO2M9OTZaYlpaY2FNRjR3MEY0anBONkxaZyZhbXA7cj00TE0wR2JSMGg5RnZ4ODZG dHNLSS13JmFtcDttPTRhYi1QTmhxemEyOTlYQW9QU0tfMHh2bFlQb0JaLWMwRmd5bTJvT3d2cXMm YW1wO3M9XzZPSm9ySlZMc0NpMVF0OXIxQ0NqRmo0eW51Q2FSWHh6UVpSNThMc0p2MCZhbXA7ZT0i Pg0KZHJhZnQtaWV0Zi1hY21lLWFjbWUubWQ8L2E+ICg0KSA8bzpwPjwvbzpwPjwvbGk+PC91bD4N CjxoND5QYXRjaCBMaW5rczo8bzpwPjwvbzpwPjwvaDQ+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwyIGxldmVsMSBsZm8zIj4NCjxhIGhyZWY9Imh0 dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fZ2l0aHVi LmNvbV9pZXRmLTJEd2ctMkRhY21lX2FjbWVfcHVsbF8yOTAucGF0Y2gmYW1wO2Q9RHdNQ2FRJmFt cDtjPTk2WmJaWmNhTUY0dzBGNGpwTjZMWmcmYW1wO3I9NExNMEdiUjBoOUZ2eDg2RnRzS0ktdyZh bXA7bT00YWItUE5ocXphMjk5WEFvUFNLXzB4dmxZUG9CWi1jMEZneW0yb093dnFzJmFtcDtzPTVl LUFOV0ZQWDlmWXNEZ2k2VFlidWhlZFlQWHpGYUoyQXNBYXIzZUV1MVUmYW1wO2U9Ij5odHRwczov L2dpdGh1Yi5jb20vaWV0Zi13Zy1hY21lL2FjbWUvcHVsbC8yOTAucGF0Y2g8L2E+PG86cD48L286 cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzMiPg0K PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBz LTNBX19naXRodWIuY29tX2lldGYtMkR3Zy0yRGFjbWVfYWNtZV9wdWxsXzI5MC5kaWZmJmFtcDtk PUR3TUNhUSZhbXA7Yz05NlpiWlpjYU1GNHcwRjRqcE42TFpnJmFtcDtyPTRMTTBHYlIwaDlGdng4 NkZ0c0tJLXcmYW1wO209NGFiLVBOaHF6YTI5OVhBb1BTS18weHZsWVBvQlotYzBGZ3ltMm9Pd3Zx cyZhbXA7cz01c1ZrUi1mTmpKNHMybG5MelZ0S0tOT2lBUm1CYjdnYkdzWmc4T05TOHhvJmFtcDtl PSI+aHR0cHM6Ly9naXRodWIuY29tL2lldGYtd2ctYWNtZS9hY21lL3B1bGwvMjkwLmRpZmY8L2E+ PG86cD48L286cD48L2xpPjwvdWw+DQo8cCBzdHlsZT0iLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0 Om5vbmUiPjxzcGFuIHN0eWxlPSJjb2xvcjojNjY2NjY2Ij7igJQ8YnI+DQpZb3UgYXJlIHJlY2Vp dmluZyB0aGlzIGJlY2F1c2UgeW91IGFyZSBzdWJzY3JpYmVkIHRvIHRoaXMgdGhyZWFkLjxicj4N ClJlcGx5IHRvIHRoaXMgZW1haWwgZGlyZWN0bHksIDxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5z ZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fZ2l0aHViLmNvbV9pZXRmLTJEd2ct MkRhY21lX2FjbWVfcHVsbF8yOTAmYW1wO2Q9RHdNQ2FRJmFtcDtjPTk2WmJaWmNhTUY0dzBGNGpw TjZMWmcmYW1wO3I9NExNMEdiUjBoOUZ2eDg2RnRzS0ktdyZhbXA7bT00YWItUE5ocXphMjk5WEFv UFNLXzB4dmxZUG9CWi1jMEZneW0yb093dnFzJmFtcDtzPWg5UUFWNTdZUG41ZXZiYlRLWHJLTFRE Y09BVGxsbi05Nk9FQUw0LVc1NkUmYW1wO2U9Ij4NCnZpZXcgaXQgb24gR2l0SHViPC9hPiwgb3Ig PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBz LTNBX19naXRodWIuY29tX25vdGlmaWNhdGlvbnNfdW5zdWJzY3JpYmUtMkRhdXRoX0FHLTVGaWxQ SmZET1RJNFhKYVl0OXRqNUYyNFBwVkhvV0lrczVyclVSRmdhSnBaTTRNdi01RnV2JmFtcDtkPUR3 TUNhUSZhbXA7Yz05NlpiWlpjYU1GNHcwRjRqcE42TFpnJmFtcDtyPTRMTTBHYlIwaDlGdng4NkZ0 c0tJLXcmYW1wO209NGFiLVBOaHF6YTI5OVhBb1BTS18weHZsWVBvQlotYzBGZ3ltMm9Pd3ZxcyZh bXA7cz1GXzBneFBYX2ROblVEREQyV0NtN3p2U3V5NVd0VkswNU1TN05tUWFQQ3c0JmFtcDtlPSI+ DQptdXRlIHRoZSB0aHJlYWQ8L2E+LjxpbWcgYm9yZGVyPSIwIiB3aWR0aD0iMSIgaGVpZ2h0PSIx IiBpZD0iX3gwMDAwX2kxMDI2IiBzcmM9Imh0dHBzOi8vZ2l0aHViLmNvbS9ub3RpZmljYXRpb25z L2JlYWNvbi9BR19pbEZRZTktdV9PR0xmRDkzQUNtYUpNRk0yNThHbGtzNXJyVVJGZ2FKcFpNNE12 X3V2LmdpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_79f8bdcbd54746fe830b5b192ce4e1cfusma1exdag1mb1msgcorpak_-- From nobody Fri Mar 31 15:22: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 8E99F124217 for ; Fri, 31 Mar 2017 15:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.397 X-Spam-Level: X-Spam-Status: No, score=-5.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.796, 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 nriDaZEJ9XNz for ; Fri, 31 Mar 2017 15:22:36 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 E56271201F2 for ; Fri, 31 Mar 2017 15:22:35 -0700 (PDT) Received: from [10.171.73.68] (unknown [12.125.215.110]) (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 0F3A6509B8 for ; Fri, 31 Mar 2017 18:22:34 -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\)) Message-Id: Date: Fri, 31 Mar 2017 17:22:33 -0500 To: ACME WG X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [Acme] "Slide 21" follow-up (textual encoding question) PART 1 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, 31 Mar 2017 22:22:38 -0000 Hi ACME: I listened to the audio recording of the session in addition to the = notes about =E2=80=9C**Don't call it PEM certificate chain** (slide = 21)=E2=80=9D. I=E2=80=99ll separate my response into three parts. This = first part is more of a protocol/general question, that may obviate the = second part. The ACME protocol has an Order Object that: =E2=80=9Crepresents a = client's request for a certificate and is used to track the progress of = that order through to issuance.=E2=80=9D Section 7.1.3. Once the requirements are satisfied, a certificate gets issued, and the = =E2=80=9Ccertificate=E2=80=9D field appears with the URL* to GET the = certificate. The certificate field is supposed to be present whenever = the order status is =E2=80=9Cvalid=E2=80=9D: o "valid": The server has issued the certificate and provisioned its URL to the "certificate" field of the order. Furthermore, Section 7.4: The server MUST issue the requested certificate and update the order resource with a URL for the certificate shortly after the client has fulfilled the server's requirements. If the client has already satisfied the server's requirements at the time of this request (e.g., by obtaining authorization for all of the identifiers in the certificate in previous transactions), then the server MUST proactively issue the requested certificate and provide a URL for it in the "certificate" field of the order. The server MUST, however, still list the completed authorizations in the "authorizations" array. This text tells me that the ACME client should keep on polling for order = status until it switches to valid, at which point, it can get the = certificate. (I guess that the =E2=80=9Cpolling interval=E2=80=9D is = supposed to be in response to authorizations succeeding, the statuses = for which are explicitly =E2=80=9Cpolled=E2=80=9D in the text.) So, how about supplying the certificate directly by putting it in the = certificate field in base64(url) format? Forget all this certificate = URL* stuff. It just adds unnecessary redirection and more server state = that needs to be tracked (i.e., certificate retrieval URL). The order = JSON object is already big because of the required =E2=80=9Ccsr=E2=80=9D = field, so you=E2=80=99re not going to make it appreciably bigger. I would propose putting the certificate in a JSON array in the = =E2=80=9Ccertificate=E2=80=9D field of the ACME Order object. The first = array element is the subject certificate, and subsequent elements are = other chain parts (which =E2=80=9CSHOULD=E2=80=9D be TLS-ordered). You = can write a simple Python script that parses any stored =E2=80=9CACME = Order=E2=80=9D JSON file and spews out the certificate chain as your web = server du jour likes it, or spews out better error messages, like = =E2=80=9Ccertificates not issued yet because of XYZ reason=E2=80=9D. Thanks, Sean *Editorial: =E2=80=9Ccertificate URL=E2=80=9D should be =E2=80=9Ccertifica= te URI=E2=80=9D, per RFC 3986.= From nobody Fri Mar 31 15:23: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 C8994128616 for ; Fri, 31 Mar 2017 15:23:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.397 X-Spam-Level: X-Spam-Status: No, score=-5.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.796, 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 Ji5xlM11zuUG for ; Fri, 31 Mar 2017 15:23:43 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 53F82124217 for ; Fri, 31 Mar 2017 15:23:43 -0700 (PDT) Received: from [10.171.73.68] (unknown [12.125.215.110]) (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 8B72A509BE for ; Fri, 31 Mar 2017 18:23:42 -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\)) Message-Id: Date: Fri, 31 Mar 2017 17:23:42 -0500 To: ACME WG X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [Acme] "Slide 21" follow-up (textual encoding question) PART 2 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, 31 Mar 2017 22:23:45 -0000 Hi ACME: SECOND PART. I think some of my comments may have been misconstrued about the = =E2=80=9C**Don't call it PEM certificate chain** (slide 21)=E2=80=9D = issue. Textual encoding amounts to a way to ASCII-armor binary data in plain = text. This is obvious because the human usability that it enables is: = =E2=80=9Ccopy-and-paste from your web browser or e-mail client into a = text file=E2=80=9D. And the problem with human usability is that when = you tell people to copy and paste things, they don=E2=80=99t know or = they ignore *what* they are copying and pasting, so they can facilitate = transmitting malicious content across security boundaries. Human interaction is not a design goal in ACME. You want humans to touch = this stuff as little as possible. By letting software =E2=80=9Ccopy and = paste=E2=80=9D the ACME server=E2=80=99s response to anything, *without = validating it*, you facilitate attacks such as the private key = substitution attack. (There are others, for example, OpenSSL behaves = differently when you supply it with -----TRUSTED CERTIFICATE-----.) If the WG=E2=80=99s consensus is that you really want a separate = certificate URI (seriously: why? you want it retrievable over ldap:// or = ni:// or something?), then the URI dereference should return *just* = certificates in a well-defined way. Blobs of text (regardless of what = MIME type you serve it as) are not well-defined compared to the gold = standard of application/pkix-cert. If your goal really is so that a = human being can take the certificate URI and put it in their web browser = and copy and paste the certificate, then it should be served as = text/plain; charset=3Dus-ascii. Or if you want, text/html and include = some dancing hamsters and last-minute unilateral changes to the CA = contract (because hunting-and-picking for -----BEGIN CERTIFICATE----- in = HTML source works exactly the same way, it=E2=80=99s called =E2=80=9Cpage = scraping=E2=80=9D). But I thought that the point of ACME is to get away = from page scraping techniques. Anyway, if you want a format at a separate URI that includes the = certificate and the ACME server=E2=80=99s proposed chain and is = automatable, my first suggestion is multipart/mixed where each part is = application/pkix-cert. Most web browsers don't handle multipart/mixed = responses well, but the point is that you=E2=80=99re not supposed to use = a web browser to get this URI. My second suggestion is (what I wrote initially): a new binary type, = application/pkix-certs (or cert-chain), with concatenated DER-encoded = certificates: the first one is the subject certificate you=E2=80=99re = interested in and the others =E2=80=9CSHOULD=E2=80=9D be in TLS order. Thanks, Sean From nobody Fri Mar 31 15:27: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 57F89124217 for ; Fri, 31 Mar 2017 15:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.397 X-Spam-Level: X-Spam-Status: No, score=-5.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.796, 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 FKcMVe_-L8_7 for ; Fri, 31 Mar 2017 15:27:29 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 EB0A71201F2 for ; Fri, 31 Mar 2017 15:27:28 -0700 (PDT) Received: from [10.171.73.68] (unknown [12.125.215.110]) (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 29A3E509BB for ; Fri, 31 Mar 2017 18:27:28 -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\)) Message-Id: <620106B4-D49C-4548-B9E8-CBF770EA7B52@seantek.com> Date: Fri, 31 Mar 2017 17:27:27 -0500 To: ACME WG X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [Acme] "Slide 21" follow-up (textual encoding question) PART 3: post-issuance client error feedback 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, 31 Mar 2017 22:27:30 -0000 Hi ACME: I see ways in this protocol for the ACME server to issue error messages = to the ACME client. How come there is no way for the ACME client to = issue error messages back to the ACME server, particularly = post-issuance? The ACME server can send over a certificate that the server *thinks* is = valid, but doesn=E2=80=99t meet production requirements. Maybe the key = usage is wrong, or there is something wrong with the chain certs or the = roots because the web server is talking to clients that don=E2=80=99t = support that particular CA root. It would save a lot of headache for the ACME client to validate that the = certificates (including chain) that it got are acceptable, *before* = putting the certificates into production and having millions of = certificate validation errors from around the world on its hands. If the = client finds a validation problem, then it can communicate that = immediately to the ACME server (or elsewhere) so that operators can = collaboratively deal with it. I thought of this workflow as part of Part 1, since the error feedback = from ACME client to ACME server would be after the order status turns = =E2=80=9Cvalid=E2=80=9D and the certificate (and chain) is available. = This bolsters the proposal that the certificates should be incorporated = directly into the ACME order object. That=E2=80=99s it, thanks all for a nice IETF 98. Sean= From nobody Fri Mar 31 17:27: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 C0FF8128792 for ; Fri, 31 Mar 2017 17:27:00 -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 aJACTBBBydLo for ; Fri, 31 Mar 2017 17:26:59 -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 2D354126CC7 for ; Fri, 31 Mar 2017 17:26:57 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.20/8.16.0.20) with SMTP id v310MB61028138; Sat, 1 Apr 2017 01:26:54 +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=ULpWcfTZLaLR2lAnXRjH0kGDXIo7pwAEi132sfCFRaA=; b=mjUFeKgubwm/ayomDuMu95y9XKmrZ67lnjnNqCug042uwB2/OzmJVCfU0DaTULK70gKy ZtxT6FRks9K1icQ9oiLafHkIwC4vs0RSCCoy1NtJgfTXbHsmPA2+mpBGd0xyHAv0Hqy/ Nmmknt6xRv/rPYy5T5pSqwgx5/WZpp2DpTk+U8+H5AE1+cUtAWeyJZn30l0Jy74wa+CK Z32xB7EJ55ipK7Aw38O5AyU+i+3yQf4MH/uZCFFU+imQzu/J/kXPnhdhzk4D2ipNvkMS qzd63M+QTEQSRx66404OSsXIuzUGcpJd550dt3OHW+0sCKUopkBoooiH0JnOE0gBrpQn /A== 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 29hv201gj1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 01 Apr 2017 01:26:53 +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 v310PcPR027522; Fri, 31 Mar 2017 20:26:53 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint2.akamai.com with ESMTP id 29fsx69y91-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 31 Mar 2017 20:26:53 -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.1178.4; Fri, 31 Mar 2017 20:26:52 -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.1178.000; Fri, 31 Mar 2017 20:26:52 -0400 From: "Salz, Rich" To: Sean Leonard , ACME WG Thread-Topic: [Acme] "Slide 21" follow-up (textual encoding question) PART 2 Thread-Index: AQHSqm16spyWDD7X70Sh0X9mnd79yqGvqCrQ Date: Sat, 1 Apr 2017 00:26:50 +0000 Message-ID: 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.32.74] 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-03-31_18:, , 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-1702020001 definitions=main-1704010002 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-31_18:, , 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-1702020001 definitions=main-1704010002 Archived-At: Subject: Re: [Acme] "Slide 21" follow-up (textual encoding question) PART 2 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, 01 Apr 2017 00:27:01 -0000 U2VhbiwNCg0KVGhlIHdvcmtpbmcgZ3JvdXAgZmVsdCBwcmV0dHkgY2xlYXJseSB0aGF0IHRoZSBC RUdJTi9FTkQgYmFzZTY0IGVuY29kaW5nIHdhcyB0aGUgZm9ybWF0IHVzZWQgYnkgImFsbCIgd2Vi IHNlcnZlcnMgYW5kIHRoYXQgYW55dGhpbmcgZWxzZSB3b3VsZCByZXF1aXJlIHRoZSBjbGllbnQg dG8gdHJhbnNsYXRlIGludG8gdGhhdCBmb3JtYXQuDQoNCkhvcGUgdGhpcyBoZWxwcy4NCg==