<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></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 1:34 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 12:35 PM, Peter Bowen <span dir="ltr" class=""><<a href="mailto:pzb@amzn.com" target="_blank" class="">pzb@amzn.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">First, the modules in the current X.520 SelectedAttributes module all use UnboundedDirectoryString, while we expect upper bounds on some strings. </blockquote><div class=""><br class=""></div><div class="">Fair enough, although RFC 5280 defines these upper bounds, and 5280 is normative. I think the subtlety of 5280 vs X.520 may be lost for some members, so I think it's reasonable here, although RFC 5912 may be suitable for incorporation.</div></div></div></div></div></blockquote><div><br class=""></div><div>I’ll compare RFC 5912 and the ITU-T Ed. 8 ASN.1 and make sure that I’m not conflicting incompatibly.</div><div><br class=""></div><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><br class=""></div>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.<br class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">Thanks for pointing out both of these issues.</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"><span class="gmail-">
> I found a couple of errors in the tor appendix.  I think I got the intent right, but can someone please confirm?<br class="">
><br class="">
> Can you clarify the errors you see? A quick visual scan only shows the differences being the introduction of the EXTENSION .. IDENTIFIED BY syntax, is that correct?<br class="">
<br class="">
</span><span class="gmail-">cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 }<br class="">
</span><span class="gmail-">cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 }<br class="">
<br class="">
</span>Both of these use a “cabf” definition, but this is not defined anywhere.  I was guessing it is<br class="">
<span class="gmail-">cabf ID ::= { joint‐iso‐itu‐t(2) international‐organizations(<wbr class="">23) ca‐browser‐forum(140) }<br class="">
<br class="">
</span>However it could mean something under 2.23.140 (eg. 2.23.140.3 or so).<br class=""></blockquote><div class=""><br class=""></div><div class="">Ah, good point! I believe the 'intent' was 140.1 (consistent with the .onion extension). Jeremy, given that DigiCert is issuing these certificates, can you clarify what you've done in production? </div><div class=""><br class=""></div><div class="">Note, it was a 'bug' that we put the .onion extension on the .1 arc, since .1 is for policies at <a href="https://cabforum.org/object-registry/" class="">https://cabforum.org/object-registry/</a></div></div></div></div>
</div></blockquote><br class=""></div><div>Given that it seems that these were never used (see other thread) should we fix this?</div><div><br class=""></div><div>Thanks,</div><div>Peter</div><br class=""></body></html>