> > - 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
[ citation needed ] A. Do all the checks on the first shot, at the cost of possibly doing a > revocation later Is this the kind of behaviour we want to encourage for CAs? I realize ACME doesn't address policy questions but it also shouldn't encourage sloppy behaviour from CAs with its design. 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". I'm trying to point out that sending the CSR twice seems like it makes client development easier but there are corner cases that do not match that assessment. We can try to reduce the corner cases with a warning that "you ought not do that" but there will be server implementations that ignore that recommendation and clients will likely have to update their implementations to accommodate this reality. I understand that these corner cases aren't a super convincing line of argument, but I also don't think a slight preference for double CSR strictly because it allows delivering a public key rejection error slightly earlier in the order flow is a very convincing argument either. Does someone have something stronger in mind? - Daniel / cpu On Thu, Nov 2, 2017 at 10:15 AM, Richard Barnes <[email protected]> wrote: > > > 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
