You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
dezren39
changed the title
Allow Wildcard Domain's Like Certificates
Allow Wildcard Domains Like Certificates
Jan 13, 2019
Is your feature request related to a problem? Please describe.
I saw that you had listed this requirement:
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.
The text was updated successfully, but these errors were encountered: