Re: [Acme] ACME for pre-ACME CAs

Peter Bowen <pzbowen@gmail.com> Sat, 23 January 2016 01:38 UTC

Return-Path: <pzbowen@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 3D6331B2EB5 for <acme@ietfa.amsl.com>; Fri, 22 Jan 2016 17:38:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4
X-Spam-Level:
X-Spam-Status: No, score=-4 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, GB_I_LETTER=-2, SPF_PASS=-0.001] autolearn=ham
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 ZevvzezBG-2f for <acme@ietfa.amsl.com>; Fri, 22 Jan 2016 17:38:11 -0800 (PST)
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 455DD1B2EB3 for <acme@ietf.org>; Fri, 22 Jan 2016 17:38:11 -0800 (PST)
Received: by mail-pf0-x22f.google.com with SMTP id 65so50735566pff.2 for <acme@ietf.org>; Fri, 22 Jan 2016 17:38:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0sv+UmIpLaXFxrTFO23OGvvf0cTPCxPjAyxaKIOhxNs=; b=o874W9CBfPf1NS6KtIkI9T5DJS7n5mvGyu/aYXaKzoqkVVcK+x1yDrlzfqhoKle/kX QAxAZs1iADD07QGCoxGqkwx4/3v+KANOV2EGVROgM6nRL45irIi0av+QWimy3d3PrD4u VYth7vKGYFrLvGnPu7Wc7Z7TzvUYakO7vty2vyYV8OMgQ7fOhnjV/Vcf0pT/Ja62WH9Q TPKXYWwA0aoQM9wxmOedGUfcmxPyLT7q4PSO4ew8qN6Vay6HnbvyDGBAZ8XKTfCcAa9o R0CL7owVnXPHnIGevVYp+/0Wi+y8/5dyYl1a3MFyizMlITAYOKC05nXaICQv4XkFjGfr 17ww==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=0sv+UmIpLaXFxrTFO23OGvvf0cTPCxPjAyxaKIOhxNs=; b=IINrDnBdIvoOabPAwm6yqol1Vwnc3rh9GLKmpaHp9gOQbSikV0SIPTd8vYZzydVA+n X/21X2fb1Ih+ue1v2JTIkwPpHPEqseE8M0mt7wUFf8MThYJiaI6gtf/uo5PXMGcSMmNN YwXHpQySkqLReXUsjzy9wubx7MbECsa9tW3UaCh+L6/qCQI6cgci0B5gvDZ9C8GtRwHN rsXPmlblk/9+KA3EVI2nrEGiIqYKp5iKJyNSNcSBZrhzRAP2rZzg5/9YH0dkw7uNDFA2 nH9MdI9WIoDpniTOANBJPCjPNQdDuSxX2G3HxKr5xr6Yv1zGoyb4ZbvjqmHVvXlEE50N G/eg==
X-Gm-Message-State: AG10YORX6NQolKcBifdGD8r/NBhN0MtVp6rspPLybCvgNoCi7i5Td2AmHPHPkl2Jhxug++aEq5MOAcI6Ff3e/g==
MIME-Version: 1.0
X-Received: by 10.98.8.218 with SMTP id 87mr8865222pfi.39.1453513090849; Fri, 22 Jan 2016 17:38:10 -0800 (PST)
Received: by 10.66.142.193 with HTTP; Fri, 22 Jan 2016 17:38:10 -0800 (PST)
In-Reply-To: <CAL02cgQnXOZFwpbRcbdDAzBjeM2pyqOkoTv3WbXWf_BVT5SdBg@mail.gmail.com>
References: <CAL02cgQnXOZFwpbRcbdDAzBjeM2pyqOkoTv3WbXWf_BVT5SdBg@mail.gmail.com>
Date: Fri, 22 Jan 2016 17:38:10 -0800
Message-ID: <CAK6vND_s+dOFqNN2OPyMv91b-CbKqbCwCOediG-n3FWSLMDhMA@mail.gmail.com>
From: Peter Bowen <pzbowen@gmail.com>
To: Richard Barnes <rlb@ipv.sx>
Content-Type: text/plain; charset=UTF-8
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/jLtbHQIq6g795KkEW15gkIx6310>
Cc: "acme@ietf.org" <acme@ietf.org>
Subject: Re: [Acme] ACME for pre-ACME CAs
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: <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: Sat, 23 Jan 2016 01:38:13 -0000

On Tue, Dec 22, 2015 at 12:02 PM, Richard Barnes <rlb@ipv.sx> wrote:
> I mentioned at the IETF meeting that a major next milestone for ACME
> is to get it to the point where it can be used by current CAs,
> including ones that require clients to pay for certificates.  I've
> been chatting with Andrew Ayer and a few other folks about how to do
> this, and have come up with the following loose proposal (in a Gist
> because it's a little long):
>
> https://gist.github.com/bifurcation/8c955b99bd0daec8673d
>
> tl;dr:
> - Add an "order" resource type that can group certificates
> - Reinforce the distinction between certificate requests and certificates
> - Add an "activation" action or an "out-of-band" challenge type

Richard,

I think that this is a good start.  However I think there is a high
risk of putting too much policy into the protocol.  Given this, what I
describe below are what I see as core building blocks that allow a CA
to implement policy as they see fit.

I think there are several areas where the current draft API could be
enhanced to better support existing CA and places where it is worth
calling out things that are out of scope and better handled via some
other standard.  The biggest of these is permissions and roles.  The
current spec only considers one

The first area that probably needs work is identifier authorization.
There are three main groups of methods for validating domain
authorization:
- Public challenge (this is what ACME has today)
- Private challenge
- Non-automated

One popular way to validate control of an identifier is to look up the
owner or registrant of the identifier, get contact info (such as a
postal address) and mail them a letter containing a private challenge.
Once they receive the letter, they provide the challenge to the CA/RA
to provide they received the letter.  Today with ACME, there is no way
to have a private challenge.  Additionally, given that there may be
multiple contact addresses, it is necessary to give the caller a way
to choose which address to use when there are multiple choices.  For
these challenge types, the token would would not be in the structure.

Non-automated validation is another gap.  There are times where it is
desirable to record that an account is authorized for the identifier
via some "other' mechanism.  This could be via an authorization letter
or research by the CA.

The other item missing from domain authorization information is scope.
Some CAs may determine that an authorization is good for a portion of
the DNS tree larger than just the validated FQDN.  For example, I
might validate peterbowen.org and then be able to get
foo.peterbowen.org without re-validating.  I suggest reusing the scope
terms from LDAP as an attribute on base, one, sub, and children as a
new attribute in the identifier structure.

In addition to dns identifiers, CAs that include subject identity
information will need to be able to represent these identifiers.  I
don't expect that most of these identifiers will use any automated
challenge.  Instead the URL might be somewhere that scans of documents
can be uploaded.

In addition to identifier and challenge enhancements, the new-cert
method does not align to what most CAs do today.  Specifically, almost
all CAs allow providing the certificate details outside of the CSR and
only use the CSR to carry the public key and self-signature.  The
new-cert method probably should allow optional parameters for
specifying identities to be included in the certificate.

Many CAs also offer different certificate profiles, which is also
missing from the new-cert method.  Profiles can be used to determine
which extensions to include, how to set key usages, and even which CA
will sign the certificate.

Lastly, I would extend CSR to allow for either a PKCS#10 formatted CSR
or a SPKAC CSR.  This would allow systems built using the HTML5 keygen
element and other systems that use SPKAC formatted CSRs to use ACME.

I think these changes would give a solid foundation and API upon which
many different business models and issuance policies could be
implemented.

Thanks,
Peter