[cabfpub] Ballot 167 - Baseline Requirements Corrections

Thu Apr 7 00:17:23 MST 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 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 
> <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.
>
>     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 <http://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 <http://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 <http://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 <http://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 www.example.com 
> <http://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 list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20160407/c3ad8526/attachment-0001.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 : https://cabforum.org/pipermail/public/attachments/20160407/c3ad8526/attachment-0001.doc 