Subject: [Acme] 'new-order' Implementation in node.js

From: Prasheel Soni <[email-masked]>
Date: Wed, 25 Oct 2017 14:10:39 +0530

Hi Devs,

I recently tried to implement the 'new-order' process in Node.JS and came
across several confusions which are required to be cleared before we can
move on:

1. Are authorization resources created only when a new-order request comes
to the server or they are stored in the database and returned when a
new-order request id encountered?

2.  If the resources are created in runtime, then how do I proceed? Should
I first create challenge resources in challenges table and then create
authorization resources or vice-versa?

3. Is it defined or mentioned somewhere that how many authorizations should
be sent to a client in response to a new-order request?

4. Is it defined or mentioned somewhere that how many challenges should be
there in an authorization and what should be their types?

5. Do we consider an authorization as valid when the client validates even
one of the challenges sent to him?

I have just started to study ACME and thought to implement it. Any help on
any of these questions will be really appreciable and helpful.

Thanks in advance!!

Regards
*Prasheel*

‌

---

From: Richard Barnes <[email-masked]>
Date: Wed, 25 Oct 2017 06:00:11 -0400

> across several confusions which are required to be cleared before we can

Hi Prasheel,

In case it's helpful, here's my node.js implementation of an earlier draft
of ACME:

https://github.com/bifurcation/rocket-skates

You can also look at the Go implementation that Let's Encrypt is working on:

https://github.com/letsencrypt/pebble

> new-order request id encountered?

You're going to want to store them in a database either way.  If you're
going to support new-order, you should be prepared to create authorizations
in response to a new-order request.

> authorization resources or vice-versa?

That's up to your internal architecture.  You should ensure that each
challenge is associated to a a unique authorization.

> 3. Is it defined or mentioned somewhere that how many authorizations
> should be sent to a client in response to a new-order request?
>

That's up to the server's policy.  Typically, there would be one
authorization per identifier in the CSR.

> there in an authorization and what should be their types?

That's up to the server's policy.  Typically, the server offers whatever
challenges it considers to be sufficient to prove authorization.

> one of the challenges sent to him?

Yes.  "... a server should consider any one of the challenges sufficient to
make the authorization valid"

https://ietf-wg-acme.github.io/acme/draft-ietf-acme-acme.html#rfc.section.7.1.4

> any of these questions will be really appreciable and helpful.

Good luck!
--Richard

>
> Thanks in advance!!
>
> Regards
> *Prasheel*
>
>
>
> ‌
>
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>
>

---

From: Prasheel Soni <[email-masked]>
Date: Wed, 25 Oct 2017 15:34:03 +0530

Thanks for the quick response Richard. This will help me a lot in the
implementation.

On 25-Oct-2017 3:30 PM, "Richard Barnes" <[email-masked]> wrote:

>> 1. Are authorization resources created only when a new-order request
>> comes to the server or they are stored in the database and returned when a
>> 2.  If the resources are created in runtime, then how do I proceed?
>> Should I first create challenge resources in challenges table and then
>> create authorization resources or vice-versa?
>>
>
>> 4. Is it defined or mentioned somewhere that how many challenges should
>> be there in an authorization and what should be their types?
>>
>
>> 5. Do we consider an authorization as valid when the client validates
>> even one of the challenges sent to him?
>>
>
> Yes.  "... a server should consider any one of the challenges sufficient
> to make the authorization valid"
>
>> I have just started to study ACME and thought to implement it. Any help
>> on any of these questions will be really appreciable and helpful.
>>
>
> Good luck!
> --Richard
>
>
>
>
>>
>> Thanks in advance!!
>>
>> Regards
>> *Prasheel*
>>
>>
>>
>> ‌
>>