On Tue, 16 Aug 2016 16:48:27 -0400
Richard Barnes wrote:
> There are two clearly separable problems here:
>
> 1. Associating an ACME account key to an account in some other system
> 2. Determining when to issue an EV certificate (and with what
> contents)
>
> Let's address them each separately.
See below inline, thanks.
Regards,
Andy
On 17 Aug 2016, at 04:54, Richard Barnes mailto:r...@ipv.sx>>
wrote:
There are two clearly separable problems here:
1. Associating an ACME account key to an account in some other system
2. Determining when to issue an EV certificate (and with what conte
See below inline, thanks.
Regards,
Andy
> On 17 Aug 2016, at 00:11, Jacob Hoffman-Andrews 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
On Tuesday, August 16, 2016, Martin Thomson
wrote:
> On 17 August 2016 at 06:48, Richard Barnes wrote:
> > a. Infer the certificate type from the CSR. For example, if the Subject
> in
> > the CSR has (C, O, CN), infer that the applicant wants EV.
> > b. Have a field in the new-application reque
Hmm...
If the server provides a terms-of-service URL in the directory, the
client MUST indicate its operator's agreement to the terms at that URL
by including the "terms-of-service": "agreed" field in the
new-registration body.
This text seems like an attempt to triangulate between what's
Any further objections to this?
https://github.com/ietf-wg-acme/acme/pull/167/files
On 08/09/2016 12:50 PM, Jacob Hoffman-Andrews wrote:
> On 08/09/2016 12:42 PM, Ron wrote:
>>> - If the CA uses legal auto-update language (most common case by far),
>>> nothing else is required.
>>
>> I think in
On 17 August 2016 at 06:48, Richard Barnes wrote:
> a. Infer the certificate type from the CSR. For example, if the Subject in
> the CSR has (C, O, CN), infer that the applicant wants EV.
> b. Have a field in the new-application request that the client can use to
> indicate what type of certifica
There are two clearly separable problems here:
1. Associating an ACME account key to an account in some other system
2. Determining when to issue an EV certificate (and with what contents)
Let's address them each separately. (Note that Andy filed
https://github.com/ietf-wg-acme/acme/issues/170 f
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
See below inline, thanks.
From: Jacob Hoffman-Andrews [mailto:j...@eff.org]
Sent: Tuesday, August 16, 2016 12:35 AM
To: J.C. Jones ; Andy Ligg
Cc: Acme@ietf.org
Subject: Re: [Acme] Add a special token parameter in ACME registration
One possibility would to make it the client's responsibil
Currently, we called it as API token if you want to use StartAPI, it is a
string like this: tk_dc09cfc9aff5409ea98227e212858669.
We use this API Token together with the API authentication certificate to call
our API.
So if we can add this API Token in the ACME registration, then we can bind thi
11 matches
Mail list logo
