https://github.com/ietf-wg-acme/acme/pull/165
On Fri, Aug 5, 2016 at 2:12 PM, Richard Barnes <[email protected]> wrote: > > > On Wed, Jul 27, 2016 at 5:52 AM, Ilari Liusvaara <[email protected] > > wrote: > >> On Tue, Jul 26, 2016 at 02:29:54PM -0700, Andrew Ayer wrote: >> > On Tue, 26 Jul 2016 23:03:18 +0200 >> > Richard Barnes <[email protected]> wrote: >> > >> > > - Add an "identifiers" field to the application object >> > > - Each application MUST have exactly one of "csr" and "identifiers" >> > > - If "csr" is present, then do what's in the draft now >> > > - If "identifiers" is present, then do the same dance, but don't >> > > issue the certificate >> > > >> > > Does that sound sane to folks? It still seems slightly gross to me, >> > > because of the switching based on the presence of fields. Anyone have >> > > better ideas? >> > >> > This seems sane, and better than option 1. The switching is gross, but >> > perhaps it can be made less gross with this logic: >> > >> > - "identifiers" MUST be present. >> > - "csr" MAY be present. >> > - If "csr" is present, its identifiers MUST match "identifiers". >> > - A certificate will only be issued if "csr" is present. >> >> IMO, that makes it even worse, by introducing duplication. >> >> Also, these pre-auth lists aren't actually valid applications, >> and I don't think one should treat those as applications. >> > > Yeah, I'm sort of coming around to this opinion as well. In addition to > this semantic mismatch, it's actually not that much additional machinery to > have the old new-authz endpoint present. The authorization fulfillment > flow is already defined in Section 6.4, so all you have to specify is that > the client can also use the new-authz endpoint to initiate. > > I'll take a cut at a PR. > > --Richard > > > > >> >> >> -Ilari >> > >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
