On Wed, Nov 29, 2017 at 12:43 PM, Mary Barnes <mary.ietf.bar...@gmail.com> wrote:
> My comments below [MB]. > > Regards, > Mary > > On Wed, Nov 29, 2017 at 11:23 AM, Andrew Ayer <a...@andrewayer.name> > wrote: > >> On Tue, 28 Nov 2017 13:28:08 -0500 >> Daniel McCarney <c...@letsencrypt.org> 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 >> > > [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] > 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
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
