On Thu, Nov 2, 2017 at 9:51 AM, Daniel McCarney <[email protected]> wrote:
> 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. > This doesn't seem like a very convincing line of argument, for a few reasons: - There's not that much time between new-order and finalize (is there?), so it doesn't seem tremendously likely that there will be a change in security posture - Even if there is, there's nothing that says the CA has to behave as you describe. It could: A. Do all the checks on the first shot, at the cost of possibly doing a revocation later B. Do all the checks on the second shot, at the risk of possibly doing some unnecessary authz C. Reuse authorizations, so that the new-order is cheap (Note that the current non-CSR PR is effectively (B), so either case has that risk.) You're basically saying if (1) you do checks both times and (2) you don't re-use authorizations, then you might have to do some unnecessary authz. I would be satisfied to resolve this by saying "you ought not do that". --Richard > > - Daniel / cpu > > > 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. >> 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
