Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WebPKI and You

blog.brycekerley.net

Post reply on HN
Print view View original

11–20 of 24 posts

Re: WebPKI and You

#11

Post by lelanthran »

bob1029 wrote: post #9
lelanthran wrote: post #7

Earlier quoted context omitted.

> I am reading your comment and find the proposition interesting, but I can't quite understand the part about the STUN server - doesn't that "just" help me find my own public IP address ? He is hosting his domain on a machine behind a reverse proxy over which he has no control (common enough); in this case the server will not know its own public IP as all resolves to (for example) `www.mydomain.com` will return the a…

You can issue a TLS certificate with a SAN that is a literal IPv4 address. You do not need a domain to serve TLS to clients. It definitely helps with the UX, but it's not mandatory for the browsers and other web tech to function.

If you're running private PKI, sure, you'll do it.

What value is it when you are behind a proxy that can change IP? I mean, I'm going on the assumption that the proxy is not under his control, nor does it do the tls termination.

Re: WebPKI and You

#12

Post by bob1029 »

lelanthran wrote: post #11
bob1029 wrote: post #9

Earlier quoted context omitted.

You can issue a TLS certificate with a SAN that is a literal IPv4 address. You do not need a domain to serve TLS to clients. It definitely helps with the UX, but it's not mandatory for the browsers and other web tech to function.

If you're running private PKI, sure, you'll do it. What value is it when you are behind a proxy that can change IP? I mean, I'm going on the assumption that the proxy is not under his control, nor does it do the tls termination.

If your public interface address can change, it does dramatically reduce the value of a purely IP-addressed host. But I don't think it eliminates it entirely.

With a dynamic IP you can still detect a change, reissue a cert for the new IP and proceed automatically. There are self-hosting and machine-to-machine scenarios where this amount of autonomy could be welcome.

Re: WebPKI and You

#13

Post by alwillis »

ocdtrekkie wrote: post #10

There's a huge suggestion in here which would make PKI vastly more respectable: Disallowing root programs (browser operators) from also being CAs. I loudly suggested at the time Google Trust Services should be rejected but the Mozilla rep loudly defended approving a CA from a root program from a company that happens to pay their entire salary. PKI as it stands is only a few steps from Google just deciding everyone mu…

The CA/Browser Forum, not Google, decides the length of time certificates are valid for.

If you don’t like a particular CA’s policies, you can choose a different one.

Re: WebPKI and You

#14

Post by ocdtrekkie »

alwillis wrote: post #13
ocdtrekkie wrote: post #10

There's a huge suggestion in here which would make PKI vastly more respectable: Disallowing root programs (browser operators) from also being CAs. I loudly suggested at the time Google Trust Services should be rejected but the Mozilla rep loudly defended approving a CA from a root program from a company that happens to pay their entire salary. PKI as it stands is only a few steps from Google just deciding everyone mu…

The CA/Browser Forum, not Google, decides the length of time certificates are valid for. If you don’t like a particular CA’s policies, you can choose a different one.

That's fundamentally untrue. Browser root programs unilaterally decide their requirements, and also unilaterally boot other CA/B members out of the CA/B. The CA/B is not by any means a useful functional body, it's an excuse why companies can't be forced to undo things after the fact.

Re: WebPKI and You

#15

Post by nickf »

alwillis wrote: post #13
ocdtrekkie wrote: post #10

There's a huge suggestion in here which would make PKI vastly more respectable: Disallowing root programs (browser operators) from also being CAs. I loudly suggested at the time Google Trust Services should be rejected but the Mozilla rep loudly defended approving a CA from a root program from a company that happens to pay their entire salary. PKI as it stands is only a few steps from Google just deciding everyone mu…

The CA/Browser Forum, not Google, decides the length of time certificates are valid for. If you don’t like a particular CA’s policies, you can choose a different one.

That's absolutely incorrect. While CABF sets the 'Baseline Requirements' that ultimately go into the WebTrust audit scheme that root programs use to accept roots into their trust stores...browsers can and do set their own rules.

The reduction of TLS cert lifetime to a max of 398 days was an Apple policy.

Re: WebPKI and You

#16

Post by nickf »

ocdtrekkie wrote: post #10

There's a huge suggestion in here which would make PKI vastly more respectable: Disallowing root programs (browser operators) from also being CAs. I loudly suggested at the time Google Trust Services should be rejected but the Mozilla rep loudly defended approving a CA from a root program from a company that happens to pay their entire salary. PKI as it stands is only a few steps from Google just deciding everyone mu…

While I sort-of see what you're trying to say, if you knew the groups and teams involved - you'd know there was no favouritism and a strong degree of separation between CA and root programs.

The root programs who have their own CAs are also cloud providers, who arguably have a legitimate need for the CA. Or in Apple's case they have their own CA, but don't issue externally. They keep CA and root program separate.

Re: WebPKI and You

#17

Post by ocdtrekkie »

nickf wrote: post #16
ocdtrekkie wrote: post #10

There's a huge suggestion in here which would make PKI vastly more respectable: Disallowing root programs (browser operators) from also being CAs. I loudly suggested at the time Google Trust Services should be rejected but the Mozilla rep loudly defended approving a CA from a root program from a company that happens to pay their entire salary. PKI as it stands is only a few steps from Google just deciding everyone mu…

While I sort-of see what you're trying to say, if you knew the groups and teams involved - you'd know there was no favouritism and a strong degree of separation between CA and root programs. The root programs who have their own CAs are also cloud providers, who arguably have a legitimate need for the CA. Or in Apple's case they have their own CA, but don't issue externally. They keep CA and root program separate.

I know the people involved enough to be very concerned that the CA/B decides whether something can exist on the web.

Re: WebPKI and You

#18

Post by alwillis »

nickf wrote: post #15
alwillis wrote: post #13

Earlier quoted context omitted.

The CA/Browser Forum, not Google, decides the length of time certificates are valid for. If you don’t like a particular CA’s policies, you can choose a different one.

That's absolutely incorrect. While CABF sets the 'Baseline Requirements' that ultimately go into the WebTrust audit scheme that root programs use to accept roots into their trust stores...browsers can and do set their own rules. The reduction of TLS cert lifetime to a max of 398 days was an Apple policy.

> browsers can and do set their own rules.

Here's a link to the minutes of the CABF meeting where the 25 certificate issuers and the 4 browser vendors—Apple, Google, Microsoft, Mozilla—agreed to reduce the validity period of TLS certificates unanimously [1].

> The reduction of TLS cert lifetime to a max of 398 days was an Apple policy.

Actually, all of the browser vendors voted to reduce the validity period of TLS certificates from 825 days to 398 days at the September 2019 meeting. The ballot failed because a majority of the certificate issuers voted against it.

At the February 2020 CABF meeting, Apple announced it would unilaterally enforce the 398-day limit through its own root program policy. Starting September 1, 2020, any new TLS certificate with a validity period exceeding 398 days would simply not be trusted by Safari, macOS, or iOS.

This effectively made the 398-day limit a de facto standard — no CA would issue longer certificates if they’d be rejected by Apple devices [2].

    |Date             |Max Certificate Validity|SAN Data Reuse Period|
    |-----------------|------------------------|---------------------|
    |Before March 2026|398 days (current)      |398 days             |
    |March 15, 2026   |200 days                |200 days             |
    |March 15, 2027   |100 days                |100 days             |
    |March 15, 2028   |47 days                 |10 days              |
    |March 15, 2029   |47 days                 |10 days (final)      |
[1]: https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-sch...

[2]: https://www.entrust.com/blog/2020/02/apple-announces-398-day...

Re: WebPKI and You

#19

Post by pseudohadamard »

ivanr wrote: post #3

If you like this sort of thing, perhaps you'll enjoy my SSL/TLS and PKI history where I track a variety of ecosystem events starting with the creation of SSL in 1994: https://www.feistyduck.com/ssl-tls-and-pki-history/

  TLS is not The Web
Does the TLS working group know that? Pretty much all their design work apart from one guy representing email use via Postfix and a few guys working on a perpetual-motion-machine profile for telcos assumes the only possible use for TLS is the web.

Re: WebPKI and You

#20

Post by ivanr »

pseudohadamard wrote: post #19
ivanr wrote: post #3

If you like this sort of thing, perhaps you'll enjoy my SSL/TLS and PKI history where I track a variety of ecosystem events starting with the creation of SSL in 1994: https://www.feistyduck.com/ssl-tls-and-pki-history/

TLS is not The Web Does the TLS working group know that? Pretty much all their design work apart from one guy representing email use via Postfix and a few guys working on a perpetual-motion-machine profile for telcos assumes the only possible use for TLS is the web.

Maybe you're onto something, but in what way do you think that TLS is not serving other protocols?

Personally, I think we have a bigger problem on the PKI side, where Web PKI is very strong, but Internet PKI has been neglected. The recent move to remove client authentication is a good example.

Post reply on HN