<div dir="ltr">Dimitris,<div><br></div><div>Your changes are actually quite opposite of what I was suggesting, and is even more problematic to support.</div><div><br></div><div>I think the best step would be to simply drop that item from this ballot, and then I can work with Peter to see if we can propose a suitable text that provides the same degree of clarification, while addresses the concerns I raised.</div><div><br></div><div>To be explicit: I do not want to see 7.1.4.2 deleted.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 7, 2016 at 12:17 AM, Dimitris Zacharopoulos <span dir="ltr"><<a href="mailto:jimmy@it.auth.gr" target="_blank">jimmy@it.auth.gr</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div><br>
I believe Ryan's suggestions are uncontroversial and could be
included in this cleanup ballot. I made an attempt to incorporate
these suggestions on top of Peter's red-lined latest version.<br>
<br>
In summary:<br>
<ol>
<li>Moved the text of 7.1.4.3 that refers to subject information
of subordinate CAs to 7.1.2.2 (h) [made sure that there are no
references to 7.1.4.3 in the document]<br>
</li>
<li>Corrected the language for countryName in the Root CA
Certificate (7.1.2.1 e) and Subordinate CA Certificate
(7.1.2.2 h) sections to match the language in the Subscriber
Certificate section. I basically, added the following sentence
"If a Country is not represented by an official ISO 3166-1
country code, the CA MAY specify the ISO 3166-1 user-assigned
code of XX indicating that an official ISO 3166-1 alpha-2 code
has not been assigned"</li>
<li>Moved the subject information for subscriber certificates
from 7.1.4.2.2 to 7.1.2.3 (g), following the structure of
sections 7.1.2.1 and 7.1.2.2 [corrected references in section
7.1.6.1 to match this move]</li>
<li>Moved the Subject Alternative Name Extension from 7.1.4.2.1
to 7.1.2.3 (h) [corrected references in the revised 7.1.2.3
(g) and in section 1.2.2]</li>
<li>Moved the text of the first paragraph of 7.1.4.2 that refers
to subject information of subscriber certificates to the
revised 7.1.2.3 (g)</li>
<li>Deleted section 7.1.4.2 and this is where I discovered some
problematic references:</li>
<ol>
<li>reference to a non-existing section "7.1.4.2.5". This
reference appears in 7.1.5 which should be 7.1.2.5
(corrected) and in 7.1.4.2.2 (e) which is also corrected to
the revised 7.1.2.3 g (vii)<br>
</li>
<li>reference to a non-existing section "7.1.2.4.2.5". This
reference appears in 7.1.4.2.2 (d) which refers to the same
information so this is also corrected to the revised 7.1.2.3
g (vii)<br>
</li>
</ol>
</ol>
I know that these changes seem a lot but consistency and proper
references in a very important element when it comes to policy
documents and guidelines. The sooner these issues are corrected,
the better for everyone. We also have a policy WG meeting today
and more people could review these changes.<br>
<br>
<br>
Best regards,<br>
Dimitris.<div><div class="h5"><br>
<br>
<br>
On 7/4/2016 3:24 πμ, Ryan Sleevi wrote:<br>
</div></div></div>
<blockquote type="cite"><div><div class="h5">
<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><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" target="_blank">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" target="_blank">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" target="_blank">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" target="_blank"></a><a href="http://www.example.com" target="_blank">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>
<br>
<fieldset></fieldset>
<br>
</div></div><pre>_______________________________________________
Public mailing list
<a href="mailto:Public@cabforum.org" target="_blank">Public@cabforum.org</a>
<a href="https://cabforum.org/mailman/listinfo/public" target="_blank">https://cabforum.org/mailman/listinfo/public</a>
</pre>
</blockquote>
<br>
</div>
</blockquote></div><br></div>