Re: [TLS] Trusting self-signed TLS certificates - specifically for HTTPS

[Ollie <[e-mail]>]

Hi Bas,

Good question - my suggestion is for CT logs to check for the DANE records as explained in this git repo: https://github.com/OllieJC/justselfsigned.org
Here's a copy:

Unfortunately, existing CT logs do not support SSCs (self-signed certificates) 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:

1. 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)
2. the SSPC signature is added to tlsa._dane TLSA record for every domain
3. SSPC is submitted to a CT log
4. CT log checks for valid domains and associated TLSA signatures and issues an SCT (Signed Certificate Timestamp)
5. SSC (Self-Signed Certificates) is generated from the SSPC to include the SCT
6. SSC signature is added to TLSA records (likely replacing the pre-certificate signature)
7. SSC is submitted to the CT log
8. CT log checks for valid domains, associated TLSA records and a valid SCT

Thanks,
Ollie

-------- Original Message --------
On 29 Nov 2022, 00:04, Bas Westerbaan wrote:

>> In essence, I'm proposing that user agents should trust a fully DNSSEC domain with a TLS certificate set up using DANE, along with changes to CT log submission process to allow self-signed certificates (looking to suggest via rfc9162).
>
> How do you propose we prevent CT from being DoSed by a deluge of self-signed certificates?
>
> Best,
>
> Bas