justselfsigned.org is an example site with recommendations for the adoption of more decentralisation in the HTTPS trust system.
In summary, user agents should trust SSCs (Self-Signed Certificates) with DNS Security Extensions (DNSSEC) and DANE (DNS-based Authentication of Named Entities).
A user agent is any browser, client or HTTP library; for example, Mozilla Firefox, curl, or python httpx.
Ideally, user agents should additionally trust websites with the following configuration:
- fully-trusted DNSSEC domain name
- have an SSC with only valid public domains
- all domain names in an SSC have valid TLSA DNS records with signatures that match the SSC
- SSCs have less than a 90-day expiry
- inclusion in CT (Certificate Transparency) logs with associated SSPC(s) (Self-Signed Pre-Certificate)
Unfortunately, existing CT logs do not support SSCs due to spam concerns (rfc6962). The suggestion (being raised in rfc9162) is for CT logs to check for full DNSSEC compliance and TLSA records when generating a CT log entry for SSCs, which would work in the following way:
- a new SSPC (Self-Signed Pre-Certificate) is generated with the following:
- only valid domains
- less than 90-day expiry (although this may start in the future)
- the SSPC signature is added to
tlsa._daneTLSA record for every domain - SSPC is submitted to a CT log
- CT log checks for valid domains and associated TLSA signatures and issues an SCT (Signed Certificate Timestamp)
- SSC (Self-Signed Certificates) is generated from the SSPC to include the SCT
- SSC signature is added to TLSA records (likely replacing the pre-certificate signature)
- SSC is submitted to the CT log
- CT log checks for valid domains, associated TLSA records and a valid SCT
Additionally, CT logs could use SSCs, where they would add their SSPC and SSC to their own log. The client adding the first SSPC and SSC (of the CT log itself) to the CT log would not check CT logs during the initial creation of the CT log.
These are the current certificates in use by the site: