Subject: Re: [Acme] Removing OOB Challenge Type

From: Robert Kästel <[email-masked]>
Date: Fri, 1 Dec 2017 13:55:46 +0100

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-masked]> wrote:

> No objections here.
>
> Regards,
> Andrew
>
> On Thu, 30 Nov 2017 10:22:56 -0800
> Jacob Hoffman-Andrews <[email-masked]> 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-masked]
> > > <mailto:[email-masked]>> 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-masked]
> > >     <mailto:[email-masked]>> 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-masked] <mailto:[email-masked]>
> > >     https://www.ietf.org/mailman/listinfo/acme
> > >
> > >
> > >
> > > _______________________________________________
> > > Acme mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/acme
> >
>
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

---

From: Daniel McCarney <[email-masked]>
Date: Fri, 1 Dec 2017 10:10:07 -0500

Hi Robert,

> 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-masked]> wrote:

> [0] https://ietf-wg-acme.github.io/acme/draft-ietf-acme-acme.
> html#rfc.section.7.4.1
>
> regards,
> Robert Kästel
>

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 1 Dec 2017 15:36:22 +0000

*   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.

That’s not right.  Deployments rarely occur right as the draft is finished.

So the question was asked, is anyone planning on using this?  And we got a definitive yes answer.  I think the question now becomes, are the alternatives acceptable?

We can of course still decide that OOB should be removed, but let’s talk about options right now.

---

From: Robert Kästel <[email-masked]>
Date: Fri, 1 Dec 2017 16:36:27 +0100

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-masked]> wrote:

>> [0] https://ietf-wg-acme.github.io/acme/draft-ietf-acme-acme.htm
>> l#rfc.section.7.4.1
>>
>> regards,
>> Robert Kästel
>>

---

From: Daniel McCarney <[email-masked]>
Date: Fri, 1 Dec 2017 10:49:28 -0500

> That’s not right.  Deployments rarely occur right as the draft is finished.

What isn't right? I expressed an opinion that entering last call for
specification text that hasn't been implemented by anyone seems like a
recipe for errata. My comment was also specific to implementations not
deployments.

For added context, the OOB challenge type has been in the spec largely
unchanged for two years[0].  Plans to use something are nice but I thought
our goal was rough consensus and running code.

[0] -
https://github.com/ietf-wg-acme/acme/commit/3e64248088da56f046c7448a84a0263d1328f470

On Fri, Dec 1, 2017 at 10:36 AM, Salz, Rich <[email-masked]> wrote:

>
>    - 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
> So the question was asked, is anyone planning on using this?  And we got a
> definitive yes answer.  I think the question now becomes, are the
> alternatives acceptable?
>
>
>

---

From: Daniel McCarney <[email-masked]>
Date: Fri, 1 Dec 2017 12:33:05 -0500

> recipe for errata. My comment was also specific to implementations not

Apologies Rich - I reread my original message and I did say "What date is
planned for this release" when I should have said "What date do you expect
to have an implementation".

I understand the source of confusion now & agree with your correction.

On Fri, Dec 1, 2017 at 10:49 AM, Daniel McCarney <[email-masked]>
wrote:

> [0] - https://github.com/ietf-wg-acme/acme/commit/
> 3e64248088da56f046c7448a84a0263d1328f470
>
>
>> So the question was asked, is anyone planning on using this?  And we got
>> a definitive yes answer.  I think the question now becomes, are the
>> alternatives acceptable?
>>
>>
>>

---

From: Daniel McCarney <[email-masked]>
Date: Fri, 8 Dec 2017 08:25:55 -0500

Happy Friday folks ;-)

Can we move forward with removing the OOB challenge? It seems like there is
rough consensus:

Clint, Jacob, Andrew and myself all vote for removal. Robert posed one
use-case that he thought required OOB challenges but doesn't, and one
use-case where they have plans for the future but no concrete
implementations.

On Thu, Nov 30, 2017 at 11:42 AM, Salz, Rich <[email-masked]> 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.
>

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 8 Dec 2017 13:54:58 +0000

Thank you for the reminder.

As chair, I say that we have consensus to remove the OOB challenge.