<div dir="ltr"><div>On Thu, Sep 10, 2020 at 12:55 PM Paul Walsh <<a href="mailto:paul@metacert.com">paul@metacert.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><span style="font-size:17px">Hi Ryan,</span><div style="font-size:17px"><br></div><div><span style="font-size:17px">I tried to avoid posting a follow-up, but I had to correct your perception - I didn’t provide enough insight in my original message - my bad.</span><br style="font-size:17px"><div style="font-size:17px"><br></div><div style="font-size:17px">My carrier/operator example isn’t a hypothetical - sorry for not making that clear. I can’t name names but some carriers want to implement identity verification for URLs inside SMS messages to combat fraud/phishing. They say that trying to block known threats with multiple vendors isn’t working well enough. </div></div></div></blockquote><div><br></div><div>There's nothing inherently wrong with that proposal, and certainly, one of the many places where identity information about a domain can potentially be useful. However, the only caveat is that such use cases don't need to be expressed within TLS itself. The example given previously, of serving a certificate via a defined .well-known URL, could easily provide such information, and even further allow carrier-defined policies (e.g. broadcasting a particular URL via a particular carrier requires prior agreement with that carrier). So I'm not dismissive at all of the value of identity verification with URLs, but rather, highlighting that there's no technical reason to use it in TLS (which itself opens up new risks, for that use case)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><div style="font-size:17px">Due to how my company serves identity info (API instead of TLS), it's in my personal interest to find common ground with you. So I’m motivated to find security issues related to empty/incorrectly populated fields that are ignored by browsers. I just can’t get my head around how unused data has caused actual harm to browser users.</div><div style="font-size:17px"><br></div><div style="font-size:17px">I’ve read as much as I could on this topic thanks to your links. I found it easy to find issues related to fields that browsers use, but I couldn’t find any security issues related to fields that browsers do not use. I know you’re busy, but it would be really amazing if you could point me to just one specific issue so I can really see where you’re coming from. </div></div></div></blockquote><div><br></div><div>The Chair of the Forum has, in their official capacity, expressed concerns that sharing specific CA incidents, despite being publicly available with the intent to help inform and improve the ecosystem, represent Code of Conduct violations because they may embarrass a particular member company, and apparently that is a higher priority than collective improvement.</div><div><br></div><div>However, I think this question is also framed poorly: there's ample evidence that fields unrelated for TLS cause impact in complying with the requirements for TLS, ranging from the aforementioned SHA-1 deprecation (and browser-used certificates being used in non-browser use cases, like payment terminals) to eIDAS (for example, a CA that misissued 100% of their Qualified Certificates, which lead to revocation). You can equally find ample discussion among revocation delays where the revocation delay was caused by a customer using a certificate in an unrelated purpose or application, and that the constraints of that application or purpose leading to the Subscriber violating their Subscriber Agreement, and the CA violating their CP/CPS in order to accommodate that Subscriber. Looking at delayed revocations is fairly easy here.</div><div><br></div><div>Put differently, each use of a browser/OS-intended TLS certificate outside of that browser/OS-intended use case is, inherently, a security risk, because it affects the ability to comply with the security policies of that browser/OS.  Using the example you cited above, should an organization be required to use an OV/EV certificate, as implied by the proposal, then such an organization would be rate-limited in how quickly they could replace a certificate, thus posing security risk to end users under a myriad of situations. Similarly, the inclusion of such information also creates substantially more risk of misissuance, which can lead to revocation, which then requires reissuance, all of which act to disrupt the ability for such websites to serve TLS-protected connections, also a security risk. If an EV certificate, such an organization would be prohibited from automation, which thus discourages regular certificate rotation, and thus again, increasing security risk.</div><div><br></div><div>Although there are dozens of examples of those principles at play, as reported by CAs, the underlying principles remain and can easily be discussed as such.</div></div></div>