Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow Wildcard Domains Like Certificates #142

Closed
dezren39 opened this issue Jan 13, 2019 · 2 comments
Closed

Allow Wildcard Domains Like Certificates #142

dezren39 opened this issue Jan 13, 2019 · 2 comments

Comments

@dezren39
Copy link

Is your feature request related to a problem? Please describe.
I saw that you had listed this requirement:

[...] "A security.txt file MUST only apply to the domain in the URI used to retrieve it, not to any of its subdomains or parent domains."

You had described in #69 that you had considered them early on but couldn't figure out how to allow them. I understand the reason that a security.txt file cannot apply to a parent domain, but I feel that it should be possible for a security.txt file for the root domain to cover all subdomains.

Describe the solution you'd like
Perhaps allow full domain coverage through the use of DNS as in #91. If you own the DNS you own the service, right? Aside from DNS spoofing, which may be mitigated with encryption.

If new features were allowed, some sort of 'include' directive:
include-subdomain: *
include-subdomain-allow-override: dev.people.
include-subdomain-allow-override: pages.
include-subdomain-allow-override: *ftp.
include-subdomain-allow-override: *.sftp.

"-allow-override" signifying your permission for that subdomain to publish their own.

Obviously nothing forces a researcher to go check the parent domain's security.txt, but then it's possible to make one security contact for your entire domain instead of one for each subdomain. Some sites have very many subdomains. For instance, github.io. This can limit the reach of the security.txt file, because it can't be centrally managed across all the site. Even trivially, www vs no www. Taken literally, I'd need invididual security.txt files with their own canonical links. I've got pages that are the exact same website but accessible from multiple subdomains. I'm not restructuring my website for this.

Additional context
I know that I'm going to add this file to my root domain's .well-known, but I don't have personalized .well-known folders for each of my subdomains. The ones that need them use and reference the same .well-known folder from the root domain. I want to set this to my policies, with my contact info and keybase, and be done. Larger organizations have such permissions/communication overhead that it may be difficult to get this utilized for all of a company's services. Instead of Security setting the file for the domain, each individual team will have to choose or be told to implement.

@dezren39 dezren39 changed the title Allow Wildcard Domain's Like Certificates Allow Wildcard Domains Like Certificates Jan 13, 2019
@dezren39
Copy link
Author

#35

@nightwatchcyber
Copy link
Contributor

We will defer this to future work to address via a new field in the IANA registry

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants