Hi Robert,
> We're planning on using the OOB challenge type to signify pre-authorized > domains (in the existing CA system) as already validated challenges in the > ACME response, as described in section 7.4.1 Pre-authorization [0]. I don't think Section 7.4.1 indicates that you should use authorizations with an OOB challenge type for this purpose. The requirement is that the order object returned by new-order reflect authorizations obtained by the new-authz endpoint in its response. In this case you describe it sounds like the authorizations are from your existing CA system and are not from `new-authz` and the ACME pre-authorization process - I don't think this section applies. Further, if the authorizations were obtained that way then they weren't obtained by solving an OOB challenge returned by the CA per Section 8.6 and it seems confusing/misleading to return a valid authorization with an OOB challenge that wasn't used to obtain the authorization. Since 7.4.1 doesn't mention challenges at all wouldn't it be sufficient to have the order return valid authorizations covering the domains that were pre-authorized in the legacy system with no accompanying challenges present? This is planned for the first release of the ACME service. What date is planned for this release? If there won't be a client and server implementation available by the time we enter last call I still think it is most appropriate to defer the OOB challenge type as follow-up work. - Daniel / cpu On Fri, Dec 1, 2017 at 7:55 AM, Robert Kästel <[email protected]> wrote: > We at Telia Company are working on an ACME server implementation that is > going to integrate with an existing CA system using external account > binding. > We're planning on using the OOB challenge type to signify pre-authorized > domains (in the existing CA system) as already validated challenges in the > ACME response, as described in section 7.4.1 Pre-authorization [0]. This is > planned for the first release of the ACME service. > > Another use for it we're planning is to support validating EV and OV > certificates using an OOB href/URL. > > [0] https://ietf-wg-acme.github.io/acme/draft-ietf-acme-acme. > html#rfc.section.7.4.1 > > regards, > Robert Kästel > > On Fri, Dec 1, 2017 at 12:07 AM, Andrew Ayer <[email protected]> wrote: > >> No objections here. >> >> Regards, >> Andrew >> >> On Thu, 30 Nov 2017 10:22:56 -0800 >> Jacob Hoffman-Andrews <[email protected]> wrote: >> >> > I agree with this change. It's a good plan to not try and pre-specify >> > things like OOB that aren't on anyone's roadmap, because that leaves >> > the space open for a better specification once someone wants to >> > implement it. >> > >> > On 11/30/2017 09:39 AM, Clint Wilson wrote: >> > > >> > > I agree with the reasoning and decision to remove this. >> > > While I think it's possible for this challenge type to become useful >> > > in the future, I don't have any justification for keeping it in in >> > > the meantime. As Daniel notes, it's straightforward to add it back >> > > if needed. >> > > >> > > >> > > On Thu, Nov 30, 2017, 10:25 AM Daniel McCarney <[email protected] >> > > <mailto:[email protected]>> wrote: >> > > >> > > > Daniel, please do not merge this until we determine WG >> > > >consensus >> > > >> > > Of course :-) I don't have any merge privileges! >> > > >> > > On Thu, Nov 30, 2017 at 11:42 AM, Salz, Rich <[email protected] >> > > <mailto:[email protected]>> wrote: >> > > >> > > Does anyone disagree with Daniel’s reasoning? If so, please >> > > speak up before next Friday. >> > > >> > > >> > > >> > > Daniel, please do not merge this until we determine WG >> > > consensus. >> > > >> > > >> > > _______________________________________________ >> > > Acme mailing list >> > > [email protected] <mailto:[email protected]> >> > > https://www.ietf.org/mailman/listinfo/acme >> > > >> > > >> > > >> > > _______________________________________________ >> > > Acme mailing list >> > > [email protected] >> > > https://www.ietf.org/mailman/listinfo/acme >> > >> >> _______________________________________________ >> Acme mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/acme >> > >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
