https://docs.adyen.com/plugins#built-by-adyen

There are no SCTs, which were a compromise to get CT shipped. Each Merkle Tree Certificate has an actual inclusion proof in it.

CT has multiple independent logs, and requires certs to be logged to 2+ of them. With MTC, you have one issuing log, along with signatures from other "witnesses" which monitor and mirror log integrity. Those co-signatures are validated when checking the certificate.

Thus the witness network makes it much harder for logs to fork, as you can't present a forked view to just the client. You also need to present it to a witness. And it'll be much easier for folks to check all the witnesses are in sync.

Monitoring the MTC logs will be easier than CT, as they'll actually be smaller than CT for a few reasons. At least for the initial version, there won't be a better way to monitor for mis-issued certificates for a particular domain than linear scanning all certificates, but that's a problem being worked on for both CT and MTC, called "verifiable indexes".

On other OSes (like Mac OS and Windows), there's also OS-level services which could support this.

It would be a shame if we end up with a bunch of copies of this data, so I think a shared OS service is the only reasonable approach.

The hardest part is going to be smaller embedded systems.

We expect batches to be produced quickly, on the same order of magnitude as current CT logs - somewhere in the 0.5s to 5 second range. This is an existing problem since (at least some) CT logs do the same batched behaviour.

Now, there is a catch with MTCA: That gets you a "standalone" certificate, which works just like a certificate does today. But it's big, still. To get the new, small certificates (landmark-relative), you will have to wait for the next landmark. Based on current planning and discussions with Chrome, we expect that to be hourly for short-lived certs, and 4 hours for longer-lived certificates.

So you'll get a big cert instantly, but you might have to wait an hour or 4 to get a certificate. So your new website can be online quickly, but with some downsides until you get the small landmark-relative cert.

(I work at Let's Encrypt)

There’s some upcoming attempts at transport security for authoritative DNS servers which might help too: https://datatracker.ietf.org/doc/html/draft-hoffman-deleg-se...

To get complete control with DNSSEC, you also need the accounturi and validationmethod extensions (which you need to guarantee only your account can issue, and only with the DNS validation type).

Those aren't yet mandatory, but you can restrict to a CA today which implements them, like Let's Encrypt.

> Co-Authored-By: Claude Opus 4.7

Android has it as a toggle: https://source.android.com/docs/security/features/cellular-s...

iPhone disables it for phones in lockdown mode.

At least as of today, most phones have an option to turn off 2g but that isn't a default.

Comments URL: https://news.ycombinator.com/item?id=47720719

Points: 71

# Comments: 38

I think this is all Github's fault, in the end, but I think we need to get Github to change and until then will keep using squash-merges.

If you update a PR with review feedback, you shouldn’t change existing commits because GitHub’s tools for showing you what has changed since your last review assume you are pushing new commits.

But then you don’t want those multiple commits addressing PR feedback to merge as they’re noise.

So sure, there’s workflows with Git that doesn’t need squashing. But they’re incompatible with GitHub, which is at least where I keep my code today.

Is it perfect? No. But neither is git, and I live in the world I am given.

> The 15-digit pet microchip is the international standard (see ISO 11784:1996 and ISO 11785:1996)

https://www.aaha.org/for-veterinary-professionals/microchip-...

https://en.wikipedia.org/wiki/ISO_11784_and_ISO_11785

You can read the RFC draft at https://datatracker.ietf.org/doc/html/draft-ietf-acme-dns-pe...

It says: CAs MUST properly parse and interpret the integer timestamp value as a UNIX timestamp (the number of seconds since 1970-01-01T00:00:00Z ignoring leap seconds) and apply the expiration correctly.

DNSSEC prevents any modification of records, but isn’t widely deployed.

We query authoritative nameservers directly from at least four places, over a diverse set of network connections, from multiple parts of the world. This (called MPIC) makes interception more difficult.

We are also working on DNS over secure transports to authoritative nameservers, for cases where DNSSEC isn’t or won’t be deployed.