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

2022-11-28 Thread Ollie
Hi folks, I'm new to the I-D/RFC process so apologies for any naivety! Firstly, I've done a quick search for any commentary around this but haven't found anything specific - but let me know if I've likely missed something. I want to propose a way for a user agent to trust self-signed certificat

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

2022-11-30 Thread Ollie
igned 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 Me

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

2022-11-30 Thread Ollie
d submit a bunch of certificate chains to CT logs. I consider the current requirement to have a certificate chain rooted to a known CA to be synonymous with requiring a full DNSSEC chain, unless I'm missing (most likely!) something that CAs offer over DNS providers/registrars.

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

2022-12-01 Thread Ollie
> There's nothing to be gained by publishing SCTs in self-issued DANE-EE > validated certificates. Are you proposing to make SCTs mandatory in > DANE? Which user agents would insist on such SCTs and why? If not, > what problem would optionally including them solve? Yes, primarily for browser user

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

2022-12-02 Thread Ollie
st isn't a concern, reliance on a CA is. So getting certificates from LE is a big difference. > So if there's an IETF group to nudge along the lines you suggest, it > might be ACME, rather than TLS, with a suitable directive in > DNSSEC-signed CAA records. Thanks, I'll r