Re: [FORGED] Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert
On Sat, Jul 4, 2020 at 9:41 PM Peter Gutmann wrote: > Ryan Sleevi writes: > > >And they are accomodated - by using something other than the Web PKI. > > That's the HTTP/2 "let them eat cake" response again. For all intents and > purposes, PKI *is* the Web PKI. If it wasn't, people wouldn't be worrying > about having to reissue/replace certificates that will never be used in a > web > context because of some Web PKI requirement that doesn't apply to them. > Thanks Peter, but I fail to see how you're making your point. The problem that "PKI *is* the Web PKI" is the problem to be solved. That's not a desirable outcome, and exactly the kind of thing we'd expect to see as part of a CA transition. PKI is a technology, much like HTTP/2 is a protocol. Unlike your example, of HTTP/2 not being considerate of SCADA devices, PKI is an abstract technology fully capable of addressing the SCADA needs. The only distinction is that, by design and rather intentionally, it doesn't mean that the billions of devices out there, in their default configuration, can or should expect to talk to SCADA servers. I'm would hope you recognize why that's undesirable, just like it would be if your phone were to ship with a SCADA client. At the end of the day, this is something that should require a degree of intentionality. Whether it's HL7 or SCADA, these are limited use cases that aren't part of a generic and interoperable Web experience, and it's not at all unreasonable to think they may require additional, explicit configuration to support. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: [FORGED] Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert
Ryan Sleevi writes: >And they are accomodated - by using something other than the Web PKI. That's the HTTP/2 "let them eat cake" response again. For all intents and purposes, PKI *is* the Web PKI. If it wasn't, people wouldn't be worrying about having to reissue/replace certificates that will never be used in a web context because of some Web PKI requirement that doesn't apply to them. Peter. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: [FORGED] Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert
On Sat, Jul 4, 2020 at 9:21 PM Peter Gutmann wrote: > So the problem isn't "everyone should do what the Web PKI wants, no matter > how > inappropriate it is in their environment", it's "CAs (and protocol > designers) > need to acknowledge that something other than the web exists and > accommodate > it". And they are accomodated - by using something other than the Web PKI. Your examples of SCADA are apt: there's absolutely no reason to assume a default phone device, for example, should be able to manage a SCADA device. Of course we'd laugh at that and say "Oh god, who would do something that stupid?" Yet that's what happens when one tries to make a one-size fits-all PKI. Of course the PKI technologies accommodate these scenarios: you use locally trusted anchors, specific to your environment, and hope that the OS vendor does not remove support for your use case in a subsequent update. Yet it would be grossly negligent if we allowed SCADA, in your example, to hold back the evolution of the Web. As you yourself note, it's something other than the Web. And it can use its own PKI. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: [FORGED] Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert
Eric Mill via dev-security-policy writes: >This is a clear, straightforward statement of perhaps the single biggest core >issue that limits the agility and security of the Web PKI That's not the biggest issue by a long shot. The biggest issue is that the public PKI (meaning public/commercial CAs, not sure what the best collective noun for that is) assumes that the only possible use for certificates is the web. For all intents and purposes, public PKI = Web PKI. For example for embedded systems, SCADA devices, anything on an RFC 1918 LAN, and much more, the only appropriate expiry date for a certificate is never. However, since the Web PKI has decided that certificates should constantly expire because $reasons, everything that isn't the web has to deal with this, or more usually suffer under it. The same goes for protocols like HTTP and TLS, the current versions (HTTP/2 /3 and TLS 1.3) are designed for efficient content delivery by large web service providers above everything else. When some SCADA folks requested a few minor changes to the SCADA-hostile HTTP/2 from the WG, not mandatory but just negotiable options to make it more usable in a SCADA environment, the response was "let them eat HTTP/1.1". In other words they'd explicitly forked HTTP, there was HTTP/2 for the web and HTTP/1.1 for the rest of them. So the problem isn't "everyone should do what the Web PKI wants, no matter how inappropriate it is in their environment", it's "CAs (and protocol designers) need to acknowledge that something other than the web exists and accommodate it". Peter. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
