<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><span style="font-size: 17px;" class="">Hi Ryan,</span><div style="font-size: 17px;" class=""><br class=""></div><div class=""><span style="font-size: 17px;" class="">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;" class=""><div style="font-size: 17px;" class=""><br class=""></div><div style="font-size: 17px;" class="">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 style="font-size: 17px;" class=""><br class=""></div><div style="font-size: 17px;" class="">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;" class=""><br class=""></div><div style="font-size: 17px;" class="">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 style="font-size: 17px;" class=""><br class=""></div><div class=""><span style="font-size: 17px;" class="">- Paul </span><br style="font-size: 17px;" class=""><div class=""><div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""></div></div></div></div>
</div>
<div><br class=""><blockquote type="cite" class=""><div class="">On Sep 9, 2020, at 5:10 PM, Ryan Sleevi <<a href="mailto:sleevi@google.com" class="">sleevi@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div dir="ltr" class=""><br class=""></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 9, 2020 at 3:33 PM Paul Walsh <<a href="mailto:paul@metacert.com" class="">paul@metacert.com</a>> wrote:<br class=""></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;" class=""><div class=""><blockquote type="cite" class=""><div dir="ltr" class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 9, 2020 at 12:08 PM Dimitris Zacharopoulos (HARICA) <<a href="mailto:dzacharo@harica.gr" target="_blank" class="">dzacharo@harica.gr</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class=""><br class="">
It's also unambiguously clear that parts in a TLS Certificates that
are not related to a Domain Name, are not part of the "processing
model used in TLS to validate a domain name". You have been
advocating that, for any Identity Information included in TLS
Certificates, yet there are cases where this information is used.</div></blockquote><div class=""><br class=""></div><div class="">Not by browsers. Which is precisely why it doesn't belong in the TLS certificates used, by browsers, to connect to a server.</div></div></div></blockquote><br class=""></div><div style="font-size:16px" class="">[PW] I’m sorry if I’m asking a specific question that has been answered already. I’m really hoping to learn more about this particular issue. Even if I get a response that’s not to my understanding or liking, I’ll simply digest it, and leave it at that :)</div><div style="font-size:16px" class=""><br class=""></div><div style="font-size:16px" class="">Referring only to fields that browsers don’t use - are there any fields that have been empty, or populated incorrectly in the past, that resulted in a security problem for one or more organization? </div></div></blockquote><div class=""><br class=""></div><div class="">Yes.</div><div class=""> </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;" class=""><div style="font-size:16px" class="">If yes, is it possible to get a link to a news website or company blog where the security incident was announced? I’d also love to learn how those fields caused a problem if they’re not used by browsers.</div></div></blockquote><div class=""><br class=""></div><div class="">Given that members of the Forum take umbrage at highlighting failures of CAs to uphold the Baseline Requirements, I can only encourage you to carefully read through <a href="https://wiki.mozilla.org/CA/Incident_Dashboard" class="">https://wiki.mozilla.org/CA/Incident_Dashboard</a> and see the numerous incidents that have been caused.</div><div class=""><br class=""></div><div class="">However, you also need to carefully re-read my previous message; this additional data limits automation, increases secondary dependencies that harm improvements (and the list is 100% of every contentious deprecation discussed in this Forum, from SHA-1 to lifetimes), and creates more challenges for organizations. It creates couplings that have no technical reason to exist other than convenience, and given that such convenience actively harms browser users by limiting the ability to effectively improve TLS within our products, that's a real problem.</div><div class=""> </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;" class=""><div style="font-size:16px" class="">If a browser doesn’t need specific fields, can’t they just ignore them and allow other certificate consumers to use them? </div></div></blockquote><div class=""><br class=""></div><div class="">No.</div><div class=""><br class=""></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;" class=""><div style="font-size:16px" class="">For example, a mobile carrier might want to consume certificates that contain one or two specific fields that browser vendors don’t use/trust, while ignoring the encryption aspect of the cert. </div></div></blockquote><div class=""><br class=""></div><div class="">I'm not going to engage in hypotheticals here, because that's not productive here for the OU discussion, other than the answer is what I previously stated: use a different certificate.</div><div class=""><br class=""></div><div class="">There's a fundamental problem with your framing: "They want it, ergo it must be good / we should allow it." There are many things I want, but it would be harmful to myself, to others, and society at large if I just got everything I wanted. It's the same with certificates. They're just a container format. We would rightfully laugh at someone who tried to make a Single API To Do Everything, where everything imaginable under the sun is an optional parameter that can be sent. Why should we accept the same from certificates?</div><div class=""><br class=""></div><div class="">If there are concrete use cases or needs for OU, let's discuss them, so we can objectively evaluate whether the risk to agility, to security, and to auditability are justified. But let's not engage in hypothetical "What ifs".</div></div></div>
</div></blockquote></div><br class=""></div></div></body></html>