Got it - thanks for the clarification (now I just need to start updating IPNNI docs ;)
On Wed, Nov 29, 2017 at 11:48 AM, Richard Barnes <[email protected]> wrote: > > > On Wed, Nov 29, 2017 at 12:43 PM, Mary Barnes <[email protected]> > wrote: > >> My comments below [MB]. >> >> Regards, >> Mary >> >> On Wed, Nov 29, 2017 at 11:23 AM, Andrew Ayer <[email protected]> >> wrote: >> >>> On Tue, 28 Nov 2017 13:28:08 -0500 >>> Daniel McCarney <[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/acme
