[cabfcert_policy] EV SSL Certificate Guidelines V1.5.8 doc and pdf Re: [cabfcert_ policy] Fwd: Re: [cabfpub] Ballot 167 -Baseline Requirements Cor rections

realsky(CHT) realsky at cht.com.tw
Thu Apr 7 06:38:55 MST 2016 

Dear Ben,

      I have not yet seen Version 1.5.8 word and pdf after Ballot 163 in wiki or cabforum.org. I think you are busy recently. I transer the word and pdf version as attached file. 

   Li-Chun CHEN
   Chunghwa Telecom


-----Original message-----
From:Dean Coclin<Dean_Coclin at symantec.com>
To:Dimitris Zacharopoulos<jimmy at it.auth.gr>,policyreview at cabforum.org<policyreview at cabforum.org>
Date: Thu, 07 Apr 2016 21:21:11
Subject: Re: [cabfcert_policy] Fwd: Re: [cabfpub] Ballot 167 -Baseline Requirements Corrections
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 <jimmy at it.auth.gr>

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

CC: 
CABFPub <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:
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]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"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]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]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)Deleted section 7.1.4.2 and this is where I discovered some problematic references: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)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 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
 

 

_______________________________________________
Policyreview mailing list
Policyreview at cabforum.org
https://cabforum.org/mailman/listinfo/policyreview




本信件可能包含中華電信股份有限公司機密資訊,非指定之收件者,請勿蒐集、處理或利用本信件內容,並請銷毀此信件. 如為指定收件者,應確實保護郵件中本公司之營業機密及個人資料,不得任意傳佈或揭露,並應自行確認本郵件之附檔與超連結之安全性,以共同善盡資訊安全與個資保護責任. 
Please be advised that this email message (including any attachments) contains confidential information and may be legally privileged. If you are not the intended recipient, please destroy this message and all attachments from your system and do not further collect, process, or use them. Chunghwa Telecom and all its subsidiaries and associated companies shall not be liable for the improper or incomplete transmission of the information contained in this email nor for any delay in its receipt or damage to your system. If you are the intended recipient, please protect the confidential and/or personal information contained in this email with due care. Any unauthorized use, disclosure or distribution of this message in whole or in part is strictly prohibited. Also, please self-inspect attachments and hyperlinks contained in this email to ensure the information security and to protect personal information.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/policyreview/attachments/20160407/ac4d2994/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: EV_V1_5_8-redlined.doc
Type: application/msword
Size: 358400 bytes
Desc: not available
Url : https://cabforum.org/pipermail/policyreview/attachments/20160407/ac4d2994/attachment-0002.doc 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: EV_V1_5_8.doc
Type: application/msword
Size: 357376 bytes
Desc: not available
Url : https://cabforum.org/pipermail/policyreview/attachments/20160407/ac4d2994/attachment-0003.doc 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: EV_V1_5_8.pdf
Type: application/pdf
Size: 1393819 bytes
Desc: not available
Url : https://cabforum.org/pipermail/policyreview/attachments/20160407/ac4d2994/attachment-0002.pdf 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: EV_V1_5_8-redlined.pdf
Type: application/pdf
Size: 1394628 bytes
Desc: not available
Url : https://cabforum.org/pipermail/policyreview/attachments/20160407/ac4d2994/attachment-0003.pdf

More information about the Policyreview mailing list