> > 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.
I'm sympathetic to wanting to give this information earlier in the process but I want to point out again that there will always be the potential for errors/rejection to happen at the time of finalization/issuance. All clients will have to handle it whether or not the CSR is included at the time of new-order. I think having two places where the same weak key rejection could occur will be more complicated. It also means that some orders will have to be recreated from scratch, making it harder to recover than in the case where the CSR is only sent at finalization. As a concrete example with "double CSR" orders: * Client A creates an order with CSR_1, covering "example.com", using CPU's ACME CA * Client A fully authorizes their order * CPU's CA becomes aware of a new vulnerability, RIVESTGATEKEYBLEED and updates the weak key policy * Client A sends CSR_1 again to finalize their order. Oops - it's affected by RIVESTKEYBLEED and is rejected. * Client A can not rekey their order and must always send the same CSR as from the new-order request. Outcome: Client A has to create a brand new order with CSR_2, potentially redoing all authorizations depending on CA policy (CPU's CA never reuses authorizations) Conversely, if the CSR was only sent at finalization time there would be only one place for weak-key rejection to occur. If the key policy changed no orders will have to be recreated, a different finalization CSR can be sent with the same set of identifiers. Again more concretely: * Client A creates an order for identifiers "example.com", no CSR is included. * Client A fully authorizes their order * CPU's CA becomes aware of a new vulnerability, RIVESTGATEKEYBLEED and updates the weak key policy * Client A sends CSR_1 covering "example.com" to finalize their order. Oops - it's affected by RIVESTKEYBLEED and is rejected. * Client A sends CSR_2 covering "example.com" to finalize their order. It doesn't use a weak key so the order is finalized. Otucome: Client A gets a cert. Thoughts? In this case it seems like learning later is perhaps an advantage since the actions available to remediate the error are less involved. - Daniel / cpu On Wed, Nov 1, 2017 at 6:12 PM, Brad Warren <b...@eff.org> 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. > 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 <c...@letsencrypt.org> > 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 <r...@ipv.sx> wrote: >> >>> >>> >>> On Mon, Oct 30, 2017 at 10:15 AM, Daniel McCarney <c...@letsencrypt.org> >>> 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 < >>>> ilariliusva...@welho.com> 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 >>>> Acme@ietf.org >>>> https://www.ietf.org/mailman/listinfo/acme >>>> >>>> >>> >> > > > _______________________________________________ > Acme mailing listAcme@ietf.orghttps://www.ietf.org/mailman/listinfo/acme > > >
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
