[cabfpub] Ballot 167 - Baseline Requirements Corrections

Ryan Sleevi sleevi at google.com
Thu Apr 7 00:30:37 MST 2016


Dimitris,

Your changes are actually quite opposite of what I was suggesting, and is
even more problematic to support.

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.

To be explicit: I do not want to see 7.1.4.2 deleted.

On Thu, Apr 7, 2016 at 12:17 AM, Dimitris Zacharopoulos <jimmy at it.auth.gr>
wrote:

>
> 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.
>
> In summary:
>
>    1. 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]
>    2. 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"
>    3. 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]
>    4. 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]
>    5. 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)
>    6. Deleted section 7.1.4.2 and this is where I discovered some
>    problematic references:
>       1. 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)
>       2. 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)
>
> 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.
>
>
> Best regards,
> Dimitris.
>
>
>
> On 7/4/2016 3:24 πμ, Ryan Sleevi wrote:
>
>
>
> On Wed, Apr 6, 2016 at 4:40 PM, Peter Bowen <pzb at amzn.com> wrote:
>
>>
>> This change is to address
>> https://bugzilla.cabforum.org/show_bug.cgi?id=31, which is one of the
>> bugs Gerv listed in the prior thread.
>>
>> 7.1.4.3 is already "Subject Information – Subordinate CA Certificates”,
>> so I was following the same heading format.
>>
>> 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.
>>
>> 7.1.2.1/7.1.2.2 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.
>>
>> Would you prefer we drop the change to the heading on 7.1.4.2?
>>
>
> Right, my main concern with the change was the asymmetry between
> 7.1.2.1/7.1.2.2 and 7.1.4.2.
>
> 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 7.1.2.1/7.1.2.2
> 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 7.1.2.1/7.1.2.2 (meaning they're *optional* for CA
> certificates) would be validated, because this change would suggest "no
> validation needed".
>
> 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"
>
> 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:
>
> - Remove the change from 7.1.4.2's heading
> - Let's work up a ballot that:
>   - 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])
>   - Moves the remarks about "required/optional" for subjectAltNames to a
> new 7.1.2.3 [h]
>   - 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)
>     - 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)
>
> 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 <http://www.example.com>www.example.com"
> 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
>
> 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.
>
>
>
> _______________________________________________
> Public mailing listPublic at cabforum.orghttps://cabforum.org/mailman/listinfo/public
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20160407/8bd915c6/attachment.html 


More information about the Public mailing list