It does mean Unix timestamps. The blog post doesn’t have the full details.

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.

Note that we only do best-effort submission of final certs, so it's not actually guaranteed that they end up being logged.

Two current mitigations and one future:

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.

Ah that makes sense. I was wondering why I haven’t heard of cases of successfully attacks like this. Thank you for the info!

This wasn’t the first version of the ballot, so there was substantial work to get consensus on a ballot before the vote.

CAs were already doing something like this (CNAME to a dns server controlled by the CA), so there was interest from everyone involved to standardize and decide on what the rules should be.

We (Let’s Encrypt) also agree 10 days seems too long, so we are migrating to 7 hours, aligning with the restrictions on CAA records.

Yes, you can limit both challenge types and account URIs in CAA records.

To revoke the record, delete it from DNS. Let’s Encrypt queries authoritative nameservers with caches capped at 1 minute. Authorizations that have succeeded will soon be capped at 7 hours, though that’s independent of this challenge.

There is no username in ACME besides the account URI, so the UUID you’re suggesting isn’t needed. The account uri themselves just have a number (db primary key).

If you’re worried about correlating between domains, then yes just make multiple accounts.

There is an email field in ACME account registration but we don’t persist that since we dropped sending expiry emails.

It’s still a valid point IMHO - why not just use the public key directly? It seems like the account URI just adds problems instead of resolving any.

It has these primary advantages:

1. It matches what the CAA accounturi field has

2. Its consistent across an account, making it easier to set up new domains without needing to make any API calls

3. It doesn’t pin a users key, so they can rotate it without needing to update DNS records - which this method assumes is nontrivial, otherwise you’d use the classic DNS validation method

Interesting.

I didn't realize the email field wasn't persisted. I assumed it could be used in some type of account recovery scenario.

As I understand it, greynoise is monitoring scanner traffic, so yes this would all be scans or attacks

The current PKI system was designed by Netscape as part of SSL to enable secure connections to websites. It was never independent of the web. Of course PKIs and TLS have expanded beyond that.

"WebPKI" is the term used to refer to the PKI used by the web, with root stores managed by the browsers. Let's Encrypt is a WebPKI CA.

The "client cert" requirements were specifically not a CABF rule because that would rule it out for everyone complying with those rules, which is much broader than just the CAs included in Chrome.

Some CAs will continue to run PKIs which support client certs, for use outside of Chrome.

In general, the "baseline requirements" are intended to be just that: A shared baseline that is met by everyone. All the major root programs today have requirements which are unique to their program.

Thanks for chiming in! I remember now that you also said this on the LE community forum.

Right, that explains it. So the use would be for things other than websites or for websites that don't need to support Chrome (and also need clientAuth)?

I guess I find it hard to wrap my head around this because I don't have experience with any applications where this plus a publicly trusted certificate makes sense. But I suppose they must exist, otherwise there would've been an effort to vote it into the BRs.

If you or someone else here knows more about these use cases, then I'd like to hear about it to better understand this.

Are you asking why an HTTPS server would need to use client auth outside of the browser? The answer is mTLS. If you want to use one cert for your one domain to serve both "normal" browser content and HTTPS APIs with mTLS, your cert needs to be able to do it all.

The server that wants to authenticate clients via mTLS doesn't need the clientAuth EKU on its certificate, only the clients do.

Most of the time you set up mTLS by creating your own self-signed certificate and verifying that the client has that cert (or one that chains up to it). I'm wondering what systems exist that need a publicly trusted cert with clientAuth.

Only think I've heard of so far is XMPP for server-to-server auth, but there are alternative auth methods it supports.