Re: [Acme] Want client-defined callback port
Phillip Hallam-Baker <phill@hallambaker.com> Thu, 23 April 2015 17:01 UTC
Return-Path: <hallam@gmail.com>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20A9E1ACD35 for <acme@ietfa.amsl.com>; Thu, 23 Apr 2015 10:01:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.621
X-Spam-Level: *
X-Spam-Status: No, score=1.621 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, J_BACKHAIR_32=1, SPF_PASS=-0.001] autolearn=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 uNpt2-DLkVoV for <acme@ietfa.amsl.com>; Thu, 23 Apr 2015 10:01:56 -0700 (PDT)
Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::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 88CC91AC437 for <acme@ietf.org>; Thu, 23 Apr 2015 10:01:55 -0700 (PDT)
Received: by lbcga7 with SMTP id ga7so18039104lbc.1 for <acme@ietf.org>; Thu, 23 Apr 2015 10:01:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=x5Uibry8O/Z9y5qYQjP8ndrjKenDqD6i8y6INjEUL9o=; b=hyfbqCEpGjlUnZV+xLTd3ZuqECP6UyUDyo1j3BJ7cnX6425nOk28XruhSwB6RHwkzN abFHMnexYC3DXn9q+9y5NEXMGecOzUzZmat9gpxRnNh2Wn64tTu5YoJr4QyfVcuYvQLM 7ZOIk9OM9wqltbbXa6vKG9mIkuKxuGPA97buJNCYmn5owQXlOPWt+jezzz/Bw3Q9FhTI UpFpSd9oJxwbf1wFVwStWL4dlRMiZiP5yZg0lK0l91s2v1cU+zQq7chxtYCtlQAoIc3Y FuHd4+DM+HJCZCqs9l95kUJmA/p8S7FTGBtodfT4Xjx5maFJBaI6/U1bI+7/OZ2Fno09 Wx4g==
MIME-Version: 1.0
X-Received: by 10.112.42.233 with SMTP id r9mr1748504lbl.58.1429808514082; Thu, 23 Apr 2015 10:01:54 -0700 (PDT)
Sender: hallam@gmail.com
Received: by 10.112.203.163 with HTTP; Thu, 23 Apr 2015 10:01:53 -0700 (PDT)
In-Reply-To: <02937f42ee274952a44476be019f2864@usma1ex-dag1mb2.msg.corp.akamai.com>
References: <352DA5FE-AC6F-49A7-8F9F-70A74889204F@apple.com> <CAK3OfOjey4bk02qC_jj2c0AzZ54qnP=KAJnG=mXnO6A5gZ4m9g@mail.gmail.com> <CAL02cgQ94ijVrCM9SStcodRW+XSG2w5Zwu3+ny8HriDBnxjdtg@mail.gmail.com> <FF21526F-BA8D-4F54-AAE3-047632706668@apple.com> <CAL02cgSDk0TNYusEkXA3onmqF7=kaAWhHjpW8WjbiqxgQMdQwQ@mail.gmail.com> <555F6C74-2416-4893-BDEA-A3C2E55A6D57@apple.com> <16985cf1c8c444c48d328fa766ec5ff8@usma1ex-dag1mb2.msg.corp.akamai.com> <DE264105-7317-4343-BCEE-539A73D42544@apple.com> <CAL02cgTv5Zi4wP0gJPvcrty6N96pAaLRkCveyvMNfoyjQrrEyw@mail.gmail.com> <0609C348-A6D8-46D5-AF58-5BE69910D261@apple.com> <CAL02cgT_DPY-Bn9A=UtCx+g2FKHON-TXGCWfH-gL8rR4yEFHZg@mail.gmail.com> <CA+9kkMAqte7O0k0KVRLRaEOmJL-wK0ncoruv3yoqKBjZVnc99g@mail.gmail.com> <CABkgnnVP4as97fXe7XTFpC=rw6ETdXY5s=1cRj1Xan1sgDsx3A@mail.gmail.com> <CAMm+Lwg5GiknSceb1Ocs=VxA1cZpmcrmZbPeXpgfAHbOC3CUcw@mail.gmail.com> <CAL02cgReRXAu4QjvsDYYkJN-WKS2bZeWNtZK-AoVndTncMQvag@mail.gmail.com> <CAMm+Lwi97VeE7j72oCXTeqEJWSQ=RTM3VH6hZ_GapbtZ9bmfwQ@mail.gmail.com> <CAL02cgTeztSb2B2pfweQfUL8Ty0XfiBLbtCLTrHwLNZ2LTQPVQ@mail.gmail.com> <CAMm+LwiR2tZVvWYOfKOMKybNNi9f52A_W4QGH6Bxx_haivFz3g@mail.gmail.com> <02937f42ee274952a44476be019f2864@usma1ex-dag1mb2.msg.corp.akamai.com>
Date: Thu, 23 Apr 2015 13:01:53 -0400
X-Google-Sender-Auth: U3tdJ76_siPZVLRpeX4GvQkGzd8
Message-ID: <CAMm+LwjdSzpg_kSwKgTiCkSpV7LXZk_J_UOg06FFp3mrK5OrCg@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: "Salz, Rich" <rsalz@akamai.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/Uy8PFeEyoiNZnStNXiD2FCtUWd0>
Cc: "acme@ietf.org" <acme@ietf.org>
Subject: Re: [Acme] Want client-defined callback port
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Automated Certificate Management Environment <acme.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/acme>, <mailto:acme-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/acme/>
List-Post: <mailto:acme@ietf.org>
List-Help: <mailto:acme-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/acme>, <mailto:acme-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Apr 2015 17:01:59 -0000
On Thu, Apr 23, 2015 at 11:56 AM, Salz, Rich <rsalz@akamai.com> wrote: >> I think we can decide on a mechanism. But getting into long arguments as to >> whether ports other then 443 should be accepted or if so which ones seems >> to be unnecessary. > > I am fully in favor of mechanism, not policy. But we would HAVE to change the protocol to allow a port to be specified. The protocol has to support multiple validation mechanisms, not all of which are going to be relevant to WebPKI. So one approach would be to say 'if you are going to use a port other than 443 then its a different mechanism that is out of scope for now'. > It's a slippery slope. Taking your argument only a little bit further, should PKIX have shut down once CABForum spun up? Some say it should have shut down earlier. PKIX does not just support the WebPKI. It also has all the peculiar policy constraint curlicues. > If you're not a browser or well-established CA, you need special dispensation to join[1]. That leaves a very important community -- users[2], who haven't been well-served by previous efforts in this area -- out. I am not sympathetic to "just let CABForum do it" arguments. Well both sides have a veto power as far as the WebPKI goes. So if IETF wants to say '443 or nothing' it certainly can make it stick. Alternatively it can leave the choice of port blank and let CABForum decide if they want to choose one or more for WebPKI. But deciding other port numbers seems to me to be down in the weeds. Its like offering fifty options for desert to a child who will only eat mac and cheese. Another point to consider here is the framing of the problem. People are discussing this as validating a certificate request. I think that is the wrong way to look at it. What we are doing is to validate the holdership of a DNS name. Which is not the same thing. That may be a component of a certificate validation process but it is not necessarily one that would apply to every certificate issue. Ten years from now, I would expect we will be using short lived certs that roll every 24 hours, that every service has a separate cert and the default configuration for systems is load balanced and fault tolerant. In that configuration a SOHO configuration using a couple of off the shelf appliances is going to be consuming two sets of half a dozen certs every day. I don't think we need to do twelve separate domain validations every day. In fact I don't think we really need or want to do validation every day. Or at least I don't want to be using this particular scheme on a repeat basis. What I would prefer is to validate the certificate applications under a device key and push the fingerprint of the two device keys out into the DNS (It was one of the extended use cases for CAA records). So if the DNS record changes we can infer that a change of control has occurred and we want to retest holdership. Now would such a scheme eliminate the need for a port443 check? Well it certainly does not support the 'run this one program and go' scenario so it can't be the only scheme. And I am not even sure that CAA record validation alone is sufficient for reasons I don't want to go into right now. But looking at where we are likely to go with ACME, I think we could make a good case for 443 validation only right now and punt on the question of seamless issue for protocols on ports other than 443 where there isn't a connection to the Web server. The protocol we are designing right now is the one I think will be the LRA<->CA protocol long term. I think we want the device<->LRA protocol to do a bit more. In particular I think stuffing HSTS/HPKP records into the DNS is a no brainer and we probably want to configure the A, AAAA, SRV etc records as well.
- [Acme] Want client-defined callback port Bruce Gaya
- Re: [Acme] Want client-defined callback port Jacob Hoffman-Andrews
- Re: [Acme] Want client-defined callback port Bruce Gaya
- Re: [Acme] Want client-defined callback port Nico Williams
- Re: [Acme] Want client-defined callback port Salz, Rich
- Re: [Acme] Want client-defined callback port Richard Barnes
- Re: [Acme] Want client-defined callback port Bruce Gaya
- Re: [Acme] Want client-defined callback port Randy Bush
- Re: [Acme] Want client-defined callback port Richard Barnes
- Re: [Acme] Want client-defined callback port Bruce Gaya
- Re: [Acme] Want client-defined callback port Salz, Rich
- Re: [Acme] Want client-defined callback port Bruce Gaya
- Re: [Acme] Want client-defined callback port Viktor Dukhovni
- Re: [Acme] Want client-defined callback port Salz, Rich
- Re: [Acme] Want client-defined callback port Richard Barnes
- Re: [Acme] Want client-defined callback port Richard Barnes
- Re: [Acme] Want client-defined callback port Bruce Gaya
- Re: [Acme] Want client-defined callback port Ted Hardie
- Re: [Acme] Want client-defined callback port Martin Thomson
- Re: [Acme] Want client-defined callback port Phillip Hallam-Baker
- Re: [Acme] Want client-defined callback port Peter Eckersley
- Re: [Acme] Want client-defined callback port Martin Thomson
- Re: [Acme] Want client-defined callback port Richard Barnes
- Re: [Acme] Want client-defined callback port Richard Barnes
- Re: [Acme] Want client-defined callback port Phillip Hallam-Baker
- Re: [Acme] Want client-defined callback port Richard Barnes
- Re: [Acme] Want client-defined callback port Phillip Hallam-Baker
- Re: [Acme] Want client-defined callback port Richard Barnes
- Re: [Acme] Want client-defined callback port Salz, Rich
- Re: [Acme] Want client-defined callback port Phillip Hallam-Baker
- Re: [Acme] Want client-defined callback port Bruce Gaya
- Re: [Acme] Want client-defined callback port Viktor Dukhovni
- Re: [Acme] Want client-defined callback port Michael Ströder