On Wed, Nov 1, 2017 at 7:10 PM, Richard Barnes <[email protected]> wrote: > > > 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. >
This seems like a great opportunity for defects. -Ekr > > --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 > >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
