Hi Daniel, You're right. I've misunderstood that. I don't have to use any challenges at all. I just set the authorization to valid if the domain is already pre-authorized (proprietary CA system-wise).
We're targeting 2018 Q1 for the ACME service, but we're aware that we're dependent on the client support for v2-spec/external account binding. When do you think last call will take place? regards, Robert Kästel On Fri, Dec 1, 2017 at 4:10 PM, Daniel McCarney <[email protected]> wrote: > 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.htm >> l#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
