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 list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
