On Tue, Jul 26, 2016 at 1:13 PM, Richard Barnes <r...@ipv.sx> wrote: > > > 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 >
So, it's more than a policy decision, unfortunately; it's a combination of two properties of the DNS that are problematic. The first is that control of a specific label has no easily generalized implication about administrative control of subsidiary labels. The IAB controls .ARPA, for example, but has delegated e164.arpa in a way that would make allowing the IAB to request certificates for delegations under it to be a pretty problem. The same problem occurs for many gTLDs, ccTLDs, and a number of second level domains. The work in the DBOUND working group also notes this in describing delegation <https://datatracker.ietf.org/doc/draft-deccio-dbound-organizational-domain-policy/?include_text=1> : "However, policies governing the use of domain names do not always align with those lines of delegation. There are currently no generally reliable methods to reconcile domain names with policy for their use." They are working on the problem, of course, but it is still a problem. The second issue is that this seriously worsens the cache poisoning attack; if you manage to cache poison the CA's view of the hierarchical ancestor, you would now be able to generate certificates for all its descendants. So, while I agree that this is a policy issue, I believe that the specification should have a statement that the default should be restrictive and why. I don't think that the text should be in an appendix, frankly, but should be pretty much front and center with appropriate warnings. (as an individual) Ted > > >> 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 > >
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
