well I brought this already up as "walk-up authorisations" or similar.
Rich Salz brought up domains like wordpress.com and github.io as examples where the parent shouldnt get certs with another check, but I personally think that this is junk. this is (obviously) because the parent could take control of the subdomain and verify it anyway that's just how the system works. not allowing a walk up for subs just makes it more annoying. also talking about cache-poisoning and other funny stuff, one could say that walk up only can occur only in certain conditions, for example that there needs a flag set as a record in DNS and secured by DNSSec and the CA could easily check the DNSSec. also unlike the CA system DNSSec works with a tree-like structure so it's pretty limited on who can sign for what. for example for the domain "google.com" there are only 3 entities that can sign for it. one is obviously Google themselves, then we have the Management of the .com DNSSec key and finnaly (obviously enough) the ICANN with the root key. so one could say that if the authorisation is done via DNSSec'ed DNS authorisation plus a record indicating walk-up it would be fine enough and that would be pretty strict. it may be that in some cases the subdomains are controlled by another entity but it isnt a secret that the parent can take control anyway. That's just my opinin. Best regards (or for all the german readers, MFG) Philipp Junghannß / My1 2016-07-26 22:34 GMT+02:00 Ted Hardie <[email protected]>: > On Tue, Jul 26, 2016 at 1:13 PM, Richard Barnes <[email protected]> wrote: > >> >> >> On Tue, Jul 26, 2016 at 6:48 PM, Patrick Figel <[email protected]> >> 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 >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/acme >>> >> >> >> _______________________________________________ >> Acme mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/acme >> >> > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme > >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
