[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