<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 27, 2017, at 4:29 PM, Ryan Sleevi <<a href="mailto:sleevi@google.com" class="">sleevi@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div dir="ltr" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Mon, Feb 27, 2017 at 4:22 PM, Peter Bowen <span dir="ltr" class=""><<a href="mailto:pzb@amzn.com" target="_blank" class="">pzb@amzn.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><span class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><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"> Second, the BRs and EVGs have redefined the content of the attributes vis-a-vis X.520, so I think it makes sense to have our own version.</blockquote><div class=""><br class=""></div><div class="">I think this is a much more compelling argument, since we've certainly seen some confusion from members with respect to the normative constraints of what this content must cover. Despite the Baseline Requirements defining rules for the validation/verification of this information, the question of what this contains (e.g. "country") is surprisingly one that's tripped up more than a few member CAs.</div></div></div></div></blockquote><div class=""><br class=""></div></span>Given this, would it make sense to add comments about what content is allowed for certain attributes?  Right now the syntax is defined but not the permitted content.</div></div></blockquote><div class=""><br class=""></div><div class="">I'm a little nervous about duplicating content in a way that could be seen as normative. I think one approach to that would be to set the ASN.1 module (either as an appendix or a dedicated Guideline), refer to the appropriate guideline as to the content, and within the Guideline, describe what is permitted.</div><div class=""><br class=""></div><div class="">How do you feel about that approach? I think you're right that we've had enough subtle slight divergence between the X.500/X.520 idealized DIT and the real-world of the WebPKI, so this seems much less a case of actively 'forking' a spec so much as recognize it's been 'forked' since 2012 (at a minimum, although in practice, much earlier)</div></div></div></div></div></blockquote><div><br class=""></div><div>I think pointers to the guideline are perfect.  There have been discussions about making the guideline clearer on content.  Maybe we can have a draft for review in RTP and target a vote shortly after.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class="">Given that it seems that these were never used (see other thread) should we fix this?</div></div></blockquote><div class=""><br class=""></div><div class="">Yeah, given that, let's fix it and do it right. It does sound like the impact of changing OIDs is so minimal that the ecosystem can handle the divergence, and that lets us get our OID arc clean.</div><div class=""><br class=""></div><div class="">So it sounds like two, possibly three ballots:</div><div class="">- X.520 vs RFC5280 vs RFC5912 , aligning both the technical content and the descriptive content and adopting it</div><div class="">  - Option 1 - By updating the EVGs & BRs with this</div><div class="">  - Option 2 - By adopting as a separate document</div><div class="">- .onion & Tor cleanup of OID arcs and ASN.1 module (affects EVGs) </div><div class=""><br class=""></div><div class="">Does that sound right?</div></div></div></div>
</div></blockquote></div><br class=""><div class="">I like Option 1.  I want to make sure that anything we do matches RFC 5280 syntax and ideally X.520 syntax, so anyone using the grammars defined in either can process the certificates.</div></body></html>