> > This sounds like you want to provide the order identifiers that > triggered this authorization within the authorization object?
Generally speaking yes. In principle, several order identifiers could lead to a single > authorization I guess? > I think in principle that's true. ACME doesn't prescribe that there be a single authorization per-identifier. Perhaps Wildcards are just the most immediate case of there being a disconnect between the order identifiers and the authorizations. I was thinking only of identifier value but you're right that there may be a disconnect in the quantity of order authorizations compared to requested identifiers. It would be helpful if a CA with intentions to implement an issuance policy that differs from "n order identifiers, n authorizations" would speak up. I'm partial to the optional bool field because its very simple. Your proposal is more robust but also a bigger change and I'd like to know someone in the real world will benefit from the work involved :-) - Daniel / cpu On Fri, Mar 2, 2018 at 3:46 PM, Sophie Herold <[email protected]> wrote: > On 02/03/18 18:32, Daniel McCarney wrote: > > Richard: That's up to the client and the situation. In the linked Certbot > > issues there were questions about error output/UX. In this case if the > > client saw an error attached to an authorization with the identifier `{ > > "type": "dns", "value": "example.com"}` and the authorization had > > `wildcard: true` the client could say "Failed to authorize *.example.com > : > > blah blah blah" or otherwise use the knowledge to inform their actions > > (whatever they may be). > > This sounds like you want to provide the order identifiers that > triggered this authorization within the authorization object? > > I think, in general it is just a guess that exmaple.com + wildcard means > that the order contains *.example.com. This depends on which > authorizations are created for which order identifiers, which is not > specified by acme. > > In principle, several order identifiers could lead to a single > authorization I guess? For example, if sub1.example.org and > sub2.example.org lead to just an example.org authorization. Therefore > "orderIdentifiers", as I call it here, needs to be a list: > > { > "status": "valid", > "expires": "2015-03-01T14:09:00Z", > > "identifier": { > "type": "dns", > "value": "example.org" > }, > > "orderIdentifiers": [ > { > "type": "dns", > "value": "*.example.org" > } > ], > > "challenges": [ > … > > Best, > Sophie > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
