Re: [Acme] Add a special token parameter in ACME registration

Jacob Hoffman-Andrews <jsha@eff.org> Tue, 16 August 2016 16:04 UTC

Return-Path: <jsha@eff.org>
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 8617712D728 for <acme@ietfa.amsl.com>; Tue, 16 Aug 2016 09:04:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.249
X-Spam-Level:
X-Spam-Status: No, score=-8.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.247, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org
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 H8BS7DMue0BR for <acme@ietfa.amsl.com>; Tue, 16 Aug 2016 09:04:54 -0700 (PDT)
Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B22A712D121 for <acme@ietf.org>; Tue, 16 Aug 2016 09:04:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=fGdK1yNzuZAVWXKc0C1l7h53SkcGG2f6ev5B5h9BDIY=; b=jgqJgoF7xhGnDEAuKxhqrUKZNVEru2I63qLvUksPDZedsQXqMED0ScpAp2Ihhql2wI05SIuSSFiOrSLJSjRdBLWGOzyxkLcL7bmvlpli8abpNtWe9w77dN/jGe23pVQyEP0QlGbupUynwjHE5t6ioZiU6/ggA7wqbRYaHrnmdcE=;
Received: ; Tue, 16 Aug 2016 09:04:54 -0700
To: acme@ietf.org
References: <236F64DDDC83C742A24E89E6E215CFC7E4CFB7@mx3.startssl.com> <CAObDDPAEaiWE0Apao_sWin2njhC+CjQuw1D07upTsn4=BQQZnQ@mail.gmail.com> <d729f81d-44a7-7e64-a528-a43df5e6dd69@eff.org> <010e01d1f7d0$dcd3c7a0$967b56e0$@startssl.com>
From: Jacob Hoffman-Andrews <jsha@eff.org>
Message-ID: <c81aa0ec-4d8b-8e9f-cba3-d6205e466e53@eff.org>
Date: Tue, 16 Aug 2016 09:04:53 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <010e01d1f7d0$dcd3c7a0$967b56e0$@startssl.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/8EWIP7eoelDWQjEGaPsGa0rhJT0>
Subject: Re: [Acme] Add a special token parameter in ACME registration
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: Tue, 16 Aug 2016 16:04:56 -0000

On 08/16/2016 08:14 AM, Andy Ligg wrote:
>> One possibility would to make it the client's responsibility to request
>> EV by including the desired O, OU, etc. fields in the Subject DN of the
>> CSR. It would then be the server's responsibility to accept or reject
>> the request based on whether the account has a sufficient validation
>> level (and payment).
> 
> A: StartCom issued the certificate not based on CSR info, we don’t care
> about the info in the CSR, we issue the certificate based on this
> account validated level and validated identity information. This mode
> don’t work, CSR is not enough to identify the certificate type.

Keep in mind that you're gong to have to start using *some* of the info
from the requested CSR, because ACME uses the hostnames embedded in a
CSR to determine which hostnames to issue for. ACME also uses the CSR to
convey requested extensions, like Must Staple, though obviously not all
CAs will support all extensions.

Can you say more about why a CSR is not enough to identify the
certificate type?

> A: Yes, our API call is the same way as ACME registration – using client
> certificate for authentication. In my last email, we need to add a API
> Token in the ACME registration, then all are OK for paid CA.
> Sure, if the paid CA is not this way but like to use ACME, then they
> need to change the API system.

Is your proposal that `POST /acme/new-reg` would contain a token
obtained from the StartSSL website? Or that your ACME server would
generate a token and provide it as part of the response to new-reg?