<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Apr 30, 2021 at 2:36 AM Dimitris Zacharopoulos <<a href="mailto:dzacharo@harica.gr">dzacharo@harica.gr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> 
  
 <div><span style="font-family:sans-serif">From a quick review of the profiles, it appears that the OU field is optional, similar to the keyEncipherment KU.</span></div></blockquote><div><br></div><div>As a practical matter, <b>any</b> attempts to curtail, subprofile, or extend the Web PKI profile is problematic.</div><div><br></div><div>Consider the very real scenario we saw during a Certain Large CA's deprecation, where customers were using OV certificates, and from CA A, they contained a specific value. When these customers migrated to CA B, CA B did not use the same O value as CA A, because of the use of a different datasource for validation as well as different CA policies, and this actively broken the Subscriber's products (somewhat badly), due to "Organizational pinning". That's an example of a field that's required here, but the reality is that the contents of that field, same as any of the other DN fields, cannot and must not be profiled by the Applicant/Subscriber. When we consider "optional" fields, we've all seen the questions come in to the questions@ list that are of some form "CA A did X for me, but CA B won't, please tell CA B they're wrong", and so for CAs that, say, choose not to issue the OU field (as some thankfully have), they're either unable to issue such certificates, forced to expend support effort explaining to the customer that it is, in fact,  optional, or inclined to go ahead and change their policies again, because someone asked.</div><div><br></div><div>None of this is sustainable nor reasonable, and as currently proposed, represents a fundamental misunderstanding of the trust framework that the Web PKI operates. For client certificates, this is entirely unreasonable, because there's zero technical reason to use the Web PKI for client certificates. And, for server certificates, the only thing that is reliably consistent among all CAs is the subjectAltName, as all Subject fields are inherently (by CAs' design, and in keeping with the misguided X.500 view), subjective to the CA issuing them.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div> <span style="font-family:sans-serif">I think the design contains several components that need to be analyzed independently to see where the Publicly Trusted Certificates apply, for which components and for which functions.</span></div></blockquote><div><br></div><div>I'm not sure what you're referring to here? The proposal only covers it in two scenarios (a server certificate and a client certificate). Were you seeing other scenarios?</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> <span style="font-family:sans-serif">I will try to review it better next week. The pandemic has caused unprecedented challenges so we should take that into consideration. Not everyone is super familiar with the nuances of the WebPKI and often try to rely on an existing Publicly Trusted framework, due to time constraints, rather than bootstrapping a new one. This is not always a successful path but has worked and still works fairly well in some use cases for client authentication.</span></div></blockquote><div><br></div><div>I think this is misleading, because the issue consistently is the "It works, until it doesn't", and the "until it doesn't" is a piece of technical debt that is catastrophically unprepared for. Our goal is to avoid that scenario in the first place, rather than couch it in warnings that will be ignored. </div></div></div>