On Wed, Jul 6, 2016 at 2:54 PM, Jonathan Rudenberg <jonat...@titanous.com> wrote:
> It seems that there are potentially multiple valid sets of authorizations > that are mutually exclusive. > > Consider a request for a certificate that has three SANs: a.example.com, > b.example.com, c.example.com > > There are two valid paths to issuance: validate example.com, or validate > the three SANs as specified in the CSR. > Note that whether these paths are valid depends entirely on the CA's policy. For example, I believe that Let's Encrypt would not consider the "validate example.com" path to be valid. > Under the precondition system, with ACME server/client implementations > that were aware of this shortcut, the client could present a CSR that > included example.com as one of the SANs, the server would return a single > authorization request for example.com, and then after fulfilling that > request, a subsequent request could be made with a CSR that did not contain > the example.com SAN, only the subdomains, which would lead to immediate > issuance without further authorization. > > Does it make sense for the server to be allowed to return multiple > exclusive sets of authorizations that could lead to issuance, in order to > avoid knowledge of the issuance rules in the client? > I don't really find this all that appealing, to be honest. But I would note that we have the "combinations" notion in the authorization struct right now, which we could import here if we think there's really a need to support this use case. I would prefer just having the CA tell the client what to do; flexibility does not seem nearly as necessary here as it does at the authorization/validation stage. --Richard > > Jonathan
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
