<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 6, 2016 at 4:40 PM, Peter Bowen <span dir="ltr"><<a href="mailto:pzb@amzn.com" target="_blank">pzb@amzn.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div class="h5"><br></div></div><div>This change is to address <a href="https://bugzilla.cabforum.org/show_bug.cgi?id=31" target="_blank">https://bugzilla.cabforum.org/show_bug.cgi?id=31</a>, which is one of the bugs Gerv listed in the prior thread.</div><div><br></div><div>7.1.4.3 is already "Subject Information – Subordinate CA Certificates”, so I was following the same heading format.</div><div><br></div><div>7.1.4.2 says the subject alternative name extension is required and the "extension MUST contain at least one entry. Each entry MUST be either a dNSName containing
the Fully‐Qualified Domain Name or an iPAddress containing the IP address of a server”. Clearly this is incorrect for CA certificates.</div><div><br></div><div><a href="http://7.1.2.1/7.1.2.2" target="_blank">7.1.2.1/7.1.2.2</a> call out the requirement for validation of organizationName for CA certificates. I admit that BR structure here is a little weird — very similar requirements are applied to different types of certificates in 7.1.2 and 7.1.4. It would probably be better to call out validation requirements in one place. However that is starting to feel like its own ballot as it is going to take some careful thought on how to make it work correctly.</div><div><br></div><div>Would you prefer we drop the change to the heading on 7.1.4.2?</div></div></blockquote><div><br></div><div>Right, my main concern with the change was the asymmetry between <a href="http://7.1.2.1/7.1.2.2">7.1.2.1/7.1.2.2</a> and 7.1.4.2.</div><div><br></div><div>I agree, 7.1.4.2 is structured weird right now. There are elements that clearly only apply to subscriber certificates, so in that context, I think your change makes logical sense with that argument, as <a href="http://7.1.2.1/7.1.2.2">7.1.2.1/7.1.2.2</a> cover what MUST appear for CA certificates. The downside is that the change leaves ambiguity as to how data in the name types currently listed in 7.1.4.2, but not in <a href="http://7.1.2.1/7.1.2.2">7.1.2.1/7.1.2.2</a> (meaning they're *optional* for CA certificates) would be validated, because this change would suggest "no validation needed".</div><div><br></div><div>I think you're absolutely correct that the spirit of the change to 7.1.4.2 is meant to be uncontroversial, and the understanding of how it generally means is accepted, I just wouldn't want there to be an argument that, say, that the subject:postalCode can be any arbitrary value (because 7.1.4.2(f) covers exactly how those field contents are validated), simply because 7.1.4.3 allowed the CA to say "We'll put whatever we want in there"</div><div><br></div><div>My concrete suggestions, which I hope would be uncontroversial, but sound like would benefit from a separate cleanup-ballot because it's more work, and I wouldn't want to delay the other cleanups in this ballot, are:</div><div><br></div><div>- Remove the change from 7.1.4.2's heading</div><div>- Let's work up a ballot that:</div><div> - Moves the remarks about "required/optional" for subject names (which is only relevant to subscriber certificates) into a new 7.1.2.3 (g) [thus mirroring 7.1.2.1 [e] and 7.1.2.2 [h])</div><div> - Moves the remarks about "required/optional" for subjectAltNames to a new 7.1.2.3 [h]</div><div> - Ensures that 7.1.4.2.2 consistently describes a policy which is "If this name is present, here's how the contents must be validated" (for any/all certificate types)</div><div> - The two differences here are that 7.1.4.2.2(b) allows for a natural person Subject's name (is this OK or not for CA certificates) and 7.1.4.2.2(g) allows for non-assigned country code (which seems like that should be permitted for CA certificates too, for the same reasons)</div><div><br></div><div>There's also the question as to whether the prohibitions against domain names/IP addresses (from 7.1.4.2) should be merged with 7.1.4.3, but IF these are meant to be distinct (that is, it's OK for a sub-CA to say "organizationalUnitName:Issued by <a href="http://www.example.com">www.example.com</a>" and that's desirable to support via the BRs), then we'd need to deconflict 7.1.4.3 and 7.1.4.2. One way to do that would be to swap(ish) the text from the first pargraphs of each, such that 7.1.4.2 read as "Subject Information - Subscriber Certificates", and acted as a more-specific restriction over the general (all certificate) policies from 7.1.4.2</div><div><br></div><div>Since that's a lot of editorial work, it doesn't feel fair or right to ask you to do, and I also agree that we should deconflict these sections, AND I hope none of what I said above would be controversial, because it (mostly) aligns with practice. I just wouldn't want to accidentally introduce a loophole, which I think the change-as-proposed would.</div><div><br></div></div></div></div>