<div dir="ltr">So it would seem you are arguing that a CA should be permissible to encode these fields in BER, because that is the only possible way to support the interpretation that you're concerned about being material and non-trivial, since this would prohibit such an interpretation.<div><br></div><div>Though I strongly disagree, it's helpful to understand your perspective, and would hope we don't have to see a 2 week delay for a pre-existing concern of a hypothetical problem for which auditors can be informed on the basis of this discussion here, but we'll have to see how the vote turns out.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 15, 2016 at 1:14 PM, Jeremy Rowley <span dir="ltr"><<a href="mailto:jeremy.rowley@digicert.com" target="_blank">jeremy.rowley@digicert.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">*Potentially non-trivial. Whether it’s material probably depends on the CA and their interpretation and auditor. <u></u><u></u></span></p><p class="MsoNormal"><a name="m_-3250711942581633971__MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></a></p><div><div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0in 0in 0in"><p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> <a href="mailto:public-bounces@cabforum.org" target="_blank">public-bounces@cabforum.org</a> [mailto:<a href="mailto:public-bounces@cabforum.org" target="_blank">public-bounces@cabforum.org</a>] <b>On Behalf Of </b>Jeremy Rowley<br><b>Sent:</b> Friday, April 15, 2016 2:12 PM<br><b>To:</b> Ryan Sleevi<span class=""><br><b>Cc:</b> CABFPub<br><b>Subject:</b> Re: [cabfpub] Ballot 167 - Baseline Requirements Corrections<u></u><u></u></span></span></p></div></div><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">On Fri, Apr 15, 2016 at 12:50 PM, Jeremy Rowley <<a href="mailto:jeremy.rowley@digicert.com" target="_blank">jeremy.rowley@digicert.com</a>> wrote:<u></u><u></u></p><div><div class="h5"><blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt"><p class="MsoNormal">Alright, but if I am planning to introduce the ballot that clearly conflicts with 5280, won't this be a problem? Plus, name constraints  are an obvious conflict as they are required to be marked critical in 5280 but not required to be marked critical in the BRs. This was done to support Apple (similar to the proposal I am making for IP Addresses).<br><br>This language is a change as it says "All other fields and extensions MUST be set in accordance with 5280".  The language you proposed removes the "All other.."<u></u><u></u></p></blockquote><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Surely you don't mean to suggest that it would be permissible, based on that language, to encoder in BER the Certificate Policies (v.1.3.4, 7.1.2.2, item a), right? So the "all other" surely does not exempt the current, enumerated fields from needing to comply with 5280, or else we'd have a great mess on our hands.<u></u><u></u></p></div><div><p class="MsoNormal"><span style="color:#1f497d">[JR]  I’m suggesting this language change is a material change and non-trivial. <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p></div><div><p class="MsoNormal">Similarly for basicConstraints - if we take the approach you're implying, it would suggest that a conforming BR certificate does not need to conform to RFC 5280, only to the obligations set forth in the BRs (e.g. v.1.3.4, 7.1.2.3, item D), which don't specify the encoding rules (e.g. DER vs BER)<u></u><u></u></p></div><div><p class="MsoNormal"><span style="color:#1f497d">[JR]  See above <u></u><u></u></span></p><p class="MsoNormal"><u></u> <u></u></p></div><p class="MsoNormal">I think your concern with respect to non-criticality is already addressed, and unaffected by, this ballot, in that v1.3.4, 7.1.2.2, item f provides the scope-limited exception to 5280, very explicitly, rather than interpreting it as if there's a blanket exception to 5280 for all enumerated fields, which you seem to be arguing for.<u></u><u></u></p><p class="MsoNormal"><span style="color:#1f497d">[JR] No. I’m saying the old language needs to be retained as the impact hasn’t really been evaluated yet. <u></u><u></u></span></p><p class="MsoNormal"><span style="color:#1f497d"><u></u> <u></u></span></p><div><div><div><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p></div></div></div></div></div></div></div></div></blockquote></div><br></div>