[Acme] draft-ietf-acme-star

Richard Barnes <rlb@ipv.sx> Wed, 28 August 2019 14:52 UTC

Return-Path: <rlb@ipv.sx>
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 B939C120043 for <acme@ietfa.amsl.com>; Wed, 28 Aug 2019 07:52:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 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, SPF_HELO_NONE=0.001, SPF_NONE=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 QXspDUbuUqqN for <acme@ietfa.amsl.com>; Wed, 28 Aug 2019 07:52:38 -0700 (PDT)
Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) (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 BA5E612001E for <acme@ietf.org>; Wed, 28 Aug 2019 07:52:38 -0700 (PDT)
Received: by mail-ot1-x330.google.com with SMTP id f17so87073otq.4 for <acme@ietf.org>; Wed, 28 Aug 2019 07:52:38 -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=1LueD3zguZb/KFbXNKWduCH1AZ/+LcRKX/XylvQ/Jf0=; b=SZng7IcdBGlt3+EUS4KqE6g24zftPhkfxG5pmcpezVtov6XJn02SNzD/82w9lA4gfZ 3tZYfH3tJn9/YGDw2eW2VRKS7M9sbV0xWfll6pQ0zF8hAepAO6BEXuTPpoJnNlLfvFiu gZmBTFDEKRztyP7uWL3cP2b1w2wVKNGVHvEXOrhtStYlm03FRCIyCXdE1AE/09F5GHry dqLTQtf3cKYJcEs0h48bYhYMHKcPZKFUdXH0fwfy9EoVy0tmDSMVNOoHiP94XV8n+oMJ xDhjZEcxELmYIMklrh3US42pGTd0p/shh6WMHkkd4EgZt3N6dq8x55HZF5+ofg7lJsiZ WJIw==
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=1LueD3zguZb/KFbXNKWduCH1AZ/+LcRKX/XylvQ/Jf0=; b=dT9phH8d4vTQznfPaaQ8hb8jKKM85G//RWpPR5k8qRV18/ok0O2cF6EOGq+nSzSnZM fpEOze+S363JxX71jH2ZCb/aNLa0zmXrkwRIhX0rhtaA0X3zu4TULoMo2sJuJGqxyNfI E/mTb5hUNQm7Y42AMLFGWFnZ3Qs3y1iZ+ijLBbvavE1imzT2HKS3ktIypEBFpb7kKk1w BRAbkDPNE8eQM8WBxtEEuU8ryw8+SQuOK5hHnLP3v3PuGysXXmywp5WzdQrsMyDFixNk oP0soTL116rCJ04mV3X+N43lBi63ZlTdtusNjMO8mn2YwcNdlFX1OcvG5j63kRWLCBTc eX2g==
X-Gm-Message-State: APjAAAX/BSH6qRusg2sIVQNC1hF8mRO0GUlS2NK++At31I0e7N1QdsuH koXDevG/uSu/cAQtoLLrM9J1XOBZPzjKyVoOHXhcFhm3hMM=
X-Google-Smtp-Source: APXvYqxsJeHNmQhRx+GfB4b4+3V5KG/zJAybmYJNfQ1lJtk72r1BJqHeh0Ps/40IzJpwzivpQcK6V+hqzKYwqyIt6rs=
X-Received: by 2002:a05:6830:1159:: with SMTP id x25mr3449293otq.237.1567003957602; Wed, 28 Aug 2019 07:52:37 -0700 (PDT)
MIME-Version: 1.0
From: Richard Barnes <rlb@ipv.sx>
Date: Wed, 28 Aug 2019 10:52:16 -0400
Message-ID: <CAL02cgST77G9uR23x4Hf0L8_hqi6zSuJqB=dbunGYcDPEDpbDg@mail.gmail.com>
To: IETF ACME <acme@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000041442505912e8a62"
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/dv0F9iqtMdPLDP8q7Bw1iq0w7pA>
Subject: [Acme] draft-ietf-acme-star
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.29
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, 28 Aug 2019 14:52:41 -0000

I had a chance to take a look at this draft as a result of being a
designated expert on the registries.  I approved the registrations, but
independently, I have several major concerns about the draft.  In no
particular order

- The use of the "STAR" acronym is not helpful.  This is not an acronym
that will be familiar to a reader, and less so an implementer who has not
fully read and absorbed this spec.  Instead, you should say what you mean,
e.g., for the "meta" fields:

star-enabled -> auto-renewal-allowed
star-min-cert-validity -> min-cert-validity
star-max-renewal -> max-auto-renewals

- Likewise, "recurrent" is not a common word in English.  If you want to
use a single word, "recurring" is more common, but referring to
"auto-renewal" would be even better.

- It would be even cleaner to group all these "recurrent" fields into a
sub-object, so that you wouldn't have to worry about them being present if
"recurrent" wasn't set.  In other words, just signal the "recurrent"
boolean by the presence of the object, and specify the parameters in the
object.

{
  "auto-renew": {
    "start": ...,
    "end": ...,
    "lifetime": ...,
  }
}

- The idea of "predating" is toxic.  Pre-dating a certificate means making
the notBefore date earlier than when you actually issued it, which is a
huge problem for a real CA to do.  That's not what you mean here.  You just
want there to be some overlap between certificates.  Say that instead
("recurrent-certificate-predate" -> "overlap") and adjust Section 3.5
accordingly.

- The Not-Before and Not-After headers should be removed.  On the one hand,
it's not clear to me that it's any easier to parse these headers than it is
to parse the certificate.  On the other hand, there are existing HTTP
headers that express almost exactly the same semantics, e.g., Expires.

- It's not clear that there's any reason to negotiate certificate-GET on a
per-order basis.  Just have the CA allow it or not unilaterally and delete
the "recurrent-certificate-get" field.

- The "star-certificate" attribute is unnecessary.  Instead, you should
just say that when auto-renewal is enabled, the "certificate" attribute
points to the current certificate, and use "previous" link relations to
expose earlier certs.