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
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
