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
