[cabfcert_policy] Fwd: Re: [cabfpub] Ballot 167 - Baseline Requirements Corrections

Dean Coclin Dean_Coclin at symantec.com
Thu Apr 7 06:21:11 MST 2016 

The policy WG call is in about 30 mins, 10am EST, which I believe is 2pm UTC.


Dean

 

From: policyreview-bounces at cabforum.org [mailto:policyreview-bounces at cabforum.org] On Behalf Of Dimitris Zacharopoulos
Sent: Thursday, April 07, 2016 3:29 AM
To: policyreview at cabforum.org
Subject: [cabfcert_policy] Fwd: Re: [cabfpub] Ballot 167 - Baseline Requirements Corrections

 


In case you want to discuss this in today's call. Can someone please confirm the time of the call in UTC?


Best regards,
Dimitris.

-------- Forwarded Message -------- 


Subject: 

Re: [cabfpub] Ballot 167 - Baseline Requirements Corrections


Date: 

Thu, 7 Apr 2016 10:17:23 +0300


From: 

Dimitris Zacharopoulos  <mailto:jimmy at it.auth.gr> <jimmy at it.auth.gr>


To: 

Ryan Sleevi  <mailto:sleevi at google.com> <sleevi at google.com>, Peter Bowen  <mailto:pzb at amzn.com> <pzb at amzn.com>


CC: 

CABFPub  <mailto:public at cabforum.org> <public at cabforum.org>

 


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 <mailto:Public at cabforum.org> 
https://cabforum.org/mailman/listinfo/public

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/policyreview/attachments/20160407/b5b7fdcc/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5747 bytes
Desc: not available
Url : https://cabforum.org/pipermail/policyreview/attachments/20160407/b5b7fdcc/attachment-0001.bin

More information about the Policyreview mailing list