Scott_Helme_

I wrote my thoughts on that already: https://scotthelme.co.uk/passkeys-are-not-a-trap/

The public key is calculated from the private key, so it all still works, it's just a public key for a private key of 4.

If an attacker takes the CA key and issues a valid certificate, but does not log it to CT, mainstream browser clients will not accept it.

When a certificate is logged to CT, you get back an SCT, and the issuing CA will normally include that in the certificate. The browser will then accept this certificate as it has the correct SCTs (there are always at least two).

The attacker issued certificate hasn't been logged, so can't have an SCT, so won't be accepted by the browser.

We can't say that no certificates have been issued by an attacker. We can say that no certificates have been issued by an attacker that a modern browser client would accept.

But that's detectable and what we have MMD for, a log operator that does this can be found out.

Yes, exactly this.

I have an older blog post that goes in to a little detail on what a CA is and how it works: https://scotthelme.co.uk/impending-doom-root-ca-expiring-leg...

Wouldn't that be almost 2,000 root CAs?

Also if it's the same CA operating a bunch of different roots for different TLDs, they're likely to just make the same mistake that impacts them all. Sadly, I can't see anything like this working.

Hey what's wrong with Passkeys?!

I'm not sure what laws apply to you where you live so you'd have to check, but you could also do this on pen and paper if that helps :)

Yep, it's a long tail. Anything that ships it's own CA bundle will ignore whatever you fix at the OS level. Those bundles are generally root-only and don't have revocation checking, so they can't block a bad intermediate cert.

The fix can only come from the tool shipping an updated bundle, or if there's some way you can point it at the OS store once that's updated.

If you've got the compute power, it's easy enough to have a go at it!

Apple has blocked the intermediates, so updating is good enough to resolve it for you.

Fair enough, call it a mix if you like. I'm happy to stand behind every claim in my post, and if something's wrong, tell me and I'll fix it.

I agree this is a burden placed on domain owners, but who else can know if a certificate for my domain 'scotthelme.co.uk' was supposed to be issued other than me, the owner of 'scotthelme.co.uk'?

Do you have any info on the malicious CT logs? I'd be interested to read something on that!

CAA records are only checked by the CA at the point of issuance, not by the client later. If they did, there are problems to consider:

1. A domain would have to keep the CAA records for a CA in place to keep using the certificates from that CA, but that means continuing to authorise new issuance too. Right now, I can remove the `letsencrypt.org` value to stop them from issuing new certificates for me, but I can keep using any certificates I have until they expire.

2. The client would need to have support for this new DNS RR type.

3. The client would need a secure way to query DNS, which is not widespread.

Yeah, this would work.

For a scenario like this it doesn't help a given client what % of the ecosystem does SCT validation or not, all that matters is whether that client does it.

I agree that more SCT validation across the ecosystem reduces the value of a mis-issued certificate to an attacker, but a lot of value still remains.

If 90% of clients did SCT validation, an attacker can still succeed against the 10% that don't, there's no herd immunity.

1. They could do this now, the implementation exists publicly, but I think it would be better at the OS level like upki for revocation: https://discourse.ubuntu.com/t/addressing-linuxs-missing-pki...

2. I don't think such constraints would really work. My company might have 4 domains on different TLDs and then end up needing to use 4 different CAs. Geography doesn't really apply on the Internet.

The problem now becomes all of the things that can't be so easily updated.

It's a valid question at this point.

I'm just not sure that I can see a world where all devices that rely on TLS/PKI are capable of CT SCT validation. Look at the issues we have around stale root stores still happening when we have validity periods of literally decades. Some of these clients out there simply won't ever be able to keep their trusted log store updated.

Refs: Part 1: https://scotthelme.co.uk/impending-doom-root-ca-expiring-leg... Part 2: https://scotthelme.co.uk/complexities-chain-building-ca-infr... Part 3: https://scotthelme.co.uk/cross-signing-alternate-trust-paths... Part 4: https://scotthelme.co.uk/building-certificate-chains/

There's also the Let's Encrypt root migration that was postponed due to legacy devices: https://scotthelme.co.uk/lets-encrypt-postpone-isrg-root-tra...

Can't lose your key if it's easy to remember!

I think this might be proprietary source code, did you get permission to share this?..

It's an interesting idea, but how would a user make that decision on who to trust? As in, what 'things' could we look at to make that call?

It was all written by me and then I had final pass/tweak with Claude.

Yeah this is absolutely possible, and while they are a few good opportunities like this, it also means that someone else can decrypt all of your traffic in the same way.

That really depends how you define "trusted certificate authorities".

If you're talking about root certs then it's almost 350 currently trusted by at least one major operator.

If you include intermediates, you're talking more than 3,600!

I have to be honest, that hasn't stopped me from trying!

Just imagine how much stuff you're going to be able to MiTM now!!