Subject: [Acme] Landing PR#342 (proactive issuance with identifier-first)

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Mon, 27 Nov 2017 12:04:31 -0800

Hi all,

Daniel McCarney's been working on PR#342, which changes the new-order
flow to take a list of identifiers instead of a CSR, and to be finalized
with a CSR: https://github.com/ietf-wg-acme/acme/pull/342. We've had
some back-and-forth on the list about this, versus CSR-first, versus
CSR-first-and-last. There was some further discussion at IETF 100
(minutes:
https://github.com/thomas-fossati/acme-minutes/blob/master/ietf-100.md),
and we hummed to accept PR 342 over the alternatives.

If there's anyone here who couldn't make it to the meeting and would
like to raise strenuous objections, please speak up now, otherwise we'll
incorporate that change.

Thanks,
Jacob

---

From: Richard Barnes <[email-masked]>
Date: Tue, 28 Nov 2017 13:05:17 -0500

I think this is fine to land now.  It's not my favorite approach, but
there's clear consensus.  I filed Issue #356 [1] to track the lost
functionality here, and how we might want to add it back.

https://github.com/ietf-wg-acme/acme/issues/356

On Mon, Nov 27, 2017 at 3:04 PM, Jacob Hoffman-Andrews <[email-masked]> wrote:

> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

---

From: Richard Barnes <[email-masked]>
Date: Tue, 28 Nov 2017 13:08:12 -0500

Using my editor's prerogative, I went ahead and merged this PR.

---

From: Daniel McCarney <[email-masked]>
Date: Tue, 28 Nov 2017 13:19:40 -0500

>
>  I filed Issue #356 [1] to track the lost functionality here, and how we
> might want to add it back.

>From #356:

" In making that change, we dropped support for certain legacy back-end
> APIs that require a CSR before issuing challenges"

Which legacy back-end APIs are you referring to? I recall many weeks ago
you thought a specific commercial CA and a specific certificate re-seller
required CSR in new-order but both confirmed off-list they did not.

It's frustrating to see continued resistance on the back of constraints
imposed by vague legacy systems without name. Where are the
users/maintainers of these systems to express their concerns at the
perceived "drop of support" to the working group directly?

- Daniel / cpu

---

From: Richard Barnes <[email-masked]>
Date: Tue, 28 Nov 2017 13:23:23 -0500

> perceived "drop of support" to the working group directly?

Dude, it's just a tracking issue, assigned to the Defer milestone.  It's
not blocking any work here.

The canonical example for me here is SSLMate [1], which takes a CSR up
front, I'm told because the back-ends it uses require it.  Andrew Ayer, who
maintains SSLMate, is on this list, and might be able to provide further
insight.

But like I said, this is not blocking anything for the base spec any more.
It's just a possible extension if someone shows up and asks for the feature.

--Richard

[1] https://sslmate.com/help/api/rest

---

From: Daniel McCarney <[email-masked]>
Date: Tue, 28 Nov 2017 13:28:08 -0500

> maintains SSLMate, is on this list, and might be able to provide further

SSLMate/Andrew are the reseller I recall confirming could accommodate #342
without needing a CSR in new-order. I hope Andrew can clarify if I'm
remembering incorrectly.

On Tue, Nov 28, 2017 at 1:23 PM, Richard Barnes <[email-masked]> wrote:

> But like I said, this is not blocking anything for the base spec any
> more.  It's just a possible extension if someone shows up and asks for the
> feature.
>
> --Richard
>
>

---

From: Andrew Ayer <[email-masked]>
Date: Wed, 29 Nov 2017 09:23:27 -0800

On Tue, 28 Nov 2017 13:28:08 -0500
Daniel McCarney <[email-masked]> wrote:

> >
> > The canonical example for me here is SSLMate [1], which takes a CSR
> > up front, I'm told because the back-ends it uses require it.
> > Andrew Ayer, who maintains SSLMate, is on this list, and might be
> > able to provide further insight.
> 
> 
> SSLMate/Andrew are the reseller I recall confirming could accommodate
> #342 without needing a CSR in new-order. I hope Andrew can clarify if
> #I'm
> remembering incorrectly.

You are remembering correctly.

To recap what I said off-list, removing the CSR from new-order wouldn't
work if a CA wanted to extend ACME to add non-standard challenges that
were derived from the CSR.  If a CA is only going to use the standard
challenges, then I don't see a problem.  SSLMate isn't going to use
non-standard challenges, so I'm fine moving the CSR to finalize and
removing it from new-order.

Regards,
Andrew

---

From: Mary Barnes <[email-masked]>
Date: Wed, 29 Nov 2017 11:43:02 -0600

My comments below [MB].

Regards,
Mary

> removing it from new-order.

[MB] With what we have in place right now for SHAKEN (based on STIR), we
are using non-standard challenges based on the TNAuthList in the CSR.  This
may change with the development of the generic token challenge mechanism,
but this is another example of the need for this mechanism.[/MB]

---

From: Richard Barnes <[email-masked]>
Date: Wed, 29 Nov 2017 12:48:26 -0500

> but this is another example of the need for this mechanism.[/MB]

It's perfectly fine to use non-standard challenges, as long as they can be
derived from the "identifiers" array added in #342.  It's only if you
needed some other component of the CSR (e.g., the public key) in the
challenge that you would have an issue.

--Richard

---

From: Mary Barnes <[email-masked]>
Date: Wed, 29 Nov 2017 13:57:26 -0600

Got it - thanks for the clarification (now I just need to start updating
IPNNI docs ;)