[Acme] Short term certificates - two options
Yaron Sheffer <yaronf.ietf@gmail.com> Wed, 20 July 2016 09:52 UTC
Return-Path: <yaronf.ietf@gmail.com>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93B0F12D0A5 for <acme@ietfa.amsl.com>; Wed, 20 Jul 2016 02:52:20 -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 a4Y5Su4t9Mes for <acme@ietfa.amsl.com>; Wed, 20 Jul 2016 02:52:18 -0700 (PDT)
Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 080A012DB03 for <acme@ietf.org>; Wed, 20 Jul 2016 02:52:00 -0700 (PDT)
Received: by mail-wm0-x22f.google.com with SMTP id q128so49048697wma.1 for <acme@ietf.org>; Wed, 20 Jul 2016 02:52:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:to:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=axCOwTiiKYOtvlbqQ6yRfr+3fQa+o7/etAZEDXPPg9I=; b=GdCeUjKskOnvrSmupP4WY4+sknQIK8B6CLHwOy/f73aPzQDivlUKD4c7P8tsBK+eVA UwcxVR3SmAGAAcmCVM1PFQlNXpwNSTpLD8miSlbi4KMkG0RyHVlXOZnZzUmoxSxCP64J mgplTCu72tihO9zSR+w2HyffdI+VRtcPyGervftA1EcaGUq/eyTa3mYfWWvo4BEu59fg kVoJIy+JSxN2vY3Y8IwTWc/fxSibEuyuHmRCHSMqia14TfQ2C+qT8II/dO6YOS/aa4h9 AQ5Mi+ZMyUDgJHYxBA4EaIpO79SXXSydbcfNmf93arJYIh8qust6VuQgtwQo8QJicQX9 cvsw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=axCOwTiiKYOtvlbqQ6yRfr+3fQa+o7/etAZEDXPPg9I=; b=Y3hr2FHvun/0FEF0JX4AY1M8sSn3ULrDUTHFy+m9N/tMZ0rTb+Kc7+43IEmZKfGr3s xvym875oKDOttN89dThXayGyplL1UWhoPFqGDOAm0dD7GDfMDhIrNrB3dQToynvpg4d8 2xdwvtAzjd+Kk8tIIZgt2SEuioPG8iyRGMSRGMMkWVOrQ428qvHzo0qQQA4Wzp1EksCh WQRhICNU5PaJxxUyQ7WMH/DfYz8Vw71+noObrP02oNauHbMn8NjH9sdzH1YeGIE5LmZ1 bB7cBs0TTQIFYO0kOwBP4Z/MGdVxzyAurfkvQjrv4Qa24UfDCiyucx7memv1xecd/saz ts6A==
X-Gm-Message-State: ALyK8tL7CPAVsq5b/UqrXnMS+X8kz1MAquD8IMdzMbciQy6Kci+rJp3hit7nEdklMnVX2Q==
X-Received: by 10.194.127.97 with SMTP id nf1mr451171wjb.175.1469008319279; Wed, 20 Jul 2016 02:51:59 -0700 (PDT)
Received: from ?IPv6:2001:67c:370:160:e99d:fe39:137d:bd46? ([2001:67c:370:160:e99d:fe39:137d:bd46]) by smtp.gmail.com with ESMTPSA id d1sm366593wju.23.2016.07.20.02.51.57 for <acme@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Jul 2016 02:51:58 -0700 (PDT)
From: Yaron Sheffer <yaronf.ietf@gmail.com>
To: ACME WG <acme@ietf.org>
Message-ID: <826ed7ae-9358-a3fc-f816-bc5074395f99@gmail.com>
Date: Wed, 20 Jul 2016 11:51:57 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/I3vOEE901HUuYxTgck7KVXYW0l8>
Subject: [Acme] Short term certificates - two options
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 20 Jul 2016 09:52:20 -0000
Hi, At the LURK BoF this week there was some interest in having a solution where a domain owner can delegate to some other entity (which we will call "the TLS server") the authority to terminate TLS connections on its behalf, using short-term certificates. These certificates allow the domain owner to terminate the TLS server's authorization when necessary, without requiring certificate revocation - which we know doesn't work reliably. The certificates' validity is measured in days, e.g. 3 days. First, I would like to request the working group to adopt short-term certificates as a charter item. Second, I would like the group's advice in choosing between two very different approaches to this problem. Option 1: Certificate Pull This option is documented in the LURK draft [1], which will be modified to include feedback received this week, specifically to use more traditional certification request (CSR) flows. But the basic idea is very simple: 1. TLS server generates a CSR once every 3 days for www.example.com, sends it to the domain owner using an authenticated REST API. 2. Domain owner validates the CSR, forwards it to ACME server, gets back a short-term cert. 3. Domain owner returns the cert to the TLS server. If something bad happens, the domain owner simply stops forwarding requests from this particular TLS server. Option 2: Certificate Delegation This option moves more of the responsibility to the ACME server. 1. Domain owner contacts the ACME server and obtains a "delegation ticket" which is specific to the TLS server. The ticket is good for a long period, e.g. 1 year. 2. TLS server regularly contacts the ACME server, proves ownership of the delegation ticket, and receives a short-term certificate. If something bad happens, the domain owner contacts the ACME server and revokes the delegation ticket. Comparison: 1. Option 2 is clearly more complicated to specify and to implement. 2. Option 2 extends the ACME protocol. Many clients can ignore it, but servers will need to implement it. 3. Option 1 requires the domain owner to have a server available regularly, even if it is only a short REST interaction once every few days. Option 2 doesn't require any such server. 4. Option 1 looks to the ACME server as a normal cert request, and therefore will swamp the CT logs with lots of short-term certs. With Option 2, we can log to CT the issuance of the delegation ticket instead of the actual certificates. I would appreciate your input! Thanks, Yaron [1] https://tools.ietf.org/html/draft-sheffer-lurk-cert-delegation-00
- Re: [Acme] Short term certificates - two options Patrick Figel
- Re: [Acme] cache poisoning Alan Doherty
- Re: [Acme] Short term certificates - two options Alan Doherty
- Re: [Acme] Short term certificates - two options Yaron Sheffer
- Re: [Acme] Short term certificates - two options Salz, Rich
- Re: [Acme] Short term certificates - two options Alan Doherty
- Re: [Acme] Short term certificates - two options Yaron Sheffer
- Re: [Acme] Short term certificates - two options Eric Mill
- Re: [Acme] Short term certificates - two options Chris Drake
- Re: [Acme] Short term certificates - two options Eric Mill
- Re: [Acme] Short term certificates - two options Chris Drake
- Re: [Acme] Short term certificates - two options Eric Rescorla
- Re: [Acme] Short term certificates - two options Chris Drake
- Re: [Acme] Short term certificates - two options Salz, Rich
- Re: [Acme] Short term certificates - two options Chris Drake
- Re: [Acme] Short term certificates - two options Salz, Rich
- Re: [Acme] Short term certificates - two options Chris Drake
- Re: [Acme] Short term certificates - two options Yaron Sheffer
- Re: [Acme] Short term certificates - two options Chris Drake
- Re: [Acme] Attribute Certificates Re: Short term … Sean Leonard
- Re: [Acme] Attribute Certificates Re: Short term … Yaron Sheffer
- Re: [Acme] Attribute Certificates Re: Short term … Richard Barnes
- Re: [Acme] Attribute Certificates Re: Short term … Yaron Sheffer
- Re: [Acme] Short term certificates - two options Yaron Sheffer
- [Acme] Attribute Certificates Re: Short term cert… Sean Leonard
- Re: [Acme] Short term certificates - two options Chris Drake
- Re: [Acme] Short term certificates - two options Carl Wallace
- Re: [Acme] Short term certificates - two options Yaron Sheffer
- Re: [Acme] Short term certificates - two options Yaron Sheffer
- Re: [Acme] Short term certificates - two options Yaron Sheffer
- Re: [Acme] Short term certificates - two options Chris Drake
- Re: [Acme] Short term certificates - two options Salz, Rich
- Re: [Acme] Short term certificates - two options Carl Wallace
- Re: [Acme] Short term certificates - two options Andrew Ayer
- Re: [Acme] Short term certificates - two options Yaron Sheffer
- Re: [Acme] Short term certificates - two options Yaron Sheffer
- Re: [Acme] Short term certificates - two options Yaron Sheffer
- Re: [Acme] Short term certificates - two options Niklas Keller
- Re: [Acme] Short term certificates - two options Sean Leonard
- Re: [Acme] Short term certificates - two options Niklas Keller
- [Acme] Short term certificates - two options Yaron Sheffer
- Re: [Acme] Short term certificates - two options Carl Wallace
- Re: [Acme] Short term certificates - two options Carl Wallace
- Re: [Acme] Short term certificates - two options Tom Ritter