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
