> > 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
