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