On Wed, Nov 1, 2017 at 6:12 PM, Brad Warren <[email protected]> wrote: > As a client developer, I slightly prefer submitting the CSR twice. In > addition to making the request logic a bit simpler, it causes the client to > provide more information about the cert it would like to obtain earlier in > the process. This was mentioned in another thread on this topic, but to > provide a concrete example of where this might be useful, Let's Encrypt > currently refuses to issue for CSRs containing a weak key. By initially > providing the CSR, the server is able to immediately reject the request > rather than waiting until the end of the process. > > This approach would mean something else needs to be done to alleviate > bloat in in the server's database, but I think it provides a better > experience on the client side. > I think as long as the CSR is also included in the finalize request, we're OK for CA bloat -- the CA can throw away the first CSR after it parses it and produces the authorizations.
Or rather, they should keep around a hash of the CSR so that they can verify that the second CSR is the same. Since we should require that. --Richard > On 11/01/2017 09:13 AM, Richard Barnes wrote: > > Some of us have been discussing this off-list, and where we got to was > basically as follows: > > 1. We should have some sort of explicit "finalize" request that triggers > issuance of a certificate > 2. The finalize request will need to have the CSR attached to it, so that > the CA doesn't have to cache the CSR from new-order > 3. The "new-order" request still needs to have some sort of description of > the certificate being requested, in order to support legacy back-end > interfaces, > 4. That description can be either: > 4.1. In the form of a CSR, or > 4.2. In the form of a list of identifiers (as in @cpu's PR [0]) > > On the one hand, sending a CSR twice seems clumsy (as Hugo notes above) > and it makes the server parse the CSR twice. On the other hand, using a > CSR both times makes the client logic a bit simpler since you just send the > same thing in both requests. > > Anyone else have thoughts here? > > --Richard > > > [0] https://github.com/ietf-wg-acme/acme/pull/342 > > > > > > On Mon, Oct 30, 2017 at 3:48 PM, Daniel McCarney <[email protected]> > wrote: > >> Wouldn't it be a lot better not to do the validations at all if you can >>> tell at new-order time that you're not going to be willing to issue? >> >> >> Yes, that would be better in this one capacity. However I don't think it >> comes close to justify the scaling issues associated with accepting the CSR >> up-front, and as mentioned, there are other reasons why validations may >> occur for an order that the CA isn't willing to issue at the time of >> finalization. >> >> There also isn't a CAA-PKP so we're bikeshedding about impact on features >> that are both unspecified & unimplemented. >> >> - Daniel / cpu >> >> On Mon, Oct 30, 2017 at 3:33 PM, Richard Barnes <[email protected]> wrote: >> >>> >>> >>> On Mon, Oct 30, 2017 at 10:15 AM, Daniel McCarney <[email protected]> >>> wrote: >>> >>>> > Example: Suppose that CAA-PKP got added (restrict issuance on SPKI key). >>>> Implementing that without knowing the public key at validation time is >>>> annoying. >>>> >>>> Can you expand on "annoying"? >>>> >>>> It seems completely possible to reject the order finalization message >>>> based on a CAA-PKP property. >>>> >>> >>> Wouldn't it be a lot better not to do the validations at all if you can >>> tell at new-order time that you're not going to be willing to issue? >>> >>> >>> >>>> In-fact, we already have to be rechecking CAA for authorizations >>>> validated more than 8 hours ago at the time of issuance so there must be >>>> code in place to check CAA at finalization and clients must be prepared for >>>> their order to be rejected at finalization based on CAA already. >>>> >>>> I don't see how this is any more annoying. >>>> >>>> - cpu >>>> >>>> On Tue, Oct 24, 2017 at 10:17 AM, Ilari Liusvaara < >>>> [email protected]> wrote: >>>> >>>>> On Tue, Oct 24, 2017 at 02:45:01PM +0100, Hugo Landau wrote: >>>>> > >>>>> > The ACME protocol should permit CAs to implement policy as far as is >>>>> > reasonably practicable with regard to the workflows around which the >>>>> > protocol is organised. Providing the CSR up-front allows the CA to >>>>> > predicate order processing on aspects of that CSR, both with regard >>>>> to >>>>> > the present protocol and any future extensions, both now and in the >>>>> > future in ways that we can and cannot foresee. I don't think it's >>>>> > appropriate to defer giving critical information to the CA until the >>>>> > last minute due to a resource utilisation concern which LE has >>>>> already >>>>> > proven capable of dealing with, especially when the whole point of >>>>> the >>>>> > order flow in the first place was to provide more flexibility for >>>>> CAs to >>>>> > institute policy. >>>>> >>>>> Example: Suppose that CAA-PKP got added (restrict issuance on SPKI >>>>> key). Implementing that without knowing the public key at validation >>>>> time is annoying. >>>>> >>>>> As to why one would want something like that, it would allow limiting >>>>> trust on certficiate management system without deploying something as >>>>> dangerous as HPKP. >>>>> >>>>> >>>>> >>>>> -Ilari >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Acme mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/acme >>>> >>>> >>> >> > > > _______________________________________________ > Acme mailing [email protected]https://www.ietf.org/mailman/listinfo/acme > > >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
