<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 13, 2017 at 7:23 AM, Gervase Markham via Public <span dir="ltr"><<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 13/01/17 14:55, Doug Beattie wrote:<br>
> I'd suggest we include exactly what is required in the ballot and if<br>
> the RFC changes then we have a new ballot to specify the changes and<br>
> effective dates.<br>
<br>
</span>Well, it's not the RFC that would change - if it was, that would be<br>
simpler :-) It's the extension registries.<br>
<br>
Text proposals welcome.<br></blockquote><div><br></div><div>CAs MUST support the issue, issuewild, and iodef property tags. Additional property tags MAY be supported, but MUST NOT conflict with or supersede the mandatory property tags set out in this document. CAs MUST respect the critical flag and reject any unrecognized properties with this set.</div><div><br></div><div>Is just one stab. I think Doug's on the money that it does make sense to highlight what's mandatory to implement, what's optional. If you particularly aren't sure how to word this, I think RFC 5280 provides enough examples that may be (hopefully) accessible to CAs and auditors, considering how extensions like basicConstraints or nameConstraints are specified.</div><div><br></div><div>The above wording is mostly to make sure we don't have CA inventing something that says "I get to ignore everything" and then claiming compliance - that's why it tries to lay out the 'no sneaky tricks' in the MUST NOT.</div><div><br></div></div><br></div></div>