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

Andy Ligg <andy@startssl.com> Wed, 17 August 2016 02:29 UTC

Return-Path: <andy@startssl.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 0865512D179 for <acme@ietfa.amsl.com>; Tue, 16 Aug 2016 19:29:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.148
X-Spam-Level:
X-Spam-Status: No, score=-8.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 llqlQuq7vEWZ for <acme@ietfa.amsl.com>; Tue, 16 Aug 2016 19:29:35 -0700 (PDT)
Received: from mx3.startssl.com (mx3.startssl.com [124.251.21.41]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66AE712D0AA for <acme@ietf.org>; Tue, 16 Aug 2016 19:29:34 -0700 (PDT)
Received: from mx3.startssl.com ([fe80::bd1d:eeaf:a825:d540]) by mx3.startssl.com ([fe80::bd1d:eeaf:a825:d540%13]) with mapi id 14.02.0247.003; Wed, 17 Aug 2016 10:35:37 +0800
From: Andy Ligg <andy@startssl.com>
To: Jacob Hoffman-Andrews <jsha@eff.org>
Thread-Topic: [Acme] Add a special token parameter in ACME registration
Thread-Index: AQHR9w4PsKlaS/7lgE65PBJcOC1dgaBJsauAgAF70QCAAA4kgIABNlaP
Date: Wed, 17 Aug 2016 02:35:37 +0000
Message-ID: <838716A1-8E33-4F9D-803E-4418676DDAC8@startssl.com>
References: <236F64DDDC83C742A24E89E6E215CFC7E4CFB7@mx3.startssl.com> <CAObDDPAEaiWE0Apao_sWin2njhC+CjQuw1D07upTsn4=BQQZnQ@mail.gmail.com> <d729f81d-44a7-7e64-a528-a43df5e6dd69@eff.org> <010e01d1f7d0$dcd3c7a0$967b56e0$@startssl.com>, <c81aa0ec-4d8b-8e9f-cba3-d6205e466e53@eff.org>
In-Reply-To: <c81aa0ec-4d8b-8e9f-cba3-d6205e466e53@eff.org>
Accept-Language: en-US, zh-CN
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/vh9i_Lu4aB7_lNusCpHFcQz3uzI>
Cc: "acme@ietf.org" <acme@ietf.org>
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: Wed, 17 Aug 2016 02:29:37 -0000

See below inline, thanks.

Regards,

Andy

> On 17 Aug 2016, at 00:11, Jacob Hoffman-Andrews <jsha@eff.org> wrote:
> 
> 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, we can generate the CSR including the cert type info.

> 
>> 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?

A: the API token is obtained from StartSSL website before using ACME client, this is for identifying the client's validation level to let us know to issue the EV SSL for this client.

> 
> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme