undefined | Better HN

0 pointsthrow0101a1mo ago0 comments

> Let's Encrypt could of course continue offering client certificates if they wanted to, but they'd need to set up a separate root for those certificates to chain up to, and they don't think there's enough demand for that to be worth it.

Why an entire new root? Perhaps set up a ACME profile [1] where the requestor could ask for clientAuth if their use case would be helped; the default would be off.

Google would be free to reject with-clientAuth HTTPS server certificates in their browser, but why should they care if a XMPP or SMTP server has a such a certificate if the browser never sees it?

[1] https://datatracker.ietf.org/doc/draft-ietf-acme-profiles/

0 comments

Ajedi321mo ago

That's not allowed.

> To qualify as a dedicated TLS server authentication PKI hierarchy under this policy:

> All corresponding unexpired and unrevoked subordinate CA certificates operated beneath an applicant root CA MUST:

> [...]

> when disclosed to the CCADB…

> [...]

> on or after June 15, 2025, include the extendedKeyUsage extension and only assert an extendedKeyUsage purpose of id-kp-serverAuth.

> [...]

> NOT contain a public key corresponding to any other unexpired or unrevoked certificate that asserts different extendedKeyUsage values.

https://googlechrome.github.io/chromerootprogram/policy-arch...

throw0101aOP1mo ago

> That's not allowed.

According to Google. Why do they get to dictate this?

Per the current (2.2.2) CAB requirements [1], §7.1.2.10.6, "CA Certificate Extended Key Usage": id-kp-clientAuth is a MAY.

If I was (say) Let's Encrypt I would (optionally?) allow it and dare Google/Chrome to remove my root certificate. Letting bullies get away with this kind of non-sense only encourages them.

[1] https://cabforum.org/working-groups/server/baseline-requirem...

nightpool1mo ago

Have you been reading the thread? https://news.ycombinator.com/item?id=46952590 there are a lot of reasons why browsers need to care about whether CAs are issuing insecure certificates to XMPP or SMTP servers (or credit card machines)

throw0101aOP1mo ago

> […] there are a lot of reasons why browsers need to care about whether CAs are issuing insecure certificates to XMPP or SMTP servers (or credit card machines)

Why does having the clientAuth capability make a certificate "insecure"?

j / k navigate · click thread line to collapse

0 pointsthrow0101a1mo ago0 comments

Why an entire new root? Perhaps set up a ACME profile [1] where the requestor could ask for clientAuth if their use case would be helped; the default would be off.

Google would be free to reject with-clientAuth HTTPS server certificates in their browser, but why should they care if a XMPP or SMTP server has a such a certificate if the browser never sees it?

[1] https://datatracker.ietf.org/doc/draft-ietf-acme-profiles/

0 comments

Ajedi321mo ago

That's not allowed.

> To qualify as a dedicated TLS server authentication PKI hierarchy under this policy:

> All corresponding unexpired and unrevoked subordinate CA certificates operated beneath an applicant root CA MUST:

> [...]

> when disclosed to the CCADB…

> [...]

> on or after June 15, 2025, include the extendedKeyUsage extension and only assert an extendedKeyUsage purpose of id-kp-serverAuth.

> [...]

> NOT contain a public key corresponding to any other unexpired or unrevoked certificate that asserts different extendedKeyUsage values.

https://googlechrome.github.io/chromerootprogram/policy-arch...

throw0101aOP1mo ago

> That's not allowed.

According to Google. Why do they get to dictate this?

Per the current (2.2.2) CAB requirements [1], §7.1.2.10.6, "CA Certificate Extended Key Usage": id-kp-clientAuth is a MAY.

If I was (say) Let's Encrypt I would (optionally?) allow it and dare Google/Chrome to remove my root certificate. Letting bullies get away with this kind of non-sense only encourages them.

[1] https://cabforum.org/working-groups/server/baseline-requirem...

nightpool1mo ago

throw0101aOP1mo ago

> […] there are a lot of reasons why browsers need to care about whether CAs are issuing insecure certificates to XMPP or SMTP servers (or credit card machines)

Why does having the clientAuth capability make a certificate "insecure"?

j / k navigate · click thread line to collapse