On 10/29/2016 09:26 AM, Richard Barnes wrote: > * Requirement == What you have to do to get *this* *particular* > certificate issued > * Authz == You must do one of N things to prove you control the identifier
Since authz's are recyclable or not at the server's discretion, why do you need two separate types to represent the difference between something needed for *this* *particular* certificate vs something needed for any certificate containing an identifier? You can use the same type to represent both, which simplifies both client and server implementation, as well as simplifying the spec. > The current structure is basically a conjunctive normal form: > > App <= (Chall1 || Chall2) && (Chall3 || Chall4) && Req1 > > That is, there are two things that tell the client what to do, > requirements and challenges. Authorizations allow the CA to offer > groups of challenges "or"ed together. Right - and I'll note that Req1 in this diagram fills exactly the same role as an authz. > (1) the specialization of the authz grouping means you don't have to > repeat the identifier in each challenge The same is true when you specialize on a specific type of authz, i.e. "dns-name". I'll also note that the requirements / authorizations divide is a lot of protocol complexity to take for some unspecific future use case. I agree we need a nice place to slot in extensibility, but I think the place to do that is among the types that are already going to be implemented, specifically authz.
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
