undefined | Better HN

0 pointsMattJ1001mo ago0 comments

They weren't "HTTPS certificates" originally, just certificates. They may be "HTTPS certificates" today if you listen to some people. However there was never a line drawn where one day they weren't "HTTPS certificates" and the next day they were. The ecosystem was just gradually pushed in that direction because of the dominance of the browser vendors and the popularity of the web.

I put "HTTPS certificates" in quotes in this comment because it is not a technical term defined anywhere, just a concept that "these certificates should only be used for HTTPS". The core specifications talk about "TLS servers" and "TLS clients".

0 comments

growse1mo ago

The CAB is only concerned with the WebPKI. This means HTTPS.

There's loads of non web, non HTTPS TLS use cases, it's just the CAB doesn't care about those (why should it?).

ge0rg1mo ago

This is technically true, and nobody contested the CABF's focus on HTTPS TLS.

However, eventually, the CABF started imposing restrictions on the public CA operators regarding the issuance of non-HTTPS certificates. Nominally, the CAs are still offering "TLS certificates", but due to the pressure from the CABF, the allowed certificates are getting more and more limited, with the removal of SRVname a few years ago, and the removal of clientAuth that this thread is about.

I can understand the CABF position of "just make your own PKI" to a degree, but in practice that would require a LetsEncrypt level of effort for something that is already perfectly provided by LetsEncrypt, if it wouldn't be for the CABF lobbying.

growse1mo ago

> CABF started imposing restrictions on the public CA operators regarding the issuance of non-HTTPS certificates.

The restriction is on signing non web certificates with the same root/intermediate as is part of the WebPKI.

There's no rule (that I'm aware of?) that says the CAs can't have different signing roots for whatever use-case that are then trusted by people who need that use case.

throw0101a1mo ago

> The CAB is only concerned with the WebPKI. This means HTTPS.

[citation needed]

The title of their current (2.2.2) standard is "Baseline Requirements for the Issuance and Management of Publicly‐Trusted TLS Server Certificates":

* https://cabforum.org/working-groups/server/baseline-requirem...

§1.3, "PKI Participants", states:

> The CA/Browser Forum is a voluntary organization of Certification Authorities and suppliers of Internet browser and other relying‐party software applications.

IMHO "other relying-party software applications" can include XMPP servers (also perhaps SMTP, IMAP, FTPS, NNTP, etc).

growse1mo ago

> [citation needed]

My citation is the membership of the CAB.

> IMHO "other relying-party software applications" can include XMPP servers (also perhaps SMTP, IMAP, FTPS, NNTP, etc).

This may be your opinion, but what's the representation of XMPP etc. software maintainers at the CAB?

1 more reply

j / k navigate · click thread line to collapse

0 comments

growse1mo ago

The CAB is only concerned with the WebPKI. This means HTTPS.

There's loads of non web, non HTTPS TLS use cases, it's just the CAB doesn't care about those (why should it?).

ge0rg1mo ago

This is technically true, and nobody contested the CABF's focus on HTTPS TLS.

growse1mo ago

> CABF started imposing restrictions on the public CA operators regarding the issuance of non-HTTPS certificates.

The restriction is on signing non web certificates with the same root/intermediate as is part of the WebPKI.

There's no rule (that I'm aware of?) that says the CAs can't have different signing roots for whatever use-case that are then trusted by people who need that use case.

throw0101a1mo ago

> The CAB is only concerned with the WebPKI. This means HTTPS.

[citation needed]

The title of their current (2.2.2) standard is "Baseline Requirements for the Issuance and Management of Publicly‐Trusted TLS Server Certificates":

* https://cabforum.org/working-groups/server/baseline-requirem...

§1.3, "PKI Participants", states:

> The CA/Browser Forum is a voluntary organization of Certification Authorities and suppliers of Internet browser and other relying‐party software applications.

IMHO "other relying-party software applications" can include XMPP servers (also perhaps SMTP, IMAP, FTPS, NNTP, etc).

growse1mo ago

> [citation needed]

My citation is the membership of the CAB.

> IMHO "other relying-party software applications" can include XMPP servers (also perhaps SMTP, IMAP, FTPS, NNTP, etc).

This may be your opinion, but what's the representation of XMPP etc. software maintainers at the CAB?

1 more reply

j / k navigate · click thread line to collapse