From nobody Sun Apr 2 05:03: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 C92FA1286CA for ; Sun, 2 Apr 2017 05:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 XaD1JrBMxdaM for ; Sun, 2 Apr 2017 05:03:41 -0700 (PDT) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::6]) (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 73F7E1287A7 for ; Sun, 2 Apr 2017 05:03:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1491134619; l=1490; s=domk; d=kelunik.com; h=Content-Type:Cc:To:Subject:Date:From:References:In-Reply-To: MIME-Version; bh=35Ja0usINBh75c173KwmZ2V0KPnS9ZBXGKIIaCX4FaQ=; b=xmzJE945v1mqPExNkgl8mUqMAXCBeGIKlniiCp/7wdA82M+nGfYIPvDs9twZik7eR4 qGZNmW8NyQQlG986aAPaTnVugL9sh7WeGl3BpQy5bNpbyGEuvCVBXe/nh50QbqeOg9Oj we4kjAsjCz7pwPOg4M0x9ZLyxWvEv9cSKuTYI= X-RZG-AUTH: :IWkkfkWkbvHsXQGmRYmUo9mls2vWuiu+7SLDup6E67mzuoBPBqD/sWo= X-RZG-CLASS-ID: mo00 Received: by mail-qk0-f171.google.com with SMTP id d201so66500615qkc.0 for ; Sun, 02 Apr 2017 05:03:38 -0700 (PDT) X-Gm-Message-State: AFeK/H1tJZJmNj2DeRaV48mAdPPH0OwC4F+xBdcn5Nf2ph78iUGMpdpyEYezZ20WiLF5yf3hm8vLyAnmBE1cRQ== X-Received: by 10.233.222.6 with SMTP id s6mr11869754qkf.231.1491134618253; Sun, 02 Apr 2017 05:03:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.144.167 with HTTP; Sun, 2 Apr 2017 05:03:37 -0700 (PDT) In-Reply-To: References: From: Niklas Keller Date: Sun, 2 Apr 2017 14:03:37 +0200 X-Gmail-Original-Message-ID: Message-ID: To: "Salz, Rich" Cc: Sean Leonard , ACME WG Content-Type: multipart/alternative; boundary=94eb2c04316a3bc7c1054c2dd596 Archived-At: Subject: Re: [Acme] "Slide 21" follow-up (textual encoding question) PART 2 X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2017 12:03:44 -0000 --94eb2c04316a3bc7c1054c2dd596 Content-Type: text/plain; charset=UTF-8 > > Sean, > > The working group felt pretty clearly that the BEGIN/END base64 encoding > was the format used by "all" web servers and that anything else would > require the client to translate into that format. > That's true, but using a format that can just be dumped without inspection makes these private key injection attacks easier. I'm all for simple clients, but that ends where simplicity means not checking inputs and outputs. Regards, Niklas --94eb2c04316a3bc7c1054c2dd596 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sean,

The working group felt pretty clearly that the BEGIN/END base64 encoding wa= s the format used by "all" web servers and that anything else wou= ld require the client to translate into that format.
<= br>
That's true, but using a format that can just be dumped w= ithout inspection makes these private key injection attacks easier.

I'm all for simple clients, but that ends where simpl= icity means not checking inputs and outputs.

Regar= ds, Niklas=C2=A0
--94eb2c04316a3bc7c1054c2dd596-- From nobody Sun Apr 2 08:59:32 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B744128656 for ; Sun, 2 Apr 2017 08:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGxD7mLXAN71 for ; Sun, 2 Apr 2017 08:59:28 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C826C127B5A for ; Sun, 2 Apr 2017 08:59:28 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id p77so54653373ywg.1 for ; Sun, 02 Apr 2017 08:59:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=FFikJEKkep/O1Nn7PYZFSAkC4ReliffIJk5buWfnD1Y=; b=ENLq8neLObL1Ppemk1WuGNaP86KMTUKYmdyrNtmGSwJKUxZJ19nqxIJujoS98DwwrB +HnG+X8KJ7BxSRdH0ti+/igAOGHYaVHZaYNRoqJURssfJva1aPXycP2gORRt0o2uFZw4 rxSwvekaOdwlP4En/ZPdP3BMA8uq+bXkbJTvIIfGuDN4ciaKkQ55B/5ZCPsgWz73TDxB JOjK/+rbZOiDX2bJZCZoFYkL9NG/gGButqJeNJ3Upk9RA5navrnTyd/AHK/C1W9Q+FwK FngtGz09EAyxiTe4xfE/piGoRrO303PxZgjT2ZAJkrZf2nhXHtJ+bxBo8v0zCgrAFjwG 3NWQ== 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=FFikJEKkep/O1Nn7PYZFSAkC4ReliffIJk5buWfnD1Y=; b=Q8EzHAhKdXdm8OHba0t3kZZtil4ycPOsmctkx6qDDeiI0xsV8lDihZUiLy8yepm0fK FLnX7y86t8ao6XnFtlYeK9HpPI6YDhyLlcjX0Xz6NhoSBTNSkRgaPOTADP8Y6uo/ZjYm y7KrQXkDWd5XS3q+/DCxFNvx5LeRoc+jLqNEJVZhkatIdjElxrP5ltDSTKxms/0tC22U UCie12MX2iBMj5yPFDEwVGC1PqhamCYdmkg436q/YzMc50qhcif6FNJyWbmShzPZQcOX OgtbCMcVSiXCwZ3XA09WpGhRLWXvYlzIbNXSju2wGI7UnE1wexFlRgWCciwp0zTKnmGb d6tA== X-Gm-Message-State: AFeK/H0O+eFyA0jt30kkDSBeRsnwzOuCH9f/71eJ5QFeSS6xhaz0LPxmPOClmeV8ALeDKw== X-Received: by 10.129.101.7 with SMTP id z7mr10866578ywb.45.1491148768008; Sun, 02 Apr 2017 08:59:28 -0700 (PDT) Received: from [172.18.133.122] (cowboy3.intuit.com. [65.204.229.13]) by smtp.gmail.com with ESMTPSA id d80sm5094183ywh.75.2017.04.02.08.59.26 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 02 Apr 2017 08:59:27 -0700 (PDT) To: acme@ietf.org References: From: Yaron Sheffer Message-ID: Date: Sun, 2 Apr 2017 18:59:23 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1255; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Acme] FW: [ietf-wg-acme/acme] Add CAA text (per IETF98) (#290) X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2017 15:59:30 -0000 > > Fulfilling my promise made the other day ? A PR to address the CAA issue. > Rich's new text reads as follows: "Further, an ACME-based CA can use the Certification Authority Authorization record {{!RFC6844}} to prevent it from being misdirected and generate an unauthorized issuance." IMHO we need a "SHOULD" here. If you're an ACME server, there's no reason to ignore CAA records. Especially since we are looking into adding ACME-specific information into these records, in draft-ietf-acme-caa-01. Thanks, Yaron From nobody Sun Apr 2 09:09:11 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B68512940D for ; Sun, 2 Apr 2017 09:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xW-3Zi9Z8JMl for ; Sun, 2 Apr 2017 09:09:07 -0700 (PDT) Received: from mail-yb0-x236.google.com (mail-yb0-x236.google.com [IPv6:2607:f8b0:4002:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AE22129353 for ; Sun, 2 Apr 2017 09:09:07 -0700 (PDT) Received: by mail-yb0-x236.google.com with SMTP id i124so24886536ybc.3 for ; Sun, 02 Apr 2017 09:09:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=mtdfMh+uxcsZvVFyoJXxjPLMcxnrUO/Ycks8zZiSvVs=; b=khraklH1K0q23tZZju3YhdZ6NQoYFT9byBRCppEH4xXuh3+eNWTiRsoCHxtOeJ/E3h d1lG4QmFYF/YMsEz13RoQJnlIDXcfwMTVvB//7qC6JACYF2O9pxZqNpIir0cS9e+tr0j EoJGontcZLwN/ORdf/UCvDph3mQooTtrO/v2YddoygkMYrl7baxeNGPpMP4ClqZdk0HJ IwXq3SC+JTi/JCxanRjI0axDGfhpP3bKqbizBWeJ5rSGLjxgiqZsnndIulsScmO5k+AQ C+1KWjUtTmOoycXo1X5g3kyRoixdjkp3K23UUiPQg+8p+0UjML3btnSLSCiycLYniujQ 8OJw== 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=mtdfMh+uxcsZvVFyoJXxjPLMcxnrUO/Ycks8zZiSvVs=; b=N2PTBTGazS+k68pUrvtIBn/J3RKGVlmHLiMA9PrQtPEuAH9etjizoCWaQEQ5hSJOt8 BmsWFHq/0ull2NpKkE85vZImFU9OPqjCzofXl7h06FbIGoY+b5wR0gR06fSdZ0A2wWCC cv7gzWvVFvhE0VoMmVMmO65AU8g1rA2Mcy3yB++zi3oK+aYqy7axLaFi9xcsTDb+Dksc p1jlLqPY+VyCL0ZKs+xbYT3yGVb0aRE8GG5jahA4XPQ4tWJpGkDf0FfdA3tYdw1jF6l0 naPyIJ++i92LXCe1XEmg7q3KipfTOTqx+B6TcMnNw5wB/L8T06sVaCeI6N2B6YfLSMBq FP4Q== X-Gm-Message-State: AFeK/H1M7azBfXaiOIkduefC1clb6j4i2MLR1j6lWo+dHn5l1pbrPWx2pje2BFa4hLVG9A== X-Received: by 10.37.174.96 with SMTP id g32mr9532210ybe.124.1491149346403; Sun, 02 Apr 2017 09:09:06 -0700 (PDT) Received: from [172.18.133.122] (cowboy3.intuit.com. [65.204.229.13]) by smtp.gmail.com with ESMTPSA id f138sm5130085ywb.66.2017.04.02.09.09.05 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 02 Apr 2017 09:09:06 -0700 (PDT) To: acme@ietf.org References: From: Yaron Sheffer Message-ID: <5fe4a546-4d36-f64c-2da7-88e22f5b68bc@gmail.com> Date: Sun, 2 Apr 2017 19:09:03 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1255; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Acme] draft-sheffer-acme-star-lurk: key lifetime ? X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2017 16:09:10 -0000 > Date: Fri, 31 Mar 2017 09:07:14 +0300 > From: Ilari Liusvaara > To: "Dr. Pala" > Cc: acme@ietf.org > Subject: Re: [Acme] draft-shaffer-acme-star-lurk: key lifetime ? > Message-ID: > <20170331060714.GA26933@LK-Perkele-V2.elisa-laajakaista.fi> > Content-Type: text/plain; charset=utf-8 > > On Thu, Mar 30, 2017 at 03:36:30PM -0500, Dr. Pala wrote: >> Hi Ilari, all, >> >> I strongly disagree with your statement. From a crypto standpoint, key >> rotation IS an important point and should be addressed. I think something >> could/should be added to the I-D to limit the number of renewal or the >> period where the same CSR can be used for certificate re-issuing. >> >> The solution might be as simple as set a validity in the CSR that is >> generated (if you want that to be in control of the requesting client). I am >> not suggesting the specifics of how to solve it, but I think that this is a >> point that should be addressed (possibly something that was in the mind of >> the original authors, but did not make it in the document... ?). > > I just read the draft. A facility to limit the private key period, > assuming you want to do that, already exists. > > And there are a number of sane-looking metrics[1], where any timed key > rotation strictly[2] decreases security. > > > [1] Basically, anything that considers security issue duration. > > [2] Meaning you get '<' operator in comparision, not '<='. > > > -Ilari The draft is not very clear on this, but the intent is to limit the duration of each delegated certificate, as well as the duration of delegation as a whole. Once delegation is over, a new CSR needs to be generated. However if the client wants to use the same private key forever, the CA will not stop it from doing that. And as far as I know, neither does a CA today. Thanks, Yaron From nobody Sun Apr 2 13:06: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 302C91292C5 for ; Sun, 2 Apr 2017 13:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Jz9Sor48VZL for ; Sun, 2 Apr 2017 13:06:23 -0700 (PDT) Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD07B126FB3 for ; Sun, 2 Apr 2017 13:06:22 -0700 (PDT) Received: by mail-wr0-x22e.google.com with SMTP id w11so141625935wrc.3 for ; Sun, 02 Apr 2017 13:06:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qeCTWgn28h/TWmyJbZ3mc/v6E3kxSR1aKmQCNGFaFgY=; b=I+arvdgp6c+nCUTlBGkAO0T3q1PerSTdYOgx/+//KHUpIrIIQ3pfDxqg2ZcTt3fsiz tLtF904qnDh2+kz6g5cSN0snOmJ9uSb9NGrP10PnhnLV2qcGadXWVCER3d9KmpVdI8rr GT0/WVHyWbbec4igcbis389cMGd8He85Hh1hnRSzvuR7uGYoDERkVq3nV9OGDrtkPxZJ ik2a1/+x1lTF5dVlinU8OjNTb62UjRMEsSkIv/s7efUttEaRpDKwpNnR6prDFbvh+Q+3 /x19PoJOCwXxiizUMIFjnnMWBKN2DghEi0/atVhYUxLutq7yeK5YPWTCQwytpSBMWu4S sjSg== 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=qeCTWgn28h/TWmyJbZ3mc/v6E3kxSR1aKmQCNGFaFgY=; b=AaYu16guap0cTVn5/g31kf/FxscpHgguzwLALYQswFGIZlYDGW6UoH9EMRzNWplVY8 PRevhGXttkgFdfKR1tZ1xvsmpF4o6DxK8lm+j0hiiMR3wboSA+MJ1y2iUswwGdeoKSUK i6Pv9PZsMe41/xXCBF81b1JMh/J7LoPx+0kFzBYii/ZWuU+MNJgGNMKwmrFNff5V3JAV hCm/6mEtuXP8eGINJEiYiVZNm1bZ4usRV7029eQSVa/K4DTIH4w3lywifuLCvIDklN4s itPFUbwXjnJAFjFoxNrTE+16emWG0RFsYKV3toQiaBTQ5lhUT6QL5CsrMN1bBjaHNjJh GNNA== X-Gm-Message-State: AFeK/H0VmgGl7/bCdadRY3estswMV9GCb/Jusk6OZlCZ9QmbxksGxlMyY+NGoUN9eiu0/ouU9mtlkRIJWY9PQQ== X-Received: by 10.223.138.200 with SMTP id z8mr13176120wrz.49.1491163580992; Sun, 02 Apr 2017 13:06:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.40.65 with HTTP; Sun, 2 Apr 2017 13:06:20 -0700 (PDT) In-Reply-To: References: From: Richard Barnes Date: Sun, 2 Apr 2017 15:06:20 -0500 Message-ID: To: Sean Leonard Cc: ACME WG Content-Type: multipart/alternative; boundary=001a113c49488c2276054c3493f1 Archived-At: Subject: Re: [Acme] "Slide 21" follow-up (textual encoding question) PART 2 X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2017 20:06:25 -0000 --001a113c49488c2276054c3493f1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Mar 31, 2017 at 5:23 PM, Sean Leonard wrote: > Hi ACME: > > SECOND PART. > > I think some of my comments may have been misconstrued about the =E2=80= =9C**Don't > call it PEM certificate chain** (slide 21)=E2=80=9D issue. > > Textual encoding amounts to a way to ASCII-armor binary data in plain > text. This is obvious because the human usability that it enables is: > =E2=80=9Ccopy-and-paste from your web browser or e-mail client into a tex= t file=E2=80=9D. > And the problem with human usability is that when you tell people to copy > and paste things, they don=E2=80=99t know or they ignore *what* they are = copying > and pasting, so they can facilitate transmitting malicious content across > security boundaries. > > Human interaction is not a design goal in ACME. You want humans to touch > this stuff as little as possible. By letting software =E2=80=9Ccopy and p= aste=E2=80=9D the > ACME server=E2=80=99s response to anything, *without validating it*, you = facilitate > attacks such as the private key substitution attack. (There are others, f= or > example, OpenSSL behaves differently when you supply it with -----TRUSTED > CERTIFICATE-----.) > You're confusing parsing with validation. Yes, if we provide things in some non-de-facto-standard format, then clients will have to reformat things. That introduces some likelihood that the reformatting will break on invalid inputs, but it's far from guaranteed. That said, the idea of "inlining" the certificate / chain doesn't seem completely awful. On the one hand, it would save an HTTP round-trip in the common case, and we don't have anything else in the protocol that relies on a certificate being referenced indepenedently from the order that created it. On the other hand, it seems like there could be some utility in the future to being able to refer to the certificate per se, vs. the order that created it. I could go either way. If we do inline the certificate into the order, ISTM the natural thing to do would be to just present it in base64url-encoded form: { // existing order fields "certificate": "[[ base64url data ]]", "chain": ["[[ base64url data ]]", ...] } Then it would just be a syntactic transformation to whatever an HTTP server accepts. --Richard > > If the WG=E2=80=99s consensus is that you really want a separate certific= ate URI > (seriously: why? you want it retrievable over ldap:// or ni:// or > something?), then the URI dereference should return *just* certificates i= n > a well-defined way. Blobs of text (regardless of what MIME type you serve > it as) are not well-defined compared to the gold standard of > application/pkix-cert. If your goal really is so that a human being can > take the certificate URI and put it in their web browser and copy and pas= te > the certificate, then it should be served as text/plain; charset=3Dus-asc= ii. > Or if you want, text/html and include some dancing hamsters and last-minu= te > unilateral changes to the CA contract (because hunting-and-picking for > -----BEGIN CERTIFICATE----- in HTML source works exactly the same way, it= =E2=80=99s > called =E2=80=9Cpage scraping=E2=80=9D). But I thought that the point of = ACME is to get > away from page scraping techniques. > > Anyway, if you want a format at a separate URI that includes the > certificate and the ACME server=E2=80=99s proposed chain and is automatab= le, my > first suggestion is multipart/mixed where each part is > application/pkix-cert. Most web browsers don't handle multipart/mixed > responses well, but the point is that you=E2=80=99re not supposed to use = a web > browser to get this URI. > > My second suggestion is (what I wrote initially): a new binary type, > application/pkix-certs (or cert-chain), with concatenated DER-encoded > certificates: the first one is the subject certificate you=E2=80=99re int= erested in > and the others =E2=80=9CSHOULD=E2=80=9D be in TLS order. > > Thanks, > > Sean > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > --001a113c49488c2276054c3493f1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Mar 31, 2017 at 5:23 PM, Sean Leonard <dev+ietf@seantek.com= > wrote:
Hi ACME:

SECOND PART.

I think some of my comments may have been misconstrued about the =E2=80=9C*= *Don't call it PEM certificate chain** (slide 21)=E2=80=9D issue.

Textual encoding amounts to a way to ASCII-armor binary data in plain text.= This is obvious because the human usability that it enables is: =E2=80=9Cc= opy-and-paste from your web browser or e-mail client into a text file=E2=80= =9D. And the problem with human usability is that when you tell people to c= opy and paste things, they don=E2=80=99t know or they ignore *what* they ar= e copying and pasting, so they can facilitate transmitting malicious conten= t across security boundaries.

Human interaction is not a design goal in ACME. You want humans to touch th= is stuff as little as possible. By letting software =E2=80=9Ccopy and paste= =E2=80=9D the ACME server=E2=80=99s response to anything, *without validati= ng it*, you facilitate attacks such as the private key substitution attack.= (There are others, for example, OpenSSL behaves differently when you suppl= y it with -----TRUSTED CERTIFICATE-----.)

You're confusing parsing with validation.=C2=A0 Yes, if we provide t= hings in some non-de-facto-standard format, then clients will have to refor= mat things.=C2=A0 That introduces some likelihood that the reformatting wil= l break on invalid inputs, but it's far from guaranteed.
=
That said, the idea of "inlining" the certificate = / chain doesn't seem completely awful.=C2=A0 On the one hand, it would = save an HTTP round-trip in the common case, and we don't have anything = else in the protocol that relies on a certificate being referenced indepene= dently from the order that created it.=C2=A0 On the other hand, it seems li= ke there could be some utility in the future to being able to refer to the = certificate per se, vs. the order that created it.=C2=A0 I could go either = way.

If we do inline the certificate into the orde= r, ISTM the natural thing to do would be to just present it in base64url-en= coded form:

{
=C2=A0 // existing order f= ields
=C2=A0 "certificate": "[[ base64url data ]]&= quot;,
=C2=A0 "chain": ["[[ base64url data ]]"= ;, ...]
}

Then it would just be a syntac= tic transformation to whatever an HTTP server accepts.

=
--Richard

=C2=A0

If the WG=E2=80=99s consensus is that you really want a separate certificat= e URI (seriously: why? you want it retrievable over ldap:// or ni:// or som= ething?), then the URI dereference should return *just* certificates in a w= ell-defined way. Blobs of text (regardless of what MIME type you serve it a= s) are not well-defined compared to the gold standard of application/pkix-c= ert. If your goal really is so that a human being can take the certificate = URI and put it in their web browser and copy and paste the certificate, the= n it should be served as text/plain; charset=3Dus-ascii. Or if you want, te= xt/html and include some dancing hamsters and last-minute unilateral change= s to the CA contract (because hunting-and-picking for -----BEGIN CERTIFICAT= E----- in HTML source works exactly the same way, it=E2=80=99s called =E2= =80=9Cpage scraping=E2=80=9D). But I thought that the point of ACME is to g= et away from page scraping techniques.

Anyway, if you want a format at a separate URI that includes the certificat= e and the ACME server=E2=80=99s proposed chain and is automatable, my first= suggestion is multipart/mixed where each part is application/pkix-cert. Mo= st web browsers don't handle multipart/mixed responses well, but the po= int is that you=E2=80=99re not supposed to use a web browser to get this UR= I.

My second suggestion is (what I wrote initially): a new binary type, applic= ation/pkix-certs (or cert-chain), with concatenated DER-encoded certificate= s: the first one is the subject certificate you=E2=80=99re interested in an= d the others =E2=80=9CSHOULD=E2=80=9D be in TLS order.

Thanks,

Sean

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

--001a113c49488c2276054c3493f1-- From nobody Mon Apr 3 02:00: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 0391E128954 for ; Mon, 3 Apr 2017 02:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKoch1QhcF_m for ; Mon, 3 Apr 2017 02:00:45 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A52861295E3 for ; Mon, 3 Apr 2017 02:00:45 -0700 (PDT) Received: from [192.168.123.7] (unknown [76.90.60.238]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 9B54322E25C; Mon, 3 Apr 2017 05:00:26 -0400 (EDT) To: Richard Barnes References: Cc: ACME WG From: Sean Leonard Message-ID: <083b73a4-a199-dc57-e078-bf1bf9c10bd2@seantek.com> Date: Mon, 3 Apr 2017 02:00:20 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------0EC051EDA6FE534E6BA80FFE" Archived-At: Subject: Re: [Acme] "Slide 21" follow-up (textual encoding question) PART 2 X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 09:00:48 -0000 This is a multi-part message in MIME format. --------------0EC051EDA6FE534E6BA80FFE Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 4/2/2017 1:06 PM, Richard Barnes wrote: > > > On Fri, Mar 31, 2017 at 5:23 PM, Sean Leonard > wrote: > > Hi ACME: > > SECOND PART. > [...] > > That said, the idea of "inlining" the certificate / chain doesn't seem = > completely awful. On the one hand, it would save an HTTP round-trip=20 > in the common case, and we don't have anything else in the protocol=20 > that relies on a certificate being referenced indepenedently from the=20 > order that created it. On the other hand, it seems like there could=20 > be some utility in the future to being able to refer to the=20 > certificate per se, vs. the order that created it. I could go either wa= y. That's the idea (in PART 1, anyway). The issue of whether a certificate should be referred to by reference=20 (URI) or by value (supplied as the certificate itself) is discussed in=20 draft-seantek-certspec-11. In this case, I do not see any additional=20 value in /requiring/ a separate URI to access the certificate octets.=20 Put another way: if you want a separate URI instead of the certificate,=20 because you don't want to store the certificate, then you will have to=20 store the separate URI somewhere. And, if you are storing the separate=20 URI, you have a place to store the certificate in the first place. Perhaps there is business value in a CA standing up a sensible=20 (well-known) URI scheme, such as: https://www.cawebsite.com/.well-known/getcert?host=3DFOO.BAR.COM&{other=20 parameters} =2E..but that is outside of the scope of the (current) protocol for this = working group. Compare with draft-bhjl-x509-srv-03. I could see it being = added to the ACME server as a "feature", but that is up to you all. > > If we do inline the certificate into the order, ISTM the natural thing = > to do would be to just present it in base64url-encoded form: > > { > // existing order fields > "certificate": "[[ base64url data ]]", > "chain": ["[[ base64url data ]]", ...] > } > > Then it would just be a syntactic transformation to whatever an HTTP=20 > server accepts. Something like that could be okay. Although I suppose some "aesthetics"=20 are involved, the choice for JSON format is not exactly bikeshedding. If = it's in JSON then some part of it ought to be an array. The main point=20 (raised in PART 1) is that inlining makes things faster and sidesteps=20 all of the problems raised by MIME types and text blobs in PART 2. I note that a base64url-encoded version of the DER octets of a=20 certificate are already included in this protocol, in Certificate=20 Revocation Section 7.6. Sean --------------0EC051EDA6FE534E6BA80FFE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 4/2/2017 1:06 PM, Richard Barnes wrote:


On Fri, Mar 31, 2017 at 5:23 PM, Sean Leonard <dev+ietf@seantek.com> wrote:
Hi ACME:

SECOND PART.
[...]
That said, the idea of "inlining" the certificate / chain doesn't seem completely awful.  On the one hand, it would save an HTTP round-trip in the common case, and we don't have anything else in the protocol that relies on a certificate being referenced indepenedently from the order that created it.  On the other hand, it seems like there could be some utility in the future to being able to refer to the certificate per se, vs. the order that created it.  I could go either way.

That's the idea (in PART 1, anyway).

The issue of whether a certificate should be referred to by reference (URI) or by value (supplied as the certificate itself) is discussed in draft-seantek-certspec-11. In this case, I do not see any additional value in requiring a separate URI to access the certificate octets. Put another way: if you want a separate URI instead of the certificate, because you don't want to store the certificate, then you will have to store the separate URI somewhere. And, if you are storing the separate URI, you have a place to store the certificate in the first place.

Perhaps there is business value in a CA standing up a sensible (well-known) URI scheme, such as:

https://www.cawebsite.com/.well-known/getcert?host=FOO.BAR.COM&{other parameters}

...but that is outside of the scope of the (current) protocol for this working group. Compare with draft-bhjl-x509-srv-03. I could see it being added to the ACME server as a "feature", but that is up to you all.


If we do inline the certificate into the order, ISTM the natural thing to do would be to just present it in base64url-encoded form:

{
  // existing order fields
  "certificate": "[[ base64url data ]]",
  "chain": ["[[ base64url data ]]", ...]
}

Then it would just be a syntactic transformation to whatever an HTTP server accepts.

Something like that could be okay. Although I suppose some "aesthetics" are involved, the choice for JSON format is not exactly bikeshedding. If it's in JSON then some part of it ought to be an array. The main point (raised in PART 1) is that inlining makes things faster and sidesteps all of the problems raised by MIME types and text blobs in PART 2.

I note that a base64url-encoded version of the DER octets of a certificate are already included in this protocol, in Certificate Revocation Section 7.6.

Sean

--------------0EC051EDA6FE534E6BA80FFE-- From nobody Mon Apr 3 04:29:05 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 290A512944A for ; Mon, 3 Apr 2017 04:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 uZUhc-ooKCiL for ; Mon, 3 Apr 2017 04:29:02 -0700 (PDT) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D458912871F for ; Mon, 3 Apr 2017 04:29:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1491218939; l=1306; s=domk; d=kelunik.com; h=Content-Type:Cc:To:Subject:Date:From:References:In-Reply-To: MIME-Version; bh=sww7l9+O3O5k025k1jVUgtxgLQ3NHgCWA0C+PdsvRiI=; b=yROzIFCQwZzUbQ2ofkD83TUvdW/3gTpMbsn4hqYp6tLwZm9RxMtU39XrWeQLv1hl2K vdH1v13RxSb2HvD52XXqMgIAu5tH3oe8MA5iKPMm/v1V2jb9xjdstbwHkOHpKoc3RaJj jCLHXSvgwvn70sXQ24wl8RN1Zvx63p1zj7xsk= X-RZG-AUTH: :IWkkfkWkbvHsXQGmRYmUo9mls2vWuiu+7SLDup6E67mzuoNJBqDwsMA= X-RZG-CLASS-ID: mo00 Received: by mail-qt0-f180.google.com with SMTP id r45so108663450qte.3 for ; Mon, 03 Apr 2017 04:28:59 -0700 (PDT) X-Gm-Message-State: AFeK/H37TIZiqHLKa4rwBAaCHUIW+K5GwtfeqohA4hOt4QQp3eRDqxLLSz6iWU0HSSYnqUL3rLqseODI4pBZpw== X-Received: by 10.200.34.171 with SMTP id f40mr15906886qta.125.1491218938890; Mon, 03 Apr 2017 04:28:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.144.167 with HTTP; Mon, 3 Apr 2017 04:28:58 -0700 (PDT) In-Reply-To: <083b73a4-a199-dc57-e078-bf1bf9c10bd2@seantek.com> References: <083b73a4-a199-dc57-e078-bf1bf9c10bd2@seantek.com> From: Niklas Keller Date: Mon, 3 Apr 2017 13:28:58 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Sean Leonard Cc: Richard Barnes , ACME WG Content-Type: multipart/alternative; boundary=001a113ff01822976d054c4177be Archived-At: Subject: Re: [Acme] "Slide 21" follow-up (textual encoding question) PART 2 X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 11:29:04 -0000 --001a113ff01822976d054c4177be Content-Type: text/plain; charset=UTF-8 One potential issue I can see with embedding certificates with the currently proposed format directly into orders are alternative chains. Chains usually do not change between orders, so they could be kept with separate URIs for cachability and less bloat in the order response. e.g. "certificate": base64url(derEncodedCertificate), "chains": [ "https://.../chain", "https://.../alternate-chain" ] Regards, Niklas --001a113ff01822976d054c4177be Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
One potential issue I can see with embedding certificates = with the currently proposed format directly into orders are alternative cha= ins. Chains usually do not change between orders, so they could be kept wit= h separate URIs for cachability and less bloat in the order response.
<= br>
e.g.

"certificate": base64= url(derEncodedCertificate),
"chains": [
=C2= =A0 =C2=A0"https://.../chain",
=C2=A0 =C2=A0"https= ://.../alternate-chain"
]

Regards, = Niklas
--001a113ff01822976d054c4177be-- From nobody Mon Apr 3 05:54: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 7CB62129579 for ; Mon, 3 Apr 2017 05:54:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FvLgpP0P6X1Q for ; Mon, 3 Apr 2017 05:54:10 -0700 (PDT) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D50F127342 for ; Mon, 3 Apr 2017 05:54:10 -0700 (PDT) Received: by mail-pg0-x230.google.com with SMTP id 21so119802582pgg.1 for ; Mon, 03 Apr 2017 05:54:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PT5HBEr8/dluzKi36TqZEvAg3nJhRH9VAVd9CVEaTtE=; b=Wkr1LHxjfKat+iT0Ym2h5CTVCKnEgLAhSkJEluTsvgCWHCA5ofYI6euwnflKVjXNTH CnygzXt99fHbU4SjMxq1U11dwLvWZ+un3YTJ5diUxGcnbSpK1fo4KdIETyDc+Gpbqq2y K9DPLv5oKZW0v57+6xuSGdp40h07/SoOfeO96HFA/YT40N/lXXTmKkGNK4HXuFXVZ7IH HZ55aAwMRg+Rga9PvuIjyZN7wRqRP6WSU051jTUQo6W6pipi5BaLKQZ9glrvvDRCDOmC QZeNm90inWgWS5HEYKrgo+bRX7gHFj3/CE2iDK6xc0O5TYWWovMUPu14S54/8bjW/oyb 5Vlw== 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=PT5HBEr8/dluzKi36TqZEvAg3nJhRH9VAVd9CVEaTtE=; b=ukLM/qoqzaG/3p8/XyTgSxJ5TSPVQ/ks/uYcy+Wc6QNltpfVr+Q8QlbaAveS+BA8R8 SPDWC6hD0CPrdDtCFI1QsJxBSx5DT6QwXnUzZmZ9e95ajkOHqMiwKvuWkRrHnB7wzblb v0jQ011rj3G+8HE60/jJNC457r9qN8RI6GJ8hGXCRqsynaTrpKi4IVPolWobGGUKLeEE qTO5ocHUP/LCNkWamgtCjeiKNj4tSwq8UaXtlYzNSJmx2ZmX6TeIKjJX1Y4YvQ9v7VaL jAAaqhlyvysOl4DNgICYI39aEP/FAxO4cwTy7FqoKYiKep1/zUmH8PCXO9Qm9oQaMLgR w2Kg== X-Gm-Message-State: AFeK/H0AzB2oS8nsT02pAG8NECErtziTlMttQgf0vbpFkVuhxFVikdyB7xvWOWTL33TnPquLzlpnNUS45g12bA== X-Received: by 10.99.225.5 with SMTP id z5mr17645367pgh.145.1491224049549; Mon, 03 Apr 2017 05:54:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.130.129 with HTTP; Mon, 3 Apr 2017 05:54:08 -0700 (PDT) Received: by 10.100.130.129 with HTTP; Mon, 3 Apr 2017 05:54:08 -0700 (PDT) In-Reply-To: References: <083b73a4-a199-dc57-e078-bf1bf9c10bd2@seantek.com> From: Logan Widick Date: Mon, 3 Apr 2017 07:54:08 -0500 Message-ID: To: Niklas Keller Cc: Sean Leonard , Richard Barnes , ACME WG Content-Type: multipart/alternative; boundary=001a114e93a4c10521054c42a795 Archived-At: Subject: Re: [Acme] "Slide 21" follow-up (textual encoding question) PART 2 X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 12:54:12 -0000 --001a114e93a4c10521054c42a795 Content-Type: text/plain; charset=UTF-8 I think that having separate URIs to reduce bloat is a good idea. I understand that the client needs to send the CSR as a field in the new-order request payload for security. However, in the server response, could the CSR be a URI that would allow the client to retrieve the CSR that the client submitted in DER format? So, could new-order requests look like: { csr: "base64url(derEncodedCSR)" //rest of fields in new-order here } And the server's order response look like: { csrLink: "[link to DER encoded CSR]" certificate: "[link to DER encoded certificate]" chains: [array of links to chains as suggested by Niklas] //rest of fields in order response here (except for "csr") } For consistency, I think the chain links (when retrieved) should be concatenated DER. Sincerely, Logan Widick On Apr 3, 2017 06:29, "Niklas Keller" wrote: One potential issue I can see with embedding certificates with the currently proposed format directly into orders are alternative chains. Chains usually do not change between orders, so they could be kept with separate URIs for cachability and less bloat in the order response. e.g. "certificate": base64url(derEncodedCertificate), "chains": [ "https://.../chain", "https://.../alternate-chain" ] Regards, Niklas _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme --001a114e93a4c10521054c42a795 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think that having separate URIs to reduce bloat is= a good idea. I understand that the client needs to send the CSR as a field= in the new-order request payload for security. However, in the server resp= onse, could the CSR be a URI that would allow the client to retrieve the CS= R that the client submitted in DER format? So, could new-order requests loo= k like:=C2=A0

{
csr: "base64url(derEncodedCSR)"
//rest of fields in new-order here
}

And the server's order response look like:
{
c= srLink: "[link to DER encoded CSR]"
certificate: "[link to DER encoded certificate]"<= /div>
chains: [array of links to cha= ins as suggested by Niklas]
//= rest of fields in order response here (except for "csr")
}

For consistency= , I think the chain links (when retrieved) should be concatenated DER.=C2= =A0

Sincerely,

Logan Widick

On Apr 3, 2017 06:29, = "Niklas Keller" <me@kelunik.= com> wrote:
One potential issue I can see with embedding certificates with th= e currently proposed format directly into orders are alternative chains. Ch= ains usually do not change between orders, so they could be kept with separ= ate URIs for cachability and less bloat in the order response.

e.g.

"certificate": base64url(derEncodedCertificate),
"chains": [
=C2=A0 = =C2=A0"https://.../chain",
=C2=A0 =C2=A0"https://.= ../alternate-chain"
]

Regards, Nikl= as

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


--001a114e93a4c10521054c42a795-- From nobody Mon Apr 3 08:44: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 7B846129455 for ; Mon, 3 Apr 2017 08:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m3vOc8j8PZcA for ; Mon, 3 Apr 2017 08:43:58 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10414129422 for ; Mon, 3 Apr 2017 08:43:52 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.20/8.16.0.20) with SMTP id v33Fhl2I022580; Mon, 3 Apr 2017 16:43:49 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=fRXxLAC7dtmlmAtLpKW/Z9d6CBmMk0EFdJjx5jIosfs=; b=ea2iOdytS3iFpdNfz1PjU/VhkMWOCPCpBo6En0uOZh0od7KnN2A1WqFjb6CA9KCgdPhk 4d9SuLwtzj4e6GLgURu6AwgAvpvlSFKDleV9dH4jq+Aju+PBskwJ8TnHpeqlNbgJWy7L FJC2xfQpmVbqezysm0UH9fBv9P/DRhyLC/+PyZ1jrysCHOqfaBA/3dWknUV527N/HzIs 3jjeBCjZxYrZmbGlvDncls7AzelTToT1BYi8eIfLx+OjMk33ahO4mzycAwtEjAySj6yp UPBrnI+eFTNbsHdNiVxI/gfUclc7JnAllXatEix3BFNjqXD+aoYqtDVkab35mK3AoZt8 9w== Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 29j4m4348e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 03 Apr 2017 16:43:47 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v33Ffi33001249; Mon, 3 Apr 2017 11:43:17 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint1.akamai.com with ESMTP id 29j7hu8w2x-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 03 Apr 2017 11:43:17 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 3 Apr 2017 11:43:17 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Mon, 3 Apr 2017 11:43:17 -0400 From: "Salz, Rich" To: Richard Barnes , Sean Leonard CC: ACME WG Thread-Topic: [Acme] "Slide 21" follow-up (textual encoding question) PART 2 Thread-Index: AQHSqm16spyWDD7X70Sh0X9mnd79yqGyx2MAgAEFfpA= Date: Mon, 3 Apr 2017 15:43:16 +0000 Message-ID: <41ce7ddf23e2446aac9de6685afdf0eb@usma1ex-dag1mb1.msg.corp.akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.113] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-03_14:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1704030140 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-03_14:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1704030140 Archived-At: Subject: Re: [Acme] "Slide 21" follow-up (textual encoding question) PART 2 X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 15:43:59 -0000 U3BlYWtpbmcgYXMgYW4gaW5kaXZpZHVhbCwgSSB0aGluayByZXR1cm5pbmcgdGhlIGNlcnRsaXN0 IGluIHRoZSByZXNwb25zZSB3aWxsIGxlYWQgdG8gY2FyZWxlc3MgY2xpZW50cyB0aGFuIGNhbiAq b25seSogaGFuZGxlIHN5bmNocm9ub3VzIGNlcnQgY3JlYXRpb24uDQoNClRoaXMgc3RyaWtlcyBt ZSBhcyBhIHByZW1hdHVyZSBvcHRpbWl6YXRpb24uDQoNCg== From nobody Mon Apr 3 14:08: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 96DE1128CD5 for ; Mon, 3 Apr 2017 14:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzUlcvLDiqxL for ; Mon, 3 Apr 2017 14:08:04 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 197FD129459 for ; Mon, 3 Apr 2017 14:07:57 -0700 (PDT) Received: from [192.168.123.7] (unknown [76.90.60.238]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4185122E255; Mon, 3 Apr 2017 17:07:38 -0400 (EDT) To: Logan Widick , Niklas Keller References: <083b73a4-a199-dc57-e078-bf1bf9c10bd2@seantek.com> Cc: Richard Barnes , ACME WG From: Sean Leonard Message-ID: <9f046557-fe26-faad-30b3-7f721851cb5b@seantek.com> Date: Mon, 3 Apr 2017 14:07:32 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------7BBF8B7FF825FFB3CB418F36" Archived-At: Subject: Re: [Acme] "Slide 21" follow-up (textual encoding question) PART 2 X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 21:08:07 -0000 This is a multi-part message in MIME format. --------------7BBF8B7FF825FFB3CB418F36 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 4/3/2017 5:54 AM, Logan Widick wrote: > I think that having separate URIs to reduce bloat is a good idea. I=20 > understand that the client needs to send the CSR as a field in the=20 > new-order request payload for security. However, in the server=20 > response, could the CSR be a URI that would allow the client to=20 > retrieve the CSR that the client submitted in DER format? So, could=20 > new-order requests look like: > > { > csr: "base64url(derEncodedCSR)" > //rest of fields in new-order here > } > > And the server's order response look like: > { > csrLink: "[link to DER encoded CSR]" > certificate: "[link to DER encoded certificate]" > chains: [array of links to chains as suggested by Niklas] > //rest of fields in order response here (except for "csr") > } The wrinkle with this proposal is that CSRs are likely non-public data.=20 They could contain personally identifiable information in the metadata,=20 or other random stuff. It is undesirable to have a link that has to be=20 maintained for the lifetime of the order history, which could be=20 harvested by search engines or otherwise made public. Typically CAs=20 harvest the public key and discard the rest (after verifying the=20 authenticity of the CSR). Therefore, I am not in favor of URIs for CSR da= ta. The case for URIs for issued end-entity certificates is half-half.=20 Certificates are public documents, but it's an extra round-trip and you=20 have to save the same amount of state on the client side (i.e., the=20 certificate URI). The case for URI(s) for CA certificates in the validation chain is=20 strongest, since they are unlikely to change and are reused across many=20 customers. Basically "de-duplication". On the other hand, there are=20 business/usability advantages to packaging up "everything you need to=20 run your web server" in one neat package. I think that CA=20 operators/implementers would have the most authority to weigh in on what = works best. > > For consistency, I think the chain links (when retrieved) should be=20 > concatenated DER. I am in favor of DER. :) (But less sure about whether links are=20 desirable in the first place.) I could have sworn that when certificate retrieval is done over the=20 wire, CMS (PKCS #7) is an IETF standardized type for blobs of=20 certificates. Oh yeah, here it is: RFC 5280 Section 4.2.2.1 (it's repeated elsewhere): HTTP server implementations accessed via the URI SHOULD specify the media type application/pkix-cert [RFC2585 ] in the content-type header field of the response for a single DER encoded certificate and SHOULD= specify the media type application/pkcs7-mime [RFC2797 ] in the content-type header field of the response for "certs-only" CMS messages. For FTP, the name of a file that contains a single DER encoded certificate SHOULD have a suffix of ".cer" [RFC2585 ] and the name of a file that contains a "certs-only" CMS message SHOULD have a= suffix of ".p7c" [RFC2797 ]. Co= nsuming clients may use the media type or file extension as a hint to the content, but should not depend solely on the presence of the correct media type or file extension in= the server response. Just sayin'... ;-) It is worth pointing out that PKCS #7 / CMS "certs-only", amounts to=20 concatenated DER certificates plus a little bit of goo at the beginning=20 and end (which can be ignored/skipped). Here is a dump of a .p7s file I=20 have lying around using asn1js: SEQUENCE(2 elem) OBJECT IDENTIFIER1.2.840.113549.1.7.2 [0](1 elem) SEQUENCE(5 elem) INTEGER1 SET(0 elem) SEQUENCE(1 elem) OBJECT IDENTIFIER1.2.840.113549.1.7.1 [0](3 elem) SEQUENCE(3 elem) SEQUENCE(3 elem) SEQUENCE(3 elem) SET(0 elem) In this case, the SEQ -> [0] -> SEQ -> [0] has three certificates, which = start with SEQUENCE. Rip and go. Finally, here is how you convert from p7s to textual certificates: openssl pkcs7 -inform DER -in yourfile.p7s -print_certs The advantage of the command-line/OpenSSL recipe above, is that you are=20 guaranteed that the output will only be -----BEGIN CERTIFICATE-----=20 things. Non-certificates shall not pass. Sean > > Sincerely, > > Logan Widick > > On Apr 3, 2017 06:29, "Niklas Keller" > wrote: > > One potential issue I can see with embedding certificates with the > currently proposed format directly into orders are alternative > chains. Chains usually do not change between orders, so they could > be kept with separate URIs for cachability and less bloat in the > order response. > > e.g. > > "certificate": base64url(derEncodedCertificate), > "chains": [ > "https://.../chain", > "https://.../alternate-chain" > ] > > Regards, Niklas > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > > > --------------7BBF8B7FF825FFB3CB418F36 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 4/3/2017 5:54 AM, Logan Widick wrote:
I think that having separate URIs to reduce bloat is a good idea. I understand that the client needs to send the CSR as a field in the new-order request payload for security. However, in the server response, could the CSR be a URI that would allow the client to retrieve the CSR that the client submitted in DER format? So, could new-order requests look like: 

{
csr: "base64url(derEncodedCSR)"
//rest of fields in new-order here
}

And the server's order response look like:
{
csrLink: "[link to DER encoded CSR]"
certificate: "[link to DER encoded certificate]"
chains: [array of links to chains as suggested by Niklas]
//rest of fields in order response here (except for "csr")
}

The wrinkle with this proposal is that CSRs are likely non-public data. They could contain personally identifiable information in the metadata, or other random stuff. It is undesirable to have a link that has to be maintained for the lifetime of the order history, which could be harvested by search engines or otherwise made public. Typically CAs harvest the public key and discard the rest (after verifying the authenticity of the CSR). Therefore, I am not in favor of URIs for CSR data.

The case for URIs for issued end-entity certificates is half-half. Certificates are public documents, but it's an extra round-trip and you have to save the same amount of state on the client side (i.e., the certificate URI).

The case for URI(s) for CA certificates in the validation chain is strongest, since they are unlikely to change and are reused across many customers. Basically "de-duplication". On the other hand, there are business/usability advantages to packaging up "everything you need to run your web server" in one neat package. I think that CA operators/implementers would have the most authority to weigh in on what works best.


For consistency, I think the chain links (when retrieved) should be concatenated DER.

I am in favor of DER. :) (But less sure about whether links are desirable in the first place.)

I could have sworn that when certificate retrieval is done over the wire, CMS (PKCS #7) is an IETF standardized type for blobs of certificates. Oh yeah, here it is:
RFC 5280 Section 4.2.2.1 (it's repeated elsewhere):
   HTTP server implementations accessed via the URI SHOULD specify the
   media type application/pkix-cert [RFC2585] in the content-type header
   field of the response for a single DER encoded certificate and SHOULD
   specify the media type application/pkcs7-mime [RFC2797] in the
   content-type header field of the response for "certs-only" CMS
   messages.  For FTP, the name of a file that contains a single DER
   encoded certificate SHOULD have a suffix of ".cer" [RFC2585] and the
   name of a file that contains a "certs-only" CMS message SHOULD have a
   suffix of ".p7c" [RFC2797].  Consuming clients may use the media type
   or file extension as a hint to the content, but should not depend
   solely on the presence of the correct media type or file extension in
   the server response.


Just sayin'... ;-)

It is worth pointing out that PKCS #7 / CMS "certs-only", amounts to concatenated DER certificates plus a little bit of goo at the beginning and end (which can be ignored/skipped). Here is a dump of a .p7s file I have lying around using asn1js:

SEQUENCE(2 elem)
OBJECT IDENTIFIER1.2.840.113549.1.7.2
[0](1 elem)
SEQUENCE(5 elem)
INTEGER1
SET(0 elem)
SEQUENCE(1 elem)
OBJECT IDENTIFIER1.2.840.113549.1.7.1
[0](3 elem)

In this case, the SEQ -> [0] -> SEQ -> [0] has three certificates, which start with SEQUENCE. Rip and go.

Finally, here is how you convert from p7s to textual certificates:
  openssl pkcs7 -inform DER -in yourfile.p7s -print_certs

The advantage of the command-line/OpenSSL recipe above, is that you are guaranteed that the output will only be -----BEGIN CERTIFICATE----- things. Non-certificates shall not pass.

Sean


Sincerely,

Logan Widick

On Apr 3, 2017 06:29, "Niklas Keller" <me@kelunik.com> wrote:
One potential issue I can see with embedding certificates with the currently proposed format directly into orders are alternative chains. Chains usually do not change between orders, so they could be kept with separate URIs for cachability and less bloat in the order response.

e.g.

"certificate": base64url(derEncodedCertificate),
"chains": [
]

Regards, Niklas

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



--------------7BBF8B7FF825FFB3CB418F36-- From nobody Tue Apr 4 12:33:30 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3E16129471 for ; Tue, 4 Apr 2017 12:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 P2qCbFR-ReSl for ; Tue, 4 Apr 2017 12:33:26 -0700 (PDT) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC356127275 for ; Tue, 4 Apr 2017 12:33:26 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id y18so66629131itc.1 for ; Tue, 04 Apr 2017 12:33:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=letsencrypt.org; s=google; h=mime-version:reply-to:from:date:message-id:subject:to; bh=3rzYGv6JzwGKatfW+ANepmKODC+Fz7dk+R/mZn6WTwg=; b=TmDznhn/RowdxCPW158BZCigCQuthZY5MZ+ToVvn1PHLx6+Rqf+I3L6EqjYk89+k9M BV/HJlkjqHamKkt/i6T0QN2iVmXgl/EWmVW5tpqxjTP+hae8flYFd4G01Ejneu6y8RFT OxUEMO5YHH0XdRnHBc9OOr+vbolctwHKGJooA= 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:from:date:message-id :subject:to; bh=3rzYGv6JzwGKatfW+ANepmKODC+Fz7dk+R/mZn6WTwg=; b=Mo0ZDYePb9u+Hlt+9Nz1NBmgKh7dNvtfSecQTu0PMo54kSQB24FsWVkoJEa9wnLR94 GQjgEw2aFOIF0sLjucoKM8pMRQJf3ktK4RAuKsw4Z7pzBj5SskEusmlLwy04GQfw3WXY LCAQOLKv3wpVuBaSD3w7MbStIvrodHSYlpaYz3S2ETg95pneLibUODni9xg9If0+3jrh l9CRaM1cvqMFDtBoNoiecdyeUnp/i21gXop05zprG0yBGsdet3G+S4dvqGWUdJbyl+e4 B0+ugHdVXzYjzd/XAMG78O1mQtfrIZY7YIr5MZsf1xdhpE0VApuJNk2h9GVOufS3VU1R GRig== X-Gm-Message-State: AFeK/H3Ix4PijialdMqwGMtIO8OpbBGq4OUVABs1mLDVvpYijLX1EzqKdogGCxatMNeaZRDbExxkfY5O5IgiHfKy X-Received: by 10.36.121.129 with SMTP id z123mr18408919itc.16.1491334405849; Tue, 04 Apr 2017 12:33:25 -0700 (PDT) MIME-Version: 1.0 Reply-To: cpu@letsencrypt.org Received: by 10.107.9.147 with HTTP; Tue, 4 Apr 2017 12:33:25 -0700 (PDT) From: Daniel McCarney Date: Tue, 4 Apr 2017 15:33:25 -0400 Message-ID: To: IETF ACME Content-Type: multipart/alternative; boundary=001a114ab47e80cfe9054c5c59ef Archived-At: Subject: [Acme] "mailto" mandatory to implement X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 19:33:29 -0000 --001a114ab47e80cfe9054c5c59ef Content-Type: text/plain; charset=UTF-8 Following up on the draft minutes[0] item for server contact support from the meeting at IETF98: """ - **Advertise server contact support** (slide 19) - Discussion: Ted highlights the risk of failure in negotiation (empty intersection) a single MTI scheme is necessary and sufficient for interop - **Decision** is to REQUIRE `mailto` as URL scheme so that it's always possible to fall back to it """ I submitted https://github.com/ietf-wg-acme/acme/pull/291 to cover this & add an unsupported contact protocol error type. [0] - https://mailarchive.ietf.org/arch/msg/acme/wO4AAJxnGEDT4LZQbIAbm4xXods - daniel --001a114ab47e80cfe9054c5c59ef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Following up on the draft minutes[0] item for server conta= ct support from the meeting at IETF98:

&q= uot;""
- **Advertise server contact support** (slide 19)
=C2=A0 - Discussion: Ted = highlights the risk of failure in negotiation (empty intersection) a single= MTI scheme is necessary and sufficient for interop
=C2=A0 - **Decision** is to = REQUIRE `mailto` as URL scheme so that it's always possible to fall bac= k to it
"""

I submitted https://github.com/ietf-wg-acme/acme= /pull/291 to cover this & add an unsupported contact protocol error= type.

[0] -=C2=A0https://mailarchive.ietf.org/arch/msg/acme= /wO4AAJxnGEDT4LZQbIAbm4xXods

- daniel
--001a114ab47e80cfe9054c5c59ef-- From nobody Sun Apr 9 01: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 32A4A1252BA for ; Sun, 9 Apr 2017 01:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.699 X-Spam-Level: X-Spam-Status: No, score=0.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=devever.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QUgkIuXH7phM for ; Sun, 9 Apr 2017 01:48:00 -0700 (PDT) Received: from umbriel.devever.net (umbriel.devever.net [149.202.51.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6D6A126C2F for ; Sun, 9 Apr 2017 01:47:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by umbriel.devever.net (Postfix) with ESMTP id 3029D1D4F3 for ; Sun, 9 Apr 2017 10:47:57 +0200 (CEST) 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=1491727677; x=1509917038; bh=J+IN vVkEVY5Xuz9V/aiCWB9alllswhLgEb5dJaD4qTA=; b=ngLXPOk4ucdc3jxLObqN 6691mmgfpBKshph2YxhVFznGHUCrezzVXdFvPM6d3WGd5A6aScWcPzdJuiwbQbE+ c3qha7l7AGq7F1GPDtWsB+vjzdlSzKpEAOPDGhbGCeJ9bAqvb/ZsfWmxS4Fd3uoD ZpLBrrVdvUPOt+U7gmp5Oh4lFgpBL+1wGfEPT8umckmvnBslGZBJzIQ1MxDXRiY0 m0aYzux87bExjBP5LhwbteyzlhrQ7jOvHJlg8cUYaC4/GTtpXrtf6jR/QWRT6z8x 4PzkuQpkr6vYACQCfNgtyduCvZheGgylOHRP4KJSdYsRqpfzPfc3TO6/mwj6Q8H9 5g== 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 Sg1bHzoV8DCp for ; Sun, 9 Apr 2017 10:47:57 +0200 (CEST) Received: from andover.lhh.devever.net (localhost [127.0.0.1]) by umbriel.devever.net (Postfix) with SMTP id 0620C1D4F1 for ; Sun, 9 Apr 2017 10:47:56 +0200 (CEST) Date: Sun, 9 Apr 2017 09:47:56 +0100 From: Hugo Landau To: acme@ietf.org Message-ID: <20170409084756.GA31209@andover.lhh.devever.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.8.0 (2017-02-23) Archived-At: Subject: [Acme] PR: allow challenge retries X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Apr 2017 08:48:01 -0000 This is a proposed change to enable challenges to be retried. https://github.com/ietf-wg-acme/acme/pull/292 From nobody Sun Apr 9 02:11:18 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 331DA126C2F for ; Sun, 9 Apr 2017 02:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=devever.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hda2OPxS-WJi for ; Sun, 9 Apr 2017 02:11:14 -0700 (PDT) Received: from umbriel.devever.net (umbriel.devever.net [149.202.51.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D725124D68 for ; Sun, 9 Apr 2017 02:11:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by umbriel.devever.net (Postfix) with ESMTP id 1079E1D4F3; Sun, 9 Apr 2017 11:11:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=devever.net; h= user-agent:in-reply-to:content-transfer-encoding :content-disposition:content-type:content-type:mime-version :references:message-id:subject:subject:from:from:date:date :received:received; s=mimas; t=1491729072; x=1509918433; bh=98mR bAvVTq8Hhv30F5zArR+GVs7ZWmZKzXxm6rW6WDQ=; b=MxWo3JSwQ66rvPT7LoQV lJ7dcQA1RVZNNH6pC7ZU81DIgIsmowY3IpCxeC+d9hIi8B2AaLmX+NfglqUWUIZl DQtdI8gA+LQhWH9mdzLeG+UcijENpnmXxiywE9xU9nxpoWeV0CVv8uCFzeRl7Qpe IqhiXTkXGj0xGYXpVumkH+79XpCoUgCkBNPQ7yyAtNf6zLEkCWs47BUZPftEmar6 yJO1qhrjVVS1G9l7JeoRm2cTyrxV7AEy5L7Dbu3UtV6L+dtV3y2hrlIJIFYKaWpL cqq0gM8lt1f34dpoFcTqZJY8K2Gta5F4ouPxoRnTJiyhHdmCS++oUOt9CCl7f9JS Vw== 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 HjhWBmOFuVtK; Sun, 9 Apr 2017 11:11:12 +0200 (CEST) Received: from andover.lhh.devever.net (localhost [127.0.0.1]) by umbriel.devever.net (Postfix) with ESMTP id C61A21D4E5; Sun, 9 Apr 2017 11:11:12 +0200 (CEST) Date: Sun, 9 Apr 2017 10:11:12 +0100 From: Hugo Landau To: Niklas Keller Cc: acme@ietf.org Message-ID: <20170409091112.GA31321@andover.lhh.devever.net> References: <083b73a4-a199-dc57-e078-bf1bf9c10bd2@seantek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.8.0 (2017-02-23) Archived-At: Subject: Re: [Acme] "Slide 21" follow-up (textual encoding question) PART 2 X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Apr 2017 09:11:16 -0000 I agree that end certificate data should be inlined in the certificate object, rather than being hosted at a separate certificate URI, so long as GET requests for order resources do not require authentication and can thus be easily polled (which is currently the case). I'm indifferent as to whether certificate data in the certificate object is a PEM formatted JSON string or base64url-encoded DER formatted JSON string. I think it's essential to support multiple certificate chains and referencing these by an array of URIs makes sense to me. I think it should be a requirement that the server always list its "recommended" chain first in that array, so that clueless clients can always have a sensible default to go with. (i.e., Let's Encrypt would list its current IdenTrust-based chain first, and its ISRG-based ahin second). I think having the certificate chains encoded in a format other than concatenated PEM is likely to be more trouble than it's worth. I think it's important that those certificate chains should include the root certificate, because it's required for some applications (DANE). Clients which do not require the root certificate can simply be mandated to strip off the last certificate returned in the chain. This is my preference. Alternatively, if that's viewed as too error-prone, a link rel=up link from the chain URL to the root URL could be used. I don't agree that including the certificate in the certificate object will cause badly implemented clients to assume synchronous issuance; one simply polls the order resource until the certificate appears. This is no different than waiting for a certificate URI to appear. (The current specification doesn't provide for requests to the certificate URI to defer a response; that was in a previous version.) On Mon, Apr 03, 2017 at 01:28:58PM +0200, Niklas Keller wrote: > One potential issue I can see with embedding certificates with the > currently proposed format directly into orders are alternative chains. > Chains usually do not change between orders, so they could be kept with > separate URIs for cachability and less bloat in the order response. > e.g. > "certificate": base64url(derEncodedCertificate), > "chains": [ > "https://.../chain", > "https://.../alternate-chain" > ] > Regards, Niklas From nobody Mon Apr 10 09:13:08 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D298612955B for ; Mon, 10 Apr 2017 09:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 A6grH0q9iD4j for ; Mon, 10 Apr 2017 09:13:05 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id BB358124217 for ; Mon, 10 Apr 2017 09:13:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 5BDCF1D031 for ; Mon, 10 Apr 2017 19:13:03 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id J7L6iP00tZBq for ; Mon, 10 Apr 2017 19:13:03 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 2F6A3C4 for ; Mon, 10 Apr 2017 19:13:03 +0300 (EEST) Date: Mon, 10 Apr 2017 19:13:01 +0300 From: Ilari Liusvaara To: acme@ietf.org Message-ID: <20170410161301.GA6442@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] Potential future incompatiblity between HTTP-01 and CABForum BRs X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 16:13:08 -0000 I read a draft for ballot[1] about changes to CABForum BR domain validation rules, and noticed that it drops the "required website content" bit, only retaining the Random Value and Request Token bits. Now, request token parts are irrelevant: HTTP-01 clearly does not qualify as request token. This leaves Random Value. There there is also a requirement that the Random Value does not appear in the request. Now, obviously HTTP-01 does put the Random Value into request. So it seemingly would not comply. Having to drop HTTP validation without replacement would be very bad to say the least. Estimated number of domains using it is in millions, and for vast majority, there is no viable replacement (besides disabling HTTPS, perhaps using commercial cert to ride HSTS timeout).. Maybe the WG could define HTTP-02 that doesn't send the same random value back? It would also solve the known issue that one can mint responses without knowing about the challenge (TLS-SNI-01 had a similar issue). As to why they want to drop the "required website content" bit, historically, many CAs have invented many quite bad validation methods, some based on methods from Baseline Requirements. [1] AFAIK, not yet in pre-voting discussion, but has the two endorsers needed to start official pre-voting discussion. -Ilari From nobody Mon Apr 10 10:55: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 35248129A96 for ; Mon, 10 Apr 2017 10:55:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=letsencrypt.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nnrNe0GFEhx0 for ; Mon, 10 Apr 2017 10:55:31 -0700 (PDT) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::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 5FCED129AAD for ; Mon, 10 Apr 2017 10:55:28 -0700 (PDT) Received: by mail-pf0-x22b.google.com with SMTP id i5so36729625pfc.2 for ; Mon, 10 Apr 2017 10:55:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=letsencrypt.org; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=mYvtnkbR4iyx2jTiqcoewdOakiDovrXjcFoZLpx2SYQ=; b=AasOG3LbjsDiyfSLMOvNMdmwceMgHcNZOO/bW1/IosqKCemIIa9baEbeu7D15ZevcA SUtj8D/XFXzWk2IT4SeQBUBofrwjthFuczQvwxQTME2QUFnilCZqtzroOqvWyKIeTba0 OoQHbGtMGLG7We45LoTsciYwYql/6LtuirTqM= 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=mYvtnkbR4iyx2jTiqcoewdOakiDovrXjcFoZLpx2SYQ=; b=WI7QGShT+XpDHznAsDVMbNxATwWE8Z6h/wAjVyPFcNqW6APOuCcIlqFCdTZd2Vcp5W rIPQ4wewB13RfPfpON1rQzQNQsay4YflKaBn7/iyWD6WSLo2yPHqiDAANhsuQFUSodsc L0u7Gte+dAqT4LKZC28HjEAw4Su5h1oYu+vQnuBUL/w1PYy8AQk5MwbCiBIbT67mD7KM YPwJGLCfJzj5nFKd6wjlXhN5KGngtPJd7Q3Q4isPIfbo+ZPBD30viabBl0HHD7rxpJ21 DJJmdbM2aCYfL33OEsrHoEv8G2ddIaeb8K8hUuGk9aP8eYoQYM7HDa02y8/Yc9Mjbm16 6Mkw== X-Gm-Message-State: AFeK/H2G+DfP8K+qw0YDqKiu+GFJVATqTWQimeqWMWUyLbuO9K6woze/d/9nPD+VdZ4yg9tq X-Received: by 10.84.178.101 with SMTP id y92mr69939775plb.171.1491846927334; Mon, 10 Apr 2017 10:55:27 -0700 (PDT) Received: from [192.168.42.101] ([50.1.57.147]) by smtp.gmail.com with ESMTPSA id s3sm25997414pgn.29.2017.04.10.10.55.26 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Apr 2017 10:55:26 -0700 (PDT) To: acme@ietf.org References: <20170410161301.GA6442@LK-Perkele-V2.elisa-laajakaista.fi> From: Roland Bracewell Shoemaker Message-ID: <19242844-99ce-3087-b5b4-d3c7981feb3f@letsencrypt.org> Date: Mon, 10 Apr 2017 10:55:25 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170410161301.GA6442@LK-Perkele-V2.elisa-laajakaista.fi> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Acme] Potential future incompatiblity between HTTP-01 and CABForum BRs X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 17:55:34 -0000 I'm not sure why the contents of the http-01 challenge could not be considered a 'request token'? A favorable interpretation that would require no changes would be that the random token (in ACME speak) is only half of the 'request token' (CABF speak) that is required for validation and therefore the full 'request token' _is not_ present in the request (since the required key authorization contains both the random token and the thumbprint of the JWK public key). On 04/10/2017 09:13 AM, Ilari Liusvaara wrote: > I read a draft for ballot[1] about changes to CABForum BR domain > validation rules, and noticed that it drops the "required website > content" bit, only retaining the Random Value and Request Token > bits. Now, request token parts are irrelevant: HTTP-01 clearly does > not qualify as request token. > > This leaves Random Value. There there is also a requirement that the > Random Value does not appear in the request. Now, obviously HTTP-01 > does put the Random Value into request. So it seemingly would not > comply. > > Having to drop HTTP validation without replacement would be very > bad to say the least. Estimated number of domains using it is in > millions, and for vast majority, there is no viable replacement > (besides disabling HTTPS, perhaps using commercial cert to ride > HSTS timeout).. > > > Maybe the WG could define HTTP-02 that doesn't send the same > random value back? It would also solve the known issue that one > can mint responses without knowing about the challenge > (TLS-SNI-01 had a similar issue). > > > > As to why they want to drop the "required website content" bit, > historically, many CAs have invented many quite bad validation > methods, some based on methods from Baseline Requirements. > > > [1] AFAIK, not yet in pre-voting discussion, but has the two > endorsers needed to start official pre-voting discussion. > > > -Ilari > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > From nobody Mon Apr 10 12:14: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 9AFE9129AB6 for ; Mon, 10 Apr 2017 12:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wXliZgbIIGLq for ; Mon, 10 Apr 2017 12:14:45 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 084B81296B0 for ; Mon, 10 Apr 2017 12:14:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 4E4B21F1E7; Mon, 10 Apr 2017 22:14:41 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id fKNNXF5lyOgl; Mon, 10 Apr 2017 22:14:41 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 1586E27F; Mon, 10 Apr 2017 22:14:41 +0300 (EEST) Date: Mon, 10 Apr 2017 22:14:39 +0300 From: Ilari Liusvaara To: Roland Bracewell Shoemaker Cc: acme@ietf.org Message-ID: <20170410191439.GA6904@LK-Perkele-V2.elisa-laajakaista.fi> References: <20170410161301.GA6442@LK-Perkele-V2.elisa-laajakaista.fi> <19242844-99ce-3087-b5b4-d3c7981feb3f@letsencrypt.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <19242844-99ce-3087-b5b4-d3c7981feb3f@letsencrypt.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [Acme] Potential future incompatiblity between HTTP-01 and CABForum BRs X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 19:14:48 -0000 On Mon, Apr 10, 2017 at 10:55:25AM -0700, Roland Bracewell Shoemaker wrote: > I'm not sure why the contents of the http-01 challenge could not be > considered a 'request token'? A favorable interpretation that would > require no changes would be that the random token (in ACME speak) is > only half of the 'request token' (CABF speak) that is required for > validation and therefore the full 'request token' _is not_ present in > the request (since the required key authorization contains both the > random token and the thumbprint of the JWK public key). The problem here is two SHALL (i.e. RFC2119 MUST) -level requirements on Request Tokens: - They incorporate the "key used in the certificate request" - Non-timestamped Request Tokens are single-use (timestamped ones are valid for maximum of 30 days). (Section 1.6.1 of CABForum baseline requirements version 1.4.4) My reading of "key used in the certificate request" is the CSR public key, which can't match the account key anyway (and in the case of Let's Encrypt as of today, isn't even known). There is no definition of "certifiate request" as far as I can see. As for the second requirement, there is actually a twisted reading that might be met: There is no requirement to bind the timestamp or the use-once diversification to the rest of the token in any way. Let's throw the random value as use-once diversification (LOL), it certainly renders the response unique... -Ilari From nobody Tue Apr 11 07:33:56 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A0FA129B23 for ; Tue, 11 Apr 2017 07:33:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.4 X-Spam-Level: X-Spam-Status: No, score=-5.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v2evRB3i3wC3 for ; Tue, 11 Apr 2017 07:33:51 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43AEF129515 for ; Tue, 11 Apr 2017 07:33:51 -0700 (PDT) Received: from [172.28.236.132] (unknown [50.254.145.121]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 6684A509C4; Tue, 11 Apr 2017 10:33:49 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sean Leonard In-Reply-To: <20170409091112.GA31321@andover.lhh.devever.net> Date: Tue, 11 Apr 2017 07:33:47 -0700 Cc: Niklas Keller , Hugo Landau Content-Transfer-Encoding: quoted-printable Message-Id: <2698A81A-35A6-4AC1-8BC8-0A7EC20C8428@seantek.com> References: <083b73a4-a199-dc57-e078-bf1bf9c10bd2@seantek.com> <20170409091112.GA31321@andover.lhh.devever.net> To: ACME WG X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Acme] "Slide 21" follow-up (textual encoding question) PART 2 X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 14:33:54 -0000 So what I am hearing is that there are rising voices in favor of PART 1, = namely inlining the certificate data, which obviates (i.e., removes) the = need for a separate MIME type. As for the format of end-entity certificate data: if it=E2=80=99s in = JSON then it has to be some textual encoding. I am mostly indifferent to = RFC 7468 textual encoding vs. base64/base64url, but on balance I think = base64/base64url is better because that=E2=80=99s the same format as the = csr field, which means that clients and servers have to process it = anyway. Furthermore, we don=E2=80=99t want naive clients to dump the = contents of the certificate field into their web server preferences, = since that results in the same validation problem as before in letting = through more than just a single certificate. It=E2=80=99s also smaller. = (I don=E2=80=99t understand why base64url was chosen over base64, is = that some JWS requirement or something? Please help me understand that.) I can=E2=80=99t say whether support for multiple chains is necessary, = but several people have identified it as being useful. So that should be = some kind of array. If URIs are used to retrieve the certificate chain(s), ACME doesn=E2=80=99= t currently specify what kinds of URIs clients and servers need to = support=E2=80=94the draft ought to say something about that. RFC 5280 = describes URI access mechanisms using HTTP, HTTPS, FTP, LDAP, and X.500 = without recommending any particular thing. I think the same = constellation of URIs ought to be supported (proposed text: =E2=80=9CSome = URI schemes are documented in [RFC5280].=E2=80=9D =E2=80=94 not = recommending any particular thing). This is less work than people might = think, as many crypto stacks implement rudimentary HTTP/HTTPS, FTP, and = LDAP clients anyway (yes, even LDAP). If =E2=80=9Centerprise=E2=80=9D is = a use case for this protocol then LDAP should be supported anyway. = (Note: if the data: URI is also supported, then you have an option for = inlining in a different part of the software stack, not sure if folks = want to go there as data: is base64 rather than base64url.) The draft could also discuss that the caIssuers access method (RFC 5280 = Section 4.2.2.1) SHOULD be filled in the subject certificate, and the = clients are to follow those URIs to get any CA certificate chains. Then = you can just let the crypto stack have at it. In MS CAPI it is just a = flag (default is on) to CertGetCertificateChain. The protocol could allow both inlined certificate data (array of = base64(url)-encoded certs)) and URI options. This is more complicated, = but as pointed out above, URIs are mostly supported by crypto stacks = anyway. Again, it=E2=80=99s just one call in MS CAPI: = CryptRetrieveObjectByUrl. (See also CryptGetObjectUrl.) Sean > On Apr 9, 2017, at 2:11 AM, Hugo Landau wrote: >=20 > I agree that end certificate data should be inlined in the certificate > object, rather than being hosted at a separate certificate URI, so = long > as GET requests for order resources do not require authentication and > can thus be easily polled (which is currently the case). >=20 > I'm indifferent as to whether certificate data in the certificate = object > is a PEM formatted JSON string or base64url-encoded DER formatted JSON > string. >=20 > I think it's essential to support multiple certificate chains and > referencing these by an array of URIs makes sense to me. >=20 > I think it should be a requirement that the server always list its > "recommended" chain first in that array, so that clueless clients can > always have a sensible default to go with. (i.e., Let's Encrypt would > list its current IdenTrust-based chain first, and its ISRG-based ahin > second). >=20 > I think having the certificate chains encoded in a format other than > concatenated PEM is likely to be more trouble than it's worth. >=20 > I think it's important that those certificate chains should include = the > root certificate, because it's required for some applications (DANE). > Clients which do not require the root certificate can simply be = mandated > to strip off the last certificate returned in the chain. This is my > preference. Alternatively, if that's viewed as too error-prone, a link > rel=3Dup link from the chain URL to the root URL could be used. >=20 > I don't agree that including the certificate in the certificate object > will cause badly implemented clients to assume synchronous issuance; = one > simply polls the order resource until the certificate appears. This is > no different than waiting for a certificate URI to appear. (The = current > specification doesn't provide for requests to the certificate URI to > defer a response; that was in a previous version.) >=20 > On Mon, Apr 03, 2017 at 01:28:58PM +0200, Niklas Keller wrote: >> One potential issue I can see with embedding certificates with the >> currently proposed format directly into orders are alternative = chains. >> Chains usually do not change between orders, so they could be kept = with >> separate URIs for cachability and less bloat in the order response. >> e.g. >> "certificate": base64url(derEncodedCertificate), >> "chains": [ >> "https://.../chain", >> "https://.../alternate-chain" >> ] >> Regards, Niklas >=20 > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme From nobody Tue Apr 11 08:34: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 8732B12EABB for ; Tue, 11 Apr 2017 08:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MREltv8JFGg0 for ; Tue, 11 Apr 2017 08:34:51 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id CDD9C12EAAA for ; Tue, 11 Apr 2017 08:34:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id D660522473; Tue, 11 Apr 2017 18:34:48 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id FuWaAGuxPYjC; Tue, 11 Apr 2017 18:34:48 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 805352313; Tue, 11 Apr 2017 18:34:48 +0300 (EEST) Date: Tue, 11 Apr 2017 18:34:46 +0300 From: Ilari Liusvaara To: Sean Leonard Cc: ACME WG , Hugo Landau , Niklas Keller Message-ID: <20170411153446.GA8573@LK-Perkele-V2.elisa-laajakaista.fi> References: <083b73a4-a199-dc57-e078-bf1bf9c10bd2@seantek.com> <20170409091112.GA31321@andover.lhh.devever.net> <2698A81A-35A6-4AC1-8BC8-0A7EC20C8428@seantek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2698A81A-35A6-4AC1-8BC8-0A7EC20C8428@seantek.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [Acme] "Slide 21" follow-up (textual encoding question) PART 2 X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 15:34:53 -0000 On Tue, Apr 11, 2017 at 07:33:47AM -0700, Sean Leonard wrote: > > As for the format of end-entity certificate data: if it’s in JSON > then it has to be some textual encoding. I am mostly indifferent > to RFC 7468 textual encoding vs. base64/base64url, but on balance > I think base64/base64url is better because that’s the same format > as the csr field, which means that clients and servers have to > process it anyway. Furthermore, we don’t want naive clients to > dump the contents of the certificate field into their web server > preferences, since that results in the same validation problem as > before in letting through more than just a single certificate. It’s > also smaller. (I don’t understand why base64url was chosen over > base64, is that some JWS requirement or something? Please help me > understand that.) Well, JWS tends to use base64url. And dumping a array of base64url encoded certificates into "PEM" file is not difficult: 1) For each entry: 1a) Write "-----BEGIN CERTIFICATE-----" and linefeed 1b) Check that the string consists of only alphanumerics, - and _. 1c) Replace - with +, and _ with / in string. 1d) Pad to multiple of 4 with =. 1e) Write out the modified string, wrapping to 72 characters. 1f) Write "-----END CERTIFICATE-----" and linefeed. This method is not vulernable to special certificate types. > I can’t say whether support for multiple chains is necessary, > but several people have identified it as being useful. So that > should be some kind of array. Problem is, since multiple chains are involved, it becomes some sort of array of array. And if you dump all the certificates in chains there, assume lots of servers will end up with serving such "chains" (which break TLS 1.2 rules). > If URIs are used to retrieve the certificate chain(s), ACME > doesn’t currently specify what kinds of URIs clients and servers > need to support—the draft ought to say something about that. RFC > 5280 describes URI access mechanisms using HTTP, HTTPS, FTP, LDAP, > and X.500 without recommending any particular thing. I think the > same constellation of URIs ought to be supported (proposed text: > “Some URI schemes are documented in [RFC5280].” — not recommending > any particular thing). This is less work than people might think, > as many crypto stacks implement rudimentary HTTP/HTTPS, FTP, and > LDAP clients anyway (yes, even LDAP). If “enterprise” is a use > case for this protocol then LDAP should be supported anyway. (Note: > if the data: URI is also supported, then you have an option for > inlining in a different part of the software stack, not sure if folks want to go there as data: is base64 rather than base64url.) I presume URLs are all HTTPS. > The draft could also discuss that the caIssuers access method > (RFC 5280 Section 4.2.2.1) SHOULD be filled in the subject > certificate, and the clients are to follow those URIs to get any > CA certificate chains. Then you can just let the crypto stack > have at it. In MS CAPI it is just a flag (default is on) to > CertGetCertificateChain. Way too complicated for most clients. And didn't that kind of thing blow up rather badly when LE updated their intermediates (from X1/X2 to X3/X4)? > The protocol could allow both inlined certificate data (array of > base64(url)-encoded certs)) and URI options. This is more complicated, > but as pointed out above, URIs are mostly supported by crypto stacks > anyway. Again, it’s just one call in MS CAPI: CryptRetrieveObjectByUrl. > (See also CryptGetObjectUrl.) Doing something because MS CAPI makes it easy is a bad idea. Most users won't be using anything that has anything to do with CAPI. -Ilari From nobody Tue Apr 11 09:10: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 6CD34129536 for ; Tue, 11 Apr 2017 09:10:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.4 X-Spam-Level: X-Spam-Status: No, score=-5.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a_UQj8SqcLkR for ; Tue, 11 Apr 2017 09:10:19 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03193129513 for ; Tue, 11 Apr 2017 09:10:18 -0700 (PDT) Received: from [172.28.236.132] (unknown [50.254.145.121]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 2A50D509BB; Tue, 11 Apr 2017 12:10:16 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sean Leonard In-Reply-To: <20170411153446.GA8573@LK-Perkele-V2.elisa-laajakaista.fi> Date: Tue, 11 Apr 2017 09:10:15 -0700 Cc: Hugo Landau , Niklas Keller Content-Transfer-Encoding: quoted-printable Message-Id: <522F29CD-5005-4CF9-9DC8-513E540144F4@seantek.com> References: <083b73a4-a199-dc57-e078-bf1bf9c10bd2@seantek.com> <20170409091112.GA31321@andover.lhh.devever.net> <2698A81A-35A6-4AC1-8BC8-0A7EC20C8428@seantek.com> <20170411153446.GA8573@LK-Perkele-V2.elisa-laajakaista.fi> To: Ilari Liusvaara , ACME WG X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Acme] "Slide 21" follow-up (textual encoding question) PART 2 X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 16:10:20 -0000 > On Apr 11, 2017, at 8:34 AM, Ilari Liusvaara = wrote: >=20 > On Tue, Apr 11, 2017 at 07:33:47AM -0700, Sean Leonard wrote: >>=20 >> As for the format of end-entity certificate data: if it=E2=80=99s in = JSON >> then it has to be some textual encoding. I am mostly indifferent >> to RFC 7468 textual encoding vs. base64/base64url, but on balance >> I think base64/base64url is better because that=E2=80=99s the same = format >> as the csr field, which means that clients and servers have to >> process it anyway. Furthermore, we don=E2=80=99t want naive clients = to >> dump the contents of the certificate field into their web server >> preferences, since that results in the same validation problem as >> before in letting through more than just a single certificate. It=E2=80= =99s >> also smaller. (I don=E2=80=99t understand why base64url was chosen = over >> base64, is that some JWS requirement or something? Please help me >> understand that.) >=20 > Well, JWS tends to use base64url. >=20 > And dumping a array of base64url encoded certificates into "PEM" > file is not difficult: >=20 > 1) For each entry: > 1a) Write "-----BEGIN CERTIFICATE-----" and linefeed > 1b) Check that the string consists of only alphanumerics, - and _. > 1c) Replace - with +, and _ with / in string. > 1d) Pad to multiple of 4 with =3D. > 1e) Write out the modified string, wrapping to 72 characters. > 1f) Write "-----END CERTIFICATE-----" and linefeed. >=20 > This method is not vulernable to special certificate types. Thanks for the algorithm. :) Yup, pretty easy. >=20 >> I can=E2=80=99t say whether support for multiple chains is necessary, >> but several people have identified it as being useful. So that >> should be some kind of array. >=20 > Problem is, since multiple chains are involved, it becomes > some sort of array of array. =E2=80=A6which is not a problem, since that=E2=80=99s what it is anyway, = regardless of whether it=E2=80=99s a JSON [ [ =E2=80=9C=E2=80=9D ] ] or = something else. Nested structures are just fine. >=20 > And if you dump all the certificates in chains there, assume lots > of servers will end up with serving such "chains" (which break TLS 1.2 > rules). Less sure about this one, I would think a naive implementation would = just pick the first chain in the array of chains, and not do any = checking (as opposed to doing validation checking before putting into = production). >=20 >> If URIs are used to retrieve the certificate chain(s), ACME >> doesn=E2=80=99t currently specify what kinds of URIs clients and = servers >> need to support=E2=80=94the draft ought to say something about that. = RFC >> 5280 describes URI access mechanisms using HTTP, HTTPS, FTP, LDAP, >> and X.500 without recommending any particular thing. I think the >> same constellation of URIs ought to be supported (proposed text: >> =E2=80=9CSome URI schemes are documented in [RFC5280].=E2=80=9D =E2=80=94= not recommending >> any particular thing). This is less work than people might think, >> as many crypto stacks implement rudimentary HTTP/HTTPS, FTP, and >> LDAP clients anyway (yes, even LDAP). If =E2=80=9Centerprise=E2=80=9D = is a use >> case for this protocol then LDAP should be supported anyway. (Note: >> if the data: URI is also supported, then you have an option for >> inlining in a different part of the software stack, not sure if > folks want to go there as data: is base64 rather than base64url.) >=20 > I presume URLs are all HTTPS. I don=E2=80=99t think that presumption is warranted. Besides, they could = be straight HTTP, it avoids circularity problems if you can=E2=80=99t = validate the server cert or client cert for mutual auth because somehow = your validation depends on ACME or this-and-that (hand wave). Note: there *is* a substitution attack if, during the ACME protocol, you = retrieve the certificate URI over HTTP and an adversary = man-in-the-middle attacks the communication and provides you with the = wrong cert. Yet it=E2=80=99s unclear what exactly the harm is, since you = have the private key, it would just be a DoS attack. Well, the harm is = much more obvious if you don=E2=80=99t check the text that is returned = and there is a -----BEGIN RSA PRIVATE KEY----- snuck in the middle = there. :^) >=20 >> The draft could also discuss that the caIssuers access method >> (RFC 5280 Section 4.2.2.1) SHOULD be filled in the subject >> certificate, and the clients are to follow those URIs to get any >> CA certificate chains. Then you can just let the crypto stack >> have at it. In MS CAPI it is just a flag (default is on) to >> CertGetCertificateChain. >=20 > Way too complicated for most clients. >=20 > And didn't that kind of thing blow up rather badly when LE updated > their intermediates (from X1/X2 to X3/X4)? Not familiar with the history on that one, maybe a link would be = helpful? >=20 >> The protocol could allow both inlined certificate data (array of >> base64(url)-encoded certs)) and URI options. This is more = complicated, >> but as pointed out above, URIs are mostly supported by crypto stacks >> anyway. Again, it=E2=80=99s just one call in MS CAPI: = CryptRetrieveObjectByUrl. >> (See also CryptGetObjectUrl.) >=20 > Doing something because MS CAPI makes it easy is a bad idea. Most > users won't be using anything that has anything to do with CAPI. I know people around here like to hate on MS CAPI but that is what a = significant fraction of TLS clients use. When RFC 7468 was written, we checked the behavior of at least five = different implementations: OS X/iOS Cryptographic Services, MS CAPI, = OpenSSL, Mozilla NSS, and GnuTLS. Wish we checked others but didn=E2=80=99= t have the time, unfortunately. You would be surprised how finicky the = different implementations are when it came to line endings and = whitespace, for example. I thought we strive around these parts to check at least two independent = implementations. =E2=80=9CApache and Nginix=E2=80=9D are not two = independent implementations, since they both use OpenSSL (and both, = notably, in more-or-less the same way). OpenSSL is fine software but = it=E2=80=99s not the only deployed software out there, that=E2=80=99s my = point. Regards, Sean From nobody Tue Apr 11 10:22:01 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0786124282 for ; Tue, 11 Apr 2017 10:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nidHfdEsPdJg for ; Tue, 11 Apr 2017 10:21:56 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id DD4A3128D69 for ; Tue, 11 Apr 2017 10:21:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 63C8E22D40; Tue, 11 Apr 2017 20:21:54 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id 3ZzD-eooxPAh; Tue, 11 Apr 2017 20:21:54 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id F39662313; Tue, 11 Apr 2017 20:21:53 +0300 (EEST) Date: Tue, 11 Apr 2017 20:21:52 +0300 From: Ilari Liusvaara To: Sean Leonard Cc: ACME WG , Hugo Landau , Niklas Keller Message-ID: <20170411172152.GA8813@LK-Perkele-V2.elisa-laajakaista.fi> References: <083b73a4-a199-dc57-e078-bf1bf9c10bd2@seantek.com> <20170409091112.GA31321@andover.lhh.devever.net> <2698A81A-35A6-4AC1-8BC8-0A7EC20C8428@seantek.com> <20170411153446.GA8573@LK-Perkele-V2.elisa-laajakaista.fi> <522F29CD-5005-4CF9-9DC8-513E540144F4@seantek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <522F29CD-5005-4CF9-9DC8-513E540144F4@seantek.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [Acme] "Slide 21" follow-up (textual encoding question) PART 2 X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 17:21:59 -0000 On Tue, Apr 11, 2017 at 09:10:15AM -0700, Sean Leonard wrote: > > > On Apr 11, 2017, at 8:34 AM, Ilari Liusvaara wrote: > > > > On Tue, Apr 11, 2017 at 07:33:47AM -0700, Sean Leonard wrote: > >> > > > >> I can’t say whether support for multiple chains is necessary, > >> but several people have identified it as being useful. So that > >> should be some kind of array. > > > > Problem is, since multiple chains are involved, it becomes > > some sort of array of array. > > …which is not a problem, since that’s what it is anyway, regardless > of whether it’s a JSON [ [ “” ] ] or something else. Nested structures > are just fine. > > > > > And if you dump all the certificates in chains there, assume lots > > of servers will end up with serving such "chains" (which break TLS 1.2 > > rules). > > Less sure about this one, I would think a naive implementation would > just pick the first chain in the array of chains, and not do any > checking (as opposed to doing validation checking before putting into > production). Oops, that was phrased in unclear way. I meant that if all the certificates are dumped into one array, you will likely get those kinds of chains sent from TLS servers. If it is array of arrays, and ACME client picks the first one, then obviously only that chain gets sent. And I expect number of ACME clients that do no validation before throwing cert into production to outnumber the ones that do even some validation. > > > >> If URIs are used to retrieve the certificate chain(s), ACME > >> doesn’t currently specify what kinds of URIs clients and servers > >> need to support—the draft ought to say something about that. RFC > >> 5280 describes URI access mechanisms using HTTP, HTTPS, FTP, LDAP, > >> and X.500 without recommending any particular thing. I think the > >> same constellation of URIs ought to be supported (proposed text: > >> “Some URI schemes are documented in [RFC5280].” — not recommending > >> any particular thing). This is less work than people might think, > >> as many crypto stacks implement rudimentary HTTP/HTTPS, FTP, and > >> LDAP clients anyway (yes, even LDAP). If “enterprise” is a use > >> case for this protocol then LDAP should be supported anyway. (Note: > >> if the data: URI is also supported, then you have an option for > >> inlining in a different part of the software stack, not sure if > > folks want to go there as data: is base64 rather than base64url.) > > > > I presume URLs are all HTTPS. > > I don’t think that presumption is warranted. Besides, they could > be straight HTTP, it avoids circularity problems if you can’t > validate the server cert or client cert for mutual auth because > somehow your validation depends on ACME or this-and-that (hand wave). Is this about servers fetching their existing certificates from CA on startup? I don't think that would be in scope for ACME. Also, I presume that any such fetch has reasonable TA list (NOT using the "system default" one). > Note: there *is* a substitution attack if, during the ACME protocol, > you retrieve the certificate URI over HTTP and an adversary man-in- > the-middle attacks the communication and provides you with the wrong > cert. Yet it’s unclear what exactly the harm is, since you have the > private key, it would just be a DoS attack. Well, the harm is much > more obvious if you don’t check the text that is returned and there > is a -----BEGIN RSA PRIVATE KEY----- snuck in the middle there. :^) AFAICT, scenarios where having private key in material obtained would make any sense lead into circular dependicies. > >> The draft could also discuss that the caIssuers access method > >> (RFC 5280 Section 4.2.2.1) SHOULD be filled in the subject > >> certificate, and the clients are to follow those URIs to get any > >> CA certificate chains. Then you can just let the crypto stack > >> have at it. In MS CAPI it is just a flag (default is on) to > >> CertGetCertificateChain. > > > > Way too complicated for most clients. > > > > And didn't that kind of thing blow up rather badly when LE updated > > their intermediates (from X1/X2 to X3/X4)? > > Not familiar with the history on that one, maybe a link would be helpful? Basically, Let's Encrypt got new intermediate that has different subject but the same key. Casued IIS (the webserver) chain building to go crazy, building incorrect certificate chain (containing wrong intermediate) until one cleared some system certificate storage (it took weeks to figure out what one needed to do to fix the problem). > >> The protocol could allow both inlined certificate data (array of > >> base64(url)-encoded certs)) and URI options. This is more complicated, > >> but as pointed out above, URIs are mostly supported by crypto stacks > >> anyway. Again, it’s just one call in MS CAPI: CryptRetrieveObjectByUrl. > >> (See also CryptGetObjectUrl.) > > > > Doing something because MS CAPI makes it easy is a bad idea. Most > > users won't be using anything that has anything to do with CAPI. > > I know people around here like to hate on MS CAPI but that is what a > significant fraction of TLS clients use. And even more significant fraction don't. So you can't assume MS CAPI behavior. > When RFC 7468 was written, we checked the behavior of at least five > different implementations: OS X/iOS Cryptographic Services, MS CAPI, > OpenSSL, Mozilla NSS, and GnuTLS. Wish we checked others but didn’t > have the time, unfortunately. You would be surprised how finicky the > different implementations are when it came to line endings and > whitespace, for example. Reading one of my own implementations with regards to PEM parsing: - Line endings are either '\n' or '\r\n', both are treated the same. - In base64 lines, ASCII 0x20 and 0x09 are ignored. Otherwise lines have to consist of valid Base64 characters. - If padding is present, there must be exactly correct amount to bring size to multiple of 4. - No extraneous characters are allowed in BEGIN and END lines. - Only "CERTIFICATE" blocks are read. There must be at least one. - All blocks are decoded as base64, but non-CERTIFICATE blocks are ignored. - Lines outside blocks are igored. (Well, those are supposed to be the rules, actually looks like the code has a bug that causes it to blow up if it ever encounters any block that isn't CERTIFICATE. > I thought we strive around these parts to check at least two independent > implementations. “Apache and Nginix” are not two independent > implementations, since they both use OpenSSL (and both, notably, in > more-or-less the same way). OpenSSL is fine software but it’s not the > only deployed software out there, that’s my point. Yeah, and my point is that MS CAPI is not the only deployed software, and thing that are easy in MS CAPI may be hard otherwise. -Ilari From nobody Tue Apr 11 11:34: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 39D2D12EBD0 for ; Tue, 11 Apr 2017 11:34:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4tI9QsYPUnAP for ; Tue, 11 Apr 2017 11:34:30 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 0F4C212EBFF for ; Tue, 11 Apr 2017 11:34:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 15B1D223D7; Tue, 11 Apr 2017 21:34:21 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id ILwo_1Z2XxOg; Tue, 11 Apr 2017 21:34:20 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id B3B82C4; Tue, 11 Apr 2017 21:34:20 +0300 (EEST) Date: Tue, 11 Apr 2017 21:34:19 +0300 From: Ilari Liusvaara To: Roland Bracewell Shoemaker Cc: acme@ietf.org Message-ID: <20170411183418.GA17322@LK-Perkele-V2.elisa-laajakaista.fi> References: <20170410161301.GA6442@LK-Perkele-V2.elisa-laajakaista.fi> <19242844-99ce-3087-b5b4-d3c7981feb3f@letsencrypt.org> <20170410191439.GA6904@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20170410191439.GA6904@LK-Perkele-V2.elisa-laajakaista.fi> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [Acme] Potential future incompatiblity between HTTP-01 and CABForum BRs X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 18:34:34 -0000 On Mon, Apr 10, 2017 at 10:14:39PM +0300, Ilari Liusvaara wrote: > On Mon, Apr 10, 2017 at 10:55:25AM -0700, Roland Bracewell Shoemaker wrote: > > I'm not sure why the contents of the http-01 challenge could not be > > considered a 'request token'? A favorable interpretation that would > > require no changes would be that the random token (in ACME speak) is > > only half of the 'request token' (CABF speak) that is required for > > validation and therefore the full 'request token' _is not_ present in > > the request (since the required key authorization contains both the > > random token and the thumbprint of the JWK public key). > > The problem here is two SHALL (i.e. RFC2119 MUST) -level requirements > on Request Tokens: > > - They incorporate the "key used in the certificate request" > - Non-timestamped Request Tokens are single-use (timestamped ones are > valid for maximum of 30 days). > > (Section 1.6.1 of CABForum baseline requirements version 1.4.4) > > My reading of "key used in the certificate request" is the CSR public > key, which can't match the account key anyway (and in the case of > Let's Encrypt as of today, isn't even known). There is no definition > of "certifiate request" as far as I can see. Well, thinking about it, ACME-01 as used by LE seems to imply that challenges are in response to "certificate requests" (regardless of what ACME calls it). And those requests _are_ keyed by the account key. Things get more screwy when one moves to ACME-06 (which is presumably close to ACME-final) without preauthorization. Now the requests have two keys, and BRs assume there is only one... (One also seemingly has to take somewhat wide interpretations of things to get TLS-SNI-01/TLS-SNI-02 to fit into "10 methods"). > As for the second requirement, there is actually a twisted reading > that might be met: There is no requirement to bind the timestamp or > the use-once diversification to the rest of the token in any way. > Let's throw the random value as use-once diversification (LOL), > it certainly renders the response unique... -Ilari From nobody Tue Apr 11 22:36: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 629821292FC for ; Tue, 11 Apr 2017 22:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2hO_V6VbUp_8 for ; Tue, 11 Apr 2017 22:36:05 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C286128CD5 for ; Tue, 11 Apr 2017 22:35:56 -0700 (PDT) Received: from [192.168.6.190] (unknown [64.134.236.210]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 7BDF722E257; Wed, 12 Apr 2017 01:35:48 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sean Leonard In-Reply-To: <20170411172152.GA8813@LK-Perkele-V2.elisa-laajakaista.fi> Date: Tue, 11 Apr 2017 22:35:47 -0700 Cc: Hugo Landau , Niklas Keller Content-Transfer-Encoding: quoted-printable Message-Id: <39AA2DE0-2133-40A9-977A-2EA7F0D667D4@seantek.com> References: <083b73a4-a199-dc57-e078-bf1bf9c10bd2@seantek.com> <20170409091112.GA31321@andover.lhh.devever.net> <2698A81A-35A6-4AC1-8BC8-0A7EC20C8428@seantek.com> <20170411153446.GA8573@LK-Perkele-V2.elisa-laajakaista.fi> <522F29CD-5005-4CF9-9DC8-513E540144F4@seantek.com> <20170411172152.GA8813@LK-Perkele-V2.elisa-laajakaista.fi> To: Ilari Liusvaara , ACME WG X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Acme] "Slide 21" follow-up (textual encoding question) PART 2 X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 05:36:07 -0000 > On Apr 11, 2017, at 10:21 AM, Ilari Liusvaara = wrote: >=20 > On Tue, Apr 11, 2017 at 09:10:15AM -0700, Sean Leonard wrote: >>=20 >>> On Apr 11, 2017, at 8:34 AM, Ilari Liusvaara = wrote: >>>=20 >>> On Tue, Apr 11, 2017 at 07:33:47AM -0700, Sean Leonard wrote: >>>>=20 >>>=20 >>>> I can=E2=80=99t say whether support for multiple chains is = necessary, >>>> but several people have identified it as being useful. So that >>>> should be some kind of array. >>>=20 >>> Problem is, since multiple chains are involved, it becomes >>> some sort of array of array. >>=20 >> =E2=80=A6which is not a problem, since that=E2=80=99s what it is = anyway, regardless >> of whether it=E2=80=99s a JSON [ [ =E2=80=9C=E2=80=9D ] ] or = something else. Nested structures >> are just fine. >>=20 >>>=20 >>> And if you dump all the certificates in chains there, assume lots >>> of servers will end up with serving such "chains" (which break TLS = 1.2 >>> rules). >>=20 >> Less sure about this one, I would think a naive implementation would >> just pick the first chain in the array of chains, and not do any >> checking (as opposed to doing validation checking before putting into >> production). >=20 > Oops, that was phrased in unclear way. I meant that if all the > certificates are dumped into one array, you will likely get those > kinds of chains sent from TLS servers. >=20 > If it is array of arrays, and ACME client picks the first one, then > obviously only that chain gets sent. Yes, it is an array of arrays. >=20 > And I expect number of ACME clients that do no validation before > throwing cert into production to outnumber the ones that do even > some validation. An old Russian proverb: =E2=80=9CTrust, but verify.=E2=80=9D This is not = just about verification in the narrow certificate validation sense: = it=E2=80=99s about sanitizing your inputs (verify in the broad sense). Implementations (currently) do not have to verify the input from the = server. They should verify in the broad sense (making sure that the = returned data is =E2=80=9Ccertificates, and only certificates=E2=80=9D); = they should also also verify in the narrow sense (validate the = certificate chains to a TA and is currently good). But I am not going to = push for the latter too hard because I am not so sure everyone around = here is going to implement that, so the blood is on their hands if they = throw a cert into production and millions of clients fail out. >=20 >>>=20 >>>> If URIs are used to retrieve the certificate chain(s), ACME >>>> doesn=E2=80=99t currently specify what kinds of URIs clients and = servers >>>> need to support=E2=80=94the draft ought to say something about = that. RFC >>>> 5280 describes URI access mechanisms using HTTP, HTTPS, FTP, LDAP, >>>> and X.500 without recommending any particular thing. I think the >>>> same constellation of URIs ought to be supported (proposed text: >>>> =E2=80=9CSome URI schemes are documented in [RFC5280].=E2=80=9D =E2=80= =94 not recommending >>>> any particular thing). This is less work than people might think, >>>> as many crypto stacks implement rudimentary HTTP/HTTPS, FTP, and >>>> LDAP clients anyway (yes, even LDAP). If =E2=80=9Centerprise=E2=80=9D= is a use >>>> case for this protocol then LDAP should be supported anyway. (Note: >>>> if the data: URI is also supported, then you have an option for >>>> inlining in a different part of the software stack, not sure if >>> folks want to go there as data: is base64 rather than base64url.) >>>=20 >>> I presume URLs are all HTTPS. >>=20 >> I don=E2=80=99t think that presumption is warranted. Besides, they = could >> be straight HTTP, it avoids circularity problems if you can=E2=80=99t >> validate the server cert or client cert for mutual auth because >> somehow your validation depends on ACME or this-and-that (hand wave). >=20 > Is this about servers fetching their existing certificates from CA on > startup? I don't think that would be in scope for ACME. No, I was referring to the once-a-year (or quarter or whatever) = certificate update, which is in-scope for ACME. I was not envisioning = that servers fetch existing certificates on software startup. *** As for the rest: it sounds like there is value in separating the subject = certificate in one field (base64url encoded), and the intermediate CA = certificate chains (plural) in another field, which may, or may not, = include the root. There is some value in inlining the certificate chains = (arrays of arrays of base64url-encoded certificates), and some value in = referencing certificate chains by URIs (arrays of URIs). I think that as long as the ACME client has flexibility in terms of how = to determine the appropriate certificate chains that it wants to put = into production (and that the ACME draft says so), then it is fine. The = subject certificate is fixed, but the ACME client can use any = intermediate cert chain when in production, or figure out its own custom = thing. In terms of the format of certificate chains, I am in favor of a chain = being an array of base64url-encoded certificates, and the =E2=80=9Cchains=E2= =80=9D field being an array of such chain arrays. This is mainly because = I really don=E2=80=99t see certificate chains changing during the = lifetime of a subject certificate, and it=E2=80=99s not difficult for an = ACME server to serve the same static data in response to a dynamic = request. For resource- or time-constrained ACME clients, this also leads = to the most predictable and rapid behavior. Note: if you want both by-value and by-reference, a base64url = certificate always begins with =E2=80=9CM=E2=80=9D, while an absolute = URI always contains =E2=80=9C:=E2=80=9D. Therefore you can overload the = field so that it can be a URI or a string depending on whether these = factors are present (specifically, if =E2=80=9C:=E2=80=9D is in the = string). But then again you can also just say = data:application/pkix-cert;base64,MIICAS=E2=80=A6 and get the same = effect if they are always URIs. Sean= From nobody Wed Apr 12 14:47: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 3ACC5128616 for ; Wed, 12 Apr 2017 14:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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_MED=-2.3, 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=digicert.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 CGBzG6yz-3SS for ; Wed, 12 Apr 2017 14:47:51 -0700 (PDT) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9887127876 for ; Wed, 12 Apr 2017 14:47:51 -0700 (PDT) From: Jeremy Rowley DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=digicert.com; s=mail; t=1492033672; bh=BxuEcSPs8oDgdZBnyU5Ckn0VFkWAJfFuBAY9y5m8+VY=; h=From:To:Subject:Date:References:In-Reply-To; b=NxkCszK318h5xGM/8HfPgibYrbKTMiDo9xzFRYKTafKrj8uNNJUef5G+cr8xkl1DP NiuAtl2kA09uoljOzk4d/DrUDlllHwwX4Q1RNu/JtVMR33yNcrsC80PptW3eSra1Hh EHwEIhZ7jvHpsyA6JC+iOIRzH5btw8nzix3s/NdU= To: Ilari Liusvaara , "acme@ietf.org" Thread-Topic: [Acme] Potential future incompatiblity between HTTP-01 and CABForum BRs Thread-Index: AQHSshVbwIuXtO/VIkae+f/US27WMaHCRuyQ Date: Wed, 12 Apr 2017 21:47:49 +0000 Message-ID: References: <20170410161301.GA6442@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: <20170410161301.GA6442@LK-Perkele-V2.elisa-laajakaista.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [67.137.52.7] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_02EE_01D2B3A4.22D57A70" MIME-Version: 1.0 Archived-At: Subject: Re: [Acme] Potential future incompatiblity between HTTP-01 and CABForum BRs X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 21:47:53 -0000 ------=_NextPart_000_02EE_01D2B3A4.22D57A70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The proposal drops "Required Website Content" because the requirement was redundant with the other option in the same section. Required Website Content is defined as a "Random Value or Request Token" plus extra information. If you replaced the phrase with the definition, Section 3.2.2.4.6 would state that a CA can either validate domain control using 1) a request token or random value OR 2) a request token or random value plus additional info. There's no point in including the additional info in a requirement if the methods overlap so much. Jeremy -----Original Message----- From: Acme [mailto:acme-bounces@ietf.org] On Behalf Of Ilari Liusvaara Sent: Monday, April 10, 2017 10:13 AM To: acme@ietf.org Subject: [Acme] Potential future incompatiblity between HTTP-01 and CABForum BRs I read a draft for ballot[1] about changes to CABForum BR domain validation rules, and noticed that it drops the "required website content" bit, only retaining the Random Value and Request Token bits. Now, request token parts are irrelevant: HTTP-01 clearly does not qualify as request token. This leaves Random Value. There there is also a requirement that the Random Value does not appear in the request. Now, obviously HTTP-01 does put the Random Value into request. So it seemingly would not comply. Having to drop HTTP validation without replacement would be very bad to say the least. Estimated number of domains using it is in millions, and for vast majority, there is no viable replacement (besides disabling HTTPS, perhaps using commercial cert to ride HSTS timeout).. Maybe the WG could define HTTP-02 that doesn't send the same random value back? It would also solve the known issue that one can mint responses without knowing about the challenge (TLS-SNI-01 had a similar issue). As to why they want to drop the "required website content" bit, historically, many CAs have invented many quite bad validation methods, some based on methods from Baseline Requirements. [1] AFAIK, not yet in pre-voting discussion, but has the two endorsers needed to start official pre-voting discussion. -Ilari _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme ------=_NextPart_000_02EE_01D2B3A4.22D57A70 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPdzCCA7cw ggKfoAMCAQICEAzn4OUX2Eb+j+Vg/BvwMDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMxMTExMDAw MDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlxEqWu3CaUiKr0zvUgOShY YAz4gNqpFZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gyNnbM3t08qKLvavsh8lJh358g 1x/isdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgvGP4oD7Ong9bDbkTAYTWWFv5ZnIt2 bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgzbCLph9AyWqK6E4IR7TkXnZk6cqHm+qTZ 1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKmVrO9spftqqfwt8WoP5UW0P+hlusIXxh3TwID AQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUReuir/SS y4IxLVGLp6chnfNtyA8wHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQEFBQADggEBAKIOvN/i7fDjcnN6ZJS/93Jm2DLkQnVirofr8tXZ3lazn8zOFCi5DZdgXBJMWOTT PYNJRViXNWkaqEfqVsZ5qxLYZ4GE338JPJTmuCYsIL09syiJ91//IuKXhB/pZe+H4N/BZ0mzXeuy CSrrJu14vn0/K/O3JjVtX4kBtklbnwEFm6s9JcHMtn/C8W+GxvpkaOuBLZTrQrf6jB7dYvG+UGe3 bL3z8R9rDDYHFn83fKlbbXrxEkZgg9cnBL5Lzpe+w2cqaBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVt bI+lt2EBsdKjJqEQcZ2t4sP5w5lRtysHCM4u5lCyp/oKRS+i8PIwggVmMIIETqADAgECAhALgHcH Lzs1YGO/amtK2gTIMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdp Q2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNI QTIgQXNzdXJlZCBJRCBDQTAeFw0xNTEwMTMwMDAwMDBaFw0xOTAxMTAxMjAwMDBaMIGBMQswCQYD VQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNlcnQx FjAUBgNVBAMTDUplcmVteSBSb3dsZXkxKTAnBgkqhkiG9w0BCQEWGmplcmVteS5yb3dsZXlAZGln aWNlcnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8kPdqjF+ljW5h8W7mQpM jaGlZ9YDLYTtUzcQjl71vRI4M6WSiZiUfbueAgupsQnxvl8By0BdwVmXnOIAUvqpFqzZhNIc8DGH M+uvXgT4+aoQvn9qPlt04CN5hzE/GFVvqs3neWgGfkzp1Z5H6RiqNoTOzdDWyr09Q8Gzm1jW9lTq sX0cxqooYtk29ooq12BvbVz0Jjgtt4Erdp27bTth11CaulJUDRT39YLLAwiR0bw3eMu8DCyuXAwV D68Ux33UbgYU9uvyFxBhJ83ST+1aw0r4E6iYTlQnKtYjEoNwlifhkwm4xS+lQHuTirpJGRFV42hd l9AtWQKRGuCUBL5EdwIDAQABo4IB8zCCAe8wHwYDVR0jBBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8 inkwHQYDVR0OBBYEFPEtLfkj2twAoaYEb8gixWV8QW8HMAwGA1UdEwEB/wQCMAAwJQYDVR0RBB4w HIEaamVyZW15LnJvd2xleUBkaWdpY2VydC5jb20wDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQG CCsGAQUFBwMCBggrBgEFBQcDBDBDBgNVHSAEPDA6MDgGCmCGSAGG/WwEAQIwKjAoBggrBgEFBQcC ARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCBiAYDVR0fBIGAMH4wPaA7oDmGN2h0dHA6 Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVkSURDQS1nMS5jcmwwPaA7oDmG N2h0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVkSURDQS1nMS5jcmww eQYIKwYBBQUHAQEEbTBrMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wQwYI KwYBBQUHMAKGN2h0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVk SURDQS5jcnQwDQYJKoZIhvcNAQELBQADggEBAKy4O+nfR40jBgIFlaomX723rsDsnP/MT7xA9waf /K/JSqkfi97389rH0IXxwcEG/ne664wDmq4tZ9EfFkT2cGv0+itbcCDETeeu9bqOj6/LbXiYj9EB zyRFTcZih4NBIVEpTEcEIZfFfNWn3yDocY6K9wZFaM4UKLAqsnN0xYEKCNkSFsWv1Ol/8J3p363A f+PrswxqzejMiYvsi0nFYPFUMby901Crme/n4xpIJ57mLWy28YshNFip8sIOmCdVJcJ9KU65YljF 5D0cWyFk4xslKhHz6x3LKwqQmpedxWG3zYJVcaqLuTyZSqaewzJ5q8qH+usnmkmb+tcF/SDFD7Aw ggZOMIIFNqADAgECAhAErnlgZmaQGrnFf6ZsW9zNMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0xMzExMDUxMjAwMDBaFw0yODEx MDUxMjAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANz4ESM/arXvwCd5Gy0Fh6IQQzHfDtQVG093 pCLOPoxw8L4Hjt0nKrwBHbYsCsrdaVgfQe1qBR/aY3hZHiIsK/i6fsk1O1bxH3xCfiWwIxnGRTjX PUT5IHxgrhywWhgEvo8796nwlJqmDGNJtkEXU0AyvU/mUHpQHyVF6PGJr83/Xv9Q8/AXEf+9xYn1 vWK52PuORQSFbZnNxUhN/SarAjZF6jbXX2riGoJBCtzp2fWRF47GIa04PBPmHn9mnNVN2Uba9s9S p307JMO0wVE1xpvr1O9+5HsD4US9egs34E/LgooNcRjkpuCJLBvzsnM8wbCSnhh9vat9xX0IoSzC n3MCAwEAAaOCAvgwggL0MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMDQGCCsG AQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMIGBBgNVHR8E ejB4MDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290 Q0EuY3JsMDqgOKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS b290Q0EuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDCCAbMGA1UdIASCAaowggGm MIIBogYKYIZIAYb9bAACBDCCAZIwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNv bS9DUFMwggFkBggrBgEFBQcCAjCCAVYeggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0AGgAaQBz ACAAQwBlAHIAdABpAGYAaQBjAGEAdABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAAYQBjAGMA ZQBwAHQAYQBuAGMAZQAgAG8AZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQAC8AQwBQ AFMAIABhAG4AZAAgAHQAaABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAgAEEAZwByAGUA ZQBtAGUAbgB0ACAAdwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBpAGwAaQB0AHkAIABh AG4AZAAgAGEAcgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQAIABoAGUAcgBlAGkAbgAgAGIA eQAgAHIAZQBmAGUAcgBlAG4AYwBlAC4wHQYDVR0OBBYEFOcCI4AAT9jXvJQL2T90OUkyPIp5MB8G A1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBCwUAA4IBAQBO1Iknuf0d h3d+DygFkPEKL8k7Pr2TnJDGr/qRUYcyVGvoysFxUVyZjrX64GIZmaYHmnwTJ9vlAqKEEtkV9gpE V8Q0j21zHzrWoAE93uOC5EVrsusl/YBeHTmQvltC9s6RYOP5oFYMSBDOM2h7zZOr8GrLT1gPuXtd GwSBnqci4ldJJ+6Skwi+aQhTAjouXcgZ9FCATgLZsF2RtJOH+ZaWgVVAjmbtgti7KF/tTGHtBlgo GVMRRLxHICmyBGzYiVSZO3XbZ3gsHpJ4xlU9WBIRMm69QwxNNNt7xkLb7L6rm2FMBpLjjt8hKlBX BMBgojXVJJ5mNwlJz9X4ZbPg4m7CMYIDrzCCA6sCAQEweTBlMQswCQYDVQQGEwJVUzEVMBMGA1UE ChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdp Q2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEAuAdwcvOzVgY79qa0raBMgwCQYFKw4DAhoFAKCCAgsw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNDEyMjE0NzQ4WjAj BgkqhkiG9w0BCQQxFgQUuDTuCJkNwX/9eE+UejTz4JRFIBcwgYgGCSsGAQQBgjcQBDF7MHkwZTEL MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0 LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhALgHcHLzs1YGO/amtK 2gTIMIGKBgsqhkiG9w0BCRACCzF7oHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0 IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBB c3N1cmVkIElEIENBAhALgHcHLzs1YGO/amtK2gTIMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZI AWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJ YIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIIBABBEACvjPRzmGvzWQaw0TYGosUSYsTfb0y1VAXVa CjXUU0E8CXN5iQtlwM/xIIyDYP3FlnwGe0eLCZU8ieIKohfOIzkn7Gx4Cm33dSc18Q6RuBeJROZy +LpMs9fWGqLhsUdcS69bOtyCpEoY8xtrrduC/TLErXo48rdpmfkQss+TiHm8GGk5qQA7lT/iFHij ay2SgRopdNEgdpIoNkv+OT2FKa8fFHo1DN3Nliv2qOP5GX4cuTrvaEJ+OzLa9DEZMJWXkeTV79dK AcHbmbQTI9FQCQTwwn4Jm4iQo7luSs7Y9QlLDKY3HHutsBBJsMZTs05go64qxqiawWY/9zbX0YUA AAAAAAA= ------=_NextPart_000_02EE_01D2B3A4.22D57A70-- From nobody Wed Apr 12 21:34:30 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE18B128D3E for ; Wed, 12 Apr 2017 21:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EIy96GOc0H6D for ; Wed, 12 Apr 2017 21:34:26 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id B7F34127B73 for ; Wed, 12 Apr 2017 21:34:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 213A4232C3; Thu, 13 Apr 2017 07:34:24 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id j20VEZeJ9LNx; Thu, 13 Apr 2017 07:34:23 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id D1A35C4; Thu, 13 Apr 2017 07:34:23 +0300 (EEST) Date: Thu, 13 Apr 2017 07:34:21 +0300 From: Ilari Liusvaara To: Jeremy Rowley Cc: "acme@ietf.org" Message-ID: <20170413043421.GA22887@LK-Perkele-V2.elisa-laajakaista.fi> References: <20170410161301.GA6442@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [Acme] Potential future incompatiblity between HTTP-01 and CABForum BRs X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 04:34:29 -0000 On Wed, Apr 12, 2017 at 09:47:49PM +0000, Jeremy Rowley wrote: > The proposal drops "Required Website Content" because the requirement was > redundant with the other option in the same section. Required Website > Content is defined as a "Random Value or Request Token" plus extra > information. If you replaced the phrase with the definition, Section > 3.2.2.4.6 would state that a CA can either validate domain control using 1) > a request token or random value OR 2) a request token or random value plus > additional info. There's no point in including the additional info in a > requirement if the methods overlap so much. Oh yeah, this is into lawyering, and I'm not good at that. I'm much more an engineer than a laywer and the languages are pretty much polar opposites. :-) I can see a valid interpretation of HTTP-01 in terms of BRs now. Thanks. -Ilari From nobody Mon Apr 17 15:40: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 E1B321293F2 for ; Mon, 17 Apr 2017 15:40:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5bqEHm5aJbp for ; Mon, 17 Apr 2017 15:40:09 -0700 (PDT) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18E9E1293EC for ; Mon, 17 Apr 2017 15:40:09 -0700 (PDT) Received: by mail-wr0-x235.google.com with SMTP id c55so91082134wrc.3 for ; Mon, 17 Apr 2017 15:40:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tDEaX1S4Ecp0o5+LPb4UKnV6Gaazm5eoa+tGPg99Has=; b=zwnzJnv88v9nP1JDfdA5X0jAAmFLL0ztgdIou9RxAjkG0nu+uAjHgRyJaKB8oggEiz nvEHY/IkejIQqucmILJzbYsCvA8Bgk1nzVINJcee+mJvDMwl0Gqr14+VM4VFSf2DHNfi xPnDJ55FwNOkJ4Y28HR48DQ8hJ8+EAyFxhvIv9C5UYjNpglf27XUZ52BFCJ4fdHxrE6E yTnA/N2tY3effM3TAlj4CcxJ96QEdM7xfS0z1nqPNM91FcSBmbT5DKcALHceTgrpQ8tr JUM/iebtksRNJFbcZ4Qk/+UpxQjcYuCFQ5z3zZRRyiNBjlWMWt+SEM8jj5o7gcV7IKUg iJRw== 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=tDEaX1S4Ecp0o5+LPb4UKnV6Gaazm5eoa+tGPg99Has=; b=tBhTsDJk7gp32qvXymD6Vyn85LSbdTYtDxs0utOMfiBwZbEUPOhEQjf9s0JiXdpzuD zdg/EQQJAT4K3MBv4kFZgCOCWwXX4xZNjNjustc8giLH8LPJAiVCYie5hgZYSvERtUAp wh0LstlR0H4vYq4XHccfh2aERMuxkXpYqXGb97tDRJfUL4tcs2wro81WFLluDAcrQhsx 7A5UOvV0HQTKBrO6nNpX2pR12rp+uOfaNZGu8viD/vfjX+WS9zkFXFBf1+DN0oosAUR7 W0uzmhzR6ObUoGOwOQySIYEUsKK4z1bSJBpHDKCVXStHB6ofrJXXCuAIkVc01l3wEusl A38w== X-Gm-Message-State: AN3rC/7Y5ZIeQEhXeI25B23xOwOWo+qAoyPZ1RFkJIVdc1HpQKUB/rt8 sWwoIL30d65Gc9OmdfByh7E9fL5EEAVV2Eg= X-Received: by 10.223.142.143 with SMTP id q15mr19849062wrb.180.1492468807440; Mon, 17 Apr 2017 15:40:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.40.65 with HTTP; Mon, 17 Apr 2017 15:40:06 -0700 (PDT) In-Reply-To: <20170409084756.GA31209@andover.lhh.devever.net> References: <20170409084756.GA31209@andover.lhh.devever.net> From: Richard Barnes Date: Mon, 17 Apr 2017 18:40:06 -0400 Message-ID: To: Hugo Landau Cc: "acme@ietf.org" Content-Type: multipart/alternative; boundary=f403045f517c1b2d24054d647957 Archived-At: Subject: Re: [Acme] PR: allow challenge retries X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 22:40:11 -0000 --f403045f517c1b2d24054d647957 Content-Type: text/plain; charset=UTF-8 Hey Hugo, Thanks for the PR. Jacob and I chatted a bit about this, and wanted to propose a slightly different approach: https://github.com/ietf-wg-acme/acme/pull/297 What do you think? Others on the list have any thoughts? Thanks, --Richard On Sun, Apr 9, 2017 at 4:47 AM, Hugo Landau wrote: > This is a proposed change to enable challenges to be retried. > > https://github.com/ietf-wg-acme/acme/pull/292 > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > --f403045f517c1b2d24054d647957 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hey Hugo,

Thanks for the PR.= =C2=A0 Jacob and I chatted a bit about this, and wanted to propose a slight= ly different approach:


What do you think?=C2=A0 Others on the list = have any thoughts?

Thanks,
--Richard=

O= n Sun, Apr 9, 2017 at 4:47 AM, Hugo Landau <hlandau@devever.net><= /span> wrote:
This is a proposed change t= o enable challenges to be retried.

https://github.com/ietf-wg-acme/acme/pull/292<= br>
_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

--f403045f517c1b2d24054d647957-- From nobody Mon Apr 17 15:45: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 9F4C013159C for ; Mon, 17 Apr 2017 15:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nR2NRN6HlTRV for ; Mon, 17 Apr 2017 15:45:37 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F35041242F7 for ; Mon, 17 Apr 2017 15:45:36 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id r190so1027679wme.1 for ; Mon, 17 Apr 2017 15:45:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=txdLM5i/wfWHK9+BY/33YATlHcFHcdNnaQJl6RGZ14o=; b=EIugB9nrsLbXZkPWyjl5HGOipVxYjEtdTlan7Mmo97qE5VDACsiKxrVLsS5soP7tzi 2FcsRbYast/1ogk21+FhLJXS4jIhDihEuDLHIPVN45pRL0BzVXcawS3RsfuGjppT3Knx GA1A9Ai1U0KwtPD6S3TI4UJjdZG8zJivt+TsDr7WVSH8mrCOzpzJAioMJHZyDB+3uhJK x7MeQ4k7xhWNhIVgxQ3bairZZPeJ2CMvmZ6MPa/KSqFS5RqWoJTbwr3TVLvZ6+GgPgSr SQOnhvAQ9Td8gxqa0KH57867I+QHOAnIOWxSPQPO0w6CvNQ7o6pb1z7QjQ6KEeqxWj0p 8O2g== 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=txdLM5i/wfWHK9+BY/33YATlHcFHcdNnaQJl6RGZ14o=; b=nsKIUUuMM6tGjVCqXoUS7YAgrJBn0apY+Ix8uNa4C+06cIzKU5bzpdDFAh1jhyFnQE lbwzeWcUBtnMuy6M9ajSkZmkEEe8qhrBvRp+Fc2fgXu9zcDtQn4YltVOnxjVH238LJi1 EnC7s3Oq9a+bGz4+TMGdooxDBlFyDMxr4ihb9q2Jv62NJWwdUPa2TR9D0dh0bnNSiP/k mYGe4iMVkqqeOIKUawWCVPRWISf1QiIOlYzClwug4l9dSAUllMMTRgsAz8JU5GNlFdLD V62H4/tPfc5fw/O3DL+RAyhATGSbdfouhpLh+t3D3x6lAQlWy/lNYhC33DG4g+gBlmYU lPGg== X-Gm-Message-State: AN3rC/6d7iLH6+TAE6EBm0meajcyK2XsIYRTr2zmvu77OL4MNP2Fy4Ok 7JQzWMpEo+2E3s+cWm00Q9BEtIDltkOu3Qo= X-Received: by 10.28.88.2 with SMTP id m2mr10978460wmb.12.1492469135055; Mon, 17 Apr 2017 15:45:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.40.65 with HTTP; Mon, 17 Apr 2017 15:45:34 -0700 (PDT) From: Richard Barnes Date: Mon, 17 Apr 2017 18:45:34 -0400 Message-ID: To: "acme@ietf.org" Content-Type: multipart/alternative; boundary=001a11442c66a2593d054d648ced Archived-At: Subject: [Acme] Account URI recovery X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 22:45:39 -0000 --001a11442c66a2593d054d648ced Content-Type: text/plain; charset=UTF-8 In reviewing a PR today noting that a client can find the account URI for a key pair using a new-account request with an empty payload [1], Jacob and I thought it might be a little more robust to use an explicit signal. I've posted a PR that adds a "recovery" field to indicate to the server that it should not create an account if one does not exist already. Which is a little ironic in a request to an endpoint designed to create an account, but saves us creating a whole new endpoint. https://github.com/ietf-wg-acme/acme/pull/296 Please let me know if you have any comments on the approach here. Thanks, --Richard --001a11442c66a2593d054d648ced Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In reviewing a PR today noting that a client can find= the account URI for a key pair using a new-account request with an empty p= ayload [1], Jacob and I thought it might be a little more robust to use an = explicit signal.=C2=A0 I've posted a PR that adds a "recovery"= ; field to indicate to the server that it should not create an account if o= ne does not exist already.=C2=A0 Which is a little ironic in a request to a= n endpoint designed to create an account, but saves us creating a whole new= endpoint.

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

Please let me know if you have any comments on the a= pproach here.

Thanks,
--Richard
--001a11442c66a2593d054d648ced-- From nobody Mon Apr 17 22:28: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 CCCE6129415 for ; Mon, 17 Apr 2017 22:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.602 X-Spam-Level: X-Spam-Status: No, score=-0.602 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 7RgISTbTEgLg for ; Mon, 17 Apr 2017 22:28:07 -0700 (PDT) Received: from umbriel.devever.net (umbriel.devever.net [149.202.51.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D88D0127599 for ; Mon, 17 Apr 2017 22:28:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by umbriel.devever.net (Postfix) with ESMTP id 9E3AE1D503; Tue, 18 Apr 2017 07:28:02 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=devever.net; h= user-agent:in-reply-to:content-transfer-encoding :content-disposition:content-type:content-type:mime-version :references:message-id:subject:subject:from:from:date:date :received:received; s=mimas; t=1492493282; x=1510682643; bh=1RlS oqHw8SzWqMQ/AWRBTVtvNelMG+tGhajglnBh3Lw=; b=J0a7wYWR05v6TRKtZjsZ tI2qc9aiWuPcF/FnTDgr5zcJrw2SLQq3xtONfz+lVrb8qSbFdzuP7f+lTzUEfVBr dB+pSOZ0LAC8oehO1nTMUEKtLzfB1m4ie8QU5Qw38iU4i50dDDyC9df27KDXKrTs pyxtGtChRBDQqrMtD6TbzE5qZDaSXLApRW1sGM3BRoYlaDRAM1FdwKHTDMfr/LFh K0RE0nTpY3DdxMSjCVrbdaXjkZVbiCYBshFP1+eq5GQBBtwYoqyt1MtFWCNTzRdP Jh/JKTcGzPVdcgzc2zkpGVL9O07hvydtGnrr5f5HhL7ym8s79q3vXkYcFLWpj6TP 2g== 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 QMPIHrY_Fozl; Tue, 18 Apr 2017 07:28:02 +0200 (CEST) Received: from andover.lhh.devever.net (localhost [127.0.0.1]) by umbriel.devever.net (Postfix) with ESMTP id 62D091D502; Tue, 18 Apr 2017 07:28:02 +0200 (CEST) Date: Tue, 18 Apr 2017 06:28:02 +0100 From: Hugo Landau To: Richard Barnes Cc: "acme@ietf.org" Message-ID: <20170418052802.GA18137@andover.lhh.devever.net> References: <20170409084756.GA31209@andover.lhh.devever.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.8.0 (2017-02-23) Archived-At: Subject: Re: [Acme] PR: allow challenge retries X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 05:28:09 -0000 > Hey Hugo, > Thanks for the PR. Jacob and I chatted a bit about this, and wanted to > propose a slightly different approach: > [1]https://github.com/ietf-wg-acme/acme/pull/297 > What do you think? Others on the list have any thoughts? This looks mostly OK. My only concern is that it's not clear how a client can determine when a server is still attempting automatic retries. Is this to be detected via the absence of the Retry-After header? Something more explicit might be nicer (and less susceptible to misimplementation). Also, is each automatic retry to result in an error being appended if unsuccessful? This could get quite spammy depending on how many times a server repeats verification. Possibly amendment of the problem document format to add a repeat count (in the spirit of "last message repeated N times") might be desirable. Or that might be my usual overengineering. Hugo Landau From nobody Mon Apr 17 22:34:05 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC8712704A for ; Mon, 17 Apr 2017 22:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=devever.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ojuyj4Hbremp for ; Mon, 17 Apr 2017 22:34:02 -0700 (PDT) Received: from umbriel.devever.net (umbriel.devever.net [149.202.51.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78CDE126CC7 for ; Mon, 17 Apr 2017 22:34:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by umbriel.devever.net (Postfix) with ESMTP id 021E61D502; Tue, 18 Apr 2017 07:34:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=devever.net; h= user-agent:in-reply-to:content-transfer-encoding :content-disposition:content-type:content-type:mime-version :references:message-id:subject:subject:from:from:date:date :received:received; s=mimas; t=1492493640; x=1510683001; bh=i1U1 frHU7oNGTV3v+fCQurZito6tBnTbixKbA4HI3eI=; b=qVMIFo+M8h3o9n1agqjK DKHM3C7Ws5qhI5scb+oVMfyTSjQmQUA1mHmlqTsdb877F0idpDdEc4/K8OxSDPRA /XtB1wFwH0RVfOrvFYhg4ORkUXe3I7trIK7QMojbqd+E4/tbZZFkXY0q6oz8SzWh zdprnc8bf9Bah0BIDT99ojq57bMXGbronmrGyqDARqHX35JlABYZ8WeFXC5EC0mf lCaC6am5d4pIDW81TP3UNesRZ6EcBsYQMNcF6zm+J6HtiVFUs7a69dRf4SsIM5oE D3nmr4VLt20HqAbCU5dO80RnoUo8R29x83bzUftvih7JVlLss4QTY1LeSwKG5+nb ow== 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 qYEapi5w2bHI; Tue, 18 Apr 2017 07:34:00 +0200 (CEST) Received: from andover.lhh.devever.net (localhost [127.0.0.1]) by umbriel.devever.net (Postfix) with ESMTP id B99B81D4FF; Tue, 18 Apr 2017 07:34:00 +0200 (CEST) Date: Tue, 18 Apr 2017 06:34:00 +0100 From: Hugo Landau To: Richard Barnes Cc: acme@ietf.org Message-ID: <20170418053400.GB18137@andover.lhh.devever.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.8.0 (2017-02-23) Archived-At: Subject: Re: [Acme] Account URI recovery X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 05:34:04 -0000 > In reviewing a PR today noting that a client can find the account URI for > a key pair using a new-account request with an empty payload [1], Jacob > and I thought it might be a little more robust to use an explicit signal. > I've posted a PR that adds a "recovery" field to indicate to the server > that it should not create an account if one does not exist already. Which > is a little ironic in a request to an endpoint designed to create an > account, but saves us creating a whole new endpoint. > [1]https://github.com/ietf-wg-acme/acme/pull/296 I don't think this should be called recovery. It's too reminiscent of the old removed account recovery mechanisms and will be confusing. How about "existing": true? From nobody Mon Apr 17 22:48: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 2DE50129469 for ; Mon, 17 Apr 2017 22:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1JvTLsKIBsHS for ; Mon, 17 Apr 2017 22:48:21 -0700 (PDT) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F08B012947B for ; Mon, 17 Apr 2017 22:48:19 -0700 (PDT) Received: by mail-pg0-x232.google.com with SMTP id 63so22389321pgh.0 for ; Mon, 17 Apr 2017 22:48:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Rc00EkXwOdNmQgpoBXuFzAbhvgRcESJMJJDALFG0h2M=; b=ghv9SWkAcgWyG7TXjUHbi7SZmRFqZ9hTWvkKay4qjRsNtX3JuVatvV9m06yk9naWxc sfAFy81llhAbWBU7BN31UgDJo6RSg1hx34aBMKr71XaYno96zkC7ucii58uqZ/rz9WyA YSvbPZhVXjUJyYnhFwvshmhhi6gdKDVf2DINAhYwFAcMW6dHxTX1LL+iwlrdjeeAa7jK BneROY8aJLDQ7bh3CtbMYN5Pah2CdH8XggEfp32CLiPxHGlSwR31Ky7E68wMMXZIOeNq w39fIDgD0E/TeSTpN1tqLtL13j1p9lRQ53PtZDwJinFbXC2+7XZ2e/rUEPu0affsnTon AE3Q== 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=Rc00EkXwOdNmQgpoBXuFzAbhvgRcESJMJJDALFG0h2M=; b=TqKuPHlyW4W18Fy+MjSDvEelxs02hiNF8U0AnQ1OYGpL92AFzdA51tQDsCli+Q+KSu 62p7Onv9TKlblRdSdZ8eZUQr33+4mCyKFIb0QxB3NHmT5zVGbPLG+3nrnKq8ar6Rk66C mO+7wgty46+5gATG2zKgDBYX71au7rm7Dp51pdVv9GzaUsj670ggKUeRhDWpTUZHmQfo Gkdif7qYEDGHwSKmBay/t3V0WCJT850LBij9U7Q70iH20MFZA3ps2Hvya+aJEIOnO7rn DIL4hHlwNpPoX+WU/Jm866y70nO4KwNtyvdQqZufSm58QhBWPc4YCqvZ6tgzB2agPw09 l+3w== X-Gm-Message-State: AN3rC/6idiAcNk7G9ct5PGAgyD0h6gHHAib9901R8NFYrwnk/NYqlDhn 0qj3Zv5veCqJvRZ1EdRD7VuG93uuPA== X-Received: by 10.98.12.72 with SMTP id u69mr15596352pfi.47.1492494499445; Mon, 17 Apr 2017 22:48:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.130.129 with HTTP; Mon, 17 Apr 2017 22:48:18 -0700 (PDT) Received: by 10.100.130.129 with HTTP; Mon, 17 Apr 2017 22:48:18 -0700 (PDT) In-Reply-To: References: From: Logan Widick Date: Tue, 18 Apr 2017 00:48:18 -0500 Message-ID: To: Richard Barnes Cc: ACME WG Content-Type: multipart/alternative; boundary=001a1147750c7800a1054d6a74b2 Archived-At: Subject: Re: [Acme] Account URI recovery X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 05:48:23 -0000 --001a1147750c7800a1054d6a74b2 Content-Type: text/plain; charset=UTF-8 >From the text, if the field isn't present, should the server act like it was set to false? If this new field is false, and an account exists, then what happens to the pre-existing account, its orders, its certificates and its authorizations? Sincerely, Logan Widick On Apr 17, 2017 17:45, "Richard Barnes" wrote: > In reviewing a PR today noting that a client can find the account URI for > a key pair using a new-account request with an empty payload [1], Jacob and > I thought it might be a little more robust to use an explicit signal. I've > posted a PR that adds a "recovery" field to indicate to the server that it > should not create an account if one does not exist already. Which is a > little ironic in a request to an endpoint designed to create an account, > but saves us creating a whole new endpoint. > > https://github.com/ietf-wg-acme/acme/pull/296 > > Please let me know if you have any comments on the approach here. > > Thanks, > --Richard > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > > --001a1147750c7800a1054d6a74b2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
From the text, if the field isn't p= resent, should the server act like it was set to false?

If this new field is false, and an account exists= , then what happens to the pre-existing account, its orders, its certificat= es and its authorizations?=C2=A0

Sincerely,

Log= an Widick

On Apr 17, 2017 17:45, "Richard Barnes" <rlb@ipv.sx&= gt; wrote:
In reviewing a PR today noting that a client can find the acc= ount URI for a key pair using a new-account request with an empty payload [= 1], Jacob and I thought it might be a little more robust to use an explicit= signal.=C2=A0 I've posted a PR that adds a "recovery" field = to indicate to the server that it should not create an account if one does = not exist already.=C2=A0 Which is a little ironic in a request to an endpoi= nt designed to create an account, but saves us creating a whole new endpoin= t.


Please let me know if you have any co= mments on the approach here.

Thanks,
--R= ichard

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

--001a1147750c7800a1054d6a74b2-- From nobody Wed Apr 19 13:24:52 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4621129C51 for ; Wed, 19 Apr 2017 13:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y1vnlqNaYZhW for ; Wed, 19 Apr 2017 13:24:49 -0700 (PDT) Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 735EF12945F for ; Wed, 19 Apr 2017 13:24:49 -0700 (PDT) Received: by mail-wr0-x22d.google.com with SMTP id l28so22885458wre.0 for ; Wed, 19 Apr 2017 13:24:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:references:to:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=XAqYT/VVDzISMACEOWoeN+2+GEGA32vzUjFAKVUaaS4=; b=TAsDq9IhJUQi7jbO6LDwIv4Q2vQWtdqRzGhQ0CdRY8eSi+oKwtgFrt240L9C83b/7X CsoUbM9RkABMeFAZkCPZ05WfB13sL0g2IIm/tUUIoQKjJ/2PZ2ePAdfYq+BzK5l4ZzdH lM9Wci+op8jSC/cAkNN1kQboMBmgN79vKX6REY9OVIIHKO+gaNrkYB6yVC3fi1kNb/eL j5AABj0zKZiEnNPwpGPOcq1lorOtTiIu8cAFM1Jx7kmN6F3ddyqGo8OfUdsu6miPu6Lh e/DT5DW7txh8Dvee8rr1DhWNcYGPDnl1wfq6OXD045D86yT8rGz9KDpgwqk+0qcOfsHw Z/bA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:to:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=XAqYT/VVDzISMACEOWoeN+2+GEGA32vzUjFAKVUaaS4=; b=ANlWaWFqxvKHvSM81UEb0mWJ64yqHmT0/S9fPZ+ouFJkecNl75kpsePFNu8vdjxVWo EhX7+ttXnuHg4E5LjhNlTZdbr2GDXorGAg2NEOuV6pHTJtaDhahO38JB16KU8CfEI+A1 MpI4+14k/ouSBiYI3gXB/EVbdXRImQwMUKmrikoKgM/eFtLhEUGZ59ej1yy4bK9oe+mu vu8F4en0O4R/Fw6BknB+ueuNnjeNHQQgUqpi0AH30262p7121ozEh4Ay0KlzE2L3Btsz HLkNq2xtwyDVt7ruP3nA8xdg7MOhjVS0+2EYIeY5U4H6N8/fcks16XqYTHgTDOziF59h I/YQ== X-Gm-Message-State: AN3rC/7a2oQe4jRnU7Y0aYx9ScNo1s6iqAJIyFVKBpQCi+1Dn2MaQWLh bSieHYMVMUbU90iUde0= X-Received: by 10.223.133.133 with SMTP id 5mr4307849wrt.83.1492633487806; Wed, 19 Apr 2017 13:24:47 -0700 (PDT) Received: from [10.0.0.14] (bzq-79-179-45-145.red.bezeqint.net. [79.179.45.145]) by smtp.gmail.com with ESMTPSA id b10sm20678344wme.22.2017.04.19.13.24.46 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Apr 2017 13:24:47 -0700 (PDT) References: <149263306622.19180.12048305762947368199.idtracker@ietfa.amsl.com> To: "acme@ietf.org" From: Yaron Sheffer X-Forwarded-Message-Id: <149263306622.19180.12048305762947368199.idtracker@ietfa.amsl.com> Message-ID: <82c8b97e-37dc-206c-7457-6f711f9640c7@gmail.com> Date: Wed, 19 Apr 2017 23:24:45 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <149263306622.19180.12048305762947368199.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Acme] Fwd: New Version Notification for draft-sheffer-acme-star-00.txt X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 20:24:52 -0000 We just posted a new version of the STAR (formerly LURK/STAR, note the name change) draft. As a reminder: this is a method to use short-term certificates to delegate authority over a domain from a content owner to a CDN. In addition to the high-level architecture, the document now includes the first version of the actual protocol, a simple REST API. Also, discussion of how this draft addresses some of the more difficult requirements posed by the CDNI architecture. We are now working on an implementation. Thanks, Yaron -------- Forwarded Message -------- Subject: New Version Notification for draft-sheffer-acme-star-00.txt Date: Wed, 19 Apr 2017 13:17:46 -0700 From: internet-drafts@ietf.org To: Oscar Gonzalez de Dios , Oscar de Dios , Diego Lopez , Thomas Fossati , Yaron Sheffer A new version of I-D, draft-sheffer-acme-star-00.txt has been successfully submitted by Yaron Sheffer and posted to the IETF repository. Name: draft-sheffer-acme-star Revision: 00 Title: Use of Short-Term, Automatically-Renewed (STAR) Certificates to Delegate Authority over Web Sites Document date: 2017-04-19 Group: Individual Submission Pages: 15 URL: https://www.ietf.org/internet-drafts/draft-sheffer-acme-star-00.txt Status: https://datatracker.ietf.org/doc/draft-sheffer-acme-star/ Htmlized: https://tools.ietf.org/html/draft-sheffer-acme-star-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-sheffer-acme-star-00 Abstract: This memo proposes two mechanisms that work in concert to allow a third party (e.g., a content delivery network) to terminate TLS sessions on behalf of a domain name owner (e.g., a content provider). The proposed mechanisms are: Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Wed Apr 19 21: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 6377A127B52 for ; Wed, 19 Apr 2017 21:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0osGYrMdpMX for ; Wed, 19 Apr 2017 21:44:54 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001: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 CAD4C126DDF for ; Wed, 19 Apr 2017 21:44:53 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id k87so53588460ioi.0 for ; Wed, 19 Apr 2017 21:44:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lCmY2GGbzTVwwGwkRfGD9N7Y7J0t8qMTgl6526JoYhU=; b=JNB8+BG6pRFTSQhxTNGiN66W8HfsIBOZdJ1MpqYgEYt0TQFWsgZnQPqqFh0/dXWH+N E3kAO6lIp95wbD5vZ27zxLf2VIZ0/Eo1xkDgaJpK/kS9j7Ncpapr1gISMmLdEtSVGcgp X6m25ENkSce2UoezniD3j7I7txVmoAZHpIeNFNHCZKEDGIXhTqd2I41A6VLioK9T35Dv U5rAZ70yuKJG8K8z2NL8DJnLo44g1R0nxck3FoQTMDRHXjuHFTH5XQATWhr69NuGW6c/ 2nDcngnm0zekX10q60BP3Rx/luEYpFEsHaiIAOSyKN9CzPQ8cfr5p8p99cwwdE0BWV4e j87g== 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=lCmY2GGbzTVwwGwkRfGD9N7Y7J0t8qMTgl6526JoYhU=; b=PmBh2GeLmSNFinf4Ma2CRXDUIX+jh6XSLHLWg//G/8jF7qcZJrfb81rcCk3Zyq0+iK UBviL9YHr3PQBjcDQ7ZcmTel6pzZW3Um1sZiAhJ37OMcaUXhwLUln2jyoGVrA5zEd82h vRlvV5M2FctgecnBlmogCOT9pjIyJe3EZUwrAHwnM5DcWkhXv40hHpq93T50ni8jMGb7 QCHl+/ufxViHqSOEx45+GNoASRw/i4VEpkhX0d5mqhuftE7FgShmCxtREnSjEmhemw7r i+Tl2AYzTQMRNpb2wS7o2tMaksl07MKrufGJUpRZ/Zjjf1BVjXC/GFEeLP16fEGZmwq3 KXAg== X-Gm-Message-State: AN3rC/7HVNw77T6iiBVoiV3AITqv0I9yO4B+ZDoZSwREsLma2lCsmHKE D6mh42YCFfkqnVhhv+VfJ4TXzS1EBQ== X-Received: by 10.98.215.26 with SMTP id b26mr6286498pfh.162.1492663492829; Wed, 19 Apr 2017 21:44:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.130.129 with HTTP; Wed, 19 Apr 2017 21:44:52 -0700 (PDT) Received: by 10.100.130.129 with HTTP; Wed, 19 Apr 2017 21:44:52 -0700 (PDT) In-Reply-To: <9f046557-fe26-faad-30b3-7f721851cb5b@seantek.com> References: <083b73a4-a199-dc57-e078-bf1bf9c10bd2@seantek.com> <9f046557-fe26-faad-30b3-7f721851cb5b@seantek.com> From: Logan Widick Date: Wed, 19 Apr 2017 23:44:52 -0500 Message-ID: To: Sean Leonard Cc: Richard Barnes , Niklas Keller , ACME WG Content-Type: multipart/alternative; boundary=f403045eb1c64268ed054d91cd31 Archived-At: Subject: Re: [Acme] "Slide 21" follow-up (textual encoding question) PART 2 X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 04:44:56 -0000 --f403045eb1c64268ed054d91cd31 Content-Type: text/plain; charset=UTF-8 On Apr 3, 2017 16:07, "Sean Leonard" wrote: On 4/3/2017 5:54 AM, Logan Widick wrote: I think that having separate URIs to reduce bloat is a good idea. I understand that the client needs to send the CSR as a field in the new-order request payload for security. However, in the server response, could the CSR be a URI that would allow the client to retrieve the CSR that the client submitted in DER format? So, could new-order requests look like: { csr: "base64url(derEncodedCSR)" //rest of fields in new-order here } And the server's order response look like: { csrLink: "[link to DER encoded CSR]" certificate: "[link to DER encoded certificate]" chains: [array of links to chains as suggested by Niklas] //rest of fields in order response here (except for "csr") } The wrinkle with this proposal is that CSRs are likely non-public data. They could contain personally identifiable information in the metadata, or other random stuff. It is undesirable to have a link that has to be maintained for the lifetime of the order history, which could be harvested by search engines or otherwise made public. Typically CAs harvest the public key and discard the rest (after verifying the authenticity of the CSR). Therefore, I am not in favor of URIs for CSR data. Since CAs would harvest data from CSRs and then discard the rest after authenticity checks, and the identifiers would appear elsewhere (in the authorizations), could the "csr" field apply to the new-order request and be absent from the order object? The case for URIs for issued end-entity certificates is half-half. Certificates are public documents, but it's an extra round-trip and you have to save the same amount of state on the client side (i.e., the certificate URI). The case for URI(s) for CA certificates in the validation chain is strongest, since they are unlikely to change and are reused across many customers. Basically "de-duplication". On the other hand, there are business/usability advantages to packaging up "everything you need to run your web server" in one neat package. When certificates are embedded in order objects, won't the order objects get quite large? For consistency, I think the chain links (when retrieved) should be concatenated DER. I am in favor of DER. :) (But less sure about whether links are desirable in the first place.) I could have sworn that when certificate retrieval is done over the wire, CMS (PKCS #7) is an IETF standardized type for blobs of certificates. Oh yeah, here it is: RFC 5280 Section 4.2.2.1 (it's repeated elsewhere): HTTP server implementations accessed via the URI SHOULD specify the media type application/pkix-cert [RFC2585 ] in the content-type header field of the response for a single DER encoded certificate and SHOULD specify the media type application/pkcs7-mime [RFC2797 ] in the content-type header field of the response for "certs-only" CMS messages. For FTP, the name of a file that contains a single DER encoded certificate SHOULD have a suffix of ".cer" [RFC2585 ] and the name of a file that contains a "certs-only" CMS message SHOULD have a suffix of ".p7c" [RFC2797 ]. Consuming clients may use the media type or file extension as a hint to the content, but should not depend solely on the presence of the correct media type or file extension in the server response. Just sayin'... ;-) It is worth pointing out that PKCS #7 / CMS "certs-only", amounts to concatenated DER certificates plus a little bit of goo at the beginning and end (which can be ignored/skipped). Here is a dump of a .p7s file I have lying around using asn1js: SEQUENCE(2 elem) OBJECT IDENTIFIER1.2.840.113549.1.7.2 [0](1 elem) SEQUENCE(5 elem) INTEGER1 SET(0 elem) SEQUENCE(1 elem) OBJECT IDENTIFIER1.2.840.113549.1.7.1 [0](3 elem) SEQUENCE(3 elem) SEQUENCE(3 elem) SEQUENCE(3 elem) SET(0 elem) In this case, the SEQ -> [0] -> SEQ -> [0] has three certificates, which start with SEQUENCE. Rip and go. Finally, here is how you convert from p7s to textual certificates: openssl pkcs7 -inform DER -in yourfile.p7s -print_certs The advantage of the command-line/OpenSSL recipe above, is that you are guaranteed that the output will only be -----BEGIN CERTIFICATE----- things. Non-certificates shall not pass. That already standardized type would be better. On Apr 3, 2017 06:29, "Niklas Keller" wrote: One potential issue I can see with embedding certificates with the currently proposed format directly into orders are alternative chains. Chains usually do not change between orders, so they could be kept with separate URIs for cachability and less bloat in the order response. e.g. "certificate": base64url(derEncodedCertificate), "chains": [ "https://.../chain" , "https://.../alternate-chain" ] Regards, Niklas _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme --f403045eb1c64268ed054d91cd31 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Apr 3, 2017 16:07, "Sean Leonard" <dev+ietf@seantek.com> wrote:
=20 =20 =20
On 4/3/2017 5:54 AM= , Logan Widick wrote:
I think that having separate URIs to reduce bloat is a good idea. I understand that the client needs to send the CSR as a field in the new-order request payload for security. However, in the server response, could the CSR be a URI that would allow the client to retrieve the CSR that the client submitted in DER format? So, could new-order requests look like:=C2=A0

{
csr: "base64url(derEncodedCSR)"
//rest of fields in new-order here
}

And the server's orde= r response look like:
{
csrLink: "[link to D= ER encoded CSR]"
certificate: "[link = to DER encoded certificate]"
chains: [array of links t= o chains as suggested by Niklas]
//rest of fields in order response here (except for "csr")
}

The wrinkle with this proposal is that CSRs are likely non-public data. They could contain personally identifiable information in the metadata, or other random stuff. It is undesirable to have a link that has to be maintained for the lifetime of the order history, which could be harvested by search engines or otherwise made public. Typically CAs harvest the public key and discard the rest (after verifying the authenticity of the CSR). Therefore, I am not in favor of URIs for CSR data.

Since CAs would harvest data from CSR= s and then discard the rest after authenticity checks, and the identifiers = would appear elsewhere (in the authorizations), could the "csr" f= ield apply to the new-order request and be absent from the order object?=C2= =A0


The case for URIs for issued end-entity certificates is half-half. Certificates are public documents, but it's an extra round-trip and you have to save the same amount of state on the client side (i.e., the certificate URI).

The case for URI(s) for CA certificates in the validation chain is strongest, since they are unlikely to change and are reused across many customers. Basically "de-duplication". On the other hand= , there are business/usability advantages to packaging up "everything you need to run your web server" in one neat package.=C2=A0

When certificates are embedded i= n order objects, won't the order objects get quite large?

For consistency, I think the chain links (when retrieved) should be concatenated DER.

I am in favor of DER. :) (But less sure about whether links are desirable in the first place.)

I could have sworn that when certificate retrieval is done over the wire, CMS (PKCS #7) is an IETF standardized type for blobs of certificates. Oh yeah, here it is:
RFC 5280 Section 4.2.2.1 (it's repeated elsewhere):
   HTTP server implementations accessed via the URI SHOULD spec=
ify the
   media type application/pkix-cert [RFC2585] in the co=
ntent-type header
   field of the response for a single DER encoded certificate and SHOULD
   specify the media type application/pkcs7-mime [RFC2797] in the
   content-type header field of the response for "certs-only" CMS
   messages.  For FTP, the name of a file that contains a single DER
   encoded certificate SHOULD have a suffix of ".cer" [RFC2585] and the
   name of a file that contains a "certs-only" CMS message SHOULD=
 have a
   suffix of ".p7c" [RFC2797].  Consuming clients may use the media type
   or file extension as a hint to the content, but should not depend
   solely on the presence of the correct media type or file extension in
   the server response.


Just sayin'... ;-)

It is worth pointing out that PKCS #7 / CMS "certs-only", amo= unts to concatenated DER certificates plus a little bit of goo at the beginning and end (which can be ignored/skipped). Here is a dump of a .p7s file I have lying around using asn1js:

SEQUENCE(2 elem)
OBJECT IDENTIFIER1.2.840.113549.1.7.2=
[0](1 elem)
SEQUENCE(5 elem)
INTEGER1
SET(0 elem)
SEQUENCE(1 elem)
OBJECT IDENTIFIER1.2.840.113549.1.7.1
[0](3 elem)
SEQUENCE(3 elem)
SEQUENCE(3 ele= m)
SEQUENCE(3 ele= m)
SET(0 elem)

In this case, the SEQ -> [0] -> SEQ -> [0] has three certificates, which start with SEQUENCE. Rip and go.

Finally, here is how you convert from p7s to textual certificates:
=C2=A0 openssl pkcs7 -inform DER -in yourfile.p7s -print_certs=

The advantage of the command-line/OpenSSL recipe above, is that you are guaranteed that the output will only be -----BEGIN CERTIFICATE----- things. Non-certificates shall not pass.
<= /blockquote>

That already standardized type would be better.=C2=A0
<= br>

On Apr 3, 2017 06:29, "Niklas Keller" <me@kelunik.com> wrote:
One potential issue I can see with embedding certificates with the currently proposed format directly into orders are alternative chains. Chains usually do not change between orders, so they could be kept with separate URIs for cachability and less bloat in the order response.

e.g.

"certificate": base64url(derEncodedCertifi= cate),
"chains": [
=C2=A0 =C2=A0"https:/= /.../chain",
]

Regards, Niklas

_______________________________________________
Acme mailing list
Acme@iet= f.org
https://www.ietf.org/mailman/listinf= o/acme




--f403045eb1c64268ed054d91cd31-- From nobody Thu Apr 20 09:35: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 5B47C129B08 for ; Thu, 20 Apr 2017 09:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5S-4Ywf8cvul for ; Thu, 20 Apr 2017 09:35:23 -0700 (PDT) Received: from mail-yb0-x22e.google.com (mail-yb0-x22e.google.com [IPv6:2607:f8b0:4002:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DC11129436 for ; Thu, 20 Apr 2017 09:35:23 -0700 (PDT) Received: by mail-yb0-x22e.google.com with SMTP id 6so30744626ybq.2 for ; Thu, 20 Apr 2017 09:35:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=fyZgKPAkKBZF/hfqWURer1aN2met6/+0Dvipz4QIaDc=; b=pr95OIxlN6an+gvDiQdtQP+nntawR1eL67w6/Sq8pg0hJIl7QnlpBIlcccro+x1tyr 5y9odbDL14xGlO+cAXGTKrDIXQhHmGV0wLk1nncFJVgG5gKcDrXbW4eUVohWMYV7ISw7 SebaesTCRevDnDQIXHq7P3Qj5R8A8O9Ko+lT+uxcMCx2/THt3GyjwB67pdHYDPEIMHz7 0YN95DHVRtECA6OfQ9EFSXahaqCU39CFWb0I08aXh0UwkkpwUI8idQto/u8iET/9k8fx EyI3qaIOWs1+qVDLSBCoSkhm7/asGOx80WQdmCiJ36SmlYbNxAHxth8BMoutg8AVx0bC bNCA== 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=fyZgKPAkKBZF/hfqWURer1aN2met6/+0Dvipz4QIaDc=; b=Z5eq5EFCDxaM6OgE6uhEcqYKswCDjtJCqACXdlWgkDxr35hQkBioyWR74Ywt9jZqo2 O3yC7O4kP5Y7AnmnrhREKhm/jSMJfUC8KyyLd6gH4pDs8zQ5UYxuQfq7QA/7NbZcVHKS J3CCm6YfSLW2ofgONSzmUHHyuyJqMaSN4vyBxS6qVq1Ib2SKo/Jl/es+Ir8n8WC7Kh/N kkzgZcEMcjeFB0qoDfy9Rd/VYdsMwcbVL8il5OfwjFtA0FpM5HSRksQV2HosK0WWuFVw QZB8V7Byw+VnRnhXDz9txH9ftgj0AxLLm4VRxjX1vOYYFg7wmH/CCm8R2EcZynyM7+Ye YIzQ== X-Gm-Message-State: AN3rC/4qBYvM0o03ZjZez4EDhf8AUut3eDW0gecr2sbSRkoXhxNOUgLU e1Zr3wsAud0udbV7yzOrs2QdMId6+FvI X-Received: by 10.98.12.72 with SMTP id u69mr8616638pfi.47.1492706121933; Thu, 20 Apr 2017 09:35:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.130.129 with HTTP; Thu, 20 Apr 2017 09:35:21 -0700 (PDT) From: Logan Widick Date: Thu, 20 Apr 2017 11:35:21 -0500 Message-ID: To: ACME WG Content-Type: multipart/alternative; boundary=001a1147750c26ec01054d9bba10 Archived-At: Subject: [Acme] Multiple Accounts with Same Key X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 16:35:26 -0000 --001a1147750c26ec01054d9bba10 Content-Type: text/plain; charset=UTF-8 All, How should a server respond if a client is trying to perform an action that would result in multiple active accounts having the same account key? For example: - Sending a key-change request with a newKey that is already in use by another account - (If https://github.com/ietf-wg-acme/acme/issues/294 is merged into master) Sending a new-account request (that doesn't have the new "recovery" field or has the new field set to false) with a key that is already used by another account Should the server respond with an error code? Allow multiple accounts with the same key to coexist? Do something else? Sincerely, Logan Widick --001a1147750c26ec01054d9bba10 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All,=C2=A0

How should a server respond = if a client is trying to perform an action that would result in multiple ac= tive accounts having the same account key? For example:=C2=A0
  • Sending a key-change request with a newKey that is already in use by a= nother account
  • (If https://github.com/ietf-wg-acme/acme/issues/294=C2=A0is mer= ged into master) Sending a new-account request (that doesn't have the n= ew "recovery" field or has the new field set to false) with a key= that is already used by another account
    • Should the server re= spond with an error code? Allow multiple accounts with the same key to coex= ist? Do something else?=C2=A0

    Sincerely,=C2= =A0

    Logan Widick
    --001a1147750c26ec01054d9bba10-- From nobody Thu Apr 20 13:30: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 688E7131671 for ; Thu, 20 Apr 2017 13:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.088 X-Spam-Level: X-Spam-Status: No, score=0.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=onevmw.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNnzV181iIMt for ; Thu, 20 Apr 2017 13:29:54 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0042.outbound.protection.outlook.com [104.47.33.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12BAA13165E for ; Thu, 20 Apr 2017 13:29:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onevmw.onmicrosoft.com; s=selector1-vmware-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/dPjkEgVGTED+gE7tlBotiX+4fnNl1ARZJaQQdNdwRg=; b=gF0nbTwkMHLLSwuk/IcDEHPWaSgPCmxR/UZQ9lNUPIP94jmK7QlCN/UayUz+uataDLE3X2n5APcO3ku0+TJpVXRjNpaXoOXMSTFgkIpCHOS6LwwGCwrd15gEHSwkW8jF+mU7aF3W5+roJQxVF65n0pzSHFZaHvxwr8jRoMt+h3A= Received: from CY4PR05MB3045.namprd05.prod.outlook.com (10.172.155.135) by CY4PR05MB3045.namprd05.prod.outlook.com (10.172.155.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.6; Thu, 20 Apr 2017 20:29:52 +0000 Received: from CY4PR05MB3045.namprd05.prod.outlook.com ([10.172.155.135]) by CY4PR05MB3045.namprd05.prod.outlook.com ([10.172.155.135]) with mapi id 15.01.1047.008; Thu, 20 Apr 2017 20:29:52 +0000 From: Zach Shepherd To: Logan Widick , ACME WG Thread-Topic: [Acme] Multiple Accounts with Same Key Thread-Index: AQHSufQ7fKKF121iH0yiAnBTV0131KHOtAmz Date: Thu, 20 Apr 2017 20:29:51 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=vmware.com; x-originating-ip: [25.173.128.132] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR05MB3045; 7:siwH6Lark5NmZ3jzJPm3Kuj3ulQh3pLcH/uPXbSnm7nzc4WeFGEKuHkXBfCLlBj/gTun1Zxbfe5/W4Cnyd8zQ51l3Zul3OU85rtKZkk3zN9z1Mjd25DA9uDzafJ49edBMyryJ5ux3QWEuiLDmrSINDYX47sPnzI4ldZXczn0W+MFWMhC9ciBFnBCLlkc7UxQ7UNpbgtQkg5eaECYjAKp5OWqaPzdRr1qS1McZt/N+X33qdrSG4/6xoKcra5SjL1CnRjEV3qjvLItkw1MnzdbJUSKVvzl46tb9MdHbCPmRUpY1ig7T0g4UCOmOujIY3OWhBmzpS5vKQ7XS5LuVlpjqg==; 20:oON5DpFN7scdh71ZxOwGU8+z21Op4knIG6pgnOnxxj2eGAWuLKxGjm6213vUEvo7RpPzfgPHFR2zBfxsVDqWbkoSiVZcLuS/rmU1vdvvshdD4tsybp8Xtn0wVEpcFLDcDYPA3W8MMYHSHxsI3YasuqYG26P/t2g8lqvnkLm4scM= x-ms-office365-filtering-correlation-id: 2b69f90a-4230-459c-9607-08d4882bffa8 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:CY4PR05MB3045; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(10436049006162)(166708455590820); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(6041248)(20161123562025)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(20161123555025)(6072148); SRVR:CY4PR05MB3045; BCL:0; PCL:0; RULEID:; SRVR:CY4PR05MB3045; x-forefront-prvs: 02830F0362 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39410400002)(39850400002)(39450400003)(39400400002)(39840400002)(377454003)(66066001)(8936002)(3846002)(7736002)(7696004)(3280700002)(6606003)(102836003)(15650500001)(6116002)(3660700001)(2950100002)(189998001)(86362001)(74316002)(33656002)(2906002)(7906003)(229853002)(8676002)(2900100001)(122556002)(19627405001)(81166006)(5660300001)(6506006)(53546009)(6436002)(53936002)(606005)(6246003)(77096006)(76176999)(54896002)(39060400002)(38730400002)(236005)(50986999)(54356999)(99286003)(9686003)(55016002)(6306002)(25786009); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR05MB3045; H:CY4PR05MB3045.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR05MB3045C25F4C2EF71D6570D9DAC01B0CY4PR05MB3045namp_" MIME-Version: 1.0 X-OriginatorOrg: vmware.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Apr 2017 20:29:51.7570 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR05MB3045 Archived-At: Subject: Re: [Acme] Multiple Accounts with Same Key X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 20:29:58 -0000 --_000_CY4PR05MB3045C25F4C2EF71D6570D9DAC01B0CY4PR05MB3045namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Given that account recovery is based on key (with or without #294), it seems like allowing multiple a= ccounts to coexist with the same key would be problematic. It also seems like attempting to create a second account with the same key = would almost always indicate user- or client-error. Responding with an error seems best, but no existing error type seems appro= priate. ________________________________ From: Acme on behalf of Logan Widick Sent: Thursday, April 20, 2017 9:35 AM To: ACME WG Subject: [Acme] Multiple Accounts with Same Key All, How should a server respond if a client is trying to perform an action that= would result in multiple active accounts having the same account key? For = example: * Sending a key-change request with a newKey that is already in use by = another account * (If https://github.com/ietf-wg-acme/acme/issues/294 is merged into master) Sending= a new-account request (that doesn't have the new "recovery" field or has t= he new field set to false) with a key that is already used by another accou= nt Should the server respond with an error code? Allow multiple accounts with = the same key to coexist? Do something else? Sincerely, Logan Widick --_000_CY4PR05MB3045C25F4C2EF71D6570D9DAC01B0CY4PR05MB3045namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

    Given that account recovery is based on key (with or without #294), it seems l= ike allowing multiple accounts to coexist with the same key would be proble= matic.


    It also seems like attempting to create a second account with the same k= ey would almost always indicate user- or client-error.


    Responding with an error seems best, but no existing error type seems ap= propriate.


    From: Acme <acme-bounce= s@ietf.org> on behalf of Logan Widick <logan.widick@gmail.com>
    Sent: Thursday, April 20, 2017 9:35 AM
    To: ACME WG
    Subject: [Acme] Multiple Accounts with Same Key
     
    All, 

    How should a server respond if a client is trying to perform an action= that would result in multiple active accounts having the same account key?= For example: 
    • Sending a key-change request with a newKey that is already in use by an= other account
    • (If https://github.com/ietf-wg-acme/acme/issues/294 is merged into mas= ter) Sending a new-account request (that doesn't have the new "recover= y" field or has the new field set to false) with a key that is already= used by another account
    Should the server respond with an error code? Allow multiple accounts = with the same key to coexist? Do something else? 

    Sincerely, 

    Logan Widick
    --_000_CY4PR05MB3045C25F4C2EF71D6570D9DAC01B0CY4PR05MB3045namp_-- From nobody Thu Apr 20 16:02: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 68FBD1293EE for ; Thu, 20 Apr 2017 16:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.71 X-Spam-Level: X-Spam-Status: No, score=-0.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 E6X5zaUI71BA for ; Thu, 20 Apr 2017 16:02:06 -0700 (PDT) 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 473DC128D8B for ; Thu, 20 Apr 2017 16:02:06 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id x184so72051772oia.1 for ; Thu, 20 Apr 2017 16:02:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=c5d53+4jMg2e5CMAL49+7nFtOFkWJhtPNSyouJfW4AA=; b=G39hTBfTuC4wfUFvvZkVhLa3u3jWOajaHq4vAWoBepirPoi6nsUWzB6Z6V31+vlyFp Y+5/dO9EZDHSmsC+IISWZKMERjPFSW8iNHxKKl+RlK2En/23+1pgURQshkjG8wd+8c5k gHBjX48iaDCxE64a/TP7H0ELQcsI1gmAVndxau1dsZoTG6bqpHGw2HBfb6q/NCnlfDkf iR8nG/K2Jy6eVW+Y4vPyWdzltQinwFLNrr1gSfYeAqtxcOJ7otSOnHQ/dO30teqrxk7v ua2iu+P+2FtKKN1Dqk1RN8BGlhLXHEYe0aeCcWWNl7vXvledkAqNmFxZ5ZSbIhrCbZvh Mx2w== 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=c5d53+4jMg2e5CMAL49+7nFtOFkWJhtPNSyouJfW4AA=; b=hhrWH3GJ74R06SJlZin7Jni63qSfhfmG8Tr8R3IdL6ZdCTEOOtlG45XTYT1O4A7iDX rfS5WteztHRCPUwl8NZv7MPMeszAJuTGrpEEh39ikaocikmorBTfeABvcatUy+NJJcYj s9LzfC98KVv5pTXYdEKeoWKIISo/LfSHJ4Ixz4woGJrN80fCtNBeIKqNhI3kISf7tovq Uz69nNqfRknvRobslaR4E66DXseJZwDzpKYMNJf+YDLgg+MrTg4cEFdVDKH1+8L/44JU 6lMaFea6ZRJ4+rr7BkXJZLtLrzekQptur3sSLNFUzuV+rHWb/RbWWo+IJEpHGZpOxg8N bKRw== X-Gm-Message-State: AN3rC/6FECqhErrCLwcC0rRc9iPzPzRgEoJyEyRNucVuJ5ZVly2msckM DzFOF9Y6w4Wq3I/SaxPMdaFzM7xWzQ== X-Received: by 10.84.196.100 with SMTP id k91mr12353049pld.165.1492729325245; Thu, 20 Apr 2017 16:02:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.130.129 with HTTP; Thu, 20 Apr 2017 16:02:04 -0700 (PDT) In-Reply-To: References: From: Logan Widick Date: Thu, 20 Apr 2017 18:02:04 -0500 Message-ID: To: Zach Shepherd Cc: ACME WG Content-Type: multipart/alternative; boundary=94eb2c18978a2d5d29054da1216f Archived-At: Subject: Re: [Acme] Multiple Accounts with Same Key X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 23:02:08 -0000 --94eb2c18978a2d5d29054da1216f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable So there would need to be a new error type (possibly named something like "accountKeyCollision")? If so, what would be the right HTTP code? 400 (Bad Request)? Or something else? On receiving the error, should the client either generate a different key to change to or use the account URL recovery mechanism? Would the desired response change if the key clash involved a deactivated account (whether by client or CA) instead of an active one? On Thu, Apr 20, 2017 at 3:29 PM, Zach Shepherd wrote= : > Given that account recovery is based on key (with or without #294 > ), it seems like > allowing multiple accounts to coexist with the same key would be > problematic. > > > It also seems like attempting to create a second account with the same ke= y > would almost always indicate user- or client-error. > > Responding with an error seems best, but no existing error type seems > appropriate. > > ------------------------------ > *From:* Acme on behalf of Logan Widick < > logan.widick@gmail.com> > *Sent:* Thursday, April 20, 2017 9:35 AM > *To:* ACME WG > *Subject:* [Acme] Multiple Accounts with Same Key > > All, > > How should a server respond if a client is trying to perform an action > that would result in multiple active accounts having the same account key= ? > For example: > > - Sending a key-change request with a newKey that is already in use by > another account > - (If https://github.com/ietf-wg-acme/acme/issues/294 > is > merged into master) Sending a new-account request (that doesn't have t= he > new "recovery" field or has the new field set to false) with a key tha= t is > already used by another account > > Should the server respond with an error code? Allow multiple accounts wit= h > the same key to coexist? Do something else? > > Sincerely, > > Logan Widick > --94eb2c18978a2d5d29054da1216f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    So there would need to be a new error type (possibly named= something like "accountKeyCollision")?=C2=A0

    = If so, what would be the right HTTP code? 400 (Bad Request)? Or something e= lse?=C2=A0

    On receiving the error, should the clie= nt either generate a different key to change to or use the account URL reco= very mechanism?

    Would the desired response change = if the key clash involved a deactivated account (whether by client or CA) i= nstead of an active one?=C2=A0

    On Thu, Apr 20, 2017 at 3:29 PM, Zach Shepherd <shepherdz@vmware.com> wrote:

    Given that account recovery is based on key (with or without=C2=A0#29= 4), it seems like allowing multiple accounts to coexist with the same k= ey would be problematic.


    It also seems like attempting to create a second account with the same k= ey would almost always indicate user- or client-error.


    Responding with an error seems best, but no existing error type seems ap= propriate.


    From:= Acme <acme-b= ounces@ietf.org> on behalf of Logan Widick <logan.widick@gmail.com>
    Sent: Thursday, April 20, 2017 9:35 AM
    To: ACME WG
    Subject: [Acme] Multiple Accounts with Same Key
    =C2=A0
    All,=C2=A0

    How should a server respond if a client is trying to perform an action= that would result in multiple active accounts having the same account key?= For example:=C2=A0
    • Sending a key-change request with a newKey that is already in use by an= other account
    • (If https://github.com/ietf-wg-acme/acme/issues/294=C2=A0is merged int= o master) Sending a new-account request (that doesn't have the new &quo= t;recovery" field or has the new field set to false) with a key that i= s already used by another account
    Should the server respond with an error code? Allow multiple accounts = with the same key to coexist? Do something else?=C2=A0

    Sincerely,=C2=A0

    Logan Widick

    --94eb2c18978a2d5d29054da1216f-- From nobody Fri Apr 21 11:01:35 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77ADC129B22 for ; Fri, 21 Apr 2017 11:01:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hJTseVEzRk5M for ; Fri, 21 Apr 2017 11:01:32 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAE26128854 for ; Fri, 21 Apr 2017 11:01:31 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v3LHur2P016126 for ; Fri, 21 Apr 2017 19:01:29 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : mime-version; s=jan2016.eng; bh=T2Fxn3uOhIoMyKJ+6sctgEXUcz8Vsr58HVU4rbK0Efs=; b=S2gwWvc8HeQDiUiYNBsz8yBZnh6mN9JvKes6Nm5yf1giOpp69pA+kc35o3XUJ0TGOce4 xw0svueCQuuXDP+g+RcMVBR8ZV1US4lzhg1gDklQqHofwLMw3yaL1c5QXgHHIYsoYm6k C6/iV1oQGSdT0j44ZiZ6Uwz8v4Ou4OqmhgY8hNOA18hE6MKWIcAUPAseIbJmL3tAVOYX Y2EvlWQB2kWsFccIi2Nzl7TLV19qkdmn5v2fImH2b+xgD0NW/FUhOMYEa4RtQiOgBAMu 3AAmxeBvjfRSWH9J7kh7syqPMXLbxzMhTAH1TJAVJqVsEE+b5nixet3LzRl7cyugs9Qr Mg== Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 29xyftfe36-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 21 Apr 2017 19:01:28 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v3LI1Jxt019068 for ; Fri, 21 Apr 2017 14:01:28 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint1.akamai.com with ESMTP id 29wqn5v6sn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Fri, 21 Apr 2017 14:01:27 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 21 Apr 2017 11:01:27 -0700 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Fri, 21 Apr 2017 14:01:27 -0400 From: "Salz, Rich" To: ACME WG Thread-Topic: Futures Thread-Index: AdK6yP0s20BvTAD9Q3ePlESvzSMwkg== Date: Fri, 21 Apr 2017 18:01:26 +0000 Message-ID: <878ad4965b254e5aa7e58e8c812d1df1@usma1ex-dag1mb1.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.34.103] Content-Type: multipart/alternative; boundary="_000_878ad4965b254e5aa7e58e8c812d1df1usma1exdag1mb1msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-21_14:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1704210318 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-21_14:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1704210317 Archived-At: Subject: [Acme] Futures X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 18:01:33 -0000 --_000_878ad4965b254e5aa7e58e8c812d1df1usma1exdag1mb1msgcorpak_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Having talked with the authors, we expect the base ACME draft to be ready f= or WGLC at least a month before the next IETF meeting. The CAA document, which we adopted, is very short and straightforward and s= eems like it can be handled easily over email. Does anyone have any new work items that would be ready to discuss in July?= Any rechartering discussion that looks promising? If so, please post to = the mailing list soon. Thanks, Rich and Ted's Excellent ACME Adventure -- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richsalz@jabber.at Twitter: RichSalz --_000_878ad4965b254e5aa7e58e8c812d1df1usma1exdag1mb1msgcorpak_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

    Having talked with the authors, we expect the base A= CME draft to be ready for WGLC at least a month before the next IETF meetin= g.

     

    The CAA document, which we adopted, is very short an= d straightforward and seems like it can be handled easily over email.<= /o:p>

     

    Does anyone have any new work items that would be re= ady to discuss in July?  Any rechartering discussion that looks promis= ing?  If so, please post to the mailing list soon.

     

    Thanks,

    Rich and Ted’s Excellent ACME Adventure

     

     

    -- 

    Senior Architect, Akamai Technologies

    Member, OpenSSL Dev Team

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

     

    --_000_878ad4965b254e5aa7e58e8c812d1df1usma1exdag1mb1msgcorpak_-- From nobody Sat Apr 22 13:44: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 D2A7212954E for ; Sat, 22 Apr 2017 13:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9vOemWVz3Fh for ; Sat, 22 Apr 2017 13:44:18 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0126.outbound.protection.outlook.com [104.47.0.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 989A612953B for ; Sat, 22 Apr 2017 13:44:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=4zHqhdWEIxV+YNbloUsVqzuGYtmFhYkXHgDSk8yob6Q=; b=iJEvtlaM50o1M2Yr5P47dboJx+ayMoeOKVm9T3wjT5MfIrDL6nO28fQOKDOJEwmZJgty7I4kTmZGDC5nsoY7B+N5iC5ExAXVTDTJPHcoOVVmdr0P7k9+pCS89fQUMIizhkF2Jv1VBI8kcUpFrKZk1XpvBo7mof/qiDwHWNs0jb8= Received: from VI1PR07MB1102.eurprd07.prod.outlook.com (10.163.168.26) by VI1PR07MB1101.eurprd07.prod.outlook.com (10.163.168.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.6; Sat, 22 Apr 2017 20:44:14 +0000 Received: from VI1PR07MB1102.eurprd07.prod.outlook.com ([10.163.168.26]) by VI1PR07MB1102.eurprd07.prod.outlook.com ([10.163.168.26]) with mapi id 15.01.1047.008; Sat, 22 Apr 2017 20:44:14 +0000 From: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" To: "Salz, Rich" , ACME WG CC: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" Thread-Topic: [Acme] Futures Thread-Index: AQHSu6kzLCTcKkAFskSURo93jsp44g== Date: Sat, 22 Apr 2017 20:44:13 +0000 Message-ID: <6B2EB1DB-3B45-4A51-9167-86D5BAE8BF1F@on.nokia.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: akamai.com; dkim=none (message not signed) header.d=none;akamai.com; dmarc=none action=none header.from=nokia.com; x-originating-ip: [92.20.252.102] x-microsoft-exchange-diagnostics: 1; VI1PR07MB1101; 7:uF5aOl8Jsvkz9jveXm7UuT4yuS0GUp/FowJX2Ff3u+nQElWazM8+h3/+aSjvFeiRRE+UToDs/IjBRUO2HWF0D1G/WhOH3cZaLVlEhZOpruv4kU3gtScRFQUmcHsgt6qg6LfB+utSqWLaxO+nTA0EtS4/TDXkMkOe4neFNc3+BcrKo80JyEdbXX9Q9FPerZo2HrAvpir5RTLiUsYjlAlK+DM+Y5yeg3Db6yAy2X1ED6NSKMB6vqRjpmbNS4HKoPZIuOUoK5+huq5Eo+ptI4sxrMTmBb+Zfs/2/kxiWUsDFPV3KEGBGxa1Y/cFpVl2eCj58IWMd5OJVDl7lS3cND8KRA== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39860400002)(39450400003)(39400400002)(39840400002)(39850400002)(24454002)(6512007)(6486002)(33656002)(6506006)(38730400002)(77096006)(6436002)(6306002)(122556002)(83716003)(102836003)(99286003)(229853002)(6116002)(107886003)(2906002)(25786009)(3846002)(66066001)(53546009)(189998001)(53936002)(3660700001)(50986999)(6246003)(2900100001)(8676002)(305945005)(54356999)(8936002)(3280700002)(4001350100001)(83506001)(4326008)(81166006)(5660300001)(82746002)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1101; H:VI1PR07MB1102.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-ms-office365-filtering-correlation-id: 046478e8-4e36-46b2-8339-08d489c05663 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:VI1PR07MB1101; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123560025)(20161123562025)(20161123564025)(20161123555025)(6072148); SRVR:VI1PR07MB1101; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1101; x-forefront-prvs: 0285201563 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Apr 2017 20:44:13.9428 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1101 Archived-At: Subject: Re: [Acme] Futures X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Apr 2017 20:44:20 -0000 SGkgUmljaCwNCg0KT24gMjEvMDQvMjAxNyAxOTowMSwgIkFjbWUgb24gYmVoYWxmIG9mIFNhbHos IFJpY2giIDxhY21lLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIHJzYWx6QGFrYW1haS5j b20+IHdyb3RlOg0KPiBEb2VzIGFueW9uZSBoYXZlIGFueSBuZXcgd29yayBpdGVtcyB0aGF0IHdv dWxkIGJlIHJlYWR5IHRvIGRpc2N1c3MgaW4gSnVseT/CoA0KPiBBbnkgcmVjaGFydGVyaW5nIGRp c2N1c3Npb24gdGhhdCBsb29rcyBwcm9taXNpbmc/wqAgSWYgc28sIHBsZWFzZSBwb3N0IHRvIHRo ZQ0KPiBtYWlsaW5nIGxpc3Qgc29vbi4NCg0KV2UgaGF2ZSByZWNlbnRseSBwdWJsaXNoZWQgWzFd IGFuZCBzdGFydGVkIGltcGxlbWVudGluZyBpdC4NCg0KVGhlIHBsYW4gaXMgdG8gZ2V0IHRoZSBj b2RlIHJ1bm5pbmcgQVNBUCAoc3VyZWx5IGJlZm9yZSBQcmFndWUpIGFuZCwgaWYgdGhlDQpleHBl cmltZW50IGlzIHNhdGlzZmFjdG9yeSwgYXNrIGZvciBhZG9wdGlvbi4NCg0KQ2hlZXJzLCB0DQoN ClsxXSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2hlZmZlci1hY21lLXN0YXIt MDANCg0KDQo= From nobody Tue Apr 25 11:15: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 09AB8131755 for ; Tue, 25 Apr 2017 11:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F_UxJFP9iUIh for ; Tue, 25 Apr 2017 11:14:57 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDB13127978 for ; Tue, 25 Apr 2017 11:14:57 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v3PI73vN011278; Tue, 25 Apr 2017 19:14:55 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=4llMdo/sgc7Pz9hXcM4O7A6dwPyGm3CI/bqSQZ0qH9s=; b=IVcR0NNdznSWhGsMss6mbRDB3xuQEzqRRtz3aguJJ2jJBuFbq775NXBn7uWVoJhD3pAw ty1H4uyY9MmrGlp+H7NM8HQJ7wKLrNgBHQfCFSpy51rvQuYum9ykZZO7BC2P25vS7ABD mtQTwfU35ecyj85iGpZJfgyiIk6V14IiWLeLfACpDdKf1zOhUO+TarDd46I2mBlOm1Nz WQilB9vdKOaWIOZ6NJkwSgs5NTvsFQk36pWH784JoqiR1EeDbgQIj7MFpjEeTiBOfnzG QqCwfP8Wc9DeIqDKur6OT1qKIgnshJcPyhChUoW/X9QC/klxJriRmkqof3sdi1ZhvHdz Uw== Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2a28jh1h97-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 25 Apr 2017 19:14:54 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v3PIB5Sj003219; Tue, 25 Apr 2017 14:14:54 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint1.akamai.com with ESMTP id 2a02gvn09c-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 25 Apr 2017 14:14:54 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 25 Apr 2017 14:14:53 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Tue, 25 Apr 2017 14:14:53 -0400 From: "Salz, Rich" To: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" , ACME WG Thread-Topic: [Acme] Futures Thread-Index: AQHSu6kz20BvTAD9Q3ePlESvzSMwkqHWZ0ew Date: Tue, 25 Apr 2017 18:14:52 +0000 Message-ID: <6dad1e1718804b56982341b814da2563@usma1ex-dag1mb1.msg.corp.akamai.com> References: <6B2EB1DB-3B45-4A51-9167-86D5BAE8BF1F@on.nokia.com> In-Reply-To: <6B2EB1DB-3B45-4A51-9167-86D5BAE8BF1F@on.nokia.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.37.9] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-25_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1704250322 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-25_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1704250322 Archived-At: Subject: Re: [Acme] Futures X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 18:15:00 -0000 PiBXZSBoYXZlIHJlY2VudGx5IHB1Ymxpc2hlZCBbMV0gYW5kIHN0YXJ0ZWQgaW1wbGVtZW50aW5n IGl0Lg0KPiANCj4gVGhlIHBsYW4gaXMgdG8gZ2V0IHRoZSBjb2RlIHJ1bm5pbmcgQVNBUCAoc3Vy ZWx5IGJlZm9yZSBQcmFndWUpIGFuZCwgaWYgdGhlDQo+IGV4cGVyaW1lbnQgaXMgc2F0aXNmYWN0 b3J5LCBhc2sgZm9yIGFkb3B0aW9uLg0KPiANCj4gQ2hlZXJzLCB0DQo+IA0KPiBbMV0gaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNoZWZmZXItYWNtZS1zdGFyLTAwDQoNClNpbmNl IHRoZSBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LXJlc2Nvcmxh LXRscy1zdWJjZXJ0cyBpcyBiZWluZyB0YWtlbiB1cCBpbiBUTFMsIGl0IG1pZ2h0IG1ha2Ugc2Vu c2UgZm9yIHRoaXMgZHJhZnQgdG8gZ28gdGhlcmUsIHRvby4gIEJ1dCB3ZSBjYW4gc2VlLg0K From nobody Tue Apr 25 11:54: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 21E6413177D for ; Tue, 25 Apr 2017 11:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iBqKDRibOTNN for ; Tue, 25 Apr 2017 11:54:15 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1195F1316FE for ; Tue, 25 Apr 2017 11:54:10 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id u75so55947649qka.3 for ; Tue, 25 Apr 2017 11:54:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gc+Z27aE57H0Q0Ac1Io2V9WrxasMrYp9k/E3qN53l/E=; b=JXd0JEDQKYIrxryzEh2dKLQ/UlFAywTtBJE/yFW+kqiL/HO7E/9oUPE6RuoE7vkrjL JT1JntNmJRv+7zsAiZIZFSecPyZQDbe+HtXI79wZ7mFz/ZgMN4c2HBU1QrbMQEPCGoNP FW9fEiozO0roipBg0sIvN/A3kfy0S/kN6Gu3wLNxhmpghh0hHxjUGujfkrZf49LFTY13 USh66r/wXM0dvSuRWhT1y9Bx2/WDtOGjBZcGPWeEOsHQ12o4Xrbvuqy96TGcif94p9Gu oXDnj6mQ4uH9LGSoFh8tUziIFkmnNaB7Ut6xVjrBdezqC5YUKXSYfj3H5+FVCFd3Nob6 gQMQ== 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=gc+Z27aE57H0Q0Ac1Io2V9WrxasMrYp9k/E3qN53l/E=; b=LVa0dcDN3MOQlbPHWWcpIP1HUxZb1AT/Z6F2e034Bx3NM/zftLasQyUbDBgH4UxDzm Fxzjy1UnlKVTGU2Pfnd2n820sXSbnT4P6JcTMK57Ey2LTr1aZeygWi8HFPjPZVEK7j4F utBQ11fBv9srPUl+Z+x0ReK6s3G048jvYFSaWA1HQKa+bPdBebxGIEMbM6dbSeITjUDb OrJco0ag1onROc6WcyIT9qT+7OAP4WW108u5ENvBfD3YVurIOTdWvcV/voWKq7rqIhDn H7UdxVwr5ZA1JhQUN68fCvHRL9L1PeBcKFjt3bSxM76tegiRZtSxX+ZiqsTZQUOTZKwX 3y3Q== X-Gm-Message-State: AN3rC/64l5myzfn5BHpwA1GP6l+jLQ/9mG2zgAUm+fs0e6K8gNGk85tS daBRI6C0qdizbwfBw/aTBcgHRS/OEA== X-Received: by 10.55.200.218 with SMTP id t87mr24431040qkl.261.1493146449107; Tue, 25 Apr 2017 11:54:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.86.102 with HTTP; Tue, 25 Apr 2017 11:54:08 -0700 (PDT) In-Reply-To: <878ad4965b254e5aa7e58e8c812d1df1@usma1ex-dag1mb1.msg.corp.akamai.com> References: <878ad4965b254e5aa7e58e8c812d1df1@usma1ex-dag1mb1.msg.corp.akamai.com> From: Mary Barnes Date: Tue, 25 Apr 2017 13:54:08 -0500 Message-ID: To: "Salz, Rich" Cc: ACME WG , Christopher Wendt Content-Type: multipart/alternative; boundary=001a1141bb0ab2672e054e023f85 Archived-At: Subject: Re: [Acme] Futures X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 18:54:17 -0000 --001a1141bb0ab2672e054e023f85 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable So we submitted a draft to define a new challenge type to support the ATIS/SIP Forum NNI task group (SHAKEN) requirements, which are based on using protocols defined in STIR: https://datatracker.ietf.org/doc/draft-barnes-acme-service-provider/ It's not clear to me this would need to be a WG document to progress, but ideally we want this published as people are implementing it. Regards, Mary. On Fri, Apr 21, 2017 at 1:01 PM, Salz, Rich wrote: > Having talked with the authors, we expect the base ACME draft to be ready > for WGLC at least a month before the next IETF meeting. > > > > The CAA document, which we adopted, is very short and straightforward and > seems like it can be handled easily over email. > > > > Does anyone have any new work items that would be ready to discuss in > July? Any rechartering discussion that looks promising? If so, please > post to the mailing list soon. > > > > Thanks, > > Rich and Ted=E2=80=99s Excellent ACME Adventure > > > > > > -- > > Senior Architect, Akamai Technologies > > Member, OpenSSL Dev Team > > IM: richsalz@jabber.at Twitter: RichSalz > > > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > > --001a1141bb0ab2672e054e023f85 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    So we submitted a draft to define a new challenge type to = support the ATIS/SIP Forum NNI task group (SHAKEN) requirements, which are = based on using protocols defined in STIR:

    <= div>It's not clear to me this would need to be a WG document to progres= s, but ideally we want this published as people are implementing it.
    <= div>
    Regards,
    Mary.=C2=A0

    On Fri, Apr 21, 2017 at 1:01 PM= , Salz, Rich <rsalz@akamai.com> wrote:

    Having talked with the authors, we expect the base A= CME draft to be ready for WGLC at least a month before the next IETF meetin= g.

    =C2=A0

    The CAA document, which we adopted, is very short an= d straightforward and seems like it can be handled easily over email.

    =C2=A0

    Does anyone have any new work items that would be re= ady to discuss in July?=C2=A0 Any rechartering discussion that looks promis= ing?=C2=A0 If so, please post to the mailing list soon.

    =C2=A0

    Thanks,

    Rich and Ted=E2=80=99s Excellent ACME Adventure

    <= span class=3D"HOEnZb">

    =C2=A0

    =C2=A0

    --=C2=A0

    Senior Architect, Akamai Technologies<= /p>

    Member, OpenSSL Dev Team

    IM: richsalz@jabber.at Twitter: RichSalz

    =C2=A0


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


    --001a1141bb0ab2672e054e023f85-- From nobody Tue Apr 25 12:24: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 5143412EBC6 for ; Tue, 25 Apr 2017 12:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kAFIgRq9y2d2 for ; Tue, 25 Apr 2017 12:24:43 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BD3F124D68 for ; Tue, 25 Apr 2017 12:24:43 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v3PJNAac025169; Tue, 25 Apr 2017 20:24:36 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=3viiXoWCgTYF0ojRPvi0ndS0/sGCo34TV+EKvo5nqlo=; b=TPBMNegjxiVEtWbnUP9mFTo8VCQzDyoLBpjhJh3QkGZ8xEdgX9S4sXnZIhVlTWVnUS1V tx0K51B/g/eHR9sD0nXnFz8nFQOwR81YAs0DrVcg3RDG0jn50qeX9hWH/t6UaH5XidLd 1UrQlInOo1TME+31IXZXAiToIeW8+dPCa6v3jwSyvkH0oX4YOhbm++xG05IUliXhnZ4P U/ha0w949fmVmQhR0lVhziwJWgE1zTVHTS1/4nCT26VCiFpPDucK53YtcLebQZF0mRDG NtEMkbK74I9+gIrMzLhTDtgzreQtpEDp3mxoLhyVYJ6g/9eEV7NAYVc279Kn+dCxFoDs bA== Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2a28jh21ua-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 25 Apr 2017 20:24:36 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v3PJL3X2011794; Tue, 25 Apr 2017 15:24:35 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint1.akamai.com with ESMTP id 2a02gvn4np-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 25 Apr 2017 15:24:35 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 25 Apr 2017 15:24:34 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Tue, 25 Apr 2017 15:24:34 -0400 From: "Salz, Rich" To: Mary Barnes CC: ACME WG , Christopher Wendt Thread-Topic: [Acme] Futures Thread-Index: AdK6yP0s20BvTAD9Q3ePlESvzSMwkgDTdtwAAAdn7SA= Date: Tue, 25 Apr 2017 19:24:33 +0000 Message-ID: References: <878ad4965b254e5aa7e58e8c812d1df1@usma1ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.37.9] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-25_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1704250338 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-25_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1704250338 Archived-At: Subject: Re: [Acme] Futures X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 19:24:45 -0000 PiBTbyB3ZSBzdWJtaXR0ZWQgYSBkcmFmdCB0byBkZWZpbmUgYSBuZXcgY2hhbGxlbmdlIHR5cGUg dG8gc3VwcG9ydCB0aGUgQVRJUy9TSVAgRm9ydW0gTk5JIHRhc2sgZ3JvdXAgKFNIQUtFTikgcmVx dWlyZW1lbnRzLCB3aGljaCBhcmUgYmFzZWQgb24gdXNpbmcgcHJvdG9jb2xzIGRlZmluZWQgaW4g U1RJUjoNCg0KV291bGQgaXQgbWFrZSBzZW5zZSB0byBtb3ZlIHRoaXMgZm9yd2FyZCBpbiBTVElS PyAgSSBhc2sgYmVjYXVzZSBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1w ZXRlcnNvbi1zdGlyLWNlcnRpZmljYXRlcy1zaG9ydGxpdmVkLyBub3cgbGl2ZXMgdGhlcmUgYW5k IGl0IHNlZW1zIHRoYXQgdGhlIHR3byBzaG91bGQgYmUgdG9nZXRoZXIuDQoNCi0twqAgDQpTZW5p b3IgQXJjaGl0ZWN0LCBBa2FtYWkgVGVjaG5vbG9naWVzDQpNZW1iZXIsIE9wZW5TU0wgRGV2IFRl YW0NCklNOiBtYWlsdG86cmljaHNhbHpAamFiYmVyLmF0IFR3aXR0ZXI6IFJpY2hTYWx6DQoNCg== From nobody Tue Apr 25 12:54: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 83F6512943E for ; Tue, 25 Apr 2017 12:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2MbfXLinzoG for ; Tue, 25 Apr 2017 12:54:45 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F28DA12949E for ; Tue, 25 Apr 2017 12:54:44 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v3PJqVvo004319; Tue, 25 Apr 2017 20:54:38 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=tJha4v9qgMJfwDS6hZFChdRiQN02dTMY8LFR6Km3ixo=; b=Xujqo8EDB7KNho6wLlPRLUcina5M7IXBgUcE1da1/RdPYE0WNMnwrSymEBPtRt+jcFwg R5pXbDqDh1qzNxioTyGE27htrBHgcFnwaQDYjhmQ1q+vMCbAlOSZeqm0fw6NSUCjjqZA t3queyiKL+adXSAQEcJRbFE20F/vWi6XJcl9p8igbbtcRWqsJCGMdGxNqbU8eTn7WRsi shsQ9cWmZaNisekAAY/RKLpwGcqdTPlOh/QtAdLFXJBjmu8pCNk4BHwL93V3vqb8xc3u JlMY0Q6Lbic7MBM2FH8/I/6rnu65WA5MVlCgh6UrD7kwkxJtsPy/ky3OHTpWpFQYyF5M JA== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 2a22q1e52k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 25 Apr 2017 20:54:38 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v3PJobfR006604; Tue, 25 Apr 2017 15:54:37 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint2.akamai.com with ESMTP id 2a02guw73d-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 25 Apr 2017 15:54:37 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 25 Apr 2017 15:54:36 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Tue, 25 Apr 2017 15:54:35 -0400 From: "Salz, Rich" To: Mary Barnes CC: ACME WG , Christopher Wendt Thread-Topic: [Acme] Futures Thread-Index: AdK6yP0s20BvTAD9Q3ePlESvzSMwkgDTdtwAAAdn7SAADbwCAA== Date: Tue, 25 Apr 2017 19:54:35 +0000 Message-ID: References: <878ad4965b254e5aa7e58e8c812d1df1@usma1ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.37.9] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-25_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1704250345 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-25_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1704250346 Archived-At: Subject: Re: [Acme] Futures X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 19:54:46 -0000 PiA+IFNvIHdlIHN1Ym1pdHRlZCBhIGRyYWZ0IHRvIGRlZmluZSBhIG5ldyBjaGFsbGVuZ2UgdHlw ZSB0byBzdXBwb3J0IHRoZQ0KPiA+IEFUSVMvU0lQIEZvcnVtIE5OSSB0YXNrIGdyb3VwIChTSEFL RU4pIHJlcXVpcmVtZW50cywgd2hpY2ggYXJlIGJhc2VkIG9uDQo+ID4gdXNpbmcgcHJvdG9jb2xz IGRlZmluZWQgaW4gU1RJUjoNCg0KPiBXb3VsZCBpdCBtYWtlIHNlbnNlIHRvIG1vdmUgdGhpcyBm b3J3YXJkIGluIFNUSVI/DQoNCkFmdGVyIHNvbWUgb2ZmLWxpbmUgZW1haWwgY2hhdCwgSSB3YXMg d3JvbmcuICBBQ01FIGlzIHRoZSBtb3N0IHJlYXNvbmFibGUgcGxhY2UgZm9yIHRoaXMuDQoNClNv IG5ldyBxdWVzdGlvbi4gIFNvIGZhciBpdCBzZWVtcyB1bmxpa2VseSB3ZSdsbCBtZWV0IGluIFBy YWd1ZS4gIEJ1dCB3b3VsZCB5b3UgYmUgd2lsbGluZyB0byB0YWxrIGFib3V0IHRoaXMgaWYgd2Ug ZG8/ICBTaG91bGQgd2UgbWVldCBzbyB0aGF0IHdlIGNhbiB0YWxrIGFib3V0IGl0IChhbmQgQ0FB IGFuZCBhbnkgb3RoZXIgdGhpbmdzIHRoYXQgY29tZSB1cD8pDQoNCi0tICANClNlbmlvciBBcmNo aXRlY3QsIEFrYW1haSBUZWNobm9sb2dpZXMNCk1lbWJlciwgT3BlblNTTCBEZXYgVGVhbQ0KSU06 IHJpY2hzYWx6QGphYmJlci5hdCBUd2l0dGVyOiBSaWNoU2Fseg0K From nobody Wed Apr 26 11:09:52 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB433131525 for ; Wed, 26 Apr 2017 11:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fqK9Z9aI3-GA for ; Wed, 26 Apr 2017 11:09:47 -0700 (PDT) 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 42C08129459 for ; Wed, 26 Apr 2017 11:09:47 -0700 (PDT) Received: by mail-pf0-x230.google.com with SMTP id c198so3695606pfc.1 for ; Wed, 26 Apr 2017 11:09:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=4NABpmkLv2y70jvyS2+Ky8ZvV6eFpAF0Tgg00rhGXLI=; b=T5ujv7K10OyqqMMxMrxOswLuGC77MjKXyvegtLWwKKGx2u2mo29x4nv1MPFZFJBHtZ K0+9JWmxDlU2mN0mZcSvUiNfD0b5B86uGwndxvXmro9JHhxU1JtyJxe2bi3nVl/hcJk4 RkHCzBInGegPzF+hlUIsfjt6x0P5cxDIw7SccRw62x9gMrU5XglK4XCbstMQv1XcSkLR pm4RENZWJChag81pefgQnQ0sm5ZMoSolM9Df5dXZdj5yJEGvEt23rTA8mlGk2+7+oYgj M1B6vCVig2Uw02DcZHX2Q+d+NoFhqUU02xIffAuLDx6p0vEawlNT3BqlfclCUPBTtTMZ ORkg== 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=4NABpmkLv2y70jvyS2+Ky8ZvV6eFpAF0Tgg00rhGXLI=; b=gIXHEoqSLxB+pk6sZxamAczTvG3YskAQG6xJC8T+HFqbxLNo1P4xZ1kZYZp6yTLvp1 +etqXTqMWdk+WiJRK+c6scXLS3sVuqgEL3QEDwUabH0e17hpUPZd7lunUfIFe0mNzTWK DLHpS15ZEBUr//42QYLACSgsQmNOd38p8CmgR2y6OA9wG2mNQ5qVHTQxKlZM9GxFVnQs q9NhofCmGrNJ1zukN6L27vppZdxtf4z1lgMZgdMIfppjGBdmuNQ1z9GMaXfVe85SazlX CQlMxAXYnq975jjkntUGwI5OLVqGCIZIscX3Z5IOXkGL8qDjozKpt5qWRw+cYrnawDuC RiPw== X-Gm-Message-State: AN3rC/4hElVVE4YeEy7X+AUwxGSHsv18hSjNsKzZSYIvOa1ZdpHmNGoZ uJHBDcCFeoj1KWLCJNy0leuzFBSY+A== X-Received: by 10.84.254.4 with SMTP id b4mr1508920plm.64.1493230186452; Wed, 26 Apr 2017 11:09:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.157.133 with HTTP; Wed, 26 Apr 2017 11:09:46 -0700 (PDT) From: Logan Widick Date: Wed, 26 Apr 2017 13:09:46 -0500 Message-ID: To: ACME WG Content-Type: multipart/alternative; boundary=f403045ffcfed4dbcc054e15be62 Archived-At: Subject: [Acme] "Slide 16" ("up" Link Relation) Follow Up from IETF 98 X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 18:09:49 -0000 --f403045ffcfed4dbcc054e15be62 Content-Type: text/plain; charset=UTF-8 According to the draft minutes, as of the end of IETF 98, the plan was to eliminate the "up" link relation from authorization to order since an authorization can belong to multiple orders and nobody seemed to rely on this relation. However, I still see this "up" relation on GitHub. Is the plan still to remove that "up" relation, has the plan changed, or is the plan to wait and see if anyone uses the relation first? As for the "up" link relation from challenge to authorization (not mentioned on slides), this could encounter a similar problem. As a simple example to illustrate the potential problem, assume a server issues an order with two authorizations: one authorization for (http-01 or dns-01), and another authorization for (tls-sni-02 or dns-01). To prevent the client having to complete the same challenge twice, assume that the server used the same dns-01 challenge instance for both authorizations. For the common dns-01 challenge, where does the "up" relation point to? This could become a more significant issue as new identifiers, challenges, etc. are added in the future. How should this be addressed? Sincerely, Logan Widick --f403045ffcfed4dbcc054e15be62 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    According to the draft minutes, as of the end of IETF 98, = the plan was to eliminate the "up" link relation from authorizati= on to order since an authorization can belong to multiple orders and nobody= seemed to rely on this relation. However, I still see this "up" = relation on GitHub. Is the plan still to remove that "up" relatio= n, has the plan changed, or is the plan to wait and see if anyone uses the = relation first?=C2=A0

    As for the "up" link rel= ation from challenge to authorization (not mentioned on slides), this could= encounter a similar problem. As a simple example to illustrate the potenti= al problem, assume a server issues an order with two authorizations: one au= thorization for (http-01 or dns-01), and another authorization for (tls-sni= -02 or dns-01). To prevent the client having to complete the same challenge= twice, assume that the server used the same dns-01 challenge instance for = both authorizations. For the common dns-01 challenge, where does the "= up" relation point to? This could become a more significant issue as n= ew identifiers, challenges, etc. are added in the future. How should this b= e addressed?=C2=A0

    Sincerely,=C2=A0

    =
    Logan Widick
    --f403045ffcfed4dbcc054e15be62-- From nobody Wed Apr 26 12:50:52 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA37C12948F for ; Wed, 26 Apr 2017 12:50:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5NN7oZHPpgeZ for ; Wed, 26 Apr 2017 12:50:49 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A38A61293F4 for ; Wed, 26 Apr 2017 12:50:48 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id m123so14806294wma.0 for ; Wed, 26 Apr 2017 12:50:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fAhjbqmmN33imJuwR3s6hBDOZZGQhdxHP5YHWPV3Qtw=; b=2ID1+U4bEV/IROZU05zVJIBeRqcAW3xPtkZAXzBeVIg4rpYLurj7YFUYGZ/uoNNHWR 4E3ZrF6ePUiP87P3t3r+86uPEn/FlPAZYWw6Ep3vr6HbWu6UxbRVMdzlgLwo3s0/16bW FrtGG6b5ZhHsRD0AdEN5dyL5ot648mcH9oj2cCS8yWFkk0AkQ3goNI6vCd8qSdgM5mPy k06XwZtOJywn68VbjKyY59sGeHIitYT+yWrrD6bv7xx8xXErnwi2jHrlEZRGipsJnX2c icg+e3va7z24WUuvPxqMwIz4BuKEpspNTAUZdnDYIQX7QdKVLBtWt1uOnIJXNz18Y477 LCCQ== 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=fAhjbqmmN33imJuwR3s6hBDOZZGQhdxHP5YHWPV3Qtw=; b=CcJESSs7ljBJ4wHuXOTxlzW0tg/M6R+DmKWcgrdcdI6RWD3x8lsUnQhBp1dDqY6WTK 804R66k4XM61GYGlqdCYZNo6CYrJNEfuTVmNdb6Gx4GNp+aLoAWIVpn/OlXucCRqHT7/ xqfqboUs14ewq1+ctLP+oKWfr4X0sv6B4jVSCZHn7jO4N+njP6LHD3HhnJ9Nah3sgxnz DIOyX4cGUMw2TUqXu1HsvvyiF/cEd8VK4Fuw1cJAA3UZfwfsfRcLHyPgydnNXpY2QFhC MNaiaH7djFdGl8ux4vWWZYRNr8QBo0jB1Bwecf5NZaLfCqOhUEcnPOXtkoOc6KD5kIjr NWqQ== X-Gm-Message-State: AN3rC/6Db+1r7Hr/dcFlJaA5DmD7tRG8fyFx2Q4mK90DuR5uiC78aJkh 02P10iZTQmE4rP6gkxDQ7B2E28P1u8n4fXE= X-Received: by 10.28.113.73 with SMTP id m70mr2229289wmc.12.1493236246875; Wed, 26 Apr 2017 12:50:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.136.84 with HTTP; Wed, 26 Apr 2017 12:50:46 -0700 (PDT) In-Reply-To: References: From: Richard Barnes Date: Wed, 26 Apr 2017 15:50:46 -0400 Message-ID: To: Logan Widick Cc: ACME WG Content-Type: multipart/alternative; boundary=001a114791f20f9c1b054e1728b6 Archived-At: Subject: Re: [Acme] "Slide 16" ("up" Link Relation) Follow Up from IETF 98 X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 19:50:50 -0000 --001a114791f20f9c1b054e1728b6 Content-Type: text/plain; charset=UTF-8 On Wed, Apr 26, 2017 at 2:09 PM, Logan Widick wrote: > According to the draft minutes, as of the end of IETF 98, the plan was to > eliminate the "up" link relation from authorization to order since an > authorization can belong to multiple orders and nobody seemed to rely on > this relation. However, I still see this "up" relation on GitHub. Is the > plan still to remove that "up" relation, has the plan changed, or is the > plan to wait and see if anyone uses the relation first? > We just haven't gotten around to implementing it yet :) Here's a PR: https://github.com/ietf-wg-acme/acme/pull/298 > As for the "up" link relation from challenge to authorization (not > mentioned on slides), this could encounter a similar problem. As a simple > example to illustrate the potential problem, assume a server issues an > order with two authorizations: one authorization for (http-01 or dns-01), > and another authorization for (tls-sni-02 or dns-01). To prevent the client > having to complete the same challenge twice, assume that the server used > the same dns-01 challenge instance for both authorizations. For the common > dns-01 challenge, where does the "up" relation point to? This could become > a more significant issue as new identifiers, challenges, etc. are added in > the future. How should this be addressed? > Why would a server do what you're saying? It seems like the construct you propose basically just takes the OR combinations of challenges in the individual authz and ANDs them. We had agreed a long time ago that a single OR layer was sufficient for all known use cases. And if you want to create an AND, this is about the least elegant way you could create the AND, vs. say a conjuction challenge type, or the "combinations" array we had before. Given that, I'm comfortable saying that each challenge belongs to exactly one authz. --Richard > > Sincerely, > > Logan Widick > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > > --001a114791f20f9c1b054e1728b6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


    On Wed, Apr 26, 2017 at 2:09 PM, Logan Widick <logan.widick@gmail= .com> wrote:
    According to the draft minutes, as of the end of IETF= 98, the plan was to eliminate the "up" link relation from author= ization to order since an authorization can belong to multiple orders and n= obody seemed to rely on this relation. However, I still see this "up&q= uot; relation on GitHub. Is the plan still to remove that "up" re= lation, has the plan changed, or is the plan to wait and see if anyone uses= the relation first?

    We just hav= en't gotten around to implementing it yet :)=C2=A0 Here's a PR:


    =C2=A0
    As for the "up" link relation from challenge to= authorization (not mentioned on slides), this could encounter a similar pr= oblem. As a simple example to illustrate the potential problem, assume a se= rver issues an order with two authorizations: one authorization for (http-0= 1 or dns-01), and another authorization for (tls-sni-02 or dns-01). To prev= ent the client having to complete the same challenge twice, assume that the= server used the same dns-01 challenge instance for both authorizations. Fo= r the common dns-01 challenge, where does the "up" relation point= to? This could become a more significant issue as new identifiers, challen= ges, etc. are added in the future. How should this be addressed?=C2=A0

    Why would a server do what you'= re saying?=C2=A0 It seems like the construct you propose basically just tak= es the OR combinations of challenges in the individual authz and ANDs them.= =C2=A0 We had agreed a long time ago that a single OR layer was sufficient = for all known use cases.=C2=A0 And if you want to create an AND, this is ab= out the least elegant way you could create the AND, vs. say a conjuction ch= allenge type, or the "combinations" array we had before.

    Given that, I'm comfortable saying that each chall= enge belongs to exactly one authz.

    --Richard
    =

    =C2=A0

    Sincerely,=C2=A0

    Logan Widic= k

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


    --001a114791f20f9c1b054e1728b6-- From nobody Wed Apr 26 14:10: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 EA53B1294A8 for ; Wed, 26 Apr 2017 14:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mKAVt7JHwhwz for ; Wed, 26 Apr 2017 14:10:48 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0133.outbound.protection.outlook.com [104.47.0.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F29012025C for ; Wed, 26 Apr 2017 14:10:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=cWgYbG1oAo43tvt7fjvBH6NOroiH6XV++2ZTioFh4zU=; b=FYdTQYvIyRq/v6fNM1u8EbQW96wpAPbQMzNZoyjcbo6Ys69ETCyO9NZ4vuO6FPmZAmYRddqvE342Mc2STks3aUkR5bieizBW8tGLWu7KtrdxAhWXDFKQpcxdYNZWeqP8Zg16bEo59A1f41EGqxNYGdyeGIXAikv6pVHS12CP9XM= Received: from VI1PR07MB1102.eurprd07.prod.outlook.com (10.163.168.26) by VI1PR07MB1101.eurprd07.prod.outlook.com (10.163.168.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1061.6; Wed, 26 Apr 2017 21:10:45 +0000 Received: from VI1PR07MB1102.eurprd07.prod.outlook.com ([10.163.168.26]) by VI1PR07MB1102.eurprd07.prod.outlook.com ([10.163.168.26]) with mapi id 15.01.1061.011; Wed, 26 Apr 2017 21:10:44 +0000 From: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" To: "Salz, Rich" , ACME WG CC: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" Thread-Topic: [Acme] Futures Thread-Index: AQHSu6kzLCTcKkAFskSURo93jsp44qHWaFgAgAHUOQA= Date: Wed, 26 Apr 2017 21:10:44 +0000 Message-ID: References: <6B2EB1DB-3B45-4A51-9167-86D5BAE8BF1F@on.nokia.com> <6dad1e1718804b56982341b814da2563@usma1ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: <6dad1e1718804b56982341b814da2563@usma1ex-dag1mb1.msg.corp.akamai.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: akamai.com; dkim=none (message not signed) header.d=none;akamai.com; dmarc=none action=none header.from=nokia.com; x-originating-ip: [92.20.248.166] x-microsoft-exchange-diagnostics: 1; VI1PR07MB1101; 7:TRyQWp/e4vLzNaxRX5cqLT+HUMfZjIHDCqabOEw0DGmaWO6uQg7fiQN1s74tf6Veg6a48j2BmnU0mUniDN4hA+KxobUnLscKIJvzoAcgwBwSGEiF42dstUS4n8UWCB1PGJeqZT4XYuSnhzpqqK4s7DtrC//454kI0UeZOTofZMyDjE+A2bqoCEp3hhHX9b8XE28xCNzOH+Qw4Nyng71tCn1ZO4Jn7TQEXundiO/6atuWK0naUAUn4LYnHAfo5J2PfrSKdtAAwOIs+S9cCEe3EsYwnTsye/NWURnGCIE44ItKTYTjQClUdo6ki6m47JKPVcxi+G3BOExBwmohN6T/OQ== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39840400002)(39410400002)(39850400002)(39860400002)(39400400002)(24454002)(102836003)(6436002)(83716003)(77096006)(6306002)(6116002)(6486002)(6506006)(3846002)(6512007)(3660700001)(99286003)(2950100002)(2906002)(82746002)(83506001)(3280700002)(229853002)(66066001)(2900100001)(4326008)(50986999)(76176999)(54356999)(107886003)(38730400002)(305945005)(33656002)(53546009)(25786009)(86362001)(81166006)(6246003)(189998001)(7736002)(53936002)(122556002)(4001350100001)(8936002)(5660300001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1101; H:VI1PR07MB1102.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-ms-office365-filtering-correlation-id: 0f7e9316-7844-483a-ebf3-08d48ce8b3fa x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:VI1PR07MB1101; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(6055026)(6041248)(20161123558100)(20161123562025)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(6072148); SRVR:VI1PR07MB1101; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1101; x-forefront-prvs: 0289B6431E spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <666DC03D814F8346960430ED21EFB057@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Apr 2017 21:10:44.4387 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1101 Archived-At: Subject: Re: [Acme] Futures X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 21:10:51 -0000 SGkgUmljaCwNCg0KPiBPbiAyNS8wNC8yMDE3IDE5OjE0LCAiU2FseiwgUmljaCIgPHJzYWx6QGFr YW1haS5jb20+IHdyb3RlOg0KPiA+IFdlIGhhdmUgcmVjZW50bHkgcHVibGlzaGVkIFsxXSBhbmQg c3RhcnRlZCBpbXBsZW1lbnRpbmcgaXQuDQo+ID4gDQo+ID4gVGhlIHBsYW4gaXMgdG8gZ2V0IHRo ZSBjb2RlIHJ1bm5pbmcgQVNBUCAoc3VyZWx5IGJlZm9yZSBQcmFndWUpIGFuZCwgaWYgdGhlDQo+ ID4gZXhwZXJpbWVudCBpcyBzYXRpc2ZhY3RvcnksIGFzayBmb3IgYWRvcHRpb24uDQo+ID4gDQo+ ID4gQ2hlZXJzLCB0DQo+ID4gDQo+ID4gWzFdIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1zaGVmZmVyLWFjbWUtc3Rhci0wMA0KPiANCj4gU2luY2UgdGhlIGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtcmVzY29ybGEtdGxzLXN1YmNlcnRzDQo+IGlz IGJlaW5nIHRha2VuIHVwIGluIFRMUywgaXQgbWlnaHQgbWFrZSBzZW5zZSBmb3IgdGhpcyBkcmFm dCB0byBnbyB0aGVyZSwNCj4gdG9vLiAgQnV0IHdlIGNhbiBzZWUuDQoNCkknbSBub3Qgc3VyZSB0 aGF0IHdvdWxkIGJlIGEgZmVhc2libGUgc29sdXRpb246IHRoZSBtb3N0IG9idmlvdXMgcmVhc29u IGJlaW5nDQppdCdkIHJlcXVpcmUgYW4gZXh0cmVtZSBjaGFydGVyLXN0cmV0Y2hpbmcgZXhlcmNp c2UuICBCZXNpZGVzLCBTVEFSIGluY2x1ZGVzIGFuDQpleHRlbnNpb24gb2YgQUNNRSwgdGh1cyB0 aGUgQUNNRSBXRyBsb29rcyB0byBtZSBsaWtlIHRoZSBvYnZpb3VzIHBsYWNlIHdoZXJlIHRvDQpo b3N0IHRoaXMgd29yay4NCg0KQ2hlZXJzLCB0DQoNCg== From nobody Wed Apr 26 14:12: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 4C2491294C0 for ; Wed, 26 Apr 2017 14:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y32w13iIOR6O for ; Wed, 26 Apr 2017 14:12:27 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CA58127342 for ; Wed, 26 Apr 2017 14:12:27 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v3QLC0q8002593; Wed, 26 Apr 2017 22:12:25 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=X3mejHU0s3+Q7sefXpRZHqHaeVb3z4clZwClpQ/05sQ=; b=NLybojsfmrbj8U1TowVbLKs3ysoAzi/oCP8IRg9CnGfFTE/7uvRUrXZJfJypPoTktNxq 7fQgz0tpCRXODZ0i9Y5Yxq3ReW78XLYlL/b5DFOTseXGT6XuE6xZLUYbr1FSz4aS4gmA /PprLzzMCGkPep7GnR2BDT3IjmqnAioNUzNBywN6ZKxjIsvJqbtNNy9gKEuuQpBjKjdu q+Y9rQXpR0xUKeEM7XK/6DMl9+kks04z7kX55ZMZycNrarwiEyl8zVZftmeWTrCFAq2a OBtvhEIPKIrmc7uIzwFpQkRxd1EUBUhL19fV94IkX+3xjaMRSjs9I3ffv+KqZlu62BgY lA== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2a2ebgg7en-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 26 Apr 2017 22:12:24 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v3QLBgsG005032; Wed, 26 Apr 2017 17:12:23 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint2.akamai.com with ESMTP id 2a02guyf1g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 26 Apr 2017 17:12:23 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 26 Apr 2017 17:12:20 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Wed, 26 Apr 2017 17:12:18 -0400 From: "Salz, Rich" To: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" , ACME WG Thread-Topic: [Acme] Futures Thread-Index: AQHSu6kz20BvTAD9Q3ePlESvzSMwkqHWZ0ewgAIHlwD//70tkA== Date: Wed, 26 Apr 2017 21:12:18 +0000 Message-ID: References: <6B2EB1DB-3B45-4A51-9167-86D5BAE8BF1F@on.nokia.com> <6dad1e1718804b56982341b814da2563@usma1ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.162] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-26_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1704260349 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-26_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1704260349 Archived-At: Subject: Re: [Acme] Futures X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 21:12:28 -0000 IA0KPiBJJ20gbm90IHN1cmUgdGhhdCB3b3VsZCBiZSBhIGZlYXNpYmxlIHNvbHV0aW9uOiB0aGUg bW9zdCBvYnZpb3VzIHJlYXNvbiBiZWluZw0KPiBpdCdkIHJlcXVpcmUgYW4gZXh0cmVtZSBjaGFy dGVyLXN0cmV0Y2hpbmcgZXhlcmNpc2UuICBCZXNpZGVzLCBTVEFSIGluY2x1ZGVzDQo+IGFuIGV4 dGVuc2lvbiBvZiBBQ01FLCB0aHVzIHRoZSBBQ01FIFdHIGxvb2tzIHRvIG1lIGxpa2UgdGhlIG9i dmlvdXMgcGxhY2UNCj4gd2hlcmUgdG8gaG9zdCB0aGlzIHdvcmsuDQoNClRoYXQncyBmaW5lLg0K DQpJJ20ganVzdCBhc2tpbmcgYmVjYXVzZSB3ZSBzZWVtIHRvIGhhdmUgc2V2ZXJhbCBzaW1pbGFy IGtpbmRzIG9mIHRoaW5ncyBwb3BwaW5nIHVwIGluIHZhcmlvdXMgcGxhY2VzIGFuZCBJIHdhbnQg dG8gbWFrZSBzdXJlIGFsbCBpbnRlcmVzdGVkIHBhcnRpZXMgYXJlIGF3YXJlIG9mIGFsbCBvZiB0 aGVtLiA6KQ0K From nobody Wed Apr 26 16:31: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 E8406129577 for ; Wed, 26 Apr 2017 16:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 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, T_FILL_THIS_FORM_SHORT=0.01] 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 0xRwY7Esm25z for ; Wed, 26 Apr 2017 16:31:39 -0700 (PDT) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::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 99A5C1294B2 for ; Wed, 26 Apr 2017 16:31:39 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id 194so8179572pfv.3 for ; Wed, 26 Apr 2017 16:31:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/L0LGXFtJiLeqr4p9LdoGT68as4+wa/7KKTX+mHhLEg=; b=eWFU0WgUMyCQn3Q2uuEBFnPWduhOPzLc/ghfsia+49sWIEgMMyYui+kXADviPS2faA JKCRTeqoxq1z8DmdpQGh9l/DJcAIj9X3x2j2ywL3Tg8PUWbVzfoZWT6SIT+Ow+I/F92e LCXx8qD7xXP9WsFrC2SuUhmZLO2bedZwbSpefux1CjKBHT2gqPzKBCKBSWVzRIB24BTD GKmDaHJJIlNFqFE1RBM8E4enSTx2Vwdu+d4MKemnwLw4fSdvfs0OyGix2mxzdogBxpu1 9ZsWNlY57GFP/6tve3ZXdaANXihPk9HCbJvYhszqogIQYvyWQC56Eh4bQrE7gnRM2HjE wyoA== 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=/L0LGXFtJiLeqr4p9LdoGT68as4+wa/7KKTX+mHhLEg=; b=i5T6qbq/h8oqPU0TGEGiGG3e3eDy/5Px9HTJ9nTdMuk9q2DNrE3xxVHR5CG3Nuac51 HLxFcJvIFlKEnNJXuPMq/Grff7JUSlB6CE7IDpExBl6LagtntbvBNuuQfCSP1hIXlRh+ tHeSmkWyxIBBjXTkknQuV9ZqBRTmFy1pnayLhOXpa7OsyzyvPd13lURkPKB8onwlAY3F AICMTqaAAei4O/9xszuEUwPv+RZ/ay6llYp+OJJmlZRgwP6gbYs6IZTD1OpkbRuKibyq mekRXQebruT90BoIojcmn/wA1hCxP/OtwLWarp6NYllESc8Si1k4tZLWUCwtnbACeYKE VeNA== X-Gm-Message-State: AN3rC/7N6qDXmQLlK0VFYwjSrXaY19Jb69bNRI3Cy68NZUPcme0rzSOT anRO7cV80F1H6uzcNguas2hbgwb73g== X-Received: by 10.84.168.4 with SMTP id e4mr3072260plb.138.1493249498963; Wed, 26 Apr 2017 16:31:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.157.133 with HTTP; Wed, 26 Apr 2017 16:31:38 -0700 (PDT) In-Reply-To: References: From: Logan Widick Date: Wed, 26 Apr 2017 18:31:38 -0500 Message-ID: To: Richard Barnes Cc: ACME WG Content-Type: multipart/alternative; boundary=94eb2c11a04ef268ca054e1a3d8d Archived-At: Subject: Re: [Acme] "Slide 16" ("up" Link Relation) Follow Up from IETF 98 X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 23:31:42 -0000 --94eb2c11a04ef268ca054e1a3d8d Content-Type: text/plain; charset=UTF-8 On Wed, Apr 26, 2017 at 2:50 PM, Richard Barnes wrote: > > > On Wed, Apr 26, 2017 at 2:09 PM, Logan Widick > wrote: > >> According to the draft minutes, as of the end of IETF 98, the plan was to >> eliminate the "up" link relation from authorization to order since an >> authorization can belong to multiple orders and nobody seemed to rely on >> this relation. However, I still see this "up" relation on GitHub. Is the >> plan still to remove that "up" relation, has the plan changed, or is the >> plan to wait and see if anyone uses the relation first? >> > > We just haven't gotten around to implementing it yet :) Here's a PR: > > https://github.com/ietf-wg-acme/acme/pull/298 > Good to know. Thanks! > > >> As for the "up" link relation from challenge to authorization (not >> mentioned on slides), this could encounter a similar problem. As a simple >> example to illustrate the potential problem, assume a server issues an >> order with two authorizations: one authorization for (http-01 or dns-01), >> and another authorization for (tls-sni-02 or dns-01). To prevent the client >> having to complete the same challenge twice, assume that the server used >> the same dns-01 challenge instance for both authorizations. For the common >> dns-01 challenge, where does the "up" relation point to? This could become >> a more significant issue as new identifiers, challenges, etc. are added in >> the future. How should this be addressed? >> > > Why would a server do what you're saying? It seems like the construct you > propose basically just takes the OR combinations of challenges in the > individual authz and ANDs them. We had agreed a long time ago that a > single OR layer was sufficient for all known use cases. And if you want to > create an AND, this is about the least elegant way you could create the > AND, vs. say a conjuction challenge type, or the "combinations" array we > had before. > > Given that, I'm comfortable saying that each challenge belongs to exactly > one authz. > I was thinking that there could be situations where a challenge belongs to multiple authzs (which would complicate the "up" link). I thought of two types of such situations: 1. A server that follows something like the above scenario. This might not be that likely. 2. A type of "thing" that people may want to put in a certificate in the future that may require multiple identifiers to represent. This would mean that a challenge could end up validating multiple identifiers. That would require multiple authzs for the same challenge, since an authz is for one identifier only. For the second type of situation, I was going to reply with a scenario that involved future demand for physical addresses in certificates. A physical address is already required for some types of certificates (see section 9.2.7, "Subject Physical Address of Place of Business Field", in the EV spec at https://cabforum.org/wp-content/uploads/EV-V1_6_1.pdf as an example) and I thought that a physical address would be example of one "thing" that would require multiple identifiers to represent (street, city/town, state/province, country, and postcode). However, I think one could get around that with some type of special representation. Initial but likely inelegant possibilities could include encoding the address components as URL query parameters inside the value string (e.g. "streetAddress=123%20Test%20Street&localityName=Testville&stateOrProvince= AnyState&country=AnyCountry&postCode=123456"), or as a similar JSON object inside the value string (e.g. '{"streetAddress": "123 Test Street", "localityName": "Testville", "stateOrProvince": "AnyState", "country": "AnyCountry", "postcode": "123456"}'). (I know that the guiding use case for ACME is DV not EV, but I was thinking that there may be demand for ACME-based EV in the future.) A physical address was the most complex example of a "thing" that I could think of that someone may want to put in a certificate in the future, and that I thought may require multiple identifiers to represent. However, as mentioned above, there could even be a way to merge the parts of a physical address into a single identifier. Thus, I am now convinced that each "thing" that someone could ever want put in a certificate could be represented as a single identifier. Therefore, I would be comfortable saying that a challenge validates exactly one identifier. Combine this with the low (or zero) odds of my initial scenario happening, and I am also now comfortable saying a challenge belongs to exactly one authz. Logan --94eb2c11a04ef268ca054e1a3d8d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    On W= ed, Apr 26, 2017 at 2:50 PM, Richard Barnes <rlb@ipv.sx> wrote:


    On Wed, Apr 2= 6, 2017 at 2:09 PM, Logan Widick <logan.widick@gmail.com> wrote:
    According to the draft minutes, as of the end of IETF 98, the plan was= to eliminate the "up" link relation from authorization to order = since an authorization can belong to multiple orders and nobody seemed to r= ely on this relation. However, I still see this "up" relation on = GitHub. Is the plan still to remove that "up" relation, has the p= lan changed, or is the plan to wait and see if anyone uses the relation fir= st?

    We just haven't g= otten around to implementing it yet :)=C2=A0 Here's a PR:

    Good to know. Thanks!=C2= =A0
    =C2=A0
    = As for the "up" link relation from challenge to authorization (no= t mentioned on slides), this could encounter a similar problem. As a simple= example to illustrate the potential problem, assume a server issues an ord= er with two authorizations: one authorization for (http-01 or dns-01), and = another authorization for (tls-sni-02 or dns-01). To prevent the client hav= ing to complete the same challenge twice, assume that the server used the s= ame dns-01 challenge instance for both authorizations. For the common dns-0= 1 challenge, where does the "up" relation point to? This could be= come a more significant issue as new identifiers, challenges, etc. are adde= d in the future. How should this be addressed?=C2=A0

    Why would a server do what you're saying?= =C2=A0 It seems like the construct you propose basically just takes the OR = combinations of challenges in the individual authz and ANDs them.=C2=A0 We = had agreed a long time ago that a single OR layer was sufficient for all kn= own use cases.=C2=A0 And if you want to create an AND, this is about the le= ast elegant way you could create the AND, vs. say a conjuction challenge ty= pe, or the "combinations" array we had before.

    =
    Given that, I'm comfortable saying that each challenge belon= gs to exactly one authz.

    I was thinking that there could be situations where a challenge belon= gs to multiple authzs (which would complicate the "up" link). I t= hought of two types of such situations:=C2=A0
    1. A server th= at follows something like the above scenario. This might not be that likely= .
    2. A type of "thing" that people may want to put in a cert= ificate in the future that may require multiple identifiers to represent. T= his would mean that a challenge could end up validating multiple identifier= s. That would require multiple authzs for the same challenge, since an auth= z is for one identifier only.=C2=A0
    For the second = type of situation, I was going to reply with a scenario that involved futur= e demand for physical addresses in certificates. A physical address is alre= ady required for some types of certificates (see section 9.2.7, "Subje= ct Physical Address of Place of Business Field", in the EV spec at https://cabforum.org/wp-content/uploads/EV-V1_6_1.pdf=C2=A0a= s an example)=C2=A0and I thought that a physical address would be exam= ple of one "thing" that would require multiple identifiers to rep= resent (street, city/town, state/province, country, and postcode). However,= I think one could get around that with some type of special representation= . Initial but likely inelegant possibilities could include encoding the add= ress components as URL query parameters inside the value string (e.g. "= ;streetAddress=3D123%20Test%20Street&localityName=3DTestville= &stateOrProvince=3DAnyState&country=3DAnyCountry&post= Code=3D123456"),=C2=A0or as a similar JSON object inside the value str= ing (e.g. '{"streetAddress": "123 Test Street", &qu= ot;localityName": "Testville", "stateOrProvince": = "AnyState", "country": "AnyCountry", "po= stcode": "123456"}').=C2=A0

    (I know that the guiding use case for ACME is DV not EV, but I was thinkin= g that there may be demand for ACME-based EV in the future.)

    =
    A physical address was the most complex example of a "thing= " that I could think of that someone may want to put in a certificate = in the future, and that I thought may require multiple identifiers to repre= sent. However, as mentioned above, there could even be a way to merge the p= arts of a physical address into a single identifier. Thus, I am now convinc= ed that each "thing" that someone could ever want put in a certif= icate could be represented as a single identifier. Therefore, I would be co= mfortable saying that a challenge validates exactly one identifier. Combine= this with the low (or zero) odds of my initial scenario happening, and I a= m also now comfortable saying a challenge belongs to exactly one authz.=C2= =A0

    Logan
    --94eb2c11a04ef268ca054e1a3d8d-- From nobody Wed Apr 26 21:55: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 88847131592 for ; Wed, 26 Apr 2017 21:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zMjL4-jOk9_j for ; Wed, 26 Apr 2017 21:55:25 -0700 (PDT) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B564131590 for ; Wed, 26 Apr 2017 21:55:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=mvJIxI2hV4FiOLK9pj9Zr84Ug55/OHJPXcL4aN9QboI=; b=qzCJthZCtswjnLnpFzzoTlWbfVdjjcA/3vUMDxSllEfkH7PU3YHB/a9TbSm2vraT3kTZ7gcs3nTP3pM6JJZwj9atZXaW8ROSwef/fJ0A3g7ClhWiIGwme+uupeIGgWujPnJ/TA4UMt6e5VNssC88Lg8tAheiAoCimre1xRJ8YXM=; Received: ; Wed, 26 Apr 2017 21:55:24 -0700 To: Sean Leonard References: <20170329195427.GA23764@LK-Perkele-V2.elisa-laajakaista.fi> <525f79bb-a2e6-bf09-30e5-e80e0bb80379@eff.org> <3a9aaca8-204c-2a6c-2fc5-f74870effc2e@eff.org> <72CD4CDB-51BD-410C-908D-478AFB4A9411@seantek.com> Cc: ACME WG , Ilari Liusvaara From: Jacob Hoffman-Andrews Message-ID: Date: Wed, 26 Apr 2017 21:55:22 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <72CD4CDB-51BD-410C-908D-478AFB4A9411@seantek.com> Content-Type: multipart/alternative; boundary="------------A46C1CFD477BFE5E0DD5C570" Archived-At: Subject: Re: [Acme] draft-ietf-acme-acme-06: Don't call it PEM Certificate Chain X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 04:55:27 -0000 This is a multi-part message in MIME format. --------------A46C1CFD477BFE5E0DD5C570 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 03/30/2017 09:04 AM, Sean Leonard wrote: > IN PARTICULAR: both Apache and Ngnix may be subject to a private key > substitution attack with naive passing of the ACME response to the web > server! See: > http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_certificate > http://httpd.apache.org/docs/current/mod/mod_ssl.html#sslcertificatefil= e > > The SSL Certificate option includes the option of including the > private key in the same input: =93A secret key in the PEM format may be= > placed in the same file.=94 I tried to reproduce this, and I believe you are incorrect that a private key substitution attack works. For both Nginx and Apache, I created a file containing a PEM-encoded certificate, and appended a PEM-encoded RSA private key corresponding to the public key in the certificate. I then placed a different PEM-encoded RSA private key in cert-key.pem. I configured the certificate with ssl_certificate or SSLCertificateFile, respectively, and the key with ssl_certificate_key or SSLCertificateKeyFile, respectively. For Apache, I got: [Wed Apr 26 21:45:50.094519 2017] [ssl:emerg] [pid 10967] AH02565: Certificate and private key ocsp.test.wtf:8443:0 from /home/jsha/ocsp-stapling-examples/cert.pem and /home/jsha/ocsp-stapling-examples/cert-key.pem do not match AH00016: Configuration Failed For Nginx, I got: 2017/04/26 21:51:48 [emerg] 11164#11164: SSL_CTX_use_PrivateKey_file("./cert-key.pem") failed (SSL: error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch) In neither case did the server successfully start up. Absent the private key substitution attack, I don't see a strong argument against offering certificates and chains in the very common PEM format by default. --------------A46C1CFD477BFE5E0DD5C570 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit On 03/30/2017 09:04 AM, Sean Leonard wrote:
    IN PARTICULAR: both Apache and Ngnix may be subject to a private key substitution attack with naive passing of the ACME response to the web server! See:

    The SSL Certificate option includes the option of including the private key in the same input: A secret key in the PEM format may be placed in the same file.
    I tried to reproduce this, and I believe you are incorrect that a private key substitution attack works.

    For both Nginx and Apache, I created a file containing a PEM-encoded certificate, and appended a PEM-encoded RSA private key corresponding to the public key in the certificate. I then placed a different PEM-encoded RSA private key in cert-key.pem. I configured the certificate with ssl_certificate or SSLCertificateFile, respectively, and the key with ssl_certificate_key or SSLCertificateKeyFile, respectively. For Apache, I got:

    [Wed Apr 26 21:45:50.094519 2017] [ssl:emerg] [pid 10967] AH02565: Certificate and private key ocsp.test.wtf:8443:0 from /home/jsha/ocsp-stapling-examples/cert.pem and /home/jsha/ocsp-stapling-examples/cert-key.pem do not match
    AH00016: Configuration Failed

    For Nginx, I got:

    2017/04/26 21:51:48 [emerg] 11164#11164: SSL_CTX_use_PrivateKey_file("./cert-key.pem") failed (SSL: error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch)

    In neither case did the server successfully start up. Absent the private key substitution attack, I don't see a strong argument against offering certificates and chains in the very common PEM format by default.
    --------------A46C1CFD477BFE5E0DD5C570-- From nobody Thu Apr 27 10:06:31 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C19D129B48 for ; Thu, 27 Apr 2017 10:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 awqjUVvTPv3u for ; Thu, 27 Apr 2017 10:06:28 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06CFB129B5D for ; Thu, 27 Apr 2017 10:03:04 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id y33so31145193qta.2 for ; Thu, 27 Apr 2017 10:03:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=letsencrypt.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=tHr3p9U8nIwhjzVTs6V2cZzvxjNTCMWAyPhIrcmpm0w=; b=avnWOImzktYNkK9EtsTcLVWSKgfm30XdiUYgJ5+Rn9E58nETZv8USby9byN+FqeVfI rMaVi6E1v0KpBK8HdceqM+IKXV5zUcd3+VfmTgtAdxAHJTDCsrjU4a00DWYPIusPQEcX Dh4txEOYGnr9ZPKe5DrLmFJkh11rjH8ceoddE= 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=tHr3p9U8nIwhjzVTs6V2cZzvxjNTCMWAyPhIrcmpm0w=; b=WhkN3J5Cxz4OfcN4Syzt7R5hRcnpEHtveT+XFirXAGBYV2cCdN3g1lJ998l4NrchUq y9gR5tQkcx/ltofGLT6+3xuMlvHwFveVDT8ukZRpf1c9Dab4bYtEXVmXSBLGFh49vjGM kRADgRdphUfGh2tPVuzC2LlG5BJF6d6t0DEM4riYzayT4UWEJRvKRoR1zXHugKqsEf9b V/EKtFlFwtFxBwcGlk/VdrVwKqIDMTVCKPl/CBo3GNtaV0AcqmnqLQB900hlCn+BDSA+ bBSdhDIP/JMNlNVnqslSRWgw6/MqCGN69DCK4We2QEC85zd5b2S5zpt2ekxJfJNzuVJR qNKg== X-Gm-Message-State: AN3rC/6LyrmpaA4nXroI0ymuDwFxZLp1kobDvjshuxRnkAMqx8E1TqKN CkfIuhVMk/u916yn5chBGnMBhD/PcB/FZtc= X-Received: by 10.237.60.98 with SMTP id u31mr6009079qte.224.1493312583848; Thu, 27 Apr 2017 10:03:03 -0700 (PDT) MIME-Version: 1.0 References: <878ad4965b254e5aa7e58e8c812d1df1@usma1ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: <878ad4965b254e5aa7e58e8c812d1df1@usma1ex-dag1mb1.msg.corp.akamai.com> From: Roland Shoemaker Date: Thu, 27 Apr 2017 17:02:53 +0000 Message-ID: To: "Salz, Rich" , ACME WG Content-Type: multipart/alternative; boundary=94eb2c18fde0196c5a054e28ee3e Archived-At: Subject: Re: [Acme] Futures X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 17:06:30 -0000 --94eb2c18fde0196c5a054e28ee3e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'd be interested in getting draft-shoemaker-acme-ip (current draft: https://www.ietf.org/id/draft-shoemaker-acme-ip-00.txt with a revision coming in the very near future) adopted by the WG. We are currently considering implementing the extension defined in it in the Let's Encrypt server software Boulder and it would be good to get consensus from the group that it is an appropriate path forward for validating IP addresses. Thanks, Roland -- Software Engineer, Let's Encrypt Internet Security Research Group / Linux Foundation On Fri, Apr 21, 2017 at 7:01 PM Salz, Rich wrote: > Having talked with the authors, we expect the base ACME draft to be ready > for WGLC at least a month before the next IETF meeting. > > > > The CAA document, which we adopted, is very short and straightforward and > seems like it can be handled easily over email. > > > > Does anyone have any new work items that would be ready to discuss in > July? Any rechartering discussion that looks promising? If so, please > post to the mailing list soon. > > > > Thanks, > > Rich and Ted=E2=80=99s Excellent ACME Adventure > > > > > > -- > > Senior Architect, Akamai Technologies > > Member, OpenSSL Dev Team > > IM: richsalz@jabber.at Twitter: RichSalz > > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > --94eb2c18fde0196c5a054e28ee3e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    I'd be interested in getting=C2=A0draft-shoemaker-acme= -ip (current draft:=C2=A0https://www.ietf.org/id/draft-shoemaker-acme-ip-00.txt= =C2=A0with a revision coming in the very near future) adopted by the WG. We= are currently considering implementing the extension defined in it in the = Let's Encrypt server software Boulder and it would be good to get conse= nsus from the group that it is an appropriate path forward for validating I= P addresses.

    Thanks,
    Roland

    --
    Software Engineer, Let's Encrypt
    Internet= Security Research Group / Linux Foundation

    On Fri, Apr 21, 2017 at 7:01 PM Salz, Rich <<= a href=3D"mailto:rsalz@akamai.com">rsalz@akamai.com> wrote:

    Having talked with the authors, we expect the base A= CME draft to be ready for WGLC at least a month before the next IETF meetin= g.

    =C2=A0

    The CAA document, which we adopted, is very short an= d straightforward and seems like it can be handled easily over email.

    =C2=A0

    Does anyone have any new work items that would be re= ady to discuss in July?=C2=A0 Any rechartering discussion that looks promis= ing?=C2=A0 If so, please post to the mailing list soon.

    =C2=A0

    Thanks,

    Rich and Ted=E2=80=99s Excellent ACME Adventure

    =C2=A0

    =C2=A0

    --=C2=A0

    Senior Architect, Akamai Technologies<= /p>

    Member, OpenSSL Dev Team

    IM: richsalz@jabber.at Twitter: RichSalz

    =C2=A0

    _______________________________________________
    Acme mailing list
    Acme@ietf.org
    https://www.ietf.org/mailman/listinfo/acme
    --94eb2c18fde0196c5a054e28ee3e-- From nobody Thu Apr 27 12:39:20 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C101129BBE for ; Thu, 27 Apr 2017 12:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ew9orUCiSyxR for ; Thu, 27 Apr 2017 12:39:08 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C88FD129B2B for ; Thu, 27 Apr 2017 12:35:25 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id w64so25606069wma.0 for ; Thu, 27 Apr 2017 12:35:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=R+wJu/GmKiz7k64K/nrOiu3BDpDK3zA8OaeBe6J1imE=; b=e4Nb0EQ4yUogZnlktd+YyfGg+6yJ7jwl4Fq/ipAo8msgqzCw7MkG53E1ljGO9sVopv IZQ7gNK/OBP6+kJLURndrvdMeQpmrM4TFTcJx+SHqd5iInZYY4fkcgfsHCAKWUfWazHA xbW5o+urpYh30lT/S4enBsbrQqwC5zefqyM/DmDHWFNZ6LKDldhswE3tRz2tAGHXX5Nn bzUCYehLB0qora5GD580pJ5q077Cn7SNJcTFAQBP2xLEQ1YwauJXSy+WhQ4yOqrmp38t 3GhTrciT0R1HZUWoaiZcWht+kZBHo3XO7ftMYFBQv04qu3AQnnyzJJ+F/h62K159y8aI YsTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=R+wJu/GmKiz7k64K/nrOiu3BDpDK3zA8OaeBe6J1imE=; b=puLdEBVkQnsbFQtUZgf5wGjM//EW5f2Wz121kO6TthHUSLD02JdLW0E5M35YOyYCmC 5TJTZJKcdAmk7kxUU8Y6F3ciykOhtOuvQ/ZUx7HkWLa7w7tSdYljOr7PYr6eQvayiG+Y TSZfl1kqwUEYTd990Vu6+0ZXPb6T5fF5aoIy2Z0msshIf54MsuRbEcddDzhDq4Le0NMz vk7tbsOuZxmY+sQuJfsuY5ffCu/pu+zv25tqeNV+2TETV6s1Evw9mRiz/hzMnERvy+Eb fU2PEftFmdPC/FwoGH4qVJ/Rv260X2hs+z+jSplUwszuErsEdDnFzsJMGL3B8KiY/j0k uSaw== X-Gm-Message-State: AN3rC/6PM2g84Tm5H9mC2LqLaZT1DWjHD53yB8pWMYynUBvwkWGFZuUM e/01bjWgq0L/0TL4GB+Gro4l7Exg9TfI X-Received: by 10.28.113.73 with SMTP id m70mr3513939wmc.12.1493321723964; Thu, 27 Apr 2017 12:35:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.136.84 with HTTP; Thu, 27 Apr 2017 12:35:22 -0700 (PDT) In-Reply-To: <20170418052802.GA18137@andover.lhh.devever.net> References: <20170409084756.GA31209@andover.lhh.devever.net> <20170418052802.GA18137@andover.lhh.devever.net> From: Richard Barnes Date: Thu, 27 Apr 2017 15:35:22 -0400 Message-ID: To: Hugo Landau Cc: "acme@ietf.org" Content-Type: multipart/alternative; boundary=001a114791f2e4ad35054e2b0e06 Archived-At: Subject: Re: [Acme] PR: allow challenge retries X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 19:39:19 -0000 --001a114791f2e4ad35054e2b0e06 Content-Type: text/plain; charset=UTF-8 On Tue, Apr 18, 2017 at 1:28 AM, Hugo Landau wrote: > > Hey Hugo, > > Thanks for the PR. Jacob and I chatted a bit about this, and wanted > to > > propose a slightly different approach: > > [1]https://github.com/ietf-wg-acme/acme/pull/297 > > What do you think? Others on the list have any thoughts? > > This looks mostly OK. > > My only concern is that it's not clear how a client can determine when a > server is still attempting automatic retries. Is this to be detected via > the absence of the Retry-After header? Something more explicit might be > nicer (and less susceptible to misimplementation). > The idea is that as long as the challenge status is still "pending", the server is still retrying. Once it gives up, it marks the challenge as "invalid". > Also, is each automatic retry to result in an error being appended if > unsuccessful? This could get quite spammy depending on how many times a > server repeats verification. Possibly amendment of the problem document > format to add a repeat count (in the spirit of "last message repeated N > times") might be desirable. Or that might be my usual overengineering. > Yeah, I'm not to worried about spamminess here. The server can always limit the number of retries. --Richard > > Hugo Landau > --001a114791f2e4ad35054e2b0e06 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


    On Tue, Apr 18, 2017 at 1:28 AM, Hugo Landau <hlandau@devever.net> wrote:
    >= =C2=A0 =C2=A0 Hey Hugo,
    >=C2=A0 =C2=A0 Thanks for the PR.=C2=A0 Jacob and I chatted a bit about = this, and wanted to
    >=C2=A0 =C2=A0 propose a slightly different approach:
    >=C2=A0 =C2=A0 [1]    https://github.com/ietf-wg-= acme/acme/pull/297
    >=C2=A0 =C2=A0 What do you think?=C2=A0 Others on the l= ist have any thoughts?

    This looks mostly OK.

    My only concern is that it's not clear how a client can determine when = a
    server is still attempting automatic retries. Is this to be detected via the absence of the Retry-After header? Something more explicit might be
    nicer (and less susceptible to misimplementation).
    The idea is that as long as the challenge status is still "= ;pending", the server is still retrying.=C2=A0 Once it gives up, it ma= rks the challenge as "invalid".
    =C2=A0
    Also, is each automatic retry to result in an error being appended if
    unsuccessful? This could get quite spammy depending on how many times a
    server repeats verification. Possibly amendment of the problem document
    format to add a repeat count (in the spirit of "last message repeated = N
    times") might be desirable. Or that might be my usual overengineering.=

    Yeah, I'm not to worried about spa= mminess here.=C2=A0 The server can always limit the number of retries.

    --Richard

    =C2=A0

    Hugo Landau

    --001a114791f2e4ad35054e2b0e06-- From nobody Thu Apr 27 12:41:40 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 412DA129557 for ; Thu, 27 Apr 2017 12:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5A3H0OxJZEsC for ; Thu, 27 Apr 2017 12:41:35 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AAC4129B29 for ; Thu, 27 Apr 2017 12:38:12 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id u65so25613347wmu.1 for ; Thu, 27 Apr 2017 12:38:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MGD0SPuuehNJGb1bGjl9CgvnPWV2RGOYn06M3g+2Pe0=; b=N8+x3Q3DlVlfEM38JqcsEln61Htbi4/UkmQ7T8+Ax2W/qwu9UBdlIn9ILaj09wiec2 eCH7xtznPwFirWyyd8PNFWefN0BFt+UvdPcbHBlyvRgn12kOZf8foxWFFixUBY1Hjp6T JxAMLUfomhN7PLSAJA9PXR50oOgQhH5+MOF3Z9n92LScbkq8SG++H6pk/XZi7mEyxmiW 1XN82h0uHH4gSqtqdrGkMCnkHr0+P8ejLf4yg6IRSCiPZFXI8KnV8Yy73z7L+QgX2PI9 KYE/Qbr5tHkXf+80GySgFOhwH0W5B5fofJw4+NU/7v23cSLgtLDI26Zf+pCYUwTEOTmo uhJQ== 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=MGD0SPuuehNJGb1bGjl9CgvnPWV2RGOYn06M3g+2Pe0=; b=atSrBVr2Q4Vxqi00l3pQoA3gOCu6B275slPvP/JyWNeqkTbORiCt2UA8DcDHNp3t1k dPbgGSF9VGQ43WZ90/afqKtKO/ZECFqUuh6Hhd4Q4vrvZj7XVLKtSutLZKXa5bxrQccB i14ErSocMl3Tpd57F54wyeOO/BvVIftTjyDmrovyAx4aGB8mi73YdimS8A2S1iktqFGf mZ6+fgSU6s0mvqb2RuZKB/FGHJyznLqSAtCq/DKODPpy69HKrWbxPoK/dIzCtS8H4r+/ 4N97gMzeX21om01Kcd4TNtqjMfFTuUwT7VG8XFBvbXdkdLP98fERBrr4bXMR0lIWzd+T bgmw== X-Gm-Message-State: AN3rC/6d0/nOe8IaGl11cEuptK+zhM6GleY8YrDObSxP7+u+kapJ3+aT HCzRwVqZsRgT30l8pYqd5FStB24VCA== X-Received: by 10.28.150.21 with SMTP id y21mr3654122wmd.12.1493321890271; Thu, 27 Apr 2017 12:38:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.136.84 with HTTP; Thu, 27 Apr 2017 12:38:09 -0700 (PDT) In-Reply-To: References: From: Richard Barnes Date: Thu, 27 Apr 2017 15:38:09 -0400 Message-ID: To: Logan Widick Cc: ACME WG Content-Type: multipart/alternative; boundary=001a114b3ef0ce4157054e2b1878 Archived-At: Subject: Re: [Acme] Account URI recovery X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 19:41:38 -0000 --001a114b3ef0ce4157054e2b1878 Content-Type: text/plain; charset=UTF-8 On Tue, Apr 18, 2017 at 1:48 AM, Logan Widick wrote: > From the text, if the field isn't present, should the server act like it > was set to false > Correct. > > If this new field is false, and an account exists, then what happens to > the pre-existing account, its orders, its certificates and its > authorizations? > Same as before -- you get a 200 with the existing account. --Richard > > Sincerely, > > Logan Widick > > On Apr 17, 2017 17:45, "Richard Barnes" wrote: > >> In reviewing a PR today noting that a client can find the account URI for >> a key pair using a new-account request with an empty payload [1], Jacob and >> I thought it might be a little more robust to use an explicit signal. I've >> posted a PR that adds a "recovery" field to indicate to the server that it >> should not create an account if one does not exist already. Which is a >> little ironic in a request to an endpoint designed to create an account, >> but saves us creating a whole new endpoint. >> >> https://github.com/ietf-wg-acme/acme/pull/296 >> >> Please let me know if you have any comments on the approach here. >> >> Thanks, >> --Richard >> >> _______________________________________________ >> Acme mailing list >> Acme@ietf.org >> https://www.ietf.org/mailman/listinfo/acme >> >> --001a114b3ef0ce4157054e2b1878 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


    On Tue, Apr 18, 2017 at 1:48 AM, Logan Widick <logan.widick@gmail= .com> wrote:
    From the text, if the field isn't present, should= the server act like it was set to false

    <= /div>
    Correct.
    =C2=A0

    If this new fiel= d is false, and an account exists, then what happens to the pre-existing ac= count, its orders, its certificates and its authorizations?=C2=A0

    Same as before -- you get a 200 wi= th the existing account.

    --Richard
    =C2=A0

    Sincerely,

    Logan Widick

    On Apr 17, 2017 17:45, "Richard Barnes" <rlb@ipv.sx> wrote= :
    <= div class=3D"h5">
    In reviewing a PR today noting that = a client can find the account URI for a key pair using a new-account reques= t with an empty payload [1], Jacob and I thought it might be a little more = robust to use an explicit signal.=C2=A0 I've posted a PR that adds a &q= uot;recovery" field to indicate to the server that it should not creat= e an account if one does not exist already.=C2=A0 Which is a little ironic = in a request to an endpoint designed to create an account, but saves us cre= ating a whole new endpoint.


    Please let m= e know if you have any comments on the approach here.

    <= div>Thanks,
    --Richard

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


    --001a114b3ef0ce4157054e2b1878-- From nobody Thu Apr 27 12:43: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 51B3F129BDB for ; Thu, 27 Apr 2017 12:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id twhrgs7UuCDG for ; Thu, 27 Apr 2017 12:43:46 -0700 (PDT) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3DED129BDE for ; Thu, 27 Apr 2017 12:40:17 -0700 (PDT) Received: by mail-wr0-x22a.google.com with SMTP id l50so22792254wrc.3 for ; Thu, 27 Apr 2017 12:40:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RiHCSWx1UDJ9CbIgbsdz1W1TmmsxAu2A3yKuqRC6zI0=; b=k2kUBEg2gNcpJlMpGPr3GRzChgA3DXXuYPdqTljKrLp/3pYQvmBsy34cXyWJi8VVtK 6tPA5DuBtDM4ZghjUKWti5pTq5greCvrIRdhTw+q9M77qfiU0Tw2KKQWmHVeH1bKNrwN 7Z8LTdm9GE9eXtf+5CnN7E+b7y5Xj5dBx7bKTVtRroW+bWGidoYv2Onj12QnlqwOKEsj pm+tpB7Q5q3wMYRL/UHklPQqBxVNMKRwMTYzHcX78NjSCVmKZXiPTsK6SD0GIQXju1qa OFBJi8OzGnpfONorysPMM3D3UMAHLu+oA1BbJfTS0E6+xahy3nhMo+5DUMI/rGqCbkF0 nuKw== 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=RiHCSWx1UDJ9CbIgbsdz1W1TmmsxAu2A3yKuqRC6zI0=; b=I6k1ntNwGP6cZNxm+ncJV6PSbiiKm32BnG81vKmnzXs5U4yGKQGM7GEZwpSx/UNdjj 1ivBbpXK1AzMEB+1QX7VswYyp12BoDgp4OzS8+5eGibb6xhJF2B7Skpk49O30LxMZ4LU 4157GZfcCYoMmudkLDSjdcBNqK6V31DvPGrcA9om7tqugthwdjoxG9gBoVnbQVgxrgoW DwW/hvYSz7lGu83GF6OXIFQ0CtIfOI38jAdMDwSZ0l0XCKegHTYqOxvRPdP3QC7Zuy+i QGlvvE9j8CimxLU2rsvMbwG9oFKOM9Y0Rz2tps/TnmyK7zgM61Rci5tO+mUinaNiWOZJ sEqg== X-Gm-Message-State: AN3rC/6mex6N0sVQHGmR5WYllSVtpZU+jU6oib68bSeXZHWN2gBon9EU /t5ChhAyybQ3VhY2/ob0LJvoahdBIjl8 X-Received: by 10.223.142.135 with SMTP id q7mr4852840wrb.180.1493322015702; Thu, 27 Apr 2017 12:40:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.136.84 with HTTP; Thu, 27 Apr 2017 12:40:15 -0700 (PDT) In-Reply-To: <20170418053400.GB18137@andover.lhh.devever.net> References: <20170418053400.GB18137@andover.lhh.devever.net> From: Richard Barnes Date: Thu, 27 Apr 2017 15:40:15 -0400 Message-ID: To: Hugo Landau Cc: "acme@ietf.org" Content-Type: multipart/alternative; boundary=f403045f4ec4481abe054e2b209f Archived-At: Subject: Re: [Acme] Account URI recovery X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 19:43:48 -0000 --f403045f4ec4481abe054e2b209f Content-Type: text/plain; charset=UTF-8 On Tue, Apr 18, 2017 at 1:34 AM, Hugo Landau wrote: > > In reviewing a PR today noting that a client can find the account URI > for > > a key pair using a new-account request with an empty payload [1], > Jacob > > and I thought it might be a little more robust to use an explicit > signal. > > I've posted a PR that adds a "recovery" field to indicate to the > server > > that it should not create an account if one does not exist already. > Which > > is a little ironic in a request to an endpoint designed to create an > > account, but saves us creating a whole new endpoint. > > [1]https://github.com/ietf-wg-acme/acme/pull/296 > I don't think this should be called recovery. It's too reminiscent of > the old removed account recovery mechanisms and will be confusing. > > How about "existing": true? > Good idea. To be extra clear, I think I'm going to with "only-return-existing". --f403045f4ec4481abe054e2b209f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


    On Tue, Apr 18, 2017 at 1:34 AM, Hugo Landau <hlandau@devever.net> wrote:
    >= =C2=A0 =C2=A0 In reviewing a PR today noting that a client can find the acc= ount URI for
    >=C2=A0 =C2=A0 a key pair using a new-account request with an empty payl= oad [1], Jacob
    >=C2=A0 =C2=A0 and I thought it might be a little more robust to use an = explicit signal.=C2=A0
    >=C2=A0 =C2=A0 I've posted a PR that adds a "recovery" fie= ld to indicate to the server
    >=C2=A0 =C2=A0 that it should not create an account if one does not exis= t already.=C2=A0 Which
    >=C2=A0 =C2=A0 is a little ironic in a request to an endpoint designed t= o create an
    >=C2=A0 =C2=A0 account, but saves us creating a whole new endpoint.
    >=C2=A0 =C2=A0 [1]    https://github.com/ietf-wg-= acme/acme/pull/296
    I don't think this should be called recovery. It's too reminiscent = of
    the old removed account recovery mechanisms and will be confusing.

    How about "existing": true?

    G= ood idea.=C2=A0 To be extra clear, I think I'm going to with "only= -return-existing".

    --f403045f4ec4481abe054e2b209f-- From nobody Thu Apr 27 14: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 92078129452 for ; Thu, 27 Apr 2017 14:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qSPZjknVvEz7 for ; Thu, 27 Apr 2017 14:19:02 -0700 (PDT) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::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 64131129BB2 for ; Thu, 27 Apr 2017 14:15:47 -0700 (PDT) Received: by mail-pf0-x22f.google.com with SMTP id v14so38009856pfd.2 for ; Thu, 27 Apr 2017 14:15:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UIhlTec7YYE5f0RsbVm7mKEBMH0xTTzFHb8xdPwRK+w=; b=a2UvbJwSRSPoOwvGO03SP3I3qHTxpt1fmvLC378/U0jEVKbS/dUyISPvM6Pt3SZkI+ yJn4PROqUH+wIIhBSTfk2/qLxp3YR1SX98Vj7RS8QqjC2SR9mPvAnHXZt6/ixGYnzbdb huu774z6WxJEDmqtdDJtVsBaB6P8rwvjuP013SjVwQCYCEySkC/doqX4DlgU+3M2K6n6 pOOch8ag6FGg73Bpb658AZxquAZVM/CPy+pg7oDgWQYDy+cp6Oy/PThUBDwioASnbNh7 RS4M8VbafIHvmUYkkkJ5bELbRF+EClI1u+0UuwOpLSII8tXhDj/J/P2r/CjwOvL3bz78 S6ug== 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=UIhlTec7YYE5f0RsbVm7mKEBMH0xTTzFHb8xdPwRK+w=; b=VMVnTiwPG88qrOzYxi7TCBLEJ/+qF/33mU0jGt+4LbAetm9lr9uCpvSR+9qfG0vYo5 VAaNJubJhuYmJ/BePQ3s6yasT1tda9CpekK8muPV+3Z2rAdFOG+Ll+Ci9niStGcszSPp Tx5p9YZHchKG9Jdsrp/gDXHzXW4hA5dtB2eoB7RxGTSqJ6iaqQYSj0VWLO1vuoLioLnO rSICYs9iT4TouTgfjxEcp9AmEqb9lM8FKtA6WS3LqDXYItbPKPyHP2iwumW9zLa9ipVh hKMYuB9OOnp4XcetuC9J67mUIZUffTSAbtMwZfxOVHndzP7tbJHXeGghWBjJorEkIWGg HIlQ== X-Gm-Message-State: AN3rC/6MaP214bL1MU0ihzNpWaoS5RSrsIdlHPzsX/HkFhAd0yAJ5JHu YfqlTL8TiM3/peJQa5d1dWUFgwegkA== X-Received: by 10.99.152.87 with SMTP id l23mr8088153pgo.59.1493327746777; Thu, 27 Apr 2017 14:15:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.157.133 with HTTP; Thu, 27 Apr 2017 14:15:46 -0700 (PDT) In-Reply-To: References: <20170418053400.GB18137@andover.lhh.devever.net> From: Logan Widick Date: Thu, 27 Apr 2017 16:15:46 -0500 Message-ID: To: Richard Barnes Cc: Hugo Landau , "acme@ietf.org" Content-Type: multipart/alternative; boundary=f403045ebdb0e15e1d054e2c7526 Archived-At: Subject: Re: [Acme] Account URI recovery X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 21:19:05 -0000 --f403045ebdb0e15e1d054e2c7526 Content-Type: text/plain; charset=UTF-8 What would the server return if "only-return-existing" is true and the account doesn't exist? On Thu, Apr 27, 2017 at 2:40 PM, Richard Barnes wrote: > > > On Tue, Apr 18, 2017 at 1:34 AM, Hugo Landau wrote: > >> > In reviewing a PR today noting that a client can find the account >> URI for >> > a key pair using a new-account request with an empty payload [1], >> Jacob >> > and I thought it might be a little more robust to use an explicit >> signal. >> > I've posted a PR that adds a "recovery" field to indicate to the >> server >> > that it should not create an account if one does not exist already. >> Which >> > is a little ironic in a request to an endpoint designed to create an >> > account, but saves us creating a whole new endpoint. >> > [1]https://github.com/ietf-wg-acme/acme/pull/296 >> I don't think this should be called recovery. It's too reminiscent of >> the old removed account recovery mechanisms and will be confusing. >> >> How about "existing": true? >> > > Good idea. To be extra clear, I think I'm going to with > "only-return-existing". > > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > > --f403045ebdb0e15e1d054e2c7526 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    What would the server return if "only-return-existing= " is true and the account doesn't exist?=C2=A0

    On Thu, Apr 27, 2017 at 2:40 PM= , Richard Barnes <rlb@ipv.sx> wrote:


    On Tue, Apr 18, 2017 at 1:34 AM, Hugo Landau <h= landau@devever.net> wrote:
    = >=C2=A0 =C2=A0 In reviewing a PR today noting that a client can fi= nd the account URI for
    >=C2=A0 =C2=A0 a key pair using a new-account request with an empty payl= oad [1], Jacob
    >=C2=A0 =C2=A0 and I thought it might be a little more robust to use an = explicit signal.=C2=A0
    >=C2=A0 =C2=A0 I've posted a PR that adds a "recovery" fie= ld to indicate to the server
    >=C2=A0 =C2=A0 that it should not create an account if one does not exis= t already.=C2=A0 Which
    >=C2=A0 =C2=A0 is a little ironic in a request to an endpoint designed t= o create an
    >=C2=A0 =C2=A0 account, but saves us creating a whole new endpoint.
    >=C2=A0 =C2=A0 [1]https://github.com/ietf-wg-= acme/acme/pull/296
    I don't think this should be called recovery. It's too reminiscent = of
    the old removed account recovery mechanisms and will be confusing.

    How about "existing": true?

    Good idea.=C2=A0 To be extra clear, I think I'm going to with &qu= ot;only-return-existing".


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


    --f403045ebdb0e15e1d054e2c7526-- From nobody Thu Apr 27 14:31:30 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46618129BA3 for ; Thu, 27 Apr 2017 14:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7x0Vv_4Clmas for ; Thu, 27 Apr 2017 14:31:26 -0700 (PDT) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::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 14EBD1296C9 for ; Thu, 27 Apr 2017 14:28:40 -0700 (PDT) Received: by mail-wr0-x22c.google.com with SMTP id l50so24026581wrc.3 for ; Thu, 27 Apr 2017 14:28:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Tif/XFhmJpP6KbwDrSxG2WGZ3yOyE50WPZ861aYh990=; b=EiqR33iWV8Xms9kTW+vPpy9Q7PwV4xPc5CweKReeVwo3oBhL1Ot7DgpwDwZesbrzfq 1B8mGh1SKgZZcACLkB2JPUKMVsW+sWUa3BnqGTjuW8QsiZ4EszIeECrUaT23oiR99mzJ txQbWbyQBuo8UVcT8sxmQ7PcdkfcJdFnYwUr9ijDRC5nKFSAZflOP/3iB4FVAT5k/P1u GxouG7US6qOp23keHN594o1q1aQ5Una1qlJkX7EoXac+yUgit3ZFGvRgdmFGAtkGvGDW xx0PEs1vgdZaW/kU11E088Evsc+jyLmeWuLzjiZyO48Nq9sWmy+P49vIcF/gAJpTaWDU bRLQ== 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=Tif/XFhmJpP6KbwDrSxG2WGZ3yOyE50WPZ861aYh990=; b=IpnD3Enf5E0uEKewl9//VUm8k8qjGJ+rqfCU4nUm1Sf5VOsatwBr9/4Trl5GXDwAvm s1UVsBrIM7oLB2rD0jxSo+QI+AqOFYYvg8+Rk+UQJH78b02XfGkK25NQLTNeoCo/II/P 7Sb7cjiisnI5TTb4RwpbSq0T/GJSmgclpgLFqlvYkHXC7e3Esj3PlaAIG5byDx8Bu7v4 VG8P9Pr392q9hDqO7Mv/CQbyamMnzI1C0pdfrbgc/RMJIAnNQiYKVQ8fEZFxI5ae74FS 6NUvela6WfVoc/CZcz15wm5FAnl+Y8jJshrLFLT3Nls5RSgudoQjq+wxL7bZ49wX0slr Z/Hw== X-Gm-Message-State: AN3rC/5nUGtSsHUVuGvoLD+ILwptUVpgaofMRmbnsHIWN9slecsiTnOM l10uZnVSm2WccRoANx18TOSkfKiqpA== X-Received: by 10.223.142.135 with SMTP id q7mr5110403wrb.180.1493328518279; Thu, 27 Apr 2017 14:28:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.136.84 with HTTP; Thu, 27 Apr 2017 14:28:37 -0700 (PDT) In-Reply-To: References: <20170329195427.GA23764@LK-Perkele-V2.elisa-laajakaista.fi> <525f79bb-a2e6-bf09-30e5-e80e0bb80379@eff.org> <3a9aaca8-204c-2a6c-2fc5-f74870effc2e@eff.org> <72CD4CDB-51BD-410C-908D-478AFB4A9411@seantek.com> From: Richard Barnes Date: Thu, 27 Apr 2017 17:28:37 -0400 Message-ID: To: Jacob Hoffman-Andrews Cc: Sean Leonard , ACME WG , Ilari Liusvaara Content-Type: multipart/alternative; boundary=f403045f4ec4ddac2c054e2ca3e8 Archived-At: Subject: Re: [Acme] draft-ietf-acme-acme-06: Don't call it PEM Certificate Chain X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 21:31:28 -0000 --f403045f4ec4ddac2c054e2ca3e8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Based on Jacob's research, I'm pretty well convinced that this is not an issue. Nonetheless, I have posted a PR to add some text about this risk. https://github.com/ietf-wg-acme/acme/pull/306 On Thu, Apr 27, 2017 at 12:55 AM, Jacob Hoffman-Andrews wrote: > On 03/30/2017 09:04 AM, Sean Leonard wrote: > > IN PARTICULAR: both Apache and Ngnix may be subject to a private key > substitution attack with naive passing of the ACME response to the web > server! See: > http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_certificate > http://httpd.apache.org/docs/current/mod/mod_ssl.html#sslcertificatefile > > The SSL Certificate option includes the option of including the private > key in the same input: =E2=80=9CA secret key in the PEM format may be pla= ced in > the same file.=E2=80=9D > > I tried to reproduce this, and I believe you are incorrect that a private > key substitution attack works. > > For both Nginx and Apache, I created a file containing a PEM-encoded > certificate, and appended a PEM-encoded RSA private key corresponding to > the public key in the certificate. I then placed a different PEM-encoded > RSA private key in cert-key.pem. I configured the certificate with > ssl_certificate or SSLCertificateFile, respectively, and the key with > ssl_certificate_key or SSLCertificateKeyFile, respectively. For Apache, I > got: > > [Wed Apr 26 21:45:50.094519 2017] [ssl:emerg] [pid 10967] AH02565: > Certificate and private key ocsp.test.wtf:8443:0 from > /home/jsha/ocsp-stapling-examples/cert.pem and /home/jsha/ocsp-stapling-e= xamples/cert-key.pem > do not match > AH00016: Configuration Failed > > For Nginx, I got: > > 2017/04/26 21:51:48 [emerg] 11164#11164: SSL_CTX_use_PrivateKey_file("./c= ert-key.pem") > failed (SSL: error:0B080074:x509 certificate routines:X509_check_private_= key:key > values mismatch) > > In neither case did the server successfully start up. Absent the private > key substitution attack, I don't see a strong argument against offering > certificates and chains in the very common PEM format by default. > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > > --f403045f4ec4ddac2c054e2ca3e8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Based on Jacob's research, I'm pretty well co= nvinced that this is not an issue.=C2=A0 Nonetheless, I have posted a PR to= add some text about this risk.



    On Thu, Apr 27, 2017 at 12:55 AM, Jacob Hoffman-Andrews <jsha@= eff.org> wrote:
    =20 =20 =20
    On 03/30/2017 09:04 AM, Sean Leonard wrote:
    IN PARTICULAR: both A= pache and Ngnix may be subject to a private key substitution attack with naive passing of the ACME response to the web server! See:

    The SSL Certificate option includes the option of including the private key in the same input: =E2=80=9CA secret key in the PEM format may be placed in the same file.=E2=80= =9D
     I tried to reproduce this, and I believe you are incorrect that a private key substitution attack works.

    For both Nginx and Apache, I created a file containing a PEM-encoded certificate, and appended a PEM-encoded RSA private key corresponding to the public key in the certificate. I then placed a different PEM-encoded RSA private key in cert-key.pem. I configured the certificate with ssl_certificate or SSLCertificateFile, respectively, and the key with ssl_certificate_key or SSLCertificateKeyFile, respectively. For Apache, I got:

    [Wed Apr 26 21:45:50.094519 2017] [ssl:emerg] [pid 10967] AH02565: Certificate and private key ocsp.test.wtf:8443:0 from /home/jsha/ocsp-stapling-examples/cert.pem and /home/jsha/ocsp-stapling-examples/cert-key.pem do not match
    AH00016: Configuration Failed

    For Nginx, I got:

    2017/04/26 21:51:48 [emerg] 11164#11164: SSL_CTX_use_PrivateKey_file("./cert-key.pem") failed (SS= L: error:0B080074:x509 certificate routines:X509_check_private_key:ke= y values mismatch)

    In neither case did the server successfully start up. Absent the private key substitution attack, I don't see a strong argument against offering certificates and chains in the very common PEM format by default.

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


    --f403045f4ec4ddac2c054e2ca3e8-- From nobody Thu Apr 27 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 B2AEC129B60 for ; Thu, 27 Apr 2017 14:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.091 X-Spam-Level: X-Spam-Status: No, score=0.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 68QWdijE6EnM for ; Thu, 27 Apr 2017 14:36:56 -0700 (PDT) Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C922A129B6A for ; Thu, 27 Apr 2017 14:34:02 -0700 (PDT) Received: by mail-wr0-x22e.google.com with SMTP id z52so24169115wrc.2 for ; Thu, 27 Apr 2017 14:34:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WtyKUsiaYM5gzlta/r5pofmvHqfaEYRuDWMxeMDkQJY=; b=V+hfmS3B2E/DiLFhOpgu2LnLKePgeII7lhCIAlWWeghrSfdfUcCw9xe5GGuDwYVxSz eIE0hkvXeVuR4HORY+fNlK92PFMJeaGLgByf6RHTK438q92JD5m1pJQCBG6zwH9dHixc qmrJodzViYKkXMWuaQQ41IcT1lVd3mIEzm+r7U/uZLnGfOmtotQi0eAlobee9BD2Dc0R XP39PgZaLJ70sovwsFeX46db1azNPe1Sw3mcBLE4P+XhMs1DVmsu9ZzJe1Lb/f2qJ6Fh hYTnbC4hjAJ15MsYGhHlRqf1iA5mzjlSSiGb03rPDU76zwNTeREJeaGStVov9gV5EFYS 1Skw== 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=WtyKUsiaYM5gzlta/r5pofmvHqfaEYRuDWMxeMDkQJY=; b=oxC613/i9N3dgzXZ9ItAb5vR7yet+qpISN4nzLH3cSKSNEdVLvA9oRnJLNGsPwUDBN i425DqLk/IV1fwCPa74weatoyreH9bfQpRlOPA8yUo7PCNhe/JLrKOtqOSob/9cE21ti WUBxneNUpzl0/kym0DvfPtUzLoBCHP28noOiDdJLPc9CkwX8tN4K6UAV9lBFCg6yPvM3 WKNsf6sSlYjDB2O1yzoKmS7VAMKQY600fw5vnClFs2c1YK6c/jryRS83kfOXhhy4rU8g Tz1bs2NNWDc7/5gFKKuSGvHNb5Gev0SKkrW5I6kADtURNUnZW1gQrmeo7iqKWjEgJLNp o0vA== X-Gm-Message-State: AN3rC/6lqaG/p6+TFVcmp0niYEEI6aVv+8yYJcxO6hqlZmSfni/fTTMj M8iaSxfN7ML1rWW43+aSuTSV5QFjXw== X-Received: by 10.223.136.134 with SMTP id f6mr4868737wrf.187.1493328840967; Thu, 27 Apr 2017 14:34:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.136.84 with HTTP; Thu, 27 Apr 2017 14:34:00 -0700 (PDT) In-Reply-To: References: From: Richard Barnes Date: Thu, 27 Apr 2017 17:34:00 -0400 Message-ID: To: Logan Widick Cc: Zach Shepherd , ACME WG Content-Type: multipart/alternative; boundary=001a11461db2195fd7054e2cb742 Archived-At: Subject: Re: [Acme] Multiple Accounts with Same Key X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 21:36:59 -0000 --001a11461db2195fd7054e2cb742 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree we should forbid this behavior. Draft PR specifying an HTTP error code but not an ACME one: https://github.com/ietf-wg-acme/acme/pull/307 On Thu, Apr 20, 2017 at 7:02 PM, Logan Widick wrote: > So there would need to be a new error type (possibly named something like > "accountKeyCollision")? > > If so, what would be the right HTTP code? 400 (Bad Request)? Or something > else? > > On receiving the error, should the client either generate a different key > to change to or use the account URL recovery mechanism? > > Would the desired response change if the key clash involved a deactivated > account (whether by client or CA) instead of an active one? > > On Thu, Apr 20, 2017 at 3:29 PM, Zach Shepherd > wrote: > >> Given that account recovery is based on key (with or without #294 >> ), it seems like >> allowing multiple accounts to coexist with the same key would be >> problematic. >> >> >> It also seems like attempting to create a second account with the same >> key would almost always indicate user- or client-error. >> >> Responding with an error seems best, but no existing error type seems >> appropriate. >> >> ------------------------------ >> *From:* Acme on behalf of Logan Widick < >> logan.widick@gmail.com> >> *Sent:* Thursday, April 20, 2017 9:35 AM >> *To:* ACME WG >> *Subject:* [Acme] Multiple Accounts with Same Key >> >> All, >> >> How should a server respond if a client is trying to perform an action >> that would result in multiple active accounts having the same account ke= y? >> For example: >> >> - Sending a key-change request with a newKey that is already in use >> by another account >> - (If https://github.com/ietf-wg-acme/acme/issues/294 >> is >> merged into master) Sending a new-account request (that doesn't have = the >> new "recovery" field or has the new field set to false) with a key th= at is >> already used by another account >> >> Should the server respond with an error code? Allow multiple accounts >> with the same key to coexist? Do something else? >> >> Sincerely, >> >> Logan Widick >> > > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > > --001a11461db2195fd7054e2cb742 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    I agree we should forbid this behavior.=C2=A0 Draft P= R specifying an HTTP error code but not an ACME one:

    https://github= .com/ietf-wg-acme/acme/pull/307

    On Thu, Apr 20, 2017 at 7:02 PM, Logan W= idick <logan.widick@gmail.com> wrote:
    So there would need to be a new error typ= e (possibly named something like "accountKeyCollision")?=C2=A0
    If so, what would be the right HTTP code? 400 (Bad Request= )? Or something else?=C2=A0

    On receiving the error= , should the client either generate a different key to change to or use the= account URL recovery mechanism?

    Would the desired= response change if the key clash involved a deactivated account (whether b= y client or CA) instead of an active one?=C2=A0

    On Thu, Apr 20, 2017 at 3:29 PM, Zach Shepherd <= ;shepherdz@vmware= .com> wrote:

    Given that account recovery is based on key (with or without=C2=A0#29= 4), it seems like allowing multiple accounts to coexist with the same k= ey would be problematic.


    It also seems like attempting to create a second account with the same k= ey would almost always indicate user- or client-error.


    Responding with an error seems best, but no existing error type seems ap= propriate.


    From: Acme <acme-bounces@ietf.org> on behalf of Logan Widick &= lt;logan.widick= @gmail.com>
    Sent: Thursday, April 20, 2017 9:35 AM
    To: ACME WG
    Subject: [Acme] Multiple Accounts with Same Key
    =C2=A0
    All,=C2=A0

    How should a server respond if a client is trying to perform an action= that would result in multiple active accounts having the same account key?= For example:=C2=A0
    • Sending a key-change request with a newKey that is already in use by an= other account
    • (If https://github.com/ietf-wg-acme/acme/issues/294=C2=A0is merged int= o master) Sending a new-account request (that doesn't have the new &quo= t;recovery" field or has the new field set to false) with a key that i= s already used by another account
    Should the server respond with an error code? Allow multiple accounts = with the same key to coexist? Do something else?=C2=A0

    Sincerely,=C2=A0

    Logan Widick


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


    --001a11461db2195fd7054e2cb742-- From nobody Thu Apr 27 14:42:01 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04AFF127A90 for ; Thu, 27 Apr 2017 14:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pEvMV4WllLEh for ; Thu, 27 Apr 2017 14:41:56 -0700 (PDT) Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 827EB129BDE for ; Thu, 27 Apr 2017 14:38:58 -0700 (PDT) Received: by mail-wr0-x236.google.com with SMTP id l9so24206309wre.1 for ; Thu, 27 Apr 2017 14:38:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=p+8vGeR4aWk1ZP7iTWrynRKN+R62tTQ6p5z3VUUX+0g=; b=Mar4vKhJLsYbmV9gs4gGRxQxVpIeMMQfKM6LhG2esVmcfje3EEFhVFeyBjYw2Krb0u GhS+xbcYYCBkwBdBaf1qZgRRrBV/DljzMnu7j99z2iJAyNWb6DoIoUk67iQPybTT5DMR 85chUEVZxWgSyADkYq2nns2ulNf48gKYDYuQ1rmdSW7hFaR0A99vgfbLf00l+KoiPqqV PF1CNvZzjTlKrxPS0erXBE6GoEVHOcUZzKO6V3Ov2gMavPG2+kymX+TxUu6h6W3GbR8y JzV9vW59rb7DYFjbpLvzBcCZ746hno1DdvxGwjVz6k0T8qdKM1Cp+fnK2XhYluc7Rdiq e5gA== 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=p+8vGeR4aWk1ZP7iTWrynRKN+R62tTQ6p5z3VUUX+0g=; b=VzZckBCOD8HtWwkPFHKBx+rJYJSntpHojm5d7Om8E4v0IapYYUu1WPWj4EfVrb7WrB YcLfshEpsfOtQ6lkU9APQsD6FYIxs2Uk8ky2N+3rS75X1CV0SxUnJUvUs8ChRtaizhnK 5bnj05i9QA3v0mewnq0WBm+E/rySxlkK29Ed9c8rcuWW0cvHX/ZMsH/fZeyw+Ss784Au Ru82snLcpKjcD92wzg3/FfXpSwPoQNuAECnkTpgQP0/9QQzH8hNdQtXVcK9HlkbH60eh lfSbYhUboLTl7UitU28PZNhlLxOzo/I6MX4nqldqP5xXPTKSuE2PCnGuHjPe4rk2nJbW AmRA== X-Gm-Message-State: AN3rC/5JbE6EeSrWPeiPyCyDjYJug2HaUnNAZHpXOmvLDRT/09h9yw8B XnPIk0xx4PgVUzPzPt7k8DbzY19MOA== X-Received: by 10.223.142.135 with SMTP id q7mr5133292wrb.180.1493329136836; Thu, 27 Apr 2017 14:38:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.136.84 with HTTP; Thu, 27 Apr 2017 14:38:56 -0700 (PDT) In-Reply-To: References: <20170418053400.GB18137@andover.lhh.devever.net> From: Richard Barnes Date: Thu, 27 Apr 2017 17:38:56 -0400 Message-ID: To: Logan Widick Cc: Hugo Landau , "acme@ietf.org" Content-Type: multipart/alternative; boundary=f403045f4ec4bbe3d8054e2cc80b Archived-At: Subject: Re: [Acme] Account URI recovery X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 21:41:59 -0000 --f403045f4ec4bbe3d8054e2cc80b Content-Type: text/plain; charset=UTF-8 How about if it just returns 200 with no URL? That way the client can just look at the Location field to see whether an account exists or not. https://github.com/ietf-wg-acme/acme/pull/308 On Thu, Apr 27, 2017 at 5:15 PM, Logan Widick wrote: > What would the server return if "only-return-existing" is true and the > account doesn't exist? > > On Thu, Apr 27, 2017 at 2:40 PM, Richard Barnes wrote: > >> >> >> On Tue, Apr 18, 2017 at 1:34 AM, Hugo Landau wrote: >> >>> > In reviewing a PR today noting that a client can find the account >>> URI for >>> > a key pair using a new-account request with an empty payload [1], >>> Jacob >>> > and I thought it might be a little more robust to use an explicit >>> signal. >>> > I've posted a PR that adds a "recovery" field to indicate to the >>> server >>> > that it should not create an account if one does not exist >>> already. Which >>> > is a little ironic in a request to an endpoint designed to create an >>> > account, but saves us creating a whole new endpoint. >>> > [1]https://github.com/ietf-wg-acme/acme/pull/296 >>> I don't think this should be called recovery. It's too reminiscent of >>> the old removed account recovery mechanisms and will be confusing. >>> >>> How about "existing": true? >>> >> >> Good idea. To be extra clear, I think I'm going to with >> "only-return-existing". >> >> >> _______________________________________________ >> Acme mailing list >> Acme@ietf.org >> https://www.ietf.org/mailman/listinfo/acme >> >> > --f403045f4ec4bbe3d8054e2cc80b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    How about if it just returns 200 with no URL?=C2=A0 T= hat way the client can just look at the Location field to see whether an ac= count exists or not.


    On Thu, Apr 27, 2017 at 5:15 PM, Logan Widick <logan.widick@gmail.c= om> wrote:
    What would the server return if "only-return-existing" is true a= nd the account doesn't exist?=C2=A0
    On Thu, Apr 27, 2017 at = 2:40 PM, Richard Barnes <rlb@ipv.sx> wrote:


    On Tue, Apr 18, 201= 7 at 1:34 AM, Hugo Landau <hlandau@devever.net> wrote:
    =
    >=C2=A0 =C2=A0 In reviewing a PR to= day noting that a client can find the account URI for
    >=C2=A0 =C2=A0 a key pair using a new-account request with an empty payl= oad [1], Jacob
    >=C2=A0 =C2=A0 and I thought it might be a little more robust to use an = explicit signal.=C2=A0
    >=C2=A0 =C2=A0 I've posted a PR that adds a "recovery" fie= ld to indicate to the server
    >=C2=A0 =C2=A0 that it should not create an account if one does not exis= t already.=C2=A0 Which
    >=C2=A0 =C2=A0 is a little ironic in a request to an endpoint designed t= o create an
    >=C2=A0 =C2=A0 account, but saves us creating a whole new endpoint.
    >=C2=A0 =C2=A0 [1]https://github.com/ietf-wg-= acme/acme/pull/296
    I don't think this should be called recovery. It's too reminiscent = of
    the old removed account recovery mechanisms and will be confusing.

    How about "existing": true?

    Good idea.=C2=A0 To be extra clear, I think I'm going to with &qu= ot;only-return-existing".


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



    --f403045f4ec4bbe3d8054e2cc80b-- From nobody Thu Apr 27 23:38: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 BD168128792 for ; Thu, 27 Apr 2017 23:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xrobBSmqAqFc for ; Thu, 27 Apr 2017 23:38:44 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2947129C6A for ; Thu, 27 Apr 2017 23:36:00 -0700 (PDT) Received: from [192.168.123.171] (unknown [76.90.60.238]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 05DC622E1F3; Fri, 28 Apr 2017 02:35:52 -0400 (EDT) From: Sean Leonard Message-Id: <75E3C7A5-D049-4E55-A0FB-A3AEC3A89726@seantek.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_237F017C-4548-4AD4-BEE0-E8CFE5FAFCAA" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 27 Apr 2017 23:35:51 -0700 In-Reply-To: Cc: Richard Barnes , Niklas Keller , ACME WG To: Logan Widick References: <083b73a4-a199-dc57-e078-bf1bf9c10bd2@seantek.com> <9f046557-fe26-faad-30b3-7f721851cb5b@seantek.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Acme] "Slide 21" follow-up (textual encoding question) PART 2 X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 06:38:47 -0000 --Apple-Mail=_237F017C-4548-4AD4-BEE0-E8CFE5FAFCAA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 19, 2017, at 9:44 PM, Logan Widick = wrote: >=20 >=20 >=20 > On Apr 3, 2017 16:07, "Sean Leonard" > wrote: > On 4/3/2017 5:54 AM, Logan Widick wrote: >> I think that having separate URIs to reduce bloat is a good idea. I = understand that the client needs to send the CSR as a field in the = new-order request payload for security. However, in the server response, = could the CSR be a URI that would allow the client to retrieve the CSR = that the client submitted in DER format? So, could new-order requests = look like:=20 >>=20 >> { >> csr: "base64url(derEncodedCSR)" >> //rest of fields in new-order here >> } >>=20 >> And the server's order response look like: >> { >> csrLink: "[link to DER encoded CSR]" >> certificate: "[link to DER encoded certificate]" >> chains: [array of links to chains as suggested by Niklas] >> //rest of fields in order response here (except for "csr") >> } >=20 > The wrinkle with this proposal is that CSRs are likely non-public = data. They could contain personally identifiable information in the = metadata, or other random stuff. It is undesirable to have a link that = has to be maintained for the lifetime of the order history, which could = be harvested by search engines or otherwise made public. Typically CAs = harvest the public key and discard the rest (after verifying the = authenticity of the CSR). Therefore, I am not in favor of URIs for CSR = data. >=20 > Since CAs would harvest data from CSRs and then discard the rest after = authenticity checks, and the identifiers would appear elsewhere (in the = authorizations), could the "csr" field apply to the new-order request = and be absent from the order object?=20 They =E2=80=9Ccould=E2=80=9D be. But, I think the point of keeping the = CSR around is partially for reference purposes. I am aware of web = servers that keep the CSR around for users (customers) to stash. >=20 >=20 > The case for URIs for issued end-entity certificates is half-half. = Certificates are public documents, but it's an extra round-trip and you = have to save the same amount of state on the client side (i.e., the = certificate URI). >=20 > The case for URI(s) for CA certificates in the validation chain is = strongest, since they are unlikely to change and are reused across many = customers. Basically "de-duplication". On the other hand, there are = business/usability advantages to packaging up "everything you need to = run your web server" in one neat package.=20 >=20 > When certificates are embedded in order objects, won't the order = objects get quite large? They will get larger, but it=E2=80=99s not clear that the size is really = going to be an issue. The client has to download the certificates anyway = eventually. It is (arguably) more bookkeeping to store them separately, = e.g., via separate URIs. >>=20 >> For consistency, I think the chain links (when retrieved) should be = concatenated DER.=20 >=20 > I am in favor of DER. :) (But less sure about whether links are = desirable in the first place.) >=20 > I could have sworn that when certificate retrieval is done over the = wire, CMS (PKCS #7) is an IETF standardized type for blobs of = certificates. Oh yeah, here it is: > RFC 5280 Section 4.2.2.1 (it's repeated elsewhere): > HTTP server implementations accessed via the URI SHOULD specify the > media type application/pkix-cert [RFC2585 = ] in the content-type header > field of the response for a single DER encoded certificate and = SHOULD > specify the media type application/pkcs7-mime [RFC2797 = ] in the > content-type header field of the response for "certs-only" CMS > messages. For FTP, the name of a file that contains a single DER > encoded certificate SHOULD have a suffix of ".cer" [RFC2585 = ] and the > name of a file that contains a "certs-only" CMS message SHOULD have = a > suffix of ".p7c" [RFC2797 ]. = Consuming clients may use the media type > or file extension as a hint to the content, but should not depend > solely on the presence of the correct media type or file extension = in > the server response. >=20 >=20 > Just sayin'... ;-) >=20 > It is worth pointing out that PKCS #7 / CMS "certs-only", amounts to = concatenated DER certificates plus a little bit of goo at the beginning = and end (which can be ignored/skipped). Here is a dump of a .p7s file I = have lying around using asn1js: >=20 > SEQUENCE(2 elem) > OBJECT IDENTIFIER1.2.840.113549.1.7.2 > [0](1 elem) > SEQUENCE(5 elem) > INTEGER1 > SET(0 elem) > SEQUENCE(1 elem) > OBJECT IDENTIFIER1.2.840.113549.1.7.1 > [0](3 elem) > SEQUENCE(3 elem) > SEQUENCE(3 elem) > SEQUENCE(3 elem) > SET(0 elem) >=20 > In this case, the SEQ -> [0] -> SEQ -> [0] has three certificates, = which start with SEQUENCE. Rip and go. >=20 > Finally, here is how you convert from p7s to textual certificates: > openssl pkcs7 -inform DER -in yourfile.p7s -print_certs >=20 > The advantage of the command-line/OpenSSL recipe above, is that you = are guaranteed that the output will only be -----BEGIN CERTIFICATE----- = things. Non-certificates shall not pass. >=20 > That already standardized type would be better.=20 Great. My point here is to keep with what already exists. Regards, Sean --Apple-Mail=_237F017C-4548-4AD4-BEE0-E8CFE5FAFCAA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
    On Apr 19, 2017, at 9:44 PM, Logan Widick <logan.widick@gmail.com> wrote:



    On Apr 3, 2017 16:07, "Sean = Leonard" <dev+ietf@seantek.com> wrote:
    =20 =20 =20
    On 4/3/2017 5:54 = AM, Logan Widick wrote:
    I think that having separate URIs to reduce = bloat is a good idea. I understand that the client needs to send the CSR as a field in the new-order request payload for security. However, in the server response, could the CSR be a URI that would allow the client to retrieve the CSR that the client submitted in DER format? So, could new-order requests look = like: 

    {
    csr: = "base64url(derEncodedCSR)"
    //rest of fields in new-order = here
    }

    And the server's order response look like:
    {
    csrLink: "[link to DER encoded CSR]"
    certificate: "[link to = DER encoded certificate]"
    chains: [array of = links to chains as suggested by Niklas]
    //rest of fields in = order response here (except for "csr")
    }

    The wrinkle with this proposal is that CSRs are likely non-public data. They could contain personally identifiable information in the metadata, or other random stuff. It is undesirable to have a link that has to be maintained for the lifetime of the order history, which could be harvested by search engines or otherwise made public. Typically CAs harvest the public key and discard the rest (after verifying the authenticity of the CSR). Therefore, I am not in favor of URIs for CSR data.

    Since CAs = would harvest data from CSRs and then discard the rest after = authenticity checks, and the identifiers would appear elsewhere (in the = authorizations), could the "csr" field apply to the new-order request = and be absent from the order = object? 

    They =E2=80=9Ccould=E2=80=9D be. But, I think the = point of keeping the CSR around is partially for reference purposes. I = am aware of web servers that keep the CSR around for users (customers) = to stash.



    The case for URIs for issued end-entity certificates is half-half. Certificates are public documents, but it's an extra round-trip and you have to save the same amount of state on the client side (i.e., the certificate URI).

    The case for URI(s) for CA certificates in the validation chain is strongest, since they are unlikely to change and are reused across many customers. Basically "de-duplication". On the other hand, there are business/usability advantages to packaging up "everything you need to run your web server" in one neat = package. 

    When certificates are embedded in order objects, won't the = order objects get quite = large?

    They will get larger, but it=E2=80=99s not clear = that the size is really going to be an issue. The client has to download = the certificates anyway eventually. It is (arguably) more bookkeeping to = store them separately, e.g., via separate URIs.


    For consistency, I = think the chain links (when retrieved) should be concatenated DER.

    I am in favor of DER. :) (But less sure about whether links are desirable in the first place.)

    I could have sworn that when certificate retrieval is done over the wire, CMS (PKCS #7) is an IETF standardized type for blobs of certificates. Oh yeah, here it is:
    RFC 5280 Section 4.2.2.1 (it's repeated elsewhere):
       HTTP server implementations =
accessed via the URI SHOULD specify the
   media type application/pkix-cert [RFC2585] in the =
content-type header
   field of the response for a single DER encoded certificate and SHOULD
   specify the media type application/pkcs7-mime [RFC2797] in the
   content-type header field of the response for "certs-only" CMS
   messages.  For FTP, the name of a file that contains a single DER
   encoded certificate SHOULD have a suffix of ".cer" [RFC2585] and the
   name of a file that contains a "certs-only" CMS message SHOULD have a
   suffix of ".p7c" [RFC2797].  Consuming clients may use =
the media type
   or file extension as a hint to the content, but should not depend
   solely on the presence of the correct media type or file extension in
   the server response.


    Just sayin'... ;-)

    It is worth pointing out that PKCS #7 / CMS "certs-only", amounts to concatenated DER certificates plus a little bit of goo at the beginning and end (which can be ignored/skipped). Here is a dump of a .p7s file I have lying around using asn1js:

    SEQUENCE(2 = elem)
    OBJECT IDENTIFIER1.2.840.1= 13549.1.7.2
    [0= ](1 = elem)
    SE= QUENCE(5 = elem)
    INTEGER1<= /div>
    SET(0 elem)
    SEQUENCE(1 = elem)
    OBJECT IDENTIFIER1.2.840.1= 13549.1.7.1
    [0= ](3 = elem)
    SEQUEN= CE(3 = elem)
    SEQUENCE(3 = elem)
    SEQUENCE(3 = elem)
    SET(0 elem)

    In this case, the SEQ -> [0] -> SEQ -> [0] has three certificates, which start with SEQUENCE. Rip and go.

    Finally, here is how you convert from p7s to textual = certificates:
      openssl pkcs7 -inform DER -in yourfile.p7s = -print_certs

    The advantage of the command-line/OpenSSL recipe above, is that you are guaranteed that the output will only be -----BEGIN CERTIFICATE----- things. Non-certificates shall not = pass.
    That already standardized = type would be better. 

    Great. My point here is to keep with what already = exists.

    Regards,

    Sean

    = --Apple-Mail=_237F017C-4548-4AD4-BEE0-E8CFE5FAFCAA-- From nobody Thu Apr 27 23:55: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 7C0801201F8 for ; Thu, 27 Apr 2017 23:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5fMasI1dOmNE for ; Thu, 27 Apr 2017 23:55:07 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E28E9128B91 for ; Thu, 27 Apr 2017 23:52:31 -0700 (PDT) Received: from [192.168.123.171] (unknown [76.90.60.238]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4EA6522E256; Fri, 28 Apr 2017 02:52:30 -0400 (EDT) From: Sean Leonard Message-Id: <1EF494C1-B55A-40FF-B261-EE5823A06902@seantek.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_3613778C-CA94-432D-80D4-821F1F09CD51" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 27 Apr 2017 23:52:28 -0700 In-Reply-To: Cc: ACME WG , Ilari Liusvaara To: Jacob Hoffman-Andrews References: <20170329195427.GA23764@LK-Perkele-V2.elisa-laajakaista.fi> <525f79bb-a2e6-bf09-30e5-e80e0bb80379@eff.org> <3a9aaca8-204c-2a6c-2fc5-f74870effc2e@eff.org> <72CD4CDB-51BD-410C-908D-478AFB4A9411@seantek.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Acme] draft-ietf-acme-acme-06: Don't call it PEM Certificate Chain X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 06:55:09 -0000 --Apple-Mail=_3613778C-CA94-432D-80D4-821F1F09CD51 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 26, 2017, at 9:55 PM, Jacob Hoffman-Andrews = wrote: >=20 > On 03/30/2017 09:04 AM, Sean Leonard wrote: >> IN PARTICULAR: both Apache and Ngnix may be subject to a private key = substitution attack with naive passing of the ACME response to the web = server! See: >> = http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_certificate = >> = http://httpd.apache.org/docs/current/mod/mod_ssl.html#sslcertificatefile = = >>=20 >> The SSL Certificate option includes the option of including the = private key in the same input: =E2=80=9CA secret key in the PEM format = may be placed in the same file.=E2=80=9D > I tried to reproduce this, and I believe you are incorrect that a = private key substitution attack works. >=20 > For both Nginx and Apache, I created a file containing a PEM-encoded = certificate, and appended a PEM-encoded RSA private key corresponding to = the public key in the certificate. I then placed a different PEM-encoded = RSA private key in cert-key.pem. I configured the certificate with = ssl_certificate or SSLCertificateFile, respectively, and the key with = ssl_certificate_key or SSLCertificateKeyFile, respectively. For Apache, = I got: >=20 > [Wed Apr 26 21:45:50.094519 2017] [ssl:emerg] [pid 10967] AH02565: = Certificate and private key ocsp.test.wtf:8443:0 from = /home/jsha/ocsp-stapling-examples/cert.pem and = /home/jsha/ocsp-stapling-examples/cert-key.pem do not match > AH00016: Configuration Failed >=20 > For Nginx, I got: >=20 > 2017/04/26 21:51:48 [emerg] 11164#11164: = SSL_CTX_use_PrivateKey_file("./cert-key.pem") failed (SSL: = error:0B080074:x509 certificate routines:X509_check_private_key:key = values mismatch) >=20 > In neither case did the server successfully start up. Okay. So, on the contrary, your tests show: a) a viable DoS attack, and = b) that OpenSSL (Apache and Nginix) recognize non-certificate content in = the SSLCertificateFile. Which goes directly to the point of sanitizing = inputs. But this is only one implementation (OpenSSL): it doesn=E2=80=99t = say anything about the other implementations that I pointed out. What do your tests show when you leave SSLCertificateKeyFile empty, or = provide blank input for it? What if you change the order of the BEGIN = CERTIFICATE and BEGIN [RSA] PRIVATE KEY? What if you change the content = so that BEGIN CERTIFICATE actually contains a private key, or = vice-versa? =E2=80=9CQA Engineer Orders a Beer=E2=80=9D https://twitter.com/sempf/status/514473420277694465 *** I would rather sidestep the issue of what format to put the certificate = response in, by putting the certificates directly into the JSON ACME = order object. I have not seen any arguments against that premise (except = for =E2=80=9Csize=E2=80=9D) and several arguments in favor of it. Sean --Apple-Mail=_3613778C-CA94-432D-80D4-821F1F09CD51 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
    On Apr 26, 2017, at 9:55 PM, Jacob Hoffman-Andrews <jsha@eff.org> = wrote:

    =20 =20
    On 03/30/2017 09:04 AM, Sean Leonard wrote:
    IN PARTICULAR: both Apache and Ngnix may be = subject to a private key substitution attack with naive passing of the ACME response to the web server! See:
    http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_cert= ificate
    http://httpd.apache.org/docs/current/mod/mod_ssl.html#sslcertif= icatefile

    The SSL Certificate option includes the option = of including the private key in the same input: =E2=80=9CA secret key in the PEM format may be placed in the same = file.=E2=80=9D
    I tried to reproduce this, and I believe you are incorrect that a private key substitution attack works.

    For both Nginx and Apache, I created a file containing a PEM-encoded certificate, and appended a PEM-encoded RSA private key corresponding to the public key in the certificate. I then placed a different PEM-encoded RSA private key in cert-key.pem. I configured the certificate with ssl_certificate or SSLCertificateFile, respectively, and the key with ssl_certificate_key or SSLCertificateKeyFile, respectively. For Apache, I got:
    =
    [Wed Apr 26 21:45:50.094519 2017] [ssl:emerg] [pid 10967] AH02565: Certificate and private key ocsp.test.wtf:8443:0 from /home/jsha/ocsp-stapling-examples/cert.pem and /home/jsha/ocsp-stapling-examples/cert-key.pem do not match
    AH00016: Configuration Failed

    For Nginx, I got:

    2017/04/26 21:51:48 [emerg] 11164#11164: SSL_CTX_use_PrivateKey_file("./cert-key.pem") failed (SSL: error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch)

    In neither case did the server successfully start = up.

    Okay. So, on = the contrary, your tests show: a) a viable DoS attack, and b) that = OpenSSL (Apache and Nginix) recognize non-certificate content in the = SSLCertificateFile. Which goes directly to the point of sanitizing = inputs. But this is only one implementation (OpenSSL): it doesn=E2=80=99t = say anything about the other implementations that I pointed = out.

    What do your tests show when = you leave SSLCertificateKeyFile empty, or provide blank input for it? = What if you change the order of the BEGIN CERTIFICATE and BEGIN [RSA] = PRIVATE KEY? What if you change the content so that BEGIN CERTIFICATE = actually contains a private key, or vice-versa?

    =E2=80=9CQA Engineer Orders a = Beer=E2=80=9D


    ***

    I would = rather sidestep the issue of what format to put the certificate response = in, by putting the certificates directly into the JSON ACME order = object. I have not seen any arguments against that premise (except for = =E2=80=9Csize=E2=80=9D) and several arguments in favor of = it.

    Sean

    = --Apple-Mail=_3613778C-CA94-432D-80D4-821F1F09CD51-- From nobody Fri Apr 28 05:43: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 96A0E1292FC for ; Fri, 28 Apr 2017 05:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JQ0awROuvFI3 for ; Fri, 28 Apr 2017 05:43:31 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D89A0129C3E for ; Fri, 28 Apr 2017 05:40:26 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v3SCbxwE030469; Fri, 28 Apr 2017 13:40:23 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=W2+ZnHLN3Y8Q0RZFlpdxKFxBQ3LMBMOXFV2WutssBOw=; b=WnrfO0RAVe3Fifkl9g5OR0odKDKLIgot6OKGTK0e7RX5MA4QR8RXaYcNhcgXeDeNEMwJ Q0dPCBcaR4Ph5S+iBBIx93Akjcd7tEaxWTaamS7X+UU7YxpD8vbHWX7aXlE7PSt+7ohC qUUJg576rHPvphlEpSGQUeHKjtK7ytWDt+gyH2e/IOjF9j2KisNAdjNGVAlOnWBEuLeJ 3bmEXmFy1xzSh2IOT3JnHYzovsDb35AtVceRR3UdTkLoSgWzf8ikecWZFAqQrpgyzC0O cFHtHVr+Jq6d1dTuQxaaZWHeXn1YEW9Za+kBt/ZOO4y8QrkU+FQPPT4vDwey4gTjqzBR Cg== Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 2a3ffkfxj0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 28 Apr 2017 13:40:23 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v3SCa56m022228; Fri, 28 Apr 2017 08:40:22 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint1.akamai.com with ESMTP id 2a31spuf0j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 28 Apr 2017 08:40:22 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 28 Apr 2017 08:40:21 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 28 Apr 2017 08:40:21 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Fri, 28 Apr 2017 08:40:20 -0400 From: "Salz, Rich" To: Sean Leonard , Jacob Hoffman-Andrews CC: ACME WG , Ilari Liusvaara Thread-Topic: [Acme] draft-ietf-acme-acme-06: Don't call it PEM Certificate Chain Thread-Index: AQHSvxKDlpNT16hIWkWu+cAGgtGvu6HanOkAgAAdRaA= Date: Fri, 28 Apr 2017 12:40:19 +0000 Message-ID: <1172e2d83aab4b3595be4563ee141c2f@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20170329195427.GA23764@LK-Perkele-V2.elisa-laajakaista.fi> <525f79bb-a2e6-bf09-30e5-e80e0bb80379@eff.org> <3a9aaca8-204c-2a6c-2fc5-f74870effc2e@eff.org> <72CD4CDB-51BD-410C-908D-478AFB4A9411@seantek.com> <1EF494C1-B55A-40FF-B261-EE5823A06902@seantek.com> In-Reply-To: <1EF494C1-B55A-40FF-B261-EE5823A06902@seantek.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.47.38] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-28_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1704280183 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-28_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1704280184 Archived-At: Subject: Re: [Acme] draft-ietf-acme-acme-06: Don't call it PEM Certificate Chain X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 12:43:33 -0000 Pkkgd291bGQgcmF0aGVyIHNpZGVzdGVwIHRoZSBpc3N1ZSBvZiB3aGF0IGZvcm1hdCB0byBwdXQg dGhlIGNlcnRpZmljYXRlIHJlc3BvbnNlIGluLCBieSBwdXR0aW5nIHRoZSBjZXJ0aWZpY2F0ZXMg ZGlyZWN0bHkgaW50byB0aGUgSlNPTiBBQ01FIG9yZGVyIG9iamVjdC4gSSBoYXZlIG5vdCBzZWVu IGFueSBhcmd1bWVudHMgYWdhaW5zdCB0aGF0IHByZW1pc2UgKGV4Y2VwdCBmb3Ig4oCcc2l6ZeKA nSkgYW5kIHNldmVyYWwgYXJndW1lbnRzIGluIGZhdm9yIG9mIGl0Lg0KDQpUaGUgInNvLWNhbGxl ZCBQRU0gZm9ybWF0IiBpcyB3aGF0IGlzIGFjY2VwdGVkIGJ5IGFsbCB0b29saW5nIG91dCB0aGVy ZS4gIEFuZCBpZiBub3QgKEpLUykgdGhlcmUgYXJlIHdlbGwta25vd24gdG9vbHMgdG8gYWRhcHQg aXQuDQoNCldlIGFscmVhZHkgYXNrZWQgZm9yIGNvbnNlbnN1cyBvbiB0aGlzLCBidXQgSSB3aWxs IGFzayBhZ2Fpbi4gIERvIHBlb3BsZSBhZ3JlZSB3aXRoIFNlYW4/ICBQbGVhc2Ugc3BlYWsgdXAg YmVmb3JlIG5leHQgV2Vkcy4gIFdlIGhhZCBhIHN0cm9uZyBmZWVsaW5nIGF0IHRoZSBXRyBtZWV0 aW5nLCBhbmQgc2NvdXRpbmcgdGhlIGxpc3QsIEkgc2VlIG9ubHkgYSBoYW5kZnVsIG9mIHBlb3Bs ZSBpbiBmYXZvci4NCg0KLS0gIA0KU2VuaW9yIEFyY2hpdGVjdCwgQWthbWFpIFRlY2hub2xvZ2ll cw0KTWVtYmVyLCBPcGVuU1NMIERldiBUZWFtDQpJTTogcmljaHNhbHpAamFiYmVyLmF0IFR3aXR0 ZXI6IFJpY2hTYWx6DQo= From nobody Fri Apr 28 09:05:57 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1B70129AEE for ; Fri, 28 Apr 2017 09:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.103 X-Spam-Level: X-Spam-Status: No, score=-0.103 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 dR48-F4QrbYc for ; Fri, 28 Apr 2017 09:05:55 -0700 (PDT) Received: from umbriel.devever.net (umbriel.devever.net [149.202.51.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57516129BBE for ; Fri, 28 Apr 2017 09:01:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by umbriel.devever.net (Postfix) with ESMTP id B59761D512; Fri, 28 Apr 2017 18:01:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=devever.net; h= user-agent:in-reply-to:content-transfer-encoding :content-disposition:content-type:content-type:mime-version :references:message-id:subject:subject:from:from:date:date :received:received; s=mimas; t=1493395269; x=1511584630; bh=MJRw WXMoS8W1lU/lZbv0EVOblesHQhktQtuTv8KXEk0=; b=eg7YNmCcV1v9gG8r81kK vLdNeegK48HiC2ahXcYMFR+I7lICN5pwHQvoPcSg2iXjeX2Ln/0FCm3hv9U1oZmr YHIxUbhOPD8JIOLBzRqz9PQR1Y0obj6yaocUa/V2vIWWDNpZTXB7aEY20wR+lhLV e6medHGgxCjrm/0Tp5suhWKZgYskcIs2dopAsBT4dnPwiRPk1xnYlHKgUxh9tb0c +j+3j0/Qhgf2QP7D164FqGAjXo8vU6x9uh1IB67bniItK2msCuMSy2MUfKvWJ75a 9KO7/EqZnwc6W3w9uRe3khX80wkGb723bkDIPEobBLEtdxT48RNW5NTGmUPU+HIC bQ== 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 0OlP0R3OCcVQ; Fri, 28 Apr 2017 18:01:09 +0200 (CEST) Received: from andover.lhh.devever.net (localhost [127.0.0.1]) by umbriel.devever.net (Postfix) with ESMTP id 7A7F11D50D; Fri, 28 Apr 2017 18:01:09 +0200 (CEST) Date: Fri, 28 Apr 2017 17:01:09 +0100 From: Hugo Landau To: Richard Barnes Cc: acme@ietf.org Message-ID: <20170428160109.GA8320@andover.lhh.devever.net> References: <20170409084756.GA31209@andover.lhh.devever.net> <20170418052802.GA18137@andover.lhh.devever.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.8.1 (2017-04-11) Archived-At: Subject: Re: [Acme] PR: allow challenge retries X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 16:05:57 -0000 > The idea is that as long as the challenge status is still "pending", the > server is still retrying. Once it gives up, it marks the challenge as > "invalid". Bad idea. This prevents a server from supporting retries unless it commits to continuously reverifying the challenge itself. A server may want to allow retries but require a client to retrigger it (which is the most consistent with the initial behaviour of challenges anyway). Options here would be to add a new status, or an additional boolean field indicating whether proactive retries are being made. From nobody Fri Apr 28 09:18: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 27E8B1294C5 for ; Fri, 28 Apr 2017 09:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=neustar.biz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xTfp6akTIu04 for ; Fri, 28 Apr 2017 09:18:31 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (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 C9DB012EAFB for ; Fri, 28 Apr 2017 09:13:38 -0700 (PDT) Received: from pps.filterd (m0078668.ppops.net [127.0.0.1]) by mx0b-0018ba01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v3SGDP3w014954; Fri, 28 Apr 2017 12:13:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=neustar-biz; bh=WuUWM1VSwqqZrLVsrIzCD+8td67Iwf6gQxSSBEQmTk4=; b=yOU8EzW9PvXp5N3fu9OHRduT7X7zJhC/vaUHIaGo/csrzV68B8b+Ks8jFUJGh7p2weCb b3b9lwHklLZ7fs/tgQjJGBSAQTxMsLunik6FM/w+8D1J47eyNnfLb8VDY4dRXXfIvOAO tnIt8W450OlkPkVOqrsWxiHsCcUjdM9jeMHggJG6XoG7t6qd6hFgnmsgaRspSuLFnmmn e5/TRg5iKcj79Omo174FhPTuyDQNHmo4gWd6K+5ZolUZgHzEkE5s3Rug9jXNAVNprrTv 1EbACEsusYsiNldIkE5XQnzTrVOWgEyAwQtw8ZBDlxSVjaQ2bPYtXHuOWdmEkd4iLlPn sA== Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by mx0b-0018ba01.pphosted.com with ESMTP id 2a2eb0n0a5-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 28 Apr 2017 12:13:30 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.33]) by stntexhc10.cis.neustar.com ([169.254.4.170]) with mapi id 14.03.0279.002; Fri, 28 Apr 2017 12:13:30 -0400 From: "Peterson, Jon" To: "Salz, Rich" , Mary Barnes CC: ACME WG , Christopher Wendt Thread-Topic: [Acme] Futures Thread-Index: AdK6yP0s20BvTAD9Q3ePlESvzSMwkgDTdtwAAAdn7SAADbwCAABzvX2A Date: Fri, 28 Apr 2017 16:13:30 +0000 Message-ID: References: <878ad4965b254e5aa7e58e8c812d1df1@usma1ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [10.96.13.86] Content-Type: text/plain; charset="us-ascii" Content-ID: <2F323A227A63504F9E074F30867A93EF@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-28_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1704280215 Archived-At: Subject: Re: [Acme] Futures X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 16:18:33 -0000 Definitely I agree that we could use the ACME WG's help in moving forward STIR/SHAKEN stuff that will rely on ACME. I kind of see these as joint ventures with the STIR work, as it requires some coordination with the things we're doing with certificates in STIR, and also with the kinds of PASSporTs that we want these certificates to sign. But the baseline mechanisms that acquire the certs need some attention from this group. Jon Peterson Neustar, Inc. On 4/25/17, 3:54 PM, "Acme on behalf of Salz, Rich" wrote: >> > So we submitted a draft to define a new challenge type to support the >> > ATIS/SIP Forum NNI task group (SHAKEN) requirements, which are based >>on >> > using protocols defined in STIR: > >> Would it make sense to move this forward in STIR? > >After some off-line email chat, I was wrong. ACME is the most reasonable >place for this. > >So new question. So far it seems unlikely we'll meet in Prague. But >would you be willing to talk about this if we do? Should we meet so that >we can talk about it (and CAA and any other things that come up?) > >-- =20 >Senior Architect, Akamai Technologies >Member, OpenSSL Dev Team >IM: richsalz@jabber.at Twitter: RichSalz >_______________________________________________ >Acme mailing list >Acme@ietf.org >https://www.ietf.org/mailman/listinfo/acme From krustybutt@airmail.cc Fri Apr 28 10:15: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 40AA912EB23 for ; Fri, 28 Apr 2017 10:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-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=airmail.cc Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4G-NWsYuzjbT for ; Fri, 28 Apr 2017 10:15:26 -0700 (PDT) Received: from cock.li (cock.li [185.100.85.212]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C934129C5C for ; Fri, 28 Apr 2017 10:11:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=airmail.cc; s=mail; t=1493399489; bh=88+8FwoDZfBLjYPl6/8fBWLT0XkBEjg1AM41d4jGy8s=; h=Subject:To:References:From:Date:In-Reply-To:From; b=h1kiNPdRhAoeAruNhN+xeaj/yRaBEvOz19YqJN9d5Z2UCg4xV6+5GjRMkv/uxh1Ts mvF9OjmtUKGVQav9/6i4Ds8Mo5nfV35PWsiEJgkUapncd1KRpm6EcylLo75WzcY8tm b8mdm18EdwarqRd66Im+mvlwpIGYKxqtloAULUMdcWyQlZlWdJAoyvI7as2Pv9G4Z0 liDnSHKcOrVAFNyszCfSCzBgIn9pFB7ACDee7atcj9BCbLEOG1PDIZ4WDyYX+5hBEN U35tD07jDBacikd9QZdI7JeOydYyDbOGlI5RURBJmuayQvitYAnX01AuTrP+uWaqM3 lnIBFI/pEKuuw== To: acme@ietf.org References: <878ad4965b254e5aa7e58e8c812d1df1@usma1ex-dag1mb1.msg.corp.akamai.com> From: KrustyButt Openpgp: id=967513F4C37E9A969B9E41F55236578C1C4DD8F5 Message-ID: <484781b3-c083-ff70-3fc9-0c400d41f5aa@airmail.cc> Date: Fri, 28 Apr 2017 13:11:27 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------15EB930472E988DC037533D7" Content-Language: en-US Archived-At: Subject: Re: [Acme] Futures X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 17:24:15 -0000 This is a multi-part message in MIME format. --------------15EB930472E988DC037533D7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I have never been to Prague. KB On 4/28/17 12:13 PM, Peterson, Jon wrote: > > Definitely I agree that we could use the ACME WG's help in moving > forward STIR/SHAKEN stuff that will rely on ACME. I kind of see > these as joint ventures with the STIR work, as it requires some > coordination with the things we're doing with certificates in STIR, > and also with the kinds of PASSporTs that we want these > certificates to sign. But the baseline mechanisms that acquire the > certs need some attention from this group. > > Jon Peterson Neustar, Inc. > > On 4/25/17, 3:54 PM, "Acme on behalf of Salz, Rich" > wrote: > >>>> So we submitted a draft to define a new challenge type to >>>> support the ATIS/SIP Forum NNI task group (SHAKEN) >>>> requirements, which are based >>> on >>>> using protocols defined in STIR: >> >>> Would it make sense to move this forward in STIR? >> >> After some off-line email chat, I was wrong. ACME is the most >> reasonable place for this. >> >> So new question. So far it seems unlikely we'll meet in Prague. >> But would you be willing to talk about this if we do? Should we >> meet so that we can talk about it (and CAA and any other things >> that come up?) >> >> -- Senior Architect, Akamai Technologies Member, OpenSSL Dev >> Team IM: richsalz@jabber.at Twitter: RichSalz >> _______________________________________________ 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 > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJZA3e/AAoJEFI2V4wcTdj1axoQAIsIxEi4RcvbFvP7ijjLv9Z2 T6I+391XNTCi6AqMENTRNJEmo9NXEFkeXKAByKnXbimOznvtV7GVomrmG7CNwe67 A+XUgZzS5oBbt0S2wpd5mLFWVLzQBqK5slHx3dirk+BaVLj8VfVPCtX/Cgzqc/8k btmqVbrkgqoOexbvr6ETLBf1hjeeonGNkco1grJEa/sWmQ3dlQBbLFASWtg3QmTO oo3BjKrJHSdQezYTW/7DFmcufazOwTJQqXP50pIva8+X06kRu6TMfIHhcGTOBUEJ ry6TJa6XjntBSclZSZ/k+/2ZFSWxQ4VAn+Aq/dBmQuOHFKPOCezO749hB4Eegnrh 11vFxqB0ORh7e8kNcF2vNplFK8V0VV8T9oKqxQLsqeV/CylVZsE23xTKeXJGdoSL 019+B1v2GCSpxNkSYxXCrb/5MzY0EArxV/4pjqdYiHjiE7skzrhWog5TAUrmqi+l 92253P1Z2EMi7FGCwFv4kiWGvjfPids7TieR9JFesVv21sTDAEQPeWP7bmClOqaa bMs7kUVKMW53IeSG5mQI5SW2YOu3kIOzdImPGhYv+9vyjnDkILtDYvS/rqPDYnL1 qr3earj40Kpbp7IlXP6CuGYHXBtieXKnlYM1QpCN+E9btatAN1UUQkXbCGKYPRRg KSZAJlOQYgiMMOxiJkGW =33GG -----END PGP SIGNATURE----- --------------15EB930472E988DC037533D7 Content-Type: application/pgp-keys; name="0x1C4DD8F5.asc" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0x1C4DD8F5.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG/MacGPG2 v2.0 mQINBFkCMRQBEAClf07NUntDeb7tisiXANsRpWGa74a6YWjEb6KXcALs4rLG+hJ+ akEk/ESMRgjzaasJbdGLaeWixb/x3jhBykp/iBX5V1P69Njbw5onttAoGVqlKw0f UaGupiJN6Dwt3xY2vi1seiWRHYSf87ukIclj31lgDuZKPzpIcVQ/fCSdTxom6Fj9 XQ0TYwsSmijkvxiiC5vMirwYz5CDX3vZwMvuM2SWR99Gsop2RSmLDqZMK22xbU9M uWh/dimivF6mdUPkGmds8J5Q3uJKU3YjkRwQu++TMrbcEQ3hdcHwW4SVAWZKg6E6 KPs+Q/fF+kQaUGRuNYY6CvPHXfdt0l1sAPvO4D4IPufAX2hpGqhyjz4e9Evxd/mr B9SKAR0IFfWh2mEO6JREzrKVoJedzALJYpqlZ6N2T7Z8sdivPdWXA73Bq13KTjIy F4E12FBItWP1/16kWwZa8D1KMu+TANVpPUn1pnmsfuTJXa2vhnXykR06vEH9ZKos 0nwnQdfhRWq8cLjxqAPmptbXy0rOge9vUUUFkXDBONHVexSex+nUG9nwK27uK33w R+cZbLg2/RF+/boIjgTuU0+VWG6VdM19YgjaI2YLFyeOL4pZnCGjP2AphusGdZYK 4235+9Hs49Li6i1nvzlSweJseOnRS2XzBZ99CU622+kCSU5pS0XmYR7ROQARAQAB tCJLcnVzdHlCdXR0IDxrcnVzdHlidXR0QGFpcm1haWwuY2M+iQI/BBMBCAApBQJZ AjEUAhsDBQkAfpAABwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQUjZXjBxN 2PUj/BAAl5Rg/cbW5v57oH1p7Wpsfci8tMDFw2oRACgzJoeTTFZnXKLVCb7yjfpG h18Y/1EgV1Pqu+Khs9wsJCiYlkZdI8ZqntwzUJJMylY/YUf0hBO3tf2mhvgRrho6 lFMHfUARWQh/F8IYZSTq3jLZFnWRQZwbLyEA4JJ0tBdU8p+l1TREwxOzpue7TSOk dKrY4QssXXyHRypgYN0n5puEnhXdEGd+w2C0tG4chuyrEVgchPtxHHAGMnKe92P5 QtUzh1XhZkuVDV0pTmMGxjKHe2M6ZCLjjirsmRTAeEwSJ0JQd22PFtgC5VvyEIrd d47d/KiewbR8e4mBS2zHZU2Nd+ESOnIIf/SzP+6+2bKy66Ed9YkLUQ7ngPKsY3w0 y+XbpXmHDzlbLV7Kuguu3L/9QSdAhnx7UIY6ACKTdQodhfy7s5WT16Ir4i7o3vIH Pec5Ah1rsP8R7uIPTcwsO8nBxtbOWjs2UwnYkCV7dLM8kG/E5WMAWUxmFLbSpSvR XPX6qc8hOiZda63OaszmRT7Ywb62c8UNd4Zzie/u6JMoaYIHR6qjSYWKNU/R3cEn 6oL3MVOQwDo5ee2p/Fk9/zzPSqevFaz+iLRKC3eZE5lk99VEfOHikUvHSghmv3p7 9prUyubRR4aN9PgG0AECLIYg6aEwNwvPSkdIDhdXifoGXiecZuy5Ag0EWQIxFAEQ AOVfy1Sqdb0W2Q+k9OFlEx5GOkRtd5IUTwEnX5OtaMS4nrW5Qdpa5hV/vNKJDQjx TiuUdJ96vwBsYfHH+ovHXLcsjMinAZ5e0vvPZDQytdcABWl2KSE8dNToK/8/ZSKH xd2+Z71t2hgaTwZ7gh7KjFxgO99s9TG6jirCm6Zt4N6Gk82Daj5lUkPH43RnK+yZ 19xqBDyVNMjJ0z7tX1gwafN7dPO8NVtQXQooqzh5rW2hp7Qk8R6Z0D6VXMwCG2Ed WkSFKi+Qq1FAdINUT8grSA0Q0KdqdIpjS79781j1W4JBE/gBI795/WV6x07bXh0Q 8lQmdgQB58dAWOBMZuAUs3pgrQMyeUCQ3GM0jOlCacso4y4ysLQMlYubxJL0OEVq VqUv4Tjv71mHGMR+ILWRw4134xD0XnjkZfx9yaja28O4HoiG5D9PoyfxGjunbfN+ QjVLtETEpc+wsAYHdQk6/+6RM8R/GyWRv4dUmMTYLYhoiur+KPGv+TgR/u6EJvXx VsPteX9Y1NITmnURggEeE9+mgGp/uoc7XWqQDiGH7zmsmI7d7Js1J1qOF2DnmpPJ 7gBeOnWlyDF/EYGlx6M2XfmXpSoRa5KwYPla3KzsOlNhXSacMeAGy7v5vSiYeVkE dT8sYicS/jdhiM56cujj2cceT+DwY12TdKBabnqaMhZ1ABEBAAGJAiUEGAEIAA8F AlkCMRQCGwwFCQB+kAAACgkQUjZXjBxN2PW6BhAAnh4FYWR/2DCbubrCjW3jMyhj /2Vrske45A8GJVtk+pD3s6IKsY8jLOTfxZBXUB9PCyiT9jLhvIEA6dx4CGBXMFqd Xi/xHyy2Z1gz6zXUlBeGFoBMc8v93JlQgiF2nQUGyN+z5Fv+X1sr/CpZTth/2DPM L1M/Njp5wz6YMciMx8PfM+FYCtawFc+ZTxxNC4vO7kPzsc6h6Og6MF9y35DrZHdZ TKVS2jJnwIMOrNxW8dDZeZ7FVYAviasVar8gcRaov7E0pXEbU0PVkz2AX3WYhzIL cABf/gUohyT77AOWX+uF+M314K59RCSbKATvGaip741SF4mNK6cEOMOt/eLXmpGR 5bdB+kvqe0PnugGdtxW/AW5UR2yYMdgUj3aRVeAMjp/uu3qw4VeR3Hf2jeC4MXkD s+SEsz9i+kNydP594kn0WNhv92sTEYu806z9agPAXP6DjSqxb0sY2Yg7EJ+qffM4 ATwzgSMKXWGpyQYVt9K9StB+2PaZUfkthb/X1nCa4oTrOWobnmL/pGwelV7ELyL2 rVrumxVjA7akmzczKYbr8H73VLsvFT1NR47ONrnGM3ImLuBk5/TtyC4hJ83WzP/C gT76N+N77U2h+UVyyXMLklqpfRnKqrKUAImXWwwYKKY/m+CUxzcjp/2J/Tv8TcBM n0SHERhETW7S3ayio58= =YDI0 -----END PGP PUBLIC KEY BLOCK----- --------------15EB930472E988DC037533D7--