On 26/07/16 23:03, Richard Barnes wrote: > Option 2: copy/paste the "new-authz" flow back into the spec. > However, that's a lot of spec machinery to re-import, and it doesn't > allow the CA to express any sort of simplification due to multiple > domain names, such as the "just validate the top-level domain" policy > in the other thread that's going on right now. > > Given those trade-offs, I wonder if some sort of intermediate > approach would be better. The best thing that's come to me so far is > to fork the application process: > > - Add an "identifiers" field to the application object > - Each application MUST have exactly one of "csr" and "identifiers" > - If "csr" is present, then do what's in the draft now > - If "identifiers" is present, then do the same dance, but don't > issue the certificate
One problem I see here is that a identifier of type: "dns" is currently defined as a FQDN, without a wildcard label, which would be a valid value of a dNSName field in a CSR (the decision of whether that's acceptable and which identifiers need to be validated for that value being up to server policy). With these options, we'd have to either: 1. Re-define identifiers to allow wildcard labels (probably not a good idea?), 2. use a different name/type that allows wildcards (or more generally: anything you might consider a valid identifier in a CSR), or 3. force clients to understand server policy if they want to use pre-authorizations by asking them to predict exactly which FQDNs the server would ask to be validated in advance (which might be more or less impossible if, as an example, the server policy for wildcard domains is "solve a challenge for a random subdomain"). Given that this was one of the reasons for the "Application" refactor (IIRC), I don't think that's a good option either. _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
