On Tue, Jul 26, 2016 at 6:48 PM, Patrick Figel <patfi...@gmail.com> wrote:
> On 26/07/16 18:00, Peter Bowen wrote: > > I don't see anything in the ACME specification that disallows this > > at the protocol level. I think a CA could request you validate a > > DNS identifier of 'example.com', then accept that authorization for > > the issuance of 'ship.example.com'. Conversely, ACME does not > > require CAs allow such and I hope it stays that way. CA policy > > should be distinct from ACME. > > Agreed that this should be a policy decision. +1 > It's worth pointing out, > however, that prior drafts contained language that made it clear that > it's a policy decision, which seems to have been removed in the acme-03 > draft. It used to read: > "It is up to the server's local policy to decide which names are > acceptable in a certificate, given the authorizations that the server > associates with the client's account key." > > Was this removed deliberately, or did it get lost as part > of the "Application" change? I think it would make sense to add > something like that to the CA Policy Considerations section, just to > make it clear that this is indeed a policy decision (unless the WG > thinks otherwise?) > It was a side-effect of the "application" refactor. ISTM that the "application" approach is way more flexible with regard to this sort of thing. Before, the assumption was that you would do a "new-authz" for each specific name, and there was no way for the server to tell you that you just needed to prove control of the top-level domain. With the "application" approach, you can send in a CSR, and the server can tell you just to authorize the top-level name. Could someone file an issue to re-add this text? Or better yet, send a PR? :) All that said, I don't really think this style of validation is a good idea, for the reasons Rich points out. But this is not really the place to have that discussion. --Richard > > _______________________________________________ > 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
