[cabfpub] Ballot 167 - Baseline Requirements Corrections

Ryan Sleevi sleevi at google.com
Thu Apr 7 07:30:37 UTC 2016


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 deleted.

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

> 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 that refers to subject information of
>    subordinate CAs to (h) [made sure that there are no references to
> in the document]
>    2. Corrected the language for countryName in the Root CA Certificate
>    ( e) and Subordinate CA Certificate ( 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
> to (g), following the structure of sections and
> [corrected references in section to match this move]
>    4. Moved the Subject Alternative Name Extension from to
> (h) [corrected references in the revised (g) and in section
>    1.2.2]
>    5. Moved the text of the first paragraph of that refers to
>    subject information of subscriber certificates to the revised (g)
>    6. Deleted section and this is where I discovered some
>    problematic references:
>       1. reference to a non-existing section "". This reference
>       appears in 7.1.5 which should be (corrected) and  in (e)
>       which is also corrected to the revised g (vii)
>       2. reference to a non-existing section "". This
>       reference appears in (d) which refers to the same information so
>       this is also corrected to the revised 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.
>> is already "Subject Information – Subordinate CA Certificates”,
>> so I was following the same heading format.
>> 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.
>> 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
> Right, my main concern with the change was the asymmetry between
> and
> I agree, 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
> 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
>, but not in (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
> 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
> covers exactly how those field contents are validated), simply because
> 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'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 (g) [thus
> mirroring [e] and [h])
>   - Moves the remarks about "required/optional" for subjectAltNames to a
> new [h]
>   - Ensures that 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 allows for a natural
> person Subject's name (is this OK or not for CA certificates) and
> 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 should be merged with, 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
> and One way to do that would be to swap(ish) the text from
> the first pargraphs of each, such that read as "Subject Information
> - Subscriber Certificates", and acted as a more-specific restriction over
> the general (all certificate) policies from
> 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: <http://lists.cabforum.org/pipermail/public/attachments/20160407/8bd915c6/attachment-0003.html>

More information about the Public mailing list