From nobody Fri Feb 3 10:46:48 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C5951294E5 for ; Fri, 3 Feb 2017 10:46:46 -0800 (PST) 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 vox1kiCcf-H9 for ; Fri, 3 Feb 2017 10:46:44 -0800 (PST) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::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 95456129409 for ; Fri, 3 Feb 2017 10:46:44 -0800 (PST) Received: by mail-ua0-x22c.google.com with SMTP id 96so20201115uaq.3 for ; Fri, 03 Feb 2017 10:46:44 -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=sAIBaYEXpgBEvHoPNLUO6TEW81jBJ40fuBVRcFiISMM=; b=m1Ae9lgRBZ6CfUBHhdIz+985OGVHGLf1+e8SK0Iz1FrqSTZ1KGqZxhA8xtEFdGH2Hz 5tNGtaEughBb/Igv7qAqTcRZ5wgPpC4lMrQbMaYLLcY25zi7FxBAkctZMT46mVN9AUwV GGxKvVek4efMOFCmuxD5uhsWOqTng3PUm1JiukPW2gnSiKoP+/pQZ3Fj8v6nBmrqr9Kg Pi7kjJCXVBKrBc4y7TSgx/Vw0Cj6ZzxdyEnFUe0pH6i+NEweOm17UzP7oczGhmRMtJFs dLnkiaLvzN2zac/foSCkoQhqEHHCAkoYpK9jV84i7Nv6/DqpqSr+XoyZ8UQdP7x0fybV NuQA== 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=sAIBaYEXpgBEvHoPNLUO6TEW81jBJ40fuBVRcFiISMM=; b=F8gB78kdRYGFeFD9LMwWF2FIB0kEGlBM6P2RDO8ih6Cv2kbrQW0V/vQpKslNWTRmTC Q9uc0mizU5mSUDlgiX13Dn/AFGgHZdekGlMOzuEvhuZnnu8rKEH4cEKPkvxspMZaQj6X nzzXF3oymVppIGPk2orOrdsl/gaR4x4W2e4qdYGLbKLxDUWdptJlG5o6te/CyF4deOXI 5iM6BOssgWRffHj7MJxeneZ+vaoeYxhy62Ttygb8tD9ehZG1mdPnDQqDcNVjJKZSdcok bS5laCn3nEbMzug6vRGrIxR8xqfHZgUGxbQE5lcFcwc8GgZqQsVaJ/sT13oVyqGiJDMI WagQ== X-Gm-Message-State: AIkVDXLV70pz9RqWUc7j5FINNJBcQXcOSiZkPZ7J7CyYpdGFQU9Zi1ookPn333V18smtmqKqd7sjjHlsL+D7Ww== X-Received: by 10.159.36.73 with SMTP id 67mr7948403uaq.124.1486147603524; Fri, 03 Feb 2017 10:46:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.179.140 with HTTP; Fri, 3 Feb 2017 10:46:42 -0800 (PST) In-Reply-To: <1bfcd722703f4236a32fc7458084ff06@Buyp-gvk-ex01.intra.buypass.no> References: <1bfcd722703f4236a32fc7458084ff06@Buyp-gvk-ex01.intra.buypass.no> From: Richard Barnes Date: Fri, 3 Feb 2017 10:46:42 -0800 Message-ID: To: Andriy Mahats Content-Type: multipart/alternative; boundary=001a113e1c9cfe7a820547a4b308 Archived-At: Cc: "acme@ietf.org" Subject: Re: [Acme] ACME resources relations 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 Feb 2017 18:46:46 -0000 --001a113e1c9cfe7a820547a4b308 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This is a good question, and I'm not sure what the right answer is. It seems like there are basically three options: 1. Remove the "up" relation 2. Have the "up" relation point to the order that created the authz (if any= ) 3. Have multiple "up" relations pointing to all relevant orders Of those options, I would probably prefer (1), just because I don't really see much of a use case for it. On Fri, Jan 20, 2017 at 8:08 AM, Andriy Mahats wrote: > Hi all! > > > > At the resource diagram in *6.1 Resources* section, > > there is an authz resource related to order by =E2=80=9Cup=E2=80=9D relat= ion. > > > > My question is for following case: > > > > The client orders a certificate > > and at the time of ordering it satisfied some of authorizations (let=E2= =80=99s say > 2 of 3) > > in previous transactions (possibly using pre-authorization: new-authz). > > > > When client queries such previously satisfied authorization, > > what order resource shall pointed using =E2=80=9Cup=E2=80=9D relation, > > since that authorization can be used for many orders? > > > > I=E2=80=99ve created issue in GitHub for this. You can find it here: > https://github.com/ietf-wg-acme/acme/issues/236 > > > > > > Sincerely, > > Andriy > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > > --001a113e1c9cfe7a820547a4b308 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This is a good question, and I'm n= ot sure what the right answer is.=C2=A0 It seems like there are basically t= hree options:

1. Remove the "up" relation
2= . Have the "up" relation point to the order that created the auth= z (if any)
3. Have multiple "up" relations pointing to a= ll relevant orders

Of those options, I would probably prefer (= 1), just because I don't really see much of a use case for it.

On Fri, Jan 20, = 2017 at 8:08 AM, Andriy Mahats <Andriy.Mahats@buypass.no> wrote:

Hi all!

=C2=A0

At the resource diagram in 6= .1 Resources section,

there is an authz resource rela= ted to order by =E2=80=9Cup=E2=80=9D relation.

=C2=A0

My question is for following ca= se:

=C2=A0

The client orders a certificate=

and at the time of ordering it = satisfied some of authorizations (let=E2=80=99s say 2 of 3)

in previous transactions (possi= bly using pre-authorization: new-authz).

=C2=A0

When client queries such previo= usly satisfied authorization,

what order resource shall point= ed using =E2=80=9Cup=E2=80=9D relation,

since that authorization can be= used for many orders?

=C2=A0

I=E2=80=99ve created issue in G= itHub for this. You can find it here: https://github.com/ietf-wg-acme/acme/issues/236

=C2=A0

=C2=A0

Sincerely,=

Andriy


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


--001a113e1c9cfe7a820547a4b308-- From nobody Fri Feb 3 11:36: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 D414C12948C for ; Fri, 3 Feb 2017 11:36:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.201 X-Spam-Level: X-Spam-Status: No, score=-10.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199, 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 hCOxneytaV_X for ; Fri, 3 Feb 2017 11:36:39 -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 3081D12940B for ; Fri, 3 Feb 2017 11:36:39 -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=bXZH/noqbHGqkvAe2ipUtvNyoVFTmquhkM+sYhcPJGw=; b=MuCP/1zFojJCz/8KIxRBxXLO4BDT9bcz8OJB7aEgrW5wCp76VOz19bPuFcvYgYyblMv2jrOUnMs8xdFcPappnwgWwAdeTMjLOpqILYNqKRFFSl/paqRulfTbnrW7MQZ16LUGQRD7dXU8cWu772rk3so8Jsm3BvgVYYK+SgMC0Lo=; Received: ; Fri, 03 Feb 2017 11:36:38 -0800 To: Richard Barnes , Andriy Mahats References: <1bfcd722703f4236a32fc7458084ff06@Buyp-gvk-ex01.intra.buypass.no> From: Jacob Hoffman-Andrews Message-ID: <7bd34325-ed2b-b43a-a8b5-29ac7a960d2e@eff.org> Date: Fri, 3 Feb 2017 11:36:36 -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] ACME resources relations 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 Feb 2017 19:36:41 -0000 On 02/03/2017 10:46 AM, Richard Barnes wrote: > This is a good question, and I'm not sure what the right answer is. > It seems like there are basically three options: > > 1. Remove the "up" relation > 2. Have the "up" relation point to the order that created the authz > (if any) > 3. Have multiple "up" relations pointing to all relevant orders > > Of those options, I would probably prefer (1), just because I don't > really see much of a use case for it. I concur. I'd actually like to do a thorough review of the various link relations and remove the unnecessary ones, but saving that for WGLC. From nobody Fri Feb 3 11:50:36 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 F039D129535; Fri, 3 Feb 2017 11:50:31 -0800 (PST) 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.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148615143197.4029.11496311987315574351.idtracker@ietfa.amsl.com> Date: Fri, 03 Feb 2017 11:50:31 -0800 Archived-At: Cc: acme@ietf.org Subject: [Acme] I-D Action: draft-ietf-acme-acme-05.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: Fri, 03 Feb 2017 19:50:32 -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-05.txt Pages : 72 Date : 2017-02-03 Abstract: Certificates in the Web's X.509 PKI (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 certificate 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-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-acme-05 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 Sat Feb 4 04:46:51 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 292411296B9; Sat, 4 Feb 2017 04:46:50 -0800 (PST) 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.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148621241016.2834.15976439695505838728.idtracker@ietfa.amsl.com> Date: Sat, 04 Feb 2017 04:46:50 -0800 Archived-At: Cc: acme@ietf.org Subject: [Acme] I-D Action: draft-ietf-acme-caa-01.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: Sat, 04 Feb 2017 12:46:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Automated Certificate Management Environment of the IETF. Title : CAA Record Extensions for Account URI and ACME Method Binding Author : Hugo Landau Filename : draft-ietf-acme-caa-01.txt Pages : 9 Date : 2017-02-04 Abstract: The CAA DNS record allows a domain to communicate issuance policy to CAs, but only allows a domain to define policy with CA-level granularity. However, the CAA specification also provides facilities for extension to admit more granular, CA-specific policy. This specification defines two such parameters, one allowing specific accounts of a CA to be identified by URI and one allowing specific methods of domain control validation as defined by the ACME protocol to be required. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-acme-caa/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-acme-caa-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-caa-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Feb 4 04:50: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 06CE11296AA for ; Sat, 4 Feb 2017 04:50:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=devever.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLCbGqQ8frw0 for ; Sat, 4 Feb 2017 04:50:00 -0800 (PST) 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 8B05D129421 for ; Sat, 4 Feb 2017 04:50:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by umbriel.devever.net (Postfix) with ESMTP id 87EF21D256 for ; Sat, 4 Feb 2017 13:49:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=devever.net; h= user-agent:in-reply-to:content-transfer-encoding :content-disposition:content-type:content-type:mime-version :references:message-id:subject:subject:from:from:date:date :received:received; s=mimas; t=1486212598; x=1504401959; bh=GqFJ WkkWGPwPTE5shkHHipO4xfwLlctTjU/KQdbW+b0=; b=SoCbaHOZWDqnw3CP+D7/ Jb+a960ZvIaLs+I3BCl1LQ5xi1i9dzin0m3oN/OSqbb6ZxEGGIhdiq2OGXmZNfU1 G+YxtyODXgeaRE6ee53gj7PzeDKVEGh2OG2KkPNapm8jbumuQ6qk8yrN2fVsNlKE HsQvbU4w+DzOamW6UhVMSyVejwCHigs+c/YY4tM8EaaNRnYFGAaOayGEYB4cWzFA s2oS/I+8tiBXpISU2Ww32aSAjaaXX3IcxoqjU1Z53fpHqpOKwKh2YzKGt+juwvF9 GZLOoYC0s20zYpjeMvm0AlOR6MTO9tTd5xgUyxJ4gvIfP+YxvYPl4UDjl3B8k3MW 5Q== 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 c9ol6jc1DW_e for ; Sat, 4 Feb 2017 13:49:58 +0100 (CET) Received: from andover.lhh.devever.net (localhost [127.0.0.1]) by umbriel.devever.net (Postfix) with ESMTP id 518DB1D254 for ; Sat, 4 Feb 2017 13:49:58 +0100 (CET) Date: Sat, 4 Feb 2017 12:49:57 +0000 From: Hugo Landau To: acme@ietf.org Message-ID: <20170204124957.GA16805@andover.lhh.devever.net> References: <148621241016.2834.15976439695505838728.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <148621241016.2834.15976439695505838728.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [Acme] I-D Action: draft-ietf-acme-caa-01.txt 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 Feb 2017 12:50:02 -0000 This updates the ACME-CAA draft to clarify that the specification inherits all security considerations from the CAA specification, and provides no security against CAs not implementing CAA. As far as I'm aware, this was the only comment made with regard to the previous version. It also switches from “registration” to “account” to correspond with the terminology change in the current ACME draft. Hugo Landau From nobody Tue Feb 7 09:28: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 0E248129D84 for ; Tue, 7 Feb 2017 09:28:13 -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 zx7Q-Frn9_NE for ; Tue, 7 Feb 2017 09:28:11 -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 6F4B612956C for ; Tue, 7 Feb 2017 09:28:11 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id A412943344A for ; Tue, 7 Feb 2017 17:28:10 +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 8623A433401 for ; Tue, 7 Feb 2017 17:28:10 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1486488490; bh=C0bch5rG1kgHCvgvGjMEHGbrgjP+wyouD2DKPyUaCa4=; l=1512; h=From:To:Date:From; b=Aqj5PhOSOxuDqBa2eRbEV5z/LOpCpPoNOe/Mlr9HaDMOBAGjsIAbJXbMdP+M/xCJm RprWmqzCsCiqtPPz9tLcxhrNMRDSX58jKRb1//PoMH7RTIlU5NSpsXDzOT6YKQ6ZyI pvNe4HJH5bXyUVGnzO0nTrFd0JysBQ44v7yBD+iQ= Received: from email.msg.corp.akamai.com (usma1ex-casadmn.msg.corp.akamai.com [172.27.123.33]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 81FD41FC90 for ; Tue, 7 Feb 2017 17:28:10 +0000 (GMT) Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 7 Feb 2017 12:27:49 -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; Tue, 7 Feb 2017 12:27:49 -0500 From: "Salz, Rich" To: "acme@ietf.org" Thread-Topic: ACME draft is now in WGLC. Thread-Index: AdKBZ2LP4XWB1i0uR++KFKjfHhNLwg== Date: Tue, 7 Feb 2017 17:27:48 +0000 Message-ID: <8473d9ba84894d49b2f2232370d66b46@usma1ex-dag1mb3.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.39.116] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [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 Feb 2017 17:28:13 -0000 SSBwdXQgdGhlIHRpbWUgcGVyaW9kIGFzIHNpeCB3ZWVrcywgd2hpY2ggdGFrZXMgdXMgdG8ganVz dCBhcm91bmQgSUVURi05OC4uLg0KDQpQTEVBU0UgcmVwbHkgb24gbGlzdCBpZiB5b3Ugd2lsbCBy ZXZpZXcgYW5kL29yIGFyZSBpbnRlcmVzdGVkIGluIHdvcmtpbmcgb24gaW50ZXJvcC4gDQotLSAg DQpTZW5pb3IgQXJjaGl0ZWN0LCBBa2FtYWkgVGVjaG5vbG9naWVzDQpNZW1iZXIsIE9wZW5TU0wg RGV2IFRlYW0NCklNOiByaWNoc2FsekBqYWJiZXIuYXQgVHdpdHRlcjogUmljaFNhbHoNCg0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSUVURiBTZWNyZXRhcmlhdCBbbWFpbHRv OmlldGYtc2VjcmV0YXJpYXQtcmVwbHlAaWV0Zi5vcmddIA0KU2VudDogVHVlc2RheSwgRmVicnVh cnkgMDcsIDIwMTcgMTI6MjYgUE0NClRvOiBkcmFmdC1pZXRmLWFjbWUtYWNtZUBpZXRmLm9yZzsg YWNtZS1jaGFpcnNAaWV0Zi5vcmcNClN1YmplY3Q6IElFVEYgV0cgc3RhdGUgY2hhbmdlZCBmb3Ig ZHJhZnQtaWV0Zi1hY21lLWFjbWUNCg0KDQpUaGUgSUVURiBXRyBzdGF0ZSBvZiBkcmFmdC1pZXRm LWFjbWUtYWNtZSBoYXMgYmVlbiBjaGFuZ2VkIHRvICJJbiBXRyBMYXN0IENhbGwiIGZyb20gIldH IERvY3VtZW50IiBieSBSaWNoIFNhbHo6DQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlldGYtYWNtZS1hY21lLw0KDQoNCkNvbW1lbnQ6DQpBcyB3ZSBhZ3JlZWQgYXQg SUVURi05NyAoU2VvdWwpLCB3ZSB3aWxsIGhhdmUgYSBzbGlnaHRseSBsb25nZXIgV0dMQyBwZXJp b2QgdG8gZW5jb3VyYWdlIGltcGxlbWVudGF0aW9ucyBhbmQgaW50ZXJvcC4NCg0KQXJlIHRoZXJl IGFueSB2b2x1bnRlZXJzIHRvIHJlYWQgYW5kIHJldmlldyB0aGlzIGRvY3VtZW50PyAgUGxlYXNl IHBvc3QgdG8gYWNtZUBpZXRmLm9yZy4NCg0KRG9lcyBhbnlvbmUgaGF2ZSBhbiBpbXBsZW1lbnRh dGlvbiBpbiBwcm9ncmVzcyBhbmQgd291bGQgYmUgaW50ZXJlc3RlZCBpbiBkb2luZyBpbnRlcm9w IGF0IHRoZSBJRVRGIEhhY2thdGhvbiBhdCBJRVRGLTk4IGluIENoaWNhZ28/ICBQbGVhc2UgcG9z dCB0byBhY21lQGlldGYub3JnDQo= From nobody Tue Feb 7 09:41: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 EDC7E129591 for ; Tue, 7 Feb 2017 09:41:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.002 X-Spam-Level: X-Spam-Status: No, score=-7.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DHFxvLb_fxTl for ; Tue, 7 Feb 2017 09:41:09 -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 4E65D129592 for ; Tue, 7 Feb 2017 09:41:09 -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:References:To:Subject; bh=wktxm6vqpV2y0hSG6elb8vxQ4WCcTfAUGu4ENwv1bAk=; b=2ydGO9GSXq4XEgde96XSHYH8FCbOgdNhyvdRHSQY1pU0j2HINy1KBZzyvID8NOQuTyA76JjJz762ofmobm+DGGTTgxzfpGePlDfNvQWj9K4Vc7JCbZpMEGd214uZWHEkMTD2dPJnwCumRtVPhDH3d0hmioYd4PBMODoqm6I0oGQ=; Received: ; Tue, 07 Feb 2017 09:41:10 -0800 To: "Salz, Rich" , "acme@ietf.org" References: <8473d9ba84894d49b2f2232370d66b46@usma1ex-dag1mb3.msg.corp.akamai.com> From: Jacob Hoffman-Andrews Message-ID: <3a52cc35-f9ab-ad17-d5dc-c54c7f47a219@eff.org> Date: Tue, 7 Feb 2017 09:41:08 -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: <8473d9ba84894d49b2f2232370d66b46@usma1ex-dag1mb3.msg.corp.akamai.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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 Feb 2017 17:41:12 -0000 Let's Encrypt engineers have been working on an implementation of the latest spec: https://github.com/letsencrypt/pebble We'll take lessons learned from that when we build support into our production boulder software. We're also going to adapt the Python ACME library to support the latest version. On 02/07/2017 09:27 AM, 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. > -- > Senior Architect, Akamai Technologies > Member, OpenSSL Dev Team > IM: richsalz@jabber.at Twitter: RichSalz > > > -----Original Message----- > From: IETF Secretariat [mailto:ietf-secretariat-reply@ietf.org] > Sent: Tuesday, February 07, 2017 12:26 PM > To: draft-ietf-acme-acme@ietf.org; acme-chairs@ietf.org > Subject: IETF WG state changed for draft-ietf-acme-acme > > > The IETF WG state of draft-ietf-acme-acme has been changed to "In WG Last Call" from "WG Document" by Rich Salz: > > https://datatracker.ietf.org/doc/draft-ietf-acme-acme/ > > > Comment: > As we agreed at IETF-97 (Seoul), we will have a slightly longer WGLC period to encourage implementations and interop. > > Are there any volunteers to read and review this document? Please post to acme@ietf.org. > > Does anyone have an implementation in progress and would be interested in doing interop at the IETF Hackathon at IETF-98 in Chicago? Please post to acme@ietf.org > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > From nobody Tue Feb 7 21:16: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 5F7BE12996B for ; Tue, 7 Feb 2017 21:16:01 -0800 (PST) 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 rbnrl2cMYD_2 for ; Tue, 7 Feb 2017 21:15:59 -0800 (PST) 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 6A0661298D2 for ; Tue, 7 Feb 2017 21:15:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by umbriel.devever.net (Postfix) with ESMTP id CF48C1D272 for ; Wed, 8 Feb 2017 06:15:57 +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=1486530957; x=1504720318; bh=ozrV sByDSpLLM1/RNvmn6oo+sh6j1PfEXcLpkqjHMz4=; b=jT+bvwqYurT8/xfb0Je/ XYn2Lvfp3VZ2tzb4n//A6lUtUWQKgFsGnwcmYcjI5bwuJmT+zflJXM6AZ3nykkBP lpANrQf2DXOfQpg0Dkw/j58EyNZ6kfjYIWrwmL15PmPlMV7yEc796EgmQrORzKnP fX+jorLhOWpnwTMQK/8xOkE6A9/4Tip/ODXkQXSnmZ0+CR8Xi3H0GcXb5ByjYwcT 6XDsnBAU0pX3a0KdBdskS+bIy9G1WRvAXlGMLtokT3OpKaMVjGBt/tovI1NjtBUG 0j2CWbASDeoGT7wGo2z00n4OkoT/BZ0+Lu4SElf8EAfGiPUNXI99De6L1V9khG/g QQ== 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 kvGBHvgg9YNg for ; Wed, 8 Feb 2017 06:15:57 +0100 (CET) Received: from andover.lhh.devever.net (localhost [127.0.0.1]) by umbriel.devever.net (Postfix) with SMTP id 963941D25D for ; Wed, 8 Feb 2017 06:15:57 +0100 (CET) Date: Wed, 8 Feb 2017 05:15:57 +0000 From: Hugo Landau To: acme@ietf.org Message-ID: <20170208051557.GA1383@andover.lhh.devever.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: [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: Wed, 08 Feb 2017 05:16:01 -0000 Some minor questions on HTTP semantics: - HEAD new-nonce: If GET is used instead, which is allowed, is 204 returned or 200? "The server SHOULD also respond to GET requests for this resource, returning an empty body". This implies a 200 response with Content-Length: 0, but 204 should be equally valid, so I'm not sure why this needs to differ. - "If the server already has an account registered with the provided account key, then it MUST return a 200 (OK) response and provide the URI of that account in a Content-Location header field." It should probably be clarified whether the account object is returned in this request. The use of Content-Location here instead of Location is a little odd, but might make sense if the account object is returned. That said, given that an existing account can't be updated by POSTing to new-account I'm not sure that really works. The new-account resource doesn't represent an existing account, so the use of Content-Location here seems inappropriate. Is there a reason to avoid the use of Location here? Moreover, new-authz "accept"/"require" dictates use of 303/Location, so this seems inconsistent. Possibly one or the other should be changed. Previous discussion indicates that 303/Location is perceived as problematic due to HTTP libraries tending to follow it automatically, which makes it hard for ACME implementations to be aware of the final location. I agree with this; personally 200/Location for both new-account and new-authz makes sense to me. - GET certificate: If Accept: application/pkix-cert is used, does rel=up link to intermediate? Is varying links such as rel=up by content negotiation OK? RFC5988 seems to suggest otherwise to me, as it describes a link as being between two resources, not between two resource representations. To be fair, optimal mapping to platonic HTTP semantics often seems to be more of an hope than something ever fully accomplished. These are minor issues. Editorial fixes: s/JSON dictionary/JSON object/: There are no dictionaries in JSON, only objects. s/use when configuring CAA record/use when configuring CAA records/ p31: inconsistent use of full stops. Account Creation: 'containing only the "contact" field' -> terms-of-service-agreed is required too, sentence needs updating 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. -- Hugo Landau I know of no warrant or notice of a kind defined within the Investigatory Powers Act 2016 or the Regulation of Investigatory Powers Act 2000 that has not been brought to the attention of the public. I will always answer questions about these or similar matters, assuming reasonable request rates, unless legally prevented from doing so. From nobody Fri Feb 10 10:56: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 E9106129AA3 for ; Fri, 10 Feb 2017 10:56:39 -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 XWR8Sz1M2KNH for ; Fri, 10 Feb 2017 10:56:38 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 8B31912944E for ; Fri, 10 Feb 2017 10:56:38 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id DE8E5433406 for ; Fri, 10 Feb 2017 18:56:37 +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 C8614433402 for ; Fri, 10 Feb 2017 18:56:37 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1486752997; bh=6gQwvqcwzMSY7AEU3dWFHFkNk+HMkrc2LjQB0WqpGdA=; l=425; h=From:To:Date:References:In-Reply-To:From; b=Rqs+a1sgzfvyJwJqtGkddGclXwmxHzAhaLN6cSrBSJU2hjRQ0CGJ4ZrsM7D3fxclu E82Cw8eGPKqR1oaECwHpXb/dz2koh8a19qmjmaXSax4Y3UBRN9C6gwv6gCz/x0oWRh Jj9XnqN3lkIpNmX/msXi+UGsYGCVNmWIBYevz5sY= Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id C4FDC1FC94 for ; Fri, 10 Feb 2017 18:56:37 +0000 (GMT) Received: from USMA1EX-EXJRNL1.msg.corp.akamai.com (172.27.123.99) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 10 Feb 2017 13:56:37 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by USMA1EX-EXJRNL1.msg.corp.akamai.com (172.27.123.99) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 10 Feb 2017 13:56:37 -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; Fri, 10 Feb 2017 13:56:36 -0500 From: "Salz, Rich" To: "Salz, Rich" , "acme@ietf.org" Thread-Topic: ACME draft is now in WGLC. Thread-Index: AdKBZ2LP4XWB1i0uR++KFKjfHhNLwgCZ6t8A Date: Fri, 10 Feb 2017 18:56:36 +0000 Message-ID: <83f7104eef75470181d7f81fc7604a8e@usma1ex-dag1mb3.msg.corp.akamai.com> References: <8473d9ba84894d49b2f2232370d66b46@usma1ex-dag1mb3.msg.corp.akamai.com> In-Reply-To: <8473d9ba84894d49b2f2232370d66b46@usma1ex-dag1mb3.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.42.134] 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: Fri, 10 Feb 2017 18:56:40 -0000 > PLEASE reply on list if you will review and/or are interested in working = on > interop. Looking for last-minute Valentine's Day plans? (https://en.wikipedia.org/w= iki/Valentine's_Day among others). What could be more romantic than an eve= ning spent with your loved one reading the ACME WGLC spec, and jointly post= ing comments to the list? Start here: https://datatracker.ietf.org/doc/draft-ietf-acme-acme/ From nobody Sat Feb 11 14:37: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 3A87D129580 for ; Sat, 11 Feb 2017 14:36:58 -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 h_0evPyx0z2d for ; Sat, 11 Feb 2017 14:36:56 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B779E129548 for ; Sat, 11 Feb 2017 14:36:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id E0A5730041D for ; Sat, 11 Feb 2017 17:36:53 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 415_etHs_0ao for ; Sat, 11 Feb 2017 17:36:51 -0500 (EST) Received: from mail.smeinc.net (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTPSA id D37C4300293; Sat, 11 Feb 2017 17:36:51 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sat, 11 Feb 2017 17:36:51 -0500 From: housley@vigilsec.com To: "Salz, Rich" In-Reply-To: <8473d9ba84894d49b2f2232370d66b46@usma1ex-dag1mb3.msg.corp.akamai.com> References: <8473d9ba84894d49b2f2232370d66b46@usma1ex-dag1mb3.msg.corp.akamai.com> Message-ID: <3eac78aafc08b23b3bbe1949dd34bc0e@vigilsec.com> X-Sender: housley@vigilsec.com User-Agent: Roundcube Webmail Archived-At: Cc: acme@ietf.org 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: Sat, 11 Feb 2017 22:36:58 -0000 > From: IETF Secretariat [mailto:ietf-secretariat-reply@ietf.org] > Sent: Tuesday, February 07, 2017 12:26 PM > To: draft-ietf-acme-acme@ietf.org; acme-chairs@ietf.org > Subject: IETF WG state changed for draft-ietf-acme-acme > > > The IETF WG state of draft-ietf-acme-acme has been changed to "In WG > Last Call" from "WG Document" by Rich Salz: > > https://datatracker.ietf.org/doc/draft-ietf-acme-acme/ Please use the terminology from RFC 5280. Throughout the document: s/certificate authority/certification authority/ s/issuing authority/certificate issuer/ Also, please use the correct expansion for PKIX (PKI using X.509). In Section 1, please define ACME. Also in Section 1: s/Certificates in the Web PKI [RFC5280]/Certificates [RFC5280] in the Web PKI/ In Section 5.1, I think it is desirable to add a requirement that the ACME server SHOULD OCSP Staple. In Section 5.2, please repeat the reference for the JWS specification at the front of this section. Section 5.2 says: In the examples below, JWS objects are shown in the JSON or flattened JSON serialization, with the protected header and payload expressed as base64url(content) instead of the actual base64-encoded value, so that the content is readable. Some fields are omitted for brevity, marked with "...". The example is above this text (below), and there is no "..." in it. In Section 5.5, please add a MUST statement about the size of the nonce value (before base64url encoding). In Section 6.1.1, how does the key-change entry in the table in section 6.1.1 relate to the figure in Section 6.1? The other entries in this table seem to have an obvious companion in the figure. I think the figure should to show how the key-change is used update the acct. Section 6.1.1: s/function as both an ACME/functions as both an ACME/ Section 6.1.1 says: "caa-identities" (optional, array of string): Each string MUST be a lowercase hostname ... How are IDNs handled? Are all U-labels converted to A-labels? Section 6.1.2: s/associated to an account/associated with an account/ Section 6.1.3 says: status (required, string): The status of this order. Possible values are: "pending", "processing", "valid", and "invalid". Should the list of possible status strings should also include "expired"? If not, the text should say that the status will be set to invalid if the authorizations are not accomplished before the expiration time. Section 6.1.4 says: scope (optional, string): If this field is present, then it MUST contain a URI for an order resource, such that this authorization is only valid for that resource. If this field is absent, then the CA MUST consider this authorization valid for all orders until the authorization expires. [[ Open issue: More flexible scoping? ]] This scoping seems fine. Please remove the [[ question ]]. Section 6.1.4 says: ... Servers MUST verify any identifier values that begin with the ASCII Compatible Encoding prefix "xn-" as defined in [RFC5890] are properly encoded. ... I think you want to require the A-labels to be converted to U-labels and back again, and then reject the label if the converted A-label does not match the original A-label. In Section 6.3.3, the list of steps clearly includes checking the signature on the inner JWS in step 4, but I do not see a step that checks the signature on the outer JWS. I think the both signature checks need to be explicit in the steps. Is an additional subsection in Section 6.3 needed to deal with lost account signature private keys? I assume that some out-of-band mechanism would be needed to delete the account so that a new one can be created. Section 6.4.2 says: The default format of the certificate is PEM (application/x-pem-file) as specified by [RFC7468]. ... The client may request other formats by including an Accept header in its request. For example, the client may use the media type application/pkix-cert to request the end- entity certificate in DER format. RFC 7468 defines the textual encoding for certificates, but it does not define the application/x-pem-file media type. I cannot find a registration for the application/x-pem-file media type. Also, please add a reference to RFC 2585; it specifies the application/pkix-cert media type. In Section 6.5, should the example use different challenges for "http-01", "tls-sni-02", and "dns-01"? Section 7.2: s/in A and AAAA records/in the DNS A and AAAA resource records/ Section 7.3: s\by an A/AAAA record\by the DNS A and AAAA resource records\ In Section 8.2, I cannot understand the figure. Please correct it. Section 9.1: s/man in the middle/man-in-the-middle (MitM)/ Russ From nobody Sun Feb 12 21:26: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 5DD0912947C for ; Sun, 12 Feb 2017 21:26:44 -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 i92XPMsTQCbY for ; Sun, 12 Feb 2017 21:26:42 -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 BC58312940E for ; Sun, 12 Feb 2017 21:26:41 -0800 (PST) Received: by mail-qk0-x232.google.com with SMTP id s140so84880401qke.0 for ; Sun, 12 Feb 2017 21:26:41 -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=6giMJWwVk/fsBQ8jH3K0vBI2HxYWv6n2PRdm3gH6NVI=; b=lHsI6ZZB+2b2XBmkOye2nfaGGA5tZWioX5ILgWE1sJ4yixwatPvoEfqSO9o2Jnfrru cuI8L6HQ/uY7szRrKE7Z7oh/fAeHtlVFDE/+KQhM0hMvBGrj8HXz14+m2OwL2oVB4CjA 3pBJXqReix59/4osAnXByrIo9fhtJczoMaJDOIAVOu7K1dyEkrHwKPQ4BlX9xkM3MgtI b4/aco3juUrye/HJr4Ka9ulBAiBWXLUwpHIzPMHwE88rN9V99Z0zjL6XKtil/GcGRtBv haLuDNDz7BmpT2rvb2JjpNYkM1P6fp66HDXWUW2MUV6gfeEw/LO8GW9n12omll1jzzYn 0wsg== 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=6giMJWwVk/fsBQ8jH3K0vBI2HxYWv6n2PRdm3gH6NVI=; b=rieWMc8fmJt2le91OSoVe6dV8eCuClweO5H2u9HNyYQEWqtIhegqNhURGKZtoP2/s1 4mPS0V8W+oYsYnX9UNVcaOl7siT9MFpAUrL3C0RjlgOvRTTBgiunfln+9V3uTbN7yUV+ xKmxSkBWr4BqJdJBkoC9i2/PPaLK7V3eGve00/vxCfjimJSDUPSVKKd9PeXqBy1JL4TO oMo52aIWxqypoTVSRyyM4c82HlUyKwbnvnrTFjjZ7SAlEvkpF+yuJQEkEZfGjMTsgEdF e6zXj51Dtd8audZCwEgT+D5d0ugpV47O73nSJsA+LnEo7x3UHHwlzUX8DHpd23kEyxtB ivjg== X-Gm-Message-State: AMke39nN4H/YwGLzou6vMANvTcbdlyH6UUEktl6UmQm6i4sGqdsRXINnVXixUhO5m9gf9/aK/h5kPeBE5Vv3uw== X-Received: by 10.233.216.68 with SMTP id u65mr19375069qkf.68.1486963600510; Sun, 12 Feb 2017 21:26:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Sun, 12 Feb 2017 21:26:39 -0800 (PST) In-Reply-To: <83f7104eef75470181d7f81fc7604a8e@usma1ex-dag1mb3.msg.corp.akamai.com> References: <8473d9ba84894d49b2f2232370d66b46@usma1ex-dag1mb3.msg.corp.akamai.com> <83f7104eef75470181d7f81fc7604a8e@usma1ex-dag1mb3.msg.corp.akamai.com> From: Martin Thomson Date: Mon, 13 Feb 2017 16:26:39 +1100 Message-ID: To: "Salz, Rich" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "acme@ietf.org" 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 Feb 2017 05:26:44 -0000 On 11 February 2017 at 05:56, Salz, Rich wrote: > ACME WGLC It's been a while since I did a review of this, so I spent a few hours on it. This document is in pretty good shape. I have a lot of comments (a LOT), and some of these are serious enough that I'd want to see another WGLC, but they are relatively minor. Overall the document is in very good shape; most of my comments are of the nitpicking variety. This is a pretty significant piece of work and that this is as good as it is represents cause for congratulations to those involved (except me, I'm just a hazard). Meta I found the use of lowercase versions of RFC 2119 keywords quite distracting, and occasionally confusing. It's often the case that the lowercase version is used where a simple imperative statement would work. I haven't called out many of those in my review, except where they caused what I think to be a genuine problem. I have created an editorial pull request on the spec. There were lots of tiny fixes (including some opportunities to correct the above). In some cases, that PR will conflict with substantial changes that I think need to happen, so you might want to attend to that first. https://github.com/ietf-wg-acme/acme/pull/243 S5.1 Clients SHOULD support HTTP public key pinning [RFC7469], and servers SHOULD emit pinning headers. and ACME clients SHOULD send a User-Agent header in accordance with [RFC7231], including the name and version of the ACME software in addition to the name and version of the underlying HTTP client software. and Such servers SHOULD set the Access-Control-Allow-Origin header field to the value "*". Why? It's usually good practice with a SHOULD to provide some sort of reason why choosing not to comply might be necessary, or to otherwise motivate the choice. All three seem relatively easy to fix with a simple sentence (pinning good m'kay, client bugs(?), building a web-based client). S5.2 For all other requests, there MUST be a "kid" field. This field must contain the account URI received by POSTing to the new-reg resource. MUST? 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. server MUST return an error This would benefit from a reference to S5.7, as does all the other instances of error handling. Though this section includes an example (that seems unnecessary), it's very hard to tell if this is normative or not from context. In the examples below, JWS objects are shown in the JSON or flattened JSON serialization, with the protected header and payload expressed as base64url(content) instead of the actual base64-encoded value, so that the content is readable. Some fields are omitted for brevity, marked with "...". I didn't really understand this without an example to use for reference. Given that the first actual use of this form is 15 (!) pages further down the document, maybe you could move this there. S5.3 JWK thumbprint [citation needed] S5.4 I would reference RFC 7230, Section 2.7.3 "http and https URI Normalization and Comparison" here and note the risk that normalization could cause comparison failures. A recommendation that URLs generated by the server SHOULD be normalized according to that section so that the risk of normalization is reduced. S5.5 The server MUST include a Replay- Nonce header field in every successful response to a POST request, and SHOULD provide it in error responses as well. This seems to purposefully neglect to mention other requests, like GET. Does the "SHOULD" apply just to POST requests, or is it any method? This section says that nonces are mandatory with POST requests, but does not offer a way to get a nonce that does not require a nonce. Please make this observation and reference S6.2. S5.6 Once again, mention is made of error descriptions without a forward reference. Additionally, the server SHOULD send a "Retry-After" header indicating when the current request may succeed again. "may" or "could"? 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). S6.1 The list of resources could use some references to the sections that define them. S6.1.2 status (required, string): The status of this account. Possible values are: "valid", "deactivated", and "revoked". The value "deactivated" should be used to indicate user initiated deactivation whereas "revoked" should be used to indicate administratively initiated deactivation. I assume that "user" and "administratively" mean "client" and "server" respectively. Please clarify this point, it's confusing. S6.1.3 authorizations (required, array of string): For pending orders, the authorizations that the client needs to complete before the requested certificate can be issued (see Section 6.5). For final orders, the authorizations that were completed. Each entry is a URL from which an authorization can be fetched with a GET request. Which states correspond to final? If an order is pending with one authorization complete and another incomplete, do I read that the complete authorization is NOT listed here? But that doesn't fit with this: The elements of the "authorizations" array are immutable once set. It might pay to clarify this some. 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. A client should attempt to fulfill at most one of these challenges, and a server should consider any one of the challenges sufficient to make the authorization valid. lowercase should or SHOULD or MUST? This really needs more meat if it is to be useful. If we accept that a client can attempt to fulfill more than one challenge on the basis that they might fail, then permit them to try many, but encourage only one. On the server side, if a server later discovers that the challenges are insufficient, then permit that too. "A client only needs to complete one of these challenges, though it MAY attempt more than one challenge if errors prevent it from completing its first choice. A server therefore MUST accept any challenge, though a server MAY still choose not to permit an authorization for other reasons." Or something along those lines. (BTW, I applaud the simplification from earlier versions.) S6.3 A client creates a new account with the server by sending a POST request to the server's new-account URI. The body of the request is a stub account object containing only the "contact" field. In addition to the user account binding (S6.3.2), the example violates this by including a ToS agreement. I suspect the above is incorrect. [...] the server MUST reject new-account requests that do not have the "terms-of-service-agreed" set to "true". Which error code do we use here? S6.3.1 Is the intent that the "instance" document be loaded in a web browser, as opposed to being poked by an ACME client? It might help to explicitly say that. 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? 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.3 "NOT REQUIRED" isn't a thing (at least as far as I can tell). "MAY omit the "nonce" parameter" would be fine, I think. Frankly, I don't see why they can't both be required to include a nonce, but I guess that the account URI should be plenty specific enough to avoid any problems with copy and paste of the inner JWS. 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. S6.4 The body of this response is an order object reflecting the client's request and any authorizations the client must complete before the certificate will be issued. I don't think that this is "MUST", but it's a confusing word to use here. BTW, I like the description of the states in terms of what the client should do. There are other cases where this would be valuable, such as in S6.5. S6.4.1 ...mentions "combinations", but I think that this has gone away. 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. S6.5.1 If the final state is "valid", then the server MUST include an "expires" field. When finalizing an authorization, the server MAY remove challenges other than the one that was completed, and may modify the "expires" field. This just said two conflicting things about the "expires" field. I think that this could be: "When the authorization is finalized, if it is "valid" then `expires` MUST be set, otherwise `expires` MUST be removed. A server MAY remove challenges other than the one that was completed from a finalized authorization." Usually, the validation process will take some time, Could this instead be "The validation process could take some time", rather than making some statement based on what we know now in this very narrow application of the protocol? 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. The use of Retry-After here is odd, but I think that it's fine. I would separate this out in a new paragraph: "A server MAY include a Retry-After header field in its responses to clients, clients that are polling for updates SHOULD wait at least this amount of time before making another request to that resource." 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? S7 This section describes an initial set of challenge types. Each challenge must describe: MUST, I think S7.1 UTF-8 form (or, equivalently, ASCII). A normative citation for RFC 3269 is needed (and maybe even RFC 20). S7.2 Because many webservers allocate a default HTTPS virtual host to a particular low-privilege tenant user in a subtle and non-intuitive manner, the challenge must be completed over HTTP, not HTTPS. MUST 2. Verify that the resulting URI is well-formed. How is this ever not true? The URI has to be well-formed since the template is correct by design and the values for domain and token have already been checked. S7.3&4 It is RECOMMENDED that the server open multiple TLS connections from various network perspectives, in order to make MitM attacks harder. Isn't this equally valid for http? (Or - more to the point - equally invalid here?) S9.2 I think that it makes sense here to say somewhere that while a TLS MitM or CDN might compromise confidentiality (which has some implications for account holders), they cannot compromise integrity. Stylistically, this section is two things: a discussion of the ACME channel and then a discussion of the challenge channel, would subsections help? 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? S9.3 You should also recommend rate limits on account creation, or your other mitigations might be weakened. S9.4 Does an ACME server send Referer[sic]? What should it set it to? S9.5 This should probably recommend doing these checks - to the extent possible - before creating the order. Though issuance is the ultimate thing that needs to be controlled, allowing an order to proceed just makes extra work for all involved. 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? From nobody Sun Feb 12 22:09:37 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC48129550 for ; Sun, 12 Feb 2017 22:09:36 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x4g1mBynDHY1 for ; Sun, 12 Feb 2017 22:09:34 -0800 (PST) Received: from mail-wr0-x242.google.com (mail-wr0-x242.google.com [IPv6:2a00:1450:400c:c0c::242]) (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 45084129503 for ; Sun, 12 Feb 2017 22:09:34 -0800 (PST) Received: by mail-wr0-x242.google.com with SMTP id k90so22412834wrc.3 for ; Sun, 12 Feb 2017 22:09:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=JtrsKfcl79ZhbtiZZgueCRePQVniNwVsWOri8HfRmsE=; b=XAR6g2YLuF0orK8H8P9ci5ad/3Suev3jkMnm/mY7Dpg2SpZFd1LGL5/rarU5EuqDvW T1MFwIKhMIKnKZ1GRiq+S6oYRv/2t2+iFvA8EQGhe5GqPKXVIU+1evg00TOBhBZcSg90 72r4bDmkaGekJCUbNuxRsiex4cZbLGhRs6Fq82e3labnPqq+rNMsu+JRd1LkQBjOSL6Q ALjr/L2aV5Ue9XaZmWajB/5QpWEyvNb86wPI/4AhaJQWu2kBdATV0AqWK5QTcjQoU+id Cet54JtqiKB+pn+K9qVex27mtsQsecWIaqiQFpWEDXPD2lmrpi0V9SgROT0/UWZNPE/K X8Ag== 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=JtrsKfcl79ZhbtiZZgueCRePQVniNwVsWOri8HfRmsE=; b=btAeJfTmKpYnAafOJ+deYL5dTXF2/MVxXqNrUpBlzA/NTv6eyA7z8vkg/a17iaHYwt Tj+TjiQYDx+w3S/p1qE+IdQrsIgjFr4pFaKdKDDCR2H73Z8G2Caf42oAFvs8sYe3Kv2d rCNvnhM4eGcQWlz6bflG8RUefsK0pWuDH+WWcH1xYtVkFCL9O0eg7wqqra8knbhLfYEe 0BQry/aH0baCWq/IRkEEhezvvF97vKEWJzOf87KLeoPsnylMVLc3w1HRcZInvnh8pzyE bai3dEzt8ojKLqVZ1f5fB1v9CBmIs8xu+gjW0Blre3fFPdBCOble+S8DyrIysIyR25q3 1SRQ== X-Gm-Message-State: AMke39kFBfcEo0U/NxhIUFERug+7TZ9z7ED/ylixKmRzrOyUtKKVksjdl4fAJK2K8iPc6w== X-Received: by 10.223.169.85 with SMTP id u79mr18078602wrc.169.1486966172856; Sun, 12 Feb 2017 22:09:32 -0800 (PST) Received: from [192.168.1.79] (124.25.176.95.rev.sfr.net. [95.176.25.124]) by smtp.googlemail.com with ESMTPSA id u184sm3892839wmb.29.2017.02.12.22.09.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Feb 2017 22:09:32 -0800 (PST) To: Martin Thomson , "Salz, Rich" References: <8473d9ba84894d49b2f2232370d66b46@usma1ex-dag1mb3.msg.corp.akamai.com> <83f7104eef75470181d7f81fc7604a8e@usma1ex-dag1mb3.msg.corp.akamai.com> From: Anders Rundgren Message-ID: <0903e6e8-be00-b989-e388-cd811dd25ddf@gmail.com> Date: Mon, 13 Feb 2017 07:09:11 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "acme@ietf.org" 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 Feb 2017 06:09:36 -0000 On 2017-02-13 06:26, Martin Thomson wrote: > In the examples below, JWS objects are shown in the JSON or flattened > JSON serialization, with the protected header and payload expressed > as base64url(content) instead of the actual base64-encoded value, so > that the content is readable. Some fields are omitted for brevity, > marked with "...". > > I didn't really understand this without an example to use for > reference. Given that the first actual use of this form is 15 (!) > pages further down the document, maybe you could move this there. JWS is great for what is was originally designed for. ES6 normalization nullifies the need for dressing JSON data in Base64Url. Anders https://cyberphone.github.io/doc/security/jsonsignatures.html From nobody Mon Feb 13 07:58:24 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59F25128E19 for ; Mon, 13 Feb 2017 07:58:23 -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 EotuKmZa6DJf for ; Mon, 13 Feb 2017 07:58:22 -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 65E4F128B38 for ; Mon, 13 Feb 2017 07:58:22 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id C09A9433427; Mon, 13 Feb 2017 15:58:21 +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 A85ED433424; Mon, 13 Feb 2017 15:58:21 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1487001501; bh=y9X1lSci40n5zbGzmEMZJ+Xu0l/1FfARaPc4ioL+/GA=; l=776; h=From:To:CC:Date:References:In-Reply-To:From; b=0SjrVfNxY5Q0plITsEywFg118Tln85ws9seC3FKM19xtY4Uq/uAtFgVZhN5SyQWNo gJ4i1W+g0o0OLRdP8ekUB8Ulm4rnSNklrgSHeCqIdteP1wLQn0TpNWin8zpPdw7cQF 4x+91A63dcCZfBmierWMO0na8IaDycWmZ0Flu3sA= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.33]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id A45691FCA6; Mon, 13 Feb 2017 15:58:21 +0000 (GMT) Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 13 Feb 2017 10:58:21 -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, 13 Feb 2017 10:58:21 -0500 From: "Salz, Rich" To: Martin Thomson , Russ Housley Thread-Topic: [Acme] ACME draft is now in WGLC. Thread-Index: AdKBZ2LP4XWB1i0uR++KFKjfHhNLwgCZ6t8AAIUmuoAAC37dEA== Date: Mon, 13 Feb 2017 15:58:20 +0000 Message-ID: <10bd13a23f8c458fa2e2a8e597938e69@usma1ex-dag1mb3.msg.corp.akamai.com> References: <8473d9ba84894d49b2f2232370d66b46@usma1ex-dag1mb3.msg.corp.akamai.com> <83f7104eef75470181d7f81fc7604a8e@usma1ex-dag1mb3.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.46.186] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "acme@ietf.org" 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 Feb 2017 15:58:23 -0000 UnVzcyBhbmQgTWFydGluLA0KDQpUaGFuayB5b3UgdmVyeSBtdWNoIGZvciB5b3VyIGRldGFpbGVk IHJldmlldyEgIEkgZmVlbCBtdWNoIGJldHRlciB0aGF0LCBvbmNlIHlvdXIgaXNzdWVzIGFyZSBy ZXBsaWVkLXRvLCB0aGUgZG9jdW1lbnQgd2lsbCBiZSBpbiB2ZXJ5IGdvb2Qgc2hhcGUuDQoNCldl IHN0aWxsIGhhdmUgYSBtb250aCBvbiBXR0xDLCBzbyBhbiB1cGRhdGVkIGRyYWZ0IHNob3VsZCBi ZSBmZWFzaWJsZSBieSB0aGUgZW5kIG9mIHRoZSBtb250aCwgKnJpZ2h0IGF1dGhvcnM/Kg0KDQpJ IGRvIGhhdmUgb25lIHN1Z2dlc3Rpb24sIGlmIGl0J3MgcG9zc2libGUgdG8gc3BsaXQgdGhpbmdz IGludG8gInN0cmljdGx5IGVkaXRvcmlhbCIgYW5kICJiaWdnZXIgaXNzdWUiIHRoYXQgbWlnaHQg aGVscCB0aGUgYXV0aG9ycy4gIEkga25vdyB0aGF0J3MgcHJvYmFibHkgYSBsb3Qgb2Ygd29yay4g IFBlcmhhcHMgdGhlIGRvYyBhdXRob3JzIGNhbiBzeW5jIHVwIHdpdGggeW91IGd1eXMgZWFjaCwg dmlhIHBob25lLCBhbmQgd2FsayB0aHJvdWdoIGFsbCB0aGUgaXRlbXM/DQoNCgkvciQNCg0K From nobody Mon Feb 13 09:52:36 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 177ED129713 for ; Mon, 13 Feb 2017 09:52:35 -0800 (PST) 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 M1LE3hD7HwYZ for ; Mon, 13 Feb 2017 09:52:33 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72BC9129706 for ; Mon, 13 Feb 2017 09:52:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id BE10E300434 for ; Mon, 13 Feb 2017 12:52:32 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 08pZMPcO4hBV for ; Mon, 13 Feb 2017 12:52:31 -0500 (EST) Received: from [64.170.98.129] (unknown [64.170.98.129]) by mail.smeinc.net (Postfix) with ESMTPSA id C4A8C300254; Mon, 13 Feb 2017 12:52:30 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Russ Housley In-Reply-To: <3eac78aafc08b23b3bbe1949dd34bc0e@vigilsec.com> Date: Mon, 13 Feb 2017 12:52:29 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4BF684AB-EBBF-4495-8509-8312A41347FD@vigilsec.com> References: <8473d9ba84894d49b2f2232370d66b46@usma1ex-dag1mb3.msg.corp.akamai.com> <3eac78aafc08b23b3bbe1949dd34bc0e@vigilsec.com> To: "Salz, Rich" X-Mailer: Apple Mail (2.3259) Archived-At: Cc: IETF ACME 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 Feb 2017 17:52:35 -0000 Rich asked to me to divide my comments into technical and editorial. = This are the same comment that I sent earlier with that categorization. Russ =3D =3D =3D =3D =3D =3D =3D =3D TECHNICAL In Section 5.1, I think it is desirable to add a requirement that the = ACME server SHOULD OCSP Staple. In Section 5.5, please add a MUST statement about the size of the nonce = value (before base64url encoding). In Section 6.1.1, how does the key-change entry in the table in section = 6.1.1 relate to the figure in Section 6.1? The other entries in this = table seem to have an obvious companion in the figure. I think the = figure should to show how the key-change is used update the acct. Section 6.1.1 says: "caa-identities" (optional, array of string): Each string MUST be a lowercase hostname ... How are IDNs handled? Are all U-labels converted to A-labels? Section 6.1.3 says: status (required, string): The status of this order. Possible values are: "pending", "processing", "valid", and "invalid". Should the list of possible status strings should also include = "expired"? If not, the text should say that the status will be set to = invalid if the authorizations are not accomplished before the expiration = time. Section 6.1.4 says: ... Servers MUST verify any identifier values that begin with the ASCII Compatible Encoding prefix "xn-" as defined in [RFC5890] are properly encoded. ... I think you want to require the A-labels to be converted to U-labels and = back again, and then reject the label if the converted A-label does not = match the original A-label. In Section 6.3.3, the list of steps clearly includes checking the = signature on the inner JWS in step 4, but I do not see a step that = checks the signature on the outer JWS. I think the both signature = checks need to be explicit in the steps. Is an additional subsection in Section 6.3 needed to deal with lost = account signature private keys? I assume that some out-of-band = mechanism would be needed to delete the account so that a new one can be = created. Section 6.4.2 says: The default format of the certificate is PEM (application/x-pem-file) as specified by [RFC7468]. ... The client may request other formats by including an Accept header in its request. For example, the client may use the media type application/pkix-cert to request the end- entity certificate in DER format. RFC 7468 defines the textual encoding for certificates, but it does not = define the application/x-pem-file media type. I cannot find a = registration for the application/x-pem-file media type. Also, please add a reference to RFC 2585; it specifies the = application/pkix-cert media type. In Section 8.2, I cannot understand the figure. Please correct it. EDITORIAL Please use the terminology from RFC 5280. Throughout the document: s/certificate authority/certification authority/ s/issuing authority/certificate issuer/ Also, please use the correct expansion for PKIX (PKI using X.509). In Section 1, please define ACME. Also in Section 1: s/Certificates in the Web PKI [RFC5280]/Certificates [RFC5280] in the = Web PKI/ In Section 5.2, please repeat the reference for the JWS specification at = the front of this section. Section 5.2 says: In the examples below, JWS objects are shown in the JSON or flattened JSON serialization, with the protected header and payload expressed as base64url(content) instead of the actual base64-encoded value, so that the content is readable. Some fields are omitted for brevity, marked with "...". The example is above this text (below), and there is no "..." in it. Section 6.1.1: s/function as both an ACME/functions as both an ACME/ Section 6.1.2: s/associated to an account/associated with an account/ Section 6.1.4 says: scope (optional, string): If this field is present, then it MUST contain a URI for an order resource, such that this authorization is only valid for that resource. If this field is absent, then the CA MUST consider this authorization valid for all orders until the authorization expires. [[ Open issue: More flexible scoping? ]] This scoping seems fine. Please remove the [[ question ]]. In Section 6.5, should the example use different challenges for = "http-01", "tls-sni-02", and "dns-01"? Section 7.2: s/in A and AAAA records/in the DNS A and AAAA resource = records/ Section 7.3: s\by an A/AAAA record\by the DNS A and AAAA resource = records\ Section 9.1: s/man in the middle/man-in-the-middle (MitM)/ Russ= From nobody Mon Feb 13 11:33:51 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74E8512986D for ; Mon, 13 Feb 2017 11:33:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.002 X-Spam-Level: X-Spam-Status: No, score=-7.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FHILZqleVswY for ; Mon, 13 Feb 2017 11:33:46 -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 7DD4B129871 for ; Mon, 13 Feb 2017 11:33:46 -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:MIME-Version:Date:Message-ID:Subject:From:To; bh=2OhB4ErceRLOFzN2aPvCdrujIaP9L9rRIvG2qst95kI=; b=UnFaOYQdmEhpC3Il3lfXHlu3gjz3q2yPWrkEO4hh0t11sqLwFYuLvqw0AhaZnh3r6z6HhuO2tpK7MSfGiay4LOgvaBRC23nr/hkEApHwvvzV+HxEptf2O67FT/DiTaCVfNJ7Aa4ogP/4fCqhaaELK/Hl5rVlQUKMRqdkhBFvmO4=; Received: ; Mon, 13 Feb 2017 11:33:48 -0800 To: "acme@ietf.org" , Martin Thomson From: Jacob Hoffman-Andrews Message-ID: <81377754-e24d-269d-0f48-ba37e55f8942@eff.org> Date: Mon, 13 Feb 2017 11:33:46 -0800 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: quoted-printable Received-SPF: skipped for local relay Archived-At: Subject: [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: Mon, 13 Feb 2017 19:33:49 -0000 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? PR to remove: https://github.com/ietf-wg-acme/acme/pull/244 From nobody Mon Feb 13 12:02: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 E2E791296D1 for ; Mon, 13 Feb 2017 12:02:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.002 X-Spam-Level: X-Spam-Status: No, score=-7.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KATAKS9zkexd for ; Mon, 13 Feb 2017 12:02:25 -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 DCC63124281 for ; Mon, 13 Feb 2017 12:02:25 -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:MIME-Version:Date:Message-ID:Subject:From:To; bh=Pxd/V+oTRMCbR5aUnD8acAmQkI0QCYWK4yCkPLp4JpU=; b=r1ysGCDSyw9+6fsvUBWOSxFimTVV6DcgPnDl57H/rtH4IbANcKthtrHV3h0stNoeWGVuSYBGTHRhBe0RQve7f83/QrFForMAm4GEt8ZAImVMxTFChFRfzST9rKwQqv7vv0NmRDyy018Ch94YnSXQMstth4pzXz2vPsjcxSoKhx0=; Received: ; Mon, 13 Feb 2017 12:02:26 -0800 To: "acme@ietf.org" , Russ Housley From: Jacob Hoffman-Andrews Message-ID: <8874ad56-e981-c514-88c6-a52d370144cd@eff.org> Date: Mon, 13 Feb 2017 12:02:24 -0800 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] Repeated tokens for different challenges in same authorization 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 Feb 2017 20:02:27 -0000 In the WGLC thread, Russ asked: > In Section 6.5, should the example use different challenges for "http-01", "tls-sni-02", and "dns-01"? (https://ietf-wg-acme.github.io/acme/#rfc.section.6.5) I assume you meant "token" here, and no, I think the token can be the same across multiple challenges for the same authorization. Boulder (Let's Encrypt's implementation) doesn't currently do this, but will in the future. If you think there's a risk in this, please let us know! From nobody Mon Feb 13 12:10: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 1904312986A for ; Mon, 13 Feb 2017 12:10:02 -0800 (PST) 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 Wc4xbRyQOP7z for ; Mon, 13 Feb 2017 12:10:00 -0800 (PST) Received: from mail-ot0-x22c.google.com (mail-ot0-x22c.google.com [IPv6:2607:f8b0:4003:c0f::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 ADF611297A7 for ; Mon, 13 Feb 2017 12:10:00 -0800 (PST) Received: by mail-ot0-x22c.google.com with SMTP id 32so77443355oth.3 for ; Mon, 13 Feb 2017 12:10:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=VJ8L6ZZh3NZedpPicTcq7FXrvUUJ3zFM1+Y6tSKZ5gM=; b=KeRQH6chRxBx9QiuF3z/sTACv8GQOBryNsg7qjMlbxeO11ehOQWWelXtUQ9z+DiHyy uUHYGYzsPSZA3Z7c7CAd6usqE1oOc5kOhQU/0LJup6aYR+gE8mmlEmiysCsiKGqMCvxQ k5sEy3RdGw8xzOkTL/NhH2BF+Pi2Xq1WfR88LwverkG44q2FIVmVzfjfJLNVg/Su9zqC rEr63Poogb/UmyFZs4AngTFib3ug1fS7B6n40MpIlAd44lMkIpdwQjSg11MLA3nHo8qb 88U+F6UlYAghS/10vC82IOMav6QVX32oXESU97tDD0gZq5cOvwVo9pa/xx6mLnoM0+hW K9Xg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=VJ8L6ZZh3NZedpPicTcq7FXrvUUJ3zFM1+Y6tSKZ5gM=; b=QoDl9xrvr2NhUDLcPTJG1bkoR088DK6AD07A9jYzM8veNopS6pgYF0qKICqN77UFLp 30/Q8wUKP/Lu2u54TMX0ITtMYO6wv2isAfh/H9Z0DhTp3lONHa4yKaKVQQn/E9TsSefm U7PZHqOsDsFhKDm5X+VWm+w7egxscjqOQwQ/ueNDZPBOFwc6aoQNwGcdpKSEKISTp/PK KYPADxWRUuY82ML/LWh3RLGUFIBk2sNT1hJgsGE11lh5KdUfw8aqte9RB9dT1kFKpg+z DUC5z0Ys1LB+V/V0mQ423fYYIhrcxlwYihTx7Cmehk2xtRov+DgvBcR6hgg/JqSDXJh8 PEDg== X-Gm-Message-State: AMke39lleMGSzzDnuaFo1itXth7jWoj+bKDWYDNUbR6snsUF4mCaC3sW3OQgCfrivnQOWaf0GqefCPesrvYA7g== X-Received: by 10.157.6.7 with SMTP id 7mr15044343otn.254.1487016600128; Mon, 13 Feb 2017 12:10:00 -0800 (PST) MIME-Version: 1.0 References: <81377754-e24d-269d-0f48-ba37e55f8942@eff.org> In-Reply-To: <81377754-e24d-269d-0f48-ba37e55f8942@eff.org> From: Clint Wilson Date: Mon, 13 Feb 2017 20:09:48 +0000 Message-ID: To: Jacob Hoffman-Andrews , "acme@ietf.org" , Martin Thomson Content-Type: multipart/alternative; boundary=94eb2c095f7a39e53805486f08e2 Archived-At: 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: Mon, 13 Feb 2017 20:10:02 -0000 --94eb2c095f7a39e53805486f08e2 Content-Type: text/plain; charset=UTF-8 I would definitely support removing ", and servers SHOULD emit pinning headers", especially because of the footgun risk you indicated, but I think there *is* some merit in continuing to recommend support for HPKP on the client side. On Mon, Feb 13, 2017 at 12:33 PM 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? > > PR to remove: https://github.com/ietf-wg-acme/acme/pull/244 > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > --94eb2c095f7a39e53805486f08e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I would definitely support removing ", and servers SH= OULD emit pinning headers", especially because of the footgun risk you= indicated, but I think there is some merit in continuing to recomme= nd support for HPKP on the client side.

On Mon, Feb 13, 2017 at 12:33 PM Jacob Hoffman-Andrews &l= t;jsha@eff.org> wrote:
Martin brought up a section I've been consid= ering removing:

> Clients SHOULD support HTTP public key pinning [RFC7469], and servers<= br class=3D"gmail_msg"> SHOULD emit pinning headers.

Here's my reasoning:

- Public key pinning isn't implemented in most HTTPS libraries outside<= br class=3D"gmail_msg"> 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?

PR to remove: https://github.com/ie= tf-wg-acme/acme/pull/244

_______________________________________________
Acme mailing list
Acme= @ietf.org
https://www.ietf.org/mailman/listinfo/= acme
--94eb2c095f7a39e53805486f08e2-- From nobody Mon Feb 13 12:19: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 381C11298A3 for ; Mon, 13 Feb 2017 12:19:05 -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, 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 PhySFdS04J-G for ; Mon, 13 Feb 2017 12:19:03 -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 7FA951296D1 for ; Mon, 13 Feb 2017 12:19:03 -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=TpDYH/09UayOVlV+sjXV+mysxfddGJ3vecETiK5F2JU=; b=KFA5zBJYT7Q0UVkjhVFsR3j3sN5zc3CLYGrDOtQJrgYzPb/uYjqUe3PxdwFLU/ctleU3U9DsiOoSLyJdjjVzP+6qwUMI6T5c/eYTJatKZTvl/7ADmAp/eUTA5E6v+1m4IgD1Oq6cn2wAV8BpuvV60nHw8aNlqXizChiAcrAo4+M=; Received: ; Mon, 13 Feb 2017 12:19:04 -0800 To: Anders Rundgren , Martin Thomson , "Salz, Rich" References: <8473d9ba84894d49b2f2232370d66b46@usma1ex-dag1mb3.msg.corp.akamai.com> <83f7104eef75470181d7f81fc7604a8e@usma1ex-dag1mb3.msg.corp.akamai.com> <0903e6e8-be00-b989-e388-cd811dd25ddf@gmail.com> From: Jacob Hoffman-Andrews Message-ID: <82dc202a-ed6b-3ded-d79f-e0339fff4226@eff.org> Date: Mon, 13 Feb 2017 12:19:02 -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: <0903e6e8-be00-b989-e388-cd811dd25ddf@gmail.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] 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 Feb 2017 20:19:05 -0000 On 02/12/2017 10:09 PM, Anders Rundgren wrote: > JWS is great for what is was originally designed for. ES6 normalization > nullifies the need for dressing JSON data in Base64Url. Could you clarify this comment? Are you proposing that ACME should not wrap internal fields in another layer of base64url? Or that the JWS spec should be revised to not wrap payloads in base64url? From nobody Mon Feb 13 12:20: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 9701F1298BD for ; Mon, 13 Feb 2017 12:20:08 -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 RTC7Uq7SsYBV for ; Mon, 13 Feb 2017 12:20:07 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A6B5129869 for ; Mon, 13 Feb 2017 12:20:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id DCA64300436 for ; Mon, 13 Feb 2017 15:20:06 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id GCHtyS3KXFOA for ; Mon, 13 Feb 2017 15:20:05 -0500 (EST) Received: from [64.170.98.129] (unknown [64.170.98.129]) by mail.smeinc.net (Postfix) with ESMTPSA id 73DEB30024D; Mon, 13 Feb 2017 15:20:05 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Russ Housley In-Reply-To: <8874ad56-e981-c514-88c6-a52d370144cd@eff.org> Date: Mon, 13 Feb 2017 15:20:01 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8874ad56-e981-c514-88c6-a52d370144cd@eff.org> To: Jacob Hoffman-Andrews X-Mailer: Apple Mail (2.3259) Archived-At: Cc: IETF ACME Subject: Re: [Acme] Repeated tokens for different challenges in same authorization 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 Feb 2017 20:20:08 -0000 > In the WGLC thread, Russ asked: >=20 >> In Section 6.5, should the example use different challenges for = "http-01", "tls-sni-02", and "dns-01"? > (https://ietf-wg-acme.github.io/acme/#rfc.section.6.5) >=20 > I assume you meant "token" here, and no, I think the token can be the = same across multiple challenges for the same authorization. Boulder = (Let's Encrypt's implementation) doesn't currently do this, but will in = the future. If you think there's a risk in this, please let us know! I do not think it is a risk with the authorizations that have been = defined. I was wondering about a situation where a client make a = mistake. If a client tries to fulfill one of the authorizations and for = some reason is unable to do so completely, and then moves to another = authorization, can the half-done first authorization cause a problem. Russ= From nobody Mon Feb 13 12:24: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 197911298C2 for ; Mon, 13 Feb 2017 12:24:09 -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, 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 iojHOv7_c_U4 for ; Mon, 13 Feb 2017 12:24:08 -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 33C671298B5 for ; Mon, 13 Feb 2017 12:24:08 -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=BZMGO9Vcj2HRkplqChCx8CH2lQkBR5182+EhADcn0i8=; b=mzQLBc7Q4QDO2JxeuvXgaBSTG+imOoz3Y6OwVXuu6r+lSArMl89gmieNcVSn4VrvXYKNRHDHSwkYFjNNUVxctnue/xLw8GowO8HbyjePm6eWXOvN+6neRFWbdEDk+Y3fV0igq0rxqsD+jyrzMF/y9ybfKhQDwPzMVUoerVpWhoE=; Received: ; Mon, 13 Feb 2017 12:24:09 -0800 To: Russ Housley References: <8874ad56-e981-c514-88c6-a52d370144cd@eff.org> From: Jacob Hoffman-Andrews Message-ID: <26130180-d8bb-3ca6-5618-d7fb1d4216be@eff.org> Date: Mon, 13 Feb 2017 12:24:07 -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: IETF ACME Subject: Re: [Acme] Repeated tokens for different challenges in same authorization 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 Feb 2017 20:24:09 -0000 On 02/13/2017 12:20 PM, Russ Housley wrote: > I do not think it is a risk with the authorizations that have been > defined. I was wondering about a situation where a client make a > mistake. If a client tries to fulfill one of the authorizations and > for some reason is unable to do so completely, and then moves to > another authorization, can the half-done first authorization cause a > problem. Duplicate tokens across authorizations (not within authorizations) might cause some minor issues. For instance, the token is used to identify a resource being requested, so in the http-01 challenge a client might find itself trying to write the same content to the same filename as second time. From nobody Mon Feb 13 12:34: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 EA80D12940F for ; Mon, 13 Feb 2017 12:34:42 -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, 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 ohxKCtzPaZ4R for ; Mon, 13 Feb 2017 12:34:41 -0800 (PST) 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 45FED129585 for ; Mon, 13 Feb 2017 12:29:25 -0800 (PST) Received: from host249.freudenhaus.alandoherty.net ([193.120.128.249]:3254 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 1cdNAu-0004fm-Pz ; Mon, 13 Feb 2017 20:24:42 +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: Mon, 13 Feb 2017 20:29:10 +0000 To: Clint Wilson , Jacob Hoffman-Andrews ,"acme@ietf.org" , Martin Thomson From: Alan Doherty In-Reply-To: References: <81377754-e24d-269d-0f48-ba37e55f8942@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] 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: Mon, 13 Feb 2017 20:34:43 -0000 I would concur that clients should endeavour to support (and thusly CAs can consider using in future, when support is available in wider librarys) but because of the risks they should only consider doing so if/when all their processes are in place to ensure failures can't occur but how best to word that i don't know At 20:09 13/02/2017 Monday, Clint Wilson wrote: >I would definitely support removing ", and servers SHOULD emit pinning headers", especially because of the footgun risk you indicated, but I think there is some merit in continuing to recommend support for HPKP on the client side. > >On Mon, Feb 13, 2017 at 12:33 PM Jacob Hoffman-Andrews <jsha@eff.org> 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? > >PR to remove: https://github.com/ietf-wg-acme/acme/pull/244 > >_______________________________________________ >Acme mailing list >Acme@ietf.org >https://www.ietf.org/mailman/listinfo/acme > >_______________________________________________ >Acme mailing list >Acme@ietf.org >https://www.ietf.org/mailman/listinfo/acme From nobody Mon Feb 13 12:56: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 3B559129485 for ; Mon, 13 Feb 2017 12:56:42 -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 TflSkV-7S26y for ; Mon, 13 Feb 2017 12:56:40 -0800 (PST) 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 53B8F1293EC for ; Mon, 13 Feb 2017 12:56:40 -0800 (PST) Received: by mail-wm0-x233.google.com with SMTP id v77so1597404wmv.0 for ; Mon, 13 Feb 2017 12:56:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=76zdEgQsK6eML4RUfXGnz+3a9A0sJ1+yi+HXCksVNpc=; b=K2UjVi+WoyvxURjHlDfeFfbFu+FZEITlhJP+XV0NEyMhKD1Fr5cOWL4mMuohmSHyWr JV07V0yW8tRpWX6nBo2idlp45yHZ6Wl0Zfy4O0fQu85Okx+70C2mhmFY/eORplApZxC5 8JYjG0Ct1L3NNPBFMlBd3e/9loLmCT7BZr+lwITo+5zgYgCK0weayIM/SecggnjfQBEh SJerutBBCYyA75ClwqD6YMUTgjkjLnqHe3qfGeoisFeDgEfjQPjACRpN6o2uWvQeg/bD PSpJmOmgzytmtga+kzA7klRdONCj9x4j46Ge0gLQL6Kca35AclMMQHD3GMpBWCJBbCA8 0q9A== 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=76zdEgQsK6eML4RUfXGnz+3a9A0sJ1+yi+HXCksVNpc=; b=qmbWhHu1Mi1Hg/NjmC1yekL0mIeirqt65VWCL9vmn7X33lBqtSmbq3yZn0x8FnEuj+ kGChPcM4ttnNHMN2F3NEQrkevMy1nyPSJ2tF3js3TRSwAuwRiwoQOQDwN8QWOOev7e5H Hylx4huLuU3ofsbFQ99Owd0mqWRTMC1OHGUqwFJZiZV2oyxZOYYBJxW3iRSJn77Y9kqP y1TQ7WSyPzzYvQuhghrJeZ/2qq03SZJstDi0ZyNgw0dMP5cyypx4nt1wda6v9oPWPQrF 10VK/RUn7FHAJJBp6kIn/jXUFYb08B2tYxchkQ+HR6ccsOLluXT+V9N5XUheVjOIGET3 jOQA== X-Gm-Message-State: AMke39mhnwniD+bPOYimww0DOgeQCdx1gjN4SHn1UPDbwrHuhb0j4KbxMhGbsjZr4356kA== X-Received: by 10.28.68.10 with SMTP id r10mr239482wma.68.1487019398825; Mon, 13 Feb 2017 12:56:38 -0800 (PST) Received: from [192.168.1.79] (124.25.176.95.rev.sfr.net. [95.176.25.124]) by smtp.googlemail.com with ESMTPSA id u189sm762876wmu.1.2017.02.13.12.56.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Feb 2017 12:56:38 -0800 (PST) To: Jacob Hoffman-Andrews , Martin Thomson , "Salz, Rich" References: <8473d9ba84894d49b2f2232370d66b46@usma1ex-dag1mb3.msg.corp.akamai.com> <83f7104eef75470181d7f81fc7604a8e@usma1ex-dag1mb3.msg.corp.akamai.com> <0903e6e8-be00-b989-e388-cd811dd25ddf@gmail.com> <82dc202a-ed6b-3ded-d79f-e0339fff4226@eff.org> From: Anders Rundgren Message-ID: Date: Mon, 13 Feb 2017 21:56:15 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <82dc202a-ed6b-3ded-d79f-e0339fff4226@eff.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "acme@ietf.org" 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 Feb 2017 20:56:42 -0000 On 2017-02-13 21:19, Jacob Hoffman-Andrews wrote: > On 02/12/2017 10:09 PM, Anders Rundgren wrote: >> JWS is great for what is was originally designed for. ES6 normalization >> nullifies the need for dressing JSON data in Base64Url. > Could you clarify this comment? Are you proposing that ACME should not > wrap internal fields in another layer of base64url? Or that the JWS spec > should be revised to not wrap payloads in base64url? Well, it is too late to change now but I proposed this more than a year back. Martin's comment is exactly what I expected to happen when using JWS. Hopefully there won't be that many new protocols using such measures. ES6 serialization works, it is a standard, and it is implemented in the most widespread JSON tools available (browsers). JWS will probably not be revised because JWS signs "data". What I'm advocating are JSON/JavaScript objects optionally holding an enveloped signature which is a rather different animal: Using JWS: { "mydoc": { human-unreadable Base64Url-encoded signature container. } } Note: "mydoc" is not signed. Using an enveloped signature: { "mydoc": ..., "someotherprop" : ..., "signature": { ... } } Anders From nobody Mon Feb 13 13:51: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 47D5012998B for ; Mon, 13 Feb 2017 13:51:18 -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, 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 tUKAfpASffk1 for ; Mon, 13 Feb 2017 13:51:16 -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 ABC79129984 for ; Mon, 13 Feb 2017 13:51:16 -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:MIME-Version:Date:Message-ID:Subject:From:To; bh=X1SpbLCQ+AlTMGSsTVninaOv7qSjalVkK+CtMh/r6VA=; b=xZyZ+zf3PnAD83WGhTiDhWtWfB2G3rXbbJtBO1g3TqS2w1G9fTtiRIkO/501leZvt6CTbbFfEahaJxEZfQtvfaWSU5gPI650hyS7FoL1TzVjp/j2NfjLOKjdvqTWw2QCs6NuxH2XW1uLLVF/6qM9Hn93b5IJEdxyVgce7sWKXLE=; Received: ; Mon, 13 Feb 2017 13:51:18 -0800 To: "acme@ietf.org" From: Jacob Hoffman-Andrews Message-ID: <9baa4aca-120c-4ce8-b118-68dca3917f57@eff.org> Date: Mon, 13 Feb 2017 13:51:16 -0800 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] 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: Mon, 13 Feb 2017 21:51:18 -0000 >From the WGLC thread, Russ Housley said: > Section 6.4.2 says: > The default format of the certificate is PEM (application/x-pem-file) > as specified by [RFC7468]. ... The client may request other formats by > including an Accept header in its request. For example, the client > may use the media type application/pkix-cert to request the end- > entity certificate in DER format. > > RFC 7468 defines the textual encoding for certificates, but it does not define the application/x-pem-file media type. I cannot find a registration for the application/x-pem-file media type. This is a good point. Should we register x-pem-file as part of this RFC? Or come up with a new, more specific media type, like application/pem-certificate-chain? From nobody Mon Feb 13 14:03: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 E042312940D for ; Mon, 13 Feb 2017 14:02:58 -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 gsOCpvr6gmBc for ; Mon, 13 Feb 2017 14:02:57 -0800 (PST) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::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 EB86E1297EC for ; Mon, 13 Feb 2017 14:02:56 -0800 (PST) Received: by mail-qt0-x233.google.com with SMTP id v23so96061182qtb.0 for ; Mon, 13 Feb 2017 14:02:56 -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=o10uJniUERPeGkOhATXwv4RRaq2O/Zf2oXjpyb5i63w=; b=oPduYFFxYQ7FS8iqeIi0BK+NQRsgK2WMevEwIlIhbGAYS3XG0zMNOYrIjGU2tr/X0h C5oXSqlWuEnx/0O1DCbC0T0kdjcuKUbIbdbzTj99vscBC35jl997dB4LOIpbTv+vgyYq vkMBg7OXFnptefxLGwEM8tgCHi2vXMbY7oXWYgjV684/e7cfnah4JfLNzY+2P8b2QQzo uRN5xJ+9G9cPBgWuBnaFFZ1VkQzuYOdiH9WlVgJQSi1rmih2bTVd7cwKe+qY0EHfmRID BtDcEc7/xJHilD/YCzhkYkLXvtnHMTPfqHc7DIOGm+DmQoUNxClg4Vpf+flCgXGRWvPd Zp3Q== 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=o10uJniUERPeGkOhATXwv4RRaq2O/Zf2oXjpyb5i63w=; b=REHj3DdMkkl6r6VmDSSiPoyczmleASpqleHpLZVji2zLMHSyYrx+zm4vu/e60Yfa0N sIiEDO99pn8vw3M5iw4aqEqv/7/6WuUOViGhShR5J/nShtLn1dEJ2GFUHMLtYeR8ysAE beuPcdJozEMOlFCKzjWl96gIxB3J2h4zFtAzMdmFWHuCWiSIJL27WInuIYqfG9JZQgGW sBIezcZVKRyiZ+ltFpsl7PvSTaLtB+xwnuBi4BjEXuMVJBR4mVFkBT/usN4Un4/Qyspl +oGWaAFtJMObeBJ9qzh75ap+Lks272qLJrm+sMxJSeLk55bXI/o8Z3r3aU3m7tjPyfmP hBIQ== X-Gm-Message-State: AMke39mk+8prWBx5hZIChTukpFCymaIr9/HPUqQk/ackhO/1r3Hb7yL2mIwjQ5Uv9RQY3KJ5RMjEQiZNN7VWkQ== X-Received: by 10.200.57.199 with SMTP id v65mr23502538qte.13.1487023375816; Mon, 13 Feb 2017 14:02:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Mon, 13 Feb 2017 14:02:55 -0800 (PST) From: Martin Thomson Date: Tue, 14 Feb 2017 09:02:55 +1100 Message-ID: To: "acme@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [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, 13 Feb 2017 22:02:59 -0000 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? 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. 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. 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). 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. 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. 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. 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? 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? S9.3 You should also recommend rate limits on account creation, or your other mitigations might be weakened. S9.4 Does an ACME server send Referer[sic]? What should it set it to? 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? From nobody Mon Feb 13 15:35: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 72106129442 for ; Mon, 13 Feb 2017 15:35:51 -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, 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 mM3caUjp6t28 for ; Mon, 13 Feb 2017 15:35:49 -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 4B43912941C for ; Mon, 13 Feb 2017 15:35:49 -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:MIME-Version:Date:Message-ID:Subject:From:To; bh=q58XGAdCB1XL1YuxkFyHqWZiLBuQjTgItc9SXJku4g8=; b=gmfGsOYnCqXZ2uqBSt8ETdmvI3+hGrz28heccb0Viy42ToEXDK+BbDIIHWpBpXGOF/zQvjI1WA6c1MPitpOGg4sBPnrDz9XqaeJZfROE286yL/hMOMLk48eSN90+cic9yj7G/+Qa4chcXGr/ZcEh/st0Q8pncVX9c3H1kZbbb5U=; Received: ; Mon, 13 Feb 2017 15:35:50 -0800 To: "acme@ietf.org" From: Jacob Hoffman-Andrews Message-ID: <56a4a78d-92b5-55da-f5f0-35933e4d6758@eff.org> Date: Mon, 13 Feb 2017 15:35:49 -0800 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: quoted-printable Received-SPF: skipped for local relay Archived-At: Subject: [Acme] What do do on account deactivation 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 Feb 2017 23:35:51 -0000 On 02/13/2017 02:02 PM, Martin Thomson wrote: > 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. I agree. Let's change this to "server MUST NOT revoke certificates in response to an account deactivation request," and delete the other part "it is up to server policy to ..." because that is true by default. From nobody Mon Feb 13 17:49: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 8D131120726 for ; Mon, 13 Feb 2017 17:49:44 -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, 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 H9x0v0f9x7ED for ; Mon, 13 Feb 2017 17:49:42 -0800 (PST) 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 A42A2129A05 for ; Mon, 13 Feb 2017 17:49:42 -0800 (PST) Received: by mail-it0-x230.google.com with SMTP id c7so13052904itd.1 for ; Mon, 13 Feb 2017 17:49:42 -0800 (PST) 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=9uv/aoqClqUJ7FUCr89m0q/obU7Zd5RL7Sd5mEYqnGE=; b=P3IxqvRLHuOzFbUXqA+Ndm8fCUI2oSpKwcQtEkirHQGyMtQaQrJYUtcmrlbs3X+m/o 84hqEKtOktnJrZrB25DINtJF5yjUVq+mnpctnaIP82xtZiVcw7dLxJ7u/BPeKCnOKAs9 i9k2B9Jrj274ZD7WMYaWmPWPHvR2Gu5x4iR8A= 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=9uv/aoqClqUJ7FUCr89m0q/obU7Zd5RL7Sd5mEYqnGE=; b=BpRcIfR9mm/gnx9okQ847Xbh0Cb4A6CZh3s58/XkSyIO9h3LPlO6ZsghxqVbGmyufN 6PGis7Q++L4z9BQ3I+iT229o9cO+206BMqFbGiQa4bwBAhs1m5SUlwxPo/CIKCgPkAsf e1qlJRICfVRxQChLbcyer5OCUmfz7RCwDPVwcvz7tt8pL8rNkMTlKMS+Wij4P7iQJxq2 jeiLim0st5aY7gf8Q3txHlE/LES9KoF6diyliuOOVZ1Sq9ycRkjyD7O417phjartJs7y XqsYJjgUr88AZzI/p4igZ/WW+nG4iE6KyW4RxjPzw7dhbI27UGVdylDtiMxH70SPBSZ+ ML4Q== X-Gm-Message-State: AMke39mzHLeF6BDmokxrLOQuMlJ4ucPf+qThSnvlDbVehhOMQLnG4Cus1P0/qx/wbug4Zg6h X-Received: by 10.84.217.65 with SMTP id e1mr31344669plj.40.1487036981486; Mon, 13 Feb 2017 17:49:41 -0800 (PST) Received: from [10.120.0.195] (eff.static.monkeybrains.net. [208.90.213.162]) by smtp.gmail.com with ESMTPSA id n70sm23122710pfg.34.2017.02.13.17.49.40 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Feb 2017 17:49:41 -0800 (PST) To: "acme@ietf.org" From: Roland Shoemaker Message-ID: <21c78847-c99a-70d4-2296-c065c68c16d6@letsencrypt.org> Date: Mon, 13 Feb 2017 17:49:40 -0800 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] Removing extraneous link relations 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 Feb 2017 01:49:45 -0000 I propose we remove the 'author', 'revoke', and 'ct-sct' link relations. 'author' seems to provide no concrete value, and 'revoke' is already provided by the 'directory' endpoint. The 'ct-sct' relation is also somewhat pointless as the SCT will be provided by the CA via the certificate or a OCSP response, if it doesn't provide either of these then the client should be able to retrieve the SCT itself from the logs it expects to find the certificate in. I also agree with Martin's suggestion that we replace the 'directory' link relation with 'index' as it is already registered and means basically what we intend. PR making these changes: https://github.com/ietf-wg-acme/acme/pull/250 -- Roland Bracewell Shoemaker Software Engineer Linux Foundation / Internet Security Research Group From nobody Mon Feb 13 19:21: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 522BB1294BB for ; Mon, 13 Feb 2017 19:21:34 -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, 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 WnUDZdvnhCal for ; Mon, 13 Feb 2017 19:21:33 -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 24479129463 for ; Mon, 13 Feb 2017 19:21:32 -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:References:To:Subject; bh=i0rbuoTqTVMaFQ3zQNCfPV809/DvZ4iHrBkuUkZj3/U=; b=AmjdoCv2flMj5KaUenDFF6ByJ4vC1tkRDYMq5R1TDT7rkjKC7DxHW497lWTOvhsgdIwTFDpQYmlTC/nnzO6t2YDedZVHd0Gm/X52rpbldbaE51rLKBqzz6ahJ/SpZF1CvRuJsxsw0XfaCz2f90p2CVLlwDKgUazmKkSgu9sArqw=; Received: ; Mon, 13 Feb 2017 19:21:32 -0800 To: Roland Shoemaker , "acme@ietf.org" References: <21c78847-c99a-70d4-2296-c065c68c16d6@letsencrypt.org> From: Jacob Hoffman-Andrews Message-ID: <57108f64-e3f6-dca6-e506-35d7513b4123@eff.org> Date: Mon, 13 Feb 2017 19:21:30 -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: <21c78847-c99a-70d4-2296-c065c68c16d6@letsencrypt.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Received-SPF: skipped for local relay Archived-At: Subject: Re: [Acme] Removing extraneous link relations 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 Feb 2017 03:21:34 -0000 This all looks good to me. On 02/13/2017 05:49 PM, Roland Shoemaker wrote: > I propose we remove the 'author', 'revoke', and 'ct-sct' link relations. > 'author' seems to provide no concrete value, and 'revoke' is already > provided by the 'directory' endpoint. The 'ct-sct' relation is also > somewhat pointless as the SCT will be provided by the CA via the > certificate or a OCSP response, if it doesn't provide either of these > then the client should be able to retrieve the SCT itself from the logs > it expects to find the certificate in. > > I also agree with Martin's suggestion that we replace the 'directory' > link relation with 'index' as it is already registered and means > basically what we intend. > > PR making these changes: https://github.com/ietf-wg-acme/acme/pull/250 > From nobody Tue Feb 14 14: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 B4FB8129968 for ; Tue, 14 Feb 2017 14:53:18 -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, 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 XxAyr7SrWUXu for ; Tue, 14 Feb 2017 14:53:17 -0800 (PST) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC5B3129965 for ; Tue, 14 Feb 2017 14:53:16 -0800 (PST) Received: by mail-it0-x229.google.com with SMTP id x75so53044582itb.0 for ; Tue, 14 Feb 2017 14:53:16 -0800 (PST) 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=gU9sF9JMRslORdiZC6DnygG0wMUJMD5iWS6o5MQyubg=; b=HTpEku6dVeFAJ1LKMCfT6deBWwC5xQZKCWi8TENztnBRF0yFfPFH7DZBvMMIsKwMc6 kd5YFZHIPD8G83MT/j+c5jTLkwe4gx2qkXVr25jf11ETlNfF6lfXX/ucdTB1t6qSRdJi XLbZkDAob9zDwfZ0iGANQXcntS0wZ79keS54k= 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=gU9sF9JMRslORdiZC6DnygG0wMUJMD5iWS6o5MQyubg=; b=gP9Mw5rnL1lCFfpg6q2KpJOKcoiDD+J4ij5/ntB9zN/xkb/Ns5ELei1SIKr0f0vUvJ K+86ik7jiTxXU9C5+rSa+cFXKkSDMuVPpdT1nMcXB6X8dFu9J01bAdkQyrCJHuGeQb/E jsu0AzKnggWE29nWkV+lpahYP2dN0fL0mx0KmjJn2OSiQ33ZgVHxuN1QCI0XTLZ1ouWG WC7R0CVlBiLD9s4ULxtGUHEWhk8Ejn9Qfcr5hjCNiho14Y+8s94IbUfses5FA+fFgNtB N01JamCxXiKpGrBu7MhKJRAx1IGyZwL7o82+vSbTMsdqLlh7x7krZ6icFV/PQFCzs0dZ 604Q== X-Gm-Message-State: AMke39moF7FMbQtRDjkadcKp4bRwmov5MywZ15t+l1eEO26vBNoBLIDLfjOOI0YZy5YQXU4n X-Received: by 10.84.229.76 with SMTP id d12mr38138409pln.21.1487112795957; Tue, 14 Feb 2017 14:53:15 -0800 (PST) Received: from [192.168.42.66] ([50.1.57.147]) by smtp.gmail.com with ESMTPSA id u82sm3207976pfd.7.2017.02.14.14.53.14 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Feb 2017 14:53:15 -0800 (PST) To: "acme@ietf.org" From: Roland Bracewell Shoemaker Message-ID: Date: Tue, 14 Feb 2017 14:53:12 -0800 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 Archived-At: Subject: [Acme] Clarifying what to do with revocation requests with disallowed reasonCodes 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 Feb 2017 22:53:19 -0000 The current draft leaves it ambiguous as to what the server should do when a it receives a revocation request containing a reasonCode that it disallows. I suggest we add a simple 'MUST reject request' clause to the relevant section to resolve this ambiguity. PR: https://github.com/ietf-wg-acme/acme/pull/251 From nobody Tue Feb 14 15:39: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 7AD8312995C for ; Tue, 14 Feb 2017 15:39:41 -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 kN7pZMJgmujV for ; Tue, 14 Feb 2017 15:39:40 -0800 (PST) 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 21B511294DC for ; Tue, 14 Feb 2017 15:39:40 -0800 (PST) Received: by mail-wm0-x22c.google.com with SMTP id 196so17079989wmm.1 for ; Tue, 14 Feb 2017 15:39:40 -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=3Fdju8KOrt8UiEVo4CZPxknG5sNBvOMJUOgdLqSXbfg=; b=ir53Ga56U3YoZ0fnJ4a2gtgl7GLoxIkXOpBRHcIg+3XXCCgEYs8Ha7bBwJaIQnWKkl pHDZzWfANgbgkL9JG+O0+1FsEpJcrnuyw8fIUZELWS/qpj0W77IZ4uXbBHT90y2jGSHw VdPOnhPh+HBZDI1YwPR005xPu9GmaBH6RBSQdv6aucXZDY4TvfJ3h+Ufn8gj8oZh3Otd W9x2CNGv+1CT6Tq9a6XNd4RQx6Ko5RDOy+jPEdYjafW/g7epcJAGtMM1bDvnlulL426y smCk/tEod/2hEwBxgJJA25JkD3ojxJW+jyAO228drrz6uv6IJ7XEyXum4Z6eahrUlq0l 2nEw== 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=3Fdju8KOrt8UiEVo4CZPxknG5sNBvOMJUOgdLqSXbfg=; b=s0sjancYDrN38CYy/ehh6+E4z3m3J/aE6YQG0U9RR+kuDxlB2kLlZl6Fo4OsH43/SY +caWTIe+R0ERM+qVwazwhPiOqarfLxuCj/pEKpFzfXGs9/q5Givr8PzFYz1PNArCfzfi CywOTgUwVrCi9K6aNAG668FQTsokS6trKNTu/ethCfEUM0PGErRHmHlrB/p8Uq2NXk0K D8G5Hyjj3v6XJp1MnrkTvnYrirA0/LORo0r5dh2oPrc0eeFFvTq2pUJCkKlOUp+2J8zj OH2noYpItNahrFmmCTLr4U4liyQLeIM1QS7bBUEazU2xOyhA1Qw/Ckst2puRmLGYy2y6 3QxQ== X-Gm-Message-State: AMke39mhWhBAupkrtfSsonVgXmGWhq4c61GAVVLYNhmJ86Acd8yWfZky7uXyxdC3KxnQ3ykZgt848leQzLBA1Q== X-Received: by 10.28.18.134 with SMTP id 128mr5226579wms.53.1487115578342; Tue, 14 Feb 2017 15:39:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.130.67 with HTTP; Tue, 14 Feb 2017 15:39:37 -0800 (PST) From: Logan Widick Date: Tue, 14 Feb 2017 17:39:37 -0600 Message-ID: To: acme@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Acme] JWS serialization 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 Feb 2017 23:39:41 -0000 All, Which JWS serialization is to be used when implementing? The document indicates that the examples are in either flattened JSON or general JSON serializations for readability. But which serialization must be used for the actual implementations? Sincerely, Logan Widick From nobody Tue Feb 14 16:02: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 9FDB9129992 for ; Tue, 14 Feb 2017 16:02:37 -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, 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 NCnJ6qcI-M7o for ; Tue, 14 Feb 2017 16:02:35 -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 B657412998B for ; Tue, 14 Feb 2017 16:02:35 -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:References:To:Subject; bh=PjO5Drb2H25Ilx5gPAtb+NAyVxeUV0nKConLvGPVM88=; b=EhFg6R8c1ohCkNIlykR7L08kE20b+WjTjLxzFFbVq9QyG+emtfw9XUnLK2hoZwtdeh9LqYcQrBtifbLqDIqNjqHY1CwDV116JHk4pbkxmuzn6qDIkgwL/Mx81U/P6YaMOxz/kwvmKsgvVgdMOFyWftaVpOZ6v3W+VVDXP4bIw2c=; Received: ; Tue, 14 Feb 2017 16:02:37 -0800 To: Logan Widick , acme@ietf.org References: From: Jacob Hoffman-Andrews Message-ID: <45e74698-3392-54e7-8412-d2713435cfc3@eff.org> Date: Tue, 14 Feb 2017 16:02:35 -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: Subject: Re: [Acme] JWS serialization 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, 15 Feb 2017 00:02:37 -0000 Flattened JSON, IMO. And I think we should standardize on that single representation. On 02/14/2017 03:39 PM, Logan Widick wrote: > All, > > Which JWS serialization is to be used when implementing? The document > indicates that the examples are in either flattened JSON or general > JSON serializations for readability. But which serialization must be > used for the actual implementations? > > Sincerely, > > Logan Widick > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > From nobody Wed Feb 15 18:38:34 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3971129C5F for ; Wed, 15 Feb 2017 18:38:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_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 SM1G49aue_kv for ; Wed, 15 Feb 2017 18:38:31 -0800 (PST) Received: from captainmorgan.hollandpark.frase.id.au (110-174-235-130.static.tpgi.com.au [110.174.235.130]) (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 E0403129C5D for ; Wed, 15 Feb 2017 18:38:30 -0800 (PST) Received: from bacardi.hollandpark.frase.id.au (bacardi.hollandpark.frase.id.au [192.168.0.100]) by captainmorgan.hollandpark.frase.id.au (8.15.2/8.15.2) with ESMTPS id v1G2c4ZG042293 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 16 Feb 2017 02:38:06 GMT (envelope-from frase@frase.id.au) Received: from bacardi.hollandpark.frase.id.au (localhost [127.0.0.1]) by bacardi.hollandpark.frase.id.au (8.15.2/8.15.2) with ESMTPS id v1G2c4So022406 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 16 Feb 2017 12:38:04 +1000 (EST) (envelope-from frase@frase.id.au) Received: (from fraser@localhost) by bacardi.hollandpark.frase.id.au (8.15.2/8.15.2/Submit) id v1G2c2ev022405; Thu, 16 Feb 2017 12:38:02 +1000 (EST) (envelope-from frase@frase.id.au) X-Authentication-Warning: bacardi.hollandpark.frase.id.au: fraser set sender to frase@frase.id.au using -f Date: Thu, 16 Feb 2017 12:38:02 +1000 From: Fraser Tweedale To: Jacob Hoffman-Andrews Message-ID: <20170216023801.GU6258@bacardi.hollandpark.frase.id.au> References: <45e74698-3392-54e7-8412-d2713435cfc3@eff.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="hSsVBZHIO2Q9XETc" Content-Disposition: inline In-Reply-To: <45e74698-3392-54e7-8412-d2713435cfc3@eff.org> User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Cc: Logan Widick , acme@ietf.org Subject: Re: [Acme] JWS serialization 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: Thu, 16 Feb 2017 02:38:33 -0000 --hSsVBZHIO2Q9XETc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 14, 2017 at 04:02:35PM -0800, Jacob Hoffman-Andrews wrote: > Flattened JSON, IMO. And I think we should standardize on that single > representation. >=20 I think we should not specify only that a JSON serialisation be used. We SHOULD NOT specify that flattened must be used. Many JOSE libraries do not care and will decode either JSON representation as long as it is valid. Many JOSE libraries would not even provide a knob to tell it to admit only the flattened serialisation (or vice versa). If the intent is to require that exactly one signature is used, then just say that. Thanks, Fraser > On 02/14/2017 03:39 PM, Logan Widick wrote: > > All, > > > > Which JWS serialization is to be used when implementing? The document > > indicates that the examples are in either flattened JSON or general > > JSON serializations for readability. But which serialization must be > > used for the actual implementations? > > > > Sincerely, > > > > Logan Widick > > > > _______________________________________________ > > Acme mailing list > > Acme@ietf.org > > https://www.ietf.org/mailman/listinfo/acme > > >=20 > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme --hSsVBZHIO2Q9XETc Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEWEjOKBhrtGnClRXhS1OQUkER4eIFAlilEIYACgkQS1OQUkER 4eLiPQ//Up4TFQoO+7V3cLc/GYWNi/wT+pSFixlbjzoptzHQNMyiif28p8S85pTL npntBz3auSpbdN9XdndA84HgLOWjrdPmic08P4n5fAi07+CJREnE8F2IkUMBJqn8 B3rnP6hiMSBp+OYha51WsJrWlEXTrUuSEinVsYueBQdLw+kmY09WhAU+FV7XmKNM y+ebARM3zpIMWlQgP/lV6rK+WG2Y6y95WOoHWzOhJGvrM1TMvbcpJxUK57Pbr0FQ gwpMgA4EjkgqzMtD1YXHTVPvF4qkt+KskSLEETMfJIkfTd+qmFZ8L7cAymjCj85Y dEwDaH3z6ECKJGP7V+5RJX5FLlYF9l4Yo9oc17UGc5Tlf+Ty9J7x0dgyk6QjaY+M RntXZ7cK2/sUWw5h1A9qfXdIHFPFoMhjO+75hpiOZ0xWL9xU3YSzSc4EQMykevSU aubgMBjaBhAfUTKSQviBSuhvfc7E0t92AjmnVX6QJnPqcY80b0bDUCIUjVLvBmin xqkhtENzV/qfvLbus7Z04+GrIppQgHAqMX85foI5te7T4Jr/83EdF3wBTNyFTyqM JOzKjuOtgYpeEJXNuSLvU/6w18B+b49BOjRsIbT2XEFBaY51eg5jR4YbqGdUZPH4 sLMaiKd+rnZHjDW33aflirvxd7H6Qgd5ld/Sg1lDkY6kdFQ6qd4= =pPqI -----END PGP SIGNATURE----- --hSsVBZHIO2Q9XETc-- From nobody Wed Feb 15 21:04: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 4FC4B1294BB for ; Wed, 15 Feb 2017 21:04:16 -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, 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 SFl01_1tYm9I for ; Wed, 15 Feb 2017 21:04:14 -0800 (PST) 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 4DFC912996F for ; Wed, 15 Feb 2017 21:04:14 -0800 (PST) Received: by mail-wm0-x234.google.com with SMTP id v186so57501195wmd.0 for ; Wed, 15 Feb 2017 21:04:14 -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=4QuXeh5wzRjLRZwHdBaHqqYubTbi/ZFFR9kUacxTZWo=; b=emTriLEyYIYRo+lx3oy7KJwjZZu5mMDsjOsW9tPwAsMYDSN1xxnqDD0gWM4sZ62DdI QZx0qR2XcNTBk6l9gUz90t9MIo73xIZLFCWwQoDpGJCNxQUmFJoPi97SjlbFNH54yroW wggkROnPxTinEJlpGjUZOjEk9I7HdAe9LSQTK1HPOJof5bklSm/wuiwRP60du5T/j4wT jzIAlbtUHXECpxj27cqkawQv62XcEi973CIP0ErHNaBMRnbg1d4X9Ca30O8JTJjridPc glxDbnb8Lg3aW+Dw+kUbH66QqUzsCNfeVWPJhB7m0CKYSbq9J9tNmfnrISz6XZdX/3hS CxwQ== 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=4QuXeh5wzRjLRZwHdBaHqqYubTbi/ZFFR9kUacxTZWo=; b=AkMVtZfmJVgK9jDR1MCt0FlZHNXRn9e7E9YHD+NxD/4rNV1bhJXjNLQhYGrd7vwANJ 5zZp+iEj7RbC2Ho/Pz8DRcDw5puB0hMH1tKx6lSVEoCLcIa9Y5MCRNtoBmQF4/EyagN1 SIGsTtRtF8XvJ+u0MuYqQQ6vzQIzGZVyUbwsDgyoAXr8VVekGpR5sc1NHfdQ2stMKL/g W6+LkLro6rcGkRTgJoNvgLoZ3/AMyuzOss90tmK1bKUZuZhVuXjsZOHM1BdHxL1nIxnZ jBoVL5e4J3nOBuw1V91s0eMx3e6R05NOjLXjuDT/T1XJdNZSLoKce1sFS5ksh6T+a9mr CD9w== X-Gm-Message-State: AMke39lkLqR4tP6uZRNcEyV30xyIUo1bYUlvXidxbue5ISCJXFOlMvRywx3CR701gYpob0BlPzcGUVoAaCmgCQ== X-Received: by 10.28.213.142 with SMTP id m136mr646844wmg.90.1487221452642; Wed, 15 Feb 2017 21:04:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.130.67 with HTTP; Wed, 15 Feb 2017 21:04:12 -0800 (PST) Received: by 10.80.130.67 with HTTP; Wed, 15 Feb 2017 21:04:12 -0800 (PST) In-Reply-To: <20170216023801.GU6258@bacardi.hollandpark.frase.id.au> References: <45e74698-3392-54e7-8412-d2713435cfc3@eff.org> <20170216023801.GU6258@bacardi.hollandpark.frase.id.au> From: Logan Widick Date: Wed, 15 Feb 2017 23:04:12 -0600 Message-ID: To: Fraser Tweedale Content-Type: multipart/alternative; boundary=001a1146995063238105489eba54 Archived-At: Cc: acme@ietf.org, Jacob Hoffman-Andrews Subject: Re: [Acme] JWS serialization 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: Thu, 16 Feb 2017 05:04:16 -0000 --001a1146995063238105489eba54 Content-Type: text/plain; charset=UTF-8 So flattened and general JSON are both allowed, and the non-JSON compact is not allowed? On Feb 15, 2017 8:38 PM, "Fraser Tweedale" wrote: > On Tue, Feb 14, 2017 at 04:02:35PM -0800, Jacob Hoffman-Andrews wrote: > > Flattened JSON, IMO. And I think we should standardize on that single > > representation. > > > I think we should not specify only that a JSON serialisation be > used. We SHOULD NOT specify that flattened must be used. Many JOSE > libraries do not care and will decode either JSON representation as > long as it is valid. Many JOSE libraries would not even provide a > knob to tell it to admit only the flattened serialisation (or vice > versa). > > If the intent is to require that exactly one signature is used, then > just say that. > > Thanks, > Fraser > > > On 02/14/2017 03:39 PM, Logan Widick wrote: > > > All, > > > > > > Which JWS serialization is to be used when implementing? The document > > > indicates that the examples are in either flattened JSON or general > > > JSON serializations for readability. But which serialization must be > > > used for the actual implementations? > > > > > > Sincerely, > > > > > > Logan Widick > > > > > > _______________________________________________ > > > 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 > --001a1146995063238105489eba54 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
So flattened and general JSON are both allowed, and the n= on-JSON compact is not allowed?

On Feb 15, 2017 8:38 PM, "Fraser Tweedale" &l= t;frase@frase.id.au> wrote:
On Tue, Feb 14, 2017 at= 04:02:35PM -0800, Jacob Hoffman-Andrews wrote:
> Flattened JSON, IMO. And I think we should standardize on that single<= br> > representation.
>
I think we should not specify only that a JSON serialisation be
used.=C2=A0 We SHOULD NOT specify that flattened must be used.=C2=A0 Many J= OSE
libraries do not care and will decode either JSON representation as
long as it is valid.=C2=A0 Many JOSE libraries would not even provide a
knob to tell it to admit only the flattened serialisation (or vice
versa).

If the intent is to require that exactly one signature is used, then
just say that.

Thanks,
Fraser

> On 02/14/2017 03:39 PM, Logan Widick wrote:
> > All,
> >
> > Which JWS serialization is to be used when implementing? The docu= ment
> > indicates that the examples are in either flattened JSON or gener= al
> > JSON serializations for readability. But which serialization must= be
> > used for the actual implementations?
> >
> > Sincerely,
> >
> > Logan Widick
> >
> > _______________________________________________
> > Acme mailing list
> > Acme@ietf.org
> > https://www.ietf.org/mailman/listinfo/acme<= /a>
> >
>
> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
--001a1146995063238105489eba54-- From nobody Wed Feb 15 21:45:51 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47A031295AC for ; Wed, 15 Feb 2017 21:45:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_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 L7h6vG-J7Pkj for ; Wed, 15 Feb 2017 21:45:49 -0800 (PST) Received: from captainmorgan.hollandpark.frase.id.au (110-174-235-130.static.tpgi.com.au [110.174.235.130]) (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 0DAE21295A2 for ; Wed, 15 Feb 2017 21:45:47 -0800 (PST) Received: from bacardi.hollandpark.frase.id.au (bacardi.hollandpark.frase.id.au [192.168.0.100]) by captainmorgan.hollandpark.frase.id.au (8.15.2/8.15.2) with ESMTPS id v1G5jW3a042986 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 16 Feb 2017 05:45:33 GMT (envelope-from frase@frase.id.au) Received: from bacardi.hollandpark.frase.id.au (localhost [127.0.0.1]) by bacardi.hollandpark.frase.id.au (8.15.2/8.15.2) with ESMTPS id v1G5jVIb025164 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 16 Feb 2017 15:45:31 +1000 (EST) (envelope-from frase@frase.id.au) Received: (from fraser@localhost) by bacardi.hollandpark.frase.id.au (8.15.2/8.15.2/Submit) id v1G5jRtW025163; Thu, 16 Feb 2017 15:45:27 +1000 (EST) (envelope-from frase@frase.id.au) X-Authentication-Warning: bacardi.hollandpark.frase.id.au: fraser set sender to frase@frase.id.au using -f Date: Thu, 16 Feb 2017 15:45:27 +1000 From: Fraser Tweedale To: Logan Widick Message-ID: <20170216054526.GB6258@bacardi.hollandpark.frase.id.au> References: <45e74698-3392-54e7-8412-d2713435cfc3@eff.org> <20170216023801.GU6258@bacardi.hollandpark.frase.id.au> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="PgLV2f+xYr9y+IUc" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Cc: acme@ietf.org, Jacob Hoffman-Andrews Subject: Re: [Acme] JWS serialization 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: Thu, 16 Feb 2017 05:45:50 -0000 --PgLV2f+xYr9y+IUc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 15, 2017 at 11:04:12PM -0600, Logan Widick wrote: > So flattened and general JSON are both allowed, and the non-JSON compact = is > not allowed? >=20 Yes, I think excluding the compact serialisation is fine. My concern with distinguishing between "JSON" and "flattened JSON" serialisations is that JOSE libraries might not allow you to control what is produced, or restrict what is accepted. (I am the author of such a library). Thanks, Fraser > On Feb 15, 2017 8:38 PM, "Fraser Tweedale" wrote: >=20 > > On Tue, Feb 14, 2017 at 04:02:35PM -0800, Jacob Hoffman-Andrews wrote: > > > Flattened JSON, IMO. And I think we should standardize on that single > > > representation. > > > > > I think we should not specify only that a JSON serialisation be > > used. We SHOULD NOT specify that flattened must be used. Many JOSE > > libraries do not care and will decode either JSON representation as > > long as it is valid. Many JOSE libraries would not even provide a > > knob to tell it to admit only the flattened serialisation (or vice > > versa). > > > > If the intent is to require that exactly one signature is used, then > > just say that. > > > > Thanks, > > Fraser > > > > > On 02/14/2017 03:39 PM, Logan Widick wrote: > > > > All, > > > > > > > > Which JWS serialization is to be used when implementing? The docume= nt > > > > indicates that the examples are in either flattened JSON or general > > > > JSON serializations for readability. But which serialization must be > > > > used for the actual implementations? > > > > > > > > Sincerely, > > > > > > > > Logan Widick > > > > > > > > _______________________________________________ > > > > 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 > > --PgLV2f+xYr9y+IUc Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEWEjOKBhrtGnClRXhS1OQUkER4eIFAlilPHIACgkQS1OQUkER 4eKJrQ//V2zPuGIijGVnEazGqKKJyx9NN/zQOU0KEgd1Alg8gsze99BkvmFnV4dO vs8bXV56ecUyGt04u2lEfMh6ydJmcXr7Am+reW2Q33TWOcKZLjWalMQlrfXw9oRZ NFdxiI8saSt81oJKQGLKe1LvdCpnG5XfR3tOLareTfRzyppkOx7qcZSVqMqGHASA +EduzV/EjmldeQrRu1WD1loSNPZjsgvX4YiCJtHJwXPpWMIIYvedZrgsZyVPATcB IDAF+PVInnEMsue53swPVnEuMiiuZ1TOWs4vg1DGppa4oqyn8/Bo3onqyHbpDAfn WHwX/kbBvpfbYQDnyFnnILLgNovVix+taXO8LnngkQ9bssBhZ0NeVdLRIjFCD/uW SGJtgo2KAxnNlGelRD/xKVXt+AqcKVAf4unmkgHnA1IfPKRxT4aETl7mV4ypflSo 2KgJnHKEG2efrdK7mgxXQVcZMgOs1Qj1m4iZ7W6/bOpHAE2qKmio87lH7Ld86yjh RU6qONL/n0uXAv7454Niim+Ou0OEIbL+2PEzKavb3wZeH/1SOxx697n3Z9RbPU58 j1L3K+mSBZh+Es2qfHiL1hO/gMBgdG0fGrB/fjjyylAtdkIPemMIOJd5caQfCPxg 7JhfbnWhjpgj8VN/8DcQO36SQgBJX2B8hc0s4YYGq/BAKbFNFWI= =Moqc -----END PGP SIGNATURE----- --PgLV2f+xYr9y+IUc-- From nobody Thu Feb 16 08:16:36 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4E7512957B for ; Thu, 16 Feb 2017 08:16:34 -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, 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 2NfNFXebECkc for ; Thu, 16 Feb 2017 08:16:32 -0800 (PST) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::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 3C48912957A for ; Thu, 16 Feb 2017 08:16:32 -0800 (PST) Received: by mail-lf0-x236.google.com with SMTP id z134so10500225lff.3 for ; Thu, 16 Feb 2017 08:16:32 -0800 (PST) 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=XjSk4tZdz/OLS05YRgokwMmKSryo0pA+Km8A+22x4s4=; b=b8Iw8t1Zo+pdPnu2wqUGozpt+K/VEYPqEGGNEV06jBvLsGKV00J0H0Q8we1S88H6g3 Fh4i//PqStZ1ODTVPdNpYHMuj9MMHdS+nGvCC/nCmpBvROvMv1nMOSjtRMnVIjA7luaO Z90WsQoZvU6XGT5C2TIsH8ZpKYEBWFNt3BklY= 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=XjSk4tZdz/OLS05YRgokwMmKSryo0pA+Km8A+22x4s4=; b=SaQKAljyNsyAU2cWFXO3exSuVxswNyqu4bLuiXvfsUhoOfrX4XNzo8Zpxw0GbUC8i3 MTCCheSjnyfNj0IUQ3SmDcGWLawOLWAgoeV6MD4DQbVD/uYMDebk8Tum7xFGvNaSKxN5 ciaxZsRBNWslxZs3KZgt0cwE9K6F/1fFPOZAkYbdQVzTyv2YfSk4612RJVE69vw+1O0c eLhVGG/ss0x6dtCMVelhm/w1BzjYMdxce+mEDjdFsXrpJ/+3taD7ajQNEDINfvlXcFje Aroo4wl/TBOsqAPHKCaua3x9ysdp7YDQZjT+IIOKB6tKsAwQq+udHQp6ovbBNChT/N9A tYHw== X-Gm-Message-State: AMke39nsXLrz8M9veTt0fYniz6ndUWFU1iidGW4mE6Mx7U3eMBk24F3uiDFwEAdOekd5+ORejlQ8HS9UQy7FHP4q X-Received: by 10.46.77.149 with SMTP id c21mr848628ljd.69.1487261790371; Thu, 16 Feb 2017 08:16:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.162.72 with HTTP; Thu, 16 Feb 2017 08:16:29 -0800 (PST) In-Reply-To: References: From: Daniel McCarney Date: Thu, 16 Feb 2017 11:16:29 -0500 Message-ID: To: Roland Bracewell Shoemaker Content-Type: multipart/alternative; boundary=94eb2c1abce8b413820548a81ec4 Archived-At: Cc: "acme@ietf.org" Subject: Re: [Acme] Clarifying what to do with revocation requests with disallowed reasonCodes X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: cpu@letsencrypt.org List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 16:16:35 -0000 --94eb2c1abce8b413820548a81ec4 Content-Type: text/plain; charset=UTF-8 +1 - I think this is clearer. Would you be open to specifying what form the rejection takes? Do you think it would be advantageous to specify a new error in Section 5.7 for the purpose (e.g. `urn:ietf:params:acme:error:invalidReasonCode`) or is there an existing candidate you'd use? On Tue, Feb 14, 2017 at 5:53 PM, Roland Bracewell Shoemaker < roland@letsencrypt.org> wrote: > The current draft leaves it ambiguous as to what the server should do > when a it receives a revocation request containing a reasonCode that it > disallows. I suggest we add a simple 'MUST reject request' clause to the > relevant section to resolve this ambiguity. > > PR: https://github.com/ietf-wg-acme/acme/pull/251 > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > --94eb2c1abce8b413820548a81ec4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1 - I think this is clearer.

Would= you be open to specifying what form the rejection takes? Do you think it
would be advantageous to specify a new error in Section 5.7 for th= e purpose
(e.g. `urn:ietf:params:acme:error:invalidReasonCode`) o= r is there an existing
candidate you'd use?


On Tue, = Feb 14, 2017 at 5:53 PM, Roland Bracewell Shoemaker <<= a href=3D"mailto:roland@letsencrypt.org" target=3D"_blank">roland@letsencry= pt.org> wrote:
The current = draft leaves it ambiguous as to what the server should do
when a it receives a revocation request containing a reasonCode that it
disallows. I suggest we add a simple 'MUST reject request' clause t= o the
relevant section to resolve this ambiguity.

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

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

--94eb2c1abce8b413820548a81ec4-- From nobody Thu Feb 16 13:25: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 6B0211296B1 for ; Thu, 16 Feb 2017 13:25:01 -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, 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 Kuh259FU2VQR for ; Thu, 16 Feb 2017 13:24:58 -0800 (PST) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::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 865621296B9 for ; Thu, 16 Feb 2017 13:24:58 -0800 (PST) Received: by mail-lf0-x22d.google.com with SMTP id z134so14316735lff.3 for ; Thu, 16 Feb 2017 13:24:58 -0800 (PST) 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=DYokhaak/ajKdTHesU+MM8O/+kt0kgfOBzQreEfLTtg=; b=SqxOraWthhfPwiyhmuOPi0uAc5X6RrYk4SKxULjW6Aqrrlnc2kVzlTO6VMsAMD+z2e 1711pPD6l7ktVf4fTbKd7ANbU2koZTM9DvEgEJo6GMPC4slyrvNYKLV4kXrcP3SSn8yr AgdQyaI2Br0cXaMUEKncriS7n/4uxulqKRPJ8= 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=DYokhaak/ajKdTHesU+MM8O/+kt0kgfOBzQreEfLTtg=; b=J96GBDrZfJTmVkdrdioMjbaM0NaTkqGsDSis5gwLQkGbUCPq46T8AzEUbUjuy/RWFH IG3tYcxUxaj/tOrGChK00UYmwfI1hJ+kf5fJhRrll82XAa9UpKJIOWKdeB1G5bs3HfdJ PHfkbZSerzshCsoKZ6BiyarC/4QUc11EyOTlna8XknmvX4zKqjv3QrbN4eR/2PzZZo/T j6CYrVtc2qVzC5xKPVcBJRyWoADhWFjOinWIABOz7/Q+/2tvpPSgQ/803No+1F4fK6N+ krK2pEk0bDdmwVmbDPIQU3hqcjrpTX37gB9wZnUEesxwdstheclPG1j/dQ85c5zGAjNq 8X0w== X-Gm-Message-State: AMke39m4vWV8BcawumvLHdebZFi7UeJwsFLYngOgtppnmk+LL53PhGSZfkGeK+Kx6cvflgiveT/DmSQ4zT48mF9e X-Received: by 10.25.217.79 with SMTP id q76mr1286700lfg.178.1487280296810; Thu, 16 Feb 2017 13:24:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.162.72 with HTTP; Thu, 16 Feb 2017 13:24:56 -0800 (PST) In-Reply-To: References: <81377754-e24d-269d-0f48-ba37e55f8942@eff.org> From: Daniel McCarney Date: Thu, 16 Feb 2017 16:24:56 -0500 Message-ID: To: Alan Doherty Content-Type: multipart/alternative; boundary=94eb2c1851f8c60d210548ac6d3e Archived-At: Cc: "acme@ietf.org" , Martin Thomson , Jacob Hoffman-Andrews , Clint Wilson Subject: Re: [Acme] HPKP in ACME X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: cpu@letsencrypt.org List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 21:25:01 -0000 --94eb2c1851f8c60d210548ac6d3e Content-Type: text/plain; charset=UTF-8 I'm supportive of removing the server pinning headers SHOULD outright. > but how best to word that i don't know I don't think there's much benefit in the ACME spec discussing pinning from a client perspective. If the clients want to pin there isn't anything about ACME that makes the process different than (for e.g.) using square's okhttp library to pin for any other HTTPS server. Am I overlooking something? On Mon, Feb 13, 2017 at 3:29 PM, Alan Doherty wrote: > I would concur that clients should endeavour to support > > (and thusly CAs can consider using in future, when support is available in > wider librarys) > > but because of the risks they should only consider doing so > if/when all their processes are in place to ensure failures can't occur > > but how best to word that i don't know > > At 20:09 13/02/2017 Monday, Clint Wilson wrote: > >I would definitely support removing ", and servers SHOULD emit pinning > headers", especially because of the footgun risk you indicated, but I think > there is some merit in continuing to recommend support for HPKP on the > client side. > > > >On Mon, Feb 13, 2017 at 12:33 PM Jacob Hoffman-Andrews < jsha@eff.org>jsha@eff.org> 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? > > > >PR to remove: https:// > github.com/ietf-wg-acme/acme/pull/244 > > > >_______________________________________________ > >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 > --94eb2c1851f8c60d210548ac6d3e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm supportive of removing the server pinning hea= ders SHOULD outright.

> but how best to word th= at i don't know

I don't think there's = much benefit in the ACME spec discussing pinning from
a client pe= rspective.

If the clients want to pin there isn= 9;t anything about ACME that makes the
process different than (fo= r e.g.) using square's okhttp library to pin for any
other HT= TPS server. Am I overlooking something?


On Mon, Feb 13, 2017 at 3:= 29 PM, Alan Doherty <ietf@alandoherty.net> wrote:
I would concur that clients should endeavour to = support

(and thusly CAs can consider using in future, when support is available in = wider librarys)

but because of the risks they should only consider doing so
if/when all their processes are in place to ensure failures can't occur=

but how best to word that i don't know

At 20:09 13/02/2017=C2=A0 Monday, Clint Wilson wrote:
>I would definitely support removing ", and servers SHOULD emit pin= ning headers", especially because of the footgun risk you indicated, b= ut I think there is some merit in continuing to recommend support for HPKP = on the client side.
>
>On Mon, Feb 13, 2017 at 12:33 PM Jacob Hoffman-= Andrews <<mailto:jsha@eff.org>= jsha@eff.org> wrote:
>Martin brought up a section I've been considering removing:
>
>> Clients SHOULD support HTTP public key pinning [RFC7469], and serv= ers
>SHOULD emit pinning headers.
>
>Here's my reasoning:
>
>- Public key pinning isn't implemented in most HTTPS libraries outs= ide
>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 woul= d
>be that some of those clients would fail to renew their certs, causing<= br> >cascading breakage.
>- There is relatively little confidential information conveyed in ACME,=
>and there are other defenses built into ACME (like including the accoun= t
>key as part of the challenge data), so HPKP is not strongly necessary.<= br> >
>Any objections?
>
>PR to remove: <https://github.com/ietf-wg= -acme/acme/pull/244>https://github.com= /ietf-wg-acme/acme/pull/244
>
>_______________________________________________
>Acme mailing list
><mailto:Acme@ietf.org>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

--94eb2c1851f8c60d210548ac6d3e-- From nobody Thu Feb 16 13:37: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 A75911294F4 for ; Thu, 16 Feb 2017 13:37:12 -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, 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 H9IWKRe1wZZj for ; Thu, 16 Feb 2017 13:37:11 -0800 (PST) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4F9C129522 for ; Thu, 16 Feb 2017 13:37:10 -0800 (PST) Received: by mail-lf0-x22b.google.com with SMTP id o140so362219lff.1 for ; Thu, 16 Feb 2017 13:37:10 -0800 (PST) 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=layLRg0TCUeDeYTssL0z0QWXuU90hcdPgwqKzYDal/g=; b=ERDpacs5m6YiJFg3q8OrtWPshQ4YjghZc/4AdbvbagYoXMsRHYvtr4eQUslxfOtuFY TtPglnGkVZuGV/Rq3UoXk3GHs+83Ja8BsofoAXLpE+IscpiAYJOCSK4A0xpW5WjmDzFq gC2WSRrMh1WDy1ti2WviWPQQO7xzpPplq6YaY= 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=layLRg0TCUeDeYTssL0z0QWXuU90hcdPgwqKzYDal/g=; b=DTwskIuZ5nXNc1NkXNPQDU79Ku1qkal6/ydFfLYEddEhBUmjLW1E7d2mTbIiwmYTrd z3eATX7NNCe/yLinObhzf5DsOOszbiB5gJMPQYeSmX4IEJFY6NtOsZK42poJIgJ9Suxq OkF+lwYvc0d/0LkF84oTcl+l5jvQc80Oz5y7MH5lCWL0tekeolv7eNZk+SlkzX+a6K0F Tn+/1lLY7N1mr0RqBA8goJY8wd94YLupzGSP1ZRlvaTo6cngXjfTABUOpQ9KfnVPe5s6 89hNDpmYeE8Q4kLg2cdXn4LpEROP2xy4G9sUICrzw7h3kIoqZeIvu2rqhU3TBNix/fRK udNA== X-Gm-Message-State: AMke39kcVcG093zx4eQpnoEv8Sc6tu/R+Opjz1oot8rd9olRpzn2q6ICaiZ47aEgCStiQd1ZUrE99MyOnfOn8sD6 X-Received: by 10.25.24.156 with SMTP id 28mr1381970lfy.162.1487281029003; Thu, 16 Feb 2017 13:37:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.162.72 with HTTP; Thu, 16 Feb 2017 13:37:08 -0800 (PST) In-Reply-To: <9baa4aca-120c-4ce8-b118-68dca3917f57@eff.org> References: <9baa4aca-120c-4ce8-b118-68dca3917f57@eff.org> From: Daniel McCarney Date: Thu, 16 Feb 2017 16:37:08 -0500 Message-ID: To: Jacob Hoffman-Andrews Content-Type: multipart/alternative; boundary=001a114065da6a51fa0548ac9953 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 Reply-To: cpu@letsencrypt.org List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 21:37:12 -0000 --001a114065da6a51fa0548ac9953 Content-Type: text/plain; charset=UTF-8 > This is a good point. Should we register x-pem-file as part of this RFC? Or > come up with a new, more specific media type, like > application/pem-certificate-chain? Of the two options my vote would be for `application/pem-certificate-chain` as the better choice. On Mon, Feb 13, 2017 at 4:51 PM, Jacob Hoffman-Andrews wrote: > >From the WGLC thread, Russ Housley said: > > > Section 6.4.2 says: > > The default format of the certificate is PEM (application/x-pem-file) > > as specified by [RFC7468]. ... The client may request other formats by > > including an Accept header in its request. For example, the client > > may use the media type application/pkix-cert to request the end- > > entity certificate in DER format. > > > > RFC 7468 defines the textual encoding for certificates, but it does not > define the application/x-pem-file media type. I cannot find a registration > for the application/x-pem-file media type. > > This is a good point. Should we register x-pem-file as part of this RFC? > Or come up with a new, more specific media type, like > application/pem-certificate-chain? > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > --001a114065da6a51fa0548ac9953 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> This is a good point. Should we register x-pem-file a= s part of this RFC? Or
> come up with a new, more specific media typ= e, like
> application/pem-certificate-chain?

Of the two options my vote would be for `application/pem-certificat= e-chain` as
the better choice.


On Mon, Feb 13, 2017 at 4= :51 PM, Jacob Hoffman-Andrews <jsha@eff.org> wrote:
>From the WGLC thread, Russ Housley said:

> Section 6.4.2 says:
>=C2=A0 The default format of the certificate is PEM (application/x-pem-= file)
>=C2=A0 as specified by [RFC7468]. ... The client may request other form= ats by
>=C2=A0 including an Accept header in its request.=C2=A0 For example, th= e client
>=C2=A0 may use the media type application/pkix-cert to request the end-=
>=C2=A0 entity certificate in DER format.
>
> RFC 7468 defines the textual encoding for certificates, but it does no= t define the application/x-pem-file media type.=C2=A0 I cannot find a regis= tration for the application/x-pem-file media type.

This is a good point. Should we register x-pem-file as part of this RFC? Or= come up with a new, more specific media type, like application/pem-certifi= cate-chain?

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

--001a114065da6a51fa0548ac9953-- From nobody Thu Feb 16 14:41: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 C94C3124281 for ; Thu, 16 Feb 2017 14:41:08 -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 vXWzlLZsaf8d for ; Thu, 16 Feb 2017 14:41:07 -0800 (PST) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::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 EAEB8126B6D for ; Thu, 16 Feb 2017 14:41:06 -0800 (PST) Received: by mail-ua0-x22b.google.com with SMTP id y9so20442180uae.2 for ; Thu, 16 Feb 2017 14:41:06 -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=YEtyqNl2kC1YN5zKLvHS6BR9woOEsapsjwtg8dz1UTw=; b=xvkqqVomUewFropaWWFbRZYF+K7bLQ86ued4UBofQWXAzk4yUxk5lv52pVUY8uySYN 5aWfzoP8rWl4jYEKU0NZXRZvlu1tYgNrjBOSGzSjf5RzAa3wMHiU1n9GabpTuLgg00xM SKEdUUYW84aWXp9CGc6Jim8hLGdOSUnuKbmDx4yDU2MRNoZUFo0Qv+AyPUXhpTBp+HeK ptUewspyRWzoojZyJ/8JHcvtB7/ExaeSNe9bkqJgrGtyNuzelaTNS2F9lNQqUgwFyLH6 /0rLFEdvWGYzmB/AYsp91RmRWdGk0cXTvm746G1YfDecclMg3tUcdBu3ur89j+iabidy 08DA== 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=YEtyqNl2kC1YN5zKLvHS6BR9woOEsapsjwtg8dz1UTw=; b=Rc9WAJtW8S9xQXyXnXDD5YxSc2I83TG9vaV8ImRYOH4T5Wwi0cL3WoLVyPFRsLVfUM srsq95olIXFy8c8QIa2hZbKct8VZg4O2257CU0A29yAW4/E7YOuhBs9MgzMng9C/KLN8 JlNE4rYziS5fh/O9OmdNHV3wkcxkx/5iX1x7u+g3WzHMzkvP2FLCXuk62iZBJWVZu4ql cKyXAWeTMgDWAHO9J1xGBClHa6m76dCmR18QeXizQ3kioGUjaJ6Z/XV4yvfpMZJdatSi aPpBKZoKMD3bW7ZkGKjsNPIckf+B66wtJ6GAOZnipNTF3bkTr/tnI7wynsEMShaIAm3M B/Yw== X-Gm-Message-State: AMke39lrU5Rm7nEE41xeqzI8t7ljlQSxOMO/1hbBRgqrT3ef6lauKxJXZAoEGHDhSKPo5zWVj12L6DcNR325Ng== X-Received: by 10.176.82.93 with SMTP id j29mr2574417uaa.57.1487284865900; Thu, 16 Feb 2017 14:41:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.179.140 with HTTP; Thu, 16 Feb 2017 14:41:05 -0800 (PST) In-Reply-To: References: <9baa4aca-120c-4ce8-b118-68dca3917f57@eff.org> From: Richard Barnes Date: Thu, 16 Feb 2017 17:41:05 -0500 Message-ID: To: Daniel McCarney Content-Type: multipart/alternative; boundary=94eb2c1916a41ccc140548ad7e19 Archived-At: Cc: "acme@ietf.org" , Jacob Hoffman-Andrews 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: Thu, 16 Feb 2017 22:41:09 -0000 --94eb2c1916a41ccc140548ad7e19 Content-Type: text/plain; charset=UTF-8 It seems simplest to me to just register "application/x-pem-file" with a pointer to RFC 7468. RFC 6838 is a little unclear on what's required in this case, but it looks like the most would be an IETF document, in which I expect a small AD-sponsored draft would suffice. On Thu, Feb 16, 2017 at 4:37 PM, Daniel McCarney wrote: > > This is a good point. Should we register x-pem-file as part of this RFC? > Or > > come up with a new, more specific media type, like > > application/pem-certificate-chain? > > Of the two options my vote would be for `application/pem-certificate-chain` > as > the better choice. > > > On Mon, Feb 13, 2017 at 4:51 PM, Jacob Hoffman-Andrews > wrote: > >> >From the WGLC thread, Russ Housley said: >> >> > Section 6.4.2 says: >> > The default format of the certificate is PEM (application/x-pem-file) >> > as specified by [RFC7468]. ... The client may request other formats by >> > including an Accept header in its request. For example, the client >> > may use the media type application/pkix-cert to request the end- >> > entity certificate in DER format. >> > >> > RFC 7468 defines the textual encoding for certificates, but it does not >> define the application/x-pem-file media type. I cannot find a registration >> for the application/x-pem-file media type. >> >> This is a good point. Should we register x-pem-file as part of this RFC? >> Or come up with a new, more specific media type, like >> application/pem-certificate-chain? >> >> _______________________________________________ >> 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 > > --94eb2c1916a41ccc140548ad7e19 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It seems simplest to me to just register "applic= ation/x-pem-file" with a pointer to RFC 7468.

RFC 6838 is= a little unclear on what's required in this case, but it looks like th= e most would be an IETF document, in which I expect a small AD-sponsored dr= aft would suffice.




On Thu, Feb 16, 2017 at= 4:37 PM, Daniel McCarney <cpu@letsencrypt.org> wrote:
=
> This = is a good point. Should we register x-pem-file as part of this RFC? Or
= > come up with a new, more specific media type, like
> appl= ication/pem-certificate-chain?

Of the = two options my vote would be for `application/pem-certificate-chain` a= s
the better choice.


On Mon, Feb 13, 2017 at 4:51 PM, Jacob Hoffman-Andrews <jsha@eff.org&g= t; wrote:
>From the WGLC thread= , Russ Housley said:

> Section 6.4.2 says:
>=C2=A0 The default format of the certificate is PEM (application/x-pem-= file)
>=C2=A0 as specified by [RFC7468]. ... The client may request other form= ats by
>=C2=A0 including an Accept header in its request.=C2=A0 For example, th= e client
>=C2=A0 may use the media type application/pkix-cert to request the end-=
>=C2=A0 entity certificate in DER format.
>
> RFC 7468 defines the textual encoding for certificates, but it does no= t define the application/x-pem-file media type.=C2=A0 I cannot find a regis= tration for the application/x-pem-file media type.

This is a good point. Should we register x-pem-file as part of this RFC? Or= come up with a new, more specific media type, like application/pem-certifi= cate-chain?

_______________________________________________
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


=
--94eb2c1916a41ccc140548ad7e19-- From nobody Thu Feb 16 14:44: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 23FBB129658 for ; Thu, 16 Feb 2017 14:44:45 -0800 (PST) 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 TpmauZNahy6V for ; Thu, 16 Feb 2017 14:44:43 -0800 (PST) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0F7A12955E for ; Thu, 16 Feb 2017 14:44:42 -0800 (PST) Received: by mail-vk0-x231.google.com with SMTP id x75so19653435vke.2 for ; Thu, 16 Feb 2017 14:44:42 -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=4S3+T2/g5Zt/lhu7RrN6SmvUduvbeb5deMY0DfTu5TM=; b=e73BkVRy8VVVtSKliakM3Tzr7ojdmbC4zwJnZHp9jRyefnKM6vsIdLNiLZmWWJom7Q NVOGEm9jXxOeNgjmZAc0WwDEa3//VFJ/4BGs1ScX/gsfsc2EjwR1wkAwUjCuIOXN1VqE oucEh56IYZNyeg6VR0Oit7R4IeNiXkhGdQ8BaM44YgU3so+QQ5zi+9yGCnFMLoKrxbaL PlS93BORoFN87sxJqha1QKKuwVgkku0QTNVWgR+vGx4e7ayV1XpyEYaKGpwNkNMmBmu8 0NXGsThStAyBJRXrUWtiEMeK8GGTSrpMege/jaLPRaA//1fMUOsxxJdHqfDD1GyLg/Jx Z3hg== 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=4S3+T2/g5Zt/lhu7RrN6SmvUduvbeb5deMY0DfTu5TM=; b=Qh1TssmUdywGGVOJGqy9t/Whwo5i7ndwXJfK4gDgHVDdmrtRqu2e4+QUPpO1uVZKxz MtpF/ujh1GBzFSbE+ICPL+NfqX6MVqY6ptS1xqzNJs+gg0GThAZ6NoNcw+aBlyJ+0wL2 vOvxejN3fxbgDJEkmJA9AGuJkyQhqSp197q/Czz5Id0lR91spcXqoZcb7Or6xbiXuk4O GoEZ8hGopB1s8eJ/1kKOrnHoRjT2CQ4Q7gQfBy8QGfef9vmoflLgDdfXo2Ta6eiAa0fj JY2dx8ODWX2aO36ubv6pEn+ExOY1KkKiA9xwdjWjhnFQCsIv0g4sW2Zdht5ztJnsaF3W vn8w== X-Gm-Message-State: AMke39khLlOK7poF+hQ1tBaZQE2bB7gRW4cOb1zBgVAXuRWPXlnNMoIjz3t9p0M77BOWBb0BseFdW+GxdcIaGg== X-Received: by 10.31.59.197 with SMTP id i188mr1932044vka.45.1487285081921; Thu, 16 Feb 2017 14:44:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.179.140 with HTTP; Thu, 16 Feb 2017 14:44:41 -0800 (PST) In-Reply-To: References: <81377754-e24d-269d-0f48-ba37e55f8942@eff.org> From: Richard Barnes Date: Thu, 16 Feb 2017 17:44:41 -0500 Message-ID: To: Daniel McCarney Content-Type: multipart/alternative; boundary=001a1142f178fceb1d0548ad8af9 Archived-At: Cc: Alan Doherty , "acme@ietf.org" , Martin Thomson , Jacob Hoffman-Andrews , Clint Wilson 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: Thu, 16 Feb 2017 22:44:45 -0000 --001a1142f178fceb1d0548ad8af9 Content-Type: text/plain; charset=UTF-8 On Thu, Feb 16, 2017 at 4:24 PM, Daniel McCarney wrote: > I'm supportive of removing the server pinning headers SHOULD outright. > > > but how best to word that i don't know > > I don't think there's much benefit in the ACME spec discussing pinning from > a client perspective. > > If the clients want to pin there isn't anything about ACME that makes the > process different than (for e.g.) using square's okhttp library to pin for > any > other HTTPS server. Am I overlooking something? > There's nothing different. The idea here was just to point people to some mechanisms they could use to guard against mis-issuance. I'm OK dropping it if people don't like it, but I would kind of like to keep it. Perhaps we could downgrade to MAY WISH TO https://tools.ietf.org/html/rfc6919#section-6 > > > On Mon, Feb 13, 2017 at 3:29 PM, Alan Doherty > wrote: > >> I would concur that clients should endeavour to support >> >> (and thusly CAs can consider using in future, when support is available >> in wider librarys) >> >> but because of the risks they should only consider doing so >> if/when all their processes are in place to ensure failures can't occur >> >> but how best to word that i don't know >> >> At 20:09 13/02/2017 Monday, Clint Wilson wrote: >> >I would definitely support removing ", and servers SHOULD emit pinning >> headers", especially because of the footgun risk you indicated, but I think >> there is some merit in continuing to recommend support for HPKP on the >> client side. >> > >> >On Mon, Feb 13, 2017 at 12:33 PM Jacob Hoffman-Andrews <> jsha@eff.org>jsha@eff.org> 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? >> > >> >PR to remove: >> https://github.com/ietf-wg-acme/acme/pull/244 >> > >> >_______________________________________________ >> >Acme mailing list >> >Acme@ietf.org >> >https://www.ietf.org/mailman/listinfo/acme >> > >> >_______________________________________________ >> >Acme mailing list >> >Acme@ietf.org >> >https://www.ietf.org/mailman/listinfo/acme >> >> _______________________________________________ >> Acme mailing list >> Acme@ietf.org >> https://www.ietf.org/mailman/listinfo/acme >> > > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > > --001a1142f178fceb1d0548ad8af9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Feb 16, 2017 at 4:24 PM, Daniel McCarney <= cpu@letsencrypt.or= g> wrote:
I'm supportive of removing the server pinning h= eaders SHOULD outright.

>= ; but how best to word that i don't know

I don't think there's much benefit in the ACME spec discussing pi= nning from
a client perspective.

If the = clients want to pin there isn't anything about ACME that makes the
process different than (for e.g.) using square's okhttp library t= o pin for any
other HTTPS server. Am I overlooking something?

There's nothing different.=C2= =A0 The idea here was just to point people to some mechanisms they could us= e to guard against mis-issuance.=C2=A0 I'm OK dropping it if people don= 't like it, but I would kind of like to keep it.=C2=A0

Perhaps we could downgrade to MAY WISH TO
https://tools.ietf.org/html/rfc6919#section-= 6
=C2=A0


=C2=A0


On Mon, Feb 13, 2017 at 3:29 PM, Alan Doherty <ietf@alandoherty.net> wrote:
I would concur that clients should endeavour to suppo= rt

(and thusly CAs can consider using in future, when support is available in = wider librarys)

but because of the risks they should only consider doing so
if/when all their processes are in place to ensure failures can't occur=

but how best to word that i don't know

At 20:09 13/02/2017=C2=A0 Monday, Clint Wilson wrote:
>I would definitely support removing ", and servers SHOULD emit pin= ning headers", especially because of the footgun risk you indicated, b= ut I think there is some merit in continuing to recommend support for HPKP = on the client side.
>
>On Mon, Feb 13, 2017 at 12:33 PM Jacob Hoffman-Andrews <= ;<mailto:jsha@eff.org<= /a>>jsha@eff.org<= /a>> wrote:
>Martin brought up a section I've been considering removing:
>
>> Clients SHOULD support HTTP public key pinning [RFC7469], and serv= ers
>SHOULD emit pinning headers.
>
>Here's my reasoning:
>
>- Public key pinning isn't implemented in most HTTPS libraries outs= ide
>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 woul= d
>be that some of those clients would fail to renew their certs, causing<= br> >cascading breakage.
>- There is relatively little confidential information conveyed in ACME,=
>and there are other defenses built into ACME (like including the accoun= t
>key as part of the challenge data), so HPKP is not strongly necessary.<= br> >
>Any objections?
>
>PR to remove: <https://github.com/ietf-wg= -acme/acme/pull/244>https://github.com= /ietf-wg-acme/acme/pull/244
>
>_______________________________________________
>Acme mailing list
><mailto:Acme@ietf= .org>Acme@ie= tf.org
>https://www.ietf.org/mailman/listinfo/acme
>
>_______________________________________________
>Acme mailing list
>Acme@ietf.org >https://www.ietf.org/mailman/listinfo/acme
_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme


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


--001a1142f178fceb1d0548ad8af9-- From nobody Thu Feb 16 15:01: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 BF1E5129455 for ; Thu, 16 Feb 2017 15:01:11 -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, 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 vTUt6zVS7ivi for ; Thu, 16 Feb 2017 15:01:10 -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 E148B124281 for ; Thu, 16 Feb 2017 15:01:10 -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=7Cb2YjlrZ/F/ZgcLz1KFX/VjNTyWNx1pk3ENidMb2+M=; b=vhksvGSdKYM0GfVYpqLmJ3pT+x6pkky3tjYeV6KiT0VKka2kBYKNTuA5djiRslIzkhwNGNA/NZZcKL+Pv0SBem4v/g9E8TDaZxGbfVxOYqB3eLbB9+ArbRzmHTAyYXyV4PXBCCYx4t1Y1WAF+y+NBVXMyATapR9Omc8AimQ/dTc=; Received: ; Thu, 16 Feb 2017 15:01:12 -0800 To: Richard Barnes , Daniel McCarney References: <9baa4aca-120c-4ce8-b118-68dca3917f57@eff.org> From: Jacob Hoffman-Andrews Message-ID: Date: Thu, 16 Feb 2017 15:01:10 -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] 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: Thu, 16 Feb 2017 23:01:12 -0000 On 02/16/2017 02:41 PM, Richard Barnes wrote: > It seems simplest to me to just register "application/x-pem-file" with > a pointer to RFC 7468. Why that as opposed to application/pem-certificate-chain. x-pem-file has some existing use but it is very small, and pem-certificate-chain is much more specific. A pem file can contain any number of things: a certificate, a private key, a CSR, etc. From nobody Thu Feb 16 16:11:21 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A25D512944F for ; Thu, 16 Feb 2017 16:11:20 -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 UEPiWnAtZkP6 for ; Thu, 16 Feb 2017 16:11:19 -0800 (PST) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id A39DA12944E for ; Thu, 16 Feb 2017 16:11:19 -0800 (PST) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 0E81620006B; Fri, 17 Feb 2017 00:11:19 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id E79DE200069; Fri, 17 Feb 2017 00:11:18 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1487290278; bh=9IFTr/jiHGJssEMXDm0e70E4CFH9wG6K+lL2w9FStmQ=; l=244; h=From:To:CC:Date:References:In-Reply-To:From; b=eqdpEwph9x/y+hkOBVstD4XSMF5e0F+lRK+EnfitshngfTDTz+1OtLtHDt2QilPSk e/RNCOTW+6K/ILKvx1Q30V+SHPYGugaAu+LFDdW/Kg+Hv5P6g9A99ggf6/mSr9rytv sMbGdq9CHqPyNtEfZxcsA1nhjB5rzaxkZtfbMY90= Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id C9624980A9; Fri, 17 Feb 2017 00:11:18 +0000 (GMT) Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 16 Feb 2017 19:11:18 -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; Thu, 16 Feb 2017 19:11:17 -0500 From: "Salz, Rich" To: Jacob Hoffman-Andrews , Richard Barnes , "Daniel McCarney" Thread-Topic: [Acme] Registering a PEM Content-Type Thread-Index: AQHShkNQI/CXO86iJ0icYl1s5L6d5aFsgPAAgAAR3oCAAAWdAP//v3KQ Date: Fri, 17 Feb 2017 00:11:17 +0000 Message-ID: <937ffb4e61f745fd844e2c5a04ce26b5@usma1ex-dag1mb3.msg.corp.akamai.com> References: <9baa4aca-120c-4ce8-b118-68dca3917f57@eff.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.46.167] 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: Fri, 17 Feb 2017 00:11:21 -0000 I think you need application/pem-cert-list, which is a collection of PEM ce= rtificates 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. From nobody Thu Feb 16 18:57: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 C2952129850 for ; Thu, 16 Feb 2017 18:57:49 -0800 (PST) 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 oHX_YGGJLQRo for ; Thu, 16 Feb 2017 18:57:48 -0800 (PST) Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::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 328EA129421 for ; Thu, 16 Feb 2017 18:57:48 -0800 (PST) Received: by mail-ot0-x232.google.com with SMTP id k4so3910785otc.0 for ; Thu, 16 Feb 2017 18:57:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5gIdX+iehNOtr0NcDcBc64GIzDZuIZeuv4vRA0c/ssA=; b=coWt8Dv+BvCiQceyfOssXYBMt2SCCZ1B/5V1moCoMtuzYh/Xi7qXH0Pbgw8LHYGlT2 1FDY/81OMj0yT8hWjwPVhTc0giwx+ArH0pMbJStPC/kLU7QLB3SkGgAXbZW7xZ6bN93e X53BEJpvNxCBG6Gb+0mRpHMt+vPiKpab5GILpesJ4o2tF9Lzlg1Q9J8w6KHg7VU9O+ok N/iiwTsGF7SKddEi3734tJ/R8KB/qe8CGFA7bRjvAJHfd1TM4rB8kesE5tLmGRIw46KM jphPT4GqK4/xIE+cz3gI1NdB91PcXewiVKMDFJQrUwQQJzkvSxcFWUouIPJ5m5P9L4qh lEfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5gIdX+iehNOtr0NcDcBc64GIzDZuIZeuv4vRA0c/ssA=; b=NqGut/FsJQhP+8cBlO0v822simdggTfa1g4MJIK75l8mFYwYPmkJIv+mq+9IJ+ptrM RqZ2M4N78L487lwb2xrdXdSiriKEr/QlvH/F0Bl/PT06vq+piyVn1jyGzJ/U9PFOwdsl x0FpEMK87kwKqfl59DKm4ycV8IV/gPC3Ontl3I6TIYWIJGix9ADwFGTZlUKhmq/5SbKE ujXg2jJzZ7fXxVSjAM4IWM2nuwAqDGz4fBWUTEx2o+NHqBDa2QhX0g5v/W7YxghYCMsH KBRk4T+cdxBjgO3i16XG5SpWDxVrgXycs0h0uENVcOJcRL/H1tcXbZrCNxrcmi2FjJaA Yl9g== X-Gm-Message-State: AMke39kIRb1OnK6mvS72UaQfMZMEAfq5R/1byBz5sMJ9BysaOqionGc5q0qZDqdWDHYbXo2galTCejgLc+ZOsA== X-Received: by 10.157.6.7 with SMTP id 7mr3423386otn.254.1487300267597; Thu, 16 Feb 2017 18:57:47 -0800 (PST) MIME-Version: 1.0 References: <9baa4aca-120c-4ce8-b118-68dca3917f57@eff.org> <937ffb4e61f745fd844e2c5a04ce26b5@usma1ex-dag1mb3.msg.corp.akamai.com> In-Reply-To: <937ffb4e61f745fd844e2c5a04ce26b5@usma1ex-dag1mb3.msg.corp.akamai.com> From: Clint Wilson Date: Fri, 17 Feb 2017 02:57:32 +0000 Message-ID: To: "Salz, Rich" , Jacob Hoffman-Andrews , Richard Barnes , Daniel McCarney Content-Type: multipart/alternative; boundary=94eb2c095f7a1fe4ef0548b11450 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: Fri, 17 Feb 2017 02:57:50 -0000 --94eb2c095f7a1fe4ef0548b11450 Content-Type: text/plain; charset=UTF-8 +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 > --94eb2c095f7a1fe4ef0548b11450 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

+1 for application/pem-cert-list.


On Thu, Feb 16, 2017, 5:11 = PM Salz, Rich <rsalz@akamai.com&= gt; wrote:
I think you need applica= tion/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
--94eb2c095f7a1fe4ef0548b11450-- From nobody Fri Feb 17 05:42: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 4143A1299BA for ; Fri, 17 Feb 2017 05:42:09 -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 PWHZqsLe6ieb for ; Fri, 17 Feb 2017 05:42:08 -0800 (PST) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003: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 D85A2129A78 for ; Fri, 17 Feb 2017 05:42:07 -0800 (PST) Received: by mail-oi0-x22e.google.com with SMTP id u143so24105775oif.3 for ; Fri, 17 Feb 2017 05:42:07 -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=GJNxX2qT+vvhPI908E+m37tHLXE43HUgzRs+UvaRtI4=; b=sebFTJM+lTG0zmVV6HVh+dCBuxuq+pAhmiyd9TPRm1RYmeG+tZDUgCHrrg8RE3u9hp RSHJ2qHwIzJ7WJqZuM7XPaTUVtBZtAK08/blmT9Utp9t2wvRQdMxjO5ns7KRWl1vAd52 hfZ8qlACYiftDeHdTQUKd+EicvxvBLqkbI5SHXtke0hZwk+oxhG/2ZZ5svuR3F6S7pwy TtjwGK1BximaedCgd7VOtZkkoekwuTFpeYXIyrM4k74VDvAmHhs1NQwtVVlT3O+FLywi YfX/EU62igHxpbBmaJMJJO9BjK42VXs2YPXHfyxvWX14NfBnUyuARXx1RuWF72wOVyYB nO4A== 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=GJNxX2qT+vvhPI908E+m37tHLXE43HUgzRs+UvaRtI4=; b=ahKlnntIGv7uNbhoVAhhnGZ4p9smJpuVlWWmtecdXwGE+icGmCJo2sCg3s5zGBk7OF uARG3F8THo4JMZHgX5aJx2Nvo88OVesF6LnzApEjugZeiG+PlCPNAuyT+fO5UmrJujCS yNfxyqSHx8U38fkYifOQ9aSLiQYm4Sc4EHIijiyuUdpb+OoGs/MTWDcBzRIHrzhpV33T JxB4iV0jBBlwVJRXD3ntcJRSd1j6eXXiMmu21pLx9+PvtXQKxzOxnQ5oMOXUqfywebR6 LwqXctdT8if/tE+mMHhcACN5PPLnFPmcTMe9WPIDYYk6S2xxQynI3ume2PvlfkOaG+/d Bh9Q== X-Gm-Message-State: AMke39kuq4CgSybenP7RMHNs3I2ZMwkSCjotaLbGQj3KD0Ic0LYbxex8LM4+P/WDh1I8CviKu1skganuhzbXwQ== X-Received: by 10.202.197.137 with SMTP id v131mr4430931oif.37.1487338927065; Fri, 17 Feb 2017 05:42:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.13.20 with HTTP; Fri, 17 Feb 2017 05:42:06 -0800 (PST) From: Josh Soref Date: Fri, 17 Feb 2017 08:42:06 -0500 Message-ID: To: acme@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Acme] UX design by standards 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, 17 Feb 2017 13:42:09 -0000 I'm still working on reviewing the document. I have one large PR which I haven't finished and haven't published, and I have an entire design issue (relating to errors) which I want to talk about. (And I need to file a bug against rfc7807.) But... > Clients SHOULD display the "detail" field of all errors. [1] I'm reminded ... there was one specification (i can't remember if it was Cookie, HTTP, or HTML) which had a UAs must tell users about something (redirects? cookies?). Browser authors never implemented the thing I'm thinking about (all I remember is this quirk, I can't remember which thing it was). [1] https://github.com/ietf-wg-acme/acme/blob/68a87b4/draft-ietf-acme-acme.md#errors From nobody Fri Feb 17 09:28:49 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86F01129AD2 for ; Fri, 17 Feb 2017 09:28:47 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 xiBXbm9pj-Hx for ; Fri, 17 Feb 2017 09:28:45 -0800 (PST) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::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 7D6CA129AD1 for ; Fri, 17 Feb 2017 09:28:44 -0800 (PST) Received: by mail-lf0-x236.google.com with SMTP id x1so25631081lff.0 for ; Fri, 17 Feb 2017 09:28:44 -0800 (PST) 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=AtSf5AfbHrKlB16pU8QW2dr62MkAVjuiH/M47Zr2Dos=; b=VtQgJJoZ7NKvJNw1oWY5pfPyzjBg3hM01RdAgHuEYeaC2tGBrOsE7ANYf3womOZVRp zYyUFAbv2gBz+DRD5TnhwQJXGJuKd7KOB+RpIsH4OQRVQdud66yZ8zn3OgCftCzvxu1H MVDp+Da+O3yQ3AMA8T6sVE2Bgw5XwT4GHOyPo= 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=AtSf5AfbHrKlB16pU8QW2dr62MkAVjuiH/M47Zr2Dos=; b=PP/4FsPEtcSWFMpiiuPPBzmJkCUda407xf8IuoJPSYbHFf6G+nTrDmbDjwk3SmD8W6 INZVrzYo1wp4lB0Q006nSBIbHw6g6iQTN8gMJyuxOHdUt0H/AZQVniTFM5qejTdGyxjQ V0tIHiMzszM/teQWEJzhX6jt8k+1rTkI8uLnszyTqeLQjtzNr2DiZStbO3cBAUj6pyk5 5zLCHV8NNaSgi2YnlbjsMc8Akaq8PkAXailfceYWaUiwrF6CSYktmNqeSwtTA+RpjMRw W8IBm0C5T0JOA7GZ6TDi2unbShIl4zRMPI3Q0zgLBfBcqlzfDkQ7Ss5x9wByRH+pHO4G s5IA== X-Gm-Message-State: AMke39k7HQ/PWJy7Y/QBZERT1MCH/B+FJ1Da5otPIiquSFRafBVEInpBq4SC8ZeurYa7bD99M2LZURL7jt9HMCdf X-Received: by 10.25.79.71 with SMTP id a7mr2927521lfk.67.1487352522447; Fri, 17 Feb 2017 09:28:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.162.72 with HTTP; Fri, 17 Feb 2017 09:28:41 -0800 (PST) In-Reply-To: References: <81377754-e24d-269d-0f48-ba37e55f8942@eff.org> From: Daniel McCarney Date: Fri, 17 Feb 2017 12:28:41 -0500 Message-ID: To: Richard Barnes Content-Type: multipart/alternative; boundary=94eb2c1cd7a2c1b5cd0548bd3ebf Archived-At: Cc: Alan Doherty , "acme@ietf.org" , Martin Thomson , Jacob Hoffman-Andrews , Clint Wilson Subject: Re: [Acme] HPKP in ACME X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: cpu@letsencrypt.org List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 17:28:47 -0000 --94eb2c1cd7a2c1b5cd0548bd3ebf Content-Type: text/plain; charset=UTF-8 > Perhaps we could downgrade to MAY WISH TO > https://tools.ietf.org/html/rfc6919#section-6 This feels a little wishy-washy for something I think we could tie-break without too much delay. Jacob, Clint, and myself all stated support for removing it. You're OK with dropping it. I think Alan is in a similar mid-point camp. (Please weigh in if I'm mis-characterizing) Does anyone else feel strongly? Can we aim for consensus for Monday? On Thu, Feb 16, 2017 at 5:44 PM, Richard Barnes wrote: > > > On Thu, Feb 16, 2017 at 4:24 PM, Daniel McCarney > wrote: > >> I'm supportive of removing the server pinning headers SHOULD outright. >> >> > but how best to word that i don't know >> >> I don't think there's much benefit in the ACME spec discussing pinning >> from >> a client perspective. >> >> If the clients want to pin there isn't anything about ACME that makes the >> process different than (for e.g.) using square's okhttp library to pin >> for any >> other HTTPS server. Am I overlooking something? >> > > There's nothing different. The idea here was just to point people to some > mechanisms they could use to guard against mis-issuance. I'm OK dropping > it if people don't like it, but I would kind of like to keep it. > > Perhaps we could downgrade to MAY WISH TO > https://tools.ietf.org/html/rfc6919#section-6 > > > > > >> >> >> On Mon, Feb 13, 2017 at 3:29 PM, Alan Doherty >> wrote: >> >>> I would concur that clients should endeavour to support >>> >>> (and thusly CAs can consider using in future, when support is available >>> in wider librarys) >>> >>> but because of the risks they should only consider doing so >>> if/when all their processes are in place to ensure failures can't occur >>> >>> but how best to word that i don't know >>> >>> At 20:09 13/02/2017 Monday, Clint Wilson wrote: >>> >I would definitely support removing ", and servers SHOULD emit pinning >>> headers", especially because of the footgun risk you indicated, but I think >>> there is some merit in continuing to recommend support for HPKP on the >>> client side. >>> > >>> >On Mon, Feb 13, 2017 at 12:33 PM Jacob Hoffman-Andrews <>> jsha@eff.org>jsha@eff.org> 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? >>> > >>> >PR to remove: >>> https://github.com/ietf-wg-acme/acme/pull/244 >>> > >>> >_______________________________________________ >>> >Acme mailing list >>> >Acme@ietf.org >>> >https://www.ietf.org/mailman/listinfo/acme >>> > >>> >_______________________________________________ >>> >Acme mailing list >>> >Acme@ietf.org >>> >https://www.ietf.org/mailman/listinfo/acme >>> >>> _______________________________________________ >>> Acme mailing list >>> Acme@ietf.org >>> https://www.ietf.org/mailman/listinfo/acme >>> >> >> >> _______________________________________________ >> Acme mailing list >> Acme@ietf.org >> https://www.ietf.org/mailman/listinfo/acme >> >> > --94eb2c1cd7a2c1b5cd0548bd3ebf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
>=C2=A0Perhaps we coul= d downgrade to MAY WISH TO
>=C2=A0<= a href=3D"https://tools.ietf.org/html/rfc6919#section-6" target=3D"_blank" = style=3D"font-size:12.8px">https://tools.ietf.org/html/rfc6919#section= -6

This feels a little wishy-washy for something I think we= could tie-break without
too much delay.

Jacob, Clint, and myself all stated support for removing it. You're OK= with
dropping it. I think Alan is in a similar mid-point camp. (= Please weigh in if
I'm mis-characterizing)

Does anyone else f= eel strongly? Can we aim for consensus for=C2=A0
Monday?
<= br>

On= Thu, Feb 16, 2017 at 5:44 PM, Richard Barnes <rlb@ipv.sx> wrote:


On Thu, Feb 16, 2017 = at 4:24 PM, Daniel McCarney <cpu@letsencrypt.org> wrote:
I= 'm supportive of removing the server pinning headers SHOULD outright.

> b= ut how best to word that i don't know

I= don't think there's much benefit in the ACME spec discussing pinni= ng from
a client perspective.

If the cli= ents want to pin there isn't anything about ACME that makes the
process different than (for e.g.) using square's okhttp library to p= in for any
other HTTPS server. Am I overlooking something?
<= /div>

There's nothing different.= =C2=A0 The idea here was just to point people to some mechanisms they could= use to guard against mis-issuance.=C2=A0 I'm OK dropping it if people = don't like it, but I would kind of like to keep it.=C2=A0

Perhaps we could downgrade to MAY WISH TO
https://tools.ietf.org/= html/rfc6919#section-6
=C2=A0
<= div>

=C2=A0
<= div dir=3D"ltr">


On Mon, Feb 13, 2017 at 3:29 PM, A= lan Doherty <ietf@alandoherty.net> wrote:
I would concur that clients should en= deavour to support

(and thusly CAs can consider using in future, when support is available in = wider librarys)

but because of the risks they should only consider doing so
if/when all their processes are in place to ensure failures can't occur=

but how best to word that i don't know

At 20:09 13/02/2017=C2=A0 Monday, Clint Wilson wrote:
>I would definitely support removing ", and servers SHOULD emit pin= ning headers", especially because of the footgun risk you indicated, b= ut I think there is some merit in continuing to recommend support for HPKP = on the client side.
>
>On Mon, Feb 13, 2017 at 12:33 PM Jacob Hoffman-Andrews <= ;<mailto:jsha@eff.org<= /a>>jsha@eff.org<= /a>> wrote:
>Martin brought up a section I've been considering removing:
>
>> Clients SHOULD support HTTP public key pinning [RFC7469], and serv= ers
>SHOULD emit pinning headers.
>
>Here's my reasoning:
>
>- Public key pinning isn't implemented in most HTTPS libraries outs= ide
>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 woul= d
>be that some of those clients would fail to renew their certs, causing<= br> >cascading breakage.
>- There is relatively little confidential information conveyed in ACME,=
>and there are other defenses built into ACME (like including the accoun= t
>key as part of the challenge data), so HPKP is not strongly necessary.<= br> >
>Any objections?
>
>PR to remove: <https://github.com/ietf-wg= -acme/acme/pull/244>https://github.com= /ietf-wg-acme/acme/pull/244
>
>_______________________________________________
>Acme mailing list
><mailto:Acme@ietf= .org>Acme@ie= tf.org
>https://www.ietf.org/mailman/listinfo/acme
>
>_______________________________________________
>Acme mailing list
>Acme@ietf.org >https://www.ietf.org/mailman/listinfo/acme
_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme


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



--94eb2c1cd7a2c1b5cd0548bd3ebf-- From nobody Fri Feb 17 09:36: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 6B57212957B for ; Fri, 17 Feb 2017 09:36:37 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 1P652V3d5VCg for ; Fri, 17 Feb 2017 09:36:35 -0800 (PST) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::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 152E7126579 for ; Fri, 17 Feb 2017 09:36:35 -0800 (PST) Received: by mail-lf0-x235.google.com with SMTP id z134so25726975lff.3 for ; Fri, 17 Feb 2017 09:36:34 -0800 (PST) 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=FiOWkBmK7inYHA731nP0XCFeAWErU3Q0byBQnpXobcA=; b=KLvEFs5KpdoZqNnriiEkNhoFDVBzdtyyRAfpOYN0Tq2uV7t/tA99fTG+YqVYUAcOl8 +pWLzc5Mglj9okb9HMeNhzZcAHMCPhYiq6OXDoe6GOc/JbXT1gyj3Y/AXJ/c2xKftMp9 iS3+FPBojvRgfeAB8ILereOQwgDeupr1SJqWg= 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=FiOWkBmK7inYHA731nP0XCFeAWErU3Q0byBQnpXobcA=; b=H/38AF7DkGyzJaaNmkxiqGho8PyDsmpm+Wx8fvVLZ9xndTlSFfJWPUohKJaUmSk34s WmMSbqx1qSU7MgWLjVSP0IWggmOJ8xodPdtwyeEFXpp2eThEbufHOuO4KEMd/1SsyGEi RUeQo7NJyayvmBEasVXO3IPhWf16BAtgrwNhAtyv4jSyBkXRjLR5sQQrXd4ijtUyUCe1 qCrlZu7olqU05hm7R73kyh3MSPJ1ZkUpvXVgL9/5bSsaOJEKd2c1Q19agZDbBrnLpnRp l4K5NE97kwNiZOGiOaZfiNwmLsQxGFBjNx5LYiMfG6qctInafXUN5PUxW43kEBVWLeSz 7Ybg== X-Gm-Message-State: AMke39m9yYbDfbt/jwRGXWrVJXQGt8xKZhfmbUIj4Go0wpKanW55bdJGiyXSoAeIfl3F+hNY2BUD5k7vPQuA84Vb X-Received: by 10.25.129.147 with SMTP id c141mr2587296lfd.93.1487352993345; Fri, 17 Feb 2017 09:36:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.162.72 with HTTP; Fri, 17 Feb 2017 09:36:32 -0800 (PST) In-Reply-To: References: <81377754-e24d-269d-0f48-ba37e55f8942@eff.org> From: Daniel McCarney Date: Fri, 17 Feb 2017 12:36:32 -0500 Message-ID: To: Richard Barnes Content-Type: multipart/alternative; boundary=001a113eae76d30f8b0548bd5a83 Archived-At: Cc: Alan Doherty , "acme@ietf.org" , Martin Thomson , Jacob Hoffman-Andrews , Clint Wilson Subject: Re: [Acme] HPKP in ACME X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: cpu@letsencrypt.org List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 17:36:37 -0000 --001a113eae76d30f8b0548bd5a83 Content-Type: text/plain; charset=UTF-8 >> > https://tools.ietf.org/html/rfc6919#section-6 > This feels a little wishy-washy for something I think we could tie-break without > too much delay. Clearly I need to get in the habit of checking the published date on RFCs before reading too literally :-D Good one! On Fri, Feb 17, 2017 at 12:28 PM, Daniel McCarney wrote: > > Perhaps we could downgrade to MAY WISH TO > > https://tools.ietf.org/html/rfc6919#section-6 > > This feels a little wishy-washy for something I think we could tie-break > without > too much delay. > > Jacob, Clint, and myself all stated support for removing it. You're OK with > dropping it. I think Alan is in a similar mid-point camp. (Please weigh in > if > I'm mis-characterizing) > > Does anyone else feel strongly? Can we aim for consensus for > Monday? > > > On Thu, Feb 16, 2017 at 5:44 PM, Richard Barnes wrote: > >> >> >> On Thu, Feb 16, 2017 at 4:24 PM, Daniel McCarney >> wrote: >> >>> I'm supportive of removing the server pinning headers SHOULD outright. >>> >>> > but how best to word that i don't know >>> >>> I don't think there's much benefit in the ACME spec discussing pinning >>> from >>> a client perspective. >>> >>> If the clients want to pin there isn't anything about ACME that makes the >>> process different than (for e.g.) using square's okhttp library to pin >>> for any >>> other HTTPS server. Am I overlooking something? >>> >> >> There's nothing different. The idea here was just to point people to >> some mechanisms they could use to guard against mis-issuance. I'm OK >> dropping it if people don't like it, but I would kind of like to keep it. >> >> Perhaps we could downgrade to MAY WISH TO >> https://tools.ietf.org/html/rfc6919#section-6 >> >> >> >> >> >>> >>> >>> On Mon, Feb 13, 2017 at 3:29 PM, Alan Doherty >>> wrote: >>> >>>> I would concur that clients should endeavour to support >>>> >>>> (and thusly CAs can consider using in future, when support is available >>>> in wider librarys) >>>> >>>> but because of the risks they should only consider doing so >>>> if/when all their processes are in place to ensure failures can't occur >>>> >>>> but how best to word that i don't know >>>> >>>> At 20:09 13/02/2017 Monday, Clint Wilson wrote: >>>> >I would definitely support removing ", and servers SHOULD emit pinning >>>> headers", especially because of the footgun risk you indicated, but I think >>>> there is some merit in continuing to recommend support for HPKP on the >>>> client side. >>>> > >>>> >On Mon, Feb 13, 2017 at 12:33 PM Jacob Hoffman-Andrews <>>> jsha@eff.org>jsha@eff.org> 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? >>>> > >>>> >PR to remove: >>>> https://github.com/ietf-wg-acme/acme/pull/244 >>>> > >>>> >_______________________________________________ >>>> >Acme mailing list >>>> >Acme@ietf.org >>>> >https://www.ietf.org/mailman/listinfo/acme >>>> > >>>> >_______________________________________________ >>>> >Acme mailing list >>>> >Acme@ietf.org >>>> >https://www.ietf.org/mailman/listinfo/acme >>>> >>>> _______________________________________________ >>>> Acme mailing list >>>> Acme@ietf.org >>>> https://www.ietf.org/mailman/listinfo/acme >>>> >>> >>> >>> _______________________________________________ >>> Acme mailing list >>> Acme@ietf.org >>> https://www.ietf.org/mailman/listinfo/acme >>> >>> >> > --001a113eae76d30f8b0548bd5a83 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
>>=C2=A0>=C2=A0https://tools.ietf.org= /html/rfc6919#section-6
>=C2=A0This feels a little wishy= -washy for something I think we could tie-break without
> too much delay.

Clearly I need to get in the= habit of checking the published date on RFCs before
reading too literal= ly :-D Good one!

On Fri, Feb 17, 2017 at 12:28 PM, Daniel McCarney <cpu@letsen= crypt.org> wrote:
>=C2=A0Perhap= s we could downgrade to MAY WISH TO
&g= t;=C2=A0https://tools.ietf.org/html/rfc691= 9#section-6

This feels a little wishy-washy for some= thing I think we could tie-break without
too much delay.

Jacob, Clint, and myself all stated support for removing i= t. You're OK with
dropping it. I think Alan is in a similar m= id-point camp. (Please weigh in if
I'm mis-characterizing)

Do= es anyone else feel strongly? Can we aim for consensus for=C2=A0
Monday?=


On Thu, Feb 16, 2017 = at 5:44 PM, Richard Barnes <rlb@ipv.sx> wrote:


On Thu, Feb 16, 2017 at 4:24 PM, Daniel McCarney <cpu@letsencrypt.org> wrote:
I'm supportive of removing = the server pinning headers SHOULD outright.

> but how b= est to word that i don't know

I don'= ;t think there's much benefit in the ACME spec discussing pinning from<= /div>
a client perspective.

If the clients wan= t to pin there isn't anything about ACME that makes the
proce= ss different than (for e.g.) using square's okhttp library to pin for a= ny
other HTTPS server. Am I overlooking something?

There's nothing different.=C2=A0 T= he idea here was just to point people to some mechanisms they could use to = guard against mis-issuance.=C2=A0 I'm OK dropping it if people don'= t like it, but I would kind of like to keep it.=C2=A0

Pe= rhaps we could downgrade to MAY WISH TO
https://tools.ietf.org/html/rf<= wbr>c6919#section-6
=C2=A0


=C2=A0


On Mon, Feb 13, 2017 at 3:29 PM, Alan Doherty <= ietf@alandoherty.net> wrote:
I would concur that clients should endeavour to suppor= t

(and thusly CAs can consider using in future, when support is available in = wider librarys)

but because of the risks they should only consider doing so
if/when all their processes are in place to ensure failures can't occur=

but how best to word that i don't know

At 20:09 13/02/2017=C2=A0 Monday, Clint Wilson wrote:
>I would definitely support removing ", and servers SHOULD emit pin= ning headers", especially because of the footgun risk you indicated, b= ut I think there is some merit in continuing to recommend support for HPKP = on the client side.
>
>On Mon, Feb 13, 2017 at 12:33 PM Jacob Hoffman-Andrews <= ;<mailto:jsha@eff.org<= /a>>jsha@eff.org<= /a>> wrote:
>Martin brought up a section I've been considering removing:
>
>> Clients SHOULD support HTTP public key pinning [RFC7469], and serv= ers
>SHOULD emit pinning headers.
>
>Here's my reasoning:
>
>- Public key pinning isn't implemented in most HTTPS libraries outs= ide
>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 woul= d
>be that some of those clients would fail to renew their certs, causing<= br> >cascading breakage.
>- There is relatively little confidential information conveyed in ACME,=
>and there are other defenses built into ACME (like including the accoun= t
>key as part of the challenge data), so HPKP is not strongly necessary.<= br> >
>Any objections?
>
>PR to remove: <https://github.com/ietf-wg= -acme/acme/pull/244>https://github.com= /ietf-wg-acme/acme/pull/244
>
>_______________________________________________
>Acme mailing list
><mailto:Acme@ietf= .org>Acme@ie= tf.org
>https://www.ietf.org/mailman/listinfo/acme
>
>_______________________________________________
>Acme mailing list
>Acme@ietf.org >https://www.ietf.org/mailman/listinfo/acme
_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme


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




--001a113eae76d30f8b0548bd5a83-- From nobody Fri Feb 17 09:38:21 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A492E129AE5 for ; Fri, 17 Feb 2017 09:38:19 -0800 (PST) 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, 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 UxgySIOrxMmU for ; Fri, 17 Feb 2017 09:38:18 -0800 (PST) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::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 382B312957B for ; Fri, 17 Feb 2017 09:38:18 -0800 (PST) Received: by mail-oi0-x229.google.com with SMTP id 62so14213878oih.2 for ; Fri, 17 Feb 2017 09:38:18 -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; bh=EYwtMvZ8pE2QKoaWdcudeQ/eEO97Rm6x7+QQ5tyAFp0=; b=WptIanAhIP577iW8OnKwhWMJ6WodAPXVoejHy0WEAj38Ys/Z6aGQEv1PQQPj9iK0nc Jxutjj7kEzq0M766UzpZxlWQ4+N3iRGtQfZUYiEV2pJy2yXOatx0Dy3hnRRoU8gi1Luu eqiRxLjVBiW6lIVi7laVispbq3KJ31EuBCrnSjH4+HgE6l2GYTEWIV+DXz9C6CAOfAA+ tZqEmbITGkIihP2UZUYVje+2+ZLq/XGyteYblhykJHwyq/No/nQ/HlnIHRjfP8lUaTDh Rz/WbhM0d22o8PLyWbai5eUa+voH8hNiSK/24GJqGynYJokkGf/8yfvQYE1YUBpyM/6D /PTw== 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=EYwtMvZ8pE2QKoaWdcudeQ/eEO97Rm6x7+QQ5tyAFp0=; b=Tqe+hjUPOifIUSi6GJCM9L2v/q/eb7tWG7uVgxQgsjrNBQKQvFyxwKqYA4JkzA+kCw WhTsY+7xVrcg4Znawu0Omr6o35Zpc9yEfdmbcknP1FdMLf2DbIP+QdV1ilBWzfjGyUqg HNAYw7bbyP0GN4GVFPtXiqUMcbnbrCZs8YETR7TNoRDJg3NclxFnAKGaw+MP8fExnNn8 81osBttYSvdGaFQK3mh7UW/S8NOX7M9XmzugE231lB29JqOLNLuMOvQa5xxil2KF3W9v HZIwko7lPTL1Ag6kJqJ90ti8lsE2StJE+HOGy+pna/wwFzk74vLojQ0gb4CaOqO1K7AI qAvg== X-Gm-Message-State: AMke39lmXji9gnCoZMvg3JWys3Isi1lTt+6brvbTCaAYZUbhBAT3ERZkYPMQyfTt0G50pfTocz2tZpml5phYaw== X-Received: by 10.202.244.131 with SMTP id s125mr4288612oih.136.1487353097429; Fri, 17 Feb 2017 09:38:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.13.20 with HTTP; Fri, 17 Feb 2017 09:38:16 -0800 (PST) Received: by 10.157.13.20 with HTTP; Fri, 17 Feb 2017 09:38:16 -0800 (PST) In-Reply-To: References: <81377754-e24d-269d-0f48-ba37e55f8942@eff.org> From: Josh Soref Date: Fri, 17 Feb 2017 12:38:16 -0500 Message-ID: To: acme@ietf.org Content-Type: multipart/alternative; boundary=001a1134e590072b7a0548bd617d Archived-At: 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, 17 Feb 2017 17:38:19 -0000 --001a1134e590072b7a0548bd617d Content-Type: text/plain; charset=UTF-8 Fwiw, I'm slowly reviewing[1] the specification. Personally, for this version I'd be +1 on dropping the current pinning text. If you wanted to go with a weak statement, I think the statements you want are: 1. Acme clients may support key pinning. 2. If an Acme client supports pinning, it should provide a way to enable users to drop pins. This enables servers to experiment without saying that any will. [1] https://github.com/jsoref/acme/tree/review --001a1134e590072b7a0548bd617d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Fwiw, I'm slowly revi= ewing[1] the specification.

Personally, for this = version I'd be +1 on dropping the current pinning text.=C2=A0

If you wanted to go with a weak statement, I think the statement= s you want are:
1. Acme client= s may support key pinning.
2. = If an Acme client supports pinning, it should provide a way to enable users= to drop pins.

This enables servers to experiment witho= ut saying that any will.

<= /div>
[1]=C2=A0https://github.com/jsoref/acme/tree/review
--001a1134e590072b7a0548bd617d-- From nobody Fri Feb 17 09: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 D5364129B02 for ; Fri, 17 Feb 2017 09:54:02 -0800 (PST) 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 Y1FE_4xxM_v1 for ; Fri, 17 Feb 2017 09:54:01 -0800 (PST) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::12]) (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 A7BFE129AFD for ; Fri, 17 Feb 2017 09:54:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1487354038; l=1657; s=domk; d=kelunik.com; h=Content-Type:To:Subject:Date:From:MIME-Version; bh=mKgrydajMtqk49xbsqkG2TQwB9x8h5c+u9aSSrN+SBw=; b=B1gCMWWXSxIr0V9LIJglfQrcQ6QzyRerRFUxEOaYQQlpDo2Xs7DPqn4zBJiq+ZIE9q oI23kO7h1NxAZ7y2UIaIALNbdey1Wik2IphQLt3Mc1TLZW6CTMAyalS3lp8oYpuxJlc+ LC/48CfNXGX8VguxT+F3yQATZodxdzCttOpEA= X-RZG-AUTH: :IWkkfkWkbvHsXQGmRYmUo9mls2vWuiu+7SLDup6E67mzuoNJBqD/tRU= X-RZG-CLASS-ID: mo00 Received: from mail-qt0-f175.google.com ([209.85.216.175]) by smtp.strato.de (RZmta 39.12 AUTH) with ESMTPSA id a09f88t1HHrvhz8 (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 ; Fri, 17 Feb 2017 18:53:57 +0100 (CET) Received: by mail-qt0-f175.google.com with SMTP id v23so46678446qtb.0 for ; Fri, 17 Feb 2017 09:53:57 -0800 (PST) X-Gm-Message-State: AMke39kN7pxWmlRa67qnEfKxHRMoJ5BOA/RpbkKOi3+55+b+Lj+PlNCvL8uMq6zj7rSRFF4LBOP38Ugx9ttB5A== X-Received: by 10.200.48.14 with SMTP id f14mr8299456qte.236.1487354037051; Fri, 17 Feb 2017 09:53:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.144.132 with HTTP; Fri, 17 Feb 2017 09:53:56 -0800 (PST) From: Niklas Keller Date: Fri, 17 Feb 2017 18:53:56 +0100 X-Gmail-Original-Message-ID: Message-ID: To: IETF ACME Content-Type: multipart/alternative; boundary=001a1149c5f208d3d50548bd996c Archived-At: Subject: [Acme] 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: Fri, 17 Feb 2017 17:54:03 -0000 --001a1149c5f208d3d50548bd996c Content-Type: text/plain; charset=UTF-8 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 --001a1149c5f208d3d50548bd996c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Morning,

the current draft contains a f= ew inconsistencies in the resource naming.

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

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

Maybe we should the= n also rename "authz" to "authorization" and "cert= " to "certificate" everywhere.

Rega= rds, Niklas
--001a1149c5f208d3d50548bd996c-- From nobody Fri Feb 17 12:17:13 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 357DD129692 for ; Fri, 17 Feb 2017 12:17:12 -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, 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 RT1HN6Qg9vYN for ; Fri, 17 Feb 2017 12:17:10 -0800 (PST) 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 83BDD129642 for ; Fri, 17 Feb 2017 12:17:10 -0800 (PST) Received: by mail-pf0-x22c.google.com with SMTP id 68so4862683pfx.2 for ; Fri, 17 Feb 2017 12:17:10 -0800 (PST) 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=4yeSd0ZWwC+cp3UbZdJYj6Oor7UBfqVTF20KZEOdnWs=; b=dwSPdEakrqIUl44P8y3wlyfN2CGZktdR0NTLRX/ynlNd8NA2DY4KW735uk2RQLPx9Z KYMRAXtM6a4Qm08EqAmoE+tCRqoXj+PxgksD1KMh62zaFkYC94VfvJ8VqlOYujLfRH25 UNhQ4y6tM9WKRJIbRAIzcpMF2r/Fga/R3pVpc= 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=4yeSd0ZWwC+cp3UbZdJYj6Oor7UBfqVTF20KZEOdnWs=; b=TVIHJKHlyprvolyiEwOnbHTLlxZFyVtID+h6IaljLehnuaRrtW1IeuWKbCgMvFi7I9 Xvb+4PJQewZJwWdXSoiBZlWIDg6guYzybG+p4vonbAi4iC731vB9/bvJ7GbPnMkEK0tG lvwuC0unCus7HVBV0P0qopZbZvqOKAIDbE0FwlxZDsM+Ct8C3wttqSQFhSZbCtplxmal fdig8xDrr/yBTmdjypzlol1s8xYLoj9w7eVpTvZT/LPnVpLtGeJJQtB9qhDSXT7SrDJm HXYrw16ukcXZ6ETNTFvLSRd9Aim8GuH1ZRYip+EIKQBR0w8wO8JF7PJ8LgtB8AeS+j7c kL1A== X-Gm-Message-State: AMke39mJIiqYBdwevyhfm18bramd+rFYVdtQNs1685f4GGI2xa3o/ZPxgW2LwJyBoPNPy4pa X-Received: by 10.84.238.199 with SMTP id l7mr13607243pln.90.1487362629701; Fri, 17 Feb 2017 12:17:09 -0800 (PST) Received: from [192.168.42.66] ([50.1.57.147]) by smtp.gmail.com with ESMTPSA id i82sm21144098pfk.52.2017.02.17.12.17.08 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Feb 2017 12:17:09 -0800 (PST) To: "acme@ietf.org" From: Roland Bracewell Shoemaker Message-ID: <18706ad4-2fa2-8a8a-600b-207a719e8491@letsencrypt.org> Date: Fri, 17 Feb 2017 12:17:05 -0800 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 Archived-At: Subject: [Acme] Remove extraneous key equivalence method 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, 17 Feb 2017 20:17:12 -0000 The spec currently defines an entirely new JWK key equivalence method which is then only used once. Instead of adding this new method (which seems to just be a the JWK thumbprint computation minus the use of a digest) I propose we just re-work the key roll-over method to work without having to compare the 'newKey' and the key used to sign the inner JWS. The simplest method here seems to be to just check that the 'newKey' also verifies the inner JWS. Proposed change here: https://github.com/ietf-wg-acme/acme/pull/263 From nobody Fri Feb 17 12:32:37 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E66F7129B76 for ; Fri, 17 Feb 2017 12:32:35 -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, 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 4oKv70Vqucae for ; Fri, 17 Feb 2017 12:32:34 -0800 (PST) Received: from mail-pg0-x244.google.com (mail-pg0-x244.google.com [IPv6:2607:f8b0:400e:c05::244]) (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 75DAB129692 for ; Fri, 17 Feb 2017 12:32:34 -0800 (PST) Received: by mail-pg0-x244.google.com with SMTP id y6so4629736pgy.2 for ; Fri, 17 Feb 2017 12:32:34 -0800 (PST) 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=vY7RVKYA0Or95Nc3VdwMCoyYgIZ1N98+WbcVstt6AKg=; b=cfBMfNE2x2OtPdtemhRTXSSAdPfi0+qsRVjYOR7laTbHx70i71vBL3ugL1emfevoaD Y+MRB67ggzChRPbtNAkiCx1RRbleUq6ioe73af0OxdjgTYj5sOodfMFv27sr365sLH3n N7xqfyniVFB5z8BsR2YqSL8mkc1J2nje5Tqdw= 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=vY7RVKYA0Or95Nc3VdwMCoyYgIZ1N98+WbcVstt6AKg=; b=p3ec59sqHbo7URpceRf0fVKz9usAFH4pW9Od+qayr8XVwRpg7g15tMNwCdu8msAq25 CaUquqE813sfGrGACx1Tq/8YDUEhQzP5hBBa/cp54WhTPj3RAcR4i71qWHGktPOXnE/5 +/Lhw7DH9BA3HLC4MEQSE0mva6p/3dnj5i/tpbybFQ17oRTaX/rn4jy2agm1L0AulElk 1RlOJc18Ch2NSxk/YjvPEBklXBVNQ/jOPCDWzUPMv8/yfREyy1vIjlBzuFFU/JgYPsJS 1MuFPPCsI9UJ8WPWYKoM8fcm1EFoYrKXg6Wrmu7/oGdDOXhHqjykGouBQ23kbs6Etr3a ogMA== X-Gm-Message-State: AMke39ntmR1lTMx2pJi1CcqjvVpKAyW5V2e5hPXPUFL6s1wz5thfKVIYGBirVEOg5ZfQyPpN X-Received: by 10.99.67.130 with SMTP id q124mr12434452pga.221.1487363553829; Fri, 17 Feb 2017 12:32:33 -0800 (PST) Received: from [192.168.42.66] ([50.1.57.147]) by smtp.gmail.com with ESMTPSA id a25sm21318429pgd.26.2017.02.17.12.32.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Feb 2017 12:32:33 -0800 (PST) To: cpu@letsencrypt.org References: From: Roland Bracewell Shoemaker Message-ID: Date: Fri, 17 Feb 2017 12:32:27 -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=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "acme@ietf.org" Subject: Re: [Acme] Clarifying what to do with revocation requests with disallowed reasonCodes 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, 17 Feb 2017 20:32:36 -0000 We could add a new error type and accompany the problem document with an extra field that defines the valid reason codes à la the 'alg' field that is added when we return 'badSignatureAlgorithm'. On 02/16/2017 08:16 AM, Daniel McCarney wrote: > +1 - I think this is clearer. > > Would you be open to specifying what form the rejection takes? Do you > think it > would be advantageous to specify a new error in Section 5.7 for the purpose > (e.g. `urn:ietf:params:acme:error:invalidReasonCode`) or is there an > existing > candidate you'd use? > > > On Tue, Feb 14, 2017 at 5:53 PM, Roland Bracewell Shoemaker > > wrote: > > The current draft leaves it ambiguous as to what the server should do > when a it receives a revocation request containing a reasonCode that it > disallows. I suggest we add a simple 'MUST reject request' clause to the > relevant section to resolve this ambiguity. > > PR: https://github.com/ietf-wg-acme/acme/pull/251 > > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > > > From nobody Fri Feb 17 13:02: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 D1D98129A7A for ; Fri, 17 Feb 2017 13:02:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.002 X-Spam-Level: X-Spam-Status: No, score=-7.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m8pkfIOAjivm for ; Fri, 17 Feb 2017 13:02:09 -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 A74A4129BE1 for ; Fri, 17 Feb 2017 13:02:09 -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:MIME-Version:Date:Message-ID:Subject:From:To; bh=T9+9BFmN/jfPwwlzl1F76/9JuXMKCx3BBl5sqSi6tYI=; b=VuTWu67RC0gNU6sGk2jlOD8T0EwOW3qhzVdFQvcBJO2ZFTSG09beND8YbzeV+/p5m7aCzzKOEVk8TnOmX8/mtP4jo7gQ8ysk8sTy28bqGwhbMNN0rmsseCHF1wfRaqnDMyANnQc4qsfxCsWz33TsuAUwTazzPcY4r3aa3CU88ZM=; Received: ; Fri, 17 Feb 2017 13:02:11 -0800 To: "acme@ietf.org" From: Jacob Hoffman-Andrews Message-ID: <807854cf-a388-4729-e292-5daac236d82a@eff.org> Date: Fri, 17 Feb 2017 13:02:07 -0800 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 Archived-At: Subject: [Acme] Split up errors and add an error field to orders 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, 17 Feb 2017 21:02:12 -0000 https://github.com/ietf-wg-acme/acme/pull/264 Removes dnssec error type for a broader "dns" error type. It's very hard to split out dnssec errors from regular dns problems, because recursive resolvers can only return SERVFAIL. The new dns error type also subsumes "unknownHost." Introduces a new "incorrectResponse" error type for cases where connection and request were both successful, but the content didn't match. This also splits out the error table by the places they tend to occur: In response to ACME requests, or in the "error" field of authorization objects. Introduces an error field for orders. Orders can fail independent of authorizations because of last-minute CAA checking, failure to submit to CT logs, timeouts, etc. >From 7678e4ce122456c8d7c609a3fff99ebfe1ad865b Mon Sep 17 00:00:00 2001 From: Jacob Hoffman-Andrews Date: Fri, 17 Feb 2017 12:52:07 -0800 Subject: [PATCH] Split up errors and add an error field to orders. --- draft-ietf-acme-acme.md | 32 ++++++++++++++++++++++++-------- 1 file changed, 24 insertions(+), 8 deletions(-) diff --git a/draft-ietf-acme-acme.md b/draft-ietf-acme-acme.md index 87810ea..ecbdd1a 100644 --- a/draft-ietf-acme-acme.md +++ b/draft-ietf-acme-acme.md @@ -479,28 +479,38 @@ server MAY return status code 405 (Method Not Allowed). When the server responds with an error status, it SHOULD provide additional information using problem document {{!RFC7807}}. To facilitate automatic response to errors, this document defines the following standard tokens for use -in the "type" field (within the "urn:ietf:params:acme:error:" namespace): +in the "type" field (within the "urn:ietf:params:acme:error:" namespace). + +Error types that may be commonly returned from ACME requests: | Type | Description | |:----------------------|:-------------------------------------------------------------------| | badCSR | The CSR is unacceptable (e.g., due to a short key) | | badNonce | The client sent an unacceptable anti-replay nonce | | badSignatureAlgorithm | The JWS was signed with an algorithm the server does not support | -| caa | CAA records forbid the CA from issuing | -| connection | The server could not connect to validation target | -| dnssec | DNSSEC validation failed | | invalidContact | The contact URI for an account was invalid | | malformed | The request message was malformed | | rateLimited | The request exceeds a rate limit | | rejectedIdentifier | The server will not issue for the identifier | | serverInternal | The server experienced an internal error | -| tls | The server received a TLS error during validation | | unauthorized | The client lacks sufficient authorization | -| unknownHost | The server could not resolve a domain name | | unsupportedIdentifier | Identifier is not supported, but may be in future | -| userActionRequired | The user visit the "instance" URL and take actions specified there | +| userActionRequired | Visit the "instance" URL and take actions specified there | + +Error types that may be commonly included in the "error" field of challenge +resources: + +| Code | Description | +|:----------------------|:-------------------------------------------------------------------| +| caa | CAA records forbid the CA from issuing | +| connection | The server could not connect to validation target | +| dns | There was a problem with a DNS query during validation | +| rateLimited | The request exceeds a rate limit | +| serverInternal | The server experienced an internal error | +| incorrectResponse | Response received didn't match the challenge's requirements | +| tls | The server received a TLS error during validation | -This list is not exhaustive. The server MAY return errors whose "type" field is +These lists are not exhaustive. The server MAY return errors whose "type" field is set to a URI other than those defined above. Servers MUST NOT use the ACME URN namespace for errors other than the standard types. Clients SHOULD display the "detail" field of all errors. @@ -765,6 +775,12 @@ notAfter (optional, string): : The requested value of the notAfter field in the certificate, in the date format defined in {{!RFC3339}}. +error (optional, object): +: The error that occurred while the server was issuing the certificate, if any. +This field is structured as a problem document {{!RFC7807}}. Note that +this field is only for errors occurring after authorizations have been +validated. + authorizations (required, array of string): : For pending orders, the authorizations that the client needs to complete before the requested certificate can be issued (see From nobody Fri Feb 17 14:41: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 1510D129420 for ; Fri, 17 Feb 2017 14:41:41 -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, 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 clC-cU9TahEp for ; Fri, 17 Feb 2017 14:41:38 -0800 (PST) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::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 77D821296DD for ; Fri, 17 Feb 2017 14:41:38 -0800 (PST) Received: by mail-pf0-x230.google.com with SMTP id c73so16368151pfb.0 for ; Fri, 17 Feb 2017 14:41:38 -0800 (PST) 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=76nT3tT+OBdJbo5q6dgluqQlaluOLbgrxrcZgmlG7M4=; b=X7Zsi6Bi/kQ1OrxzqW6PQ+uUPG2Goa2kjvdhHFdj4bM2Tv9Wd//07s38FdRZ/yhMDC yenxzs/Q2h+aqH5PU0aq8zTQS7yhP3Z+HvOFIBLK/Zs37gtnLPvJPnE92Ix0fy5rNG/O +EjJqhFtskKfXyV0zqIAwvmbHXLu5lK114D4I= 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=76nT3tT+OBdJbo5q6dgluqQlaluOLbgrxrcZgmlG7M4=; b=ecJse6CBT7umir5dMX99EA9+n4R9H41PqteIqHnwf/0sWu5KpdKocxqqZS1B2N5R2B WJW7RZDx0l0LMxcbHXNMuTyC46nVHx12r8gEK1uxnNvbEtlwGs3ukDEbv7qaQGb4j3Yp g7UziV2p3NLj2HhigyJJGiBq95oQEFpEkXhchuBfvcwCLrPI8H79nAyInQq3mtI6WPpn WEYzPnFmBJTl8lTLJnxHTJzNirlI7Lj8txjfD+OHFrY9+2Qsmz2RgQwZI4eRJSFW/bJI ux1UzPLhuNdwbWdJd+uLCkcObR8SLyYpmFlxJbaMTj+AkrN3JWcnjlz7NTYkTSyfVNUz wv8Q== X-Gm-Message-State: AMke39k63qVjU35liaGmi/GqK3izc5kGfNP7b05Vh9R98pwViidNVB/Uz+9xwA3Zh8xET8oY X-Received: by 10.99.144.201 with SMTP id a192mr12893024pge.187.1487371297507; Fri, 17 Feb 2017 14:41:37 -0800 (PST) Received: from [192.168.42.66] ([50.1.57.147]) by smtp.gmail.com with ESMTPSA id c18sm21399543pfj.49.2017.02.17.14.41.36 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Feb 2017 14:41:36 -0800 (PST) To: acme@ietf.org References: <807854cf-a388-4729-e292-5daac236d82a@eff.org> From: Roland Bracewell Shoemaker Message-ID: <1ab4fa7f-d4c9-1fe8-0b70-9dbb6ffe93d6@letsencrypt.org> Date: Fri, 17 Feb 2017 14:41:34 -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: <807854cf-a388-4729-e292-5daac236d82a@eff.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Acme] Split up errors and add an error field to orders 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, 17 Feb 2017 22:41:41 -0000 +1 this seems like a good change. I've left one typo comment on the PR (code -> type). Splitting the tables up based on where the errors may be encountered is useful but adding the new 'error' field to the order object makes this slightly confusing. Will the errors on the order be from the first table or the second, or an entirely different set? On 02/17/2017 01:02 PM, Jacob Hoffman-Andrews wrote: > https://github.com/ietf-wg-acme/acme/pull/264 > > Removes dnssec error type for a broader "dns" error type. It's very hard > to split out dnssec errors from regular dns problems, because recursive > resolvers can only return SERVFAIL. The new dns error type also subsumes > "unknownHost." > > Introduces a new "incorrectResponse" error type for cases where > connection and request were both successful, but the content didn't match. > > This also splits out the error table by the places they tend to occur: > In response to ACME requests, or in the "error" field of authorization > objects. > > Introduces an error field for orders. Orders can fail independent of > authorizations because of last-minute CAA checking, failure to submit to > CT logs, timeouts, etc. > >>From 7678e4ce122456c8d7c609a3fff99ebfe1ad865b Mon Sep 17 00:00:00 2001 > From: Jacob Hoffman-Andrews > Date: Fri, 17 Feb 2017 12:52:07 -0800 > Subject: [PATCH] Split up errors and add an error field to orders. > > --- > draft-ietf-acme-acme.md | 32 ++++++++++++++++++++++++-------- > 1 file changed, 24 insertions(+), 8 deletions(-) > > diff --git a/draft-ietf-acme-acme.md b/draft-ietf-acme-acme.md > index 87810ea..ecbdd1a 100644 > --- a/draft-ietf-acme-acme.md > +++ b/draft-ietf-acme-acme.md > @@ -479,28 +479,38 @@ server MAY return status code 405 (Method Not Allowed). > When the server responds with an error status, it SHOULD provide additional > information using problem document {{!RFC7807}}. To facilitate automatic > response to errors, this document defines the following standard tokens for use > -in the "type" field (within the "urn:ietf:params:acme:error:" namespace): > +in the "type" field (within the "urn:ietf:params:acme:error:" namespace). > + > +Error types that may be commonly returned from ACME requests: > > | Type | Description | > |:----------------------|:-------------------------------------------------------------------| > | badCSR | The CSR is unacceptable (e.g., due to a short key) | > | badNonce | The client sent an unacceptable anti-replay nonce | > | badSignatureAlgorithm | The JWS was signed with an algorithm the server does not support | > -| caa | CAA records forbid the CA from issuing | > -| connection | The server could not connect to validation target | > -| dnssec | DNSSEC validation failed | > | invalidContact | The contact URI for an account was invalid | > | malformed | The request message was malformed | > | rateLimited | The request exceeds a rate limit | > | rejectedIdentifier | The server will not issue for the identifier | > | serverInternal | The server experienced an internal error | > -| tls | The server received a TLS error during validation | > | unauthorized | The client lacks sufficient authorization | > -| unknownHost | The server could not resolve a domain name | > | unsupportedIdentifier | Identifier is not supported, but may be in future | > -| userActionRequired | The user visit the "instance" URL and take actions specified there | > +| userActionRequired | Visit the "instance" URL and take actions specified there | > + > +Error types that may be commonly included in the "error" field of challenge > +resources: > + > +| Code | Description | > +|:----------------------|:-------------------------------------------------------------------| > +| caa | CAA records forbid the CA from issuing | > +| connection | The server could not connect to validation target | > +| dns | There was a problem with a DNS query during validation | > +| rateLimited | The request exceeds a rate limit | > +| serverInternal | The server experienced an internal error | > +| incorrectResponse | Response received didn't match the challenge's requirements | > +| tls | The server received a TLS error during validation | > > -This list is not exhaustive. The server MAY return errors whose "type" field is > +These lists are not exhaustive. The server MAY return errors whose "type" field is > set to a URI other than those defined above. Servers MUST NOT use the ACME URN > namespace for errors other than the standard types. Clients SHOULD display the > "detail" field of all errors. > @@ -765,6 +775,12 @@ notAfter (optional, string): > : The requested value of the notAfter field in the certificate, in the date > format defined in {{!RFC3339}}. > > +error (optional, object): > +: The error that occurred while the server was issuing the certificate, if any. > +This field is structured as a problem document {{!RFC7807}}. Note that > +this field is only for errors occurring after authorizations have been > +validated. > + > authorizations (required, array of string): > : For pending orders, the authorizations that the client needs to complete > before the requested certificate can be issued (see > > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > From nobody Fri Feb 17 14:44: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 02D60129C50 for ; Fri, 17 Feb 2017 14:44:57 -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, 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 3nsCBlXVhy3P for ; Fri, 17 Feb 2017 14:44:56 -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 53007129C4E for ; Fri, 17 Feb 2017 14:44:56 -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:References:To:Subject; bh=yemvjDehWc9RFIZJ47OMqiKEjF8b8uxanBq5FZEb3Ew=; b=znBZLFCgmYSkVxFSXC64yFWr3Q/fxWd/Of2QNl5IEaBv6Ta99o28n8+lDh7CcUR5rdQ6H/LNUNBqKZMzjL0t1sG6/yNyxZqYazKvjJVSn4OTliUKBdfB0WGS7l3MTXNd+jwcx+jW+y6qynTpGsW90ymJ/fKi73ghw8h3cOqjP60=; Received: ; Fri, 17 Feb 2017 14:44:57 -0800 To: Roland Bracewell Shoemaker , acme@ietf.org References: <807854cf-a388-4729-e292-5daac236d82a@eff.org> <1ab4fa7f-d4c9-1fe8-0b70-9dbb6ffe93d6@letsencrypt.org> From: Jacob Hoffman-Andrews Message-ID: Date: Fri, 17 Feb 2017 14:44:55 -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: <1ab4fa7f-d4c9-1fe8-0b70-9dbb6ffe93d6@letsencrypt.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Acme] Split up errors and add an error field to orders 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, 17 Feb 2017 22:44:57 -0000 On 02/17/2017 02:41 PM, Roland Bracewell Shoemaker wrote: > Splitting the tables up based on where the errors may be encountered is > useful but adding the new 'error' field to the order object makes this > slightly confusing. Will the errors on the order be from the first table > or the second, or an entirely different set? Good point. I added a short section of errors likely to happen at issuance time (caa and serverInternal). From nobody Sat Feb 18 02:07: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 F393D12941D for ; Sat, 18 Feb 2017 02:07:26 -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 CTBWbUZ9G2IL for ; Sat, 18 Feb 2017 02:07:25 -0800 (PST) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::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 68A50129405 for ; Sat, 18 Feb 2017 02:07:25 -0800 (PST) Received: by mail-qt0-x229.google.com with SMTP id w20so57781973qtb.1 for ; Sat, 18 Feb 2017 02:07:25 -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=oMgfCyW/kKbHYkJd980wpm/qZHcm56Ck9HxUoULjY7s=; b=igEIn9VE8Qdb5nIXq4GsRctj3vJ8LApm2Qm8B25GZHBbWAqaQ5iexAO0QnqKZKiu27 I6ufg31NoQsE0UngwVrCTYNZOsy7RLtJBveHk8n9U+VPQHtkrCoPd3xH9llNDfyIEb0R goSpPreH2m3Hnl4azdOG4J+rletaJTuP+QRgPiYHtuZO+Fb7U1pmCvn0fX2/OaqTEH7F NgBZsWVZCOlk87mHQVBn1YPs69u/pvJldDe7y0HEsb+ET1HUAh2z2UNOBMOTZ79hB8xX GnjF6c8Gx5FTIFeBBJ1vcl3eKf+pYEXT8MedwOAa4AhwPEvvSL/fkoc7laJ4GjVB2cPi wpug== 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=oMgfCyW/kKbHYkJd980wpm/qZHcm56Ck9HxUoULjY7s=; b=nOpVFcRGvuiCSn5Uj4RaRPBuTBmkSzHuKYBA4kv+jZ1rg5LYp4V+L8IM3nnBs95dlV 0nygQT7r9h96VdjuXa5GSiMMvhBY90biTVyzjaQFsVpiSo+IkmqxzJwirAFjE5+r5McN TJVgRuwN83O5XQhVeDoXtvNVw52ADKaDaqJGNDaTDY5+lI4gUy44e/LLMtggtaroL8l7 9fJUMHN+vrJlfDHvf2fy6PQIhE6WgpW3TjapPxnctSvRFnG4W3hllPc+nYearA4Am4E1 Jg/yMsiLqwl0VD+b3yka28gmmG5eKL5Zg59jmVwQvr0HHFzoyXflNuqKaffVQAdyP4UA lbWA== X-Gm-Message-State: AMke39l5W7BMPp09qANwvoV5YZ/lq0rKnsdqTOKFHHv+yW4EfclUTPNESChk6RvQeEV0i1AU/2PcKKQPBPj2eg== X-Received: by 10.237.55.97 with SMTP id i88mr12363788qtb.143.1487412444534; Sat, 18 Feb 2017 02:07:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Sat, 18 Feb 2017 02:07:24 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Sat, 18 Feb 2017 21:07:24 +1100 Message-ID: To: Josh Soref Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "acme@ietf.org" Subject: Re: [Acme] UX design by standards 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, 18 Feb 2017 10:07:27 -0000 On 18 February 2017 at 00:42, Josh Soref wrote: > > I'm reminded ... there was one specification (i can't remember if it > was Cookie, HTTP, or HTML) which had a UAs must tell users about > something (redirects? cookies?). HTTP did, at one time have such text. I would agree with you that attempting to push messages on users is foolish. Record the details in a log, sure, but trying to find a user, that's not gonna happen if you are running acme clients on 1000s of machines. From nobody Sat Feb 18 10:40:25 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 126221295AB for ; Sat, 18 Feb 2017 10:40:24 -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, 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 pXa9j1cG6Gpi for ; Sat, 18 Feb 2017 10:40:23 -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 369A7129480 for ; Sat, 18 Feb 2017 10:40:23 -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=6xkJiHj/FS3FCIe+WqF66gfFqR/88LIcJXZRiVIH178=; b=jgaB63LDGFMiIK6jPSppYpQfaSPRCWWRMWx8C7KhykaVA5Th6hnxk+E+3XKGsX7rL+MlaCChhO5isOMV8X1Phd742OGMkxkn4inVD9uPdWMRwPpsT9OuCJX11UpTpKbbtXxt5atAkF3jL4g3MD6ll+Z5MafgK1lE40BHWsX1n64=; Received: ; Sat, 18 Feb 2017 10:40:24 -0800 To: Martin Thomson , Josh Soref References: From: Jacob Hoffman-Andrews Message-ID: <65b336a0-0c71-0f31-5c1d-5f96d13d81cf@eff.org> Date: Sat, 18 Feb 2017 10:40:22 -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 Archived-At: Cc: "acme@ietf.org" Subject: Re: [Acme] UX design by standards 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, 18 Feb 2017 18:40:24 -0000 On 02/18/2017 02:07 AM, Martin Thomson wrote: > On 18 February 2017 at 00:42, Josh Soref wrote: >> I'm reminded ... there was one specification (i can't remember if it >> was Cookie, HTTP, or HTML) which had a UAs must tell users about >> something (redirects? cookies?). > > HTTP did, at one time have such text. I would agree with you that > attempting to push messages on users is foolish. Record the details > in a log, sure, but trying to find a user, that's not gonna happen if > you are running acme clients on 1000s of machines. This is a fair point. The language here is in response to one client that is interactive, but chose to display the "Description" from the errors table rather than the detail field. This was a problem because one error type can manifest with a lot of different details, so exposing the detail field to the end user in some way is critical. I don't think it matters whether the end user interacts primarily through log aggregation or interactively. Do you have proposed alternate langauge, given the above? From nobody Sat Feb 18 11:07: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 77F18129451 for ; Sat, 18 Feb 2017 11:07:36 -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, 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 4ou8FoszZ9fd for ; Sat, 18 Feb 2017 11:07:34 -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 80C4E1294DB for ; Sat, 18 Feb 2017 11:07:34 -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:MIME-Version:Date:Message-ID:Subject:From:To; bh=illjJYy3aEF/FS/vpkbEV0Q91Asjhv2kTzwwz8pPr4c=; b=blXksnOT1Q1CxtMbyiQeCNnjlSffCAvmyhyse+KSPFp1mI+FOJvCGffkPcMmu2QSfjX6BrdUB9Ss2BzcLzqHqUkCPYEEhngzZQoh266Ym2XV3jCW2P4bPkNy8FDdhWvO4HFkuk7umMSy/bePo3jmJ9R0Qsh6NnTwrgnerQ/7264=; Received: ; Sat, 18 Feb 2017 11:07:35 -0800 To: "acme@ietf.org" From: Jacob Hoffman-Andrews Message-ID: <49151890-f140-71bd-3124-70aa2ffaf860@eff.org> Date: Sat, 18 Feb 2017 11:07:33 -0800 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 Archived-At: Subject: [Acme] Removing public-key echo in account objects 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, 18 Feb 2017 19:07:36 -0000 Right now, account objects echo back the public key associated with the account, in the "key" field. However, this is redundant since the only request types that can return an account object are signed by the corresponding private key, so the client necessarily knows what its public key is. Removing this simplifies the spec somewhat. https://github.com/ietf-wg-acme/acme/pull/266 Thoughts? From nobody Sat Feb 18 18:07: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 63C841293D6 for ; Sat, 18 Feb 2017 18:07:33 -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 bDpqST7kx494 for ; Sat, 18 Feb 2017 18:07:32 -0800 (PST) Received: from mail-ot0-x229.google.com (mail-ot0-x229.google.com [IPv6:2607:f8b0:4003:c0f::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 57036124281 for ; Sat, 18 Feb 2017 18:07:32 -0800 (PST) Received: by mail-ot0-x229.google.com with SMTP id 45so51622691otd.2 for ; Sat, 18 Feb 2017 18:07:32 -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=rFaKwrJovQ/UKujIixKy55BxUI2zbr5BJ4iAIfcdRfY=; b=ibzztrMnocdBnOL1oXkMwPeyR8fOry1INCTqBtHGT374sN3QU2TxrGVEXM++F6TznX RlXr3dv8zdfJ0IF68lGwBjiPgKQef6r7snY5l5OaOZBRU6M3PsZKFAzwY4rZet4LKpXB e8l3xattydjN0wxzQaVzIW4ANjD6bjWAmYQFlhfm+//X9j8TpyYtUKMwsobtk4oQX7P+ lhVOTiWmqvMch2PL/Esb2THot+e5k2uWbT7hrP3Ef131sMIZ12egUs605ulYiQ3t3pTK xpDBXF1ZfkW7tFqLRWFTc2sJr1MixsrMQTxwtSvD3wQ+lo3NDtr8z6MxFzHsmd1eETpt 6ceA== 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=rFaKwrJovQ/UKujIixKy55BxUI2zbr5BJ4iAIfcdRfY=; b=uF6rKJ9UtD+fyRfXRmV7Ad6pYhpbTKiReBDNwKOGfvHynkL7AKW0a2SE30XZonAdDU ImEFyo64mSB02tX3tX0u0L5WGOiYhi9CE1OHW6+9hBTz9mjQCNSOr+SRW2+yUoV/5p6U qvUANSghVM/cQEsoqbqZhjpDKicYf/iU0qkPT9Hf97rkFl1wPimDefkaLe3HTTh9p26U RP/fUE7k6dV6PvfbN2xfIn7hcN0pOLWF8cSIZ0edAMx9AHb2jnYY3P2NflSuN7rzqH6N I0zysUnFJdE18IdfrVjglgtub5XOefJbVNZsx6QlggI9aDAPcJP7hSglMdLoxAkxigR6 w7Uw== X-Gm-Message-State: AMke39kL9tyL6ZhxkuuqgFO30uGUNbvij5yh4gOY0eQl7mK+bm/8V7kopC0IGI1kLBP5JgXBkZUHvH5OQsaOEA== X-Received: by 10.157.7.233 with SMTP id 96mr5497688oto.264.1487470051483; Sat, 18 Feb 2017 18:07:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.13.20 with HTTP; Sat, 18 Feb 2017 18:07:31 -0800 (PST) From: Josh Soref Date: Sat, 18 Feb 2017 21:07:31 -0500 Message-ID: To: acme@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Acme] why is the status value "invalid" 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, 19 Feb 2017 02:07:33 -0000 > status (required, string): : The status of this order. Possible values are: "pending", "processing", "valid", and "invalid". > expires (optional, string): : The timestamp after which the server will consider this order invalid, > encoded in the format specified in RFC 3339 {{!RFC3339}}. Is there a reason to call that status "invalid" instead of "expired"? > This field is REQUIRED for objects with "pending" or "valid" in the status field. From nobody Sat Feb 18 18:40: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 22AD2129455 for ; Sat, 18 Feb 2017 18:40:02 -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 wy70EVKePZ1L for ; Sat, 18 Feb 2017 18:40:00 -0800 (PST) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::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 CE17B129435 for ; Sat, 18 Feb 2017 18:40:00 -0800 (PST) Received: by mail-oi0-x235.google.com with SMTP id 62so26156317oih.2 for ; Sat, 18 Feb 2017 18:40:00 -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=1cTd2oseSOzlv264mAlKPuVb9HnwRoHCv72ICjJiZOY=; b=eSaITW/cjvgjoKuWcHs4dU+6elZHNMdbmDlLe8ciK3tLibbqi/JtFfPYERzSRRYxFJ /jXLiO92cTZhnRt9m4FjGqb98M5s5sMQXzXdqD++6/AtyQ0LJHJOa5fF5PCdQSw+ebNu UPu7O0W6ewdpvmFxOMKDnTETlRSw4tv0oj+ARDFMFJQYM5luiutjPs5GQg0rRubvTQ4s htSOHerVlm/dIE5Haq+p79PuuiRLxgBX1LWJ/Qh2czR0kHdRZ1hKyDzXvRZPaZqMDqF5 BPs8gcvEIa39FZJf1G3NXIxC46/oH+EBT35JKBKhb7rSVSGDcwM7BUhBPotIp7BA4orU e2Ew== 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=1cTd2oseSOzlv264mAlKPuVb9HnwRoHCv72ICjJiZOY=; b=aL+aFur+AhOZL4EjkAPp+/ps6nDagNcM3x02qunGoV1aKDzIXU4DBwYGAGBFTGnrDX PVReC4Iky+SHjUCiOf4CZkrC8iEUwetdH7Up0Adk6xvHXk1CHkLXqV7XBZkAGrX/dfyi kFRQKzivyHHrxK+LhV1oC79Untzd7nxxKqhuBSmjM4pnFbJNqz4ZupOgLdvNqqBUfLI6 BKB+Z5EHW+ko/Bqe5mlntfRNvyx+r0Lt+UG9X4LzzTLy16xmgKxS+a+hXYBZnrnGrPOj xLG8YCjQkmTC04q7HBQ+Zyx111ca5PuVf09hTi1BmSqJDGZ0m5iyJHaQ6HnMGowuOHlH gL+g== X-Gm-Message-State: AMke39k9CxktH2IwYSpmsSC2XcE2jayMqY7aNnb2y/zYTGVk8/FKkFYTm7GNdIPQbN1JUSp/OF+j0mGdyBRiQA== X-Received: by 10.202.75.209 with SMTP id y200mr7102709oia.114.1487472000134; Sat, 18 Feb 2017 18:40:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.13.20 with HTTP; Sat, 18 Feb 2017 18:39:59 -0800 (PST) In-Reply-To: <65b336a0-0c71-0f31-5c1d-5f96d13d81cf@eff.org> References: <65b336a0-0c71-0f31-5c1d-5f96d13d81cf@eff.org> From: Josh Soref Date: Sat, 18 Feb 2017 21:39:59 -0500 Message-ID: To: Jacob Hoffman-Andrews Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "acme@ietf.org" , Martin Thomson Subject: Re: [Acme] UX design by standards 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, 19 Feb 2017 02:40:02 -0000 Jacob Hoffman-Andrews wrote: > This is a fair point. The language here is in response to one client > that is interactive, but chose to display the "Description" from the > errors table rather than the detail field. The solution here is probably to say not to do that! Something like "the description field here is general advice to server implementations to indicate whether a condition fits a message, it is not designed for clients to report to their users." (This is not RFC spec format, but perhaps it's a useful direction.) > This was a problem because > one error type can manifest with a lot of different details, so exposing > the detail field to the end user in some way is critical. I don't think > it matters whether the end user interacts primarily through log > aggregation or interactively. > Do you have proposed alternate langauge, given the above? I intend to write something more detailed about this entire area (error reporting), as I don't like its general design. But right now I'm just working through the main document in a couple of passes. The table seems to say that other items can be used beyond its defined set, but it doesn't say that new things *should* be used unless they're very good matches for the existing ones. If a client encounters an item that it doesn't recognize, then it would make a lot of sense for it to display the detail field. If a server has an error condition that isn't a good match for a message but uses it anyway, it shouldn't be surprised w/ a bad client behavior. From nobody Sat Feb 18 18:51: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 B4846129420 for ; Sat, 18 Feb 2017 18:51:53 -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 Jt1c4QH4L5x6 for ; Sat, 18 Feb 2017 18:51:52 -0800 (PST) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::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 806FC124281 for ; Sat, 18 Feb 2017 18:51:52 -0800 (PST) Received: by mail-oi0-x234.google.com with SMTP id u143so39404170oif.3 for ; Sat, 18 Feb 2017 18:51:52 -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=TbDeYNXfeAW8VIxbgSL3im6OlfD0aZ1KBUBsof5IVoI=; b=ozLv9C9ZfOP3V/Y8BL7Xix6sxmElz5+di3n9ij6VjKea4t8J7PAjEHHdPuwOoPGXRt SJQsGzBwX5rMPfFzas2h2b/AFF1w46rTiivvRzn0w7uprM1iFMLLWHaPZ3AMipJdcL+p 3dLHH0E/DBktUQGtKkP+HmdeR5OuKpaOElt5Nj/ik1e+wN56Rlu1H6pBivLxYGpfdz0A gJSHU+93gZG2pyUDqmZBbWAt43WfOVUd49SxSqMEzyp1s4qrWkAs8Rc5sAGW2UWh1Tbg Crn4Z2T4q5YYxwc3+mRuS44DfWFOcWLiATO/eiC92davLmAkNy4t24DtS1r9ajJ6cI6u VtPQ== 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=TbDeYNXfeAW8VIxbgSL3im6OlfD0aZ1KBUBsof5IVoI=; b=eKgkMSHAlrFr2YhJbiG40q42uNCYuMKqMmRAQ/LwXS3lMv0Ls6lQeQ2Qbxk2fv/iIV Eu4nBeRnOy5CfQkTF3DnaHW8Z8p7qXH0C/25+SPVZgHrw/5GeSmFU/+0ctLtiEw3LBNf ChDDAHcRgAlUf9a0ZQkpqyYSQKVcK05uwxLMufs/I38rh8xKxLWRf4y2XaUS8SN7NJzE oA++NohTbzHmi2pzpBNLC8/0IusaJE2PoBW3bXHcVHKfVgH5YoTEpHTB/nIyQxAVqi8z YP07UbF62wLagM6jYSOYq1AVzMVMp+WzrdE92JTXVefLS/AAfq4/07oEQCwerbBjaKdD KFfw== X-Gm-Message-State: AMke39linwv6p0TleU9I3RVUn985I7RsQYNVJneasFtcv3EC/VFnu2jxk16R6cHXLYdT02ggFiFWC0/zawm2AA== X-Received: by 10.202.83.132 with SMTP id h126mr728924oib.136.1487472711846; Sat, 18 Feb 2017 18:51:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.13.20 with HTTP; Sat, 18 Feb 2017 18:51:51 -0800 (PST) From: Josh Soref Date: Sat, 18 Feb 2017 21:51:51 -0500 Message-ID: To: acme@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Acme] immutable 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, 19 Feb 2017 02:51:54 -0000 > The elements of the "authorizations" array are immutable once set. > The server MUST NOT change the contents of the "authorizations" array after it is created. > If a client observes a change in the contents of the "authorizations" array, > then it SHOULD consider the order invalid. This is an odd use of "immutable". The other two instances of `immutable` in the document are more traditional. But here, authorizations is returned by a request. Obviously, the response data doesn't change while the client is looking at it. I think what the spec is trying to say is that the conceptual authorizations for a broader transaction shouldn't change. But, I don't think that this quoted paragraph does that. From nobody Sat Feb 18 19:18: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 3F463126B6D for ; Sat, 18 Feb 2017 19:18:46 -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 QKKnqPBAdkzE for ; Sat, 18 Feb 2017 19:18:45 -0800 (PST) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::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 105FA1289B0 for ; Sat, 18 Feb 2017 19:18:45 -0800 (PST) Received: by mail-oi0-x22a.google.com with SMTP id 62so26302922oih.2 for ; Sat, 18 Feb 2017 19:18:45 -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; bh=OS5VYUaSHRlVhbuPTZgF1bUDNr/goJUOnLIS6TBtjvk=; b=mp8IAP2tZrW5VmJExFpqt1+PtdZO0G2e+MFJuTK+iLGpRrVAZ/7AJ7PwYVqgaNf7uw oFTtYbmDD5si6NhV5rTxv7bqoK0TJ/no1u9CAiZMlj87gS15DjmHm6+lK3A4Qylhtdhy evTJ96aGlIm/nkWBcOhLl69ZrXRv1TM6aUJlJIoHwKbd9qaYOuDLkEJ7u2Zu72tnv7HC DXONNByBXlmd5lKk9E2O87fNKkk2zC+yO6Csuv2aGbyMMAH0C7IkTI1eWQmgUfAI3EYq JPbeCkVM/CyhtaTA32PiLuW3RQTxw9cGgjXUjgMSjW+esPylFeJuYezhS8oIOK/RzvXO VKxg== 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=OS5VYUaSHRlVhbuPTZgF1bUDNr/goJUOnLIS6TBtjvk=; b=CGOlTYC6pcmk9hENSGxyuRyfWokzafVhPzw4B3QFzeRWoeBaxJ1gmhHb+h0jmNsvC3 ACyXY+bu9gLmH2YyrXTPv9hDbmRffRPQOQNvHYRRVVOaUFR1QIF3/QAAjiKHNMCmzOSb QWviyeDia9t8xIcl6wustioAyNcNjn6F0p2qJhK9e3OtyIjjLDHLOF45g5RPXS0rAbTo GAZcy4gkvrOxYMGiQtm9ntCsI4mRWqEMd+iC7keDXnUufV4NxDSumbxNpkPq7ieO6Jxk DBPADNNJ7dr5A9CCfua9gnjnFdAaBoMzJBQJ1r2BAbDaFdFPvux6SADHb3hugcbjw80H T/Xw== X-Gm-Message-State: AMke39nnG8cVI50VOBnC+XvbQCh+gCwmG9tNG3o2gRRDiTQcrxBcNq9T+KSmcWYEvQT+SK+bCOXa3X7TnMVvEQ== X-Received: by 10.202.66.6 with SMTP id p6mr7535826oia.107.1487474324227; Sat, 18 Feb 2017 19:18:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.13.20 with HTTP; Sat, 18 Feb 2017 19:18:43 -0800 (PST) In-Reply-To: References: From: Josh Soref Date: Sat, 18 Feb 2017 22:18:43 -0500 Message-ID: To: acme@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Acme] why is the status value "invalid" 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, 19 Feb 2017 03:18:46 -0000 I wrote: >> status (required, string): : The status of this order. Possible values are: "pending", "processing", "valid", and "invalid". >> expires (optional, string): : The timestamp after which the server will consider this order invalid, >> encoded in the format specified in RFC 3339 {{!RFC3339}}. > > Is there a reason to call that status "invalid" instead of "expired"? > >> This field is REQUIRED for objects with "pending" or "valid" in the status field. Later on: > an authorization includes several metadata fields, > such as the status of the authorization (e.g., "pending", "valid", or "revoked") > and which challenges were used to validate possession of the identifier. It's odd that the example list isn't complete. Offhand, I'd vote for not giving the examples. I don't think it adds value. > status (required, string): : The status of this authorization. Possible values are: "pending", "processing", "valid", "invalid" and "revoked". If this field is missing, then the default value is "pending". (Note: I'm making changes to this document in parallel to writing these emails, but I won't make changes for things I'm emailing about.) From nobody Sat Feb 18 19:30:21 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0459A12941C for ; Sat, 18 Feb 2017 19:30:20 -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 wD_Y8fut0uMv for ; Sat, 18 Feb 2017 19:30:19 -0800 (PST) Received: from mail-ot0-x22f.google.com (mail-ot0-x22f.google.com [IPv6:2607:f8b0:4003:c0f::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 EBA5A1293EC for ; Sat, 18 Feb 2017 19:30:18 -0800 (PST) Received: by mail-ot0-x22f.google.com with SMTP id 32so52087816oth.3 for ; Sat, 18 Feb 2017 19:30:18 -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=X+V/vg4kQIVYtZHcuBXmD6tdJmLyMB8812rL11lKIdI=; b=epWzVVWelJLUlYkkaZvNZln3GnSBC83Db7aG+S1gHKLIKTytrg0gUt8EU5jd4X5Vbe RfZ4b+3y0YcFX+Egor/m8c7loPEORk6pMpm1yUjxbIzAKq/K8wkgI1QUBK0CSxfho6bV 1uUBwVGZ+U/NLzoHMzDu0m5nQyd8y/bXcxiFMgqldnhuD5fJbwYhHAGPNGn/cEtIEsuY QyXF/f9DJXvmfzDYpTrQwHxUMjJyYLXejGWkVr9xJX+ksTx53/5Jz35+RvyoBVshFDor n7fqYyyZ47bC4G1j/TpcjFfgtETfB0LvLDB3W/xr42i7h3K3wq+FEhtNlXNSrTVLvZ7U S9lA== 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=X+V/vg4kQIVYtZHcuBXmD6tdJmLyMB8812rL11lKIdI=; b=CdpDGN+wWJQ95/X1HYHVVTJc8TMWGmXYfFwWijBn5315/VLlfPmwB4fe3o9g6iK7qZ jUx4C8YEaQ14UIgl5rWJFX9Gantp/+Ss4tbIXq6to6SVfXngncYilt39Aaux8/ZFsy1f n3CfZp40x3bxngvOQNhe4OO7kjCTx+r2mAxDAAzzuFNBBQ29mbyAy+mQGNtYeZzKfrx4 um2Az8j2rVZ96tJt1EPAS7r76V6Uw1ieuOR8ZT0uKE4fOFEDa8F9e0Qqa7C4my/wVdeM 04PXnfHpN8KRrHiJCLlXaoNwjwx2bueR1aey0eg56KcD87uEEHvBmHeSrtCGg9H2WTrc pzGQ== X-Gm-Message-State: AMke39l7uXdlF6I7nFSWTrWMcbEXNPRx566HWAg3TTeVvkZcZxRZ1F8aMJiCRbiUaH/a1KvPZ8KKOkbxZdkO6g== X-Received: by 10.157.42.193 with SMTP id e59mr7292411otb.127.1487475018275; Sat, 18 Feb 2017 19:30:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.13.20 with HTTP; Sat, 18 Feb 2017 19:30:17 -0800 (PST) From: Josh Soref Date: Sat, 18 Feb 2017 22:30:17 -0500 Message-ID: To: acme@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Acme] Final 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, 19 Feb 2017 03:30:20 -0000 > For final authorizations, the challenges that were used. > For final orders, the authorizations that were completed. I have no idea what "final" is, there are only three instances of the word in the document, this is the other: > If the final state is "valid", then the server MUST include an "expires" field. "final state" isn't defined anywhere, just mentioned here. From nobody Sat Feb 18 19:55: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 2D6DC128B44 for ; Sat, 18 Feb 2017 19:55:26 -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 zX2_TZLmCPVl for ; Sat, 18 Feb 2017 19:55:25 -0800 (PST) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::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 225A3126B6D for ; Sat, 18 Feb 2017 19:55:25 -0800 (PST) Received: by mail-oi0-x236.google.com with SMTP id y140so10489510oie.1 for ; Sat, 18 Feb 2017 19:55:25 -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=PJ/u/k4KyrC6drTwdk5dLlDaGrK24fK6+xHDwytwSaA=; b=NA8RjSOcJ2jpG6KG0TKNy+46acaND4N2dW5noZ0vtF/5lhMOMcEOwTjha1H5XsBsvD bf4j6/fZm9WjIhW2s4HQau1gFEDslPmWwHCxrOWP4/zeid+Y2qIq9dcIVK8GG880onzr KMwNAP4xDgwmwJuqFCeUj4mvNeVv1McdDNx0FrvcS3Zg6bv17lfpaQvt9Z/6cTj71EhO 8XpsnsEXk+UUoLLh68M9BYBKc/j6dfucsYUHbHXngpQB0quT6BAszdupvbcIjYynLVXH ETE8mg2GxY7EzqnW7uBDkFJ5Xcghm2LQubxnVyRdy2EIMYljG3t9yVS9R+2qhVBfVqJN tR+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:from:date:message-id:subject:to; bh=PJ/u/k4KyrC6drTwdk5dLlDaGrK24fK6+xHDwytwSaA=; b=qbCTDVxDN8N3UVlQ0mh42SD/Q17h62pPQE6lr8/tlsXyo3Qc6KiHXFZI56SETDX0Fv 1A0vOTZ6ubY/UV8+CoPtH0oxyRwWtLWLzB+TAuLr0gZ3cb5ZlcARj2v5shRHBRVzAXXo YBGlb8+iNQRY7lFaazVJuZr5kfxPn1oRrEBW8zktFwW6M31isE873eOAIgd7HSIiHBiq MB5wb8mj+/zbEMU/GawaLYuTXKkWXt9EC8YiFzfKYhn1HMkgbzhLETJNZZGOZ5BjO9lf V98HUFI2/GJVXWCFEsaMmEp867352Bf8Sr7BMl/nOiILMeIMXh4RUxn/DiMJmfskGEYf pa/g== X-Gm-Message-State: AMke39njgk5bkmSVMzszpWaYq3ytSmYHVWVm7ydRj5CNTFbYEbzcLMOlPVrrRXPOTdiZ9wSHRRTk4CkAliwZVg== X-Received: by 10.202.81.66 with SMTP id f63mr7489351oib.184.1487476524273; Sat, 18 Feb 2017 19:55:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.13.20 with HTTP; Sat, 18 Feb 2017 19:55:23 -0800 (PST) From: Josh Soref Date: Sat, 18 Feb 2017 22:55:23 -0500 Message-ID: To: acme@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Acme] the standard 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, 19 Feb 2017 03:55:26 -0000 > Servers MUST NOT use the ACME URN namespace for errors other than the standard types. "the standard" as written implies "this standard's". I think what you want is "things defined by IETF/RFC including future ones". I don't have spec language for such a thing. Sometimes the answer is an IANA registry. Again, I will eventually be sending more detailed comments about error handling, this is merely from a line-by-line read. From nobody Sun Feb 19 09:14: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 9ADD51294D0 for ; Sun, 19 Feb 2017 09:14:43 -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 qtR2LOAjmvjg for ; Sun, 19 Feb 2017 09:14:42 -0800 (PST) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D9B812940E for ; Sun, 19 Feb 2017 09:14:41 -0800 (PST) Received: by mail-oi0-x22f.google.com with SMTP id u143so42963336oif.3 for ; Sun, 19 Feb 2017 09:14:41 -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=vLqn6AmGV0ok1fScKJS280lMSuUGR0zU4hL47Ax0ZdI=; b=aBheuGgAgTmy9vAaziy4T6aVWOGZNmpduvlNpTDHhR/w8IdEwlt/wTOwHogzvw0wWY t2qQXhQLqz7qQ5P9YlwrCw2gdHdBxATHXfLVp6OO5xm0ssXddIe4ATl9QjAVYeBko6XR W+R1Voq6UEWXiRucuu8xN+BvI5iTd9MsWIcEtVBxu8kM7eUXk3UieWMLjqSskCTyueKI JjNykI5eC/n+x0z2Fz3fx62I/0l+aS3BSbx3cYqiO2lvLhFy7NTl46j1/1WEq3VnWPLA hZZDiXP+nqJIvse2IwQkgblGugVMSaHu4WlxGeWutequTxq2hESDWHhG44vs3yq5nA1E xDTQ== 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=vLqn6AmGV0ok1fScKJS280lMSuUGR0zU4hL47Ax0ZdI=; b=HdcVTokRRRBbon9FLk1jaBtWMiGd4o3hYR8D/abCbFM5H59HgJXsSvnYIAEmt2+rU2 k7n1RNQlFLbf+rhsRjlEHtXUScKRFOn9BFGk+cn13b6B7MUePJydmnbBmYw+c7F/H+bW m+RpFM9zyuJ7u9FGgJtkBygQ2mK6yCh7xIosdYyCoSkCSYa0AhAwFzdhc0TY1Yz27JEx J4FX500MbBejD8MFrP5CPLlsQ5fHxP00FUN66jeosNPQoLBB3BY1rZemaB9SZCIaAT4q qxUd7LVWJbSMT79NVmgcK8noqRcvLtjnU25TVkvvpHB1t4Ra63QHz4hNlXOhF2ojlsjw 3s0Q== X-Gm-Message-State: AMke39kQeU8UaNgcxDjfNGmMpXnSZLeten6LO4OVo0uvekqTQKfrNc81oyl0MEE1jJZH2jv2C9WGNkuSsp7Jyw== X-Received: by 10.202.197.137 with SMTP id v131mr9724117oif.37.1487524480741; Sun, 19 Feb 2017 09:14:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.13.20 with HTTP; Sun, 19 Feb 2017 09:14:40 -0800 (PST) From: Josh Soref Date: Sun, 19 Feb 2017 12:14:40 -0500 Message-ID: To: acme@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Acme] status required missing 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, 19 Feb 2017 17:14:43 -0000 > status (required, string): > : The status of this authorization. > Possible values are: "pending", "processing", "valid", "invalid", and "revoked". > If this field is missing, then the default value is "pending". 1. This last sentence seems to contradict "required". 2. I'm not a fan of the construct "if missing, default value is", to me it implies "if there is a value, there is no default", which isn't what you're trying to say, you're saying . I'd suggestion: 1. Change 'required' to 'optional' 2. Change the last sentence to "If this field is absent, then it should be treated as having value 'pending'." From nobody Sun Feb 19 09:18: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 8B9D1129514 for ; Sun, 19 Feb 2017 09:18:52 -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 AAaMTzLnxP1w for ; Sun, 19 Feb 2017 09:18:51 -0800 (PST) Received: from mail-ot0-x22f.google.com (mail-ot0-x22f.google.com [IPv6:2607:f8b0:4003:c0f::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 9310F12940E for ; Sun, 19 Feb 2017 09:18:51 -0800 (PST) Received: by mail-ot0-x22f.google.com with SMTP id 32so56713395oth.3 for ; Sun, 19 Feb 2017 09:18:51 -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=1qkfWvZ6r7+Tht8n77wxarZyeRFpIARUjmXbpezRfI4=; b=DbbchfKblFr01QtObviSoFXWbBqwZtU4iiC34OPWpkNTfbZ8lYb1DTvIVOikdcJ4qs JfBIgDiAnxfBnfpZObRS/J1RPZubAs1N/NdlOxt+p3rw7O8G6FokC1LmasNKEtCsRKwM phVbmutWHDq8cg7liVMY8HgpHFeK+Fd97dy7eotV+CqPA3viN0pjxENcv2+s2EIQL829 BDLh1tv+aOxcgu3GjxxhrhE/b/uva+Y2ttKuuMJPAtNLIl0kM6taOo/UH7k8lKpBpz/o X9DwoKdnmuuyIIVXFXRpufdRFd2SQgRwK8FKh7/n0nb2yxrk2fACTmhqT4dZJdZHgtnY 2IDQ== 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=1qkfWvZ6r7+Tht8n77wxarZyeRFpIARUjmXbpezRfI4=; b=hwaDBNlHCuLxlao3lbgjM+3Ltt2N5H01zXj3wfMVIZ36B4qKs/QK6ffWaa7oY8Zo5y uOc4XND4gwS8JOgnLR3zUx8pDd/hfN15uSY+grEto45lcPSDXn2WMq7poh/6PoLojs3W hw8xxCc6s9vlCO1jXLBPcfLYSrS2Rjw0+2BMCSdtSfe4uHKZ+OY7b8+r9IdWYbQGvNVb RlM+ZB/Yet7G40sCHpuHDY+yhg93FVuQ5uHDrigdeUhNGLwW/kdRdlW1ShHkcCyZUHA4 ELP7guSuKENaJP2hM8ayuKplQogchPwxhOA4o5mwe7a+5DdXvNTvh+dN79+Irwl+0vC1 CQ5A== X-Gm-Message-State: AMke39n5KYwMkPLKvixtb/El1lCB63rOZEXRpqHTR2s84BkQo4DpH4SYwPR2WStlK/UyIx+XnYzgD/ChnBM9HA== X-Received: by 10.157.6.46 with SMTP id 43mr8431209otn.143.1487524730907; Sun, 19 Feb 2017 09:18:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.13.20 with HTTP; Sun, 19 Feb 2017 09:18:50 -0800 (PST) From: Josh Soref Date: Sun, 19 Feb 2017 12:18:50 -0500 Message-ID: To: acme@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Acme] scope 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, 19 Feb 2017 17:18:52 -0000 > scope (optional, string): > : If this field is present, then it MUST contain a URI for an order resource, > such that this authorization is only valid for that resource. > If this field is absent, then the CA MUST consider this authorization valid for all orders until the authorization expires. > This process may be repeated to associate multiple identifiers to a key pair > (e.g., to request certificates with multiple identifiers), or to associate multiple accounts with an identifier > (e.g., to allow multiple entities to manage certificates). > The server may declare that an authorization is only valid for a specific order by setting the "scope" > field of the authorization to the URI for that order. 1. There are no examples in the spec of using Scope 2. The above are all instances of the word scope, which means there are no examples of two concurrent requests without a scope showing how a lack of scope might cause problems for requests (to server or client) / nor showing how the lack of a scope benefits that additional request. From nobody Sun Feb 19 09:27: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 EBC1D12944A for ; Sun, 19 Feb 2017 09:27: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, 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 6qnWQMN31SXe for ; Sun, 19 Feb 2017 09:27:09 -0800 (PST) Received: from mail-ot0-x22b.google.com (mail-ot0-x22b.google.com [IPv6:2607:f8b0:4003:c0f::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 C147F129443 for ; Sun, 19 Feb 2017 09:27:09 -0800 (PST) Received: by mail-ot0-x22b.google.com with SMTP id 45so56712890otd.2 for ; Sun, 19 Feb 2017 09:27:09 -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=9j56n+KAtEKF7+y6h/6rwlTzlwL3UHt+2YvJItPvecw=; b=X7aZ4aCNtq4hbZLxtVxiRrFQu3QF6K9DfAGuG1OXmcJtitJEMv4NftSgi3cTwsss9W 9qV+VKVrrlY7vLCkkJhCiVC4+Q6ugs8rCbo3/Pson095UVaWtLbSS6BNJ8f3LBQwlVkI KzARLNX/vLr4NXItLjbyoakqEFi8tsi/OhfreQA0X4J+ayMvomqHV2+eMAqq9qjYFUJ3 9fQUgCxwrfhZLdo+75tbxy3JuYfso5iahAWpmtHO99I+UeGPXUpeRRwCmJ3I+CXHvc0u gDY3PPi8UVmSWgLo2XsBatl9gdyxpMMkrgImdo5KZlB182P70w3ebXm+nxXy1GDe5W6Z FiHw== 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=9j56n+KAtEKF7+y6h/6rwlTzlwL3UHt+2YvJItPvecw=; b=FHH47LAZzGTVv5/LC9HYB8C58ZFRZZg48dPrDxRaJsQLTZcdDYFYGRiEWckw59uqm3 DHkfamOY+26CghK+esPaaf5Ls7W3Xl4NcTNeEuNycFyDFJtEVsOsXp7PKj/zNiPMm60H Ap8PzY68LwuQVxDDc+qZcXEOr26Okx87YCp59cuMVVD9Ah0HDmx5Ilzuv6kFqgQ/Xx+s E9jE29yiDGATI8YtyuH+sQKslU+NqnqQQpgzwjYujVrYOA6QKUNSOLPQrtwv5qhPl5hh RVGpnobhs4yTgL9GEkNqcJA+WKa0rvxhA6lWV7GHxPCxObqtOtcohMq+gUPWC0VK5P0d xWig== X-Gm-Message-State: AMke39lvCcS9UbcQarKpU1S6+x59N1vwECAuIQfKTbNQQAGHuwkGsSIMyizrRFR9XlhMkvzYKrABvWjQyUbD7g== X-Received: by 10.157.7.233 with SMTP id 96mr6881869oto.264.1487525228933; Sun, 19 Feb 2017 09:27:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.13.20 with HTTP; Sun, 19 Feb 2017 09:27:08 -0800 (PST) From: Josh Soref Date: Sun, 19 Feb 2017 12:27:08 -0500 Message-ID: To: acme@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Acme] fulfill 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, 19 Feb 2017 17:27:11 -0000 > A client should attempt to fulfill at most one of these challenges, fulfill is an odd word. And "attempt" is an odd word in concert. I'm pretty sure you're trying to say to a client "once you've fulfilled a challenge, you do not need to fulfill any additional challenges", not "you should only try one challenge, and if you fail, you should not try to complete any of the others". The "at most one" text is odd... I suppose a client could attempt to fulfill zero challenges, but that seems pointless. > and a server should consider any one of the challenges sufficient to make the authorization valid. I think something like: A server SHOULD treat the challenges portion satisfied when a client fulfills one challenge. That should be sufficient to tell client implementations that they need to complete one, and that they don't need to complete more than one. Without telling them that if they try one and fail, they shouldn't try a different one. FWIW, as a user, I run into this portion of the spec often. Typically my client tries https or http. But a friendly client would be willing to try both, stopping if the first one it tries completes, but continuing to the second if the first fails. From nobody Sun Feb 19 09:49: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 A0F121293DF for ; Sun, 19 Feb 2017 09:49:19 -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 CvRFXgC37Zxb for ; Sun, 19 Feb 2017 09:49:18 -0800 (PST) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75E4512711D for ; Sun, 19 Feb 2017 09:49:18 -0800 (PST) Received: by mail-oi0-x22f.google.com with SMTP id y140so14008634oie.1 for ; Sun, 19 Feb 2017 09:49:18 -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=1bA4lnT6Nap8AU9g0shGhay12ixzAR4EWhQ5jJ7sxu8=; b=RGdmFKh51fa6yh+sQPPyVTAOMgIeJk3JRH1cImLqUtQFPeyY1psiMjkvko91Adn5Aa 5FVDBTiHaF/CCIfvYu8I4SO35v8LOezEWxMiQOXpAmWPfzziS1MyPoEHr+9ZdCdZ37Af AC+D35BIxEOqi9x8XyMFl1SRu5HUxiF65ori+JIB5bmCjoX/3Js8G2mhDqmYwjJEVjmB MjZW3JyexlxXzFNExxQQhfjArn+IVV+i1PlX2xshWqgHan0lVgoIHboo+tk1owBtwQCM y+c9AV8Nb+V1K3QvuQosXE3P41yxWCn0a0xv4o8ljA2OnEU5b7msqPlNh85wTKgXJZ6j UUtA== 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=1bA4lnT6Nap8AU9g0shGhay12ixzAR4EWhQ5jJ7sxu8=; b=CtAcdb9BVd1toQY6EslQoM5WDzAMDQdp1T+qbBD+s8Z/nCwM/ttIpwkUrV9HCPd5R2 hPsqrUJd3pF3EikD4k6AcRgyV8zCW2NN/tQ6QjYSUHBTC2K6xI8thdQqKA9Hd2H/lDyL F/sdU9BigcIA2jI+FPuq5JO/SnvxysLdetxtJ4lHxvLN7fpE9R0ggORyxxYhtjoxSx8v Gf6RWuRYs0TynQM5XzOzzXEimceVorty95eug0qlNru0CaVhOfwAV6SPIZ1LPRx7RM07 ucwxk4wu89wc2H+hMvdJmI+VZLbSRkvrCehZsaoyO+jtinj/6E7QD4AZraAryni58Oj2 vwfA== X-Gm-Message-State: AMke39lNcSmYYdfGOHkS29R0wWuNHQbPgWzgU7jj2g8LyMmO/xsfikFn5LLUkPDSB1P1++4FJtXF7LlkHawuyw== X-Received: by 10.202.83.132 with SMTP id h126mr1817764oib.136.1487526557538; Sun, 19 Feb 2017 09:49:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.13.20 with HTTP; Sun, 19 Feb 2017 09:49:17 -0800 (PST) From: Josh Soref Date: Sun, 19 Feb 2017 12:49:17 -0500 Message-ID: To: acme@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Acme] terms-of-service boolean 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, 19 Feb 2017 17:49:19 -0000 > terms-of-service-agreed (optional, boolean): This should really be a URL, not a boolean. > : Including this field in a new-account request, > with a value of true, indicates the client's agreement with the terms of service. > This field is not updateable by the client. Consider this flow: 1. user starts ACME client 2. ACME client retrieves metadata from acme server which includes url of ToS 3. ACME server is updated with new ToS 4. ACME client presents user w/ ToS from 2 5. user accepts ToS from 4 6. ACME client makes request to acme server with "true" based on 5/4/2 7. ACME server thinks the user has accepted ToS from 3. From nobody Sun Feb 19 09:57:34 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03AF81294E7 for ; Sun, 19 Feb 2017 09:57:33 -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 SnWJhz99JVCj for ; Sun, 19 Feb 2017 09:57:31 -0800 (PST) Received: from mail-ot0-x231.google.com (mail-ot0-x231.google.com [IPv6:2607:f8b0:4003:c0f::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5390129442 for ; Sun, 19 Feb 2017 09:57:31 -0800 (PST) Received: by mail-ot0-x231.google.com with SMTP id k4so36704569otc.0 for ; Sun, 19 Feb 2017 09:57:31 -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 :content-transfer-encoding; bh=UCsdHfC1b5s0fMOFBCA6qkoqpxzhvC1gWbL/QsSH2XU=; b=IcYzLkrzWpSRreXF4O5NoxPNPT0xcX049VSh+EHkroFB3gGpESMUotZ702gE6Q/Haj WFL5+w3vFKb4JRIVf7lRkbEnBSfEGDNtjrWa6bscpyx49hYk1h+BpjEjo2Fadkdjr/Ym 6mPSY1NQQ20YgqFPefB95MjxbUchXxXBWzAYh56Wd1r+FNl/Q+weeEnxtMlz+5yU7s+b LYv3vEunOYlAvBa/7rujdqt1/8SC0w2N5CslQbIXyeqvS93liM0+azpz7gFB/kXoEbfO ci3Bl7FqS7PyhyKBIbaiYRGMTp5Lc4+owMbRnpEWfUhiA+2np87NoPFccuzluSwaGG1e yu5Q== 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=UCsdHfC1b5s0fMOFBCA6qkoqpxzhvC1gWbL/QsSH2XU=; b=B+IYnL6x7cE86vcyllwm+s9hBy+FpgELltuXWquxDN5s1/R5cnH+o7IlL/UrHzNnOh /qs7b8DHNAoOhuBGla7ojNnUA9qMO0F+mlmizFTru0TmzwG1S/W2nxqsCjxqKqj+avZL 4MLbJL/n6NU+PHE5RBYDuxivgHIG7wyNLNt0phFFGAxs3/y110XtMAfgjgrxSdO+qXB5 wKNfoVfeUPyHwaa6zE+8oUiwBV8qNljjqepkCvoMCLGQeeMJXamL/l71h+AKVf/JVPHR RJAWKi1PJZ9mpQSmtO1BttMKsd1TmZ8aHRPAUCbA8L48ih6AXQY7caIDuN26q75aMcqd G6Qg== X-Gm-Message-State: AMke39lCHS6aUQ1sDaKgu62GRGXLYGFcBFCx2YMW+jK6h7iHPb9SUB12wiEgh4W4xPuaHQwX951bQzrFwO8RAg== X-Received: by 10.157.42.193 with SMTP id e59mr8356293otb.127.1487527051008; Sun, 19 Feb 2017 09:57:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.13.20 with HTTP; Sun, 19 Feb 2017 09:57:30 -0800 (PST) From: Josh Soref Date: Sun, 19 Feb 2017 12:57:30 -0500 Message-ID: To: acme@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [Acme] only identifier 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, 19 Feb 2017 17:57:33 -0000 > The only type of identifier defined by this specification is a fully-qual= ified domain name > To enable ACME account binding, a CA needs to provision the ACME client w= ith a MAC key and a key identifier. The key identifier MUST be an ASCII str= ing. The MAC key SHOULD be provided in base64url-encoded form, to maximize = compatibility between provisioning systems and ACME clients. > The "kid" field MUST contain the key identifier provided by the CA It feels to me that the spec defines "kid" as a "key identifier", which has the word "identifier" in it. I think that this spec is trying to say that the only identifier type that ACME is defining for the purposes of vouching is FQDN/"dns", but that isn't what the plain language says. ---- > The value of the identifier MUST be the ASCII representation of the domai= n name. If I were in review mode and making changes, I'd change this instance of "identifier" to "dns identifier", but it probably will require other cascading changes. The other approach is to change "key identifier" to something which doesn't conflict with "identifier". Personally, I'd much rather the former than the latter, but both require careful work instead of spot changes (and thus they're out of scope for my current PR commit series -- which has nearly 20 individual changes to date). From nobody Sun Feb 19 12:49:16 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90C1612955F for ; Sun, 19 Feb 2017 12:49:14 -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 dF8iIhsWLcSX for ; Sun, 19 Feb 2017 12:49:13 -0800 (PST) Received: from mail-ot0-x22f.google.com (mail-ot0-x22f.google.com [IPv6:2607:f8b0:4003:c0f::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 743AF12955B for ; Sun, 19 Feb 2017 12:49:13 -0800 (PST) Received: by mail-ot0-x22f.google.com with SMTP id 32so58183108oth.3 for ; Sun, 19 Feb 2017 12:49:13 -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=YhYXFl44ZbQlsYmB907SSBY/8MFhu+7Iy+s0YUj3xnM=; b=VW3aooW01LDwND3fniwCiPOsl42Mhy0goqa2othOfXQk7GYJBiaopOjUlO7Z+MgRMw 6C9e3GMTkZtRatp+vxsMEz/nPQgztIXwdqAr7eIfnV2MnQYjeYrzebGuGw+yfHhzxUm0 Dau0Ak9yr1SoQwLbvmtI/WXFr1zQdsdIapFNADGHJVwRGkrjHqTSJXsB/jqyZ4KjSUMn //NNSFFrK9onHz8EUygR8gVIDmNN4I8YtM7VbLhrQbZd6dfYU509HRbbJcAla85xUd4Z FyqkieKOggGO1zBf4e/jCXZIXm4MiuPltM6R3B53oNm4D2gA7+tsgtgPGmfG83G/21QB mrWA== 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=YhYXFl44ZbQlsYmB907SSBY/8MFhu+7Iy+s0YUj3xnM=; b=IDZ45xQOAFazfU4zDifoSwcEGonMt36QyeLUxVPPz8fAR8vo+ld5w2RFGqIiIQozPt PbfX0gH7DssqRFyGSpFrEwE9w2drX5ozTzoMF2LfLCtSaiS2GIVOEm2dHJJ4j4oALC1f /DCF0jhZ+m9RmcbPvJ9VJlm1hBPggoo0zi02EQgDtvha5mZLLz1kALQEvcTr+A6r32Ar X0b/Uh5d9vYJtkmnwXNIi6VVtoAmdWWDXysAytVJ8pkFjZTfeMHhlgSTaYmSpi+1ZYib cW3ekq+3xgUZRmMQuDICcPLMjhQT8uV+rreu+IOo0/krZJKaC8pTzy8jWazlGgLZp5er 6Vyw== X-Gm-Message-State: AMke39kgT6BFtoDrla2jGtIpILgtuoTqP3zRlkbTd7o0ZPGB4J3fud5sW5AEdfIwDmG8BJ8BbZ8UKOZBcpOevw== X-Received: by 10.157.42.193 with SMTP id e59mr8606341otb.127.1487537352474; Sun, 19 Feb 2017 12:49:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.13.20 with HTTP; Sun, 19 Feb 2017 12:49:12 -0800 (PST) From: Josh Soref Date: Sun, 19 Feb 2017 15:49:12 -0500 Message-ID: To: acme@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Acme] accounts, consolidation, revocation, best practices 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, 19 Feb 2017 20:49:14 -0000 So, a user is likely to control multiple servers accessible via DNS. It would be helpful if the user had a way to manage revocation for all DNS names from a single key. Such a key would be usable for revocation w/o being usable for requesting issuance of new certificates. Perhaps that isn't sufficiently useful. Today I have quite a few servers, because of the default design each server has its own key id. Say I'd like to consolidate all of my identities into a single account. There doesn't seem to be any particular way for me to do that either. I could of course copy over a key I have, use it to generate a replacement certificate, and then have my server revoke the certificates issued to the prior key, that's awkward, and I'm not sure I want my certificate history to show that I revoked certificates. (From a review perspective, I haven't gotten to the revocation portion of the specification.) Lastly, I have no idea if it's a good or bad thing for me to consolidate accounts. From nobody Sun Feb 19 14:23:15 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 C34511295C8 for ; Sun, 19 Feb 2017 14:23:13 -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 g7jHgxer6E9Q for ; Sun, 19 Feb 2017 14:23:12 -0800 (PST) Received: from mail-ot0-x22a.google.com (mail-ot0-x22a.google.com [IPv6:2607:f8b0:4003:c0f::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 998561295C6 for ; Sun, 19 Feb 2017 14:23:12 -0800 (PST) Received: by mail-ot0-x22a.google.com with SMTP id 45so58746994otd.2 for ; Sun, 19 Feb 2017 14:23:12 -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=M+CUkgvagbShvzg+V//1vAOi3x9guArgEEXVoxq5gbc=; b=Zph1neN1dVmtg4yu2/HPLDEWwunpJqotJ3ShNjDS7Z1w6g4/MOKvk7aHMWS5SEhDTb lxjvBg6lSN/9OI4we4TUVXrZ5zG1q9a53Y9A6sa4dnPmW/tFNkOrDnvxeUkec14PIyg1 tpY0TlZnPH2PWtHzs+DayEx1wf5xUoE8DtNT7zsDnlScAFG1vXWIrxSGFhU7TrLTuBGm f6vO/Vx+HyJs2wFgEPucXNuDMuegJMj+jqzj2r2YHdt7ZMIVA3/QoxHJd1M+4SV5F9mI dFhBKd1HfIzQnQ4BStrDDvLwtHhWC3p+hSsq6Y40r+O53D40JL4uHMIZFwaB82Q0c+HN 14Mw== 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=M+CUkgvagbShvzg+V//1vAOi3x9guArgEEXVoxq5gbc=; b=W8C696g3gQ+pZDU7CMDmiY8+W+BhSlCbTBCkI/QOGO3SoOpt+pQFwKCb/K6asbh4x7 MA3XVkONaZd5/CemWC+OkqOYGKMX7z1gNUmiu4SdVFWw4rZe2WKjv7enD2S0+42oH5f/ 6qLyOci6uWC+3vPJEOIkCKfPc2diOHx2icrW8EfShAuUqau9e7lcaxxgWH5xsrpKZhWC YVFIM1ZIQvN97/A/H+WSEVJ/n52vhmK1lSxFqFM2OUT5uPxTSfiRXo9t+XJDcLa+sxH3 3PJRmiHKjemVmGpAWacafWfbXDwmgHogkSHa8mGi+VVG93GyvfJWSO/XMsYXX3PnTsBn nosQ== X-Gm-Message-State: AMke39nGyVdZzJHOk7z9CiMTTtxEoOJGcwYbinTjFtTAWC2xIZNGSPE0d7KzmC+gUvOBr82IRgC0y11dlCr8Yg== X-Received: by 10.157.51.19 with SMTP id f19mr10598276otc.18.1487542991857; Sun, 19 Feb 2017 14:23:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.13.20 with HTTP; Sun, 19 Feb 2017 14:23:11 -0800 (PST) From: Josh Soref Date: Sun, 19 Feb 2017 17:23:11 -0500 Message-ID: To: acme@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Acme] example domains in specification 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, 19 Feb 2017 22:23:14 -0000 rfc 2606 provides multiple example TLDs. The acme spec at present uses example.org 3 times, example.net 2 times example.com 92 times It's somewhat hard to tell when a URL in an example refers to an ACME server and when it refers to the user running the ACME client. It would be helpful if the sample ACME server domain was example.net, the sample domain requested by ACME clients was within example.com, and the sample domain for ACME client users (and anything which isn't the above two categories) was within example.org. From nobody Sun Feb 19 14:33: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 C95C31295E0 for ; Sun, 19 Feb 2017 14:33:53 -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 5qLySJMDA659 for ; Sun, 19 Feb 2017 14:33:52 -0800 (PST) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::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 14D551295DD for ; Sun, 19 Feb 2017 14:33:50 -0800 (PST) Received: by mail-qt0-x233.google.com with SMTP id k15so74777128qtg.3 for ; Sun, 19 Feb 2017 14:33:50 -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=aDOoQqc9gPmYrFqjEFZV6Z1u9gWJy29KAgBTf2h6BGc=; b=ujkTlhDJtK20wPGw2LKfiA7fVlHubXZGz6/8fIMAlkP5uUE2b94jhU9+4P4AAOZ0Ct +UD97MavSIByJfwaCa9NiCTjnxfZt1in253uKaq4AC2cQY+16w9CzQg61vx9hhvCyJxg gK+uJk8Qvqdjj41HKF288JdBTogrZeiaVU2hXGzak8LBzQt7A28xWQIijq5al3DgbG2k 19axvJf63cnDG+3eD22kCfYNmNW0oWnZ2++uZqPMy8Pw0DPRi4C/WLQbOAlz3F29f4qD 8EHgaxNJbENjVm+Vn299PDrqoaQjExOKq6BvAcdU0+xJHZ320/mSPTfLxxIzyptlO21I /AtA== 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=aDOoQqc9gPmYrFqjEFZV6Z1u9gWJy29KAgBTf2h6BGc=; b=FvMsxrIwcbrd0o0zwxR66dWWUS4L7MUNQqmeCKHRj8I6uhZGZ/L3j+S1c7sceFBKCK FZnkl7o/KIAeKIizr931Q1pNwrH1x34UCMN3sCKTbWE8vb5mY4rk0drgUBb3WcFuLxHW dP8OGA7P3Nz/M7Bp4GZovF7Zhbm+PeYujv+q9/yaLXp/XBZrahI0OD4ayPmqUCcohvOE xPRBXZ+k5sTs/Wyxf3xeQeMOz0/xscJfMSFWIbUc/RGESLByodVomYCyWy9Y0adE39T0 EoZSyPgT1J87s0trD/EJG1wMsA8HVcHfbsoEJiUA1GWfcfD+QCLMxm6n50vEoqTrKHwH +PAw== X-Gm-Message-State: AMke39noZt69y2Mkm4uCNTWf7I8J8By6aZqXkwycI6dGAim9CnO2os2OYfjnPVK5PP/GHeF/0MgF6ABAP39+zA== X-Received: by 10.237.55.97 with SMTP id i88mr18670229qtb.143.1487543629210; Sun, 19 Feb 2017 14:33:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Sun, 19 Feb 2017 14:33:48 -0800 (PST) In-Reply-To: <65b336a0-0c71-0f31-5c1d-5f96d13d81cf@eff.org> References: <65b336a0-0c71-0f31-5c1d-5f96d13d81cf@eff.org> From: Martin Thomson Date: Mon, 20 Feb 2017 09:33:48 +1100 Message-ID: To: Jacob Hoffman-Andrews Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Josh Soref , "acme@ietf.org" Subject: Re: [Acme] UX design by standards 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, 19 Feb 2017 22:33:54 -0000 On 19 February 2017 at 05:40, Jacob Hoffman-Andrews wrote: > Do you have proposed alternate langauge, given the above? Simply state the the description is designed for human consumption. It's not localized, but it might help in more precisely identifying the issue. Then, let the clients decide what to do with that. From nobody Sun Feb 19 14:41: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 D1CF412954A for ; Sun, 19 Feb 2017 14:41:40 -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 139zXoQT3_3J for ; Sun, 19 Feb 2017 14:41:39 -0800 (PST) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::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 AC648120724 for ; Sun, 19 Feb 2017 14:41:39 -0800 (PST) Received: by mail-oi0-x232.google.com with SMTP id u143so44625573oif.3 for ; Sun, 19 Feb 2017 14:41:39 -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=q9jSTG/Y1sk5QJsQaFzeEzFg9TqLWa4TZXpXfjjDUH0=; b=ts4rsmZNTD1SJoWmkz0SJnLxmM5Qg1KWTKEhQpk3DRW5lcSoLG4koaYS7+7/KaAWrh taVjq5U5K0j4a+wihbsaGzmU4NhmyoKq/jmW9e5usB1zZxqwm8R9BN3fJpv7shG8Wz+l sgUtD5Fq1mf+MDraRlZ73ZFQg5nVYIEFMSfSzDcXTDDLo82rPQmKe6qBekPH22JrZDpe QEgiIxjnpw+K9xhGu2JBCGs5jX77NW2YbdlEREk4GFVSxS0tsJEDYXMwBd0j3cAMFn9u hsqugL/XbQXdBWWBssCKQlj+lE5X917yD+X1D7/Rbwp4R5y75BRyqMgsDG+gbfhuuMdc DInw== 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=q9jSTG/Y1sk5QJsQaFzeEzFg9TqLWa4TZXpXfjjDUH0=; b=XanTt3rTBDgpzdGbJpPw1D737/Z5Po/eDMnAFW+i3VQgwiFzwWeGZ5EXEl7A6prXZv Oe6kG4R9MJHEOJ2pLJ3Wwg5IKTOLEr5fKesuEtDGRk126Cw0VIj+bwurE8JP/bKPXlD3 jXb8yqMa8epmN5x58ZnnAtbWotg72yfFvke4jZAQU14Jizfl4jm+gW3aGL1TbuOBbDGZ /u33bIxmrFSyD/AiHfw7ulOg4cNFSceCJibC8Ghm7ewOszujTBpFRWsXf95TKr9F95dy 2oGD/WEFpR2JHbAEL3+09e9gnpFUONiEs9xikxcIY3wHJsyPWmYzwcGvzi1YkpCi3xNP rCdw== X-Gm-Message-State: AMke39kn8ODoZsxwct+kJyQlR7+DB2Z0WnMjS6Hn6askvqn3OOUT6xWVkRLtthPr4KtzxhD4LSlTToABYGkh4w== X-Received: by 10.202.197.137 with SMTP id v131mr10264122oif.37.1487544098887; Sun, 19 Feb 2017 14:41:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.13.20 with HTTP; Sun, 19 Feb 2017 14:41:38 -0800 (PST) From: Josh Soref Date: Sun, 19 Feb 2017 17:41:38 -0500 Message-ID: To: acme@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Acme] external-account-binding signature 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, 19 Feb 2017 22:41:41 -0000 > ... The protected header of the JWS MUST meet the following criteria: > > * The "alg" field MUST indicate a MAC-based algorithm > * The "kid" field MUST contain the key identifier provided by the CA > * The "nonce" field MUST NOT be present > * The "url" field MUST be set to the same value as the outer JWS > > The "signature" field of the JWS will contain the MAC value computed with the > MAC key provided by the CA. Why isn't this last sentence part of the preceding bulleted list? I think the answer is that something is trying to tell me about the double layers of signatures. But, if that's the case, I don't think this is clear enough for me to figure out.
{ "protected": base64url({ ... }), "payload": base64url({ ... "external-account-binding": { "protected": base64url({ ... }), "payload": base64url(/* same as in "jwk" above */), "signature": /* MAC using MAC key from CA */ } }), "signature": "5TWiqIYQfIDfALQv...x9C2mg8JGPxl5bI4" }
From nobody Sun Feb 19 18:54: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 E97DE129633 for ; Sun, 19 Feb 2017 18:54:42 -0800 (PST) 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 HQhC_CSMInk2 for ; Sun, 19 Feb 2017 18:54:41 -0800 (PST) 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 71089129634 for ; Sun, 19 Feb 2017 18:54:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by umbriel.devever.net (Postfix) with ESMTP id 4B7B91D2E4; Mon, 20 Feb 2017 03:54:39 +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=1487559279; x=1505748640; bh=tSZNIpV12ynMjS8U7E6Hd+wB1I33p72W+psG4KKbZZ8=; b= K8wwb3rZOZ9XTUABu9bm64uF3Waz0cZijtuvVfYKwpIEZyeE6vXqg+pvvtJZYMS4 dKsgA0EFuRLkO1+9SU8zi0Y4+wTQlbKcHZxQyCGrpAtJSaPspwkN1qQrQ8+APVQQ qnwSXRhrGNaptoL1IaX70lIxMZcgwTIHwMyli4RE1mfphWvJ9Tqdt7H2AX402mKf uwT8q+S2w2bz1UMcuCZh+H3PN9n0cZ5Nq19a2/3A55kUPMj2P8ftDoV/8ZrfcEZ0 7wwxvzeBEmTMwzYOEdTcqOVvQx9tWr030FztZ9cNH3YGiTtyo3cVROCt8uJW7mVr NaXDQM/5uG31zgfYPscYQA== 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 tPQlzFudB9NR; Mon, 20 Feb 2017 03:54:39 +0100 (CET) Received: from andover.lhh.devever.net (localhost [127.0.0.1]) by umbriel.devever.net (Postfix) with SMTP id 12E4E1D2E2; Mon, 20 Feb 2017 03:54:39 +0100 (CET) Date: Mon, 20 Feb 2017 02:54:38 +0000 From: Hugo Landau To: Jacob Hoffman-Andrews Message-ID: <20170220025438.GA10979@andover.lhh.devever.net> References: <807854cf-a388-4729-e292-5daac236d82a@eff.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <807854cf-a388-4729-e292-5daac236d82a@eff.org> User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Cc: acme@ietf.org Subject: Re: [Acme] Split up errors and add an error field to orders 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, 20 Feb 2017 02:54:43 -0000 Mostly fine, some comments: If a server processes different things in parallel, multiple errors could occur. Should the "error" field be an array? Moreover, is there any utility in mandating that this "error" field only be used after (all?) authorizations have been completed? That meshes with the implementation model this list is expecting, but it seems simpler from a client implmentation perspective simply for the client to balk whenever it retrieves an order object which has an error set on it. This maximizes the flexibility of implementation on the server side. On Fri, Feb 17, 2017 at 01:02:07PM -0800, Jacob Hoffman-Andrews wrote: > Introduces an error field for orders. Orders can fail independent of > authorizations because of last-minute CAA checking, failure to submit to > CT logs, timeouts, etc. -- Hugo Landau I know of no warrant or notice of a kind defined within the Investigatory Powers Act 2016 or the Regulation of Investigatory Powers Act 2000 that has not been brought to the attention of the public. I will always answer questions about these or similar matters, assuming reasonable request rates, unless legally prevented from doing so. From nobody Sun Feb 19 19:12: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 D52F61293EE for ; Sun, 19 Feb 2017 19:12:47 -0800 (PST) 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 MLk55JUeTNEA for ; Sun, 19 Feb 2017 19:12:46 -0800 (PST) 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 8394412963E for ; Sun, 19 Feb 2017 19:12:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by umbriel.devever.net (Postfix) with ESMTP id 336191D2E4; Mon, 20 Feb 2017 04:12:45 +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=1487560365; x=1505749726; bh=m8Elx/8VXif9qV87KYGba6xsPFd7vgjxzX2G7YAxXVU=; b= kzFQ9i1DX8m7mT+zuCl4BUpNLmmWrkDSfkJYbv76m5JchU+CsKK0htBPIvQVCUOA BICQ84/xE3lmly1Q1dZRMw5//z3IlMAFLGoBLMRj9VHtR4cw5OQRRJwVKbx0azCM /6eLDG7UfxTXCfzjmsAvHFDmZaTB81rsy0LN32QdptLuKOlTbPNLSINT98P2sf/u QOs7gGMPNgt+OM5D2+PkX/gfM4vrJ8ahq2jLMB3wZUGfXMs4YzMryNKoAt8kBCXr YXt1XXoCX6uju/RGYgJvxqVXxrjX03ZMnfMewLQcCt+kEvo7oeYcQcadtg1+AprB T/Zus51kHptAZ3nZ4pXCgQ== 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 tsJj8BeW3kNW; Mon, 20 Feb 2017 04:12:45 +0100 (CET) Received: from andover.lhh.devever.net (localhost [127.0.0.1]) by umbriel.devever.net (Postfix) with SMTP id EBC281D2E2; Mon, 20 Feb 2017 04:12:44 +0100 (CET) Date: Mon, 20 Feb 2017 03:12:44 +0000 From: Hugo Landau To: Josh Soref Message-ID: <20170220031244.GB10979@andover.lhh.devever.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Cc: acme@ietf.org Subject: Re: [Acme] example domains in specification 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, 20 Feb 2017 03:12:48 -0000 This sounds good to me. On Sun, Feb 19, 2017 at 05:23:11PM -0500, Josh Soref wrote: > rfc 2606 provides multiple example TLDs. > > The acme spec at present uses example.org 3 times, > example.net 2 times > example.com 92 times > > It's somewhat hard to tell when a URL in an example refers to an ACME > server and when it refers to the user running the ACME client. > > It would be helpful if the sample ACME server domain was example.net, > the sample domain requested by ACME clients was within example.com, > and the sample domain for ACME client users (and anything which isn't > the above two categories) was within example.org. -- Hugo Landau I know of no warrant or notice of a kind defined within the Investigatory Powers Act 2016 or the Regulation of Investigatory Powers Act 2000 that has not been brought to the attention of the public. I will always answer questions about these or similar matters, assuming reasonable request rates, unless legally prevented from doing so. From nobody Sun Feb 19 20:45: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 CFEE1129666 for ; Sun, 19 Feb 2017 20:45:07 -0800 (PST) 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 tDhiePAaAdcC for ; Sun, 19 Feb 2017 20:45:06 -0800 (PST) Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e: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 E450E120727 for ; Sun, 19 Feb 2017 20:45:05 -0800 (PST) Received: by mail-pg0-x236.google.com with SMTP id a123so12243511pgc.0 for ; Sun, 19 Feb 2017 20:45:05 -0800 (PST) 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=vMG0+CManSWVLsiSI38ugPYlA44BBm3FIFcMPrjdkuQ=; b=Te7UXRoJ03lXfD76h6Kc8Hp054fL0/CcnslKy1m0IhLpn18kQdeENHcAsBN550LdaY IEtnXU/N+Bk45WDtp3vpcAnNEzptKSIdmkaeSXBBJeFJTF7EdHZYaULsgUuP4PlDwWNr J5NHbMVvVRdh4lj4w0BHyC7/b6NNlOWxUS2RM= 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=vMG0+CManSWVLsiSI38ugPYlA44BBm3FIFcMPrjdkuQ=; b=s6US5Cg9A+TP2PBQZTxOW6xe6sxQcb35KKSpnce5g4/WgTOtb+4mwiU7gbQQmiKJb4 m50oOwYhBLaerPbtaHrXOJSg7mcLGNF9dJHH4OaaqVL+VND1kNQ9S1WDsSP/l4Bwqfyu afk5tTmezKvWtxkAryDX5hFEZUy1g+o3yDTFeyyskSGjSjNoTMfqwKVWu2cBISNTiHQh Mb6dQ4tECBap3Y5/MDuYCR37GR03XEmTA4F5PJmYD32DfxkdeWG3XuznFHTz+V7F8bSA P/yFSQ3ygST6kwJLi64G1HGDIIaw6OCoZNx9rL+u5VASKXsiE/eFndf5gGFbKtkyR3uT o0xw== X-Gm-Message-State: AMke39mG0X8hWFCauxQ5e9VL25CwbrcO4hbRmXuDnV7qYmZbAcIeATy1jXhxFGMCCpGWfH46 X-Received: by 10.98.66.82 with SMTP id p79mr23678366pfa.10.1487565905107; Sun, 19 Feb 2017 20:45:05 -0800 (PST) Received: from [192.168.42.66] ([50.1.57.147]) by smtp.gmail.com with ESMTPSA id k76sm31786598pfg.42.2017.02.19.20.45.04 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 19 Feb 2017 20:45:04 -0800 (PST) To: acme@ietf.org References: From: Roland Bracewell Shoemaker Message-ID: Date: Sun, 19 Feb 2017 20:45:02 -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 Archived-At: Subject: Re: [Acme] example domains in specification 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, 20 Feb 2017 04:45:08 -0000 Making each host role have it's own distinct name would definitely be a gain from a clarity perspective but making those distinctions based solely on the TLD that is being used seems like it'd actually make things somewhat more confusing. Instead why not use subdomains below example.com that explicitly indicate what their role is, e.g. {server,client,validation}.exmaple.com? On 02/19/2017 02:23 PM, Josh Soref wrote: > rfc 2606 provides multiple example TLDs. > > The acme spec at present uses example.org 3 times, > example.net 2 times > example.com 92 times > > It's somewhat hard to tell when a URL in an example refers to an ACME > server and when it refers to the user running the ACME client. > > It would be helpful if the sample ACME server domain was example.net, > the sample domain requested by ACME clients was within example.com, > and the sample domain for ACME client users (and anything which isn't > the above two categories) was within example.org. > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > From nobody Sun Feb 19 21:14: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 1A60D12969A for ; Sun, 19 Feb 2017 21:14:41 -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 Kf63rD8DRj0P for ; Sun, 19 Feb 2017 21:14:39 -0800 (PST) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::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 88629129682 for ; Sun, 19 Feb 2017 21:14:39 -0800 (PST) Received: by mail-oi0-x22c.google.com with SMTP id 62so33798770oih.2 for ; Sun, 19 Feb 2017 21:14:39 -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=wRzXlOfG44CZpyo4bsGTGEUgS+e6W5UUtVGz0W2h2SU=; b=hX6sjr+ab+76Dl7/fYjJWLKV+vzJOLgK8d4IaZ4o6vWzfoba6wX6wo8sPDJJ1mDoHs wNeA9ATQUz4Er2vL+rCNXn8cns48L1eb7L/JDZMgk5fKxrcjLuZMTKqLy95d2Z59jEtY 4/Wud8e3Eqw496lL59S8MB7sX+sGLopj4g7TfqwS/lbzMuoBK0GYdJ3IEYJXpb3QiFD+ MEbOG854cCSatWfAIsyjzVWNbLWZpZyPvW5//FtV3cGoTplkqwYJo8HMe0GRstUIifQP v+6SzqKi33etfLmqv9wIqZey08wFnpK84uPeCSAFo23JM3V5AqqZyizbWqGjbBe/fgp5 IMwA== 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=wRzXlOfG44CZpyo4bsGTGEUgS+e6W5UUtVGz0W2h2SU=; b=oZvAoxAuSDp5QZZtDlIRyQ26izwiJqP4ij+dHMAtTMRcr1WsnL8NXJRTBaAIDFFmCo nY4U9/cFnV24Iy3A6RT7nOxHANQMupY4t81hvW8ha+EJ+MQ7u4tGeEZE01bouEuiy+zZ mKKVk0wpMieMHEpjufj09ETRepY1caGVQR8C6+GllDAllAPbReL+pXjhseiG5Aqpk8yt YgMwPesFtph/mGg0voccYb0DF/Y1rYRfWxgJlnUfBassNBx3QYNl88XSJVw94+4IKSQv oO63hXos3fl2Jl1JPnNsbhmrfBpmimDq/t4fqpHwrfzwn4Iwu8iv3CGBZZOmfcvPVtzQ 9vbA== X-Gm-Message-State: AMke39nm+GfZofZOH/5CzEcU7uJmUclihUq3ZXC7QEO6PfA87DRGUkih3/rUFSxnuFcxOEn3b1SeA6IJyjxMyQ== X-Received: by 10.202.197.137 with SMTP id v131mr10824486oif.37.1487567678820; Sun, 19 Feb 2017 21:14:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.13.20 with HTTP; Sun, 19 Feb 2017 21:14:38 -0800 (PST) From: Josh Soref Date: Mon, 20 Feb 2017 00:14:38 -0500 Message-ID: To: acme@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Acme] time in the specification 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, 20 Feb 2017 05:14:41 -0000 There are lines of the form: > "expires": "2016-01-01T00:00:00Z", It would be helpful if the specification defined what time "now" was either generally for things in the specification, or for each blob. It's probably possible to include a "Date" field in most response headers (I'm less certain about requests). From nobody Mon Feb 20 04:38: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 631CC129464 for ; Mon, 20 Feb 2017 04:38:24 -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 t1_gY75q-ZfO for ; Mon, 20 Feb 2017 04:38:23 -0800 (PST) Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::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 EE61F1299AD for ; Mon, 20 Feb 2017 04:38:22 -0800 (PST) Received: by mail-ua0-x234.google.com with SMTP id 92so9562581uad.2 for ; Mon, 20 Feb 2017 04:38:22 -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=YRgsgLcrXflomW+xOT+K2wZFcXlC8GkE9Hd2qGXjnJ4=; b=XkTwaMbTfUtsUtA0nYtUiUjmMdL/MRNi1Ty0KEbXwzRP+VwuyB0EXr0GkvAHSzO7yb Ssoo3nzo3GT0OvMqRNIRy5MJVl0P9vCNgsHaXnNG/Lj3EN6T9LsiCfVzVFx2ZNl/BciD kb7ASgT2Ekj0jFYQ9fN8zIXuG8V2pCi8MWjX6slY+z3cUJ2NgA3o5bJX7iOLanFBzKtA UUDITiVam0slzdfhv5aZcMd4t9iCxEgJGsV2Te7matnpBtB5n7/zlcDMIVuomAPuzK0S 18fP+0xW3V58bQxDDNkSOjtMfOjQSRFQjRl0CSWoiXmIKMMA8ggWidEVWB3+2ivYEfpr g4XA== 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=YRgsgLcrXflomW+xOT+K2wZFcXlC8GkE9Hd2qGXjnJ4=; b=ZXXtOe0Tet5T4QuPIgmNpHA62vwtuAeiqw1kjk772G9LAL5VFm3uI2w1mxWH37X2It ljXHXPRg1atoXAQU5rWyQplCvMLkcqgx42z1Tmj/1fIgp7rvYFDQGet686ZYvGSc40DC GTFRtPQ+fISclFXpHFF5AiJlpED1w5kC6en1zuc6CSbBdA5k7SkFyaksK/SvJgIGyIRb dmPRWdZBdiTwSNnF+pcEQDDVWtDacfEV97ATyWRnDdMIinAaNaIXrUDpmmWPTekR8JO4 IUgXEbTvBTIxu2ASkxuPqki9WsUq3gajsQU7B7zkqrvG+gsRy5C7D/gXYkt+XT1ZeUem TM4Q== X-Gm-Message-State: AMke39ka04ohse423LdljxJGQ5XrLHY/CXd0O7rXab9m184G9VhVZp8NqsVnd9B+tJ2VPzEyopDW110fSEgLfA== X-Received: by 10.159.36.56 with SMTP id 53mr3654389uaq.124.1487594301816; Mon, 20 Feb 2017 04:38:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.179.140 with HTTP; Mon, 20 Feb 2017 04:38:20 -0800 (PST) Received: by 10.31.179.140 with HTTP; Mon, 20 Feb 2017 04:38:20 -0800 (PST) In-Reply-To: References: From: Richard Barnes Date: Mon, 20 Feb 2017 07:38:20 -0500 Message-ID: To: Josh Soref Content-Type: multipart/alternative; boundary=001a113e1ca0ee15050548f5895d Archived-At: Cc: acme@ietf.org Subject: Re: [Acme] time in the specification 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, 20 Feb 2017 12:38:24 -0000 --001a113e1ca0ee15050548f5895d Content-Type: text/plain; charset=UTF-8 What's the use case for this? Diagnosing clock issues? On Feb 20, 2017 12:14 AM, "Josh Soref" wrote: There are lines of the form: > "expires": "2016-01-01T00:00:00Z", It would be helpful if the specification defined what time "now" was either generally for things in the specification, or for each blob. It's probably possible to include a "Date" field in most response headers (I'm less certain about requests). _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme --001a113e1ca0ee15050548f5895d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
What's the use case for this?=C2=A0 Diagnosing clock = issues?



On Feb 20, 2017 12:14 A= M, "Josh Soref" <jsoref@gm= ail.com> wrote:
The= re are lines of the form:
>=C2=A0 "expires": "2016-01-01T00:00:00Z",

It would be helpful if the specification defined what time "now" = was
either generally for things in the specification, or for each blob.
It's probably possible to include a "Date" field in most resp= onse
headers (I'm less certain about requests).

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

--001a113e1ca0ee15050548f5895d-- From nobody Mon Feb 20 05:32: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 2FFBF129482 for ; Mon, 20 Feb 2017 05:32:01 -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, 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 RIVIW7_RP6W6 for ; Mon, 20 Feb 2017 05:31:59 -0800 (PST) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::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 B9D4F129469 for ; Mon, 20 Feb 2017 05:31:59 -0800 (PST) Received: by mail-oi0-x235.google.com with SMTP id y140so22587116oie.1 for ; Mon, 20 Feb 2017 05:31:59 -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=vQ6r7WVyLCwPh55xGRrdroQfe/V4OVa5lgLhYSjklvY=; b=mrMDPyZul+gY5XB2VthIfbJMqdGLMGyszZTgE8LeYJV3hNNhetLWgZtshVmay6sfiK tAEgVDz3B5YuA0ERv9EOdMmqV897H+G9MsuS+6CepoJXkNtjauBqia/nVV5tDYqj3PZD FqWyJzmPmSbYJ4+v1at8L7KFgYpfNKEkdHDHHdTJB5+A4WDvPGK/1ARg/aFIi9TL5KFC TunRughVn61L00tUWOlEFzdzA+8qQz4+D2kUWGv0T9n42IH8JE13GNXzhZyZYW0Q8WfL DbPmq9s/akN/yoNim+zwibjoxMcpwPlMQwqcSOf7Q97DH52L49SlGFir2ULMTjhnR/vz xkEQ== 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=vQ6r7WVyLCwPh55xGRrdroQfe/V4OVa5lgLhYSjklvY=; b=WxMfG8Woc1zbdoNYCmsK1jZiX+rULzV2PsI75gVgcyK7mjMbjJttTsC7yFcP53P8nN wEihVJnHDQI39H96XnTMIZWmJa1M0XlOgmB+q9kmtOAq4Zvq99V6puKALTJ7alMRHZvI FPek7cuTkqv3jb9J8EEIUQdtI0xqttHfuOdzvScxeuJSV4GLzrMk//F7dMb9lVNJjDz3 f5d4zICV/+o2SCqFgX7+UBxaZpIUIWihRiqXAr77dFFYPfQ+xJo0ZXav7nR45JORt4wk 4k4nAxd8/fB2pC+nK3lCWW6qOUe3jNTaMrtWvLH7zMxlpptXtWD+qdWrjuJ7S7yg7QB4 dGkA== X-Gm-Message-State: AMke39kCePF7YcD6FKFp3Lc5XqPda3mFNYwW0vcgIngQVxMn8rc/Aqx3Vy1KN4ToYhDbYxoAy36G8ygXiAcnug== X-Received: by 10.202.8.71 with SMTP id 68mr11191117oii.59.1487597518953; Mon, 20 Feb 2017 05:31:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.54.74 with HTTP; Mon, 20 Feb 2017 05:31:57 -0800 (PST) Received: by 10.157.54.74 with HTTP; Mon, 20 Feb 2017 05:31:57 -0800 (PST) In-Reply-To: References: From: Josh Soref Date: Mon, 20 Feb 2017 08:31:57 -0500 Message-ID: To: Richard Barnes Content-Type: multipart/alternative; boundary=94eb2c12f8b4afa3670548f649a1 Archived-At: Cc: acme@ietf.org Subject: Re: [Acme] time in the specification 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, 20 Feb 2017 13:32:01 -0000 --94eb2c12f8b4afa3670548f649a1 Content-Type: text/plain; charset=UTF-8 Richard Barnes wrote: What's the use case for this? Diagnosing clock issues? Sometimes the spec lists an expires time and says what to do if time is before/after. It's hard to tell if the time in a response is supposed to be in the future when it's in fact in the past. --94eb2c12f8b4afa3670548f649a1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Richard Barnes wrote:
What's the use case for this?=C2=A0 Diagnosin= g clock issues?

<= div dir=3D"auto">Sometimes the spec lists an expires time and says what to = do if time is before/after. It's hard to tell if the time in a response= is supposed to be in the future when it's in fact in the past.
--94eb2c12f8b4afa3670548f649a1-- From sophie_herold@hemio.de Mon Feb 20 07:17: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 CACE7129440 for ; Mon, 20 Feb 2017 07:17:22 -0800 (PST) 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 nw5uNQ-zCpxJ for ; Mon, 20 Feb 2017 07:17:21 -0800 (PST) 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 34A701293FB for ; Mon, 20 Feb 2017 07:17:21 -0800 (PST) Received: from user.client.invalid (localhost [144.76.93.186]) by mail.hemio.de (Postfix) with ESMTPSA id 7DF6172 for ; Mon, 20 Feb 2017 16:17:18 +0100 (CET) To: acme@ietf.org From: Sophie Herold Message-ID: <96d31ef7-0dda-019c-4072-165fcd57e34f@hemio.de> Date: Mon, 20 Feb 2017 16:17:18 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [Acme] Missing structure and unspecified parts in "Account Creation" 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, 20 Feb 2017 15:18:47 -0000 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 Feb 20 14:38: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 838DF129415 for ; Mon, 20 Feb 2017 14:38:57 -0800 (PST) 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 0I1Lv0YdIeFb for ; Mon, 20 Feb 2017 14:38:56 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B36AB1293F5 for ; Mon, 20 Feb 2017 14:38:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 1554730042E for ; Mon, 20 Feb 2017 17:38:56 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id NJIvp0blzNFp for ; Mon, 20 Feb 2017 17:38:55 -0500 (EST) Received: from russhousleymbp.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 0A822300266; Mon, 20 Feb 2017 17:38:55 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Russ Housley In-Reply-To: Date: Mon, 20 Feb 2017 17:38:54 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Josh Soref X-Mailer: Apple Mail (2.3259) Archived-At: Cc: IETF ACME Subject: Re: [Acme] fulfill 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, 20 Feb 2017 22:38:57 -0000 > On Feb 19, 2017, at 12:27 PM, Josh Soref wrote: >=20 >> A client should attempt to fulfill at most one of these challenges, >=20 > fulfill is an odd word. And "attempt" is an odd word in concert. I'm > pretty sure you're trying to say to a client "once you've fulfilled a > challenge, you do not need to fulfill any additional challenges", not > "you should only try one challenge, and if you fail, you should not > try to complete any of the others". >=20 > The "at most one" text is odd... I suppose a client could attempt to > fulfill zero challenges, but that seems pointless. >=20 >> and a server should consider any one of the challenges sufficient to = make the authorization valid. >=20 > I think something like: >=20 > A server SHOULD treat the challenges portion satisfied when a client > fulfills one challenge. >=20 > That should be sufficient to tell client implementations that they > need to complete one, and that they don't need to complete more than > one. Without telling them that if they try one and fail, they > shouldn't try a different one. >=20 > FWIW, as a user, I run into this portion of the spec often. Typically > my client tries https or http. But a friendly client would be willing > to try both, stopping if the first one it tries completes, but > continuing to the second if the first fails. +1. This is a significant improvement over the current text. Russ= From nobody Mon Feb 20 14:48: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 49C251293EC for ; Mon, 20 Feb 2017 14:48:00 -0800 (PST) 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 mU4qJ88Bn--0 for ; Mon, 20 Feb 2017 14:47:59 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59A101293DC for ; Mon, 20 Feb 2017 14:47:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id C724B30042E for ; Mon, 20 Feb 2017 17:47:58 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 9j4JNDLZKrQm for ; Mon, 20 Feb 2017 17:47:57 -0500 (EST) Received: from russhousleymbp.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id C8B14300266; Mon, 20 Feb 2017 17:47:57 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Russ Housley In-Reply-To: Date: Mon, 20 Feb 2017 17:47:57 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <86FD9E72-0780-4A3E-B0BD-169D39F3D768@vigilsec.com> References: To: Josh Soref X-Mailer: Apple Mail (2.3259) Archived-At: Cc: IETF ACME Subject: Re: [Acme] terms-of-service boolean 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, 20 Feb 2017 22:48:00 -0000 > On Feb 19, 2017, at 12:49 PM, Josh Soref wrote: >=20 >> terms-of-service-agreed (optional, boolean): >=20 > This should really be a URL, not a boolean. >=20 >> : Including this field in a new-account request, >> with a value of true, indicates the client's agreement with the terms = of service. >> This field is not updateable by the client. >=20 > Consider this flow: >=20 > 1. user starts ACME client > 2. ACME client retrieves metadata from acme server which includes url = of ToS > 3. ACME server is updated with new ToS > 4. ACME client presents user w/ ToS from 2 > 5. user accepts ToS from 4 > 6. ACME client makes request to acme server with "true" based on 5/4/2 > 7. ACME server thinks the user has accepted ToS from 3. I am not sure that one ought to expect major changes in the = term-of-service without there being significant changes in the CA. = However, you suggest does ensure that the client is accepting the same = terms-of-service that the server is offering. Another approach would be to hash the webpage provided by the server. Russ From nobody Mon Feb 20 15:50: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 E2F8612943B for ; Mon, 20 Feb 2017 15:50:25 -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 yX38QQv_kHWt for ; Mon, 20 Feb 2017 15:50:25 -0800 (PST) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::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 C277412941A for ; Mon, 20 Feb 2017 15:50:24 -0800 (PST) Received: by mail-qk0-x235.google.com with SMTP id p22so108960715qka.0 for ; Mon, 20 Feb 2017 15:50:24 -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=D9IK6CPb7emcOT3ee67Rg9TgXYdfWySfzcQ9SOsNZ2Q=; b=bMTPrq+DAqKyB2I3IlU2lD942S7thdz9H8AoHIAfD/iIztJDRMsId+jVN09hbmGYcw Er6oiXfKr8zKT8loytxdWxCoiE3pF7Bw8KDPhsXBsI4L4P3cauGHwVbWUniKkuPWLu4G eP5vLj03UZNbRufQsRVGDXWNRgAfbi7v6FUMl3vNOUmwsN/BF/K5H91xs79rZnNSPhLm 13mfHgjCev8tai1REzp9M4PRWloe5Rnu9HysF5Cpri4qRyognR7NMroNeLVd+BIWVm9P npGLziADxLQnJU6T9+EsESwCYRRfHCiSP1PxCTFKz9oAbau3J49d0MjoPUAp2+Z7XwZC Hxew== 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=D9IK6CPb7emcOT3ee67Rg9TgXYdfWySfzcQ9SOsNZ2Q=; b=cwVJvJAOZHno0D1Z1JXhkmCDbLkKdWBBVErjXPy2PK4XoSOPIClbOpTc75CV/sDkWS MCzExvMXgM732mo48tAiIj7WXCMEm5MNTR3UJtd/m2k7z185upyZDwjx18yvQi2VyKJR T1WXnF6M2Lvt1pj3JIBz7uSctFhYVORel3XcXkiHEecdL231EQCSkA39wZE0RCurAv09 l1Yvbdn71szEX7B29MiDkN80X9hiRIgydqoaeL/VoAzBK5dV3nRnH0IRmtp57MUIo0Qw bMxgQROugX248mK+531WO/lDhrlkJRJahqPekw+9LTOCXyfJwyJ6CPCLAVeEE7N4yTyC 2UjQ== X-Gm-Message-State: AMke39mBbpTNg7QAjXmJCoTbGw9p+2fm+AFMSzgBAftvyxDSv8tC/8bh0CDxGkzodtftBaM6WVdVsCS7kn7d0g== X-Received: by 10.55.25.147 with SMTP id 19mr21296720qkz.147.1487634623968; Mon, 20 Feb 2017 15:50:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Mon, 20 Feb 2017 15:50:23 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Tue, 21 Feb 2017 10:50:23 +1100 Message-ID: To: Josh Soref Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Richard Barnes , "acme@ietf.org" Subject: Re: [Acme] time in the specification 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, 20 Feb 2017 23:50:26 -0000 On 21 February 2017 at 00:31, Josh Soref wrote: > Richard Barnes wrote: > > What's the use case for this? Diagnosing clock issues? > > > Sometimes the spec lists an expires time and says what to do if time is > before/after. It's hard to tell if the time in a response is supposed to be > in the future when it's in fact in the past. HTTP provides a Date header field if you want to go crazy. I would probably still NTP over that though. From nobody Mon Feb 20 16:40: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 014DC129530 for ; Mon, 20 Feb 2017 16:40:22 -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 H8CQvVgR3cjy for ; Mon, 20 Feb 2017 16:40:21 -0800 (PST) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::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 0164D12952B for ; Mon, 20 Feb 2017 16:40:20 -0800 (PST) Received: by mail-ua0-x235.google.com with SMTP id 35so74738703uak.1 for ; Mon, 20 Feb 2017 16:40:20 -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=pVpu1j7l88vHL2ZoKlVWKvR9uFQPRAHquIFyG2HhbjY=; b=Kh3W+Ca6WSjl8mUtJyfT5CFN3SbwGJkzpfd5hwZ+UrcOcwJ3ullVnaDhqJBC3yWw9T f7loSvBCw/N1kZjGjAmwfnfy9cGh/wpVGIZXhKrIE9WoQKj2bPlJcYR92NUOP7tjTM/C cacdqFZs8TdFuWtXY5F7HK3g4tQcnL424jCvWAd7tmAvgKws2sE6zlhCtgJs+GckxSlF hx9+DLHyJiAADKcAfm4xb/Fa40obCJOljU6nOeS6Zj4bMdqyYb781N2Zgfp0yoPFqR+8 +dWM3sOZ6doB9w9+fWtgw85yMGwhGEcUA63ByUK+Uz3aIMrRvZZtGr6bCfNP+FHLWjII r4/Q== 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=pVpu1j7l88vHL2ZoKlVWKvR9uFQPRAHquIFyG2HhbjY=; b=EAwp2AoHJGbPm0tUFZBGHzoiVqRsSHzCeC2JqjwIVl0f5SPwTBmMb8Dca6FBekSyJ/ PEq4cQdusA27AqBfbLT3O4ucnW4iHQU+e2Dp1DIJGpoLjXZYt3Z/As8uPCPWvzrRmuF4 WULDw4wPZzwfzdkCZIqlcCuCoJBTBAX5K2w/7HLD6lTk3N5q5tPCIec1P3qwhPh/nZ8n c/yBvnWXtcN1xYKZyjugiud2oFtZkTMaIuJKutAf9THsUZCJBHu/zVK093QNpYk0yQ3P qPG2SEXQE5d+5t5RW47zgvX0os3FFY1SeCBNOdl3vQDg4Y4jmL5X6jSJMvmpP06AVIDo 9Brg== X-Gm-Message-State: AMke39mpkoHIfaI8RpFGCgvNdaqa4BTr2U3EUfr27rUhRDP0a/l7p2ai55i78qh2/bpbD5P39wxEDCnOtZXR2A== X-Received: by 10.176.2.113 with SMTP id 104mr10556740uas.155.1487637619977; Mon, 20 Feb 2017 16:40:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.179.140 with HTTP; Mon, 20 Feb 2017 16:40:19 -0800 (PST) In-Reply-To: References: From: Richard Barnes Date: Mon, 20 Feb 2017 19:40:19 -0500 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a113e4b92e536220548ff9f19 Archived-At: Cc: Josh Soref , "acme@ietf.org" Subject: Re: [Acme] time in the specification 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, 21 Feb 2017 00:40:22 -0000 --001a113e4b92e536220548ff9f19 Content-Type: text/plain; charset=UTF-8 On Mon, Feb 20, 2017 at 6:50 PM, Martin Thomson wrote: > On 21 February 2017 at 00:31, Josh Soref wrote: > > Richard Barnes wrote: > > > > What's the use case for this? Diagnosing clock issues? > > > > > > Sometimes the spec lists an expires time and says what to do if time is > > before/after. It's hard to tell if the time in a response is supposed to > be > > in the future when it's in fact in the past. > > HTTP provides a Date header field if you want to go crazy. I would > probably still NTP over that though. > The dates are all advisory anyway. The real comparisons are the ones the server does with its own clock; the "expires" attributes are just advice to the client on how quickly they should be getting things done. So I'm not tremendously worried about clock desync here. The Date header seems sufficient if clients want to try to figure out why their queries are failing. --Richard --001a113e4b92e536220548ff9f19 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Feb 20, 2017 at 6:50 PM, Martin Thomson <<= a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson= @gmail.com> wrote:
On 21 Februa= ry 2017 at 00:31, Josh Soref <jsoref= @gmail.com> wrote:
> Richard Barnes wrote:
>
> What's the use case for this?=C2=A0 Diagnosing clock issues?
>
>
> Sometimes the spec lists an expires time and says what to do if time i= s
> before/after. It's hard to tell if the time in a response is suppo= sed to be
> in the future when it's in fact in the past.

HTTP provides a Date header field if you want to go crazy.=C2= =A0 I would
probably still NTP over that though.

The dates are all advisory anyway.=C2=A0 The re= al comparisons are the=20 ones the server does with its own clock; the "expires" attributes= are=20 just advice to the client on how quickly they should be getting things=20 done.

So I'm not tremendously worried about clock desync= =20 here.=C2=A0 The Date header seems sufficient if clients want to try to figu= re out why their queries are failing.

--Richard

--001a113e4b92e536220548ff9f19-- From nobody Mon Feb 20 16:49:21 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF0A6129530 for ; Mon, 20 Feb 2017 16:49:20 -0800 (PST) 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 Vv4AY-A-LJ34 for ; Mon, 20 Feb 2017 16:49:19 -0800 (PST) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::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 1A508120725 for ; Mon, 20 Feb 2017 16:49:19 -0800 (PST) Received: by mail-ua0-x235.google.com with SMTP id 35so74819481uak.1 for ; Mon, 20 Feb 2017 16:49:19 -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=e7Vk+Ew4nGQONYuDSmaXmTQvp9n7OSCsywIkkYiJ4FY=; b=ok/Vc1xCpHiJaBRM1Y8uQaumijRoPPNUjMVGqLRJnZG9figZHUuijCFixtP+FmJw11 6CJ7O3WVwU/rKJAlJahV7ox0UygMUAM8kT46Rclxp01BvrqTlOgOy/Cg2bSdMGJXP6e3 UqYzfPkp2gom+R2QKFpaSfpsCSAgQwBM1VPeI5zjGxr2sVbxY6Q8ha2hshrEtkGUquj1 LecGIvdMxYMDxeOtg/ZQQ04onANeG0p56GaVy/w40zCU0vS3zqF4J/SCrlokKReZdfed S5ukdswlzPxpN51S7t3lSGVNjdZ34wiOvgUXXAfbroTlzmI5RHgB5ryIZyrCaM5ygtm5 YP5A== 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=e7Vk+Ew4nGQONYuDSmaXmTQvp9n7OSCsywIkkYiJ4FY=; b=jOs1EshWI07vvVPUStSL6lEhAzTBATXTnMhQE9r8f2r4+CetFASoYLcJBn1bS8B+an EiT5qLOnoclFWsud45kCKGQoFsMJa17uBHKZHcKRSsGbYVEgfkXx2ouMJUZT0k16iLDd TWLQ7sWJHmZtuOb5rmoxV7Yj198eirhy5DUaZidszHK4Ix4GVrhWY3i9Ph1Jms4r0oab uRfV4cGaADLFAt33frWpQ8786CwgsguhCp1fpL3P5auH6aR+9Y1EjfvW/M3ZHRvl7gEJ sM0vG8VJHlEmAAX/zXrAW0kGwPshUHeS2gRKxjsLNYD6V6yAaRz6BED8rIbqlje/0nyC DI9w== X-Gm-Message-State: AMke39lF/BickI2be493YYJJcLIICmywWBMRFTAcQ5/1U7QmtHvSDIhML2sOlJW+esQHcb6ayUnXZpIOm23HdQ== X-Received: by 10.176.7.204 with SMTP id d12mr5765923uaf.171.1487638158012; Mon, 20 Feb 2017 16:49:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.179.140 with HTTP; Mon, 20 Feb 2017 16:49:17 -0800 (PST) In-Reply-To: <86FD9E72-0780-4A3E-B0BD-169D39F3D768@vigilsec.com> References: <86FD9E72-0780-4A3E-B0BD-169D39F3D768@vigilsec.com> From: Richard Barnes Date: Mon, 20 Feb 2017 19:49:17 -0500 Message-ID: To: Russ Housley Content-Type: multipart/alternative; boundary=f403045f7ea0f704a20548ffbfaf Archived-At: Cc: Josh Soref , IETF ACME Subject: Re: [Acme] terms-of-service boolean 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, 21 Feb 2017 00:49:21 -0000 --f403045f7ea0f704a20548ffbfaf Content-Type: text/plain; charset=UTF-8 On Mon, Feb 20, 2017 at 5:47 PM, Russ Housley wrote: > > > On Feb 19, 2017, at 12:49 PM, Josh Soref wrote: > > > >> terms-of-service-agreed (optional, boolean): > > > > This should really be a URL, not a boolean. > > > >> : Including this field in a new-account request, > >> with a value of true, indicates the client's agreement with the terms > of service. > >> This field is not updateable by the client. > > > > Consider this flow: > > > > 1. user starts ACME client > > 2. ACME client retrieves metadata from acme server which includes url of > ToS > > 3. ACME server is updated with new ToS > > 4. ACME client presents user w/ ToS from 2 > > 5. user accepts ToS from 4 > > 6. ACME client makes request to acme server with "true" based on 5/4/2 > > 7. ACME server thinks the user has accepted ToS from 3. > > I am not sure that one ought to expect major changes in the > term-of-service without there being significant changes in the CA. > However, you suggest does ensure that the client is accepting the same > terms-of-service that the server is offering. > > Another approach would be to hash the webpage provided by the server. > This was pretty extensively litigated in the working group. The consensus was: In practice, CAs structure their ToS so that they can make unilateral changes. If for some reason a CA does need re-agreement, it can use the "userActionRequired" error code. I'm not sure this particular edge case was considered. But TBH, it seems like there are a few mitigations here short of changing the protocol: - The client can ping the ToS URL immediately before 6 to see if it has changed - The server can simply not change the ToS URL, and present the most current version of its ToS there If you want advisory text to point to these risks / mitigations, by all means file a PR. But given the way ToS are structured in practice, this seems unlikely to be an issue. --Richard > > Russ > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > --f403045f7ea0f704a20548ffbfaf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Feb 20, 2017 at 5:47 PM, Russ Housley <housley@vigilsec.com= > wrote:
<= br> > On Feb 19, 2017, at 12:49 PM, Josh Soref <jsoref@gmail.com> wrote:
>
>> terms-of-service-agreed (optional, boolean):
>
> This should really be a URL, not a boolean.
>
>> : Including this field in a new-account request,
>> with a value of true, indicates the client's agreement with th= e terms of service.
>> This field is not updateable by the client.
>
> Consider this flow:
>
> 1. user starts ACME client
> 2. ACME client retrieves metadata from acme server which includes url = of ToS
> 3. ACME server is updated with new ToS
> 4. ACME client presents user w/ ToS from 2
> 5. user accepts ToS from 4
> 6. ACME client makes request to acme server with "true" base= d on 5/4/2
> 7. ACME server thinks the user has accepted ToS from 3.

I am not sure that one ought to expect major changes in the term-of-= service without there being significant changes in the CA.=C2=A0 However, y= ou suggest does ensure that the client is accepting the same terms-of-servi= ce that the server is offering.

Another approach would be to hash the webpage provided by the server.

This was pretty extensively litigated in the= working group.=C2=A0 The consensus was: In practice, CAs structure their T= oS so that they can make unilateral changes.=C2=A0 If for some reason a CA = does need re-agreement, it can use the "userActionRequired" error= code.

I'm not sure this particular edge c= ase was considered.=C2=A0 But TBH, it seems like there are a few mitigation= s here short of changing the protocol:

- The client can p= ing the ToS URL immediately before 6 to see if it has changed
- The server can simply not change the ToS URL, and present the most curre= nt version of its ToS there

If you want adviso= ry text to point to these risks / mitigations, by all means file a PR.=C2= =A0 But given the way ToS are structured in practice, this seems unlikely t= o be an issue.

--Richard

=C2= =A0

Russ

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

--f403045f7ea0f704a20548ffbfaf-- From nobody Mon Feb 20 16:50:16 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED33D129531 for ; Mon, 20 Feb 2017 16:50:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qra-kCS8r5RZ for ; Mon, 20 Feb 2017 16:50:13 -0800 (PST) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::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 1DC311294F4 for ; Mon, 20 Feb 2017 16:50:13 -0800 (PST) Received: by mail-vk0-x22f.google.com with SMTP id x75so70975450vke.2 for ; Mon, 20 Feb 2017 16:50:13 -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=jxpNWo5YFofhT7XgVwItNGZQrcT27R/RIergQnbVwPY=; b=V/tyWv9OcyWIxUuEITsQKASW7Yyfjc9reOxJt/rZp94tNVK5+xmSB3RogoZ13pZ4xT JaKcq9xqpfktFDR7rgwzwXSdazDYK6/6t6MWSIlu7N30atJaNFPfEKPr/vkjo9E5ctnE v9ObtOJB5CAJVUfZZ84owRwnIfEvSZOvSQ00uVG7xnIaEFmy/uG+47lskDkJx7XSUBR3 2omlmT672xi9wPD4Rzt3hRwLWkRxkMYVrKeM8HBj1FATIgnxTtWERh4PKANVlaEWisgQ IGIbHm4x0gH6i1i63ESIKApqpP9UrS5qag2bnvrC4MsD7+bCg/64zBjM5iqrFWINR8mI O70A== 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=jxpNWo5YFofhT7XgVwItNGZQrcT27R/RIergQnbVwPY=; b=RBuNaLhToSPjiO5qVybjyNp5ZuJxOOeQuWYrb6K+ZLzIWr0StBeAcnxdcuSLfrTy/O 4qe/Y9fMxVTjbo7PbNOJ22gFDiOrDSnXL/PgE47gspCr2qP6gDWE/lZwvX2NbQRNozcW 0a2ly4asFwEmx7wnXu5d/Ipv6VNvKpQX00ZoSlvAgSjEPK0ncjM86M2hLaYAjgcDCyAq dpGYDdfU8umBOLuvw+onHLrEwiMlfteT2mg9lZrnfxgl4pLIbu3s813xqa9qxEcK9Upq fRoRWkVkyHF68JrVP2POvYdkWLnvPNy5z8edu1vlM6VUyEUDRGys9C1XwcTTTzedJycc 9HEw== X-Gm-Message-State: AMke39l4+Ny8QuwxkhqRh2nRpHWtG4b4FTrq+k+1jQxFFZK068WF9zD1pAsEpPuvXhX9L6/N1awGaDpuTtT7NA== X-Received: by 10.31.192.204 with SMTP id q195mr11822694vkf.155.1487638212147; Mon, 20 Feb 2017 16:50:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.179.140 with HTTP; Mon, 20 Feb 2017 16:50:11 -0800 (PST) In-Reply-To: References: From: Richard Barnes Date: Mon, 20 Feb 2017 19:50:11 -0500 Message-ID: To: Russ Housley Content-Type: multipart/alternative; boundary=001a114388cc30914b0548ffc38e Archived-At: Cc: Josh Soref , IETF ACME Subject: Re: [Acme] fulfill 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, 21 Feb 2017 00:50:15 -0000 --001a114388cc30914b0548ffc38e Content-Type: text/plain; charset=UTF-8 On Mon, Feb 20, 2017 at 5:38 PM, Russ Housley wrote: > > > On Feb 19, 2017, at 12:27 PM, Josh Soref wrote: > > > >> A client should attempt to fulfill at most one of these challenges, > > > > fulfill is an odd word. And "attempt" is an odd word in concert. I'm > > pretty sure you're trying to say to a client "once you've fulfilled a > > challenge, you do not need to fulfill any additional challenges", not > > "you should only try one challenge, and if you fail, you should not > > try to complete any of the others". > > > > The "at most one" text is odd... I suppose a client could attempt to > > fulfill zero challenges, but that seems pointless. > > > >> and a server should consider any one of the challenges sufficient to > make the authorization valid. > > > > I think something like: > > > > A server SHOULD treat the challenges portion satisfied when a client > > fulfills one challenge. > > > > That should be sufficient to tell client implementations that they > > need to complete one, and that they don't need to complete more than > > one. Without telling them that if they try one and fail, they > > shouldn't try a different one. > > > > FWIW, as a user, I run into this portion of the spec often. Typically > > my client tries https or http. But a friendly client would be willing > > to try both, stopping if the first one it tries completes, but > > continuing to the second if the first fails. > > +1. This is a significant improvement over the current text. > SGTM. Send a PR? > > Russ > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > --001a114388cc30914b0548ffc38e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Feb 20, 2017 at 5:38 PM, Russ Housley <housley@vigilsec.com= > wrote:
<= br> > On Feb 19, 2017, at 12:27 PM, Josh Soref <jsoref@gmail.com> wrote:
>
>> A client should attempt to fulfill at most one of these challenges= ,
>
> fulfill is an odd word. And "attempt" is an odd word in conc= ert. I'm
> pretty sure you're trying to say to a client "once you've= fulfilled a
> challenge, you do not need to fulfill any additional challenges",= not
> "you should only try one challenge, and if you fail, you should n= ot
> try to complete any of the others".
>
> The "at most one" text is odd... I suppose a client could at= tempt to
> fulfill zero challenges, but that seems pointless.
>
>> and a server should consider any one of the challenges sufficient = to make the authorization valid.
>
> I think something like:
>
> A server SHOULD treat the challenges portion satisfied when a client > fulfills one challenge.
>
> That should be sufficient to tell client implementations that they
> need to complete one, and that they don't need to complete more th= an
> one. Without telling them that if they try one and fail, they
> shouldn't try a different one.
>
> FWIW, as a user, I run into this portion of the spec often. Typically<= br> > my client tries https or http. But a friendly client would be willing<= br> > to try both, stopping if the first one it tries completes, but
> continuing to the second if the first fails.

+1.=C2=A0 This is a significant improvement over the current text.

SGTM.=C2=A0 Send a PR?
=C2=A0

Russ
_____________________= __________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

--001a114388cc30914b0548ffc38e-- From nobody Mon Feb 20 20:31:15 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 56194129A3F for ; Mon, 20 Feb 2017 20:31:13 -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 54Qvl1DMF4Js for ; Mon, 20 Feb 2017 20:31:12 -0800 (PST) Received: from mail-ot0-x231.google.com (mail-ot0-x231.google.com [IPv6:2607:f8b0:4003:c0f::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5586F129A37 for ; Mon, 20 Feb 2017 20:31:12 -0800 (PST) Received: by mail-ot0-x231.google.com with SMTP id k4so61190996otc.0 for ; Mon, 20 Feb 2017 20:31:12 -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; bh=U51kWO/ro43K9ATYo5FzQnAPp41A41j0MO7Ks/OH2vc=; b=n06NfoZVLhU34X8VeTZGaFmYdl0imQeZBFCOvyhqUxAdLS2oT9K17gsQ7kuULVMqTP mgw6Bn997bdWJKoApuDPq0axo2v1wJskkWaAz11puKZEZutiqLFIQcaxdDmHyPiJfQd3 k0qvcz8h0ejmKwqVnVKDzCJZ6Qb2Ruyn1sR2XuI/OJtzi8Wa67j3TSboXTRlMxo4y1GV PVYpwIK1bcC5UJAvUcfO+cF/7bHbcSigTKegDdFBcFrc8bIA8fT3BLSzGb4b3qZiPM6g Dn2aHV4A9ON/xNNOiXFKkI3p3eOZKvSl5x2swgHvdHvV42CbJH6jNe/nhr/uFFt1dQvL L5vw== 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=U51kWO/ro43K9ATYo5FzQnAPp41A41j0MO7Ks/OH2vc=; b=bD5NO6GF4NV3fwT5MZnNYv9PKpKBLwJGiDl1ocJLCJ++D/0WWtIcPo5I8mHqDVB/J9 pwjutXdU+eGq5LHVASaPxb6oxVWtqNaug7NRIxNZYlHCSyV54+UQga4T9LMCe1empa3Z xyacOUolQcZ34InPS2HcXpm1ASu36QD2MBEahxWw4XMDz0slGSoqL+sD4/pQkzG3TASz IvU4ng9gW+jbgBgBQLIpbC7FHqWF8zhmc/3XVbkRrzm2r3mlxILw/ROFdmSgwcHZpV1e w2Uj8kUWYF26ByYXU5WuUHcTeNekHR5laSuEboF6WMzZ6TsORgv/R57T5a6HyFUtMceG wc+A== X-Gm-Message-State: AMke39lCE0Uu7mAbCBL2RL7F+LHJ6jdqNzhMOEHykpWWSXzYrheO8fGX+elJyb8B7vqfP49/O6nRoy7X+TJycQ== X-Received: by 10.157.51.55 with SMTP id f52mr1092017otc.18.1487651471567; Mon, 20 Feb 2017 20:31:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.5.169 with HTTP; Mon, 20 Feb 2017 20:31:11 -0800 (PST) In-Reply-To: References: From: Josh Soref Date: Mon, 20 Feb 2017 23:31:11 -0500 Message-ID: To: IETF ACME Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Acme] fulfill 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, 21 Feb 2017 04:31:13 -0000 Richard Barnes wrote: > SGTM. Send a PR? I've tacked it into my current queue. I can't really manage dozens of PRs for a small project. It's bad enough that I have 3 in flight From nobody Tue Feb 21 07:04: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 36600129C05 for ; Tue, 21 Feb 2017 07:04:27 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 mwXe0M77s2r2 for ; Tue, 21 Feb 2017 07:04:24 -0800 (PST) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::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 76DFE1294B7 for ; Tue, 21 Feb 2017 07:04:24 -0800 (PST) Received: by mail-lf0-x22c.google.com with SMTP id g134so22192995lfe.1 for ; Tue, 21 Feb 2017 07:04:24 -0800 (PST) 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=L4ApedVkfZpq+U+k8fcGuLI+9bT+vkg+G56H7baJqMM=; b=U485Z8H7mDWTuuQBS+TyZP6w11tDYxEZ9BEU5WeHf6s7UoFDML0QORVj2whdqAVlmU rHM2RvhBax9iWUPOeo+gYxIAHkr36ffWWJ70SaL1OCFrhFABGd0a+ChQeVqziME7WD2r w9az67VoE97CQR9USm5yeSImLgeNrUKm2dOA8= 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=L4ApedVkfZpq+U+k8fcGuLI+9bT+vkg+G56H7baJqMM=; b=AGFA/KVgCK0PeWLRx/IL15qFpVanZsOJQGXd7+B+eKARZqm2krzvdpEKKqebK+wcqB AfUsD7yJYaU4nNSxt33pQA0qpFm3UlHlKcNsVaMHpqRSsTde7w/gZBibS8Qy8y90SLwp d9GHKfSigEoxxMOxpfznuN+ryFrJb3bW9EYo5eWcLAPpiVidnW61XAzkIgT6FWsVrhvy 75045KbsAoJ1sRfIVKL5VOugwuoB7lCo09Zc1kYafhWyRvd9fJU0E1epiXcfybBh6jAj O5A+JYo6NAcgaHeC3y14KNj8A3Em5lC69E2WxXw+hVwHdDJ7CHx44xutdlfukp/nEH/p hE5w== X-Gm-Message-State: AMke39nJtqBKvHMKl4ANQsx40P4nAGufLMEBrw/ikazrUTspIYXE5fHIxzMb2BEsrMdJF/kilmX9yBCznRxuUmh/ X-Received: by 10.46.1.201 with SMTP id f70mr7424530lji.21.1487689462245; Tue, 21 Feb 2017 07:04:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.162.72 with HTTP; Tue, 21 Feb 2017 07:04:21 -0800 (PST) In-Reply-To: References: <81377754-e24d-269d-0f48-ba37e55f8942@eff.org> From: Daniel McCarney Date: Tue, 21 Feb 2017 10:04:21 -0500 Message-ID: To: Richard Barnes Content-Type: multipart/alternative; boundary=001a11426deaef062f05490bb1d0 Archived-At: Cc: Alan Doherty , "acme@ietf.org" , Martin Thomson , Jacob Hoffman-Andrews , Clint Wilson Subject: Re: [Acme] HPKP in ACME X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: cpu@letsencrypt.org List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 15:04:27 -0000 --001a11426deaef062f05490bb1d0 Content-Type: text/plain; charset=UTF-8 > Does anyone else feel strongly? Can we aim for consensus for > Monday? Update four days later: one additional +1 for removal from Josh Soref. Are the maintainers comfortable merging https://github.com/ietf-wg-acme/acme/pull/244 ? On Fri, Feb 17, 2017 at 12:28 PM, Daniel McCarney wrote: > > Perhaps we could downgrade to MAY WISH TO > > https://tools.ietf.org/html/rfc6919#section-6 > > This feels a little wishy-washy for something I think we could tie-break > without > too much delay. > > Jacob, Clint, and myself all stated support for removing it. You're OK with > dropping it. I think Alan is in a similar mid-point camp. (Please weigh in > if > I'm mis-characterizing) > > Does anyone else feel strongly? Can we aim for consensus for > Monday? > > > On Thu, Feb 16, 2017 at 5:44 PM, Richard Barnes wrote: > >> >> >> On Thu, Feb 16, 2017 at 4:24 PM, Daniel McCarney >> wrote: >> >>> I'm supportive of removing the server pinning headers SHOULD outright. >>> >>> > but how best to word that i don't know >>> >>> I don't think there's much benefit in the ACME spec discussing pinning >>> from >>> a client perspective. >>> >>> If the clients want to pin there isn't anything about ACME that makes the >>> process different than (for e.g.) using square's okhttp library to pin >>> for any >>> other HTTPS server. Am I overlooking something? >>> >> >> There's nothing different. The idea here was just to point people to >> some mechanisms they could use to guard against mis-issuance. I'm OK >> dropping it if people don't like it, but I would kind of like to keep it. >> >> Perhaps we could downgrade to MAY WISH TO >> https://tools.ietf.org/html/rfc6919#section-6 >> >> >> >> >> >>> >>> >>> On Mon, Feb 13, 2017 at 3:29 PM, Alan Doherty >>> wrote: >>> >>>> I would concur that clients should endeavour to support >>>> >>>> (and thusly CAs can consider using in future, when support is available >>>> in wider librarys) >>>> >>>> but because of the risks they should only consider doing so >>>> if/when all their processes are in place to ensure failures can't occur >>>> >>>> but how best to word that i don't know >>>> >>>> At 20:09 13/02/2017 Monday, Clint Wilson wrote: >>>> >I would definitely support removing ", and servers SHOULD emit pinning >>>> headers", especially because of the footgun risk you indicated, but I think >>>> there is some merit in continuing to recommend support for HPKP on the >>>> client side. >>>> > >>>> >On Mon, Feb 13, 2017 at 12:33 PM Jacob Hoffman-Andrews <>>> jsha@eff.org>jsha@eff.org> 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? >>>> > >>>> >PR to remove: >>>> https://github.com/ietf-wg-acme/acme/pull/244 >>>> > >>>> >_______________________________________________ >>>> >Acme mailing list >>>> >Acme@ietf.org >>>> >https://www.ietf.org/mailman/listinfo/acme >>>> > >>>> >_______________________________________________ >>>> >Acme mailing list >>>> >Acme@ietf.org >>>> >https://www.ietf.org/mailman/listinfo/acme >>>> >>>> _______________________________________________ >>>> Acme mailing list >>>> Acme@ietf.org >>>> https://www.ietf.org/mailman/listinfo/acme >>>> >>> >>> >>> _______________________________________________ >>> Acme mailing list >>> Acme@ietf.org >>> https://www.ietf.org/mailman/listinfo/acme >>> >>> >> > --001a11426deaef062f05490bb1d0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
>=C2=A0Does anyone els= e feel strongly? Can we aim for consensus for=C2=A0
> Monday?

Update f= our days later: one additional +1 for removal from Josh Soref.

Are t= he maintainers comfortable merging=C2=A0https://github.com/ietf-wg-acme/acme/pull/244 ?<= br>

On Fri, Feb 17, 2017 at 12:28 PM, Daniel McCarney <= cpu@letsencrypt.or= g> wrote:
= >=C2=A0Perhaps we coul= d downgrade to MAY WISH TO
>=C2=A0<= a href=3D"https://tools.ietf.org/html/rfc6919#section-6" style=3D"font-size= :12.8px" target=3D"_blank">https://tools.ietf.org/html/rfc6919#section= -6

This feels a little wishy-washy for something I t= hink we could tie-break without
too much delay.

Jacob, Clint, and myself all stated support for removing it. You= 9;re OK with
dropping it. I think Alan is in a similar mid-point = camp. (Please weigh in if
I'm mis-characterizing)

Does anyone= else feel strongly? Can we aim for consensus for=C2=A0
Monday?


On Thu, Feb 16, 2017 at 5:44 P= M, Richard Barnes <rlb@ipv.sx> wrote:


On Thu, Feb 16, 2017 at 4:24 PM, Daniel McCarney <cpu@l= etsencrypt.org> wrote:
I'm supportive of removing the ser= ver pinning headers SHOULD outright.

> but how best to wo= rd that i don't know

I don't think = there's much benefit in the ACME spec discussing pinning from
a client perspective.

If the clients want to pin = there isn't anything about ACME that makes the
process differ= ent than (for e.g.) using square's okhttp library to pin for any
<= div>other HTTPS server. Am I overlooking something?

There's nothing different.=C2=A0 The idea h= ere was just to point people to some mechanisms they could use to guard aga= inst mis-issuance.=C2=A0 I'm OK dropping it if people don't like it= , but I would kind of like to keep it.=C2=A0

Perhaps we = could downgrade to MAY WISH TO
https://tools.ietf.org/html/rfc6919= #section-6
=C2=A0


=C2=A0


On Mon, Feb 13, 2017 at 3:29 PM, Alan Doherty &l= t;ietf@alandohert= y.net> wrote:
I would concur that clients should endeavour to support

(and thusly CAs can consider using in future, when support is available in = wider librarys)

but because of the risks they should only consider doing so
if/when all their processes are in place to ensure failures can't occur=

but how best to word that i don't know

At 20:09 13/02/2017=C2=A0 Monday, Clint Wilson wrote:
>I would definitely support removing ", and servers SHOULD emit pin= ning headers", especially because of the footgun risk you indicated, b= ut I think there is some merit in continuing to recommend support for HPKP = on the client side.
>
>On Mon, Feb 13, 2017 at 12:33 PM Jacob Hoffman-Andrews <= ;<mailto:jsha@eff.org<= /a>>jsha@eff.org<= /a>> wrote:
>Martin brought up a section I've been considering removing:
>
>> Clients SHOULD support HTTP public key pinning [RFC7469], and serv= ers
>SHOULD emit pinning headers.
>
>Here's my reasoning:
>
>- Public key pinning isn't implemented in most HTTPS libraries outs= ide
>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 woul= d
>be that some of those clients would fail to renew their certs, causing<= br> >cascading breakage.
>- There is relatively little confidential information conveyed in ACME,=
>and there are other defenses built into ACME (like including the accoun= t
>key as part of the challenge data), so HPKP is not strongly necessary.<= br> >
>Any objections?
>
>PR to remove: <https://github.com/ietf-wg= -acme/acme/pull/244>https://github.com= /ietf-wg-acme/acme/pull/244
>
>_______________________________________________
>Acme mailing list
><mailto:Acme@ietf= .org>Acme@ie= tf.org
>https://www.ietf.org/mailman/listinfo/acme
>
>_______________________________________________
>Acme mailing list
>Acme@ietf.org >https://www.ietf.org/mailman/listinfo/acme
_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme


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




--001a11426deaef062f05490bb1d0-- From nobody Tue Feb 21 07:34:48 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 704BC129C25 for ; Tue, 21 Feb 2017 07:34:46 -0800 (PST) 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, HTML_MESSAGE=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 l95kLsH8VMmJ for ; Tue, 21 Feb 2017 07:34:44 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB754129491 for ; Tue, 21 Feb 2017 07:34:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id F3D8C30041F for ; Tue, 21 Feb 2017 10:34:42 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id NK9jhgmj09JU for ; Tue, 21 Feb 2017 10:34:40 -0500 (EST) Received: from [10.5.245.234] (wsip-98-172-24-238.dc.dc.cox.net [98.172.24.238]) by mail.smeinc.net (Postfix) with ESMTPSA id 63BE0300222 for ; Tue, 21 Feb 2017 10:34:40 -0500 (EST) From: Russ Housley Content-Type: multipart/signed; boundary="Apple-Mail=_88D1A926-E31C-4E38-AC9C-AA791D1F5DA9"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Tue, 21 Feb 2017 10:34:39 -0500 References: <81377754-e24d-269d-0f48-ba37e55f8942@eff.org> To: IETF ACME In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3259) Archived-At: 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, 21 Feb 2017 15:34:46 -0000 --Apple-Mail=_88D1A926-E31C-4E38-AC9C-AA791D1F5DA9 Content-Type: multipart/alternative; boundary="Apple-Mail=_9907C7F7-D839-4647-B7F0-7182DDCBCCA3" --Apple-Mail=_9907C7F7-D839-4647-B7F0-7182DDCBCCA3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I am in favor of removing the SHOUL for HPKP. As I said in my WG Last = Call comments, I support a SHOULD for OCSP stapling. Russ > On Feb 21, 2017, at 10:04 AM, Daniel McCarney = wrote: >=20 > > Does anyone else feel strongly? Can we aim for consensus for=20 > > Monday? >=20 > Update four days later: one additional +1 for removal from Josh Soref. >=20 > Are the maintainers comfortable merging = https://github.com/ietf-wg-acme/acme/pull/244 = ? >=20 >=20 > On Fri, Feb 17, 2017 at 12:28 PM, Daniel McCarney > wrote: > > Perhaps we could downgrade to MAY WISH TO > > https://tools.ietf.org/html/rfc6919#section-6 = >=20 > This feels a little wishy-washy for something I think we could = tie-break without > too much delay. >=20 > Jacob, Clint, and myself all stated support for removing it. You're OK = with > dropping it. I think Alan is in a similar mid-point camp. (Please = weigh in if > I'm mis-characterizing) >=20 > Does anyone else feel strongly? Can we aim for consensus for=20 > Monday? >=20 >=20 > On Thu, Feb 16, 2017 at 5:44 PM, Richard Barnes > wrote: >=20 >=20 > On Thu, Feb 16, 2017 at 4:24 PM, Daniel McCarney > wrote: > I'm supportive of removing the server pinning headers SHOULD outright. >=20 > > but how best to word that i don't know >=20 > I don't think there's much benefit in the ACME spec discussing pinning = from > a client perspective. >=20 > If the clients want to pin there isn't anything about ACME that makes = the > process different than (for e.g.) using square's okhttp library to pin = for any > other HTTPS server. Am I overlooking something? >=20 > There's nothing different. The idea here was just to point people to = some mechanisms they could use to guard against mis-issuance. I'm OK = dropping it if people don't like it, but I would kind of like to keep = it. =20 >=20 > Perhaps we could downgrade to MAY WISH TO > https://tools.ietf.org/html/rfc6919#section-6 = > =20 >=20 >=20 > =20 >=20 >=20 > On Mon, Feb 13, 2017 at 3:29 PM, Alan Doherty > wrote: > I would concur that clients should endeavour to support >=20 > (and thusly CAs can consider using in future, when support is = available in wider librarys) >=20 > but because of the risks they should only consider doing so > if/when all their processes are in place to ensure failures can't = occur >=20 > but how best to word that i don't know >=20 > At 20:09 13/02/2017 Monday, Clint Wilson wrote: > >I would definitely support removing ", and servers SHOULD emit = pinning headers", especially because of the footgun risk you indicated, = but I think there is some merit in continuing to recommend support for = HPKP on the client side. > > > >On Mon, Feb 13, 2017 at 12:33 PM Jacob Hoffman-Andrews = <>jsha@eff.org = > 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? > > > >PR to remove: >https://github.com/ietf-wg= -acme/acme/pull/244 > > > >_______________________________________________ > >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 > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme = >=20 >=20 > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme = >=20 >=20 >=20 >=20 > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme --Apple-Mail=_9907C7F7-D839-4647-B7F0-7182DDCBCCA3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I am in favor of removing the SHOUL for HPKP.  As I said = in my WG Last Call comments, I support a SHOULD for OCSP stapling.

Russ


On = Feb 21, 2017, at 10:04 AM, Daniel McCarney <cpu@letsencrypt.org>= wrote:

> Does anyone else feel strongly? Can we aim for consensus = for 
> Monday?

Update four days later: one additional +1 for removal from = Josh Soref.

Are the maintainers comfortable = merging https://github.com/ietf-wg-acme/acme/pull/244 ?


On Fri, Feb 17, 2017 at 12:28 PM, = Daniel McCarney <cpu@letsencrypt.org> wrote:
> Perhaps we could downgrade to MAY WISH TO
> https://tools.ietf.org/html/rfc6919#section-6

This feels a little wishy-washy for something I think we = could tie-break without
too much delay.

Jacob, Clint, and myself = all stated support for removing it. You're OK with
dropping it. I think Alan is in a similar mid-point camp. = (Please weigh in if
I'm mis-characterizing)

Does anyone else feel strongly? Can we aim for = consensus for 
Monday?


On Thu, Feb 16, 2017 at 5:44 PM, Richard Barnes = <rlb@ipv.sx> wrote:


On Thu, Feb 16, 2017 at 4:24 PM, = Daniel McCarney <cpu@letsencrypt.org> wrote:
I'm supportive of removing the = server pinning headers SHOULD outright.

> but how best to = word that i don't know

I don't think there's much = benefit in the ACME spec discussing pinning from
a = client perspective.

If the clients want to pin there isn't anything about ACME = that makes the
process different than (for e.g.) = using square's okhttp library to pin for any
other = HTTPS server. Am I overlooking something?

There's nothing = different.  The idea here was just to point people to some = mechanisms they could use to guard against mis-issuance.  I'm OK = dropping it if people don't like it, but I would kind of like to keep = it. 

Perhaps we = could downgrade to MAY WISH TO
https://tools.ietf.org/html/rfc6919#section-6
 


 


On Mon, = Feb 13, 2017 at 3:29 PM, Alan Doherty <ietf@alandoherty.net> wrote:
I would = concur that clients should endeavour to support

(and thusly CAs can consider using in future, when support is available = in wider librarys)

but because of the risks they should only consider doing so
= if/when all their processes are in place to ensure failures can't = occur

but how best to word that i don't know

At 20:09 13/02/2017  Monday, Clint Wilson wrote:
>I would definitely support removing ", and servers SHOULD emit = pinning headers", especially because of the footgun risk you indicated, = but I think there is some merit in continuing to recommend support for = HPKP on the client side.
>
>On Mon, Feb 13, 2017 at 12:33 PM Jacob = Hoffman-Andrews <<mailto:jsha@eff.org>jsha@eff.org> 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?
>
>PR to remove: <https://github.com/ietf-wg-acme/acme/pull/244>https://github.com/ietf-wg-acme/acme/pull/244
>
>_______________________________________________
>Acme mailing list
><mailto:Acme@ietf.org>Acme@ietf.org
>https://www.ietf.org/mailman/listinfo/acme
>
>_______________________________________________
>Acme mailing list
>Acme@ietf.org
>https://www.ietf.org/mailman/listinfo/acme

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


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




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

= --Apple-Mail=_9907C7F7-D839-4647-B7F0-7182DDCBCCA3-- --Apple-Mail=_88D1A926-E31C-4E38-AC9C-AA791D1F5DA9 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ9zCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBUAwggQooAMCAQICEQCzIsUuKpsHVq2Oiy2wXwvCMA0GCSqGSIb3DQEBCwUAMIGbMQswCQYD VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRow GAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTYwMzMxMDAwMDAwWhcNMTcw MzMxMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkBFhRob3VzbGV5QHZpZ2lsc2VjLmNvbTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAOQwBbNVXhmLbyClWrRBX0GdNQFhVHEpbzM4tr5pdd0q rPp8i+6qqNa4dAbJT6kodJ/LgsBi5EN3li4MJOIlf3rCsK1/VXepRwqUoc1cZfLRGdEj/4zgwrNZ ULvOFiDIvYkAYDWRlYnEXulWr3KriOApHpfzbQvHStU1YsV762AIHVbZUW5tlTC9LfI8r+PIBFzv Y5ujoUnSAgKgeE8gDK9yAxemrQ6wzDpwaf5PxEVnw0gOC2jtDojdzhoQfz57MFrL9pA1QyMbnItV zCYfc5J7EfeCGupcFqwXytbJHSYPfLfM1/3omGgCGD/DZk4z4SUVC19k02iGxAIVDsWJ5oMCAwEA AaOCAfIwggHuMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBTrsV85 Y7qY6oVPF5xRd+wqIu3VJTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BT MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNs aWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGA MFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRB dXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2Nz cC5jb21vZG9jYS5jb20wHwYDVR0RBBgwFoEUaG91c2xleUB2aWdpbHNlYy5jb20wDQYJKoZIhvcN AQELBQADggEBACgHw+/VeC7LgLJs19KZ6Ds2cW+jLSPjA3AIqSxiQ+uyDFwe6FujBUqRCXfla0qg MzbhJ+1uSxcaktsS5idpB5Dfp8SVEGLcjtSJwWVlEofjaRrx6pi2mzazQwfKklY/epvsgnCoY8KW FeSGkpbQXu5WrIL18EFqMCHqDiu5/P49PcZnJRv2xHTi5CkIsI7XgOw4FazS3xuJMVQ5TVtIUeMW OqRlNJaeTiBsOVauS3FE/zRejsAYhHp3EV1PZFhV6hdcK/8qKrqRBtZtsEIm2FNWNsk8p/3RmUQl 4n4qN/NvapmXyYqfHZiuxf2g8H/WHF8IlVDzljLy90Uy0X7Qp0gxggPGMIIDwgIBATCBsTCBmzEL MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAsyLFLiqbB1atjostsF8L wjAJBgUrDgMCGgUAoIIB6TAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzAyMjExNTM0NDBaMCMGCSqGSIb3DQEJBDEWBBRHEn+acfSw7/mPp5kjt9huSPc4nTCBwgYJ KwYBBAGCNxAEMYG0MIGxMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEQCzIsUuKpsHVq2Oiy2wXwvCMIHEBgsqhkiG9w0BCRACCzGBtKCBsTCBmzELMAkGA1UEBhMC R0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAsyLFLiqbB1atjostsF8LwjANBgkqhkiG 9w0BAQEFAASCAQCLUSoECmy36KM+l9v1swCKQk4tsIPYCR9EUWX4giHL1VXDD9mcw8r4+Sos+kvp LCTlPDhgt85rVqJUwaN7S5NIKPm1EEdHMLHmjLnBToE+nocsxQixZcKBNdlKTxLKLa8gXv98W5/K BM3laCq3TZCm2Uck5sbfTDf/PinUrQLoyk8fu11Mf7AspglYuDVjE5BRY6Rq4xVBW9KqdjC55xOt vuW6DWONpZJVD6QZ6d8AwKn3bCwBxwdavN/YjitZ4hmX9sHSC9dzt5BYbWHriboZz7teyK1oVbMP 5oSZw8tbQvWNng4kQIjbq8Nhj4P4xNFByMU3sQhyzt10BdmpZZT+AAAAAAAA --Apple-Mail=_88D1A926-E31C-4E38-AC9C-AA791D1F5DA9-- From nobody Tue Feb 21 12:56: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 F07401297C2 for ; Tue, 21 Feb 2017 12:56:02 -0800 (PST) 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 lbtDdnwTTII2 for ; Tue, 21 Feb 2017 12:56:01 -0800 (PST) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::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 73E7D1297C1 for ; Tue, 21 Feb 2017 12:56:01 -0800 (PST) Received: by mail-pg0-x22f.google.com with SMTP id z128so3620440pgb.0 for ; Tue, 21 Feb 2017 12:56:01 -0800 (PST) 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=TZ6Oizl625FlIvvX4qan9rCA5lRfTP5fyx7gsCu7xuI=; b=GUNNdHMSv5wBG9I4MEaAgc1uaiKaHu3EoL+8UARtytg1RpTG7DTZo/wA3/p2/RcMPJ o3d2bJeaTj5H/Ko1faC48xScsKC/oLwWZF95NdTEwFl1UF4S8m0flcOKXSHjeO2bbPwy jRaRiwdfW5ceuRE8z7ijb8ABAaOwNd1Qd4wRg= 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=TZ6Oizl625FlIvvX4qan9rCA5lRfTP5fyx7gsCu7xuI=; b=Db5IPYRvSptBhrXzAnsNnCpMsTaB7kuhglEcACW2GIEmgPxREALMSyxaRA3aHO8Qe+ po24js9Hxg2JYFU2W+Qgt+tFET0u6DKXHnXi7cwxtKP57LqrKHeHx6Ewc4cJ2OWt//Jo DVkbvDbRU75qkIFVHXDJ+xvfpXSu4G7k0hX8cW+rFpafpIAuj98uGaPQU6PLoRm6Arun cXabJa1WAp6Ls8ppwSVyRhmyXJxax+2BJpP6gtXc5J8xI27Q5fwsdmiyvhD5uGNwbfOb VImnzPk+rgzjiZzbW/0/oQYIO42XNMrH1tDTGKoOYNj1KNDUMEBxBmuhG087FVCezHdA dhTQ== X-Gm-Message-State: AMke39mGQrdaw6PkiYb8nB0Z4MVRzSC6GmZ6T7agXADN/Ogq1nZtmL3zvjyZHZnoJYpSpvaM X-Received: by 10.84.139.195 with SMTP id 61mr42480818plr.116.1487710560583; Tue, 21 Feb 2017 12:56:00 -0800 (PST) Received: from [10.120.0.195] (eff.static.monkeybrains.net. [208.90.213.162]) by smtp.gmail.com with ESMTPSA id i82sm42641574pfk.52.2017.02.21.12.55.59 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Feb 2017 12:56:00 -0800 (PST) To: "acme@ietf.org" From: Roland Shoemaker Message-ID: <8dc136ca-a994-ccb4-3339-5bbec22b9149@letsencrypt.org> Date: Tue, 21 Feb 2017 12:55:59 -0800 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] Minimizing risk of key compromise 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, 21 Feb 2017 20:56:03 -0000 How would people feel about adding some language to the account key roll-over section that says that any cached (already valid) authorizations for identifiers should be deactivated on roll-over? This would reduce the risk of an attacker gaining control of an account and all associated authorizations in such a way that the original user could not revoke the authorizations themselves. The original user would still be able to revoke any certificates containing identifiers for these authorizations themselves (by creating new authorizations for the identifiers in the certificate) but a attacker could simply add a single new identifier which the original user does not have control over to prevent this with the current design. -- Roland Bracewell Shoemaker Software Engineer Linux Foundation / Internet Security Research Group From nobody Tue Feb 21 20:08: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 3F070129581 for ; Tue, 21 Feb 2017 20:07:59 -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 RGzrhl_P_5re for ; Tue, 21 Feb 2017 20:07:57 -0800 (PST) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::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 BE8AA12957E for ; Tue, 21 Feb 2017 20:07:57 -0800 (PST) Received: by mail-oi0-x234.google.com with SMTP id 62so63978424oih.2 for ; Tue, 21 Feb 2017 20:07:57 -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=7Q84dZesBRo/KetAHJ4QbqpnmczDTX8Nw+TXYcRKZQk=; b=Oxy0NxiY51u+A/JfOJMyOgvf477fOIoltaJvlI90E93N/iyf3eFP01ZABIGH8ZCyWT jqp6FZ3lDmtqha2jt1T90r8817GEYZyrGOu2xOudE0WECLiiI9Gf6Azu4XA6v3Tdz6Az Ai9i7wYbUr9LLGX4/weA3FZuNRUdAF3qsSnSubRWJ9D7z5duljqknL+cKtMEyEPKPKYI wqaVdHdsgr8WARZDoX3S+/W1qi5ZVELWpWp5H7r+t8pDDsd3fEEaUBuLafh5fBh0g20p F+egpubZmOoNAokds195Us3reD7mCfr1ElnNkRS15JKw0KCtY6Iv0B+baeEk4WGU5xf6 LxNA== 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=7Q84dZesBRo/KetAHJ4QbqpnmczDTX8Nw+TXYcRKZQk=; b=m02dSDxOFZgpjdKC8fLsWmaClLt9ucyGQboiIh2Jj8hsxskfwfnIko1Tzu895w5dpO qoURqmkBodB86NxVqyqNjrsFCdH+9hmJlchIkv6M3N2X5+9KxomHieSLOB1+g7LZfe/4 OHCUqzSHEtT8/3n17erFFa7rzG3OZYeGQER7kWq2JB8RXffklk3ihEKPNFdl90ouGbh6 oZbf4OX/dFEQfUG+JlOehrk6QksYQIT0BJkTWHjKZTqfDWwqvwOKJls+MjPKjhlqBtsC PmN1am3kUZmX+ytZT/OnAOyERfeJpLcKUK/7H4LLCCCM+67jfHHWCygUhWgVQ8ajdH+N 2xCw== X-Gm-Message-State: AMke39lyOrKtGgdqIYYsPuS4dkqLPbs7X4hk0ws6guk4SQoOvmNwMqMQZMQZ/p21DDe+7+7WQCVhQqaQMYupvg== X-Received: by 10.202.8.71 with SMTP id 68mr16033232oii.59.1487736477008; Tue, 21 Feb 2017 20:07:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.5.169 with HTTP; Tue, 21 Feb 2017 20:07:56 -0800 (PST) From: Josh Soref Date: Tue, 21 Feb 2017 23:07:56 -0500 Message-ID: To: IETF ACME Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Acme] ambiguous server 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, 22 Feb 2017 04:07:59 -0000 https://github.com/ietf-wg-acme/acme/blob/28295572ca191cd14d6a9a21912b8d03aa65b885/draft-ietf-acme-acme.md#http > 3. Dereference the URI using an HTTP GET request. This request MUST be sent to TCP port 80 on the server. I think server here is http-server > 4. Verify that the body of the response is well-formed key authorization. The server SHOULD ignore whitespace characters at the end of the body. I think here server is acme-server > 5. Verify that key authorization provided by the server matches the token for this challenge and the client's account key. I think here server is acme-server I'm not certain, but in cases where acme spec is talking about the acme server acting as an http client, I'd request that `server` not be used bare. The easiest solution imo is labeling `acme-server` and `{http(s)}-server` / similar. But I'm open to other proposals. From nobody Wed Feb 22 06:48: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 1816A1299A7 for ; Wed, 22 Feb 2017 06:48:43 -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, 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 1zStqnsofIsE for ; Wed, 22 Feb 2017 06:48:41 -0800 (PST) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::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 A113112987D for ; Wed, 22 Feb 2017 06:48:40 -0800 (PST) Received: by mail-lf0-x232.google.com with SMTP id b80so2499110lfe.3 for ; Wed, 22 Feb 2017 06:48:40 -0800 (PST) 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=FVnN+s1fmCB8VDpcxZFEA5Exshh6Zn5gYw69gheJsuQ=; b=FEGxUzdofXtazLmPX35J5jTGsDPw+ZLWgh2gRs9bZuVo7bzXxMvyzzADpfPvg5a34Z jGcrQKU8C2CsowedMq2J06QPO0SfUQ6cSQUBTNgVyatjwx0KlVbBjimPFrCpRC5a0T3Z 7EiZhCSOdqs7cUph1agkpRutFJLT0AH8kHpcE= 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=FVnN+s1fmCB8VDpcxZFEA5Exshh6Zn5gYw69gheJsuQ=; b=NQ+EeRUTf8TQFJgvtzAY9Dj4QCNmvmevY+YWjiYRJN5arQbMdjNTDVLfcMwLHszi74 lgfSOhNsr/FD6akc3hgBkuAJXolpONGTtjsOFvfbzZyv5Q0ZpCHY8S+ISd/P73NFFiGe Wl+IFyhWpX9xvrHhOKau4H368fbE6MVHkpqwmFmdAgDwADTIahzwzE0KyuYBoX6zJljQ BC5WvY3im2dUVPqEE0AjpbAse22lgbjEIIMnWpk8pyu1l5tSna8M1trmdGRCJWHM5+M7 p/bTvCgxJTL2xaUotGCcYjabtlDIkW9s1OByk1SJcOEixpP1bOev3aJ8VtLXVmEtXNja GTzg== X-Gm-Message-State: AMke39mIEPJKfEfkUwTvJRCBQ8vuQPr0ZHDDoBEGG8BGVv2lugZ6yuxWBJ62jMFUPsIcD1PPgTQZ0aCyV9CXZyD2 X-Received: by 10.46.1.201 with SMTP id f70mr9045768lji.21.1487774918574; Wed, 22 Feb 2017 06:48:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.162.72 with HTTP; Wed, 22 Feb 2017 06:48:37 -0800 (PST) In-Reply-To: References: From: Daniel McCarney Date: Wed, 22 Feb 2017 09:48:37 -0500 Message-ID: To: Josh Soref Content-Type: multipart/alternative; boundary=001a11426dea871c3e05491f97dd Archived-At: Cc: IETF ACME Subject: Re: [Acme] ambiguous server in acme X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: cpu@letsencrypt.org List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 14:48:43 -0000 --001a11426dea871c3e05491f97dd Content-Type: text/plain; charset=UTF-8 > I'm not certain, but in cases where acme spec is talking about the > acme server acting as an http client, I'd request that `server` not be > used bare. > The easiest solution imo is labeling `acme-server` and > `{http(s)}-server` / similar. But I'm open to other proposals. Agreed - I think this is a sensible change to reduce confusion. "ACME server" and "HTTP challenge server" seem like good choices but I'm also not tied to anything. >> 3. Dereference the URI using an HTTP GET request. This request MUST be sent >> to TCP port 80 on the server. >I think server here is http-server +1 >> 4. Verify that the body of the response is well-formed key authorization. The >> server SHOULD ignore whitespace characters at the end of the body. > I think here server is acme-server +1 >> 5. Verify that key authorization provided by the server matches the token for this challenge and the client's account key. > I think here server is acme-server I think this one should be "Verify that the key authorization provided by the HTTP challenge server", not the acme-server (or I need more coffee/cleaner glasses). Are you going to send a PR for this? If you're tied up with your existing PRs I will find a pinch hitter. - cpu On Tue, Feb 21, 2017 at 11:07 PM, Josh Soref wrote: > https://github.com/ietf-wg-acme/acme/blob/28295572ca191cd14d6a9a21912b8d > 03aa65b885/draft-ietf-acme-acme.md#http > > > 3. Dereference the URI using an HTTP GET request. This request MUST be > sent to TCP port 80 on the server. > > I think server here is http-server > > > 4. Verify that the body of the response is well-formed key > authorization. The server SHOULD ignore whitespace characters at the end of > the body. > > I think here server is acme-server > > > 5. Verify that key authorization provided by the server matches the > token for this challenge and the client's account key. > > I think here server is acme-server > > > I'm not certain, but in cases where acme spec is talking about the > acme server acting as an http client, I'd request that `server` not be > used bare. > The easiest solution imo is labeling `acme-server` and > `{http(s)}-server` / similar. But I'm open to other proposals. > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > --001a11426dea871c3e05491f97dd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> I'm not certain, but in cases where acme spe= c is talking about the
> acme server acting as an http client,= I'd request that `server` not be
> used bare.
&= gt; The easiest solution imo is labeling `acme-server` and
> `= {http(s)}-server` / similar. But I'm open to other proposals.

Agreed - I think this is a sensible change to reduce confus= ion. "ACME server"
and "HTTP challenge server"= ; seem like good choices but I'm also not tied to
anything.

>> 3. Dereference the URI using an HTTP GET request.= This request MUST be sent
>> to TCP port 80 on the server.=
>I think server here is http-server

= +1

>> 4. Verify that the body of the respons= e is well-formed key authorization. The
>> server SHOULD ig= nore whitespace characters at the end of the body.
> I think h= ere server is acme-server

+1

<= div>>> 5. Verify that key authorization provided by the server matche= s the token for
this challenge and the client's account key.<= /div>
> I think here server is acme-server

= I think this one should be "Verify that the key authorization provided= by the
HTTP challenge server", not the acme-server (or I ne= ed more coffee/cleaner
glasses).

Are you= going to send a PR for this? If you're tied up with your existing PRs<= /div>
I will find a pinch hitter.

- cpu
<= div>

On Tue, Feb 21, 2017 at 11:07 PM, Josh Soref <jsoref@gmail.com> wrote:
https://github.co= m/ietf-wg-acme/acme/blob/28295572ca191cd14d6a9a21912b8d03aa6= 5b885/draft-ietf-acme-acme.md#http

> 3. Dereference the URI using an HTTP GET request. This request MUST be= sent to TCP port 80 on the server.

I think server here is http-server

> 4. Verify that the body of the response is well-formed key authorizati= on. The server SHOULD ignore whitespace characters at the end of the body.<= br>
I think here server is acme-server

> 5. Verify that key authorization provided by the server matches the to= ken for this challenge and the client's account key.

I think here server is acme-server


I'm not certain, but in cases where acme spec is talking about the
acme server acting as an http client, I'd request that `server` not be<= br> used bare.
The easiest solution imo is labeling `acme-server` and
`{http(s)}-server` / similar. But I'm open to other proposals.

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

--001a11426dea871c3e05491f97dd-- From nobody Wed Feb 22 06:53: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 149DB1299CA for ; Wed, 22 Feb 2017 06:52:58 -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, 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 0DP3_Lb104ul for ; Wed, 22 Feb 2017 06:52:56 -0800 (PST) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::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 160C91299D2 for ; Wed, 22 Feb 2017 06:52:56 -0800 (PST) Received: by mail-lf0-x236.google.com with SMTP id g134so2612479lfe.1 for ; Wed, 22 Feb 2017 06:52:55 -0800 (PST) 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=NMb4JurqZKkm7spYiuj6A5EOML0lK+526fif27TXmw0=; b=C5RXLY3xtG85XDaz9j6/nxcSun0pm2ompr6ZHUlw/Uz3TpNvQ8nKNlksWYuJnXrm/Y eztX413VUkLt40CkC7dEdAPDzX21SRtpgg5vNINfaWIT11N1wvFFXIWr1zJVrDoUpJJ4 kRgScaRnzmmXkoMSF2+iqi4B/dnyuI5KulqXk= 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=NMb4JurqZKkm7spYiuj6A5EOML0lK+526fif27TXmw0=; b=fCZQ7Z7Q8ivqmdCiyi+3knXEnQSpg974C3QjXn6fKYC/uVE3i+eya+DzSpIPNd7vji +2jap8kua6tsK1e2p51TeNzWvvsJEzsmyV7cC/bdvS7om1ql+/bZED+hJKTW0gCK15QG 3AXPPaWMGg5esvjcn7t/n0iTgitoR2rvhcoNcBYC6tcR9a64PhhWDn8mBFVSlwJSvArn 1Nj8No5Y/e6KuNIlRRdzzkT68ayIaOASJaz7PIfuoChoVY3CUNFQx4sRgruJPVtkOoF2 xTTyY7ED9VvPNif6KmnSA1kTYbvSicHWd7icL4LqiJBAancmDQwCK4PIRAqsLxR08dS/ XXUw== X-Gm-Message-State: AMke39mLd/vcn6vEscjpQ6xUrSi8WI6xGqF2sJhWt8bbnF94rAtN2993G4PV3LtXthitTq0AYQvbwxYC8+aQ3K9s X-Received: by 10.25.129.147 with SMTP id c141mr9185786lfd.93.1487775174351; Wed, 22 Feb 2017 06:52:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.162.72 with HTTP; Wed, 22 Feb 2017 06:52:53 -0800 (PST) In-Reply-To: <49151890-f140-71bd-3124-70aa2ffaf860@eff.org> References: <49151890-f140-71bd-3124-70aa2ffaf860@eff.org> From: Daniel McCarney Date: Wed, 22 Feb 2017 09:52:53 -0500 Message-ID: To: Jacob Hoffman-Andrews Content-Type: multipart/alternative; boundary=001a113eae76c5f2ed05491fa679 Archived-At: Cc: "acme@ietf.org" Subject: Re: [Acme] Removing public-key echo in account objects X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: cpu@letsencrypt.org List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 14:52:58 -0000 --001a113eae76c5f2ed05491fa679 Content-Type: text/plain; charset=UTF-8 I haven't been able to think of a reason to keep it since you posted. +1 to removing it. Anyone else waiting in the silence with an opinion? :-) On Sat, Feb 18, 2017 at 2:07 PM, Jacob Hoffman-Andrews wrote: > Right now, account objects echo back the public key associated with the > account, in the "key" field. However, this is redundant since the only > request types that can return an account object are signed by the > corresponding private key, so the client necessarily knows what its > public key is. Removing this simplifies the spec somewhat. > > https://github.com/ietf-wg-acme/acme/pull/266 > > Thoughts? > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > --001a113eae76c5f2ed05491fa679 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I haven't been able to think of a reason to keep it si= nce you posted.

+1 to removing it.

Anyone else waiting in the= silence with an opinion? :-)

On Sat, Feb 18, 2017 at 2:07 PM, Jacob Hoffman-Andrews <jsha@= eff.org> wrote:
Right now, = account objects echo back the public key associated with the
account, in the "key" field. However, this is redundant since the= only
request types that can return an account object are signed by the
corresponding private key, so the client necessarily knows what its
public key is. Removing this simplifies the spec somewhat.

https://github.com/ietf-wg-acme/acme/pull/266<= br>
Thoughts?

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

--001a113eae76c5f2ed05491fa679-- From nobody Wed Feb 22 06:57: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 B00341299DE for ; Wed, 22 Feb 2017 06:57:02 -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, 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 M8wiKoES9JVk for ; Wed, 22 Feb 2017 06:57:00 -0800 (PST) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B40561299D9 for ; Wed, 22 Feb 2017 06:57:00 -0800 (PST) Received: by mail-oi0-x22f.google.com with SMTP id 62so2679826oih.2 for ; Wed, 22 Feb 2017 06:57:00 -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=is4FLVT9772qUdwrWWDfQeWs/rhP9Mh186r/HqL+YoE=; b=ABQu5UGw0PMiO1UiH0FDrTHlEiphGoPK6SvMTbvGnLeGRMkpMjMotlzK6o+Wy/Y6F8 zfEWlLTgR0FnC/IDWj5cfxcnL/W07THsEjMAbF+Ej9zhPtaZR6w5V+w6iQW9EEdSveDm dK/Z1A+wj3D1/fLRvLAv/XJkN+LgHPewX46YeEI9ejxBSDCZNXmKGvWKuQrt2jtfXWda Mvqs7ePfiDICZNZreRvjeInpdIwaqc2KLBAELSrRolc1U+PW1VWcHeK1n3V3PJBPrycC D+9UPwR3Ov68y9GMd7oB5FS1spfw9nI37TxOTYRdIzJ1E8mitiN2Dvyxo5lIGXYDojuc e8Ug== 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=is4FLVT9772qUdwrWWDfQeWs/rhP9Mh186r/HqL+YoE=; b=kO+v/GZKO4iYfN+we0mVLrgCLL7l3iYyB0lgSgydEN9HyDbwPDF3t2bTlp3VZS2bOH JmQN74KI7J2FSUfr9mYfloXycKUKQWJuu1jH/B0iFy/nMTAXKFtvYgcJCrlF10vtC8aS agj69e8CbxFYSDoDRmFvvyObNnfFu720qkeYCKU7QPeO20WQ1iNclCV29xdXzwK8pzla zc9soQMN+oET6YqG0OQ1+gJingnIE2mQZUzYdcjwZqz7z9JnhYpt8HxB+TZEaxrK6lC6 69dtmKgxgWn/ZyJ4nGtgYkepJ/147mgTvD1MHP4LwRYBwZdKSmjGKufaY/EKYzVz21xw NVpQ== X-Gm-Message-State: AMke39kaDg/nMmynu4T3BAimUgDlSx+ezrhO7TeelaCwcd1AS24cxdYwl1Ba3h5M0IqPgJI+eyG8j1wNi6M4kQ== X-Received: by 10.202.83.132 with SMTP id h126mr8827603oib.136.1487775420103; Wed, 22 Feb 2017 06:57:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.5.169 with HTTP; Wed, 22 Feb 2017 06:56:59 -0800 (PST) Received: by 10.157.5.169 with HTTP; Wed, 22 Feb 2017 06:56:59 -0800 (PST) In-Reply-To: References: From: Josh Soref Date: Wed, 22 Feb 2017 09:56:59 -0500 Message-ID: To: cpu@letsencrypt.org Content-Type: multipart/alternative; boundary=001a113dd6ae6bc33b05491fb569 Archived-At: Cc: IETF ACME Subject: Re: [Acme] ambiguous server 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, 22 Feb 2017 14:57:03 -0000 --001a113dd6ae6bc33b05491fb569 Content-Type: text/plain; charset=UTF-8 I can't do this before tonight, and I'd want to cover the entire document, so if you could find a pinch hitter, I think that's best. On Feb 22, 2017 9:48 AM, "Daniel McCarney" wrote: > > I'm not certain, but in cases where acme spec is talking about the > > acme server acting as an http client, I'd request that `server` not be > > used bare. > > The easiest solution imo is labeling `acme-server` and > > `{http(s)}-server` / similar. But I'm open to other proposals. > > Agreed - I think this is a sensible change to reduce confusion. "ACME > server" > and "HTTP challenge server" seem like good choices but I'm also not tied to > anything. > > >> 3. Dereference the URI using an HTTP GET request. This request MUST be > sent > >> to TCP port 80 on the server. > >I think server here is http-server > > +1 > > >> 4. Verify that the body of the response is well-formed key > authorization. The > >> server SHOULD ignore whitespace characters at the end of the body. > > I think here server is acme-server > > +1 > > >> 5. Verify that key authorization provided by the server matches the > token for > this challenge and the client's account key. > > I think here server is acme-server > > I think this one should be "Verify that the key authorization provided by > the > HTTP challenge server", not the acme-server (or I need more coffee/cleaner > glasses). > > Are you going to send a PR for this? If you're tied up with your existing > PRs > I will find a pinch hitter. > > - cpu > > > On Tue, Feb 21, 2017 at 11:07 PM, Josh Soref wrote: > >> https://github.com/ietf-wg-acme/acme/blob/28295572ca191cd14d >> 6a9a21912b8d03aa65b885/draft-ietf-acme-acme.md#http >> >> > 3. Dereference the URI using an HTTP GET request. This request MUST be >> sent to TCP port 80 on the server. >> >> I think server here is http-server >> >> > 4. Verify that the body of the response is well-formed key >> authorization. The server SHOULD ignore whitespace characters at the end of >> the body. >> >> I think here server is acme-server >> >> > 5. Verify that key authorization provided by the server matches the >> token for this challenge and the client's account key. >> >> I think here server is acme-server >> >> >> I'm not certain, but in cases where acme spec is talking about the >> acme server acting as an http client, I'd request that `server` not be >> used bare. >> The easiest solution imo is labeling `acme-server` and >> `{http(s)}-server` / similar. But I'm open to other proposals. >> >> _______________________________________________ >> Acme mailing list >> Acme@ietf.org >> https://www.ietf.org/mailman/listinfo/acme >> > > --001a113dd6ae6bc33b05491fb569 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I can't do this before tonight, and I'd want to c= over the entire document, so if you could find a pinch hitter, I think that= 's best.=C2=A0

On Feb 22, 2017 9:48 AM, "Daniel McCarney" <cpu@letsencrypt.org> wrote:
> I'= ;m not certain, but in cases where acme spec is talking about the
> acme server acting as an http client, I'd request that `server` n= ot be
> used bare.
> The easiest solution imo is = labeling `acme-server` and
> `{http(s)}-server` / similar. But= I'm open to other proposals.

Agreed - I think= this is a sensible change to reduce confusion. "ACME server"
and "HTTP challenge server" seem like good choices but I&#= 39;m also not tied to
anything.

>> 3. Der= eference the URI using an HTTP GET request. This request MUST be sent
=
>> to TCP port 80 on the server.
>I think server he= re is http-server

+1

>= > 4. Verify that the body of the response is well-formed key authorizati= on. The
>> server SHOULD ignore whitespace characters at th= e end of the body.
> I think here server is acme-server
<= div>
+1

>> 5. Verify that key = authorization provided by the server matches the token for
this c= hallenge and the client's account key.
> I think here serv= er is acme-server

I think this one should be "= ;Verify that the key authorization provided by the
HTTP challenge= server", not the acme-server (or I need more coffee/cleaner
glasses).

Are you going to send a PR for this? If= you're tied up with your existing PRs
I will find a pinch hi= tter.

- cpu


On Tue, Feb 21, 2017 at 11:= 07 PM, Josh Soref <jsoref@gmail.com> wrote:
https://github.com/ietf-wg-acme/acme/blob/= 28295572ca191cd14d6a9a21912b8d03aa65b885/draft-ietf-acme-acme.md#= http

> 3. Dereference the URI using an HTTP GET request. This request MUST be= sent to TCP port 80 on the server.

I think server here is http-server

> 4. Verify that the body of the response is well-formed key authorizati= on. The server SHOULD ignore whitespace characters at the end of the body.<= br>
I think here server is acme-server

> 5. Verify that key authorization provided by the server matches the to= ken for this challenge and the client's account key.

I think here server is acme-server


I'm not certain, but in cases where acme spec is talking about the
acme server acting as an http client, I'd request that `server` not be<= br> used bare.
The easiest solution imo is labeling `acme-server` and
`{http(s)}-server` / similar. But I'm open to other proposals.

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

--001a113dd6ae6bc33b05491fb569-- From nobody Wed Feb 22 13:13: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 BE197129B63 for ; Wed, 22 Feb 2017 13:13:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.69 X-Spam-Level: X-Spam-Status: No, score=-2.69 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, T_KAM_HTML_FONT_INVALID=0.01] 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 t2VycNo45INA for ; Wed, 22 Feb 2017 13:13:00 -0800 (PST) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::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 4017E129B62 for ; Wed, 22 Feb 2017 13:13:00 -0800 (PST) Received: by mail-lf0-x232.google.com with SMTP id g134so7772100lfe.1 for ; Wed, 22 Feb 2017 13:13:00 -0800 (PST) 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=QZMd8KqsCxytaw+TyrMFzKDF7EPbsOQwivr6fZLO+5Q=; b=LTL11K7m/mfLD4XlQ8rgoNKhxVMwOzIIK9i/9WE3njxX/XijhCbLo4dm1f2efBs0Ec guT+nezHgf5pLhBAt0pJGbK4lSAHxFSOYyd8F2pjctJtbTrzdVEwyqHQgcWGR9ODYlOu giFn9sCHN83psO+GRQQctXjDFoLAsB4MO5sW8= 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=QZMd8KqsCxytaw+TyrMFzKDF7EPbsOQwivr6fZLO+5Q=; b=RNcrOoDvdkxm6YHsMHZhFb2AP9+EvA+UQyAlR7mMX0l4aFZt1qGzaNWAMCHbGVVr3P CnsVZnW4pM9Cg3KU5QXPGlei7TXUZJpreFC68XLT0hMuxmKL+v11ziaJmYP2EQELE5yL +sUCJbJIki/2VY1w7IdbtZoRua3flQcsT2ZYyHfD9Lt0MORx4pVawX/Gjg2aTwhntNuN PmneNgjb1nWtWsdLmJF3wq8hGl5z20Cwc5xhoU7EHZD21RGMHCCVJke/DKOG3i906uQO zep7l57MbVrXylDvU166383mtRyYDYiqG4oMihc/xrZAWmt77qEfYGvOk6tjBxgadPSg v5sQ== X-Gm-Message-State: AMke39mkvxd0038IZmd5JDMNkHNZXJ2TZCB6pQt5R0/963nNPeCCOfh6STXxPK9OwLgAl5IGiDqRfeOzNX7uK1px X-Received: by 10.46.32.19 with SMTP id g19mr8147048ljg.50.1487797978416; Wed, 22 Feb 2017 13:12:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.162.72 with HTTP; Wed, 22 Feb 2017 13:12:57 -0800 (PST) In-Reply-To: References: From: Daniel McCarney Date: Wed, 22 Feb 2017 16:12:57 -0500 Message-ID: To: Josh Soref Content-Type: multipart/alternative; boundary=001a1142b4ae005bb9054924f689 Archived-At: Cc: IETF ACME Subject: Re: [Acme] ambiguous server in acme X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: cpu@letsencrypt.org List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 21:13:03 -0000 --001a1142b4ae005bb9054924f689 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable https://github.com/ietf-wg-acme/acme/pull/268 =F0=9F=8F=86=E2=9A=BE On Wed, Feb 22, 2017 at 9:56 AM, Josh Soref wrote: > I can't do this before tonight, and I'd want to cover the entire document= , > so if you could find a pinch hitter, I think that's best. > > On Feb 22, 2017 9:48 AM, "Daniel McCarney" wrote: > >> > I'm not certain, but in cases where acme spec is talking about the >> > acme server acting as an http client, I'd request that `server` not be >> > used bare. >> > The easiest solution imo is labeling `acme-server` and >> > `{http(s)}-server` / similar. But I'm open to other proposals. >> >> Agreed - I think this is a sensible change to reduce confusion. "ACME >> server" >> and "HTTP challenge server" seem like good choices but I'm also not tied >> to >> anything. >> >> >> 3. Dereference the URI using an HTTP GET request. This request MUST b= e >> sent >> >> to TCP port 80 on the server. >> >I think server here is http-server >> >> +1 >> >> >> 4. Verify that the body of the response is well-formed key >> authorization. The >> >> server SHOULD ignore whitespace characters at the end of the body. >> > I think here server is acme-server >> >> +1 >> >> >> 5. Verify that key authorization provided by the server matches the >> token for >> this challenge and the client's account key. >> > I think here server is acme-server >> >> I think this one should be "Verify that the key authorization provided b= y >> the >> HTTP challenge server", not the acme-server (or I need more coffee/clean= er >> glasses). >> >> Are you going to send a PR for this? If you're tied up with your existin= g >> PRs >> I will find a pinch hitter. >> >> - cpu >> >> >> On Tue, Feb 21, 2017 at 11:07 PM, Josh Soref wrote: >> >>> https://github.com/ietf-wg-acme/acme/blob/28295572ca191cd14d >>> 6a9a21912b8d03aa65b885/draft-ietf-acme-acme.md#http >>> >>> > 3. Dereference the URI using an HTTP GET request. This request MUST b= e >>> sent to TCP port 80 on the server. >>> >>> I think server here is http-server >>> >>> > 4. Verify that the body of the response is well-formed key >>> authorization. The server SHOULD ignore whitespace characters at the en= d of >>> the body. >>> >>> I think here server is acme-server >>> >>> > 5. Verify that key authorization provided by the server matches the >>> token for this challenge and the client's account key. >>> >>> I think here server is acme-server >>> >>> >>> I'm not certain, but in cases where acme spec is talking about the >>> acme server acting as an http client, I'd request that `server` not be >>> used bare. >>> The easiest solution imo is labeling `acme-server` and >>> `{http(s)}-server` / similar. But I'm open to other proposals. >>> >>> _______________________________________________ >>> Acme mailing list >>> Acme@ietf.org >>> https://www.ietf.org/mailman/listinfo/acme >>> >> >> --001a1142b4ae005bb9054924f689 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wed, Feb 22, 2017 at 9:56 AM, Josh Soref = <jsoref@gmail.com<= /a>> wrote:
I= can't do this before tonight, and I'd want to cover the entire doc= ument, so if you could find a pinch hitter, I think that's best.=C2=A0<= /div>
On Feb 22, 2017 9:48 AM, "Daniel McCarney&= quot; <cpu@lets= encrypt.org> wrote:
> I'm not certain, but in cases where a= cme spec is talking about the
> acme server acting as an http = client, I'd request that `server` not be
> used bare.
> The easiest solution imo is labeling `acme-server` and
> `{http(s)}-server` / similar. But I'm open to other proposals.

Agreed - I think this is a sensible change to reduce= confusion. "ACME server"
and "HTTP challenge serv= er" seem like good choices but I'm also not tied to
anything.

>> 3. Dereference the URI using an HTTP GET r= equest. This request MUST be sent
>> to TCP port 80 on the = server.
>I think server here is http-server

+1

>> 4. Verify that the body of the = response is well-formed key authorization. The
>> server SH= OULD ignore whitespace characters at the end of the body.
> I = think here server is acme-server

+1

=
>> 5. Verify that key authorization provided by the server= matches the token for
this challenge and the client's accoun= t key.
> I think here server is acme-server

I think this one should be "Verify that the key authorization p= rovided by the
HTTP challenge server", not the acme-server (= or I need more coffee/cleaner
glasses).

= Are you going to send a PR for this? If you're tied up with your existi= ng PRs
I will find a pinch hitter.

- cpu=


On Tue, Feb 21, 2017 at 11:07 PM, Josh Soref &l= t;jsoref@gmail.com> wrote:
https://gi= thub.com/ietf-wg-acme/acme/blob/28295572ca191cd14d6a9a21912b8d03a= a65b885/draft-ietf-acme-acme.md#http

> 3. Dereference the URI using an HTTP GET request. This request MUST be= sent to TCP port 80 on the server.

I think server here is http-server

> 4. Verify that the body of the response is well-formed key authorizati= on. The server SHOULD ignore whitespace characters at the end of the body.<= br>
I think here server is acme-server

> 5. Verify that key authorization provided by the server matches the to= ken for this challenge and the client's account key.

I think here server is acme-server


I'm not certain, but in cases where acme spec is talking about the
acme server acting as an http client, I'd request that `server` not be<= br> used bare.
The easiest solution imo is labeling `acme-server` and
`{http(s)}-server` / similar. But I'm open to other proposals.

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


--001a1142b4ae005bb9054924f689-- From nobody Thu Feb 23 13:58: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 B5581129B32 for ; Thu, 23 Feb 2017 13:58:25 -0800 (PST) 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 B-7QNkTEjy2B for ; Thu, 23 Feb 2017 13:58:24 -0800 (PST) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id D299212940A for ; Thu, 23 Feb 2017 13:58:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 54BF71B5F1 for ; Thu, 23 Feb 2017 23:58:22 +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 RO_ewcQPkVhi for ; Thu, 23 Feb 2017 23:58:22 +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 1263F2318 for ; Thu, 23 Feb 2017 23:58:22 +0200 (EET) Date: Thu, 23 Feb 2017 23:58:17 +0200 From: Ilari Liusvaara To: acme@ietf.org Message-ID: <20170223215817.GA9482@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: [Acme] Q on default-vhost attacks and TLS-SNI-02 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: Thu, 23 Feb 2017 21:58:25 -0000 As you might recall, back in Sepember 2015, default-vhost attack was found against DNSVI validation method. This attack required implicit default vhost together with capability to upload certificates. It looked like TLS-SNI-01 worked around this by adding iterations and requiring provisioning multiple certificates. But TLS-SNI-02 doesn't contain anything similar, and it would seem like it would be vulernable if attacker controns the default vhost certificate. Was it decided that no host is bad enough to allow both the implicit-default-vhost and uploading own certificates without checking? One checking workaround would be to send a request for made-up challenge, check that it results either unrecognized_name alert or certificate that doesn't solve the original challenge and then check the original challenge again. Note that some systems might generate the certificates in the fly, so the two requests for the real challenge might not give the same certificate (even if bulk answering is not possible in TLS-SNI-02). -Ilari From nobody Fri Feb 24 19:20: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 94AB812985D for ; Fri, 24 Feb 2017 19:20:42 -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, 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 761KVbkiUYU4 for ; Fri, 24 Feb 2017 19:20:40 -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 C84811297EB for ; Fri, 24 Feb 2017 19:20:40 -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=y2Iv9knn2jHAG1Zl2EtBZpY85Iz6Yyo4icaam4Tigjc=; b=PMQKC/dMzYey+VCojUk9hPq6HwTURaJiyJ2xFNQp+LcemGdmP/wyuSgheiJxZz+Vo7jkZut/dcN+W6Pa9T9f5fHyhqt3t4HF4WtPLrqGQuPqBYU1YXMltZj6XYsZ6Rf4IIbdmJirkyCNEnQoobGqX3SvKaIe93G9MjcQA1xMUdU=; Received: ; Fri, 24 Feb 2017 19:20:42 -0800 To: Hugo Landau References: <807854cf-a388-4729-e292-5daac236d82a@eff.org> <20170220025438.GA10979@andover.lhh.devever.net> From: Jacob Hoffman-Andrews Message-ID: <7f0a3230-1278-4d21-e4bd-dd416d80d93b@eff.org> Date: Fri, 24 Feb 2017 19:20:38 -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: <20170220025438.GA10979@andover.lhh.devever.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: acme@ietf.org Subject: Re: [Acme] Split up errors and add an error field to orders 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, 25 Feb 2017 03:20:42 -0000 On 02/19/2017 06:54 PM, Hugo Landau wrote: > If a server processes different things in parallel, multiple errors > could occur. Should the "error" field be an array? Reading the Problem Document spec, it seems like the expected way to handle multiple errors is with fields within the problem document, rather than multiple problem documents. The way Boulder has handled this has been to pick the error that matters most. For instance, if there was a validation failure and a CAA failure, report the validation failure, because when both fail it's usually because of a DNS problem. However, it would also be entirely possible to represent multiple errors in plain text. > Moreover, is there any utility in mandating that this "error" field only > be used after (all?) authorizations have been completed? That meshes > with the implementation model this list is expecting, but it seems > simpler from a client implmentation perspective simply for the client to > balk whenever it retrieves an order object which has an error set on it. > This maximizes the flexibility of implementation on the server side. Yep, good point. Now it's just: error (optional, object): : The error that occurred while processing the order, if any. This field is structured as a problem document {{!RFC7807}}.