[cabfpub] Ballot 167 - Baseline Requirements Corrections

Dimitris Zacharopoulos jimmy at it.auth.gr
Thu Apr 7 07:17:23 UTC 2016

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,

On 7/4/2016 3:24 πμ, Ryan Sleevi wrote:
> On Wed, Apr 6, 2016 at 4:40 PM, Peter Bowen <pzb at amzn.com 
> <mailto: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 www.example.com 
> <http://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 list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160407/c3ad8526/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CA-Browser Forum BR 1.3.3-corrections.4.doc
Type: application/msword
Size: 600064 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160407/c3ad8526/attachment-0003.doc>

More information about the Public mailing list