On Tue, Jun 27, 2017 at 2:29 PM, Jacob Hoffman-Andrews <[email protected]> wrote:
> On 06/27/2017 05:15 AM, Rifaat Shekh-Yusef wrote: > > > >> The server would create an order object with one or more >> authorizations objects that need to be fulfilled. > > > My point is that the pre-authorization request (i.e. new-authz) would have > already created > a pending authorization object with the challenges for the client. > > The ACME server MAY reuse existing pending authorizations, or it may > create new ones. You should not rely on the pending authorizations that > result from a new-order request being the same as ones previously created > by new-authz requests. > > Fair enough. What would be the response from the server when it reuses existing pending authorization? 200 OK with the existing challenge? Could that be spelled out in the document? > > What I have in mind for this is that ACME client might be representing > more than one entity > when it is using the pre-authorization procedure, as specified in section > 7.4.1. > > The use case I have in mind is to use this pre-authorization mechanism for > a client to issue certificates > for large number of *endpoints*. > > Instead of sending a new-authz request per endpoint, it might be useful to > allow the client to send one > request for a list of endpoints. > > I'm not clear what you mean by entity and endpoint in this question. Are > you thinking of people, machines, companies, DNS names, IP addresses, or > something else? > I am thinking of hard endpoints, like deskphones, mobile devices, etc. I am working on an ACME endpoint extension draft that I would like to discuss later that hopefully clarifies the use case and how I think it could fit into the ACME mechanism. Regards, Rifaat
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
