<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 15, 2016 at 12:50 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">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.."<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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)</div><div><br></div><div>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.</div></div></div></div>