<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 17, 2017 at 4:08 PM, Ryan Sleevi <span dir="ltr"><<a href="mailto:sleevi@google.com" target="_blank">sleevi@google.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On Fri, Mar 17, 2017 at 3:01 PM, Dimitris Zacharopoulos <span dir="ltr"><<a href="mailto:jimmy@it.auth.gr" target="_blank">jimmy@it.auth.gr</a>></span> wrote:</span><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">The "spirit" of 9.16.3 is also
    to bring conflicting requirements to the CA/B Forum to consider
    possible revisions accordingly. This is exactly what I am doing,
    without violating the current BRs, but hoping that the CA/B Forum
    will read this as a conflicting requirement which could be resolved
    by adding a simple exception, without creating any risk in current
    practices.<br></div></blockquote></span></div></div></div></blockquote><div><br></div><div>For what it's worth - I agree with this sentiment, and it's worth considering, separate of 9.16.3, whether to _revise_ the BRs to accomodate this case. Such revisions must account for ambiguity. In many ways, the BRs strive to eliminate the rampant ambiguity that existed due to CAs' various practices, as a whole (since no two CAs really have the same CP/CPS), and so we should strive, as much as possible, to unambiguously represent the information that members see as valuable.</div><div><br></div><div>Of course, it might be that identity information in certificates is not valuable, precisely because of ambiguities and conflicts that naturally emerge from CAs. In that case, it might be worthwhile to simply stop trying to represent identity information within certificates, and accept that ambiguity, rather than try to carve it up. However, since the Forum values identity information at present, it makes sense to opt for strictness as much as possible, or to explicitly describe the deviations permitted and assess their risk, as you propose doing and is worth at least discussing :) </div></div></div></div>