Thank you for the reminder.
As chair, I say that we have consensus to remove the OOB challenge.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
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 f
>
> >> 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
>
> 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
deploy
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
* 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 fin
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 auth
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
No objections here.
Regards,
Andrew
On Thu, 30 Nov 2017 10:22:56 -0800
Jacob Hoffman-Andrews 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 som
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 de
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
> 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 wrote:
> Does anyone disagree with Daniel’s reasoning? If so, please speak up
> before next Friday.
>
>
>
> Daniel, please do not me
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
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
13 matches
Mail list logo
