Security Headers & PGP Email Encryption

As of today, this site now has strong security headers that will protect the site.

The tools I used to examine and create such are securityheaders.com and csp-evaluator.withgoogle.com

As for PGP email support; yes this site has supported PGP email from the day of creation, however support for such has improved in a few miscellaneous ways and as PGP email evolves, should continue to improve support.

For those that don't know what PGP is, here is a explanation.

For those that know what PGP is and want my public pgp key, https://pgp.greenstars.cc/email/Website[AT]bluestars.cc

However. All of these methods are somewhat complex, and due to attempting to setup without using terminal, instead wanting simply export and upload, yet not finding a SIMPLE method for such, thus here is a THEORETICAL example with the goal of inspiring a standard and very simple to setup/use format for PGP public key access to use for email.

Domains supporting the pgp subdomain format MUST have a pgp subdomain in the format of pgp.example.com.

Domains with support MAY have a config.txt file located at pgp.example.com/config.txt which SHOULD be assumed to have all values set to default unless set within the txt file.

A example of a correctly formatted config.txt file using all currently avalible THEORETICAL values and set to their defaults is:

email, True;
  emailpath, False;
  [AT], True;
 keyid, True;
  keyidpath, False;
 fingerprint, True;
  fingerprintpath, False;

Setting a path value to true requires lookup of the thing for which path is being set to also be true and will start the path with the name of that for which path is enabled. For example a fingerprintpath, True; value would mean fingerprint pgp lookup would occur in the format pgp.example.com/fingerprint/FDCF2C35F36A87215B9393315A4157DE816D706C

Queries are to work in the format of:

IF both pgp.example.com/[email protected] AND pgp.example.com/example[AT]subdomain.example.com ([AT] MUST be supported unless specified not to in config.txt) do not return a .asc pgp file (valid asc file example) then it is assumed to have no pgp value and subdomain fallback MUST be attempted.; Fallback to/from keyid and/or fingerprint MAY be attemped before (sub)domain fallback following path format if set.

Subdomain fallback attempts MUST follow the format of pgp.example.com/subdomain.example.com and MAY return a .txt with the value "NOKEY" to instruct clients not to fallback to domain key (for specified subdomains) even if it exists.

IF a subdomain is NOT assigned a specific fallback key then a attempt to retrieve a asc file in the format of pgp.example.com/unknownfallback?domain=example.com SHOULD be attempted. Attempts in the format of pgp.example.com/unknownfallback SHOULD NOT be used to prevent accidental encryption if a domain uses the pgp domain of another via a cname alias.

IF unknownfallback is supported servers SHOULD specify domain for which the key applies in the format of ?domain=example.com. Additionally if unknownfallback is supported servers MAY return a .txt with the value "NOKEY" to instruct clients not to fallback to domain key (for unknown subdomains) even if it exists.

IF unknownfallback IS NOT supported/set AND subdomain fallback fails then domain fallback MUST be attempted in the format of pgp.example.com/example.com and is assumed to fail if a .asc pgp file is not returned. ("NOKEY" SHOULD NOT be returned as there is no further fallback).

Once more to clarify, this is NOT a proposed standard and is simply a theoretical EXAMPLE intended to inspire such.