From kirk_hall at trendmicro.com Sun Feb 1 13:05:21 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Sun, 1 Feb 2015 20:05:21 +0000 Subject: [cabfpub] Ballot 145 - Formalization of Validation Working Group In-Reply-To: <54CA80B3.3050503@comodo.com> References: <54CA80B3.3050503@comodo.com> Message-ID: Trend Micro will also endorse. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Rich Smith Sent: Thursday, January 29, 2015 10:49 AM To: public at cabforum.org; jeremy.rowley at digicert.com Subject: Re: [cabfpub] Ballot 145 - Formalization of Validation Working Group I'll endorse. Rich On 1/29/2015 11:56 AM, Jeremy Rowley wrote: This is the ballot to formalize the validation working group and modify its scope to include validation and the inclusion of information in certificates. I'm looking for two endorsers Ballot 145 - Formalization of Validation Working Group Reason In order to address validation issues and inconsistencies in both the SSL Baseline Requirements and the EV Guidelines, the CAB Forum has held an informal working group previously referred to as the Extended Validation Working Group now known as the Validation Working Group, would like to modify its scope to include validation in the Baseline Requirements as well as the EV Guidelines. - Motion begins - The CA-Browser Forum formally establishes the Validation Working Group as an official working group of the CAB Forum, replacing the previous informal EV working group. The scope of this working group is to address issues arising under adopted CAB Forum standards related to the validation of certificate information and the inclusion of information in certificates. Scope: The Validation Working Group will consider all matters relating to the validation and inclusion of information in certificates under adopted CAB Forum guidelines. Deliverables: The Working Group shall produce one or more documents offering options to the Forum for validation within the scope defined above. -- Motion Ends -- The review period for this ballot shall commence at 2200 UTC on , and will close at 2200 UTC on . Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on . Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. _______________________________________________ Public mailing list Public at cabforum.org https://cabforum.org/mailman/listinfo/public 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
-------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150201/02110296/attachment.html From jeremy.rowley at digicert.com Wed Feb 4 13:51:56 2015 From: jeremy.rowley at digicert.com (Jeremy Rowley) Date: Wed, 4 Feb 2015 20:51:56 +0000 Subject: [cabfpub] Ballot .onion ballot Message-ID: The following is the finalized onion ballot. I made two changes since we spoke in the last meeting. The first is based on Tom Ritter's feedback. He mentioned that there might be several onion names for a single entity so adding an identifier in the data structure that links the onionURI to the nonce would be helpful. I've included it below. I also realized that without a change to the BRs, CAs could still issue .onion names under the BRs as an internal name OR under the EV Guidelines. Since the goal is to lock down .onion issuance, I added a restriction that all .onion names would need to be revoked by May 1 if the ballot passes. I assume everyone is still willing to endorse? --- Applicants want a CA-signed .onion address for several reasons, including: - Powerful web platform features are restricted to secure origins, which are currently not available to onion names (in part, because of the lack of IANA registration). Permitting EV certs for onion names will help provide a secure origin for the service, moving onion towards use of powerful web platform features. - Currently, access to .onion names over https from a standard browser results in the standard existing 'Invalid Certificate' warning. Training users to click through security warnings lowers the value of these warnings and will cause users to miss important security information. Removing these warnings for the user, through use of a digital certificate, will help users recognize and avoid real MITM attacks. - The public needs attribution of ownership of the .onion address to differentiate onion services, including potential phishing services. Because onion names are not easily recognizable strings, providing the public with additional information about the operator has significant security improvements, especially in regions where use of the incorrect name could have lethal consequences. The following motion has been proposed by Jeremy Rowley of DigiCert and endorsed by Ryan Sleevi of Google and Wayne Thayer of GoDaddy. --------------------- Motion Starts --------------------- Amend Section 9.2.1 of the Baseline Requirements v. 1.2.3 as follows: 9.2.1 Subject Alternative Name Extension Certificate Field: extensions:subjectAltName Required/Optional: Required Contents: This 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. The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate. Wildcard FQDNs are permitted. As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name, the CA SHALL notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016. Also as of the Effective Date, the CA SHALL NOT issue a certificate with an Expiry Date later than 1 November 2015 with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name. Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Name. Effective May 1, 2015, each CA SHALL revoke all unexpired Certificates with an Internal Name using onion as the left-most label in an entry in the subjectAltName Extension or commonName field unless such Certificate was issued in accordance with Appendix F of the EV Guidelines. Amend the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2 as follows: Amend Section 9.2.2 and 11.7.1 as follows: 9.2.2. Subject Alternative Name Extension Certificate field: subjectAltName:dNSName Required/Optional: Required Contents: This extension MUST contain one or more host Domain Name(s) owned or controlled by the Subject and to be associated with the Subject's server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). Wildcard certificates are not allowed for EV Certificates except as permitted under Appendix F. 11.7 Verification of Applicant's Domain Name 11.7.1. Verification Requirements (1) For each Fully-Qualified Domain Name listed in a Certificate, other than a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant (or the Applicant's Parent Company, Subsidiary Company, or Affiliate, collectively referred to as "Applicant" for the purposes of this section) either is the Domain Name Registrant or has control over the FQDN using a procedure specified in Section 11.1.1 of the Baseline Requirements, except that a CA MAY NOT verify a domain using the procedure described 11.1.1(7). For a Certificate issued to a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant's control over the .onion Domain Name in accordance with Appendix F. (2) Mixed Character Set Domain Names: EV Certificates MAY include Domain Names containing mixed character sets only in compliance with the rules set forth by the domain registrar. The CA MUST visually compare any Domain Names with mixed character sets with known high risk domains. If a similarity is found, then the EV Certificate Request MUST be flagged as High Risk. The CA must perform reasonably appropriate additional authentication and verification to be certain beyond reasonable doubt that the Applicant and the target in question are the same organization. Add a new Appendix F: Appendix F - Issuance of Certificates for .onion Domain Names A CA may issue an EV Certificate with .onion in the right-most label of the Domain Name provided that issuance complies with the requirements set forth in this Appendix: 1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) The CAB Forum has created an extension of the TBSCertificate for use in conveying hashes of keys related to .onion addresses. The Tor Service Descriptor Hash extension has the following format: cabf-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 } TorServiceDescriptorSyntax ::= SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash TorServiceDescriptorHash:: = SEQUENCE { onionURI UTF8String algorithm AlgorithmIdentifier subjectPublicKeyHash BIT STRING } Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 6234) performed over the DER-encoding of an ASN.1 SubjectPublicKey of the .onion service and SubjectPublicKeyHash is the hash output. 2. The CA MUST verify the Applicant's control over the .onion Domain Name using one of the following: a. The CA MAY verify the Applicant's control over the .onion service by posting a specific value at a well-known URL under RFC5785. b. The CA MAY verify the Applicant's control over the .onion service by having the Applicant provide a Certificate Request signed using the .onion public key if the Attributes section of the certificationRequestInfo contains: (i) A caSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy, 2) is generated by the CA, and 3) delivered to the Applicant through a Verified Method of Communication and (ii) An applicantSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy and 2) is generated by the Applicant. The signing nonce attributes have the following format: caSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-caSigningNonce } } cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } applicantSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-applicantSigningNonce } } cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 } 4. Each Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name MUST conform to the requirements of these Guidelines, including the content requirements in Section 9 and Appendix B of the Baseline Requirements, except that the CA MAY include a wildcard character in the Subject Alternative Name Extension and Subject Common Name Field as the leftmost character in the .onion Domain Name provided inclusion of the wildcard character complies with Section 11.1.3 of the Baseline Requirements. 5. CAs MUST NOT issue a Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name with a validity period longer than 15 months. Despite Section 9.2.1 of the Baseline Requirements deprecating the use of Internal Names, a CA MAY issue a Certificate containing an .onion name with an expiration date later than 1 November 2015 after (and only if) .onion is officially recognized by the IESG as a reserved TLD. 6. On or before February 15, 2015, each CA MUST revoke all Certificates issued with the Subject Alternative Name extension or Common Name field that includes a Domain Name where .onion is in the right-most label of the Domain Name unless the Certificate was issued in compliance with this Appendix F. ---- Motion Ends ----- The review period for this ballot shall commence at 2200 UTC on Thursday, 4 February 2015, and will close at 2200 UTC on Thursday, 11 February 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on Monday, 18 February 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150204/b705f72e/attachment.html From jeremy.rowley at digicert.com Wed Feb 4 14:05:19 2015 From: jeremy.rowley at digicert.com (Jeremy Rowley) Date: Wed, 4 Feb 2015 21:05:19 +0000 Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group Message-ID: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> Ballot 143 - Formalization of validation working group ---- Reason ---- In order to address validation issues and inconsistencies in both the SSL Baseline Requirements and the EV Guidelines, the CAB Forum has held an informal working group previously referred to as the Extended Validation Working Group now known as the Validation Working Group, would like to modify its scope to include validation in the Baseline Requirements as well as the EV Guidelines. Jeremy Rowley of DigiCert made the following motion, which was endorsed by Rich Smith of Comodo and Kirk Hall of TrendMicro ---- Motion begins ---- The CA-Browser Forum formally establishes the Validation Working Group as an official working group of the CAB Forum, replacing the previous informal EV working group. The scope of this working group is to address issues arising under adopted CAB Forum standards related to the validation of certificate information and the inclusion of information in certificates. Scope: The Validation Working Group will consider all matters relating to the validation and inclusion of information in certificates under adopted CAB Forum guidelines. Deliverables: The Working Group shall produce one or more documents offering options to the Forum for validation within the scope defined above. ---- Motion Ends ---- The review period for this ballot shall commence at 2200 UTC on 5 Feb 2015, and will close at 2200 UTC on 11 Feb 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on 18 Feb 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150204/e2955790/attachment-0001.html From Dean_Coclin at symantec.com Wed Feb 4 14:16:11 2015 From: Dean_Coclin at symantec.com (Dean Coclin) Date: Wed, 4 Feb 2015 13:16:11 -0800 Subject: [cabfpub] Draft Agenda for CA/B Forum call February 5, 2015 Message-ID: <14D026C7F297AD44AC82578DD818CDD038EEF0B789@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> We have an open 10 min slot below if anyone has a topic they'd like to discuss. Antitrust Statement: As you know, this meeting includes companies that compete against one another. This meeting is intended to discuss technical standards related to the provision of existing and new types of digital certificates without restricting competition in developing and marketing such certificates. This meeting is not intended to share competitively-sensitive information among competitors, and therefore all participants agree not to discuss or exchange information related to: (a) Pricing policies, pricing formulas, prices or other terms of sale; (b) Costs, cost structures, profit margins, (c) Pending or planned service offerings, (d) Customers, business, or marketing plans; or (e) The allocation of customers, territories, or products in any way. Note: Please announce yourself when you dial in. This helps in documenting attendance when recording is played back later. Here is the proposed agenda: Time Start(UTC) Stop Slot Description Notes / Presenters (Thur) 5 Feb 2015 0:01 16:00 16:01 1 Read Antitrust Statement Dean 0:02 16:01 16:03 2 Roll Call Dean 0:01 16:03 16:04 3 Review Agenda Dean 0:01 16:04 16:05 4 Approve Minutes of 22 Jan 2015 Distributed by Kirk on Jan 23rd 0:20 16:05 16:25 5 Ballot Updates: EV Working Group change, .Onion Ballot, Other EV Ballots? Jeremy, Kirk 0:05 16:25 16:30 6 Vivaldi 0:07 16:30 16:37 7 Any more discussion on IPv6? Ryan 0:10 16:37 16:47 8 Open Slot 0:05 16:45 16:50 9 EV Working Group Status Update Jeremy 0:02 16:50 16:52 10 Code Signing Working Group Status Update Dean/Jeremy -Public draft 0:02 16:52 16:54 11 Policy Review Working Group Status Update Ben/Dean-Boston meeting Jan 27th postponed due to blizzard 0:02 16:54 16:56 12 *New* Information Sharing Working Group Update Ben 0:03 16:56 16:59 13 Any Other Business - Cupertino Meeting-March 10-12: 26 attendees signed up so far 0:00 17:00 17:00 14 Next phone call - February 19, 2015 0:00 17:00 17:00 15 Adjourn -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150204/1f5ee5a2/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6130 bytes Desc: not available Url : https://cabforum.org/pipermail/public/attachments/20150204/1f5ee5a2/attachment-0001.bin From jeremy.rowley at digicert.com Wed Feb 4 14:19:45 2015 From: jeremy.rowley at digicert.com (Jeremy Rowley) Date: Wed, 4 Feb 2015 21:19:45 +0000 Subject: [cabfpub] Ballot .onion ballot In-Reply-To: References: Message-ID: <445290cba41444119f8c958eebbcc76a@EX2.corp.digicert.com> One correction. It should have read "right-most" not "left-most". (Fixed below) The following is the finalized onion ballot. I made two changes since we spoke in the last meeting. The first is based on Tom Ritter's feedback. He mentioned that there might be several onion names for a single entity so adding an identifier in the data structure that links the onionURI to the nonce would be helpful. I've included it below. I also realized that without a change to the BRs, CAs could still issue .onion names under the BRs as an internal name OR under the EV Guidelines. Since the goal is to lock down .onion issuance, I added a restriction that all .onion names would need to be revoked by May 1 if the ballot passes. I assume everyone is still willing to endorse? --- Applicants want a CA-signed .onion address for several reasons, including: - Powerful web platform features are restricted to secure origins, which are currently not available to onion names (in part, because of the lack of IANA registration). Permitting EV certs for onion names will help provide a secure origin for the service, moving onion towards use of powerful web platform features. - Currently, access to .onion names over https from a standard browser results in the standard existing 'Invalid Certificate' warning. Training users to click through security warnings lowers the value of these warnings and will cause users to miss important security information. Removing these warnings for the user, through use of a digital certificate, will help users recognize and avoid real MITM attacks. - The public needs attribution of ownership of the .onion address to differentiate onion services, including potential phishing services. Because onion names are not easily recognizable strings, providing the public with additional information about the operator has significant security improvements, especially in regions where use of the incorrect name could have lethal consequences. The following motion has been proposed by Jeremy Rowley of DigiCert and endorsed by Ryan Sleevi of Google and Wayne Thayer of GoDaddy. --------------------- Motion Starts --------------------- Amend Section 9.2.1 of the Baseline Requirements v. 1.2.3 as follows: 9.2.1 Subject Alternative Name Extension Certificate Field: extensions:subjectAltName Required/Optional: Required Contents: This 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. The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate. Wildcard FQDNs are permitted. As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name, the CA SHALL notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016. Also as of the Effective Date, the CA SHALL NOT issue a certificate with an Expiry Date later than 1 November 2015 with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name. Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Name. Effective May 1, 2015, each CA SHALL revoke all unexpired Certificates with an Internal Name using onion as the right-most label in an entry in the subjectAltName Extension or commonName field unless such Certificate was issued in accordance with Appendix F of the EV Guidelines. Amend the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2 as follows: Amend Section 9.2.2 and 11.7.1 as follows: 9.2.2. Subject Alternative Name Extension Certificate field: subjectAltName:dNSName Required/Optional: Required Contents: This extension MUST contain one or more host Domain Name(s) owned or controlled by the Subject and to be associated with the Subject's server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). Wildcard certificates are not allowed for EV Certificates except as permitted under Appendix F. 11.7 Verification of Applicant's Domain Name 11.7.1. Verification Requirements (1) For each Fully-Qualified Domain Name listed in a Certificate, other than a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant (or the Applicant's Parent Company, Subsidiary Company, or Affiliate, collectively referred to as "Applicant" for the purposes of this section) either is the Domain Name Registrant or has control over the FQDN using a procedure specified in Section 11.1.1 of the Baseline Requirements, except that a CA MAY NOT verify a domain using the procedure described 11.1.1(7). For a Certificate issued to a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant's control over the .onion Domain Name in accordance with Appendix F. (2) Mixed Character Set Domain Names: EV Certificates MAY include Domain Names containing mixed character sets only in compliance with the rules set forth by the domain registrar. The CA MUST visually compare any Domain Names with mixed character sets with known high risk domains. If a similarity is found, then the EV Certificate Request MUST be flagged as High Risk. The CA must perform reasonably appropriate additional authentication and verification to be certain beyond reasonable doubt that the Applicant and the target in question are the same organization. Add a new Appendix F: Appendix F - Issuance of Certificates for .onion Domain Names A CA may issue an EV Certificate with .onion in the right-most label of the Domain Name provided that issuance complies with the requirements set forth in this Appendix: 1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) The CAB Forum has created an extension of the TBSCertificate for use in conveying hashes of keys related to .onion addresses. The Tor Service Descriptor Hash extension has the following format: cabf-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 } TorServiceDescriptorSyntax ::= SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash TorServiceDescriptorHash:: = SEQUENCE { onionURI UTF8String algorithm AlgorithmIdentifier subjectPublicKeyHash BIT STRING } Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 6234) performed over the DER-encoding of an ASN.1 SubjectPublicKey of the .onion service and SubjectPublicKeyHash is the hash output. 2. The CA MUST verify the Applicant's control over the .onion Domain Name using one of the following: a. The CA MAY verify the Applicant's control over the .onion service by posting a specific value at a well-known URL under RFC5785. b. The CA MAY verify the Applicant's control over the .onion service by having the Applicant provide a Certificate Request signed using the .onion public key if the Attributes section of the certificationRequestInfo contains: (i) A caSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy, 2) is generated by the CA, and 3) delivered to the Applicant through a Verified Method of Communication and (ii) An applicantSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy and 2) is generated by the Applicant. The signing nonce attributes have the following format: caSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-caSigningNonce } } cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } applicantSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-applicantSigningNonce } } cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 } 4. Each Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name MUST conform to the requirements of these Guidelines, including the content requirements in Section 9 and Appendix B of the Baseline Requirements, except that the CA MAY include a wildcard character in the Subject Alternative Name Extension and Subject Common Name Field as the right-most character in the .onion Domain Name provided inclusion of the wildcard character complies with Section 11.1.3 of the Baseline Requirements. 5. CAs MUST NOT issue a Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name with a validity period longer than 15 months. Despite Section 9.2.1 of the Baseline Requirements deprecating the use of Internal Names, a CA MAY issue a Certificate containing an .onion name with an expiration date later than 1 November 2015 after (and only if) .onion is officially recognized by the IESG as a reserved TLD. 6. On or before February 15, 2015, each CA MUST revoke all Certificates issued with the Subject Alternative Name extension or Common Name field that includes a Domain Name where .onion is in the right-most label of the Domain Name unless the Certificate was issued in compliance with this Appendix F. ---- Motion Ends ----- The review period for this ballot shall commence at 2200 UTC on Thursday, 4 February 2015, and will close at 2200 UTC on Thursday, 11 February 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on Monday, 18 February 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150204/3961032e/attachment-0001.html From sleevi at google.com Wed Feb 4 15:08:10 2015 From: sleevi at google.com (Ryan Sleevi) Date: Wed, 4 Feb 2015 14:08:10 -0800 Subject: [cabfpub] Ballot .onion ballot In-Reply-To: References: Message-ID: On Wed, Feb 4, 2015 at 12:51 PM, Jeremy Rowley wrote: > I assume everyone is still willing to endorse? Thanks for continuing to work on this. Indeed, willing to. However, note your added revocation clause is duplicated in point 6 (with the earlier Feb 15 date). I'm guessing you just forgot you already had this clause ;) For those considering: This restricts the existing set of capabilities to issue .onion from "Whatever you want" (under internal name rules) to "Under these rules", but does nothing to prolong past the internal names sunset (.onion is still an internal name unless IANA delegates it, and a separate ballot will be needed IF IANA decides to never delegate and reserve as a special-purpose domain) From jeremy.rowley at digicert.com Wed Feb 4 15:10:26 2015 From: jeremy.rowley at digicert.com (Jeremy Rowley) Date: Wed, 4 Feb 2015 22:10:26 +0000 Subject: [cabfpub] Ballot .onion ballot In-Reply-To: References: Message-ID: Thanks - I had it in EV, but that won't effect certs issued under the BRs. I just need to update the dates so they match :) And thanks for the clarification. That's indeed the purpose. If IANA chooses not the reserve the name, we'll need to have a separate discussion on how (and whether) to proceed. -----Original Message----- From: Ryan Sleevi [mailto:sleevi at google.com] Sent: Wednesday, February 4, 2015 3:08 PM To: Jeremy Rowley Cc: CABFPub Subject: Re: [cabfpub] Ballot .onion ballot On Wed, Feb 4, 2015 at 12:51 PM, Jeremy Rowley wrote: > I assume everyone is still willing to endorse? Thanks for continuing to work on this. Indeed, willing to. However, note your added revocation clause is duplicated in point 6 (with the earlier Feb 15 date). I'm guessing you just forgot you already had this clause ;) For those considering: This restricts the existing set of capabilities to issue .onion from "Whatever you want" (under internal name rules) to "Under these rules", but does nothing to prolong past the internal names sunset (.onion is still an internal name unless IANA delegates it, and a separate ballot will be needed IF IANA decides to never delegate and reserve as a special-purpose domain) From wthayer at godaddy.com Wed Feb 4 21:00:39 2015 From: wthayer at godaddy.com (Wayne Thayer) Date: Thu, 5 Feb 2015 04:00:39 +0000 Subject: [cabfpub] Ballot .onion ballot In-Reply-To: References: Message-ID: <8144CFC7-F7F4-4FB4-9CF1-716BB32E4BDC@godaddy.com> Yes, I?ll still endorse. On 2/4/15, 3:10 PM, "Jeremy Rowley" wrote: >I assume everyone is still willing to endorse? From adriano.santoni at staff.aruba.it Thu Feb 5 00:24:51 2015 From: adriano.santoni at staff.aruba.it (Adriano Santoni) Date: Thu, 05 Feb 2015 08:24:51 +0100 Subject: [cabfpub] Draft Agenda for CA/B Forum call February 5, 2015 In-Reply-To: <14D026C7F297AD44AC82578DD818CDD038EEF0B789@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> References: <14D026C7F297AD44AC82578DD818CDD038EEF0B789@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> Message-ID: <54D31AC3.4000009@staff.aruba.it> An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150205/3974de1f/attachment-0001.html From atsushi.inaba at globalsign.com Thu Feb 5 00:36:05 2015 From: atsushi.inaba at globalsign.com (Atsushi Inaba) Date: Thu, 5 Feb 2015 07:36:05 +0000 Subject: [cabfpub] Draft Agenda for CA/B Forum call February 5, 2015 In-Reply-To: <54D31AC3.4000009@staff.aruba.it> References: <14D026C7F297AD44AC82578DD818CDD038EEF0B789@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> <54D31AC3.4000009@staff.aruba.it> Message-ID: Hello, I suppose that Vivaldi means the browser released recently. Please forgive me if I'm wrong.... Kind regards, Atsushi Inaba From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Adriano Santoni Sent: Thursday, February 5, 2015 4:25 PM To: public at cabforum.org Subject: Re: [cabfpub] Draft Agenda for CA/B Forum call February 5, 2015 Hi all, what is "Vivaldi" ? Adriano Il 04/02/2015 22:16, Dean Coclin ha scritto: We have an open 10 min slot below if anyone has a topic they'd like to discuss. Antitrust Statement: As you know, this meeting includes companies that compete against one another. This meeting is intended to discuss technical standards related to the provision of existing and new types of digital certificates without restricting competition in developing and marketing such certificates. This meeting is not intended to share competitively-sensitive information among competitors, and therefore all participants agree not to discuss or exchange information related to: (a) Pricing policies, pricing formulas, prices or other terms of sale; (b) Costs, cost structures, profit margins, (c) Pending or planned service offerings, (d) Customers, business, or marketing plans; or (e) The allocation of customers, territories, or products in any way. Note: Please announce yourself when you dial in. This helps in documenting attendance when recording is played back later. Here is the proposed agenda: Time Start(UTC) Stop Slot Description Notes / Presenters (Thur) 5 Feb 2015 0:01 16:00 16:01 1 Read Antitrust Statement Dean 0:02 16:01 16:03 2 Roll Call Dean 0:01 16:03 16:04 3 Review Agenda Dean 0:01 16:04 16:05 4 Approve Minutes of 22 Jan 2015 Distributed by Kirk on Jan 23rd 0:20 16:05 16:25 5 Ballot Updates: EV Working Group change, .Onion Ballot, Other EV Ballots? Jeremy, Kirk 0:05 16:25 16:30 6 Vivaldi 0:07 16:30 16:37 7 Any more discussion on IPv6? Ryan 0:10 16:37 16:47 8 Open Slot 0:05 16:45 16:50 9 EV Working Group Status Update Jeremy 0:02 16:50 16:52 10 Code Signing Working Group Status Update Dean/Jeremy -Public draft 0:02 16:52 16:54 11 Policy Review Working Group Status Update Ben/Dean-Boston meeting Jan 27th postponed due to blizzard 0:02 16:54 16:56 12 *New* Information Sharing Working Group Update Ben 0:03 16:56 16:59 13 Any Other Business - Cupertino Meeting-March 10-12: 26 attendees signed up so far 0:00 17:00 17:00 14 Next phone call - February 19, 2015 0:00 17:00 17:00 15 Adjourn _______________________________________________ Public mailing list Public at cabforum.org https://cabforum.org/mailman/listinfo/public -- Adriano Santoni -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150205/2abecbe8/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4315 bytes Desc: not available Url : https://cabforum.org/pipermail/public/attachments/20150205/2abecbe8/attachment-0001.bin From adriano.santoni at staff.aruba.it Thu Feb 5 00:45:57 2015 From: adriano.santoni at staff.aruba.it (Adriano Santoni) Date: Thu, 05 Feb 2015 08:45:57 +0100 Subject: [cabfpub] Draft Agenda for CA/B Forum call February 5, 2015 In-Reply-To: References: <14D026C7F297AD44AC82578DD818CDD038EEF0B789@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> <54D31AC3.4000009@staff.aruba.it> Message-ID: <54D31FB5.4070106@staff.aruba.it> An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150205/78b71cbf/attachment-0001.html From erwann.abalea at opentrust.com Thu Feb 5 03:05:01 2015 From: erwann.abalea at opentrust.com (Erwann Abalea) Date: Thu, 05 Feb 2015 11:05:01 +0100 Subject: [cabfpub] Ballot .onion ballot In-Reply-To: <445290cba41444119f8c958eebbcc76a@EX2.corp.digicert.com> References: <445290cba41444119f8c958eebbcc76a@EX2.corp.digicert.com> Message-ID: <54D3404D.90808@opentrust.com> Bonjour, Le 04/02/2015 22:19, Jeremy Rowley a ?crit : [...] > Amend the Guidelines for the Issuance and Management of Extended > Validation Certificates v1.5.2 as follows: > > Amend Section 9.2.2 and 11.7.1 as follows: > > 9.2.2. Subject Alternative Name Extension Certificate field: > subjectAltName:dNSName > > Required/Optional: Required > > Contents: This extension MUST contain one or more host Domain Name(s) > owned or controlled by the Subject and to be associated with the > Subject's server. Such server MAY be owned and operated by the Subject > or another entity (e.g., a hosting service). Wildcard certificates are > not allowed for EV Certificates_except as permitted under Appendix F_. > So an EV certificate can't be a wildcard one, except under some new conditions, applicable only to .onion names. Not a small change. [...] > Add a new Appendix F: > > Appendix F -- Issuance of Certificates for .onion Domain Names > [...] > 4. Each Certificate that includes a Domain Name where .onion is in the > right-most label of the Domain Name MUST conform to the requirements > of these Guidelines, including the content requirements in Section 9 > and Appendix B of the Baseline Requirements, except that the CA MAY > include a wildcard character in the Subject Alternative Name Extension > and Subject Common Name Field as the right-most character in the > .onion Domain Name provided inclusion of the wildcard character > complies with Section 11.1.3 of the Baseline Requirements. > What does that mean? is *.onion accepted? is *.onion accepted? -- Erwann ABALEA -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150205/10153613/attachment.html From gerv at mozilla.org Thu Feb 5 03:25:35 2015 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 05 Feb 2015 10:25:35 +0000 Subject: [cabfpub] Ballot .onion ballot In-Reply-To: <54D3404D.90808@opentrust.com> References: <445290cba41444119f8c958eebbcc76a@EX2.corp.digicert.com> <54D3404D.90808@opentrust.com> Message-ID: <54D3451F.4090201@mozilla.org> On 05/02/15 10:05, Erwann Abalea wrote: > What does that mean? > is *.onion accepted? > is *.onion accepted? You are right; this should say "left-most label" not "right-most character". Gerv From erwann.abalea at opentrust.com Thu Feb 5 07:13:59 2015 From: erwann.abalea at opentrust.com (Erwann Abalea) Date: Thu, 05 Feb 2015 15:13:59 +0100 Subject: [cabfpub] Ballot .onion ballot In-Reply-To: <54D3451F.4090201@mozilla.org> References: <445290cba41444119f8c958eebbcc76a@EX2.corp.digicert.com> <54D3404D.90808@opentrust.com> <54D3451F.4090201@mozilla.org> Message-ID: <54D37AA7.8040101@opentrust.com> Le 05/02/2015 11:25, Gervase Markham a ?crit : > On 05/02/15 10:05, Erwann Abalea wrote: >> What does that mean? >> is *.onion accepted? >> is *.onion accepted? > You are right; this should say "left-most label" not "right-most character". Even with this typo corrected, what is the rationale behind allowing wildcard EV certificates for .onion domains while rejecting wildcards for all other EV certs? Why should "*.facebookcorewwwi.onion" be allowed and "*.facebook.com" refused? -- Erwann ABALEA From gerv at mozilla.org Thu Feb 5 07:26:39 2015 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 05 Feb 2015 14:26:39 +0000 Subject: [cabfpub] Ballot .onion ballot In-Reply-To: <54D37AA7.8040101@opentrust.com> References: <445290cba41444119f8c958eebbcc76a@EX2.corp.digicert.com> <54D3404D.90808@opentrust.com> <54D3451F.4090201@mozilla.org> <54D37AA7.8040101@opentrust.com> Message-ID: <54D37D9F.1070907@mozilla.org> On 05/02/15 14:13, Erwann Abalea wrote: > Even with this typo corrected, what is the rationale behind allowing > wildcard EV certificates for .onion domains while rejecting wildcards > for all other EV certs? > > Why should "*.facebookcorewwwi.onion" be allowed and "*.facebook.com" > refused? I'm not the person who argued for a restriction on *.facebook.com EV, but the idea of no wildcard for EV, as I understand it, is that you then get e.g. EV "*.blogspot.com" and the actual person controlling fred.blogspot.com is not named in the EV cert fred.blogspot.com is using, thereby defeating the point of EV as being about identity. With .onion, there is a single private key (the one whose public fingerprint is facebookcorewwwi, in the case of Facebook) and so the idea of different mutually-untrusting entities owning and controlling different parts of the subdomain space doesn't really make much sense. So the above risk is not present. Gerv From jeremy.rowley at digicert.com Thu Feb 5 07:53:27 2015 From: jeremy.rowley at digicert.com (Jeremy Rowley) Date: Thu, 5 Feb 2015 14:53:27 +0000 Subject: [cabfpub] Ballot .onion ballot In-Reply-To: <54D3451F.4090201@mozilla.org> References: <445290cba41444119f8c958eebbcc76a@EX2.corp.digicert.com> <54D3404D.90808@opentrust.com> <54D3451F.4090201@mozilla.org> Message-ID: <2eebcc99c215491d9c19124f51c21f45@EX2.corp.digicert.com> Right - I changed both unintentionally. I'll make this correction and the correction Ryan Sleevi pointed out right after today's call. -----Original Message----- From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Gervase Markham Sent: Thursday, February 5, 2015 3:26 AM To: Erwann Abalea; public at cabforum.org Subject: Re: [cabfpub] Ballot .onion ballot On 05/02/15 10:05, Erwann Abalea wrote: > What does that mean? > is *.onion accepted? > is *.onion accepted? You are right; this should say "left-most label" not "right-most character". Gerv _______________________________________________ Public mailing list Public at cabforum.org https://cabforum.org/mailman/listinfo/public From gerv at mozilla.org Thu Feb 5 08:29:04 2015 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 05 Feb 2015 15:29:04 +0000 Subject: [cabfpub] Not coming to Switzerland in June :-( Message-ID: <54D38C40.90005@mozilla.org> Dear CAB Forum members, Unfortunately, Mozilla has scheduled a get-together the same week as the CAB Forum meeting in Switzerland at the end of June, so I will not be able to make it, or to dial in, and it's unlikely that any other Mozilla representative would be able to either. I don't want to have delusions of my own importance, but it has been noted before that it's important to have browser participation in face-to-face meetings. I also note that our friends at Google and Opera have not been attending in person recently, with their last attendances being: Opera: Meeting 30 (Sep 2013) Google: Meeting 28 (Feb 2013) Hence, I thought I'd note our planned absence so that if Microsoft were not planning to send anyone (and neither were Google or Opera), we could at least discuss whether the CAs in the group would prefer to meet alone, or would prefer to investigate an alternative week (by arrangement with our gracious hosts). Ryan? Jody? Sigbjorn? Gerv From douglas.beattie at globalsign.com Thu Feb 5 09:34:25 2015 From: douglas.beattie at globalsign.com (Doug Beattie) Date: Thu, 5 Feb 2015 16:34:25 +0000 Subject: [cabfpub] Preballot for IPv6 Support In-Reply-To: References: <548F4FAD.8070207@startcom.org> <65e414a19c364c0995474791821af203@EX2.corp.digicert.com> Message-ID: Ryan, GlobalSign, both GlobalSign proper and our CDN provider, support IPv4 and IPv6 for OCSP and CRLs today. Doug From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ryan Sleevi Sent: Wednesday, December 17, 2014 12:50 AM To: Jeremy Rowley Cc: CABFPub Subject: Re: [cabfpub] Preballot for IPv6 Support For the sake of the Forum and those questioning the value of this, I'd like to point out that this is not just theoretical for clients. Consider this message -http://seclists.org/nanog/2014/Dec/114 - to NANOG from one of the largest USP ISPs, Time Warner Cable about the trouble that they're having making a client that "Does PKI right" and the challenges they face (Robert's bio from the ARIN Advisory Council to fill in the value for $DAYJOB - https://www.arin.net/about_us/ac.html#rseastrom ) The lack of IPv6 universally penalizes a client that chooses to support revocation checking, because now in addition to supporting IPv6 on the server, server operators have to be aware of their CA's infrastructure support for IPv6. What's worse, if you look at the incentives, this penalizes the client. From the user's perspective, the choice to implement revocation checking is the fault of the device manufacturer/deployer (Time Warner), rather than an issue with the remote server. The remote server is unlikely to be told by end users that their site doesn't work when using Time Warner devices - instead, Time Warner will be told that the server doesn't work with them. These sorts of penalties have already been reported by browsers that have lead to questioning the revocation strategies, but this is yet another ecosystem affected. On Tue, Dec 16, 2014 at 8:29 PM, Jeremy Rowley > wrote: The proposal is more likely to force CAs into using their own infrastructure to provide revocation information than forcing CDNs and hosting providers to use IPv6, slowing OCSP response times. However, nothing wrong with gathering the information and looking at which CDNs and providers we need to get on board with the proposal. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ryan Sleevi Sent: Monday, December 15, 2014 2:59 PM To: Eddy Nigg Cc: CABFPub Subject: Re: [cabfpub] Preballot for IPv6 Support On Mon, Dec 15, 2014 at 1:16 PM, Eddy Nigg > wrote: On 12/15/2014 11:02 PM, Ryan Sleevi wrote: As discussed on our call last week, I'd like to put together a ballot requiring that CAs support IPv6 for their external (relying party facing) infrastructure. Funny that you want to start with that part first - most of the time that's the part CAs have the least control over it and depend on third parties. I'm not sure I follow this. CAs aren't required to delegate their infrastructure out to third-parties. If they chose to, then they have to pick third-parties who are capable of meeting the Baseline Requirements (e.g. the current 24/7 uptime requirements or the 10 second availability). If a new requirement comes down, the question is how long will it take for the CAs to either get their infrastructure updated, get their third parties to update, or transition to new third parties. That's fundamentally the question I'm asking. This is surely NOT a problem that's impossible. If CAs are telling third parties that they need IPv6 support, then eventually there will be IPv6 support. As both servers and clients transition to IPv6-only networks, the goal is to ensure that services RPs need are accessible. Hardly 5 % as of today - and I assume they all (must) support IPv4 in any case since the vast majority doesn't support IPv6. That's an assumption that is, in part, caused by the unavailability of some services over IPv4. This is a collective action problem, as the CA industry is quite familiar with, so I don't understand why "we don't support it today" is necessarily an argument for why "we shouldn't support it tomorrow". Before proposing dates/timelines, it'd be helpful to understand where the CA's current infrastructure and plans are, so that we can reach a happy medium. I believe this is premature by any standard. Of course CAs may and probably want to support IPv6 as soon as there is a real demand for it. It's also not overly difficult - but the real problem is the third party service providers involved including CDNs and ISPs which must provide IPv6 support first before the CA can. I fail to see how this is premature. It's exactly the same conversation that had to happen with SHA-1 - CAs weren't moving to support it, so eventually timelines had to be set. This is a classic collective action problem, and it's simply a question of what is a reasonable timeframe for CAs to move, and why. You've indicated "CDNs and ISPs must provide IPv6 support first". A number of them do. A number of them don't. The entire point of a preballot is to get a sense of what those numbers are, and for CAs that have contracts with those that do not support IPv6, how long would it take a reasonable CA to support it? You've indicated it's not overly difficult, so is it a matter of 3 months? 6 months? 10 years? That's the set of information that's useful to discuss, rather than assume it will happen. Consider "Real demand for it" being at least one browser with a non-trivial user base requesting it. But besides that I'm a bit curious why Google would have even the slightest interest in revocation checking services and how they are accessed considering that its products don't check revocation in first place :-) 1) This isn't just about revocation checking. As I noted in the preballot, it's also about authorityInfoAccess for intermediates. 2) As I explained in the preballot, this also applies to servers' ability to fetch fresh OCSP responses. I appreciate the feedback, Eddy, but your response seems mostly reactionary, without having read the proposal or justifications provided therein. It'd be helpful to know what concrete concerns you'd have and what it would take to address them. Regardless, I don't think it's a good state in the present form that, for counter-example, a CA could provide an OCSP responder or AIA caIssuers solely available over IPv6, when as you note, there's a non-trivial majority of clients with IPv4-only stacks. So consider this proposal as a way to close that ambiguity as well. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150205/69aaf73b/attachment-0001.html From sleevi at google.com Thu Feb 5 09:42:54 2015 From: sleevi at google.com (Ryan Sleevi) Date: Thu, 5 Feb 2015 08:42:54 -0800 Subject: [cabfpub] Not coming to Switzerland in June :-( In-Reply-To: <54D38C40.90005@mozilla.org> References: <54D38C40.90005@mozilla.org> Message-ID: On Thu, Feb 5, 2015 at 7:29 AM, Gervase Markham wrote: > Dear CAB Forum members, > > Unfortunately, Mozilla has scheduled a get-together the same week as the > CAB Forum meeting in Switzerland at the end of June, so I will not be > able to make it, or to dial in, and it's unlikely that any other Mozilla > representative would be able to either. > > I don't want to have delusions of my own importance, but it has been > noted before that it's important to have browser participation in > face-to-face meetings. I also note that our friends at Google and Opera > have not been attending in person recently, with their last attendances > being: > > Opera: Meeting 30 (Sep 2013) > Google: Meeting 28 (Feb 2013) > > Hence, I thought I'd note our planned absence so that if Microsoft were > not planning to send anyone (and neither were Google or Opera), we could > at least discuss whether the CAs in the group would prefer to meet > alone, or would prefer to investigate an alternative week (by > arrangement with our gracious hosts). > > Ryan? Jody? Sigbjorn? > > Gerv Hi Gerv, Looks like you made a typo; we hosted the February 2014 F2F here in Mountain View, and, while unable to attend the Beijing F2F in September, I remotely dialed in for all of the non-WG-specific meetings (which we don't participate in anyways). It's unclear at this time with regards to the Switzerland F2F, but do you have alternate dates or times that might work better for you, so as to inform the discussion? From gerv at mozilla.org Thu Feb 5 09:46:20 2015 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 05 Feb 2015 16:46:20 +0000 Subject: [cabfpub] Not coming to Switzerland in June :-( In-Reply-To: References: <54D38C40.90005@mozilla.org> Message-ID: <54D39E5C.6030505@mozilla.org> On 05/02/15 16:42, Ryan Sleevi wrote: > Looks like you made a typo; we hosted the February 2014 F2F here in > Mountain View, Ah! I was fooled because https://www.cabforum.org/wiki/Meeting%2031 lists no Google people. > It's unclear at this time with regards to the Switzerland F2F, but do > you have alternate dates or times that might work better for you, so > as to inform the discussion? As noted on the call, both the week before and the week after could be made to work for me. Although ideally I'd not be away two weeks on the trot, so a further week either side would actually be a bit better. Gerv From Dean_Coclin at symantec.com Thu Feb 5 10:11:58 2015 From: Dean_Coclin at symantec.com (Dean Coclin) Date: Thu, 5 Feb 2015 09:11:58 -0800 Subject: [cabfpub] Code Signing Baseline Requirements - Final Draft for public exposure Message-ID: <14D026C7F297AD44AC82578DD818CDD038EEF0BA61@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> The Code Signing Working Group of the CA/Browser Forum announces the final draft of the Code Signing Baseline Requirements. This version takes into account comments received in the first round of public review as well as comments from WebTrust auditors. Additional changes/corrections were incorporated by the working group over the past 3 months. This version is being sent out to the public mailing list and will be posted on the CA/B Forum website for final comments until March 6th, 2015. Comments should be sent to: questions at cabforum.org. If there are no further comments, the group plans to propose a ballot to the CA/B Forum in mid-March to approve the Baseline Requirements. The team wishes to thank the following companies/organizations for participating in the working group: CACert Comodo Digicert Entrust ETSI Federal PKI Firmprofessional Globalsign Intarsys Izenpe Microsoft OTA Alliance Startcom Symantec SwissSign Travelport Trend Micro WebTrust WoSign >From the beginning, we have endeavored to keep the document formation process open and inclusive and we hope everyone feels that this contribution is significant to the improvement of Internet security. Dean Coclin CA/B Forum Chair -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150205/deaaea89/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: Baseline requirements for codesigning - Feb 4 2015.doc Type: application/msword Size: 295424 bytes Desc: not available Url : https://cabforum.org/pipermail/public/attachments/20150205/deaaea89/attachment-0001.doc -------------- next part -------------- A non-text attachment was scrubbed... Name: Baseline requirements for codesigning - Feb 4 2015 (3).pdf Type: application/pdf Size: 801597 bytes Desc: not available Url : https://cabforum.org/pipermail/public/attachments/20150205/deaaea89/attachment-0001.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6130 bytes Desc: not available Url : https://cabforum.org/pipermail/public/attachments/20150205/deaaea89/attachment-0001.bin From Dean_Coclin at symantec.com Thu Feb 5 10:38:57 2015 From: Dean_Coclin at symantec.com (Dean Coclin) Date: Thu, 5 Feb 2015 09:38:57 -0800 Subject: [cabfpub] Not coming to Switzerland in June :-( In-Reply-To: <54D39E5C.6030505@mozilla.org> References: <54D38C40.90005@mozilla.org> <54D39E5C.6030505@mozilla.org> Message-ID: <14D026C7F297AD44AC82578DD818CDD038EEF0BA8C@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> Clearly that list is incorrect (especially since Google hosted the meeting but probably felt they didn't need to sign up for their own venue). But luckily they are present in the Minutes. OK, Kirk and I will discuss this along with the host and put out some suggestions. Dean -----Original Message----- From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Gervase Markham Sent: Thursday, February 05, 2015 11:46 AM To: Ryan Sleevi Cc: CABFPub Subject: Re: [cabfpub] Not coming to Switzerland in June :-( On 05/02/15 16:42, Ryan Sleevi wrote: > Looks like you made a typo; we hosted the February 2014 F2F here in > Mountain View, Ah! I was fooled because https://www.cabforum.org/wiki/Meeting%2031 lists no Google people. > It's unclear at this time with regards to the Switzerland F2F, but do > you have alternate dates or times that might work better for you, so > as to inform the discussion? As noted on the call, both the week before and the week after could be made to work for me. Although ideally I'd not be away two weeks on the trot, so a further week either side would actually be a bit better. Gerv _______________________________________________ Public mailing list Public at cabforum.org https://cabforum.org/mailman/listinfo/public -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6130 bytes Desc: not available Url : https://cabforum.org/pipermail/public/attachments/20150205/c72ed535/attachment.bin From i-barreira at izenpe.net Thu Feb 5 10:44:16 2015 From: i-barreira at izenpe.net (i-barreira at izenpe.net) Date: Thu, 05 Feb 2015 18:44:16 +0100 Subject: [cabfpub] Not coming to Switzerland in June :-( In-Reply-To: A <14D026C7F297AD44AC82578DD818CDD038EEF0BA8C@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> References: <54D38C40.90005@mozilla.org> <54D39E5C.6030505@mozilla.org> A <14D026C7F297AD44AC82578DD818CDD038EEF0BA8C@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> Message-ID: <763539E260C37C46A0D6B340B5434C3B0ACD7C48@AEX06.ejsarea.net> We haven?t heard of the other browsers yet. We can check if we have had some F2F meetings without browsers. Don?t see a major impact since they can dialing in as Ryan did last time, or read the minutes at the end I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. -----Mensaje original----- De: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] En nombre de Dean Coclin Enviado el: jueves, 05 de febrero de 2015 18:39 Para: Gervase Markham; Ryan Sleevi CC: CABFPub Asunto: Re: [cabfpub] Not coming to Switzerland in June :-( Clearly that list is incorrect (especially since Google hosted the meeting but probably felt they didn't need to sign up for their own venue). But luckily they are present in the Minutes. OK, Kirk and I will discuss this along with the host and put out some suggestions. Dean -----Original Message----- From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Gervase Markham Sent: Thursday, February 05, 2015 11:46 AM To: Ryan Sleevi Cc: CABFPub Subject: Re: [cabfpub] Not coming to Switzerland in June :-( On 05/02/15 16:42, Ryan Sleevi wrote: > Looks like you made a typo; we hosted the February 2014 F2F here in > Mountain View, Ah! I was fooled because https://www.cabforum.org/wiki/Meeting%2031 lists no Google people. > It's unclear at this time with regards to the Switzerland F2F, but do > you have alternate dates or times that might work better for you, so > as to inform the discussion? As noted on the call, both the week before and the week after could be made to work for me. Although ideally I'd not be away two weeks on the trot, so a further week either side would actually be a bit better. Gerv _______________________________________________ Public mailing list Public at cabforum.org https://cabforum.org/mailman/listinfo/public From eddy_nigg at startcom.org Thu Feb 5 10:44:49 2015 From: eddy_nigg at startcom.org (Eddy Nigg) Date: Thu, 05 Feb 2015 19:44:49 +0200 Subject: [cabfpub] Ballot .onion ballot In-Reply-To: <54D37D9F.1070907@mozilla.org> References: <445290cba41444119f8c958eebbcc76a@EX2.corp.digicert.com> <54D3404D.90808@opentrust.com> <54D3451F.4090201@mozilla.org> <54D37AA7.8040101@opentrust.com> <54D37D9F.1070907@mozilla.org> Message-ID: <54D3AC11.6050607@startcom.org> On 02/05/2015 04:26 PM, Gervase Markham wrote: > I'm not the person who argued for a restriction on *.facebook.com EV I too might be wrong on this, but according to my memory I recall that you were the person arguing against it when we discussed it last time when we created the BR. :-) IIRC Wayne from Godaddy argued (correctly) that if wild cards should be restricted it would make most sense to have it supported by EV since it's the strongest verification standard currently. EV allows to include domain names of third parties (in my opinion incorrectly), so adding wild cards doesn't change that in any way really. We would be in favor for such a move and believe that wild cards have nothing lost in the non-verified (e.g. DV) settings due to their potential abuse. If at all, wild cards should be permitted with EV and prohibited for DV (if you want anything else than EV). -- Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. XMPP: startcom at startcom.org Blog: Join the Revolution! Twitter: Follow Me -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150205/9a33b6f3/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4313 bytes Desc: S/MIME Cryptographic Signature Url : https://cabforum.org/pipermail/public/attachments/20150205/9a33b6f3/attachment-0001.bin From sleevi at google.com Thu Feb 5 11:10:33 2015 From: sleevi at google.com (Ryan Sleevi) Date: Thu, 5 Feb 2015 10:10:33 -0800 Subject: [cabfpub] Ballot .onion ballot In-Reply-To: <54D3AC11.6050607@startcom.org> References: <445290cba41444119f8c958eebbcc76a@EX2.corp.digicert.com> <54D3404D.90808@opentrust.com> <54D3451F.4090201@mozilla.org> <54D37AA7.8040101@opentrust.com> <54D37D9F.1070907@mozilla.org> <54D3AC11.6050607@startcom.org> Message-ID: On Thu, Feb 5, 2015 at 9:44 AM, Eddy Nigg wrote: > > On 02/05/2015 04:26 PM, Gervase Markham wrote: > > I'm not the person who argued for a restriction on *.facebook.com EV > > > I too might be wrong on this, but according to my memory I recall that you > were the person arguing against it when we discussed it last time when we > created the BR. :-) > > IIRC Wayne from Godaddy argued (correctly) that if wild cards should be > restricted it would make most sense to have it supported by EV since it's > the strongest verification standard currently. EV allows to include domain > names of third parties (in my opinion incorrectly), so adding wild cards > doesn't change that in any way really. > > We would be in favor for such a move and believe that wild cards have > nothing lost in the non-verified (e.g. DV) settings due to their potential > abuse. If at all, wild cards should be permitted with EV and prohibited for > DV (if you want anything else than EV). > At the risk of derailing the conversation, we'd be opposed to such a proposal (and have said so in the past) To the topic at hand - as it relates specifically to .onion names: The case for wildcards: - The use of origins (RFC 6454 for those unfamiliar with the core concept of web security) provides an effective means to separate privileges and reduce the risks of compromise (in the web sense; this means issues such as XSS) and the privileges granted - The use of separable origins can be beneficial-to-critical to high performance web pages (... unless/until the site is using HTTP/2), due to items such as connection pooling, request prioritization, etc The case against wildcards: - The primary argument against wildcards (for EV) is derived from Section 11.12.1 of EVG 1.5.2. EVG 1.5.2 requires all names be treated as High Risk (as defined in the BRs 1.2.3), which requires that the CA perform some degree of secondary checks (such as names listed on Miller Smiles or Safe Browsing). A wildcard cert allows an entity to request a potentially confusing name (bankofamericacom.facebook.com) that may phish the user. - The secondary argument against wildcards is derived from Section 11.7.1 p2 of EVG 1.5.2, the prohibition against mixed script. A wildcard allows a certificate holder to find any valid construction of IDNA/script at that subordinate domain that may exploit some confusible. Now, I don't feel that the case against is at all strong or relevant. It's long been public record that we don't view certificates as an effective means against phishing, for a wide variety of reasons, and so phishing-level arguments are, to us, particularly specious. The argument against mixed script is also questionable, in as much as it's possible with DV, and it's an issue that browsers (and their rules regarding presentation of punycode vs native scripts) are already handling. For !browser clients, it might be relevant, but I would argue that the EVGs are not exactly relevant to the !browser case. To the broader question about whether wildcards should be prevented or allowed in the EVGs, I suspect this will be the same tension and misaligned interests as the insurance discussion. CAs may perceive one set of value propositions, browsers another. The lack of wildcard support allows for greater price controls, which on a purely business level is a boon, but on a practical security level, would be unfortunate if CAs place profit over security. However, if this does represent some set of concern for CAs (although I would argue unwarranted, for the reasons explained above), then I suspect it can be removed. It just means anyone wanting to use hidden services for accessibility (e.g. as Facebook is doing) will need to invest sizably more, or work out an appropriate cost structure with the CA that allows for bulk purchase, neither of which do much to change the security landscape any. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150205/fcc0f41f/attachment.html From jodycl at microsoft.com Mon Feb 9 10:54:31 2015 From: jodycl at microsoft.com (Jody Cloutier) Date: Mon, 9 Feb 2015 17:54:31 +0000 Subject: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Message-ID: Microsoft comments on Section 17. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150209/0a4d787f/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: Baseline requirements for codesigning - Feb 4 2015.doc Type: application/msword Size: 310272 bytes Desc: Baseline requirements for codesigning - Feb 4 2015.doc Url : https://cabforum.org/pipermail/public/attachments/20150209/0a4d787f/attachment-0001.doc From benedikt at cacert.org Mon Feb 9 16:05:11 2015 From: benedikt at cacert.org (Benedikt Heintel) Date: Tue, 10 Feb 2015 00:05:11 +0100 Subject: [cabfpub] Audit over CA/B BR and WebTrust needed? Message-ID: <54D93D27.6020807@cacert.org> Dear group, Planning the next steps forward, getting our root certificates in the trust stores, we wonder what are the minimum requirements certification wise. Do we need CA/B Baseline Requirements and WebTrust Certification? Is it necessary to go for CA/B BR and ETSI TS 102 042? Is CA/B BR enough? Best Regards Benedikt -- Benedikt Heintel - benedikt at cacert.org CAcert Assurer for People & Organizations CAcert internal Auditor CAcert.org - Secure Together http://www.cacert.org -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3870 bytes Desc: S/MIME Cryptographic Signature Url : https://cabforum.org/pipermail/public/attachments/20150210/eeb34581/attachment.bin From sleevi at google.com Mon Feb 9 16:11:07 2015 From: sleevi at google.com (Ryan Sleevi) Date: Mon, 9 Feb 2015 15:11:07 -0800 Subject: [cabfpub] Audit over CA/B BR and WebTrust needed? In-Reply-To: <54D93D27.6020807@cacert.org> References: <54D93D27.6020807@cacert.org> Message-ID: On Feb 9, 2015 3:05 PM, "Benedikt Heintel" wrote: > > Dear group, > > Planning the next steps forward, getting our root certificates in the > trust stores, we wonder what are the minimum requirements certification > wise. > > Do we need CA/B Baseline Requirements and WebTrust Certification? > Is it necessary to go for CA/B BR and ETSI TS 102 042? Is CA/B BR enough? > > Best Regards > Benedikt > -- > Benedikt Heintel - benedikt at cacert.org > CAcert Assurer for People & Organizations > CAcert internal Auditor > > CAcert.org - Secure Together > http://www.cacert.org > > > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public > That's nominally a question for each root to answer as to what their individual acceptance policies are. To be enabled for the SSL trust bits in Mozilla, for example, you must complete an appropriate audit scheme that incorporates the CA/B Forum Baseline Requirements, as well as comply with the Mozilla Root Inclusion policy. The acceptable audit schemes are listed in https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ For WebTrust, this means Principles and Criteria for CAs 2.0 _and_ SSL BR audit 1.1. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150209/9d3b0a37/attachment.html From i-barreira at izenpe.net Tue Feb 10 02:17:33 2015 From: i-barreira at izenpe.net (i-barreira at izenpe.net) Date: Tue, 10 Feb 2015 10:17:33 +0100 Subject: [cabfpub] Audit over CA/B BR and WebTrust needed? In-Reply-To: References: <54D93D27.6020807@cacert.org> Message-ID: <763539E260C37C46A0D6B340B5434C3B0ACD8128@AEX06.ejsarea.net> If you have access to the wiki there you can find the different requirements of the browsers plus the information from ETSI and Webtrust. I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. De: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] En nombre de Ryan Sleevi Enviado el: martes, 10 de febrero de 2015 0:11 Para: Benedikt Heintel CC: CABFPub Asunto: Re: [cabfpub] Audit over CA/B BR and WebTrust needed? On Feb 9, 2015 3:05 PM, "Benedikt Heintel" wrote: > > Dear group, > > Planning the next steps forward, getting our root certificates in the > trust stores, we wonder what are the minimum requirements certification > wise. > > Do we need CA/B Baseline Requirements and WebTrust Certification? > Is it necessary to go for CA/B BR and ETSI TS 102 042? Is CA/B BR enough? > > Best Regards > Benedikt > -- > Benedikt Heintel - benedikt at cacert.org > CAcert Assurer for People & Organizations > CAcert internal Auditor > > CAcert.org - Secure Together > http://www.cacert.org > > > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public > That's nominally a question for each root to answer as to what their individual acceptance policies are. To be enabled for the SSL trust bits in Mozilla, for example, you must complete an appropriate audit scheme that incorporates the CA/B Forum Baseline Requirements, as well as comply with the Mozilla Root Inclusion policy. The acceptable audit schemes are listed in https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ For WebTrust, this means Principles and Criteria for CAs 2.0 _and_ SSL BR audit 1.1. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150210/04bd50cf/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 19121 bytes Desc: image001.png Url : https://cabforum.org/pipermail/public/attachments/20150210/04bd50cf/attachment-0001.png From i-barreira at izenpe.net Tue Feb 10 04:09:24 2015 From: i-barreira at izenpe.net (i-barreira at izenpe.net) Date: Tue, 10 Feb 2015 12:09:24 +0100 Subject: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Message-ID: <763539E260C37C46A0D6B340B5434C3B0ACD81A9@AEX06.ejsarea.net> Hi Jody, Regarding your comment on ETSI audits, I have to say that the ETSI audits shall be performed by accredited auditors as mentioned in Annex E of the current ETSI TS 102 042. ETSI audits performed by not accredited auditors shall be considered invalid. Microsoft is accepting ETSI audits since the very beginning in its root program requirements indicating this requirement. ETSI is providing a list of accredited auditors as mere information because has to be maintained by every NAB (National Accreditation Body). It?s true that this has to be improved regarding the new regulation 910/2014 and the new ENs and will take some time, but at the moment, it?s clearly stated that the audits shall be performed by accredited auditors. Don?t hesitate in contacting me for any additional information or help. Sometimes I?ve received some emails from Tom or Kelvin asking for the qualification of some audits, so, as say, you can contact me regarding this issue. Regards I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. De: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] En nombre de Jody Cloutier Enviado el: lunes, 09 de febrero de 2015 18:55 Para: CABFPub (public at cabforum.org) Asunto: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Microsoft comments on Section 17. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150210/b7d57383/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 19121 bytes Desc: image001.png Url : https://cabforum.org/pipermail/public/attachments/20150210/b7d57383/attachment-0001.png From ben.wilson at digicert.com Tue Feb 10 07:20:29 2015 From: ben.wilson at digicert.com (Ben Wilson) Date: Tue, 10 Feb 2015 14:20:29 +0000 Subject: [cabfpub] Audit over CA/B BR and WebTrust needed? In-Reply-To: <763539E260C37C46A0D6B340B5434C3B0ACD8128@AEX06.ejsarea.net> References: <54D93D27.6020807@cacert.org> <763539E260C37C46A0D6B340B5434C3B0ACD8128@AEX06.ejsarea.net> Message-ID: <5e42a240cc6d404ba88cda81558d7f4e@EX2.corp.digicert.com> I tried to port that all over from the wiki to the public web site. You can find information here - https://cabforum.org/browser-os-info/ and here - https://cabforum.org/audit-criteria/. Going forward, if our website isn?t clear, then we need update the information so that it is. Any member representative interested in improving our web pages should contact me. Thanks, Ben From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of i-barreira at izenpe.net Sent: Tuesday, February 10, 2015 2:18 AM To: sleevi at google.com; benedikt at cacert.org Cc: public at cabforum.org Subject: Re: [cabfpub] Audit over CA/B BR and WebTrust needed? If you have access to the wiki there you can find the different requirements of the browsers plus the information from ETSI and Webtrust. I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. De: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] En nombre de Ryan Sleevi Enviado el: martes, 10 de febrero de 2015 0:11 Para: Benedikt Heintel CC: CABFPub Asunto: Re: [cabfpub] Audit over CA/B BR and WebTrust needed? On Feb 9, 2015 3:05 PM, "Benedikt Heintel" > wrote: > > Dear group, > > Planning the next steps forward, getting our root certificates in the > trust stores, we wonder what are the minimum requirements certification > wise. > > Do we need CA/B Baseline Requirements and WebTrust Certification? > Is it necessary to go for CA/B BR and ETSI TS 102 042? Is CA/B BR enough? > > Best Regards > Benedikt > -- > Benedikt Heintel - benedikt at cacert.org > CAcert Assurer for People & Organizations > CAcert internal Auditor > > CAcert.org - Secure Together > http://www.cacert.org > > > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public > That's nominally a question for each root to answer as to what their individual acceptance policies are. To be enabled for the SSL trust bits in Mozilla, for example, you must complete an appropriate audit scheme that incorporates the CA/B Forum Baseline Requirements, as well as comply with the Mozilla Root Inclusion policy. The acceptable audit schemes are listed in https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ For WebTrust, this means Principles and Criteria for CAs 2.0 _and_ SSL BR audit 1.1. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150210/65916e00/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 19121 bytes Desc: not available Url : https://cabforum.org/pipermail/public/attachments/20150210/65916e00/attachment-0001.png -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4954 bytes Desc: not available Url : https://cabforum.org/pipermail/public/attachments/20150210/65916e00/attachment-0001.bin From jeremy.rowley at digicert.com Tue Feb 10 11:38:52 2015 From: jeremy.rowley at digicert.com (Jeremy Rowley) Date: Tue, 10 Feb 2015 18:38:52 +0000 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names Message-ID: Here's the ballot with the two typos fixed: Applicants want a CA-signed .onion address for several reasons, including: - Powerful web platform features are restricted to secure origins, which are currently not available to onion names (in part, because of the lack of IANA registration). Permitting EV certs for onion names will help provide a secure origin for the service, moving onion towards use of powerful web platform features. - Currently, access to .onion names over https from a standard browser results in the standard existing 'Invalid Certificate' warning. Training users to click through security warnings lowers the value of these warnings and will cause users to miss important security information. Removing these warnings for the user, through use of a digital certificate, will help users recognize and avoid real MITM attacks. - The public needs attribution of ownership of the .onion address to differentiate onion services, including potential phishing services. Because onion names are not easily recognizable strings, providing the public with additional information about the operator has significant security improvements, especially in regions where use of the incorrect name could have lethal consequences. The following motion has been proposed by Jeremy Rowley of DigiCert and endorsed by Ryan Sleevi of Google and Wayne Thayer of GoDaddy. --------------------- Motion Starts --------------------- 1) Amend Section 9.2.1 of the Baseline Requirements v. 1.2.3 as follows: 9.2.1 Subject Alternative Name Extension Certificate Field: extensions:subjectAltName Required/Optional: Required Contents: This 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. The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate. Wildcard FQDNs are permitted. As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name, the CA SHALL notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016. Also as of the Effective Date, the CA SHALL NOT issue a certificate with an Expiry Date later than 1 November 2015 with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name. Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Name. Effective May 1, 2015, each CA SHALL revoke all unexpired Certificates with an Internal Name using onion as the right-most label in an entry in the subjectAltName Extension or commonName field unless such Certificate was issued in accordance with Appendix F of the EV Guidelines. 2) Amend Section 9.2.2 and 11.7.1 of the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2 as follows: 9.2.2. Subject Alternative Name Extension Certificate field: subjectAltName:dNSName Required/Optional: Required Contents: This extension MUST contain one or more host Domain Name(s) owned or controlled by the Subject and to be associated with the Subject's server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). Wildcard certificates are not allowed for EV Certificates except as permitted under Appendix F. 11.7 Verification of Applicant's Domain Name 11.7.1. Verification Requirements (1) For each Fully-Qualified Domain Name listed in a Certificate, other than a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant (or the Applicant's Parent Company, Subsidiary Company, or Affiliate, collectively referred to as "Applicant" for the purposes of this section) either is the Domain Name Registrant or has control over the FQDN using a procedure specified in Section 11.1.1 of the Baseline Requirements, except that a CA MAY NOT verify a domain using the procedure described 11.1.1(7). For a Certificate issued to a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant's control over the .onion Domain Name in accordance with Appendix F. (2) Mixed Character Set Domain Names: EV Certificates MAY include Domain Names containing mixed character sets only in compliance with the rules set forth by the domain registrar. The CA MUST visually compare any Domain Names with mixed character sets with known high risk domains. If a similarity is found, then the EV Certificate Request MUST be flagged as High Risk. The CA must perform reasonably appropriate additional authentication and verification to be certain beyond reasonable doubt that the Applicant and the target in question are the same organization. 3) Add a new Appendix F to the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2: Appendix F - Issuance of Certificates for .onion Domain Names A CA may issue an EV Certificate with .onion in the right-most label of the Domain Name provided that issuance complies with the requirements set forth in this Appendix: 1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) The CAB Forum has created an extension of the TBSCertificate for use in conveying hashes of keys related to .onion addresses. The Tor Service Descriptor Hash extension has the following format: cabf-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 } TorServiceDescriptorSyntax ::= SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash TorServiceDescriptorHash:: = SEQUENCE { onionURI UTF8String algorithm AlgorithmIdentifier subjectPublicKeyHash BIT STRING } Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 6234) performed over the DER-encoding of an ASN.1 SubjectPublicKey of the .onion service and SubjectPublicKeyHash is the hash output. 2. The CA MUST verify the Applicant's control over the .onion Domain Name using one of the following: a. The CA MAY verify the Applicant's control over the .onion service by posting a specific value at a well-known URL under RFC5785. b. The CA MAY verify the Applicant's control over the .onion service by having the Applicant provide a Certificate Request signed using the .onion public key if the Attributes section of the certificationRequestInfo contains: (i) A caSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy, 2) is generated by the CA, and 3) delivered to the Applicant through a Verified Method of Communication and (ii) An applicantSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy and 2) is generated by the Applicant. The signing nonce attributes have the following format: caSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-caSigningNonce } } cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } applicantSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-applicantSigningNonce } } cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 } 4. Each Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name MUST conform to the requirements of these Guidelines, including the content requirements in Section 9 and Appendix B of the Baseline Requirements, except that the CA MAY include a wildcard character in the Subject Alternative Name Extension and Subject Common Name Field as the left-most character in the .onion Domain Name provided inclusion of the wildcard character complies with Section 11.1.3 of the Baseline Requirements. 5. CAs MUST NOT issue a Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name with a validity period longer than 15 months. Despite Section 9.2.1 of the Baseline Requirements deprecating the use of Internal Names, a CA MAY issue a Certificate containing an .onion name with an expiration date later than 1 November 2015 after (and only if) .onion is officially recognized by the IESG as a reserved TLD. 6. On or before May 1, 2015, each CA MUST revoke all Certificates issued with the Subject Alternative Name extension or Common Name field that includes a Domain Name where .onion is in the right-most label of the Domain Name unless the Certificate was issued in compliance with this Appendix F. ---- Motion Ends ----- The review period for this ballot shall commence at 2200 UTC on Thursday, 4 February 2015, and will close at 2200 UTC on Thursday, 11 February 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on Monday, 18 February 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150210/0e0b8886/attachment-0001.html From ben.wilson at digicert.com Tue Feb 10 14:02:17 2015 From: ben.wilson at digicert.com (Ben Wilson) Date: Tue, 10 Feb 2015 21:02:17 +0000 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names In-Reply-To: References: Message-ID: <5c04557077cf4564979bc37e501297de@EX2.corp.digicert.com> I'll post this to the public page with a correction stating that the review period ends and the voting period of the ballot begins to run from Wednesday, 11 Feb., to Wednesday, 18 Feb. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Tuesday, February 10, 2015 11:39 AM To: public at cabforum.org Subject: [cabfpub] Ballot 144 - Validation rules for .onion names Here's the ballot with the two typos fixed: Applicants want a CA-signed .onion address for several reasons, including: - Powerful web platform features are restricted to secure origins, which are currently not available to onion names (in part, because of the lack of IANA registration). Permitting EV certs for onion names will help provide a secure origin for the service, moving onion towards use of powerful web platform features. - Currently, access to .onion names over https from a standard browser results in the standard existing 'Invalid Certificate' warning. Training users to click through security warnings lowers the value of these warnings and will cause users to miss important security information. Removing these warnings for the user, through use of a digital certificate, will help users recognize and avoid real MITM attacks. - The public needs attribution of ownership of the .onion address to differentiate onion services, including potential phishing services. Because onion names are not easily recognizable strings, providing the public with additional information about the operator has significant security improvements, especially in regions where use of the incorrect name could have lethal consequences. The following motion has been proposed by Jeremy Rowley of DigiCert and endorsed by Ryan Sleevi of Google and Wayne Thayer of GoDaddy. --------------------- Motion Starts --------------------- 1) Amend Section 9.2.1 of the Baseline Requirements v. 1.2.3 as follows: 9.2.1 Subject Alternative Name Extension Certificate Field: extensions:subjectAltName Required/Optional: Required Contents: This 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. The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate. Wildcard FQDNs are permitted. As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name, the CA SHALL notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016. Also as of the Effective Date, the CA SHALL NOT issue a certificate with an Expiry Date later than 1 November 2015 with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name. Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Name. Effective May 1, 2015, each CA SHALL revoke all unexpired Certificates with an Internal Name using onion as the right-most label in an entry in the subjectAltName Extension or commonName field unless such Certificate was issued in accordance with Appendix F of the EV Guidelines. 2) Amend Section 9.2.2 and 11.7.1 of the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2 as follows: 9.2.2. Subject Alternative Name Extension Certificate field: subjectAltName:dNSName Required/Optional: Required Contents: This extension MUST contain one or more host Domain Name(s) owned or controlled by the Subject and to be associated with the Subject's server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). Wildcard certificates are not allowed for EV Certificates except as permitted under Appendix F. 11.7 Verification of Applicant's Domain Name 11.7.1. Verification Requirements (1) For each Fully-Qualified Domain Name listed in a Certificate, other than a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant (or the Applicant's Parent Company, Subsidiary Company, or Affiliate, collectively referred to as "Applicant" for the purposes of this section) either is the Domain Name Registrant or has control over the FQDN using a procedure specified in Section 11.1.1 of the Baseline Requirements, except that a CA MAY NOT verify a domain using the procedure described 11.1.1(7). For a Certificate issued to a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant's control over the .onion Domain Name in accordance with Appendix F. (2) Mixed Character Set Domain Names: EV Certificates MAY include Domain Names containing mixed character sets only in compliance with the rules set forth by the domain registrar. The CA MUST visually compare any Domain Names with mixed character sets with known high risk domains. If a similarity is found, then the EV Certificate Request MUST be flagged as High Risk. The CA must perform reasonably appropriate additional authentication and verification to be certain beyond reasonable doubt that the Applicant and the target in question are the same organization. 3) Add a new Appendix F to the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2: Appendix F - Issuance of Certificates for .onion Domain Names A CA may issue an EV Certificate with .onion in the right-most label of the Domain Name provided that issuance complies with the requirements set forth in this Appendix: 1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) The CAB Forum has created an extension of the TBSCertificate for use in conveying hashes of keys related to .onion addresses. The Tor Service Descriptor Hash extension has the following format: cabf-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 } TorServiceDescriptorSyntax ::= SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash TorServiceDescriptorHash:: = SEQUENCE { onionURI UTF8String algorithm AlgorithmIdentifier subjectPublicKeyHash BIT STRING } Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 6234) performed over the DER-encoding of an ASN.1 SubjectPublicKey of the .onion service and SubjectPublicKeyHash is the hash output. 2. The CA MUST verify the Applicant's control over the .onion Domain Name using one of the following: a. The CA MAY verify the Applicant's control over the .onion service by posting a specific value at a well-known URL under RFC5785. b. The CA MAY verify the Applicant's control over the .onion service by having the Applicant provide a Certificate Request signed using the .onion public key if the Attributes section of the certificationRequestInfo contains: (i) A caSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy, 2) is generated by the CA, and 3) delivered to the Applicant through a Verified Method of Communication and (ii) An applicantSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy and 2) is generated by the Applicant. The signing nonce attributes have the following format: caSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-caSigningNonce } } cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } applicantSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-applicantSigningNonce } } cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 } 4. Each Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name MUST conform to the requirements of these Guidelines, including the content requirements in Section 9 and Appendix B of the Baseline Requirements, except that the CA MAY include a wildcard character in the Subject Alternative Name Extension and Subject Common Name Field as the left-most character in the .onion Domain Name provided inclusion of the wildcard character complies with Section 11.1.3 of the Baseline Requirements. 5. CAs MUST NOT issue a Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name with a validity period longer than 15 months. Despite Section 9.2.1 of the Baseline Requirements deprecating the use of Internal Names, a CA MAY issue a Certificate containing an .onion name with an expiration date later than 1 November 2015 after (and only if) .onion is officially recognized by the IESG as a reserved TLD. 6. On or before May 1, 2015, each CA MUST revoke all Certificates issued with the Subject Alternative Name extension or Common Name field that includes a Domain Name where .onion is in the right-most label of the Domain Name unless the Certificate was issued in compliance with this Appendix F. ---- Motion Ends ----- The review period for this ballot shall commence at 2200 UTC on Thursday, 4 February 2015, and will close at 2200 UTC on Thursday, 11 February 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on Monday, 18 February 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150210/aaa0f384/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4954 bytes Desc: not available Url : https://cabforum.org/pipermail/public/attachments/20150210/aaa0f384/attachment-0001.bin From jodycl at microsoft.com Tue Feb 10 16:32:19 2015 From: jodycl at microsoft.com (Jody Cloutier) Date: Tue, 10 Feb 2015 23:32:19 +0000 Subject: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc In-Reply-To: <763539E260C37C46A0D6B340B5434C3B0ACD81A9@AEX06.ejsarea.net> References: <763539E260C37C46A0D6B340B5434C3B0ACD81A9@AEX06.ejsarea.net> Message-ID: Thank you, Inigo. I think the problem is that, under ETSI, it's difficult to discern what an "equivalent national scheme" is. This sets up the scenario in which an auditor is employed by an organization that is recognized somehow by the government, but is not affiliated with an ETSI member organization (http://www.european-accreditation.org/home ). Microsoft does not know whether or not this auditor is qualified or not. For example, ? Company A is a commercial CA that operates in Israel ? Auditor Jones works for AuditCo, which is based in Israel ? AuditCo is certified by some governmental agency as a qualified auditor ? AuditCo is not an ETSI Member or Associate Member ? Auditor Jones audits Company A using the ETSI 102042 standard, and Company A sends the auditor's attestation letter to Microsoft as evidence that Company A complied with the Program's requirements. In this scenario, how does Microsoft know that Auditor Jones conducted a proper audit without expending significant resources to determine whether and according to what standard AuditCo and Auditor Jones was certified? Microsoft believes that it would be simpler if the requirements were that the Auditor must work for a company that is affiliated with an ETSI-approved member organization. If Company A needs an auditor and there is no qualified auditor in Israel, the company can use an auditor from a member organization via the cross-border conformity rules. Unless I am fundamentally misunderstanding the rules, the above is something that Microsoft is presently struggling with, and we'd like to try to make the rules easier to understand for potential partners and ourselves. Jody Cloutier Senior Security Program Manager Microsoft Trusted Root Certificate Program jody.cloutier at microsoft.com 425.443.8922 Operating Systems Group Global Risk and Compliance [https://brandtools.microsoft.com/Style%20Library/BT/Images/MicrosoftMasterLogo.png] From: i-barreira at izenpe.net [mailto:i-barreira at izenpe.net] Sent: Tuesday, February 10, 2015 3:09 AM To: Jody Cloutier; public at cabforum.org Subject: RE: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Hi Jody, Regarding your comment on ETSI audits, I have to say that the ETSI audits shall be performed by accredited auditors as mentioned in Annex E of the current ETSI TS 102 042. ETSI audits performed by not accredited auditors shall be considered invalid. Microsoft is accepting ETSI audits since the very beginning in its root program requirements indicating this requirement. ETSI is providing a list of accredited auditors as mere information because has to be maintained by every NAB (National Accreditation Body). It?s true that this has to be improved regarding the new regulation 910/2014 and the new ENs and will take some time, but at the moment, it?s clearly stated that the audits shall be performed by accredited auditors. Don?t hesitate in contacting me for any additional information or help. Sometimes I?ve received some emails from Tom or Kelvin asking for the qualification of some audits, so, as say, you can contact me regarding this issue. Regards I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 [Descripci?n: cid:image001.png at 01CE3152.B4804EB0] ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. De: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] En nombre de Jody Cloutier Enviado el: lunes, 09 de febrero de 2015 18:55 Para: CABFPub (public at cabforum.org) Asunto: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Microsoft comments on Section 17. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150210/26159507/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 19121 bytes Desc: image001.png Url : https://cabforum.org/pipermail/public/attachments/20150210/26159507/attachment-0002.png -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 1181 bytes Desc: image002.png Url : https://cabforum.org/pipermail/public/attachments/20150210/26159507/attachment-0003.png From haavardm at opera.com Wed Feb 11 07:32:07 2015 From: haavardm at opera.com (haavardm at work) Date: Wed, 11 Feb 2015 15:32:07 +0100 Subject: [cabfpub] Not coming to Switzerland in June :-( In-Reply-To: <54D38C40.90005@mozilla.org> References: <54D38C40.90005@mozilla.org> Message-ID: Hi Gerv, Depending on a few internal factors, we are considering sending one representative to the Switzerland meeting. If so, either me or Sigbj?rn will attend. Cheers, H?vard On Thu, Feb 5, 2015 at 4:29 PM, Gervase Markham wrote: > Dear CAB Forum members, > > Unfortunately, Mozilla has scheduled a get-together the same week as the > CAB Forum meeting in Switzerland at the end of June, so I will not be > able to make it, or to dial in, and it's unlikely that any other Mozilla > representative would be able to either. > > I don't want to have delusions of my own importance, but it has been > noted before that it's important to have browser participation in > face-to-face meetings. I also note that our friends at Google and Opera > have not been attending in person recently, with their last attendances > being: > > Opera: Meeting 30 (Sep 2013) > Google: Meeting 28 (Feb 2013) > > Hence, I thought I'd note our planned absence so that if Microsoft were > not planning to send anyone (and neither were Google or Opera), we could > at least discuss whether the CAs in the group would prefer to meet > alone, or would prefer to investigate an alternative week (by > arrangement with our gracious hosts). > > Ryan? Jody? Sigbjorn? > > Gerv > _______________________________________________ > 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/20150211/93bfa17f/attachment.html From ben.wilson at digicert.com Wed Feb 11 14:21:37 2015 From: ben.wilson at digicert.com (Ben Wilson) Date: Wed, 11 Feb 2015 21:21:37 +0000 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names In-Reply-To: <5c04557077cf4564979bc37e501297de@EX2.corp.digicert.com> References: <5c04557077cf4564979bc37e501297de@EX2.corp.digicert.com> Message-ID: <3ff9a59417eb41ff98aed77794f075e2@EX2.corp.digicert.com> I've posted the ballot here - https://cabforum.org/2015/02/11/ballot-144-validation-rules-dot-onion-names/ Voting begins in 40 minutes and lasts for 7 days. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ben Wilson Sent: Tuesday, February 10, 2015 2:02 PM To: public at cabforum.org Subject: Re: [cabfpub] Ballot 144 - Validation rules for .onion names I'll post this to the public page with a correction stating that the review period ends and the voting period of the ballot begins to run from Wednesday, 11 Feb., to Wednesday, 18 Feb. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Tuesday, February 10, 2015 11:39 AM To: public at cabforum.org Subject: [cabfpub] Ballot 144 - Validation rules for .onion names Here's the ballot with the two typos fixed: Applicants want a CA-signed .onion address for several reasons, including: - Powerful web platform features are restricted to secure origins, which are currently not available to onion names (in part, because of the lack of IANA registration). Permitting EV certs for onion names will help provide a secure origin for the service, moving onion towards use of powerful web platform features. - Currently, access to .onion names over https from a standard browser results in the standard existing 'Invalid Certificate' warning. Training users to click through security warnings lowers the value of these warnings and will cause users to miss important security information. Removing these warnings for the user, through use of a digital certificate, will help users recognize and avoid real MITM attacks. - The public needs attribution of ownership of the .onion address to differentiate onion services, including potential phishing services. Because onion names are not easily recognizable strings, providing the public with additional information about the operator has significant security improvements, especially in regions where use of the incorrect name could have lethal consequences. The following motion has been proposed by Jeremy Rowley of DigiCert and endorsed by Ryan Sleevi of Google and Wayne Thayer of GoDaddy. --------------------- Motion Starts --------------------- 1) Amend Section 9.2.1 of the Baseline Requirements v. 1.2.3 as follows: 9.2.1 Subject Alternative Name Extension Certificate Field: extensions:subjectAltName Required/Optional: Required Contents: This 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. The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate. Wildcard FQDNs are permitted. As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name, the CA SHALL notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016. Also as of the Effective Date, the CA SHALL NOT issue a certificate with an Expiry Date later than 1 November 2015 with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name. Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Name. Effective May 1, 2015, each CA SHALL revoke all unexpired Certificates with an Internal Name using onion as the right-most label in an entry in the subjectAltName Extension or commonName field unless such Certificate was issued in accordance with Appendix F of the EV Guidelines. 2) Amend Section 9.2.2 and 11.7.1 of the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2 as follows: 9.2.2. Subject Alternative Name Extension Certificate field: subjectAltName:dNSName Required/Optional: Required Contents: This extension MUST contain one or more host Domain Name(s) owned or controlled by the Subject and to be associated with the Subject's server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). Wildcard certificates are not allowed for EV Certificates except as permitted under Appendix F. 11.7 Verification of Applicant's Domain Name 11.7.1. Verification Requirements (1) For each Fully-Qualified Domain Name listed in a Certificate, other than a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant (or the Applicant's Parent Company, Subsidiary Company, or Affiliate, collectively referred to as "Applicant" for the purposes of this section) either is the Domain Name Registrant or has control over the FQDN using a procedure specified in Section 11.1.1 of the Baseline Requirements, except that a CA MAY NOT verify a domain using the procedure described 11.1.1(7). For a Certificate issued to a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant's control over the .onion Domain Name in accordance with Appendix F. (2) Mixed Character Set Domain Names: EV Certificates MAY include Domain Names containing mixed character sets only in compliance with the rules set forth by the domain registrar. The CA MUST visually compare any Domain Names with mixed character sets with known high risk domains. If a similarity is found, then the EV Certificate Request MUST be flagged as High Risk. The CA must perform reasonably appropriate additional authentication and verification to be certain beyond reasonable doubt that the Applicant and the target in question are the same organization. 3) Add a new Appendix F to the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2: Appendix F - Issuance of Certificates for .onion Domain Names A CA may issue an EV Certificate with .onion in the right-most label of the Domain Name provided that issuance complies with the requirements set forth in this Appendix: 1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) The CAB Forum has created an extension of the TBSCertificate for use in conveying hashes of keys related to .onion addresses. The Tor Service Descriptor Hash extension has the following format: cabf-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 } TorServiceDescriptorSyntax ::= SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash TorServiceDescriptorHash:: = SEQUENCE { onionURI UTF8String algorithm AlgorithmIdentifier subjectPublicKeyHash BIT STRING } Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 6234) performed over the DER-encoding of an ASN.1 SubjectPublicKey of the .onion service and SubjectPublicKeyHash is the hash output. 2. The CA MUST verify the Applicant's control over the .onion Domain Name using one of the following: a. The CA MAY verify the Applicant's control over the .onion service by posting a specific value at a well-known URL under RFC5785. b. The CA MAY verify the Applicant's control over the .onion service by having the Applicant provide a Certificate Request signed using the .onion public key if the Attributes section of the certificationRequestInfo contains: (i) A caSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy, 2) is generated by the CA, and 3) delivered to the Applicant through a Verified Method of Communication and (ii) An applicantSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy and 2) is generated by the Applicant. The signing nonce attributes have the following format: caSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-caSigningNonce } } cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } applicantSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-applicantSigningNonce } } cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 } 4. Each Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name MUST conform to the requirements of these Guidelines, including the content requirements in Section 9 and Appendix B of the Baseline Requirements, except that the CA MAY include a wildcard character in the Subject Alternative Name Extension and Subject Common Name Field as the left-most character in the .onion Domain Name provided inclusion of the wildcard character complies with Section 11.1.3 of the Baseline Requirements. 5. CAs MUST NOT issue a Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name with a validity period longer than 15 months. Despite Section 9.2.1 of the Baseline Requirements deprecating the use of Internal Names, a CA MAY issue a Certificate containing an .onion name with an expiration date later than 1 November 2015 after (and only if) .onion is officially recognized by the IESG as a reserved TLD. 6. On or before May 1, 2015, each CA MUST revoke all Certificates issued with the Subject Alternative Name extension or Common Name field that includes a Domain Name where .onion is in the right-most label of the Domain Name unless the Certificate was issued in compliance with this Appendix F. ---- Motion Ends ----- The review period for this ballot shall commence at 2200 UTC on Thursday, 4 February 2015, and will close at 2200 UTC on Thursday, 11 February 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on Monday, 18 February 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150211/2e1e63d0/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4954 bytes Desc: not available Url : https://cabforum.org/pipermail/public/attachments/20150211/2e1e63d0/attachment-0001.bin From arno.fiedler at nimbus-berlin.com Thu Feb 12 01:44:33 2015 From: arno.fiedler at nimbus-berlin.com (Arno Fiedler) Date: Thu, 12 Feb 2015 09:44:33 +0100 Subject: [cabfpub] CA-Day in Berlin on 09.06.15 In-Reply-To: References: <54D93D27.6020807@cacert.org> Message-ID: <54DC67F1.7030209@nimbus-berlin.com> Hello, please save the date: TSP Compliance Info-Day "eIDAS and Trust Service Provider Conformity Assessment" Organizer: T?VIT, Bundesdruckerei, Date: Tuesday, 09.06.2015 from 10:00 AM to 05:00 PM Venue: T?VIT at Microsoft Berlin, Unter den Linden Best regards Arno Fiedler -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150212/62aecdfb/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: arno_fiedler.vcf Type: text/x-vcard Size: 302 bytes Desc: not available Url : https://cabforum.org/pipermail/public/attachments/20150212/62aecdfb/attachment.vcf From kirk_hall at trendmicro.com Thu Feb 12 13:43:36 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Thu, 12 Feb 2015 20:43:36 +0000 Subject: [cabfpub] Ballot 144 -.onion domains Message-ID: Jeremy and Ben - sorry we didn't ask these questions last week, but I was travelling and didn't realize the comment period had begun. (1) We are concerned that under Ballot 144 there could be two .onion certs with the SAME domain but identifying two DIFFERENT subjects. For example, Evil Corp. and Angel Corp. could each submit a request for a .onion cert and get the same domain: [same 16 digit hash of their public keys].onion if their public keys hash to the same value. One cert would say O=Evil Corp. the other would say O=Angel Corp., so that a .onion domain would not be uniquely identified with one subject. While unlikely, it could happen. How does Tor resolve this if the same .onion domain is assigned to multiple, different subjects? If someone types in [16 digit hash].onion and that could lead to multiple Tor locations, how does Tor decide where to direct the user? (2) Does this also create an opportunity for a hacker? For example, one of the .onion domains in the SANs field of the Facebook cert you created is *.xx.fbcdn23dssr3jqnq.onion - could a hacker create a public key that would hash to the same value in order to get a cert with the same .onion domain and imitate the Facebook cert? (This is maybe the more serious case.) (3) Another concern is there is no central registry to identify the owner of a .onion domain (of course, there could be multiple owners of the domain under the scenario above). If there is no Subject info in the O field, etc., with no registry there is no real way to contact the domain (or cert owner). Any information you can provide on these point will be very helpful. 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
-------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150212/ad95660d/attachment.html From kirk_hall at trendmicro.com Thu Feb 12 13:45:45 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Thu, 12 Feb 2015 20:45:45 +0000 Subject: [cabfpub] Ballot 144 -.onion domains Message-ID: Here are screen shots of the Facebook.com cert, if anyone hasn't seen it. The .onion domains are in the second shot in the SANs field. [cid:image001.png at 01D046C1.D1682440] [cid:image002.png at 01D046C1.D1682440] From: Kirk Hall (RD-US) Sent: Thursday, February 12, 2015 12:44 PM To: Jeremy Rowley (jeremy.rowley at digicert.com); Ben Wilson (Ben.Wilson at digicert.com) Cc: CABFPub (public at cabforum.org) Subject: Ballot 144 -.onion domains Jeremy and Ben - sorry we didn't ask these questions last week, but I was travelling and didn't realize the comment period had begun. (1) We are concerned that under Ballot 144 there could be two .onion certs with the SAME domain but identifying two DIFFERENT subjects. For example, Evil Corp. and Angel Corp. could each submit a request for a .onion cert and get the same domain: [same 16 digit hash of their public keys].onion if their public keys hash to the same value. One cert would say O=Evil Corp. the other would say O=Angel Corp., so that a .onion domain would not be uniquely identified with one subject. While unlikely, it could happen. How does Tor resolve this if the same .onion domain is assigned to multiple, different subjects? If someone types in [16 digit hash].onion and that could lead to multiple Tor locations, how does Tor decide where to direct the user? (2) Does this also create an opportunity for a hacker? For example, one of the .onion domains in the SANs field of the Facebook cert you created is *.xx.fbcdn23dssr3jqnq.onion - could a hacker create a public key that would hash to the same value in order to get a cert with the same .onion domain and imitate the Facebook cert? (This is maybe the more serious case.) (3) Another concern is there is no central registry to identify the owner of a .onion domain (of course, there could be multiple owners of the domain under the scenario above). If there is no Subject info in the O field, etc., with no registry there is no real way to contact the domain (or cert owner). Any information you can provide on these point will be very helpful. 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
-------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150212/2e69ba75/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 49635 bytes Desc: image001.png Url : https://cabforum.org/pipermail/public/attachments/20150212/2e69ba75/attachment-0002.png -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 51544 bytes Desc: image002.png Url : https://cabforum.org/pipermail/public/attachments/20150212/2e69ba75/attachment-0003.png From sleevi at google.com Thu Feb 12 14:01:58 2015 From: sleevi at google.com (Ryan Sleevi) Date: Thu, 12 Feb 2015 13:01:58 -0800 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: References: Message-ID: On Feb 12, 2015 12:43 PM, "kirk_hall at trendmicro.com" < kirk_hall at trendmicro.com> wrote: > > Jeremy and Ben ? sorry we didn?t ask these questions last week, but I was travelling and didn?t realize the comment period had begun. > > > > (1) We are concerned that under Ballot 144 there could be two .onion certs with the SAME domain but identifying two DIFFERENT subjects. > > > > For example, Evil Corp. and Angel Corp. could each submit a request for a .onion cert and get the same domain: [same 16 digit hash of their public keys].onion if their public keys hash to the same value. One cert would say O=Evil Corp. the other would say O=Angel Corp., so that a .onion domain would not be uniquely identified with one subject. While unlikely, it could happen. > > > > How does Tor resolve this if the same .onion domain is assigned to multiple, different subjects? If someone types in [16 digit hash].onion and that could lead to multiple Tor locations, how does Tor decide where to direct the user? > > Hi Kirk, While not Jeremy, this is actually why I suggested that the full public key be included within the issued certificate itself, so as to highlight any hash collision attempts on the onion private key (e.g. by funkily encoding key parameters or by using key confusion). On a practical level, it's far out there from the realm of being feasible, but it's enough of an issue that I felt important that this should be included in the issued cert, so that sites could use, for example, certificate transparency to monitor for such things. On the TOR side, the protocol is being revved to deal with this, but it is described more at https://trac.torproject.org/projects/tor/wiki/doc/HiddenServiceNames So from the issuance side, the mitigations are including the full public key as well as requiring the EV validation, rather than DV. > > (2) Does this also create an opportunity for a hacker? For example, one of the .onion domains in the SANs field of the Facebook cert you created is *.xx.fbcdn23dssr3jqnq.onion ? could a hacker create a public key that would hash to the same value in order to get a cert with the same .onion domain and imitate the Facebook cert? (This is maybe the more serious case.) > Isn't this a restatement of 1? Or at least, the answers there would still apply. > (3) Another concern is there is no central registry to identify the owner of a .onion domain (of course, there could be multiple owners of the domain under the scenario above). If there is no Subject info in the O field, etc., with no registry there is no real way to contact the domain (or cert owner). > I'm not entirely sure I follow? Note during the discussion phase also included discussion about requiring one or more DNS names from the IANA zone as well, which seems like it would mitigate this concern. > > > Any information you can provide on these point will be very helpful. > I think it is important when considering these that, as of today, any CA can issue any name under .onion under the "Internal Names" exception. This proposal merely restricts it from being "any rules you want" to "more stringent verification required" It still treats .onion as an internal name, in as much as they still sunset and must be revoked. If this ballot fails, every CA will still be able to issue .onion names to any party they wish, including parties who have no relationship whatsoever to the onion HS. That is, if this fails, there is no requirement for attackers to execute a hash collision or factor a private key - they just need to find a CA willing to issue under the "Internal Names" rule (which, as you know, is typically validated at a level less than EV, such as OV). That's why I think this ballot is good - it doesn't prolong or extend risk, it actually _restricts_ issuance in this space until internal names are sunset, at which point, no more of these certs will be issued, no matter the rules. In practice, I expect discussion and standardization to continue, and we may see DigiCert issue a ballot in half a year that looks to extend such issuance, but that's not this ballot, thankfully, so we don't have to solve all of these issues right away. > > > > > TREND MICRO EMAIL NOTICE > The information contained in this email and any attachments is confidential > and may be subject to copyright or other intellectual property protection. > If you are not the intended recipient, you are not authorized to use or > disclose this information, and we request that you notify us by reply mail or > telephone and delete the original message from your mail system. > > > _______________________________________________ > 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/20150212/e49ec60e/attachment.html From gerv at mozilla.org Thu Feb 12 14:41:01 2015 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 12 Feb 2015 21:41:01 +0000 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: References: Message-ID: <54DD1DED.4090105@mozilla.org> On 12/02/15 20:43, kirk_hall at trendmicro.com wrote: > For example, Evil Corp. and Angel Corp. could each submit a request for > a .onion cert and get the same domain: _[same 16 digit hash of their > public keys].onion_ if their public keys hash to the same value. One > cert would say O=Evil Corp. the other would say O=Angel Corp., so that a > .onion domain would not be uniquely identified with one subject. While > unlikely, it could happen. Have you been able to put a figure on the likelihood of this occurrence? I think I could calculate it, but I'm interested in what figure you came up with that led to your concern. > (2) Does this also create an opportunity for a hacker? For example, > one of the .onion domains in the SANs field of the Facebook cert you > created is _*.xx.fbcdn23dssr3jqnq.onion_ ? could a hacker create a > public key that would hash to the same value in order to get a cert with > the same .onion domain and imitate the Facebook cert? (This is maybe > the more serious case.) Being able to create some text which hashes to a specific, defined value that you are targetting would be what's called a Preimage attack: http://en.wikipedia.org/wiki/Preimage_attack SHA-1 has no known preimage attacks. Tor .onion names use 80 bits of the SHA-1 hash, which is not the full hash, so it's possible that they might be slightly easier to attack. While there are no known attacks, my understanding is that the Tor people are looking at moving to SHA-256 as a precautionary measure. > (3) Another concern is there is no central registry to identify the > owner of a .onion domain (of course, there could be multiple owners of > the domain under the scenario above). If there is no Subject info in > the O field, etc., with no registry there is no real way to contact the > domain (or cert owner). .onion certs are going to be EV, right? So they would have Subject info in the O field. Gerv From Dean_Coclin at symantec.com Thu Feb 12 15:04:09 2015 From: Dean_Coclin at symantec.com (Dean Coclin) Date: Thu, 12 Feb 2015 14:04:09 -0800 Subject: [cabfpub] Voting period: Ballots 143 and 144 Message-ID: <14D026C7F297AD44AC82578DD818CDD038EF1E9E65@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> Just a reminder that the voting period is underway for Ballots 143 (Validation Working Group) and 144 (.onion) and closes on February 18th. Dean -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150212/ad4fd525/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6130 bytes Desc: not available Url : https://cabforum.org/pipermail/public/attachments/20150212/ad4fd525/attachment-0001.bin From kirk_hall at trendmicro.com Thu Feb 12 15:18:35 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Thu, 12 Feb 2015 22:18:35 +0000 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: <54DD1DED.4090105@mozilla.org> References: <54DD1DED.4090105@mozilla.org> Message-ID: Responding both the Ryan and Gerv. Ryan -- you are correct that concerns (1) and (2) are related -- (1) relates to accidental clashes that give different customers the same domain. Gerv -- you are right, the change is extremely small -- but giving the same domain to different customers is something not allowed today, so it would be quite a change to allow it. This link has some information on the subject, but I really don?t understand the explanation of why clashes aren?t a concern. https://trac.torproject.org/projects/tor/wiki/doc/HiddenServiceNames On (2) ? this concern is of an intentional clash created by a hacker for evil purpose ? a much more serious issue. I notice that in Facebook?s existing .onion cert, they managed to get the following .onion domain: *.m.facebookcorewwwi.onion See screen shot below or attached. I?m sure that didn?t happen randomly, so there must have been some very serious computing that happened to get that particular 16 digit ?random? hash of a Facebook public key, facebookcorewwwi. If Facebook can reverse engineer to get that .onion domain, couldn?t a hacker (or googlegoogle.onion, for another example) do the same and get a duplicate cert with the same domain? [cid:image001.png at 01D046CE.C86B58F0] -----Original Message----- From: Gervase Markham [mailto:gerv at mozilla.org] Sent: Thursday, February 12, 2015 1:41 PM To: Kirk Hall (RD-US); Jeremy Rowley (jeremy.rowley at digicert.com); Ben Wilson (Ben.Wilson at digicert.com) Cc: CABFPub (public at cabforum.org) Subject: Re: [cabfpub] Ballot 144 -.onion domains On 12/02/15 20:43, kirk_hall at trendmicro.com wrote: > For example, Evil Corp. and Angel Corp. could each submit a request > for a .onion cert and get the same domain: _[same 16 digit hash of > their public keys].onion_ if their public keys hash to the same value. > One cert would say O=Evil Corp. the other would say O=Angel Corp., so > that a .onion domain would not be uniquely identified with one > subject. While unlikely, it could happen. Have you been able to put a figure on the likelihood of this occurrence? I think I could calculate it, but I'm interested in what figure you came up with that led to your concern. > (2) Does this also create an opportunity for a hacker? For example, > one of the .onion domains in the SANs field of the Facebook cert you > created is _*.xx.fbcdn23dssr3jqnq.onion_ ? could a hacker create a > public key that would hash to the same value in order to get a cert > with the same .onion domain and imitate the Facebook cert? (This is > maybe the more serious case.) Being able to create some text which hashes to a specific, defined value that you are targetting would be what's called a Preimage attack: http://en.wikipedia.org/wiki/Preimage_attack SHA-1 has no known preimage attacks. Tor .onion names use 80 bits of the SHA-1 hash, which is not the full hash, so it's possible that they might be slightly easier to attack. While there are no known attacks, my understanding is that the Tor people are looking at moving to SHA-256 as a precautionary measure. > (3) Another concern is there is no central registry to identify the > owner of a .onion domain (of course, there could be multiple owners of > the domain under the scenario above). If there is no Subject info in > the O field, etc., with no registry there is no real way to contact > the domain (or cert owner). .onion certs are going to be EV, right? So they would have Subject info in the O field. Gerv 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
-------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150212/96755d93/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 51544 bytes Desc: image001.png Url : https://cabforum.org/pipermail/public/attachments/20150212/96755d93/attachment-0001.png From gerv at mozilla.org Thu Feb 12 15:26:38 2015 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 12 Feb 2015 22:26:38 +0000 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: References: <54DD1DED.4090105@mozilla.org> Message-ID: <54DD289E.8040304@mozilla.org> Hi Kirk, On 12/02/15 22:18, kirk_hall at trendmicro.com wrote: > Ryan -- you are correct that concerns (1) and (2) are related -- (1) > relates to accidental clashes that give different customers the same > domain. Gerv -- you are right, the change is extremely small -- but > giving the same domain to different customers is something not allowed > today, so it would be quite a change to allow it. How unlikely would it need to be for you not to use the word "allow"? At the moment, it's possible for two different customers to generate the same public/private key pair, and so they would be able to impersonate each other. But, assuming there's no flaws in the RNG, it is pretty unlikely. Would you say that the CAB Forum "allows" this? > This link has some information on the subject, but I really don?t > understand the explanation of why clashes aren?t a concern. > > https://trac.torproject.org/projects/tor/wiki/doc/HiddenServiceNames Yes, I'm not sure I understand that either. Ryan? > On (2) ? this concern is of an intentional clash created by a hacker for > evil purpose ? a much more serious issue. I notice that in Facebook?s > existing .onion cert, they managed to get the following .onion domain: > > *.m.facebookcorewwwi.onion > > I?m sure that didn?t happen randomly, so there must have been some very > serious computing that happened to get that particular 16 digit ?random? > hash of a Facebook public key, _facebookcorewwwi_. Yes, it did. Facebook are on record as saying that they threw a lot of computing power at the problem, and then reviewed all the options generated which started with "facebook" and picked the one they liked best. The engineer said something like: "I feel we were very lucky in generating a good name." I rather wish they hadn't, actually, because it confuses people into thinking it's possible to just pick a good name and use it, which it isn't. > If Facebook can > reverse engineer to get that .onion domain, couldn?t a hacker (or > googlegoogle.onion, for another example) do the same and get a duplicate > cert with the same domain? No. What Facebook did was generate a lot of hashes starting "facebook", reviewed them, picked the one they liked best and then invented a "reason" for why it's that one: "Facebook's Core WWW Infrastructure". However, generating a second one which exactly matched the name Facebook picked is a much harder process. Gerv From kirk_hall at trendmicro.com Thu Feb 12 15:26:40 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Thu, 12 Feb 2015 22:26:40 +0000 Subject: [cabfpub] Ballot 143 - Formalization of validation working group Message-ID: Trend Micro votes yes. Kirk R. Hall Operations Director, Trust Services Trend Micro +1.503.753.3088 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
-------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150212/96882de0/attachment.html From THollebeek at trustwave.com Thu Feb 12 15:33:23 2015 From: THollebeek at trustwave.com (Tim Hollebeek) Date: Thu, 12 Feb 2015 22:33:23 +0000 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: References: <54DD1DED.4090105@mozilla.org> Message-ID: The 40-bit attack only applies in a scenario like the following: 1. I generate 2^40 RSA key pairs. I now (probably) have two RSA key pairs with the same 80-bit URL. 2. I convince someone to use one of the two as their hidden service name I now have a second RSA key pair that can masquerade as the first. But that?s not horribly useful to me, as I also have the first key pair as well! I can convince them to use the key I generated (#2), without having to first generate a collision, and achieve the same result. There is an actual issue (the pre-image attack), where I just generate key pairs until I do collide, but: 1. That?s 2^80 / #hiddenservices key pairs. That?s a lot. 2. I have no control over which hidden service I accidentally collide with. If hidden services become widely used and there are lots of them, this conceivably becomes an issues sometime in the future, which is why I expressed concern about it on the management call. It really is time for the Tor folks to fix this before it becomes a problem. But the existing state of the .onion world is so bad, that allowing EV certificates and HTTPS for Tor is a significant improvement. The size and potential weakness of the onion hashes merit continuing attention, and perhaps a timeline to phase them out, but they?re not a practical attack today. -Tim From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of kirk_hall at trendmicro.com Sent: Thursday, February 12, 2015 5:19 PM To: Gervase Markham; Jeremy Rowley (jeremy.rowley at digicert.com); Ben Wilson (Ben.Wilson at digicert.com) Cc: CABFPub (public at cabforum.org) Subject: Re: [cabfpub] Ballot 144 -.onion domains Responding both the Ryan and Gerv. Ryan -- you are correct that concerns (1) and (2) are related -- (1) relates to accidental clashes that give different customers the same domain. Gerv -- you are right, the change is extremely small -- but giving the same domain to different customers is something not allowed today, so it would be quite a change to allow it. This link has some information on the subject, but I really don?t understand the explanation of why clashes aren?t a concern. https://trac.torproject.org/projects/tor/wiki/doc/HiddenServiceNames On (2) ? this concern is of an intentional clash created by a hacker for evil purpose ? a much more serious issue. I notice that in Facebook?s existing .onion cert, they managed to get the following .onion domain: *.m.facebookcorewwwi.onion See screen shot below or attached. I?m sure that didn?t happen randomly, so there must have been some very serious computing that happened to get that particular 16 digit ?random? hash of a Facebook public key, facebookcorewwwi. If Facebook can reverse engineer to get that .onion domain, couldn?t a hacker (or googlegoogle.onion, for another example) do the same and get a duplicate cert with the same domain? [cid:image001.png at 01D046E8.B2667340] -----Original Message----- From: Gervase Markham [mailto:gerv at mozilla.org] Sent: Thursday, February 12, 2015 1:41 PM To: Kirk Hall (RD-US); Jeremy Rowley (jeremy.rowley at digicert.com); Ben Wilson (Ben.Wilson at digicert.com) Cc: CABFPub (public at cabforum.org) Subject: Re: [cabfpub] Ballot 144 -.onion domains On 12/02/15 20:43, kirk_hall at trendmicro.com wrote: > For example, Evil Corp. and Angel Corp. could each submit a request > for a .onion cert and get the same domain: _[same 16 digit hash of > their public keys].onion_ if their public keys hash to the same value. > One cert would say O=Evil Corp. the other would say O=Angel Corp., so > that a .onion domain would not be uniquely identified with one > subject. While unlikely, it could happen. Have you been able to put a figure on the likelihood of this occurrence? I think I could calculate it, but I'm interested in what figure you came up with that led to your concern. > (2) Does this also create an opportunity for a hacker? For example, > one of the .onion domains in the SANs field of the Facebook cert you > created is _*.xx.fbcdn23dssr3jqnq.onion_ ? could a hacker create a > public key that would hash to the same value in order to get a cert > with the same .onion domain and imitate the Facebook cert? (This is > maybe the more serious case.) Being able to create some text which hashes to a specific, defined value that you are targetting would be what's called a Preimage attack: http://en.wikipedia.org/wiki/Preimage_attack SHA-1 has no known preimage attacks. Tor .onion names use 80 bits of the SHA-1 hash, which is not the full hash, so it's possible that they might be slightly easier to attack. While there are no known attacks, my understanding is that the Tor people are looking at moving to SHA-256 as a precautionary measure. > (3) Another concern is there is no central registry to identify the > owner of a .onion domain (of course, there could be multiple owners of > the domain under the scenario above). If there is no Subject info in > the O field, etc., with no registry there is no real way to contact > the domain (or cert owner). .onion certs are going to be EV, right? So they would have Subject info in the O field. Gerv TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. ________________________________ This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150212/7d18c61c/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 51544 bytes Desc: image001.png Url : https://cabforum.org/pipermail/public/attachments/20150212/7d18c61c/attachment-0001.png From jeremy.rowley at digicert.com Thu Feb 12 17:58:58 2015 From: jeremy.rowley at digicert.com (Jeremy Rowley) Date: Fri, 13 Feb 2015 00:58:58 +0000 Subject: [cabfpub] Ballot 143 - Formalization of validation working group In-Reply-To: References: Message-ID: <608ba22f4b5d42ec9926ed95d6548299@EX2.corp.digicert.com> DigiCert votes yes From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of kirk_hall at trendmicro.com Sent: Thursday, February 12, 2015 3:27 PM To: CABFPub (public at cabforum.org) Subject: [cabfpub] Ballot 143 - Formalization of validation working group Trend Micro votes yes. Kirk R. Hall Operations Director, Trust Services Trend Micro +1.503.753.3088 TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150213/aaf159dc/attachment.html From jeremy.rowley at digicert.com Thu Feb 12 18:14:01 2015 From: jeremy.rowley at digicert.com (Jeremy Rowley) Date: Fri, 13 Feb 2015 01:14:01 +0000 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: References: Message-ID: <50b4fdabaa7a4c7e9d1c3b962071f9af@EX2.corp.digicert.com> One caveat is that another ballot is not required if the IESG officially recognizes .onion a reserved name. From: Ryan Sleevi [mailto:sleevi at google.com] Sent: Thursday, February 12, 2015 2:02 PM To: kirk_hall at trendmicro.com Cc: Jeremy Rowley; CABFPub; Ben Wilson Subject: Re: [cabfpub] Ballot 144 -.onion domains On Feb 12, 2015 12:43 PM, "kirk_hall at trendmicro.com" > wrote: > > Jeremy and Ben ? sorry we didn?t ask these questions last week, but I was travelling and didn?t realize the comment period had begun. > > > > (1) We are concerned that under Ballot 144 there could be two .onion certs with the SAME domain but identifying two DIFFERENT subjects. > > > > For example, Evil Corp. and Angel Corp. could each submit a request for a .onion cert and get the same domain: [same 16 digit hash of their public keys].onion if their public keys hash to the same value. One cert would say O=Evil Corp. the other would say O=Angel Corp., so that a .onion domain would not be uniquely identified with one subject. While unlikely, it could happen. > > > > How does Tor resolve this if the same .onion domain is assigned to multiple, different subjects? If someone types in [16 digit hash].onion and that could lead to multiple Tor locations, how does Tor decide where to direct the user? > > Hi Kirk, While not Jeremy, this is actually why I suggested that the full public key be included within the issued certificate itself, so as to highlight any hash collision attempts on the onion private key (e.g. by funkily encoding key parameters or by using key confusion). On a practical level, it's far out there from the realm of being feasible, but it's enough of an issue that I felt important that this should be included in the issued cert, so that sites could use, for example, certificate transparency to monitor for such things. On the TOR side, the protocol is being revved to deal with this, but it is described more at https://trac.torproject.org/projects/tor/wiki/doc/HiddenServiceNames So from the issuance side, the mitigations are including the full public key as well as requiring the EV validation, rather than DV. > > (2) Does this also create an opportunity for a hacker? For example, one of the .onion domains in the SANs field of the Facebook cert you created is *.xx.fbcdn23dssr3jqnq.onion ? could a hacker create a public key that would hash to the same value in order to get a cert with the same .onion domain and imitate the Facebook cert? (This is maybe the more serious case.) > Isn't this a restatement of 1? Or at least, the answers there would still apply. > (3) Another concern is there is no central registry to identify the owner of a .onion domain (of course, there could be multiple owners of the domain under the scenario above). If there is no Subject info in the O field, etc., with no registry there is no real way to contact the domain (or cert owner). > I'm not entirely sure I follow? Note during the discussion phase also included discussion about requiring one or more DNS names from the IANA zone as well, which seems like it would mitigate this concern. > > > Any information you can provide on these point will be very helpful. > I think it is important when considering these that, as of today, any CA can issue any name under .onion under the "Internal Names" exception. This proposal merely restricts it from being "any rules you want" to "more stringent verification required" It still treats .onion as an internal name, in as much as they still sunset and must be revoked. If this ballot fails, every CA will still be able to issue .onion names to any party they wish, including parties who have no relationship whatsoever to the onion HS. That is, if this fails, there is no requirement for attackers to execute a hash collision or factor a private key - they just need to find a CA willing to issue under the "Internal Names" rule (which, as you know, is typically validated at a level less than EV, such as OV). That's why I think this ballot is good - it doesn't prolong or extend risk, it actually _restricts_ issuance in this space until internal names are sunset, at which point, no more of these certs will be issued, no matter the rules. In practice, I expect discussion and standardization to continue, and we may see DigiCert issue a ballot in half a year that looks to extend such issuance, but that's not this ballot, thankfully, so we don't have to solve all of these issues right away. > > > > > TREND MICRO EMAIL NOTICE > The information contained in this email and any attachments is confidential > and may be subject to copyright or other intellectual property protection. > If you are not the intended recipient, you are not authorized to use or > disclose this information, and we request that you notify us by reply mail or > telephone and delete the original message from your mail system. > > > _______________________________________________ > 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/20150213/67458ded/attachment-0001.html From sleevi at google.com Thu Feb 12 18:18:06 2015 From: sleevi at google.com (Ryan Sleevi) Date: Thu, 12 Feb 2015 17:18:06 -0800 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: <50b4fdabaa7a4c7e9d1c3b962071f9af@EX2.corp.digicert.com> References: <50b4fdabaa7a4c7e9d1c3b962071f9af@EX2.corp.digicert.com> Message-ID: On Thu, Feb 12, 2015 at 5:14 PM, Jeremy Rowley wrote: > One caveat is that another ballot is not required if the IESG officially > recognizes .onion a reserved name. Yes it does. Per BR 1.2.3 Internal Name: A string of characters (not an IP address) in a Common Name or Subject Alternative Name field of a Certificate that cannot be verified as globally unique within the public DNS at the time of certificate issuance because it does not end with a Top Level Domain registered in IANA?s Root Zone Database. An IESG reservation would not result in it being added to the IANA Root Zone Database. You can see this is already the case for RFC 6761 names not being present in the Root Zone Database at [1] [1] https://www.iana.org/domains/root/files From jeremy.rowley at digicert.com Thu Feb 12 18:43:22 2015 From: jeremy.rowley at digicert.com (Jeremy Rowley) Date: Fri, 13 Feb 2015 01:43:22 +0000 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: References: <50b4fdabaa7a4c7e9d1c3b962071f9af@EX2.corp.digicert.com> Message-ID: <258fee1ba76546188b462cc2c6ba0327@EX2.corp.digicert.com> #5 in the ballot: 5. CAs MUST NOT issue a Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name with a validity period longer than 15 months. Despite Section 9.2.1 of the Baseline Requirements deprecating the use of Internal Names, a CA MAY issue a Certificate containing an .onion name with an expiration date later than 1 November 2015 after (and only if) .onion is officially recognized by the IESG as a reserved TLD. -----Original Message----- From: Ryan Sleevi [mailto:sleevi at google.com] Sent: Thursday, February 12, 2015 6:18 PM To: Jeremy Rowley Cc: kirk_hall at trendmicro.com; CABFPub; Ben Wilson Subject: Re: [cabfpub] Ballot 144 -.onion domains On Thu, Feb 12, 2015 at 5:14 PM, Jeremy Rowley wrote: > One caveat is that another ballot is not required if the IESG > officially recognizes .onion a reserved name. Yes it does. Per BR 1.2.3 Internal Name: A string of characters (not an IP address) in a Common Name or Subject Alternative Name field of a Certificate that cannot be verified as globally unique within the public DNS at the time of certificate issuance because it does not end with a Top Level Domain registered in IANA?s Root Zone Database. An IESG reservation would not result in it being added to the IANA Root Zone Database. You can see this is already the case for RFC 6761 names not being present in the Root Zone Database at [1] [1] https://www.iana.org/domains/root/files From jeremy.rowley at digicert.com Thu Feb 12 19:26:21 2015 From: jeremy.rowley at digicert.com (Jeremy Rowley) Date: Fri, 13 Feb 2015 02:26:21 +0000 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names In-Reply-To: References: Message-ID: <95e76d821df3405eb58dcb116081b82b@EX2.corp.digicert.com> DigiCert votes "Yes" From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Tuesday, February 10, 2015 11:39 AM To: public at cabforum.org Subject: [cabfpub] Ballot 144 - Validation rules for .onion names Here's the ballot with the two typos fixed: Applicants want a CA-signed .onion address for several reasons, including: - Powerful web platform features are restricted to secure origins, which are currently not available to onion names (in part, because of the lack of IANA registration). Permitting EV certs for onion names will help provide a secure origin for the service, moving onion towards use of powerful web platform features. - Currently, access to .onion names over https from a standard browser results in the standard existing 'Invalid Certificate' warning. Training users to click through security warnings lowers the value of these warnings and will cause users to miss important security information. Removing these warnings for the user, through use of a digital certificate, will help users recognize and avoid real MITM attacks. - The public needs attribution of ownership of the .onion address to differentiate onion services, including potential phishing services. Because onion names are not easily recognizable strings, providing the public with additional information about the operator has significant security improvements, especially in regions where use of the incorrect name could have lethal consequences. The following motion has been proposed by Jeremy Rowley of DigiCert and endorsed by Ryan Sleevi of Google and Wayne Thayer of GoDaddy. --------------------- Motion Starts --------------------- 1) Amend Section 9.2.1 of the Baseline Requirements v. 1.2.3 as follows: 9.2.1 Subject Alternative Name Extension Certificate Field: extensions:subjectAltName Required/Optional: Required Contents: This 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. The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate. Wildcard FQDNs are permitted. As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name, the CA SHALL notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016. Also as of the Effective Date, the CA SHALL NOT issue a certificate with an Expiry Date later than 1 November 2015 with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name. Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Name. Effective May 1, 2015, each CA SHALL revoke all unexpired Certificates with an Internal Name using onion as the right-most label in an entry in the subjectAltName Extension or commonName field unless such Certificate was issued in accordance with Appendix F of the EV Guidelines. 2) Amend Section 9.2.2 and 11.7.1 of the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2 as follows: 9.2.2. Subject Alternative Name Extension Certificate field: subjectAltName:dNSName Required/Optional: Required Contents: This extension MUST contain one or more host Domain Name(s) owned or controlled by the Subject and to be associated with the Subject's server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). Wildcard certificates are not allowed for EV Certificates except as permitted under Appendix F. 11.7 Verification of Applicant's Domain Name 11.7.1. Verification Requirements (1) For each Fully-Qualified Domain Name listed in a Certificate, other than a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant (or the Applicant's Parent Company, Subsidiary Company, or Affiliate, collectively referred to as "Applicant" for the purposes of this section) either is the Domain Name Registrant or has control over the FQDN using a procedure specified in Section 11.1.1 of the Baseline Requirements, except that a CA MAY NOT verify a domain using the procedure described 11.1.1(7). For a Certificate issued to a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant's control over the .onion Domain Name in accordance with Appendix F. (2) Mixed Character Set Domain Names: EV Certificates MAY include Domain Names containing mixed character sets only in compliance with the rules set forth by the domain registrar. The CA MUST visually compare any Domain Names with mixed character sets with known high risk domains. If a similarity is found, then the EV Certificate Request MUST be flagged as High Risk. The CA must perform reasonably appropriate additional authentication and verification to be certain beyond reasonable doubt that the Applicant and the target in question are the same organization. 3) Add a new Appendix F to the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2: Appendix F - Issuance of Certificates for .onion Domain Names A CA may issue an EV Certificate with .onion in the right-most label of the Domain Name provided that issuance complies with the requirements set forth in this Appendix: 1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) The CAB Forum has created an extension of the TBSCertificate for use in conveying hashes of keys related to .onion addresses. The Tor Service Descriptor Hash extension has the following format: cabf-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 } TorServiceDescriptorSyntax ::= SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash TorServiceDescriptorHash:: = SEQUENCE { onionURI UTF8String algorithm AlgorithmIdentifier subjectPublicKeyHash BIT STRING } Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 6234) performed over the DER-encoding of an ASN.1 SubjectPublicKey of the .onion service and SubjectPublicKeyHash is the hash output. 2. The CA MUST verify the Applicant's control over the .onion Domain Name using one of the following: a. The CA MAY verify the Applicant's control over the .onion service by posting a specific value at a well-known URL under RFC5785. b. The CA MAY verify the Applicant's control over the .onion service by having the Applicant provide a Certificate Request signed using the .onion public key if the Attributes section of the certificationRequestInfo contains: (i) A caSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy, 2) is generated by the CA, and 3) delivered to the Applicant through a Verified Method of Communication and (ii) An applicantSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy and 2) is generated by the Applicant. The signing nonce attributes have the following format: caSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-caSigningNonce } } cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } applicantSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-applicantSigningNonce } } cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 } 4. Each Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name MUST conform to the requirements of these Guidelines, including the content requirements in Section 9 and Appendix B of the Baseline Requirements, except that the CA MAY include a wildcard character in the Subject Alternative Name Extension and Subject Common Name Field as the left-most character in the .onion Domain Name provided inclusion of the wildcard character complies with Section 11.1.3 of the Baseline Requirements. 5. CAs MUST NOT issue a Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name with a validity period longer than 15 months. Despite Section 9.2.1 of the Baseline Requirements deprecating the use of Internal Names, a CA MAY issue a Certificate containing an .onion name with an expiration date later than 1 November 2015 after (and only if) .onion is officially recognized by the IESG as a reserved TLD. 6. On or before May 1, 2015, each CA MUST revoke all Certificates issued with the Subject Alternative Name extension or Common Name field that includes a Domain Name where .onion is in the right-most label of the Domain Name unless the Certificate was issued in compliance with this Appendix F. ---- Motion Ends ----- The review period for this ballot shall commence at 2200 UTC on Thursday, 4 February 2015, and will close at 2200 UTC on Thursday, 11 February 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on Monday, 18 February 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150213/349a74de/attachment-0001.html From kirk_hall at trendmicro.com Thu Feb 12 19:33:12 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Fri, 13 Feb 2015 02:33:12 +0000 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: <54DD289E.8040304@mozilla.org> References: <54DD1DED.4090105@mozilla.org> <54DD289E.8040304@mozilla.org> Message-ID: Gerv, you made an interesting point below in response to my message: [Kirk] If Facebook can reverse engineer to get that .onion domain, couldn?t a hacker (or googlegoogle.onion, for another example) do the same and get a duplicate cert with the same domain? [Gerv] No. What Facebook did was generate a lot of hashes starting "facebook", reviewed them, picked the one they liked best and then invented a "reason" for why it's that one: "Facebook's Core WWW Infrastructure". However, generating a second one which exactly matched the name Facebook picked is a much harder process. Fair enough. But if Facebook can engineer *multiple* public keys that hash so the first 8 characters of ALL of them are ?facebook?, I?m guessing its not that hard and a hacker could do the same thing (or get the first 5 as yahoo, the first 6 as google, or the first 8 as microsoft). After that, the rest of the characters could be random or meaningful, but the potential harm (trickery in the domain name) is already done. Under the ballot, CAs have no obligation to scan or verify a *meaningful* .onion domain and look for phishing or fraud attempts. I was under the impression that .onion domain names were ALWAYS 12 random characters (which avoids fraud); now I see that people who want a specific .onion name can arguably game the system to get a meaningful name that they want (and it might not even be their own name ? gervmarkham1 for example). Under BR 9.2.4g, CAs are not permitted to issue certs with unverified names in the OU field: The CA SHALL implement a process that prevents an OU attribute from including a name, DBA, tradename, trademark, address, location, or other text that refers to a specific natural person or Legal Entity unless the CA has verified this information in accordance with Section 11.2 and the Certificate also contains subject:organizationName, subject:localityName, and subject:countryName attributes, also verified in accordance with Section 11.2. Of course, the OU field is not very important because it?s almost never visible to users. In contrast, a .onion domain name will be displayed to Tor users, and could cause confusion. Should we require CAs to follow the rules of BR 9.2.4g so that .onion domains that include meaningful names are verified? Or better yet, not allow .onion domains to be meaningful (require them to be random only)? 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
-------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150213/92052f29/attachment.html From sleevi at google.com Thu Feb 12 19:43:57 2015 From: sleevi at google.com (Ryan Sleevi) Date: Thu, 12 Feb 2015 18:43:57 -0800 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: References: <54DD1DED.4090105@mozilla.org> <54DD289E.8040304@mozilla.org> Message-ID: On Thu, Feb 12, 2015 at 6:33 PM, kirk_hall at trendmicro.com < kirk_hall at trendmicro.com> wrote: > > In contrast, a .onion domain name will be displayed to Tor users, and > could cause confusion. Should we require CAs to follow the rules of BR > 9.2.4g so that .onion domains that include meaningful names are verified? > Or better yet, not allow .onion domains to be meaningful (require them to > be random only)? > How do you define meaningful? How do you define random? In quantifiable ways that can either be audited or inspected by third-parties (e.g. via Certificate Transparency) facebookcorewwwi is a random name. That it has symbolic meaning in English is something that happens with any random system, given sufficient time. Would these concerns go away if Item #5 was removed from the ballot (the automatic extension if IESG reserves)? While I think this discussion is useful to a degree, I do have some concerns: - Under the current provisions, anyone can issue for .onion, so this is by no means worse in any quantifiable way - Under the current provisions, using a .onion with HTTP is objectively less secure than using a .onion name with HTTPS - A .onion name is based upon an RSA-1024 bit key, which is the only security protection in play here. - A .onion name is denied access to privacy-and-security enhancing technologies (due to browsers restricting access to features not delivered over secure transports) - The concerns regarding 'spoofability' of a .onion name exist independent of any discussion in the Forum. That is, it is, at it's core, a TOR protocol "issue" (I'm not sure I would call it that, but for sake of discussion...) - Anyone using .onion names can create facebookwwwcore1.onion, given sufficient time and energy - DNS spoofing exists entirely in the Baseline Requirements (CAs are only required to document their procedures regarding high risk requests. They are not prohibited from issuing such phishy names, per 11.5 of the BR 1.2.3) - DNS spoofing exists entirely in the EV Guidelines (CAs are only required to inspect mixed-script domains, per 11.7.1 p2 of the EVG 1.5.2) Nothing prohibits facebookcorewwwi.com and facebookcorewww1.com from purchasing certificates, EV or DV, provided they demonstrate control over that namespace. Why would or should .onion be any different? -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150212/6b9fb2f7/attachment.html From jeremy.rowley at digicert.com Thu Feb 12 19:44:39 2015 From: jeremy.rowley at digicert.com (Jeremy Rowley) Date: Fri, 13 Feb 2015 02:44:39 +0000 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: References: <54DD1DED.4090105@mozilla.org> <54DD289E.8040304@mozilla.org> Message-ID: Actually, this illustrates exactly why EV is being used for these. Someone might be able to generate a name that looks similar to the facebook onion name. Without EV, you couldn?t convey which is the actual onion service run by facebook, making it easier to conduct phishing attacks. All onion names are meaningful in that they tie the service to a particular key. With EV, you have a way to tie the key directly to an existing organization. From: kirk_hall at trendmicro.com [mailto:kirk_hall at trendmicro.com] Sent: Thursday, February 12, 2015 7:33 PM To: Gervase Markham; Jeremy Rowley; Ben Wilson Cc: CABFPub (public at cabforum.org) Subject: RE: [cabfpub] Ballot 144 -.onion domains Gerv, you made an interesting point below in response to my message: [Kirk] If Facebook can reverse engineer to get that .onion domain, couldn?t a hacker (or googlegoogle.onion, for another example) do the same and get a duplicate cert with the same domain? [Gerv] No. What Facebook did was generate a lot of hashes starting "facebook", reviewed them, picked the one they liked best and then invented a "reason" for why it's that one: "Facebook's Core WWW Infrastructure". However, generating a second one which exactly matched the name Facebook picked is a much harder process. Fair enough. But if Facebook can engineer *multiple* public keys that hash so the first 8 characters of ALL of them are ?facebook?, I?m guessing its not that hard and a hacker could do the same thing (or get the first 5 as yahoo, the first 6 as google, or the first 8 as microsoft). After that, the rest of the characters could be random or meaningful, but the potential harm (trickery in the domain name) is already done. Under the ballot, CAs have no obligation to scan or verify a *meaningful* .onion domain and look for phishing or fraud attempts. I was under the impression that .onion domain names were ALWAYS 12 random characters (which avoids fraud); now I see that people who want a specific .onion name can arguably game the system to get a meaningful name that they want (and it might not even be their own name ? gervmarkham1 for example). Under BR 9.2.4g, CAs are not permitted to issue certs with unverified names in the OU field: The CA SHALL implement a process that prevents an OU attribute from including a name, DBA, tradename, trademark, address, location, or other text that refers to a specific natural person or Legal Entity unless the CA has verified this information in accordance with Section 11.2 and the Certificate also contains subject:organizationName, subject:localityName, and subject:countryName attributes, also verified in accordance with Section 11.2. Of course, the OU field is not very important because it?s almost never visible to users. In contrast, a .onion domain name will be displayed to Tor users, and could cause confusion. Should we require CAs to follow the rules of BR 9.2.4g so that .onion domains that include meaningful names are verified? Or better yet, not allow .onion domains to be meaningful (require them to be random only)? TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150213/517e3bd0/attachment-0001.html From jeremy.rowley at digicert.com Thu Feb 12 19:55:02 2015 From: jeremy.rowley at digicert.com (Jeremy Rowley) Date: Fri, 13 Feb 2015 02:55:02 +0000 Subject: [cabfpub] Domain Validation Revision Message-ID: Attached is a draft proposal from the EV working group about revising the domain validation in the BRs. The intent is 1) to eliminate the "any other option" (as it made domain validation essentially meaningless, 2) tighten up the domain validation language, and 3) permit attorney/accountants to draft the domain authorization document. Note that revising this section will automatically revise domain validation in EV. Also note that this is a draft from the working group and not yet a proposed ballot. Jeremy -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150213/5ec92951/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: Domain Validation Revision Proposal.docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Size: 20594 bytes Desc: Domain Validation Revision Proposal.docx Url : https://cabforum.org/pipermail/public/attachments/20150213/5ec92951/attachment-0001.bin From sleevi at google.com Thu Feb 12 20:08:50 2015 From: sleevi at google.com (Ryan Sleevi) Date: Thu, 12 Feb 2015 19:08:50 -0800 Subject: [cabfpub] Domain Validation Revision In-Reply-To: References: Message-ID: Jeremy, I'm excited to see momentum towards removing the the "Any other option" language, so I'm glad to hear the EV working group is tackling this. In line with "tightening up" the requirements, it would be nice to see Section 7 tightened to go from "Making a change on any file on a web server" to being a specific path (e.g. a .well-known URI) Incidentally, due to other discussions, I'm curious how 2 and 3 tangibly differ (given that the Registrar will provide WHOIS information). Even if they are kept separate, does it make sense to add "through a Reliable Method of Communication" to Section 3, as you have with 1/2? Regarding the language "agreed-upon", this does seem to give significant leeway for CAs to be lax in ways that attackers may exploit. Consistent with your "tightening up" goal, should Items 6 and 7 be explicit that the CA must dictate what change to make? Otherwise, I am concerned that the attacker can "propose" a change (using a portion of the system that they control) and then be issued a certificate. As I've mentioned in the past, it would be nice to see an explicit whitelist for these two methods, consistent with the whitelist for email addresses in Section 4. Put differently, I can see 7 being a little fuzzy-on-the-edges, even though it does approach a more restrictive subset. It would be great to explicitly specify record types that may be used to perform this demonstration (e.g. a TXT record with some CA-dictated value, making a change to a CNAME/A/AAAA in some meaningful way, etc) 8 concerns me for a couple reasons, even though it's moving in the right direction. - You require HTTPS, but that seems overkill, when you only need to perform a TLS handshake. That is, consider a mail server configured for SMTP-S - it seems that would be a viable configuration - It would seem that anyone that can get a port forwarded on a particular address can now get a certificate on that address. For things like STUN-TCP services, this seems quite bad! - The definition of "test certificate" is, from experience, a bit of a handwave that varies from CA to CA. It would be nice to put some explicit technical profile in place here (e.g. a critical poison extension, a requirement that EKUs are present but not serverAuth/clientAuth, issued from a CA independent of the issuing CA's 'trusted' hierarchy) that would prevent relying parties from believing the test certificate is "real" These are just some initial reactions from the proposal; more may come in time. On Thu, Feb 12, 2015 at 6:55 PM, Jeremy Rowley wrote: > Attached is a draft proposal from the EV working group about revising the > domain validation in the BRs. The intent is 1) to eliminate the ?any other > option? (as it made domain validation essentially meaningless, 2) tighten up > the domain validation language, and 3) permit attorney/accountants to draft > the domain authorization document. > > > > Note that revising this section will automatically revise domain validation > in EV. Also note that this is a draft from the working group and not yet a > proposed ballot. > > > > Jeremy > > > > > > > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public > From jeremy.rowley at digicert.com Thu Feb 12 20:37:18 2015 From: jeremy.rowley at digicert.com (Jeremy Rowley) Date: Fri, 13 Feb 2015 03:37:18 +0000 Subject: [cabfpub] Domain Validation Revision In-Reply-To: References: Message-ID: <64bba0d4f05e48fe9673b25b87dd400d@EX2.corp.digicert.com> Thanks Ryan, In line with "tightening up" the requirements, it would be nice to see Section 7 tightened to go from "Making a change on any file on a web server" to being a specific path (e.g. a .well-known URI) [JR] We discussed this, but I can't remember what the objection was. I'll bring it back to the working group unless someone else chimes in. Incidentally, due to other discussions, I'm curious how 2 and 3 tangibly differ (given that the Registrar will provide WHOIS information). Even if they are kept separate, does it make sense to add "through a Reliable Method of Communication" to Section 3, as you have with 1/2? [JR] For 2 sometimes we call up the registrar to get info on how to contact the registrant (such as when the domain is private). However, we could probably combine them to a single bullet point and apply reliable method of communication to both. Regarding the language "agreed-upon", this does seem to give significant leeway for CAs to be lax in ways that attackers may exploit. Consistent with your "tightening up" goal, should Items 6 and 7 be explicit that the CA must dictate what change to make? Otherwise, I am concerned that the attacker can "propose" a change (using a portion of the system that they control) and then be issued a certificate. As I've mentioned in the past, it would be nice to see an explicit whitelist for these two methods, consistent with the whitelist for email addresses in Section 4. [JR] Agreed. By posting this to the mailing list, we're hoping that CAs will indicate exactly what they want covered so we can narrow the scope of these two sections. I probably should have mentioned that in the original email... Put differently, I can see 7 being a little fuzzy-on-the-edges, even though it does approach a more restrictive subset. It would be great to explicitly specify record types that may be used to perform this demonstration (e.g. a TXT record with some CA-dictated value, making a change to a CNAME/A/AAAA in some meaningful way, etc) [JR] I'll have the working group come up with an initial list. If anyone has specific ways they verify though DNS, please email it to me for consideration. 8 concerns me for a couple reasons, even though it's moving in the right direction. - You require HTTPS, but that seems overkill, when you only need to perform a TLS handshake. That is, consider a mail server configured for SMTP-S - it seems that would be a viable configuration - It would seem that anyone that can get a port forwarded on a particular address can now get a certificate on that address. For things like STUN-TCP services, this seems quite bad! - The definition of "test certificate" is, from experience, a bit of a handwave that varies from CA to CA. It would be nice to put some explicit technical profile in place here (e.g. a critical poison extension, a requirement that EKUs are present but not serverAuth/clientAuth, issued from a CA independent of the issuing CA's 'trusted' hierarchy) that would prevent relying parties from believing the test certificate is "real" [JR] This was added by GlobalSign so I'll let them comment. These are just some initial reactions from the proposal; more may come in time. On Thu, Feb 12, 2015 at 6:55 PM, Jeremy Rowley wrote: > Attached is a draft proposal from the EV working group about revising > the domain validation in the BRs. The intent is 1) to eliminate the > ?any other option? (as it made domain validation essentially > meaningless, 2) tighten up the domain validation language, and 3) > permit attorney/accountants to draft the domain authorization document. > > > > Note that revising this section will automatically revise domain > validation in EV. Also note that this is a draft from the working > group and not yet a proposed ballot. > > > > Jeremy > > > > > > > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public > From kirk_hall at trendmicro.com Thu Feb 12 23:22:59 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Fri, 13 Feb 2015 06:22:59 +0000 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: References: <54DD1DED.4090105@mozilla.org> <54DD289E.8040304@mozilla.org> Message-ID: BR 11.5 High Risk Requests The CA SHALL develop, maintain, and implement documented procedures that identify and require additional verification activity for High Risk Certificate Requests prior to the Certificate?s approval, as reasonably necessary to ensure that such requests are properly verified under these Requirements. High Risk Certificate Request: A Request that the CA flags for additional scrutiny by reference to internal criteria and databases maintained by the CA, which may include names at higher risk for phishing or other fraudulent usage, names contained in previously rejected certificate requests or revoked Certificates, names listed on the Miller Smiles phishing list or the Google Safe Browsing list, or names that the CA identifies using its own risk-mitigation criteria. We won?t issue certs for microsoft.example.com, googleserver.example.com, etc., even though our customer owns example.com. I think the same concerns would apply to .onion certs, for the same reason. From: Ryan Sleevi [mailto:sleevi at google.com] Sent: Thursday, February 12, 2015 6:44 PM To: Kirk Hall (RD-US) Cc: Gervase Markham; Jeremy Rowley (jeremy.rowley at digicert.com); Ben Wilson (Ben.Wilson at digicert.com); CABFPub (public at cabforum.org) Subject: Re: [cabfpub] Ballot 144 -.onion domains On Thu, Feb 12, 2015 at 6:33 PM, kirk_hall at trendmicro.com > wrote: In contrast, a .onion domain name will be displayed to Tor users, and could cause confusion. Should we require CAs to follow the rules of BR 9.2.4g so that .onion domains that include meaningful names are verified? Or better yet, not allow .onion domains to be meaningful (require them to be random only)? How do you define meaningful? How do you define random? In quantifiable ways that can either be audited or inspected by third-parties (e.g. via Certificate Transparency) facebookcorewwwi is a random name. That it has symbolic meaning in English is something that happens with any random system, given sufficient time. Would these concerns go away if Item #5 was removed from the ballot (the automatic extension if IESG reserves)? While I think this discussion is useful to a degree, I do have some concerns: - Under the current provisions, anyone can issue for .onion, so this is by no means worse in any quantifiable way - Under the current provisions, using a .onion with HTTP is objectively less secure than using a .onion name with HTTPS - A .onion name is based upon an RSA-1024 bit key, which is the only security protection in play here. - A .onion name is denied access to privacy-and-security enhancing technologies (due to browsers restricting access to features not delivered over secure transports) - The concerns regarding 'spoofability' of a .onion name exist independent of any discussion in the Forum. That is, it is, at it's core, a TOR protocol "issue" (I'm not sure I would call it that, but for sake of discussion...) - Anyone using .onion names can create facebookwwwcore1.onion, given sufficient time and energy - DNS spoofing exists entirely in the Baseline Requirements (CAs are only required to document their procedures regarding high risk requests. They are not prohibited from issuing such phishy names, per 11.5 of the BR 1.2.3) - DNS spoofing exists entirely in the EV Guidelines (CAs are only required to inspect mixed-script domains, per 11.7.1 p2 of the EVG 1.5.2) Nothing prohibits facebookcorewwwi.com and facebookcorewww1.com from purchasing certificates, EV or DV, provided they demonstrate control over that namespace. Why would or should .onion be any different? 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
-------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150213/7f5bd98b/attachment-0001.html From sleevi at google.com Fri Feb 13 00:18:08 2015 From: sleevi at google.com (Ryan Sleevi) Date: Thu, 12 Feb 2015 23:18:08 -0800 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: References: <54DD1DED.4090105@mozilla.org> <54DD289E.8040304@mozilla.org> Message-ID: Right, I'm aware you, as an individual CA, may not, but the BRs 1) Don't place any requirements beyond documenting and having a procedure for those flagged High Risk. The procedures may simply be "We require a phone call and a pinky promise to be good" 2) Don't place any requirements on the criteria for a request being flagged as High Risk, other than all EV certs are automatically high risk. Thus while you won't issue for microsoft.example.com or googleserver.example.com (and, to be fair, TrendMicro certainly will issue certs for those names, since it seems you will sell *.example.com), another CA may, and without violating any requirements. This is true whether the CA is issuing for DV or EV. I'm not trying to be stubborn here, but again, it is worth reiterating that nothing in the BRs or EVGs requires that a CA treat a request for facebook1.com any different than facebook2.com, or fbcdn.com any different than fcbdn.com, beyond the ambiguous and underspecified "addition verification activity", and if and only if the CA deems it high risk (which they may not). They do not prohibit a CA from issuing these certs, so I see no reason why .onion should be any different, especially since certificates are not an anti-phishing tool. My goal in arguing for these certs is I believe they are a great tool to increase online privacy and security, and, from a validation and verification space, are not weaker than the existing DV and EV practices. Indeed, in very real ways, this proposal is actually stronger than some of the verification practices CAs currently use (e.g. it requires a cryptographic key binding the name, rather than the insecure and unauthenticated reliance on DNS) I am concerned that the questions on criteria from my previous mail were somewhat ignored. I definitely think that if there are opportunities to improve this ballot, we should take them. However, your previous comment regarding "randomness" doesn't really establish actionable, auditable, objective criteria, and proposes to require more than the BRs require or CAs practice. I'm not sure how we can reasonably satisfy your concerns because of this, nor whether the absence of a solution for a problem the BRs don't address means you will vote to leave .onion unvalidated and unregulated, and, as a consequence, untrusted by some UAs (notably, Chrome). On Feb 12, 2015 10:23 PM, "kirk_hall at trendmicro.com" < kirk_hall at trendmicro.com> wrote: > *BR 11.5 High Risk Requests* > > The CA SHALL develop, maintain, and implement documented procedures that > identify and require additional verification activity for High Risk > Certificate Requests prior to the Certificate?s approval, as reasonably > necessary to ensure that such requests are properly verified under these > Requirements. > > > > *High Risk Certificate Request: *A Request that the CA flags for > additional scrutiny by reference to internal criteria and databases > maintained by the CA, which may include names at higher risk for phishing > or other fraudulent usage, names contained in previously rejected > certificate requests or revoked Certificates, names listed on the Miller > Smiles phishing list or the Google Safe Browsing list, or names that the CA > identifies using its own risk-mitigation criteria. > > > > We won?t issue certs for microsoft.example.com, googleserver.example.com, > etc., even though our customer owns example.com. I think the same > concerns would apply to .onion certs, for the same reason. > > > > *From:* Ryan Sleevi [mailto:sleevi at google.com] > *Sent:* Thursday, February 12, 2015 6:44 PM > *To:* Kirk Hall (RD-US) > *Cc:* Gervase Markham; Jeremy Rowley (jeremy.rowley at digicert.com); Ben > Wilson (Ben.Wilson at digicert.com); CABFPub (public at cabforum.org) > *Subject:* Re: [cabfpub] Ballot 144 -.onion domains > > > > > > > > On Thu, Feb 12, 2015 at 6:33 PM, kirk_hall at trendmicro.com < > kirk_hall at trendmicro.com> wrote: > > In contrast, a .onion domain name will be displayed to Tor users, and > could cause confusion. Should we require CAs to follow the rules of BR > 9.2.4g so that .onion domains that include meaningful names are verified? > Or better yet, not allow .onion domains to be meaningful (require them to > be random only)? > > > > How do you define meaningful? How do you define random? In quantifiable > ways that can either be audited or inspected by third-parties (e.g. via > Certificate Transparency) > > > > facebookcorewwwi is a random name. That it has symbolic meaning in English > is something that happens with any random system, given sufficient time. > > > > Would these concerns go away if Item #5 was removed from the ballot (the > automatic extension if IESG reserves)? > > > > While I think this discussion is useful to a degree, I do have some > concerns: > > > > - Under the current provisions, anyone can issue for .onion, so this is by > no means worse in any quantifiable way > > > > - Under the current provisions, using a .onion with HTTP is objectively > less secure than using a .onion name with HTTPS > > - A .onion name is based upon an RSA-1024 bit key, which is the only > security protection in play here. > > - A .onion name is denied access to privacy-and-security enhancing > technologies (due to browsers restricting access to features not delivered > over secure transports) > > > > - The concerns regarding 'spoofability' of a .onion name exist independent > of any discussion in the Forum. That is, it is, at it's core, a TOR > protocol "issue" (I'm not sure I would call it that, but for sake of > discussion...) > > - Anyone using .onion names can create facebookwwwcore1.onion, given > sufficient time and energy > > - DNS spoofing exists entirely in the Baseline Requirements (CAs are > only required to document their procedures regarding high risk requests. > They are not prohibited from issuing such phishy names, per 11.5 of the BR > 1.2.3) > > - DNS spoofing exists entirely in the EV Guidelines (CAs are only > required to inspect mixed-script domains, per 11.7.1 p2 of the EVG 1.5.2) > > > > Nothing prohibits facebookcorewwwi.com and facebookcorewww1.com from > purchasing certificates, EV or DV, provided they demonstrate control over > that namespace. Why would or should .onion be any different? > > > TREND MICRO EMAIL NOTICE > The information contained in this email and any attachments is confidential > and may be subject to copyright or other intellectual property protection. > If you are not the intended recipient, you are not authorized to use or > disclose this information, and we request that you notify us by reply mail or > telephone and delete the original message from your mail system. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150212/0cecb770/attachment.html From i-barreira at izenpe.net Fri Feb 13 01:05:11 2015 From: i-barreira at izenpe.net (i-barreira at izenpe.net) Date: Fri, 13 Feb 2015 09:05:11 +0100 Subject: [cabfpub] ballots 143 and 144 Message-ID: <763539E260C37C46A0D6B340B5434C3B0ADAE0DE@AEX06.ejsarea.net> Izenpe votes as follow 143: yes 144: abstains I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150213/4ed758d5/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 19121 bytes Desc: image001.png Url : https://cabforum.org/pipermail/public/attachments/20150213/4ed758d5/attachment-0001.png From i-barreira at izenpe.net Fri Feb 13 01:16:20 2015 From: i-barreira at izenpe.net (i-barreira at izenpe.net) Date: Fri, 13 Feb 2015 09:16:20 +0100 Subject: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc In-Reply-To: A References: <763539E260C37C46A0D6B340B5434C3B0ACD81A9@AEX06.ejsarea.net> A Message-ID: <763539E260C37C46A0D6B340B5434C3B0ADAE0EB@AEX06.ejsarea.net> Dear Jody, I understand your concern because it?s not easy for you to manage all possible combinations regarding ETSI audits in different countries so will try to clarify your example. First of all, no AuditCo has to be member of ETSI, AuditCo can perform ETSI accredited audits without being member of ETSI, they only need to be accredited in their country as stated in Annex E requirements. So, For example, ? Company A is a commercial CA that operates in Israel ? Auditor Jones works for AuditCo, which is based in Israel ? AuditCo is certified by some governmental agency as a qualified auditor IB? AuditCo has to be accredited under its National Accreditation Body according to ISO 17021. In the case of Israel, to follow the example, in the associated members tab of the EA, you can find the Israeli accreditation body, called ISRAC. Then AuditCo should be listed there and meeting the requirements to perform ETSI audits according to the national scheme indicated by ISRAC ? AuditCo is not an ETSI Member or Associate Member IB ? this is not necessary. No need to be an ETSI member to perform ETSI audits ? Auditor Jones audits Company A using the ETSI 102042 standard, and Company A sends the auditor's attestation letter to Microsoft as evidence that Company A complied with the Program's requirements. IB? this is perfectly valid if AuditCo is listed in ISRAC and is allowed to perform ETSI audits. Of course Auditor Jones has to be also accredited to perform these kind of audits, has to be "qualified", so it?s not only the company but also the auditor, but that?s an internal task of the AuditCo. Regarding of being member of not, this is voluntary, they can join ETSI or not and don?t think that solve the problem because joining ETSI does not mean that you?re "qualified" or "accredited" to perform an ETSI audit, it?s just indicate that you belong to a club for example. And of course, if company A needs an auditing company accredited in Israel and there?s none, they can look for in other countries. For example, in Spain there?s no accredited auditing bodies to perform ETSI audits listed in our NAB, called ENAC, so, we, Izenpe, had to look for another option. So, we contacted for the first 6 years with KPMG in the Netherlands, and the last 3, with TUV IT in Germany. And Izenpe has an accredited ETSI audits according to the, right now, German national scheme and we?re listed in Germany. We?ll debate this within ETSI ESI trying to find an easier solution. Regards I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. De: Jody Cloutier [mailto:jodycl at microsoft.com] Enviado el: mi?rcoles, 11 de febrero de 2015 0:32 Para: Barreira Iglesias, I?igo; public at cabforum.org Asunto: RE: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Thank you, Inigo. I think the problem is that, under ETSI, it's difficult to discern what an "equivalent national scheme" is. This sets up the scenario in which an auditor is employed by an organization that is recognized somehow by the government, but is not affiliated with an ETSI member organization (http://www.european-accreditation.org/home ). Microsoft does not know whether or not this auditor is qualified or not. For example, ? Company A is a commercial CA that operates in Israel ? Auditor Jones works for AuditCo, which is based in Israel ? AuditCo is certified by some governmental agency as a qualified auditor ? AuditCo is not an ETSI Member or Associate Member ? Auditor Jones audits Company A using the ETSI 102042 standard, and Company A sends the auditor's attestation letter to Microsoft as evidence that Company A complied with the Program's requirements. In this scenario, how does Microsoft know that Auditor Jones conducted a proper audit without expending significant resources to determine whether and according to what standard AuditCo and Auditor Jones was certified? Microsoft believes that it would be simpler if the requirements were that the Auditor must work for a company that is affiliated with an ETSI-approved member organization. If Company A needs an auditor and there is no qualified auditor in Israel, the company can use an auditor from a member organization via the cross-border conformity rules. Unless I am fundamentally misunderstanding the rules, the above is something that Microsoft is presently struggling with, and we'd like to try to make the rules easier to understand for potential partners and ourselves. Jody Cloutier Senior Security Program Manager Microsoft Trusted Root Certificate Program jody.cloutier at microsoft.com 425.443.8922 Operating Systems Group Global Risk and Compliance From: i-barreira at izenpe.net [mailto:i-barreira at izenpe.net] Sent: Tuesday, February 10, 2015 3:09 AM To: Jody Cloutier; public at cabforum.org Subject: RE: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Hi Jody, Regarding your comment on ETSI audits, I have to say that the ETSI audits shall be performed by accredited auditors as mentioned in Annex E of the current ETSI TS 102 042. ETSI audits performed by not accredited auditors shall be considered invalid. Microsoft is accepting ETSI audits since the very beginning in its root program requirements indicating this requirement. ETSI is providing a list of accredited auditors as mere information because has to be maintained by every NAB (National Accreditation Body). It?s true that this has to be improved regarding the new regulation 910/2014 and the new ENs and will take some time, but at the moment, it?s clearly stated that the audits shall be performed by accredited auditors. Don?t hesitate in contacting me for any additional information or help. Sometimes I?ve received some emails from Tom or Kelvin asking for the qualification of some audits, so, as say, you can contact me regarding this issue. Regards I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. De: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] En nombre de Jody Cloutier Enviado el: lunes, 09 de febrero de 2015 18:55 Para: CABFPub (public at cabforum.org) Asunto: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Microsoft comments on Section 17. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150213/f5643dcd/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 19121 bytes Desc: image001.png Url : https://cabforum.org/pipermail/public/attachments/20150213/f5643dcd/attachment-0002.png -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 1181 bytes Desc: image002.png Url : https://cabforum.org/pipermail/public/attachments/20150213/f5643dcd/attachment-0003.png From adriano.santoni at staff.aruba.it Fri Feb 13 02:23:47 2015 From: adriano.santoni at staff.aruba.it (Adriano Santoni) Date: Fri, 13 Feb 2015 10:23:47 +0100 Subject: [cabfpub] Ballots 143 and 144 In-Reply-To: <763539E260C37C46A0D6B340B5434C3B0ADAE0DE@AEX06.ejsarea.net> References: <763539E260C37C46A0D6B340B5434C3B0ADAE0DE@AEX06.ejsarea.net> Message-ID: <54DDC2A3.2000200@staff.aruba.it> An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150213/4d461b94/attachment.html From gerv at mozilla.org Fri Feb 13 02:53:18 2015 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 13 Feb 2015 09:53:18 +0000 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: References: <54DD1DED.4090105@mozilla.org> <54DD289E.8040304@mozilla.org> Message-ID: <54DDC98E.8020907@mozilla.org> Hi Kirk, On 13/02/15 02:33, kirk_hall at trendmicro.com wrote: > Fair enough. But if Facebook can engineer **multiple** public keys that > hash so the first 8 characters of ALL of them are ?facebook?, I?m > guessing its not that hard and a hacker could do the same thing (or get > the first 5 as yahoo, the first 6 as google, or the first 8 as > microsoft). After that, the rest of the characters could be random or > meaningful, but the potential harm (trickery in the domain name) is > already done. .onion names represent 80 bits of data (half of the 160 bits of a SHA-1 hash) and are 16 characters, so each character represents 5 bits. This means that to fix the first character would require generating about 32 (2 ^ 5) keys. Not many. But to fix the first two characters would require 32 ^ 2 = 1024 keys. Each additional character you want to fix makes the job 32 times harder. Therefore, getting even one key where the first 8 hash characters are "facebook" requires approx. 1 x 10^12 keys to be generated (that's 100,000,000,000). Facebook has a lot of computing power, so they could do this. This is not out of the reach of others, but would be expensive. I'm not sure a phisher would consider this the most cost-effective method of phishing. > Under the ballot, CAs have no obligation to scan or verify a > **meaningful** .onion domain and look for phishing or fraud attempts. Do they have such an obligation for normal domain names? If so, why does that obligation not extend to .onion names? > I > was under the impression that .onion domain names were ALWAYS 12 random > characters (which avoids fraud); now I see that people who want a > specific .onion name can arguably game the system to get a meaningful > name that they want (and it might not even be their own name ? > gervmarkham1 for example). The longer the required "meaningful" portion is, the harder it is to find a name beginning with it. As I said, each extra character you want makes it 32 times harder. So getting an 8-character prefix ("facebook") requires approx. 1 x 10^12 keys to be generated. Getting an 11 character prefix ("gervmarkham") requires 3.6 x 10^16 - i.e. it's 32,678 times harder. 11 characters would have been out of the reach of even Facebook. > In contrast, a .onion domain name will be displayed to Tor users, and > could cause confusion. Should we require CAs to follow the rules of BR > 9.2.4g so that .onion domains that include meaningful names are > verified? Or better yet, not allow .onion domains to be meaningful > (require them to be random only)? I think the idea of requiring "randomness" would not be any better. Let's say we required Facebook to be: 5jdgiu3sn4j2lkqq.onion. It would be equally as easy for someone to generate a key matching the first 8 letters of this as it is for someone to generate one matching the word "facebook". So for the same effort as above, I could generate: 5jdgiu3sya3mldpz.onion I'm not convinced that a user is going to recognise the difference between those two better than the difference between two strings starting "facebook". This is fundamentally why the proposal is that onion names be EV only - because looking at the domain name is not a good way of determining the owner, whether it's random or mnemonic. Gerv From gerv at mozilla.org Fri Feb 13 03:05:17 2015 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 13 Feb 2015 10:05:17 +0000 Subject: [cabfpub] Domain Validation Revision In-Reply-To: References: Message-ID: <54DDCC5D.50305@mozilla.org> On 13/02/15 02:55, Jeremy Rowley wrote: > Attached is a draft proposal from the EV working group about revising > the domain validation in the BRs. The intent is 1) to eliminate the > ?any other option? (as it made domain validation essentially > meaningless, I don't agree that the "any other option" makes domain validation essentially meaningless. The current text is as follows: "Using any other method of confirmation, provided that the CA maintains documented evidence that the method of confirmation establishes that the Applicant is the Domain Name Registrant or has control over the FQDN to at least the same level of assurance as those methods previously described." This basically means that CAs can innovate in the way they do domain control as long as the level of assurance remains the same, and it makes the CA responsible for confirming that this is so. (And if a CA was using this clause, I would expect the auditor auditing them to the BRs to review their documentation and make an assessment as to whether the level of assurance was equivalent.) Given that this is an area of CA operations where there are patents on some methods of doing things, open-endedness is IMO important to make sure that the BRs are not used as a device to force CAs to acquire patent licenses due to limited options. I have no objection to listing more methods that the CAB Forum explicitly finds to be acceptable, but I think removing the flexibility is a backwards step. > 3) permit > attorney/accountants to draft the domain authorization document. If I understand this correctly, then I am opposed. I don't see why a lawyer or an accountant is an appropriate authority on the subject of who controls a domain. Domain control can only be properly validated either by the registrar who issued the domain, the registrant listed in WHOIS, or some practical demonstration of control. No-one else's opinion matters. Gerv From bruce.morton at entrust.com Fri Feb 13 06:17:57 2015 From: bruce.morton at entrust.com (Bruce Morton) Date: Fri, 13 Feb 2015 13:17:57 +0000 Subject: [cabfpub] Domain Validation Revision In-Reply-To: References: Message-ID: <452C99D20750E74083DBA441FF932385E4162A8B@SOTTEXCH10.corp.ad.entrust.com> Some comments: Item 1 would originally allow confirmation of the domain name registrant using a WHOIS review. Now this must be done using a Reliable Method of Communications which does not appear to be compatible. Items 2, 3 and 4 now state "Confirming authorization of the Certificate's issuance". The purpose of section 11.1.1 is to confirm "the Applicant either is the Domain Name Registrant or has control." I don't think we need the new language about certificate's issuance. Thanks, Bruce. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Thursday, February 12, 2015 9:55 PM To: CABFPub (public at cabforum.org) Subject: [cabfpub] Domain Validation Revision Attached is a draft proposal from the EV working group about revising the domain validation in the BRs. The intent is 1) to eliminate the "any other option" (as it made domain validation essentially meaningless, 2) tighten up the domain validation language, and 3) permit attorney/accountants to draft the domain authorization document. Note that revising this section will automatically revise domain validation in EV. Also note that this is a draft from the working group and not yet a proposed ballot. Jeremy -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150213/dda19d2e/attachment.html From bruce.morton at entrust.com Fri Feb 13 06:46:05 2015 From: bruce.morton at entrust.com (Bruce Morton) Date: Fri, 13 Feb 2015 13:46:05 +0000 Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group In-Reply-To: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> References: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> Message-ID: <452C99D20750E74083DBA441FF932385E4162C54@SOTTEXCH10.corp.ad.entrust.com> Entrust votes Yes. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Wednesday, February 04, 2015 4:05 PM To: CABFPub Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group Ballot 143 - Formalization of validation working group ---- Reason ---- In order to address validation issues and inconsistencies in both the SSL Baseline Requirements and the EV Guidelines, the CAB Forum has held an informal working group previously referred to as the Extended Validation Working Group now known as the Validation Working Group, would like to modify its scope to include validation in the Baseline Requirements as well as the EV Guidelines. Jeremy Rowley of DigiCert made the following motion, which was endorsed by Rich Smith of Comodo and Kirk Hall of TrendMicro ---- Motion begins ---- The CA-Browser Forum formally establishes the Validation Working Group as an official working group of the CAB Forum, replacing the previous informal EV working group. The scope of this working group is to address issues arising under adopted CAB Forum standards related to the validation of certificate information and the inclusion of information in certificates. Scope: The Validation Working Group will consider all matters relating to the validation and inclusion of information in certificates under adopted CAB Forum guidelines. Deliverables: The Working Group shall produce one or more documents offering options to the Forum for validation within the scope defined above. ---- Motion Ends ---- The review period for this ballot shall commence at 2200 UTC on 5 Feb 2015, and will close at 2200 UTC on 11 Feb 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on 18 Feb 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150213/9fd76ba7/attachment-0001.html From volkan.nergiz at turktrust.com.tr Fri Feb 13 08:18:42 2015 From: volkan.nergiz at turktrust.com.tr (Volkan Nergiz) Date: Fri, 13 Feb 2015 17:18:42 +0200 Subject: [cabfpub] Ballots 143 and 144 Message-ID: <00db01d047a0$59e3dfb0$0dab9f10$@turktrust.com.tr> T?RKTRUST votes YES for Ballot 143 and ABSTAIN for Ballot 144. Volkan NERG?Z Quality Management System Specialist TURKTRUST Information Security Services Inc. Address: Hollanda Caddesi 696. Sokak No: 7 Y?ld?z, ?ankaya 06550 - ANKARA Phone: (312) 439 10 00 - 226 Fax: (312) 439 10 01 E-Mail: volkan.nergiz at turktrust.com.tr Web: www.turktrust.com.tr -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150213/4555530f/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 1906 bytes Desc: not available Url : https://cabforum.org/pipermail/public/attachments/20150213/4555530f/attachment.jpe From kirk_hall at trendmicro.com Fri Feb 13 09:28:29 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Fri, 13 Feb 2015 16:28:29 +0000 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: <54DDC98E.8020907@mozilla.org> References: <54DD1DED.4090105@mozilla.org> <54DD289E.8040304@mozilla.org> <54DDC98E.8020907@mozilla.org> Message-ID: Thanks, Gerv ? but if it wasn?t too hard for Facebook to generate multiple ?facebook? .onion domains (presumably using automated methods), I?m not convinced it would be hard for hackers. And I?m still troubled that the .onion plan allows multiple customers to obtain the same .onion domain (meaning there could be multiple certs for the same .onion domain that belong to different subjects). I have to circle back to ?Why are we doing this?? ? Tor users want to visit websites anonymously. [That sounds like something CAs should support if possible] ? Website owners do *not* want anonymity ? in fact, just the opposite. They want EV certs with their identity information included that will work for Tor users. ? For some reason, regular TLD certs (like .com certs) won?t work after Tor users go through the Tor blender. [Does anyone know why that is the case?] ? But for some reason, Internal Name .onion certs *do* work for Tor users after they go through the Tor blender. [Does anyone know why this is so?] ? Tor does not want to apply for .onion as a TLD, and does not want to be the registrar for .onion [Why not? That would solve everything by making .onion a TLD, so all the current CA rules could apply. And remember, website users are not looking for anonymity in their certs ? they want EV certs with their identity displayed prominently in the browsers.] ? The Tor process for assigning .onion domains does not require domains to be unique. Why won?t regular TLD certs work in Tor? Why do .onion Internal Name certs work in Tor? Could Tor fix this discrepancy so we don?t have to continue allowing Internal Name certs for the .onion case? If two or more website owners receive the same .onion domain (either by accident, or by design of some of the website owners who choose what their .onion domain will be, like Facebook did), how does Tor resolve this clash? Where does it send users? I really don?t understand why we have to create an exception to the rules to accommodate this case. -----Original Message----- From: Gervase Markham [mailto:gerv at mozilla.org] Sent: Friday, February 13, 2015 1:53 AM To: Kirk Hall (RD-US); Jeremy Rowley (jeremy.rowley at digicert.com); Ben Wilson (Ben.Wilson at digicert.com) Cc: CABFPub (public at cabforum.org) Subject: Re: [cabfpub] Ballot 144 -.onion domains Hi Kirk, On 13/02/15 02:33, kirk_hall at trendmicro.com wrote: > Fair enough. But if Facebook can engineer **multiple** public keys > that hash so the first 8 characters of ALL of them are ?facebook?, I?m > guessing its not that hard and a hacker could do the same thing (or > get the first 5 as yahoo, the first 6 as google, or the first 8 as > microsoft). After that, the rest of the characters could be random or > meaningful, but the potential harm (trickery in the domain name) is > already done. .onion names represent 80 bits of data (half of the 160 bits of a SHA-1 hash) and are 16 characters, so each character represents 5 bits. This means that to fix the first character would require generating about 32 (2 ^ 5) keys. Not many. But to fix the first two characters would require 32 ^ 2 = 1024 keys. Each additional character you want to fix makes the job 32 times harder. Therefore, getting even one key where the first 8 hash characters are "facebook" requires approx. 1 x 10^12 keys to be generated (that's 100,000,000,000). Facebook has a lot of computing power, so they could do this. This is not out of the reach of others, but would be expensive. I'm not sure a phisher would consider this the most cost-effective method of phishing. > Under the ballot, CAs have no obligation to scan or verify a > **meaningful** .onion domain and look for phishing or fraud attempts. Do they have such an obligation for normal domain names? If so, why does that obligation not extend to .onion names? > I > was under the impression that .onion domain names were ALWAYS 12 > random characters (which avoids fraud); now I see that people who want > a specific .onion name can arguably game the system to get a > meaningful name that they want (and it might not even be their own > name ? > gervmarkham1 for example). The longer the required "meaningful" portion is, the harder it is to find a name beginning with it. As I said, each extra character you want makes it 32 times harder. So getting an 8-character prefix ("facebook") requires approx. 1 x 10^12 keys to be generated. Getting an 11 character prefix ("gervmarkham") requires 3.6 x 10^16 - i.e. it's 32,678 times harder. 11 characters would have been out of the reach of even Facebook. > In contrast, a .onion domain name will be displayed to Tor users, and > could cause confusion. Should we require CAs to follow the rules of > BR 9.2.4g so that .onion domains that include meaningful names are > verified? Or better yet, not allow .onion domains to be meaningful > (require them to be random only)? I think the idea of requiring "randomness" would not be any better. Let's say we required Facebook to be: 5jdgiu3sn4j2lkqq.onion. It would be equally as easy for someone to generate a key matching the first 8 letters of this as it is for someone to generate one matching the word "facebook". So for the same effort as above, I could generate: 5jdgiu3sya3mldpz.onion I'm not convinced that a user is going to recognise the difference between those two better than the difference between two strings starting "facebook". This is fundamentally why the proposal is that onion names be EV only - because looking at the domain name is not a good way of determining the owner, whether it's random or mnemonic. Gerv 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
-------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150213/ce6a71ba/attachment-0001.html From gerv at mozilla.org Fri Feb 13 09:45:16 2015 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 13 Feb 2015 16:45:16 +0000 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: References: <54DD1DED.4090105@mozilla.org> <54DD289E.8040304@mozilla.org> <54DDC98E.8020907@mozilla.org> Message-ID: <54DE2A1C.9050601@mozilla.org> On 13/02/15 16:28, kirk_hall at trendmicro.com wrote: > Thanks, Gerv ? but if it wasn?t too hard for Facebook to generate > multiple ?facebook? .onion domains (presumably using automated methods), > I?m not convinced it would be hard for hackers. I will again try and convince you that the laws of probability mean it would be extremely, extremely hard -> impossible. > And I?m still troubled > that the .onion plan allows multiple customers to obtain the same .onion > domain (meaning there could be multiple certs for the same .onion domain > that belong to different subjects). I don't think that's true, for any useful meaning of the term "allow". There is a level of "vanishingly unlikely" which we can equate to "impossible". If I wanted to get a cert for facebookcorewwwi.onion, I would need to generate approximately 2^80 certificates to have a reasonable chance of finding one with the right hash. 2^80 is: 120,892,581,961,463,000,000,000. That's approximately a million times the number of grains of sand in the world. Making some estimates, it would require Amazon to run all of their 2 million AWS machines generating only keypairs for a thousand years. So it's possible that if I just start generating certs, I might get one which matches, but it's vanishingly unlikely for any reasonable scenario, even if I have lots and lots of computers and lots and lots of money. > ? For some reason, regular TLD certs (like .com > certs) won?t work after Tor users go through the Tor blender. [Does > anyone know why that is the case?] Because unless CAs issue for .onion, the domain name in any certificate the site is able to obtain doesn't match the domain name they are using. > ? But for some reason, Internal Name .onion certs > **do** work for Tor users after they go through the Tor blender. [Does > anyone know why this is so?] Because the domain names match. > ? Tor does not want to apply for .onion as a TLD, and > does not want to be the registrar for .onion [Why not? That would solve > everything by making .onion a TLD, so all the current CA rules could > apply. It is not meaningful to have a "registrar" for a namespace where everyone picks their own name, at random, by generating a keypair. > ? The Tor process for assigning .onion domains does > not require domains to be unique. The laws of chance, as noted above, means that a collision is highly, highly, highly unlikely. > If two or more website owners receive the same .onion domain (either by > accident, or by design of some of the website owners who choose what > their .onion domain will be, like Facebook did), As noted in previous emails, it would require gargantuan computing power to obtain a cert which matched an existing cert. Gerv From tom at ritter.vg Fri Feb 13 09:52:43 2015 From: tom at ritter.vg (Tom Ritter) Date: Fri, 13 Feb 2015 10:52:43 -0600 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: References: <54DD1DED.4090105@mozilla.org> <54DD289E.8040304@mozilla.org> <54DDC98E.8020907@mozilla.org> Message-ID: Damn, Gerv replied before I could. I'll add a couple notes: On 13 February 2015 at 10:28, kirk_hall at trendmicro.com < kirk_hall at trendmicro.com> wrote: > * Tor does not want to apply for .onion as a TLD, and > does not want to be the registrar for .onion [Why not? That would solve > everything by making .onion a TLD, so all the current CA rules could > apply. And remember, website users are not looking for anonymity in their > certs - they want EV certs with their identity displayed prominently in the > browsers.] > Tor will consider applying for .onion the next time the TLD rigamarole comes up. I don't believe you can just shoot off an application at this point, the process is closed until it is opened again, and no announcements on when that will be. (I could be wrong there, but that's my belief.) As Gerv said, it's strange and difficult to try and register for a generic term that you don't intend to actually process registrations for, that would not be publicly accessible. There was a big debate a few years ago I don't know the status of, but how would people feel if I wanted to register for [looks around the room, sees a picture frame] .frames and then never use it? Anyway, besides all that, the application fee is $180K and that doesn't include the cost in terms of manpower (internal and external) to apply. If anyone is willing to sponsor the costs of doing so for a non-profit, Tor will be happy to chat. > * The Tor process for assigning .onion domains does > not require domains to be unique. > Technically, no. The math makes it diminishingly small, but just on the verge of attackable. It's weak. We know. We're working on fixing it. I would say; however, that while the Tor process for assigning .onion does not require domains to be unique - the CA issuance process can. These are going to be in Certificate Transparency logs, you can go look. -tom -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150213/0aefc884/attachment.html From tom at ritter.vg Fri Feb 13 09:55:20 2015 From: tom at ritter.vg (Tom Ritter) Date: Fri, 13 Feb 2015 10:55:20 -0600 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names In-Reply-To: <95e76d821df3405eb58dcb116081b82b@EX2.corp.digicert.com> References: <95e76d821df3405eb58dcb116081b82b@EX2.corp.digicert.com> Message-ID: I'll voice my support for this. =) -tom On 12 February 2015 at 20:26, Jeremy Rowley wrote: > DigiCert votes "Yes" > > > > From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On > Behalf Of Jeremy Rowley > Sent: Tuesday, February 10, 2015 11:39 AM > To: public at cabforum.org > Subject: [cabfpub] Ballot 144 - Validation rules for .onion names > > > > Here's the ballot with the two typos fixed: > > > > Applicants want a CA-signed .onion address for several reasons, including: > > - Powerful web platform features are restricted to secure > origins, which are currently not available to onion names (in part, because > of the lack of IANA registration). Permitting EV certs for onion names will > help provide a secure origin for the service, moving onion towards use of > powerful web platform features. > > - Currently, access to .onion names over https from a standard > browser results in the standard existing 'Invalid Certificate' warning. > Training users to click through security warnings lowers the value of these > warnings and will cause users to miss important security information. > Removing these warnings for the user, through use of a digital certificate, > will help users recognize and avoid real MITM attacks. > > - The public needs attribution of ownership of the .onion > address to differentiate onion services, including potential phishing > services. Because onion names are not easily recognizable strings, providing > the public with additional information about the operator has significant > security improvements, especially in regions where use of the incorrect name > could have lethal consequences. > > > > The following motion has been proposed by Jeremy Rowley of DigiCert and > endorsed by Ryan Sleevi of Google and Wayne Thayer of GoDaddy. > > > > --------------------- > > Motion Starts > > --------------------- > > > > 1) Amend Section 9.2.1 of the Baseline Requirements v. 1.2.3 as follows: > > 9.2.1 Subject Alternative Name Extension > > Certificate Field: extensions:subjectAltName > > Required/Optional: Required > > Contents: This 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. The CA MUST confirm that the > Applicant controls the Fully-Qualified Domain Name or IP address or has been > granted the right to use it by the Domain Name Registrant or IP address > assignee, as appropriate. > > > > Wildcard FQDNs are permitted. As of the Effective Date of these > Requirements, prior to the issuance of a Certificate with a > subjectAlternativeName extension or Subject commonName field containing a > Reserved IP Address or Internal Name, the CA SHALL notify the Applicant that > the use of such Certificates has been deprecated by the CA / Browser Forum > and that the practice will be eliminated by October 2016. Also as of the > Effective Date, the CA SHALL NOT issue a certificate with an Expiry Date > later than 1 November 2015 with a subjectAlternativeName extension or > Subject commonName field containing a Reserved IP Address or Internal Name. > Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose > subjectAlternativeName extension or Subject commonName field contains a > Reserved IP Address or Internal Name. Effective May 1, 2015, each CA SHALL > revoke all unexpired Certificates with an Internal Name using onion as the > right-most label in an entry in the subjectAltName Extension or commonName > field unless such Certificate was issued in accordance with Appendix F of > the EV Guidelines. > > > > 2) Amend Section 9.2.2 and 11.7.1 of the Guidelines for the Issuance and > Management of Extended Validation Certificates v1.5.2 as follows: > > > > 9.2.2. Subject Alternative Name Extension Certificate field: > subjectAltName:dNSName > > Required/Optional: Required > > Contents: This extension MUST contain one or more host Domain Name(s) owned > or controlled by the Subject and to be associated with the Subject's server. > Such server MAY be owned and operated by the Subject or another entity > (e.g., a hosting service). Wildcard certificates are not allowed for EV > Certificates except as permitted under Appendix F. > > > > 11.7 Verification of Applicant's Domain Name > > > > 11.7.1. Verification Requirements > > > > (1) For each Fully-Qualified Domain Name listed in a Certificate, other than > a Domain Name with .onion in the right-most label of the Domain Name, the CA > SHALL confirm that, as of the date the Certificate was issued, the Applicant > (or the Applicant's Parent Company, Subsidiary Company, or Affiliate, > collectively referred to as "Applicant" for the purposes of this section) > either is the Domain Name Registrant or has control over the FQDN using a > procedure specified in Section 11.1.1 of the Baseline Requirements, except > that a CA MAY NOT verify a domain using the procedure described 11.1.1(7). > For a Certificate issued to a Domain Name with .onion in the right-most > label of the Domain Name, the CA SHALL confirm that, as of the date the > Certificate was issued, the Applicant's control over the .onion Domain Name > in accordance with Appendix F. > > > > (2) Mixed Character Set Domain Names: EV Certificates MAY include Domain > Names containing mixed character sets only in compliance with the rules set > forth by the domain registrar. The CA MUST visually compare any Domain Names > with mixed character sets with known high risk domains. If a similarity is > found, then the EV Certificate Request MUST be flagged as High Risk. The CA > must perform reasonably appropriate additional authentication and > verification to be certain beyond reasonable doubt that the Applicant and > the target in question are the same organization. > > > > 3) Add a new Appendix F to the Guidelines for the Issuance and Management of > Extended Validation Certificates v1.5.2: > > > > Appendix F - Issuance of Certificates for .onion Domain Names > > > > A CA may issue an EV Certificate with .onion in the right-most label of the > Domain Name provided that issuance complies with the requirements set forth > in this Appendix: > > 1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) > > The CAB Forum has created an extension of the TBSCertificate for use in > conveying hashes of keys related to .onion addresses. The Tor Service > Descriptor Hash extension has the following format: > > > > cabf-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 } > > > > TorServiceDescriptorSyntax ::= > > SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash > > > > TorServiceDescriptorHash:: = SEQUENCE { > > onionURI UTF8String > > algorithm AlgorithmIdentifier > > subjectPublicKeyHash BIT STRING } > > > > Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 6234) > performed over the DER-encoding of an ASN.1 SubjectPublicKey of the .onion > service and SubjectPublicKeyHash is the hash output. > > > > 2. The CA MUST verify the Applicant's control over the .onion Domain > Name using one of the following: > > > > a. The CA MAY verify the Applicant's control over the .onion service by > posting a specific value at a well-known URL under RFC5785. > > > > b. The CA MAY verify the Applicant's control over the .onion service by > having the Applicant provide a Certificate Request signed using the .onion > public key if the Attributes section of the certificationRequestInfo > contains: > > > > (i) A caSigningNonce attribute that 1) contains a single value > with at least 64-bits of entropy, 2) is generated by the CA, and 3) > delivered to the Applicant through a Verified Method of Communication and > > (ii) An applicantSigningNonce attribute that 1) contains a single > value with at least 64-bits of entropy and 2) is generated by the Applicant. > > > > The signing nonce attributes have the following format: > > > > caSigningNonce ATTRIBUTE ::= { > > WITH SYNTAX OCTET STRING > > EQUALITY MATCHING RULE octetStringMatch > > SINGLE VALUE TRUE > > ID { > cabf-caSigningNonce } > > } > > > > cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } > > > > applicantSigningNonce ATTRIBUTE ::= { > > WITH SYNTAX OCTET STRING > > EQUALITY MATCHING RULE octetStringMatch > > SINGLE VALUE TRUE > > ID { > cabf-applicantSigningNonce } > > } > > > > cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 } > > > > 4. Each Certificate that includes a Domain Name where .onion is in the > right-most label of the Domain Name MUST conform to the requirements of > these Guidelines, including the content requirements in Section 9 and > Appendix B of the Baseline Requirements, except that the CA MAY include a > wildcard character in the Subject Alternative Name Extension and Subject > Common Name Field as the left-most character in the .onion Domain Name > provided inclusion of the wildcard character complies with Section 11.1.3 of > the Baseline Requirements. > > > > 5. CAs MUST NOT issue a Certificate that includes a Domain Name where > .onion is in the right-most label of the Domain Name with a validity period > longer than 15 months. Despite Section 9.2.1 of the Baseline Requirements > deprecating the use of Internal Names, a CA MAY issue a Certificate > containing an .onion name with an expiration date later than 1 November 2015 > after (and only if) .onion is officially recognized by the IESG as a > reserved TLD. > > > > 6. On or before May 1, 2015, each CA MUST revoke all Certificates issued > with the Subject Alternative Name extension or Common Name field that > includes a Domain Name where .onion is in the right-most label of the Domain > Name unless the Certificate was issued in compliance with this Appendix F. > > > > ---- > > Motion Ends > > ----- > > The review period for this ballot shall commence at 2200 UTC on Thursday, 4 > February 2015, and will close at 2200 UTC on Thursday, 11 February 2015. > Unless the motion is withdrawn during the review period, the voting period > will start immediately thereafter and will close at 2200 UTC on Monday, 18 > February 2015. Votes must be cast by posting an on-list reply to this > thread. > > A vote in favor of the motion must indicate a clear 'yes' in the response. A > vote against must indicate a clear 'no' in the response. A vote to abstain > must indicate a clear 'abstain' in the response. Unclear responses will not > be counted. The latest vote received from any representative of a voting > member before the close of the voting period will be counted. Voting members > are listed here: https://cabforum.org/members/ > > In order for the motion to be adopted, two thirds or more of the votes cast > by members in the CA category and greater than 50% of the votes cast by > members in the browser category must be in favor. Quorum is currently nine > (9) members- at least nine members must participate in the ballot, either by > voting in favor, voting against, or abstaining. > > > > > > > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public > From gerv at mozilla.org Fri Feb 13 10:08:41 2015 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 13 Feb 2015 17:08:41 +0000 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: References: <54DD1DED.4090105@mozilla.org> <54DD289E.8040304@mozilla.org> <54DDC98E.8020907@mozilla.org> Message-ID: <54DE2F99.9010004@mozilla.org> On 13/02/15 16:52, Tom Ritter wrote: > Tor will consider applying for .onion the next time the TLD rigamarole > comes up. I personally think the RFC reservation is a better, quicker and cheaper route than an ICANN application. > Technically, no. The math makes it diminishingly small, but just on the > verge of attackable. ...by an extremely well-resourced adversary? Was my maths in my email to Kirk correct? If so, that seems currently beyond attackable to me. But perhaps I missed something. Gerv From tom at ritter.vg Fri Feb 13 10:12:06 2015 From: tom at ritter.vg (Tom Ritter) Date: Fri, 13 Feb 2015 11:12:06 -0600 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: <54DE2F99.9010004@mozilla.org> References: <54DD1DED.4090105@mozilla.org> <54DD289E.8040304@mozilla.org> <54DDC98E.8020907@mozilla.org> <54DE2F99.9010004@mozilla.org> Message-ID: On 13 February 2015 at 11:08, Gervase Markham wrote: > On 13/02/15 16:52, Tom Ritter wrote: >> Tor will consider applying for .onion the next time the TLD rigamarole >> comes up. > > I personally think the RFC reservation is a better, quicker and cheaper > route than an ICANN application. > >> Technically, no. The math makes it diminishingly small, but just on the >> verge of attackable. > > ...by an extremely well-resourced adversary? Was my maths in my email to > Kirk correct? If so, that seems currently beyond attackable to me. But > perhaps I missed something. No, I think it is correct. And yes, a well-resourced adversary. I think I've seen estimates that the bitcoin network as a whole turns over 2^80 in some reasonable amount of time; government agencies; a very large botnet; someone at Google gets bored ;) -tom From gerv at mozilla.org Fri Feb 13 10:18:13 2015 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 13 Feb 2015 17:18:13 +0000 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: References: <54DD1DED.4090105@mozilla.org> <54DD289E.8040304@mozilla.org> <54DDC98E.8020907@mozilla.org> <54DE2F99.9010004@mozilla.org> Message-ID: <54DE31D5.5030306@mozilla.org> On 13/02/15 17:12, Tom Ritter wrote: > No, I think it is correct. And yes, a well-resourced adversary. I > think I've seen estimates that the bitcoin network as a whole turns > over 2^80 in some reasonable amount of time; government agencies; a > very large botnet; someone at Google gets bored ;) 2^80 CPU cycles, hashes, or keypair generations? I estimated keypair generation at 1000 cycles, but it could be more expensive than that. Gerv From TShirley at trustwave.com Fri Feb 13 10:24:54 2015 From: TShirley at trustwave.com (Tim Shirley) Date: Fri, 13 Feb 2015 17:24:54 +0000 Subject: [cabfpub] Domain Validation Revision In-Reply-To: References: Message-ID: <252D51A38EFF0D4B991378E55299BFD15F7AE1AF@SKYMB1.trustwave.com> While we're in this section, do we want to consider removing the "registrant" address from item 3 as one of the WHOIS options? I only mention it because Mozilla lists only the technical and administrative fields as acceptable options at https://wiki.mozilla.org/CA:Problematic_Practices#Email_Address_Prefixes_for_DV_Certs. Or was that simply an oversight on Mozilla's part? I realize specific browser programs can and do make their requirements more stringent than the Baseline Requirements, and that this is not even a requirement from Mozilla as of yet. But that page says discussion is underway to make it mandatory, and if indeed Mozilla does not consider the registrant field to be acceptable for validating domain control, then it might reduce potential confusion to include the same restriction here. Regards, Tim From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Thursday, February 12, 2015 9:55 PM To: CABFPub (public at cabforum.org) Subject: [cabfpub] Domain Validation Revision Attached is a draft proposal from the EV working group about revising the domain validation in the BRs. The intent is 1) to eliminate the "any other option" (as it made domain validation essentially meaningless, 2) tighten up the domain validation language, and 3) permit attorney/accountants to draft the domain authorization document. Note that revising this section will automatically revise domain validation in EV. Also note that this is a draft from the working group and not yet a proposed ballot. Jeremy ________________________________ This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150213/b6d3994d/attachment.html From tom at ritter.vg Fri Feb 13 10:39:35 2015 From: tom at ritter.vg (Tom Ritter) Date: Fri, 13 Feb 2015 11:39:35 -0600 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: <54DE31D5.5030306@mozilla.org> References: <54DD1DED.4090105@mozilla.org> <54DD289E.8040304@mozilla.org> <54DDC98E.8020907@mozilla.org> <54DE2F99.9010004@mozilla.org> <54DE31D5.5030306@mozilla.org> Message-ID: On 13 February 2015 at 11:18, Gervase Markham wrote: > On 13/02/15 17:12, Tom Ritter wrote: >> No, I think it is correct. And yes, a well-resourced adversary. I >> think I've seen estimates that the bitcoin network as a whole turns >> over 2^80 in some reasonable amount of time; government agencies; a >> very large botnet; someone at Google gets bored ;) > > 2^80 CPU cycles, hashes, or keypair generations? I estimated keypair > generation at 1000 cycles, but it could be more expensive than that. Alright, let me do some handwaving and back-of-the-envelope calculations. Bitcoin network appears to be at about 300,000 Trillion hashes/second, and a hash is ~64 cycles, we'll use a key gen as 1000 cycles so a keypair is 15 times as difficult. (pow(2,80) * 15) / (300000 * pow(2,40)) / 3600 / 24 / 365.25 = 1.7412731006160165 years In another expression, the bitcoin network is at 4048030.71 petaflops, which was more than the top 500 public supercomputers in the world combined. Except that's not accurate because it was in 2013 when bitcoin was even smaller. [0] So if you controlled the entire bitcoin network (HAH!), and my back of the envelope handwaving is roughly correct, you could collide a .onion address in about a year, year and a half. If you were Google, and you had the _best_ super computer in the world, it would take you (4048030.71 * 1000) / 54902.4 = ~73,731 times longer[1]. So I came out to be a little more than Gerv (1,000 years vs my 73,000) but either way we're not talking something trivial. Like I said - this is much weaker than we want for our cryptosystems. But it's not so weak that it's practically exploitable today or in the next couple years. If we're still using it in 2 years I'll be very disappointed. And unlike the internet, it is actually much easier to upgrade the whole Tor network in a relative short timespan (6 months-year). -tom [0] http://www.forbes.com/sites/reuvencohen/2013/11/28/global-bitcoin-computing-power-now-256-times-faster-than-top-500-supercomputers-combined/ [1]http://www.top500.org/lists/2014/11/ From kirk_hall at trendmicro.com Fri Feb 13 10:51:28 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Fri, 13 Feb 2015 17:51:28 +0000 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: References: <54DD1DED.4090105@mozilla.org> <54DD289E.8040304@mozilla.org> <54DDC98E.8020907@mozilla.org> <54DE2F99.9010004@mozilla.org> <54DE31D5.5030306@mozilla.org> Message-ID: Terrific calculations, Tom -- but I'm wondering how hard it was for Facebook to get their multiple .onion domains that included "facebook". Yes, I'm concerned about the possibility of an exact clash, but I'm also concerned about the ability of a hacker to get a .onion domain that includes names commonly sought by hackers. Perhaps Tor limit final .onion domains to random letters and numbers using the same pattern scanning methods that CAs use. -----Original Message----- From: Tom Ritter [mailto:tom at ritter.vg] Sent: Friday, February 13, 2015 9:40 AM To: Gervase Markham Cc: Kirk Hall (RD-US); Jeremy Rowley (jeremy.rowley at digicert.com); Ben Wilson (Ben.Wilson at digicert.com); CABFPub (public at cabforum.org) Subject: Re: [cabfpub] Ballot 144 -.onion domains On 13 February 2015 at 11:18, Gervase Markham wrote: > On 13/02/15 17:12, Tom Ritter wrote: >> No, I think it is correct. And yes, a well-resourced adversary. I >> think I've seen estimates that the bitcoin network as a whole turns >> over 2^80 in some reasonable amount of time; government agencies; a >> very large botnet; someone at Google gets bored ;) > > 2^80 CPU cycles, hashes, or keypair generations? I estimated keypair > generation at 1000 cycles, but it could be more expensive than that. Alright, let me do some handwaving and back-of-the-envelope calculations. Bitcoin network appears to be at about 300,000 Trillion hashes/second, and a hash is ~64 cycles, we'll use a key gen as 1000 cycles so a keypair is 15 times as difficult. (pow(2,80) * 15) / (300000 * pow(2,40)) / 3600 / 24 / 365.25 = 1.7412731006160165 years In another expression, the bitcoin network is at 4048030.71 petaflops, which was more than the top 500 public supercomputers in the world combined. Except that's not accurate because it was in 2013 when bitcoin was even smaller. [0] So if you controlled the entire bitcoin network (HAH!), and my back of the envelope handwaving is roughly correct, you could collide a .onion address in about a year, year and a half. If you were Google, and you had the _best_ super computer in the world, it would take you (4048030.71 * 1000) / 54902.4 = ~73,731 times longer[1]. So I came out to be a little more than Gerv (1,000 years vs my 73,000) but either way we're not talking something trivial. Like I said - this is much weaker than we want for our cryptosystems. But it's not so weak that it's practically exploitable today or in the next couple years. If we're still using it in 2 years I'll be very disappointed. And unlike the internet, it is actually much easier to upgrade the whole Tor network in a relative short timespan (6 months-year). -tom [0] http://www.forbes.com/sites/reuvencohen/2013/11/28/global-bitcoin-computing-power-now-256-times-faster-than-top-500-supercomputers-combined/ [1]http://www.top500.org/lists/2014/11/ 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
From gerv at mozilla.org Fri Feb 13 10:58:00 2015 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 13 Feb 2015 17:58:00 +0000 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: References: <54DD1DED.4090105@mozilla.org> <54DD289E.8040304@mozilla.org> <54DDC98E.8020907@mozilla.org> <54DE2F99.9010004@mozilla.org> <54DE31D5.5030306@mozilla.org> Message-ID: <54DE3B28.5030109@mozilla.org> On 13/02/15 17:51, kirk_hall at trendmicro.com wrote: > Terrific calculations, Tom -- but I'm wondering how hard it was for > Facebook to get their multiple .onion domains that included > "facebook". > > Yes, I'm concerned about the possibility of an exact clash, but I'm > also concerned about the ability of a hacker to get a .onion domain > that includes names commonly sought by hackers. Insofar as this issue is in scope for the CAB Forum, why can't we solve it using exactly the same mechanisms we use to solve it for non-onion domain names? Gerv From wthayer at godaddy.com Fri Feb 13 11:03:12 2015 From: wthayer at godaddy.com (Wayne Thayer) Date: Fri, 13 Feb 2015 18:03:12 +0000 Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group In-Reply-To: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> References: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> Message-ID: GoDaddy votes Yes. Thanks, Wayne From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Wednesday, February 04, 2015 2:05 PM To: CABFPub Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group Ballot 143 - Formalization of validation working group ---- Reason ---- In order to address validation issues and inconsistencies in both the SSL Baseline Requirements and the EV Guidelines, the CAB Forum has held an informal working group previously referred to as the Extended Validation Working Group now known as the Validation Working Group, would like to modify its scope to include validation in the Baseline Requirements as well as the EV Guidelines. Jeremy Rowley of DigiCert made the following motion, which was endorsed by Rich Smith of Comodo and Kirk Hall of TrendMicro ---- Motion begins ---- The CA-Browser Forum formally establishes the Validation Working Group as an official working group of the CAB Forum, replacing the previous informal EV working group. The scope of this working group is to address issues arising under adopted CAB Forum standards related to the validation of certificate information and the inclusion of information in certificates. Scope: The Validation Working Group will consider all matters relating to the validation and inclusion of information in certificates under adopted CAB Forum guidelines. Deliverables: The Working Group shall produce one or more documents offering options to the Forum for validation within the scope defined above. ---- Motion Ends ---- The review period for this ballot shall commence at 2200 UTC on 5 Feb 2015, and will close at 2200 UTC on 11 Feb 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on 18 Feb 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150213/7b0b5357/attachment.html From douglas.beattie at globalsign.com Fri Feb 13 11:45:52 2015 From: douglas.beattie at globalsign.com (Doug Beattie) Date: Fri, 13 Feb 2015 18:45:52 +0000 Subject: [cabfpub] Domain Validation Revision In-Reply-To: References: Message-ID: > -----Original Message----- > From: public-bounces at cabforum.org [mailto:public- > bounces at cabforum.org] On Behalf Of Ryan Sleevi > Sent: Thursday, February 12, 2015 10:09 PM > To: Jeremy Rowley > Cc: CABFPub (public at cabforum.org) > Subject: Re: [cabfpub] Domain Validation Revision > > > 8 concerns me for a couple reasons, even though it's moving in the right > direction. > - You require HTTPS, but that seems overkill, when you only need to perform > a TLS handshake. That is, consider a mail server configured for SMTP-S - it > seems that would be a viable configuration Sure, we can change this to be just TLS handshake. > - It would seem that anyone that can get a port forwarded on a particular > address can now get a certificate on that address. For things like STUN-TCP > services, this seems quite bad! We might want to align this with the final approach regarding making a change on the web server at a well-known URI and/or list a small number of approved ports. We'll need to circle back on this later when the other updates are closer to consensus. > - The definition of "test certificate" is, from experience, a bit of a handwave > that varies from CA to CA. It would be nice to put some explicit technical > profile in place here (e.g. a critical poison extension, a requirement that EKUs > are present but not serverAuth/clientAuth, issued from a CA independent of > the issuing CA's 'trusted' hierarchy) that would prevent relying parties from > believing the test certificate is "real" Sure, we can define what we mean by a "test" certificate to cover these. Proposed new wording for item 8): Having the Applicant demonstrate practical control over the FQDN by the Applicant requesting and then installing a Test TLS Certificate issued by the CA on the FQDN which is accessed via a TLS handshake by the CA New Definition in section 4: Test TLS Certificate: A certificate which contains a poison extension, does not have serverAuth/clientAuth, is issued under a root not in browser public key stores, or similar such methods which would render a cert unusable for TLS server use. From kirk_hall at trendmicro.com Fri Feb 13 12:25:06 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Fri, 13 Feb 2015 19:25:06 +0000 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: <54DE3B28.5030109@mozilla.org> References: <54DD1DED.4090105@mozilla.org> <54DD289E.8040304@mozilla.org> <54DDC98E.8020907@mozilla.org> <54DE2F99.9010004@mozilla.org> <54DE31D5.5030306@mozilla.org> <54DE3B28.5030109@mozilla.org> Message-ID: Maybe you're right on that point, Gerv. One other question: Does Tor do revocation checking for .onion certs? I'm guessing not for privacy reasons... I know some browsers have given up some revocation checking (a mistake in my opinion), but if we know an application never checks for revocation as a matter of policy, that would concern me. There would be no way to remove a bad cert (used for fraud or abuse, or misissued to the wrong party) from the Tor system, even if the CA revokes it. -----Original Message----- From: Gervase Markham [mailto:gerv at mozilla.org] Sent: Friday, February 13, 2015 9:58 AM To: Kirk Hall (RD-US); Tom Ritter Cc: Jeremy Rowley (jeremy.rowley at digicert.com); Ben Wilson (Ben.Wilson at digicert.com); CABFPub (public at cabforum.org) Subject: Re: [cabfpub] Ballot 144 -.onion domains On 13/02/15 17:51, kirk_hall at trendmicro.com wrote: > Terrific calculations, Tom -- but I'm wondering how hard it was for > Facebook to get their multiple .onion domains that included > "facebook". > > Yes, I'm concerned about the possibility of an exact clash, but I'm > also concerned about the ability of a hacker to get a .onion domain > that includes names commonly sought by hackers. Insofar as this issue is in scope for the CAB Forum, why can't we solve it using exactly the same mechanisms we use to solve it for non-onion domain names? Gerv 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
From tom at ritter.vg Fri Feb 13 12:38:28 2015 From: tom at ritter.vg (Tom Ritter) Date: Fri, 13 Feb 2015 13:38:28 -0600 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: References: <54DD1DED.4090105@mozilla.org> <54DD289E.8040304@mozilla.org> <54DDC98E.8020907@mozilla.org> <54DE2F99.9010004@mozilla.org> <54DE31D5.5030306@mozilla.org> <54DE3B28.5030109@mozilla.org> Message-ID: On 13 February 2015 at 13:25, kirk_hall at trendmicro.com wrote: > Maybe you're right on that point, Gerv. > > One other question: Does Tor do revocation checking for .onion certs? I'm guessing not for privacy reasons... I know some browsers have given up some revocation checking (a mistake in my opinion), but if we know an application never checks for revocation as a matter of policy, that would concern me. There would be no way to remove a bad cert (used for fraud or abuse, or misissued to the wrong party) from the Tor system, even if the CA revokes it. I do not believe that Tor Browser edits Firefox's configuration for revocation. I expected to see something here: https://gitweb.torproject.org/tor-browser.git/tree/browser/app/profile/000-tor-browser.js?h=tor-browser-31.4.0esr-4.5-1 - but the absence and other bug reports I've seen make me believe it's left as the default. -tom From kirk_hall at trendmicro.com Fri Feb 13 12:42:46 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Fri, 13 Feb 2015 19:42:46 +0000 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: References: <54DD1DED.4090105@mozilla.org> <54DD289E.8040304@mozilla.org> <54DDC98E.8020907@mozilla.org> <54DE2F99.9010004@mozilla.org> <54DE31D5.5030306@mozilla.org> <54DE3B28.5030109@mozilla.org> Message-ID: I'm over my ski tips, but... wouldn't revocation checking (by the user's client) potentially reveal which websites the Tor user is viewing? -----Original Message----- From: Tom Ritter [mailto:tom at ritter.vg] Sent: Friday, February 13, 2015 11:38 AM To: Kirk Hall (RD-US) Cc: Gervase Markham; Jeremy Rowley (jeremy.rowley at digicert.com); Ben Wilson (Ben.Wilson at digicert.com); CABFPub (public at cabforum.org) Subject: Re: [cabfpub] Ballot 144 -.onion domains On 13 February 2015 at 13:25, kirk_hall at trendmicro.com wrote: > Maybe you're right on that point, Gerv. > > One other question: Does Tor do revocation checking for .onion certs? I'm guessing not for privacy reasons... I know some browsers have given up some revocation checking (a mistake in my opinion), but if we know an application never checks for revocation as a matter of policy, that would concern me. There would be no way to remove a bad cert (used for fraud or abuse, or misissued to the wrong party) from the Tor system, even if the CA revokes it. I do not believe that Tor Browser edits Firefox's configuration for revocation. I expected to see something here: https://gitweb.torproject.org/tor-browser.git/tree/browser/app/profile/000-tor-browser.js?h=tor-browser-31.4.0esr-4.5-1 - but the absence and other bug reports I've seen make me believe it's left as the default. -tom 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
From tom at ritter.vg Fri Feb 13 12:51:41 2015 From: tom at ritter.vg (Tom Ritter) Date: Fri, 13 Feb 2015 13:51:41 -0600 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: References: <54DD1DED.4090105@mozilla.org> <54DD289E.8040304@mozilla.org> <54DDC98E.8020907@mozilla.org> <54DE2F99.9010004@mozilla.org> <54DE31D5.5030306@mozilla.org> <54DE3B28.5030109@mozilla.org> Message-ID: On Feb 13, 2015 1:42 PM, "kirk_hall at trendmicro.com" < kirk_hall at trendmicro.com> wrote: > > I'm over my ski tips, but... wouldn't revocation checking (by the user's client) potentially reveal which websites the Tor user is viewing? To the CA? Yes. But you're not going to learn anything other than that a Tor user visited the site at that time. The exit IP is a Tor IP, and TorBrowser is designed to present a uniform presentation to prevent fingerprinting. I think they may even use a different circuit so the IP wouldn't even match the IP the website sees, but I'm not certain. -tom -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150213/5b7c22b8/attachment.html From douglas.beattie at globalsign.com Fri Feb 13 13:27:42 2015 From: douglas.beattie at globalsign.com (Doug Beattie) Date: Fri, 13 Feb 2015 20:27:42 +0000 Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group In-Reply-To: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> References: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> Message-ID: GlobalSign votes YES Doug From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Wednesday, February 4, 2015 4:05 PM To: CABFPub Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group Ballot 143 - Formalization of validation working group ---- Reason ---- In order to address validation issues and inconsistencies in both the SSL Baseline Requirements and the EV Guidelines, the CAB Forum has held an informal working group previously referred to as the Extended Validation Working Group now known as the Validation Working Group, would like to modify its scope to include validation in the Baseline Requirements as well as the EV Guidelines. Jeremy Rowley of DigiCert made the following motion, which was endorsed by Rich Smith of Comodo and Kirk Hall of TrendMicro ---- Motion begins ---- The CA-Browser Forum formally establishes the Validation Working Group as an official working group of the CAB Forum, replacing the previous informal EV working group. The scope of this working group is to address issues arising under adopted CAB Forum standards related to the validation of certificate information and the inclusion of information in certificates. Scope: The Validation Working Group will consider all matters relating to the validation and inclusion of information in certificates under adopted CAB Forum guidelines. Deliverables: The Working Group shall produce one or more documents offering options to the Forum for validation within the scope defined above. ---- Motion Ends ---- The review period for this ballot shall commence at 2200 UTC on 5 Feb 2015, and will close at 2200 UTC on 11 Feb 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on 18 Feb 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150213/d22c9a8b/attachment-0001.html From jodycl at microsoft.com Fri Feb 13 13:28:14 2015 From: jodycl at microsoft.com (Jody Cloutier) Date: Fri, 13 Feb 2015 20:28:14 +0000 Subject: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc In-Reply-To: <763539E260C37C46A0D6B340B5434C3B0ADAE0EB@AEX06.ejsarea.net> References: <763539E260C37C46A0D6B340B5434C3B0ACD81A9@AEX06.ejsarea.net> A <763539E260C37C46A0D6B340B5434C3B0ADAE0EB@AEX06.ejsarea.net> Message-ID: Thank you, Inigo, What seems to be happening is that organizations are applying the ETSI standard in cases in which either there is no National Standards Body, or where the national standards body does not certify the company. Building on the scenario below, Audit Co is not recognized by ISRAC, but Auditor Jones has a CISP certification, which I've already confirmed with ETSI is not sufficient. I think what would help here is to make the requirement much more specific: A Qualified Auditor is limited to an auditor that is employed by a company that is certified by a National Authority listed in either the Members or Associate Members link. This, much simplified language, seems to be what you are saying below, but the current language is such that Audit Co can argue that it can issue an ETSI audit because it's company is certified by another national authority that's not listed on the ETSI webpages anywhere. Jody From: i-barreira at izenpe.net [mailto:i-barreira at izenpe.net] Sent: Friday, February 13, 2015 12:16 AM To: Jody Cloutier; public at cabforum.org Subject: RE: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Dear Jody, I understand your concern because it?s not easy for you to manage all possible combinations regarding ETSI audits in different countries so will try to clarify your example. First of all, no AuditCo has to be member of ETSI, AuditCo can perform ETSI accredited audits without being member of ETSI, they only need to be accredited in their country as stated in Annex E requirements. So, For example, * Company A is a commercial CA that operates in Israel * Auditor Jones works for AuditCo, which is based in Israel * AuditCo is certified by some governmental agency as a qualified auditor IB--> AuditCo has to be accredited under its National Accreditation Body according to ISO 17021. In the case of Israel, to follow the example, in the associated members tab of the EA, you can find the Israeli accreditation body, called ISRAC. Then AuditCo should be listed there and meeting the requirements to perform ETSI audits according to the national scheme indicated by ISRAC * AuditCo is not an ETSI Member or Associate Member IB --> this is not necessary. No need to be an ETSI member to perform ETSI audits * Auditor Jones audits Company A using the ETSI 102042 standard, and Company A sends the auditor's attestation letter to Microsoft as evidence that Company A complied with the Program's requirements. IB--> this is perfectly valid if AuditCo is listed in ISRAC and is allowed to perform ETSI audits. Of course Auditor Jones has to be also accredited to perform these kind of audits, has to be "qualified", so it?s not only the company but also the auditor, but that?s an internal task of the AuditCo. Regarding of being member of not, this is voluntary, they can join ETSI or not and don?t think that solve the problem because joining ETSI does not mean that you?re "qualified" or "accredited" to perform an ETSI audit, it?s just indicate that you belong to a club for example. And of course, if company A needs an auditing company accredited in Israel and there?s none, they can look for in other countries. For example, in Spain there?s no accredited auditing bodies to perform ETSI audits listed in our NAB, called ENAC, so, we, Izenpe, had to look for another option. So, we contacted for the first 6 years with KPMG in the Netherlands, and the last 3, with TUV IT in Germany. And Izenpe has an accredited ETSI audits according to the, right now, German national scheme and we?re listed in Germany. We?ll debate this within ETSI ESI trying to find an easier solution. Regards I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 [Descripci?n: cid:image001.png at 01CE3152.B4804EB0] ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. De: Jody Cloutier [mailto:jodycl at microsoft.com] Enviado el: mi?rcoles, 11 de febrero de 2015 0:32 Para: Barreira Iglesias, I?igo; public at cabforum.org Asunto: RE: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Thank you, Inigo. I think the problem is that, under ETSI, it's difficult to discern what an "equivalent national scheme" is. This sets up the scenario in which an auditor is employed by an organization that is recognized somehow by the government, but is not affiliated with an ETSI member organization (http://www.european-accreditation.org/home ). Microsoft does not know whether or not this auditor is qualified or not. For example, * Company A is a commercial CA that operates in Israel * Auditor Jones works for AuditCo, which is based in Israel * AuditCo is certified by some governmental agency as a qualified auditor * AuditCo is not an ETSI Member or Associate Member * Auditor Jones audits Company A using the ETSI 102042 standard, and Company A sends the auditor's attestation letter to Microsoft as evidence that Company A complied with the Program's requirements. In this scenario, how does Microsoft know that Auditor Jones conducted a proper audit without expending significant resources to determine whether and according to what standard AuditCo and Auditor Jones was certified? Microsoft believes that it would be simpler if the requirements were that the Auditor must work for a company that is affiliated with an ETSI-approved member organization. If Company A needs an auditor and there is no qualified auditor in Israel, the company can use an auditor from a member organization via the cross-border conformity rules. Unless I am fundamentally misunderstanding the rules, the above is something that Microsoft is presently struggling with, and we'd like to try to make the rules easier to understand for potential partners and ourselves. Jody Cloutier Senior Security Program Manager Microsoft Trusted Root Certificate Program jody.cloutier at microsoft.com 425.443.8922 Operating Systems Group Global Risk and Compliance [https://brandtools.microsoft.com/Style%20Library/BT/Images/MicrosoftMasterLogo.png] From: i-barreira at izenpe.net [mailto:i-barreira at izenpe.net] Sent: Tuesday, February 10, 2015 3:09 AM To: Jody Cloutier; public at cabforum.org Subject: RE: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Hi Jody, Regarding your comment on ETSI audits, I have to say that the ETSI audits shall be performed by accredited auditors as mentioned in Annex E of the current ETSI TS 102 042. ETSI audits performed by not accredited auditors shall be considered invalid. Microsoft is accepting ETSI audits since the very beginning in its root program requirements indicating this requirement. ETSI is providing a list of accredited auditors as mere information because has to be maintained by every NAB (National Accreditation Body). It?s true that this has to be improved regarding the new regulation 910/2014 and the new ENs and will take some time, but at the moment, it?s clearly stated that the audits shall be performed by accredited auditors. Don?t hesitate in contacting me for any additional information or help. Sometimes I?ve received some emails from Tom or Kelvin asking for the qualification of some audits, so, as say, you can contact me regarding this issue. Regards I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 [Descripci?n: cid:image001.png at 01CE3152.B4804EB0] ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. De: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] En nombre de Jody Cloutier Enviado el: lunes, 09 de febrero de 2015 18:55 Para: CABFPub (public at cabforum.org) Asunto: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Microsoft comments on Section 17. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150213/588757d3/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 19121 bytes Desc: image001.png Url : https://cabforum.org/pipermail/public/attachments/20150213/588757d3/attachment-0002.png -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 1181 bytes Desc: image002.png Url : https://cabforum.org/pipermail/public/attachments/20150213/588757d3/attachment-0003.png From jodycl at microsoft.com Fri Feb 13 13:29:41 2015 From: jodycl at microsoft.com (Jody Cloutier) Date: Fri, 13 Feb 2015 20:29:41 +0000 Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group In-Reply-To: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> References: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> Message-ID: Microsoft votes yes., From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Wednesday, February 4, 2015 1:05 PM To: CABFPub Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group Ballot 143 - Formalization of validation working group ---- Reason ---- In order to address validation issues and inconsistencies in both the SSL Baseline Requirements and the EV Guidelines, the CAB Forum has held an informal working group previously referred to as the Extended Validation Working Group now known as the Validation Working Group, would like to modify its scope to include validation in the Baseline Requirements as well as the EV Guidelines. Jeremy Rowley of DigiCert made the following motion, which was endorsed by Rich Smith of Comodo and Kirk Hall of TrendMicro ---- Motion begins ---- The CA-Browser Forum formally establishes the Validation Working Group as an official working group of the CAB Forum, replacing the previous informal EV working group. The scope of this working group is to address issues arising under adopted CAB Forum standards related to the validation of certificate information and the inclusion of information in certificates. Scope: The Validation Working Group will consider all matters relating to the validation and inclusion of information in certificates under adopted CAB Forum guidelines. Deliverables: The Working Group shall produce one or more documents offering options to the Forum for validation within the scope defined above. ---- Motion Ends ---- The review period for this ballot shall commence at 2200 UTC on 5 Feb 2015, and will close at 2200 UTC on 11 Feb 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on 18 Feb 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150213/837bcd0d/attachment.html From ben.wilson at digicert.com Fri Feb 13 13:38:57 2015 From: ben.wilson at digicert.com (Ben Wilson) Date: Fri, 13 Feb 2015 20:38:57 +0000 Subject: [cabfpub] [cabfquest] Domain Validation Revision In-Reply-To: <54DE3BBE.9000203@eff.org> References: <54DE3BBE.9000203@eff.org> Message-ID: Forwarding from questions list. From: questions-bounces at cabforum.org [mailto:questions-bounces at cabforum.org] On Behalf Of Jacob Hoffman-Andrews Sent: Friday, February 13, 2015 11:01 AM To: questions at cabforum.org Subject: Re: [cabfquest] [cabfpub] Domain Validation Revision Following up from a thread on cabfpub: On 02/12/2015 07:08 PM, Ryan Sleevi wrote: 8 concerns me for a couple reasons, even though it's moving in the right direction. - You require HTTPS, but that seems overkill, when you only need to perform a TLS handshake. That is, consider a mail server configured for SMTP-S - it seems that would be a viable configuration Agreed. As a concrete example, the ACME spec under discussion at IETF proposes a challenge type called "Domain Validation with Server Name Indication," or DVSNI for short: http://www.ietf.org/id/draft-barnes-acme-01.txt. We believe that DVSNI allows us to offer a higher level of assurance than item (6), "making an agreed-upon change to information found on an online Web page," since some sites allow arbitrary file upload, either by intent or by accident. We're planning to use it for the Let's Encrypt CA for that reason, so we'd like to make sure that item (8) allows for DVSNI. For example, here is a version of item (8) that we think would work: Having the Applicant demonstrate practical control over the FQDN by providing a TLS service on a host found in DNS for the FQDN. The CA SHALL initiate a TLS connection with that host and verify that the response contains unique, unguessable information proposed by the CA, in a well-specified format. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150213/5cabc264/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4954 bytes Desc: not available Url : https://cabforum.org/pipermail/public/attachments/20150213/5cabc264/attachment.bin From md at ssc.lt Fri Feb 13 14:00:24 2015 From: md at ssc.lt (Moudrick M. Dadashov) Date: Fri, 13 Feb 2015 23:00:24 +0200 Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group In-Reply-To: <452C99D20750E74083DBA441FF932385E4162C54@SOTTEXCH10.corp.ad.entrust.com> References: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> <452C99D20750E74083DBA441FF932385E4162C54@SOTTEXCH10.corp.ad.entrust.com> Message-ID: <54DE65E8.20202@ssc.lt> SSC votes: "Yes". Thanks, M.D. On 2/13/2015 3:46 PM, Bruce Morton wrote: > > Entrust votes Yes. > > *From:* public-bounces at cabforum.org > [mailto:public-bounces at cabforum.org] *On Behalf Of *Jeremy Rowley > *Sent:* Wednesday, February 04, 2015 4:05 PM > *To:* CABFPub > *Subject:* [cabfpub] Ballot 143 - Formalization of Validation Working > Group > > Ballot 143 - Formalization of validation working group > > ---- > > Reason > > ---- > > In order to address validation issues and inconsistencies in both the > SSL Baseline Requirements and the EV Guidelines, the CAB Forum has > held an informal working group previously referred to as the Extended > Validation Working Group now known as the Validation Working Group, > would like to modify its scope to include validation in the Baseline > Requirements as well as the EV Guidelines. > > Jeremy Rowley of DigiCert made the following motion, which was > endorsed by Rich Smith of Comodo and Kirk Hall of TrendMicro > > ---- > > Motion begins > > ---- > > The CA-Browser Forum formally establishes the Validation Working Group > as an official working group of the CAB Forum, replacing the previous > informal EV working group. The scope of this working group is to > address issues arising under adopted CAB Forum standards related to > the validation of certificate information and the inclusion of > information in certificates. > > Scope: The Validation Working Group will consider all matters relating > to the validation and inclusion of information in certificates under > adopted CAB Forum guidelines. > > Deliverables: The Working Group shall produce one or more documents > offering options to the Forum for validation within the scope defined > above. > > ---- > > Motion Ends > > ---- > > The review period for this ballot shall commence at 2200 UTC on 5 Feb > 2015, and will close at 2200 UTC on 11 Feb 2015. Unless the motion is > withdrawn during the review period, the voting period will start > immediately thereafter and will close at 2200 UTC on 18 Feb 2015. > Votes must be cast by posting an on-list reply to this thread. > > A vote in favor of the motion must indicate a clear 'yes' in the > response. A vote against must indicate a clear 'no' in the response. A > vote to abstain must indicate a clear 'abstain' in the response. > Unclear responses will not be counted. The latest vote received from > any representative of a voting member before the close of the voting > period will be counted. Voting members are listed here: > https://cabforum.org/members/ > > In order for the motion to be adopted, two thirds or more of the votes > cast by members in the CA category and greater than 50% of the votes > cast by members in the browser category must be in favor. Quorum is > currently nine (9) members? at least nine members must participate in > the ballot, either by voting in favor, voting against, or abstaining. > > > > _______________________________________________ > 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/20150213/993427ad/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3653 bytes Desc: S/MIME Cryptographic Signature Url : https://cabforum.org/pipermail/public/attachments/20150213/993427ad/attachment-0001.bin From eddy_nigg at startcom.org Fri Feb 13 14:10:53 2015 From: eddy_nigg at startcom.org (Eddy Nigg) Date: Fri, 13 Feb 2015 23:10:53 +0200 Subject: [cabfpub] Ballot 143 In-Reply-To: <68a8241d150c4bc6bd624e08988e44fa@EX2.corp.digicert.com> References: <68a8241d150c4bc6bd624e08988e44fa@EX2.corp.digicert.com> Message-ID: <54DE685D.2000500@startcom.org> There appears to be a mistake with ballot number 143 which was previously assigned to "Remove the operational existence requirement for Government Entities" and later "Formalization of validation working group". Jeremy I believe both were initiated by you? -- Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. XMPP: startcom at startcom.org Blog: Join the Revolution! Twitter: Follow Me -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150213/0d14fd28/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4313 bytes Desc: S/MIME Cryptographic Signature Url : https://cabforum.org/pipermail/public/attachments/20150213/0d14fd28/attachment.bin From Dean_Coclin at symantec.com Fri Feb 13 14:31:20 2015 From: Dean_Coclin at symantec.com (Dean Coclin) Date: Fri, 13 Feb 2015 13:31:20 -0800 Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group In-Reply-To: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> References: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> Message-ID: <14D026C7F297AD44AC82578DD818CDD038EF1EA29E@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> Symantec votes YES. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Wednesday, February 04, 2015 4:05 PM To: CABFPub Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group Ballot 143 - Formalization of validation working group ---- Reason ---- In order to address validation issues and inconsistencies in both the SSL Baseline Requirements and the EV Guidelines, the CAB Forum has held an informal working group previously referred to as the Extended Validation Working Group now known as the Validation Working Group, would like to modify its scope to include validation in the Baseline Requirements as well as the EV Guidelines. Jeremy Rowley of DigiCert made the following motion, which was endorsed by Rich Smith of Comodo and Kirk Hall of TrendMicro ---- Motion begins ---- The CA-Browser Forum formally establishes the Validation Working Group as an official working group of the CAB Forum, replacing the previous informal EV working group. The scope of this working group is to address issues arising under adopted CAB Forum standards related to the validation of certificate information and the inclusion of information in certificates. Scope: The Validation Working Group will consider all matters relating to the validation and inclusion of information in certificates under adopted CAB Forum guidelines. Deliverables: The Working Group shall produce one or more documents offering options to the Forum for validation within the scope defined above. ---- Motion Ends ---- The review period for this ballot shall commence at 2200 UTC on 5 Feb 2015, and will close at 2200 UTC on 11 Feb 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on 18 Feb 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150213/e720aaca/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6130 bytes Desc: not available Url : https://cabforum.org/pipermail/public/attachments/20150213/e720aaca/attachment-0001.bin From eddy_nigg at startcom.org Fri Feb 13 14:47:34 2015 From: eddy_nigg at startcom.org (Eddy Nigg) Date: Fri, 13 Feb 2015 23:47:34 +0200 Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group In-Reply-To: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> References: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> Message-ID: <54DE70F6.1070706@startcom.org> On 02/04/2015 11:05 PM, Jeremy Rowley wrote: > > Ballot 143 - Formalization of validation working group > StartCom votes YES to this ballot. -- Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. XMPP: startcom at startcom.org Blog: Join the Revolution! Twitter: Follow Me -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150213/8bbcf206/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4313 bytes Desc: S/MIME Cryptographic Signature Url : https://cabforum.org/pipermail/public/attachments/20150213/8bbcf206/attachment.bin From Dean_Coclin at symantec.com Fri Feb 13 15:33:48 2015 From: Dean_Coclin at symantec.com (Dean Coclin) Date: Fri, 13 Feb 2015 14:33:48 -0800 Subject: [cabfpub] IPv6 support References: <14D026C7F297AD44AC82578DD818CDD038EEF0BA5B@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C01141460BD37468D1@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <14D026C7F297AD44AC82578DD818CDD038EEF0BFAD@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> Message-ID: <14D026C7F297AD44AC82578DD818CDD038EF1EA316@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> Ryan, As discussed on the last CA/B call, I was asked to poll the CASC members on their support of IPv6. The results are below. You'll probably realize after reading this that there isn't much actionable material here as many members are "scoping" or "waiting for info" without any concrete response dates. We'll keep this tally going and update as we get more info. Globalsign: Yes, can support Symantec: We don't support this today. We've received very little demand for it from customers, but we're in the process of scoping out the effort. Comodo: Yes, for CRL and OCSP Trend Micro: Yes GoDaddy: Waiting for info from network team Entrust: Yes for CRL and OCSP. Trustwave: We don't support this today. Just started scoping the effort. Not many requests for this Digicert: We currently do not support it. Our connectivity providers support it, and it could be done with CRLs and OCSP, but we'd need to look for any gotchas before pulling the trigger. We've only had a couple of customers ask whether we support it. Thanks, Dean -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150213/3a1c1ce1/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6130 bytes Desc: not available Url : https://cabforum.org/pipermail/public/attachments/20150213/3a1c1ce1/attachment-0001.bin From kirk_hall at trendmicro.com Fri Feb 13 15:52:38 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Fri, 13 Feb 2015 22:52:38 +0000 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names Message-ID: Trend Micro abstains Kirk R. Hall Operations Director, Trust Services Trend Micro +1.503.753.3088 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
-------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150213/166cf32e/attachment.html From eddy_nigg at startcom.org Fri Feb 13 15:58:11 2015 From: eddy_nigg at startcom.org (Eddy Nigg) Date: Sat, 14 Feb 2015 00:58:11 +0200 Subject: [cabfpub] IPv6 support In-Reply-To: <14D026C7F297AD44AC82578DD818CDD038EF1EA316@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> References: <14D026C7F297AD44AC82578DD818CDD038EEF0BA5B@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C01141460BD37468D1@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <14D026C7F297AD44AC82578DD818CDD038EEF0BFAD@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> <14D026C7F297AD44AC82578DD818CDD038EF1EA316@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> Message-ID: <54DE8183.1060204@startcom.org> On 02/14/2015 12:33 AM, Dean Coclin wrote: > You'll probably realize after reading this that there isn't much > actionable material here as many members are "scoping" or "waiting for > info" without any concrete response dates. We'll keep this tally > going and update as we get more info. > > Globalsign: Yes, can support > > Symantec: We don't support this today. We've received very little > demand for it from customers, but we're in the process of scoping out > the effort. > > Comodo:Yes, for CRL and OCSP > > TrendMicro:Yes > GoDaddy: Waiting for info from network team > > Entrust:Yes for CRL and OCSP. > > Trustwave:We don't support this today. Just started scoping the > effort. Not many requests for this > > Digicert:We currently do not support it. Our connectivity providers > support it, and it could be done with CRLs and OCSP, but we'd need to > look for any gotchas before pulling the trigger. We've only had a > couple of customers ask whether we support it. > To add StartCom to the list, we could support it for almost everything, but we have some historical CRL distribution points that can't support IPv6 for now. It seems that OCSP would work, but CRLs not 100%. Same as with Digicert, demand for IPv6 has been so low that we haven't invested into it so far. -- Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. XMPP: startcom at startcom.org Blog: Join the Revolution! Twitter: Follow Me -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150214/c0204ff2/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4313 bytes Desc: S/MIME Cryptographic Signature Url : https://cabforum.org/pipermail/public/attachments/20150214/c0204ff2/attachment.bin From wthayer at godaddy.com Fri Feb 13 17:02:09 2015 From: wthayer at godaddy.com (Wayne Thayer) Date: Sat, 14 Feb 2015 00:02:09 +0000 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names In-Reply-To: References: Message-ID: GoDaddy votes Yes. Thanks, Wayne From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Tuesday, February 10, 2015 11:39 AM To: public at cabforum.org Subject: [cabfpub] Ballot 144 - Validation rules for .onion names Here's the ballot with the two typos fixed: Applicants want a CA-signed .onion address for several reasons, including: - Powerful web platform features are restricted to secure origins, which are currently not available to onion names (in part, because of the lack of IANA registration). Permitting EV certs for onion names will help provide a secure origin for the service, moving onion towards use of powerful web platform features. - Currently, access to .onion names over https from a standard browser results in the standard existing 'Invalid Certificate' warning. Training users to click through security warnings lowers the value of these warnings and will cause users to miss important security information. Removing these warnings for the user, through use of a digital certificate, will help users recognize and avoid real MITM attacks. - The public needs attribution of ownership of the .onion address to differentiate onion services, including potential phishing services. Because onion names are not easily recognizable strings, providing the public with additional information about the operator has significant security improvements, especially in regions where use of the incorrect name could have lethal consequences. The following motion has been proposed by Jeremy Rowley of DigiCert and endorsed by Ryan Sleevi of Google and Wayne Thayer of GoDaddy. --------------------- Motion Starts --------------------- 1) Amend Section 9.2.1 of the Baseline Requirements v. 1.2.3 as follows: 9.2.1 Subject Alternative Name Extension Certificate Field: extensions:subjectAltName Required/Optional: Required Contents: This 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. The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate. Wildcard FQDNs are permitted. As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name, the CA SHALL notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016. Also as of the Effective Date, the CA SHALL NOT issue a certificate with an Expiry Date later than 1 November 2015 with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name. Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Name. Effective May 1, 2015, each CA SHALL revoke all unexpired Certificates with an Internal Name using onion as the right-most label in an entry in the subjectAltName Extension or commonName field unless such Certificate was issued in accordance with Appendix F of the EV Guidelines. 2) Amend Section 9.2.2 and 11.7.1 of the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2 as follows: 9.2.2. Subject Alternative Name Extension Certificate field: subjectAltName:dNSName Required/Optional: Required Contents: This extension MUST contain one or more host Domain Name(s) owned or controlled by the Subject and to be associated with the Subject's server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). Wildcard certificates are not allowed for EV Certificates except as permitted under Appendix F. 11.7 Verification of Applicant's Domain Name 11.7.1. Verification Requirements (1) For each Fully-Qualified Domain Name listed in a Certificate, other than a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant (or the Applicant's Parent Company, Subsidiary Company, or Affiliate, collectively referred to as "Applicant" for the purposes of this section) either is the Domain Name Registrant or has control over the FQDN using a procedure specified in Section 11.1.1 of the Baseline Requirements, except that a CA MAY NOT verify a domain using the procedure described 11.1.1(7). For a Certificate issued to a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant's control over the .onion Domain Name in accordance with Appendix F. (2) Mixed Character Set Domain Names: EV Certificates MAY include Domain Names containing mixed character sets only in compliance with the rules set forth by the domain registrar. The CA MUST visually compare any Domain Names with mixed character sets with known high risk domains. If a similarity is found, then the EV Certificate Request MUST be flagged as High Risk. The CA must perform reasonably appropriate additional authentication and verification to be certain beyond reasonable doubt that the Applicant and the target in question are the same organization. 3) Add a new Appendix F to the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2: Appendix F - Issuance of Certificates for .onion Domain Names A CA may issue an EV Certificate with .onion in the right-most label of the Domain Name provided that issuance complies with the requirements set forth in this Appendix: 1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) The CAB Forum has created an extension of the TBSCertificate for use in conveying hashes of keys related to .onion addresses. The Tor Service Descriptor Hash extension has the following format: cabf-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 } TorServiceDescriptorSyntax ::= SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash TorServiceDescriptorHash:: = SEQUENCE { onionURI UTF8String algorithm AlgorithmIdentifier subjectPublicKeyHash BIT STRING } Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 6234) performed over the DER-encoding of an ASN.1 SubjectPublicKey of the .onion service and SubjectPublicKeyHash is the hash output. 2. The CA MUST verify the Applicant's control over the .onion Domain Name using one of the following: a. The CA MAY verify the Applicant's control over the .onion service by posting a specific value at a well-known URL under RFC5785. b. The CA MAY verify the Applicant's control over the .onion service by having the Applicant provide a Certificate Request signed using the .onion public key if the Attributes section of the certificationRequestInfo contains: (i) A caSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy, 2) is generated by the CA, and 3) delivered to the Applicant through a Verified Method of Communication and (ii) An applicantSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy and 2) is generated by the Applicant. The signing nonce attributes have the following format: caSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-caSigningNonce } } cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } applicantSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-applicantSigningNonce } } cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 } 4. Each Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name MUST conform to the requirements of these Guidelines, including the content requirements in Section 9 and Appendix B of the Baseline Requirements, except that the CA MAY include a wildcard character in the Subject Alternative Name Extension and Subject Common Name Field as the left-most character in the .onion Domain Name provided inclusion of the wildcard character complies with Section 11.1.3 of the Baseline Requirements. 5. CAs MUST NOT issue a Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name with a validity period longer than 15 months. Despite Section 9.2.1 of the Baseline Requirements deprecating the use of Internal Names, a CA MAY issue a Certificate containing an .onion name with an expiration date later than 1 November 2015 after (and only if) .onion is officially recognized by the IESG as a reserved TLD. 6. On or before May 1, 2015, each CA MUST revoke all Certificates issued with the Subject Alternative Name extension or Common Name field that includes a Domain Name where .onion is in the right-most label of the Domain Name unless the Certificate was issued in compliance with this Appendix F. ---- Motion Ends ----- The review period for this ballot shall commence at 2200 UTC on Thursday, 4 February 2015, and will close at 2200 UTC on Thursday, 11 February 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on Monday, 18 February 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150214/a50f8307/attachment-0001.html From Patrick.Tronnier at oati.net Fri Feb 13 20:53:43 2015 From: Patrick.Tronnier at oati.net (Patrick Tronnier) Date: Sat, 14 Feb 2015 03:53:43 +0000 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names In-Reply-To: <5c04557077cf4564979bc37e501297de@EX2.corp.digicert.com> References: , <5c04557077cf4564979bc37e501297de@EX2.corp.digicert.com> Message-ID: <4F1C24C0-B730-495E-AE84-098FC341323E@oati.net> OATI abstains. Thanks, With kind regards, Patrick Tronnier Principal Security Architect & Sr. Director of Quality Assurance Phone: 763.201.2000 Fax: 763.201.5333 Direct Line: 763.201.2052 Open Access Technology International, Inc. 3660 Technology Drive NE, Minneapolis, MN 55418 CONFIDENTIAL INFORMATION: This email and any attachment(s) contain confidential and/or proprietary information of Open Access Technology International, Inc. Do not copy or distribute without the prior written consent of OATI. If you are not a named recipient to the message, please notify the sender immediately and do not retain the message in any form, printed or electronic. On Feb 10, 2015, at 3:03 PM, Ben Wilson > wrote: I?ll post this to the public page with a correction stating that the review period ends and the voting period of the ballot begins to run from Wednesday, 11 Feb., to Wednesday, 18 Feb. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Tuesday, February 10, 2015 11:39 AM To: public at cabforum.org Subject: [cabfpub] Ballot 144 - Validation rules for .onion names Here?s the ballot with the two typos fixed: Applicants want a CA-signed .onion address for several reasons, including: - Powerful web platform features are restricted to secure origins, which are currently not available to onion names (in part, because of the lack of IANA registration). Permitting EV certs for onion names will help provide a secure origin for the service, moving onion towards use of powerful web platform features. - Currently, access to .onion names over https from a standard browser results in the standard existing 'Invalid Certificate' warning. Training users to click through security warnings lowers the value of these warnings and will cause users to miss important security information. Removing these warnings for the user, through use of a digital certificate, will help users recognize and avoid real MITM attacks. - The public needs attribution of ownership of the .onion address to differentiate onion services, including potential phishing services. Because onion names are not easily recognizable strings, providing the public with additional information about the operator has significant security improvements, especially in regions where use of the incorrect name could have lethal consequences. The following motion has been proposed by Jeremy Rowley of DigiCert and endorsed by Ryan Sleevi of Google and Wayne Thayer of GoDaddy. --------------------- Motion Starts --------------------- 1) Amend Section 9.2.1 of the Baseline Requirements v. 1.2.3 as follows: 9.2.1 Subject Alternative Name Extension Certificate Field: extensions:subjectAltName Required/Optional: Required Contents: This 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. The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate. Wildcard FQDNs are permitted. As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name, the CA SHALL notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016. Also as of the Effective Date, the CA SHALL NOT issue a certificate with an Expiry Date later than 1 November 2015 with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name. Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Name. Effective May 1, 2015, each CA SHALL revoke all unexpired Certificates with an Internal Name using onion as the right-most label in an entry in the subjectAltName Extension or commonName field unless such Certificate was issued in accordance with Appendix F of the EV Guidelines. 2) Amend Section 9.2.2 and 11.7.1 of the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2 as follows: 9.2.2. Subject Alternative Name Extension Certificate field: subjectAltName:dNSName Required/Optional: Required Contents: This extension MUST contain one or more host Domain Name(s) owned or controlled by the Subject and to be associated with the Subject?s server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). Wildcard certificates are not allowed for EV Certificates except as permitted under Appendix F. 11.7 Verification of Applicant?s Domain Name 11.7.1. Verification Requirements (1) For each Fully-Qualified Domain Name listed in a Certificate, other than a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant (or the Applicant?s Parent Company, Subsidiary Company, or Affiliate, collectively referred to as ?Applicant? for the purposes of this section) either is the Domain Name Registrant or has control over the FQDN using a procedure specified in Section 11.1.1 of the Baseline Requirements, except that a CA MAY NOT verify a domain using the procedure described 11.1.1(7). For a Certificate issued to a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant?s control over the .onion Domain Name in accordance with Appendix F. (2) Mixed Character Set Domain Names: EV Certificates MAY include Domain Names containing mixed character sets only in compliance with the rules set forth by the domain registrar. The CA MUST visually compare any Domain Names with mixed character sets with known high risk domains. If a similarity is found, then the EV Certificate Request MUST be flagged as High Risk. The CA must perform reasonably appropriate additional authentication and verification to be certain beyond reasonable doubt that the Applicant and the target in question are the same organization. 3) Add a new Appendix F to the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2: Appendix F ? Issuance of Certificates for .onion Domain Names A CA may issue an EV Certificate with .onion in the right-most label of the Domain Name provided that issuance complies with the requirements set forth in this Appendix: 1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) The CAB Forum has created an extension of the TBSCertificate for use in conveying hashes of keys related to .onion addresses. The Tor Service Descriptor Hash extension has the following format: cabf-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 } TorServiceDescriptorSyntax ::= SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash TorServiceDescriptorHash:: = SEQUENCE { onionURI UTF8String algorithm AlgorithmIdentifier subjectPublicKeyHash BIT STRING } Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 6234) performed over the DER-encoding of an ASN.1 SubjectPublicKey of the .onion service and SubjectPublicKeyHash is the hash output. 2. The CA MUST verify the Applicant?s control over the .onion Domain Name using one of the following: a. The CA MAY verify the Applicant?s control over the .onion service by posting a specific value at a well-known URL under RFC5785. b. The CA MAY verify the Applicant?s control over the .onion service by having the Applicant provide a Certificate Request signed using the .onion public key if the Attributes section of the certificationRequestInfo contains: (i) A caSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy, 2) is generated by the CA, and 3) delivered to the Applicant through a Verified Method of Communication and (ii) An applicantSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy and 2) is generated by the Applicant. The signing nonce attributes have the following format: caSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-caSigningNonce } } cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } applicantSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-applicantSigningNonce } } cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 } 4. Each Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name MUST conform to the requirements of these Guidelines, including the content requirements in Section 9 and Appendix B of the Baseline Requirements, except that the CA MAY include a wildcard character in the Subject Alternative Name Extension and Subject Common Name Field as the left-most character in the .onion Domain Name provided inclusion of the wildcard character complies with Section 11.1.3 of the Baseline Requirements. 5. CAs MUST NOT issue a Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name with a validity period longer than 15 months. Despite Section 9.2.1 of the Baseline Requirements deprecating the use of Internal Names, a CA MAY issue a Certificate containing an .onion name with an expiration date later than 1 November 2015 after (and only if) .onion is officially recognized by the IESG as a reserved TLD. 6. On or before May 1, 2015, each CA MUST revoke all Certificates issued with the Subject Alternative Name extension or Common Name field that includes a Domain Name where .onion is in the right-most label of the Domain Name unless the Certificate was issued in compliance with this Appendix F. ---- Motion Ends ----- The review period for this ballot shall commence at 2200 UTC on Thursday, 4 February 2015, and will close at 2200 UTC on Thursday, 11 February 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on Monday, 18 February 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members? at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. _______________________________________________ Public mailing list Public at cabforum.org https://cabforum.org/mailman/listinfo/public From richard at wosign.com Fri Feb 13 20:52:38 2015 From: richard at wosign.com (Richard Wang) Date: Sat, 14 Feb 2015 03:52:38 +0000 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names In-Reply-To: References: Message-ID: <84AFFBBCB7046F44B89AAD7AC09C4A06153353E5@ex2.corp.wosign.com> WoSign vote ?abstains? Best Regards, Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150214/ef9cc375/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5075 bytes Desc: not available Url : https://cabforum.org/pipermail/public/attachments/20150214/ef9cc375/attachment.bin From richard at wosign.com Fri Feb 13 20:53:37 2015 From: richard at wosign.com (Richard Wang) Date: Sat, 14 Feb 2015 03:53:37 +0000 Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group In-Reply-To: <54DE70F6.1070706@startcom.org> References: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> <54DE70F6.1070706@startcom.org> Message-ID: <84AFFBBCB7046F44B89AAD7AC09C4A0615335403@ex2.corp.wosign.com> WoSign votes YES Best Regards, Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150214/f7f382f2/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5075 bytes Desc: not available Url : https://cabforum.org/pipermail/public/attachments/20150214/f7f382f2/attachment-0001.bin From eddy_nigg at startcom.org Sun Feb 15 11:01:57 2015 From: eddy_nigg at startcom.org (Eddy Nigg) Date: Sun, 15 Feb 2015 20:01:57 +0200 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names In-Reply-To: References: Message-ID: <54E0DF15.6060006@startcom.org> StartCom abstains as well for now. On 02/14/2015 12:52 AM, kirk_hall at trendmicro.com wrote: > > Trend Micro abstains > > */Kirk R. Hall/* > > Operations Director, Trust Services > > Trend Micro > > +1.503.753.3088 > -- Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. XMPP: startcom at startcom.org Blog: Join the Revolution! Twitter: Follow Me -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150215/7a605324/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4313 bytes Desc: S/MIME Cryptographic Signature Url : https://cabforum.org/pipermail/public/attachments/20150215/7a605324/attachment.bin From Dean_Coclin at symantec.com Sun Feb 15 13:50:13 2015 From: Dean_Coclin at symantec.com (Dean Coclin) Date: Sun, 15 Feb 2015 12:50:13 -0800 Subject: [cabfpub] Minutes of recent CA/B Forum meetings Message-ID: <14D026C7F297AD44AC82578DD818CDD038EF1EA3EE@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> It occurred to me that I may not have sent to the public list the minutes from recent meetings. They can be found here: https://cabforum.org/2015/01/22/2015-01-22-minutes/ https://cabforum.org/2015/01/08/2015-01-08-minutes/ All previous meeting minutes are located here: https://cabforum.org/category/proceedings/minutes/ Dean Coclin CA/B Forum Chair -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150215/9139383f/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6130 bytes Desc: not available Url : https://cabforum.org/pipermail/public/attachments/20150215/9139383f/attachment.bin From Dean_Coclin at symantec.com Sun Feb 15 14:39:31 2015 From: Dean_Coclin at symantec.com (Dean Coclin) Date: Sun, 15 Feb 2015 13:39:31 -0800 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names In-Reply-To: References: Message-ID: <14D026C7F297AD44AC82578DD818CDD038EF1EA3F7@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> Symantec votes YES From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Tuesday, February 10, 2015 1:39 PM To: public at cabforum.org Subject: [cabfpub] Ballot 144 - Validation rules for .onion names Here's the ballot with the two typos fixed: Applicants want a CA-signed .onion address for several reasons, including: - Powerful web platform features are restricted to secure origins, which are currently not available to onion names (in part, because of the lack of IANA registration). Permitting EV certs for onion names will help provide a secure origin for the service, moving onion towards use of powerful web platform features. - Currently, access to .onion names over https from a standard browser results in the standard existing 'Invalid Certificate' warning. Training users to click through security warnings lowers the value of these warnings and will cause users to miss important security information. Removing these warnings for the user, through use of a digital certificate, will help users recognize and avoid real MITM attacks. - The public needs attribution of ownership of the .onion address to differentiate onion services, including potential phishing services. Because onion names are not easily recognizable strings, providing the public with additional information about the operator has significant security improvements, especially in regions where use of the incorrect name could have lethal consequences. The following motion has been proposed by Jeremy Rowley of DigiCert and endorsed by Ryan Sleevi of Google and Wayne Thayer of GoDaddy. --------------------- Motion Starts --------------------- 1) Amend Section 9.2.1 of the Baseline Requirements v. 1.2.3 as follows: 9.2.1 Subject Alternative Name Extension Certificate Field: extensions:subjectAltName Required/Optional: Required Contents: This 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. The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate. Wildcard FQDNs are permitted. As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name, the CA SHALL notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016. Also as of the Effective Date, the CA SHALL NOT issue a certificate with an Expiry Date later than 1 November 2015 with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name. Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Name. Effective May 1, 2015, each CA SHALL revoke all unexpired Certificates with an Internal Name using onion as the right-most label in an entry in the subjectAltName Extension or commonName field unless such Certificate was issued in accordance with Appendix F of the EV Guidelines. 2) Amend Section 9.2.2 and 11.7.1 of the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2 as follows: 9.2.2. Subject Alternative Name Extension Certificate field: subjectAltName:dNSName Required/Optional: Required Contents: This extension MUST contain one or more host Domain Name(s) owned or controlled by the Subject and to be associated with the Subject's server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). Wildcard certificates are not allowed for EV Certificates except as permitted under Appendix F. 11.7 Verification of Applicant's Domain Name 11.7.1. Verification Requirements (1) For each Fully-Qualified Domain Name listed in a Certificate, other than a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant (or the Applicant's Parent Company, Subsidiary Company, or Affiliate, collectively referred to as "Applicant" for the purposes of this section) either is the Domain Name Registrant or has control over the FQDN using a procedure specified in Section 11.1.1 of the Baseline Requirements, except that a CA MAY NOT verify a domain using the procedure described 11.1.1(7). For a Certificate issued to a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant's control over the .onion Domain Name in accordance with Appendix F. (2) Mixed Character Set Domain Names: EV Certificates MAY include Domain Names containing mixed character sets only in compliance with the rules set forth by the domain registrar. The CA MUST visually compare any Domain Names with mixed character sets with known high risk domains. If a similarity is found, then the EV Certificate Request MUST be flagged as High Risk. The CA must perform reasonably appropriate additional authentication and verification to be certain beyond reasonable doubt that the Applicant and the target in question are the same organization. 3) Add a new Appendix F to the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2: Appendix F - Issuance of Certificates for .onion Domain Names A CA may issue an EV Certificate with .onion in the right-most label of the Domain Name provided that issuance complies with the requirements set forth in this Appendix: 1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) The CAB Forum has created an extension of the TBSCertificate for use in conveying hashes of keys related to .onion addresses. The Tor Service Descriptor Hash extension has the following format: cabf-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 } TorServiceDescriptorSyntax ::= SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash TorServiceDescriptorHash:: = SEQUENCE { onionURI UTF8String algorithm AlgorithmIdentifier subjectPublicKeyHash BIT STRING } Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 6234) performed over the DER-encoding of an ASN.1 SubjectPublicKey of the .onion service and SubjectPublicKeyHash is the hash output. 2. The CA MUST verify the Applicant's control over the .onion Domain Name using one of the following: a. The CA MAY verify the Applicant's control over the .onion service by posting a specific value at a well-known URL under RFC5785. b. The CA MAY verify the Applicant's control over the .onion service by having the Applicant provide a Certificate Request signed using the .onion public key if the Attributes section of the certificationRequestInfo contains: (i) A caSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy, 2) is generated by the CA, and 3) delivered to the Applicant through a Verified Method of Communication and (ii) An applicantSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy and 2) is generated by the Applicant. The signing nonce attributes have the following format: caSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-caSigningNonce } } cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } applicantSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-applicantSigningNonce } } cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 } 4. Each Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name MUST conform to the requirements of these Guidelines, including the content requirements in Section 9 and Appendix B of the Baseline Requirements, except that the CA MAY include a wildcard character in the Subject Alternative Name Extension and Subject Common Name Field as the left-most character in the .onion Domain Name provided inclusion of the wildcard character complies with Section 11.1.3 of the Baseline Requirements. 5. CAs MUST NOT issue a Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name with a validity period longer than 15 months. Despite Section 9.2.1 of the Baseline Requirements deprecating the use of Internal Names, a CA MAY issue a Certificate containing an .onion name with an expiration date later than 1 November 2015 after (and only if) .onion is officially recognized by the IESG as a reserved TLD. 6. On or before May 1, 2015, each CA MUST revoke all Certificates issued with the Subject Alternative Name extension or Common Name field that includes a Domain Name where .onion is in the right-most label of the Domain Name unless the Certificate was issued in compliance with this Appendix F. ---- Motion Ends ----- The review period for this ballot shall commence at 2200 UTC on Thursday, 4 February 2015, and will close at 2200 UTC on Thursday, 11 February 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on Monday, 18 February 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150215/96043772/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6130 bytes Desc: not available Url : https://cabforum.org/pipermail/public/attachments/20150215/96043772/attachment-0001.bin From sleevi at google.com Sun Feb 15 17:44:08 2015 From: sleevi at google.com (Ryan Sleevi) Date: Sun, 15 Feb 2015 16:44:08 -0800 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names In-Reply-To: <14D026C7F297AD44AC82578DD818CDD038EF1EA3F7@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> References: <14D026C7F297AD44AC82578DD818CDD038EF1EA3F7@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> Message-ID: Google votes YES. On Sun, Feb 15, 2015 at 1:39 PM, Dean Coclin wrote: > Symantec votes YES > > > > From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On > Behalf Of Jeremy Rowley > Sent: Tuesday, February 10, 2015 1:39 PM > To: public at cabforum.org > Subject: [cabfpub] Ballot 144 - Validation rules for .onion names > > > > Here?s the ballot with the two typos fixed: > > > > Applicants want a CA-signed .onion address for several reasons, including: > > - Powerful web platform features are restricted to secure > origins, which are currently not available to onion names (in part, because > of the lack of IANA registration). Permitting EV certs for onion names will > help provide a secure origin for the service, moving onion towards use of > powerful web platform features. > > - Currently, access to .onion names over https from a standard > browser results in the standard existing 'Invalid Certificate' warning. > Training users to click through security warnings lowers the value of these > warnings and will cause users to miss important security information. > Removing these warnings for the user, through use of a digital certificate, > will help users recognize and avoid real MITM attacks. > > - The public needs attribution of ownership of the .onion > address to differentiate onion services, including potential phishing > services. Because onion names are not easily recognizable strings, providing > the public with additional information about the operator has significant > security improvements, especially in regions where use of the incorrect name > could have lethal consequences. > > > > The following motion has been proposed by Jeremy Rowley of DigiCert and > endorsed by Ryan Sleevi of Google and Wayne Thayer of GoDaddy. > > > > --------------------- > > Motion Starts > > --------------------- > > > > 1) Amend Section 9.2.1 of the Baseline Requirements v. 1.2.3 as follows: > > 9.2.1 Subject Alternative Name Extension > > Certificate Field: extensions:subjectAltName > > Required/Optional: Required > > Contents: This 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. The CA MUST confirm that the > Applicant controls the Fully-Qualified Domain Name or IP address or has been > granted the right to use it by the Domain Name Registrant or IP address > assignee, as appropriate. > > > > Wildcard FQDNs are permitted. As of the Effective Date of these > Requirements, prior to the issuance of a Certificate with a > subjectAlternativeName extension or Subject commonName field containing a > Reserved IP Address or Internal Name, the CA SHALL notify the Applicant that > the use of such Certificates has been deprecated by the CA / Browser Forum > and that the practice will be eliminated by October 2016. Also as of the > Effective Date, the CA SHALL NOT issue a certificate with an Expiry Date > later than 1 November 2015 with a subjectAlternativeName extension or > Subject commonName field containing a Reserved IP Address or Internal Name. > Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose > subjectAlternativeName extension or Subject commonName field contains a > Reserved IP Address or Internal Name. Effective May 1, 2015, each CA SHALL > revoke all unexpired Certificates with an Internal Name using onion as the > right-most label in an entry in the subjectAltName Extension or commonName > field unless such Certificate was issued in accordance with Appendix F of > the EV Guidelines. > > > > 2) Amend Section 9.2.2 and 11.7.1 of the Guidelines for the Issuance and > Management of Extended Validation Certificates v1.5.2 as follows: > > > > 9.2.2. Subject Alternative Name Extension Certificate field: > subjectAltName:dNSName > > Required/Optional: Required > > Contents: This extension MUST contain one or more host Domain Name(s) owned > or controlled by the Subject and to be associated with the Subject?s server. > Such server MAY be owned and operated by the Subject or another entity > (e.g., a hosting service). Wildcard certificates are not allowed for EV > Certificates except as permitted under Appendix F. > > > > 11.7 Verification of Applicant?s Domain Name > > > > 11.7.1. Verification Requirements > > > > (1) For each Fully-Qualified Domain Name listed in a Certificate, other than > a Domain Name with .onion in the right-most label of the Domain Name, the CA > SHALL confirm that, as of the date the Certificate was issued, the Applicant > (or the Applicant?s Parent Company, Subsidiary Company, or Affiliate, > collectively referred to as ?Applicant? for the purposes of this section) > either is the Domain Name Registrant or has control over the FQDN using a > procedure specified in Section 11.1.1 of the Baseline Requirements, except > that a CA MAY NOT verify a domain using the procedure described 11.1.1(7). > For a Certificate issued to a Domain Name with .onion in the right-most > label of the Domain Name, the CA SHALL confirm that, as of the date the > Certificate was issued, the Applicant?s control over the .onion Domain Name > in accordance with Appendix F. > > > > (2) Mixed Character Set Domain Names: EV Certificates MAY include Domain > Names containing mixed character sets only in compliance with the rules set > forth by the domain registrar. The CA MUST visually compare any Domain Names > with mixed character sets with known high risk domains. If a similarity is > found, then the EV Certificate Request MUST be flagged as High Risk. The CA > must perform reasonably appropriate additional authentication and > verification to be certain beyond reasonable doubt that the Applicant and > the target in question are the same organization. > > > > 3) Add a new Appendix F to the Guidelines for the Issuance and Management of > Extended Validation Certificates v1.5.2: > > > > Appendix F ? Issuance of Certificates for .onion Domain Names > > > > A CA may issue an EV Certificate with .onion in the right-most label of the > Domain Name provided that issuance complies with the requirements set forth > in this Appendix: > > 1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) > > The CAB Forum has created an extension of the TBSCertificate for use in > conveying hashes of keys related to .onion addresses. The Tor Service > Descriptor Hash extension has the following format: > > > > cabf-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 } > > > > TorServiceDescriptorSyntax ::= > > SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash > > > > TorServiceDescriptorHash:: = SEQUENCE { > > onionURI UTF8String > > algorithm AlgorithmIdentifier > > subjectPublicKeyHash BIT STRING } > > > > Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 6234) > performed over the DER-encoding of an ASN.1 SubjectPublicKey of the .onion > service and SubjectPublicKeyHash is the hash output. > > > > 2. The CA MUST verify the Applicant?s control over the .onion Domain > Name using one of the following: > > > > a. The CA MAY verify the Applicant?s control over the .onion service by > posting a specific value at a well-known URL under RFC5785. > > > > b. The CA MAY verify the Applicant?s control over the .onion service by > having the Applicant provide a Certificate Request signed using the .onion > public key if the Attributes section of the certificationRequestInfo > contains: > > > > (i) A caSigningNonce attribute that 1) contains a single value > with at least 64-bits of entropy, 2) is generated by the CA, and 3) > delivered to the Applicant through a Verified Method of Communication and > > (ii) An applicantSigningNonce attribute that 1) contains a single > value with at least 64-bits of entropy and 2) is generated by the Applicant. > > > > The signing nonce attributes have the following format: > > > > caSigningNonce ATTRIBUTE ::= { > > WITH SYNTAX OCTET STRING > > EQUALITY MATCHING RULE octetStringMatch > > SINGLE VALUE TRUE > > ID { > cabf-caSigningNonce } > > } > > > > cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } > > > > applicantSigningNonce ATTRIBUTE ::= { > > WITH SYNTAX OCTET STRING > > EQUALITY MATCHING RULE octetStringMatch > > SINGLE VALUE TRUE > > ID { > cabf-applicantSigningNonce } > > } > > > > cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 } > > > > 4. Each Certificate that includes a Domain Name where .onion is in the > right-most label of the Domain Name MUST conform to the requirements of > these Guidelines, including the content requirements in Section 9 and > Appendix B of the Baseline Requirements, except that the CA MAY include a > wildcard character in the Subject Alternative Name Extension and Subject > Common Name Field as the left-most character in the .onion Domain Name > provided inclusion of the wildcard character complies with Section 11.1.3 of > the Baseline Requirements. > > > > 5. CAs MUST NOT issue a Certificate that includes a Domain Name where > .onion is in the right-most label of the Domain Name with a validity period > longer than 15 months. Despite Section 9.2.1 of the Baseline Requirements > deprecating the use of Internal Names, a CA MAY issue a Certificate > containing an .onion name with an expiration date later than 1 November 2015 > after (and only if) .onion is officially recognized by the IESG as a > reserved TLD. > > > > 6. On or before May 1, 2015, each CA MUST revoke all Certificates issued > with the Subject Alternative Name extension or Common Name field that > includes a Domain Name where .onion is in the right-most label of the Domain > Name unless the Certificate was issued in compliance with this Appendix F. > > > > ---- > > Motion Ends > > ----- > > The review period for this ballot shall commence at 2200 UTC on Thursday, 4 > February 2015, and will close at 2200 UTC on Thursday, 11 February 2015. > Unless the motion is withdrawn during the review period, the voting period > will start immediately thereafter and will close at 2200 UTC on Monday, 18 > February 2015. Votes must be cast by posting an on-list reply to this > thread. > > A vote in favor of the motion must indicate a clear 'yes' in the response. A > vote against must indicate a clear 'no' in the response. A vote to abstain > must indicate a clear 'abstain' in the response. Unclear responses will not > be counted. The latest vote received from any representative of a voting > member before the close of the voting period will be counted. Voting members > are listed here: https://cabforum.org/members/ > > In order for the motion to be adopted, two thirds or more of the votes cast > by members in the CA category and greater than 50% of the votes cast by > members in the browser category must be in favor. Quorum is currently nine > (9) members? at least nine members must participate in the ballot, either by > voting in favor, voting against, or abstaining. > > > > > > > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public > From sleevi at google.com Sun Feb 15 17:49:52 2015 From: sleevi at google.com (Ryan Sleevi) Date: Sun, 15 Feb 2015 16:49:52 -0800 Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group In-Reply-To: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> References: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> Message-ID: Jeremy, To confirm, will this newly-formalized WG be operated consistent with Section 5.3 of our Bylaws? Specifically: "With the approval of the Chair, Working Groups may establish separate list-servs, wikis, and web pages for their communications, but all such separate list-servs must be managed in the same fashion as the Public Mail List." The existing EV WG does not operate according to the above, so I'm wanting to know how this newly formalized group will be handled if the motion succeeds. Cheers, From jeremy.rowley at digicert.com Sun Feb 15 18:09:18 2015 From: jeremy.rowley at digicert.com (Jeremy Rowley) Date: Mon, 16 Feb 2015 01:09:18 +0000 Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group In-Reply-To: References: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> Message-ID: <4560f1b512db41a98c4ddb3198adad2d@EX2.corp.digicert.com> Yes - that is the plan. -----Original Message----- From: Ryan Sleevi [mailto:sleevi at google.com] Sent: Sunday, February 15, 2015 5:50 PM To: Jeremy Rowley Cc: CABFPub Subject: Re: [cabfpub] Ballot 143 - Formalization of Validation Working Group Jeremy, To confirm, will this newly-formalized WG be operated consistent with Section 5.3 of our Bylaws? Specifically: "With the approval of the Chair, Working Groups may establish separate list-servs, wikis, and web pages for their communications, but all such separate list-servs must be managed in the same fashion as the Public Mail List." The existing EV WG does not operate according to the above, so I'm wanting to know how this newly formalized group will be handled if the motion succeeds. Cheers, From sleevi at google.com Sun Feb 15 18:10:33 2015 From: sleevi at google.com (Ryan Sleevi) Date: Sun, 15 Feb 2015 17:10:33 -0800 Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group In-Reply-To: <4560f1b512db41a98c4ddb3198adad2d@EX2.corp.digicert.com> References: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> <4560f1b512db41a98c4ddb3198adad2d@EX2.corp.digicert.com> Message-ID: In that case, Google votes YES. On Sun, Feb 15, 2015 at 5:09 PM, Jeremy Rowley wrote: > Yes - that is the plan. > > -----Original Message----- > From: Ryan Sleevi [mailto:sleevi at google.com] > Sent: Sunday, February 15, 2015 5:50 PM > To: Jeremy Rowley > Cc: CABFPub > Subject: Re: [cabfpub] Ballot 143 - Formalization of Validation Working Group > > Jeremy, > > To confirm, will this newly-formalized WG be operated consistent with Section 5.3 of our Bylaws? Specifically: > > "With the approval of the Chair, Working Groups may establish separate list-servs, wikis, and web pages for their communications, but all such separate list-servs must be managed in the same fashion as the Public Mail List." > > The existing EV WG does not operate according to the above, so I'm wanting to know how this newly formalized group will be handled if the motion succeeds. > > Cheers, From i-barreira at izenpe.net Mon Feb 16 02:50:51 2015 From: i-barreira at izenpe.net (i-barreira at izenpe.net) Date: Mon, 16 Feb 2015 10:50:51 +0100 Subject: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc In-Reply-To: A References: <763539E260C37C46A0D6B340B5434C3B0ACD81A9@AEX06.ejsarea.net> A <763539E260C37C46A0D6B340B5434C3B0ADAE0EB@AEX06.ejsarea.net> A Message-ID: <763539E260C37C46A0D6B340B5434C3B0ADAE39F@AEX06.ejsarea.net> Jody, The auditor can be certified, can have a CISA, ISO27001 lead auditor, CISSP, etc. but does not entitled him to perform an ETSI audit. Of course is good to have, but is the auditing body that is allowed to perform an ETSI audit. And in their internal reqs they request their auditors to have those certifications or others. That has to be defined by the National Accreditation Body on the requirements to fulfill by the auditing body, in this case AuditCo. If AuditCo meets the requirements, then it can be incorporated in the list of its NAB and therefore perform ETSI audits if ETSI is one of the admitted ones (otherwise you can?t be on the list, of course). Once AuditCo is accredited in its NAB according to whatever national scheme able to performing ETSI audits, then you can hire them even if you?re not, as a CA, belonging to that country. Again, if we take Izenpe as a CA that wants to have an ETSI accredited audit (of course I can have ETSI audit but not accredited) then I have to look for Auditing bodies accredited in their countries (in Spain we don?t have), then I found that in Germany, TUV IT is accredited in its NAB according to the ISO standards requested and able to perform ETSI audits. And yes, it?s not easy, not for me as a CA and not for you as a RP. As said, we?re working on improving the language (the requisites are not so easy as it depends on every country). Hopefully I can provide some inputs for the F2F I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. De: Jody Cloutier [mailto:jodycl at microsoft.com] Enviado el: viernes, 13 de febrero de 2015 21:28 Para: Barreira Iglesias, I?igo; public at cabforum.org Asunto: RE: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Thank you, Inigo, What seems to be happening is that organizations are applying the ETSI standard in cases in which either there is no National Standards Body, or where the national standards body does not certify the company. Building on the scenario below, Audit Co is not recognized by ISRAC, but Auditor Jones has a CISP certification, which I've already confirmed with ETSI is not sufficient. I think what would help here is to make the requirement much more specific: A Qualified Auditor is limited to an auditor that is employed by a company that is certified by a National Authority listed in either the Members or Associate Members link. This, much simplified language, seems to be what you are saying below, but the current language is such that Audit Co can argue that it can issue an ETSI audit because it's company is certified by another national authority that's not listed on the ETSI webpages anywhere. Jody From: i-barreira at izenpe.net [mailto:i-barreira at izenpe.net] Sent: Friday, February 13, 2015 12:16 AM To: Jody Cloutier; public at cabforum.org Subject: RE: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Dear Jody, I understand your concern because it?s not easy for you to manage all possible combinations regarding ETSI audits in different countries so will try to clarify your example. First of all, no AuditCo has to be member of ETSI, AuditCo can perform ETSI accredited audits without being member of ETSI, they only need to be accredited in their country as stated in Annex E requirements. So, For example, ? Company A is a commercial CA that operates in Israel ? Auditor Jones works for AuditCo, which is based in Israel ? AuditCo is certified by some governmental agency as a qualified auditor IB? AuditCo has to be accredited under its National Accreditation Body according to ISO 17021. In the case of Israel, to follow the example, in the associated members tab of the EA, you can find the Israeli accreditation body, called ISRAC. Then AuditCo should be listed there and meeting the requirements to perform ETSI audits according to the national scheme indicated by ISRAC ? AuditCo is not an ETSI Member or Associate Member IB ? this is not necessary. No need to be an ETSI member to perform ETSI audits ? Auditor Jones audits Company A using the ETSI 102042 standard, and Company A sends the auditor's attestation letter to Microsoft as evidence that Company A complied with the Program's requirements. IB? this is perfectly valid if AuditCo is listed in ISRAC and is allowed to perform ETSI audits. Of course Auditor Jones has to be also accredited to perform these kind of audits, has to be "qualified", so it?s not only the company but also the auditor, but that?s an internal task of the AuditCo. Regarding of being member of not, this is voluntary, they can join ETSI or not and don?t think that solve the problem because joining ETSI does not mean that you?re "qualified" or "accredited" to perform an ETSI audit, it?s just indicate that you belong to a club for example. And of course, if company A needs an auditing company accredited in Israel and there?s none, they can look for in other countries. For example, in Spain there?s no accredited auditing bodies to perform ETSI audits listed in our NAB, called ENAC, so, we, Izenpe, had to look for another option. So, we contacted for the first 6 years with KPMG in the Netherlands, and the last 3, with TUV IT in Germany. And Izenpe has an accredited ETSI audits according to the, right now, German national scheme and we?re listed in Germany. We?ll debate this within ETSI ESI trying to find an easier solution. Regards I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. De: Jody Cloutier [mailto:jodycl at microsoft.com] Enviado el: mi?rcoles, 11 de febrero de 2015 0:32 Para: Barreira Iglesias, I?igo; public at cabforum.org Asunto: RE: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Thank you, Inigo. I think the problem is that, under ETSI, it's difficult to discern what an "equivalent national scheme" is. This sets up the scenario in which an auditor is employed by an organization that is recognized somehow by the government, but is not affiliated with an ETSI member organization (http://www.european-accreditation.org/home ). Microsoft does not know whether or not this auditor is qualified or not. For example, ? Company A is a commercial CA that operates in Israel ? Auditor Jones works for AuditCo, which is based in Israel ? AuditCo is certified by some governmental agency as a qualified auditor ? AuditCo is not an ETSI Member or Associate Member ? Auditor Jones audits Company A using the ETSI 102042 standard, and Company A sends the auditor's attestation letter to Microsoft as evidence that Company A complied with the Program's requirements. In this scenario, how does Microsoft know that Auditor Jones conducted a proper audit without expending significant resources to determine whether and according to what standard AuditCo and Auditor Jones was certified? Microsoft believes that it would be simpler if the requirements were that the Auditor must work for a company that is affiliated with an ETSI-approved member organization. If Company A needs an auditor and there is no qualified auditor in Israel, the company can use an auditor from a member organization via the cross-border conformity rules. Unless I am fundamentally misunderstanding the rules, the above is something that Microsoft is presently struggling with, and we'd like to try to make the rules easier to understand for potential partners and ourselves. Jody Cloutier Senior Security Program Manager Microsoft Trusted Root Certificate Program jody.cloutier at microsoft.com 425.443.8922 Operating Systems Group Global Risk and Compliance From: i-barreira at izenpe.net [mailto:i-barreira at izenpe.net] Sent: Tuesday, February 10, 2015 3:09 AM To: Jody Cloutier; public at cabforum.org Subject: RE: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Hi Jody, Regarding your comment on ETSI audits, I have to say that the ETSI audits shall be performed by accredited auditors as mentioned in Annex E of the current ETSI TS 102 042. ETSI audits performed by not accredited auditors shall be considered invalid. Microsoft is accepting ETSI audits since the very beginning in its root program requirements indicating this requirement. ETSI is providing a list of accredited auditors as mere information because has to be maintained by every NAB (National Accreditation Body). It?s true that this has to be improved regarding the new regulation 910/2014 and the new ENs and will take some time, but at the moment, it?s clearly stated that the audits shall be performed by accredited auditors. Don?t hesitate in contacting me for any additional information or help. Sometimes I?ve received some emails from Tom or Kelvin asking for the qualification of some audits, so, as say, you can contact me regarding this issue. Regards I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. De: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] En nombre de Jody Cloutier Enviado el: lunes, 09 de febrero de 2015 18:55 Para: CABFPub (public at cabforum.org) Asunto: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Microsoft comments on Section 17. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150216/2a187969/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 19121 bytes Desc: image001.png Url : https://cabforum.org/pipermail/public/attachments/20150216/2a187969/attachment-0002.png -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 1181 bytes Desc: image002.png Url : https://cabforum.org/pipermail/public/attachments/20150216/2a187969/attachment-0003.png From gerv at mozilla.org Mon Feb 16 04:02:35 2015 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 16 Feb 2015 11:02:35 +0000 Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group In-Reply-To: References: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> <4560f1b512db41a98c4ddb3198adad2d@EX2.corp.digicert.com> Message-ID: <54E1CE4B.8030800@mozilla.org> On 16/02/15 01:10, Ryan Sleevi wrote: > In that case, Google votes YES. Mozilla votes YES. Gerv From gerv at mozilla.org Mon Feb 16 04:02:56 2015 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 16 Feb 2015 11:02:56 +0000 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names In-Reply-To: References: Message-ID: <54E1CE60.9020304@mozilla.org> Mozilla votes YES. Gerv From Peter.Miskovic at disig.sk Mon Feb 16 09:32:27 2015 From: Peter.Miskovic at disig.sk (Miskovic Peter) Date: Mon, 16 Feb 2015 16:32:27 +0000 Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group In-Reply-To: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> References: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> Message-ID: <3bb806d9da2b4517bc1e0e0726d3cce2@DISIGEX.disig.local> Ballot 143 - Formalization of Validation Working Group: Disig votes "YES". Regards, Peter Miskovic From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Wednesday, February 04, 2015 10:05 PM To: CABFPub Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group Ballot 143 - Formalization of validation working group ---- Reason ---- In order to address validation issues and inconsistencies in both the SSL Baseline Requirements and the EV Guidelines, the CAB Forum has held an informal working group previously referred to as the Extended Validation Working Group now known as the Validation Working Group, would like to modify its scope to include validation in the Baseline Requirements as well as the EV Guidelines. Jeremy Rowley of DigiCert made the following motion, which was endorsed by Rich Smith of Comodo and Kirk Hall of TrendMicro ---- Motion begins ---- The CA-Browser Forum formally establishes the Validation Working Group as an official working group of the CAB Forum, replacing the previous informal EV working group. The scope of this working group is to address issues arising under adopted CAB Forum standards related to the validation of certificate information and the inclusion of information in certificates. Scope: The Validation Working Group will consider all matters relating to the validation and inclusion of information in certificates under adopted CAB Forum guidelines. Deliverables: The Working Group shall produce one or more documents offering options to the Forum for validation within the scope defined above. ---- Motion Ends ---- The review period for this ballot shall commence at 2200 UTC on 5 Feb 2015, and will close at 2200 UTC on 11 Feb 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on 18 Feb 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150216/8e252978/attachment-0001.html From Peter.Miskovic at disig.sk Mon Feb 16 09:34:12 2015 From: Peter.Miskovic at disig.sk (Miskovic Peter) Date: Mon, 16 Feb 2015 16:34:12 +0000 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names In-Reply-To: References: Message-ID: <593c466c7fc34b4da114746b576d4396@DISIGEX.disig.local> Ballot 144 - Validation rules for .onion names: Disig abstains. Regards, Peter Miskovic From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Tuesday, February 10, 2015 7:39 PM To: public at cabforum.org Subject: [cabfpub] Ballot 144 - Validation rules for .onion names Here's the ballot with the two typos fixed: Applicants want a CA-signed .onion address for several reasons, including: - Powerful web platform features are restricted to secure origins, which are currently not available to onion names (in part, because of the lack of IANA registration). Permitting EV certs for onion names will help provide a secure origin for the service, moving onion towards use of powerful web platform features. - Currently, access to .onion names over https from a standard browser results in the standard existing 'Invalid Certificate' warning. Training users to click through security warnings lowers the value of these warnings and will cause users to miss important security information. Removing these warnings for the user, through use of a digital certificate, will help users recognize and avoid real MITM attacks. - The public needs attribution of ownership of the .onion address to differentiate onion services, including potential phishing services. Because onion names are not easily recognizable strings, providing the public with additional information about the operator has significant security improvements, especially in regions where use of the incorrect name could have lethal consequences. The following motion has been proposed by Jeremy Rowley of DigiCert and endorsed by Ryan Sleevi of Google and Wayne Thayer of GoDaddy. --------------------- Motion Starts --------------------- 1) Amend Section 9.2.1 of the Baseline Requirements v. 1.2.3 as follows: 9.2.1 Subject Alternative Name Extension Certificate Field: extensions:subjectAltName Required/Optional: Required Contents: This 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. The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate. Wildcard FQDNs are permitted. As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name, the CA SHALL notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016. Also as of the Effective Date, the CA SHALL NOT issue a certificate with an Expiry Date later than 1 November 2015 with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name. Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Name. Effective May 1, 2015, each CA SHALL revoke all unexpired Certificates with an Internal Name using onion as the right-most label in an entry in the subjectAltName Extension or commonName field unless such Certificate was issued in accordance with Appendix F of the EV Guidelines. 2) Amend Section 9.2.2 and 11.7.1 of the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2 as follows: 9.2.2. Subject Alternative Name Extension Certificate field: subjectAltName:dNSName Required/Optional: Required Contents: This extension MUST contain one or more host Domain Name(s) owned or controlled by the Subject and to be associated with the Subject's server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). Wildcard certificates are not allowed for EV Certificates except as permitted under Appendix F. 11.7 Verification of Applicant's Domain Name 11.7.1. Verification Requirements (1) For each Fully-Qualified Domain Name listed in a Certificate, other than a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant (or the Applicant's Parent Company, Subsidiary Company, or Affiliate, collectively referred to as "Applicant" for the purposes of this section) either is the Domain Name Registrant or has control over the FQDN using a procedure specified in Section 11.1.1 of the Baseline Requirements, except that a CA MAY NOT verify a domain using the procedure described 11.1.1(7). For a Certificate issued to a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant's control over the .onion Domain Name in accordance with Appendix F. (2) Mixed Character Set Domain Names: EV Certificates MAY include Domain Names containing mixed character sets only in compliance with the rules set forth by the domain registrar. The CA MUST visually compare any Domain Names with mixed character sets with known high risk domains. If a similarity is found, then the EV Certificate Request MUST be flagged as High Risk. The CA must perform reasonably appropriate additional authentication and verification to be certain beyond reasonable doubt that the Applicant and the target in question are the same organization. 3) Add a new Appendix F to the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2: Appendix F - Issuance of Certificates for .onion Domain Names A CA may issue an EV Certificate with .onion in the right-most label of the Domain Name provided that issuance complies with the requirements set forth in this Appendix: 1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) The CAB Forum has created an extension of the TBSCertificate for use in conveying hashes of keys related to .onion addresses. The Tor Service Descriptor Hash extension has the following format: cabf-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 } TorServiceDescriptorSyntax ::= SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash TorServiceDescriptorHash:: = SEQUENCE { onionURI UTF8String algorithm AlgorithmIdentifier subjectPublicKeyHash BIT STRING } Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 6234) performed over the DER-encoding of an ASN.1 SubjectPublicKey of the .onion service and SubjectPublicKeyHash is the hash output. 2. The CA MUST verify the Applicant's control over the .onion Domain Name using one of the following: a. The CA MAY verify the Applicant's control over the .onion service by posting a specific value at a well-known URL under RFC5785. b. The CA MAY verify the Applicant's control over the .onion service by having the Applicant provide a Certificate Request signed using the .onion public key if the Attributes section of the certificationRequestInfo contains: (i) A caSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy, 2) is generated by the CA, and 3) delivered to the Applicant through a Verified Method of Communication and (ii) An applicantSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy and 2) is generated by the Applicant. The signing nonce attributes have the following format: caSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-caSigningNonce } } cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } applicantSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-applicantSigningNonce } } cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 } 4. Each Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name MUST conform to the requirements of these Guidelines, including the content requirements in Section 9 and Appendix B of the Baseline Requirements, except that the CA MAY include a wildcard character in the Subject Alternative Name Extension and Subject Common Name Field as the left-most character in the .onion Domain Name provided inclusion of the wildcard character complies with Section 11.1.3 of the Baseline Requirements. 5. CAs MUST NOT issue a Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name with a validity period longer than 15 months. Despite Section 9.2.1 of the Baseline Requirements deprecating the use of Internal Names, a CA MAY issue a Certificate containing an .onion name with an expiration date later than 1 November 2015 after (and only if) .onion is officially recognized by the IESG as a reserved TLD. 6. On or before May 1, 2015, each CA MUST revoke all Certificates issued with the Subject Alternative Name extension or Common Name field that includes a Domain Name where .onion is in the right-most label of the Domain Name unless the Certificate was issued in compliance with this Appendix F. ---- Motion Ends ----- The review period for this ballot shall commence at 2200 UTC on Thursday, 4 February 2015, and will close at 2200 UTC on Thursday, 11 February 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on Monday, 18 February 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150216/456173cd/attachment-0001.html From ben.wilson at digicert.com Mon Feb 16 09:56:37 2015 From: ben.wilson at digicert.com (Ben Wilson) Date: Mon, 16 Feb 2015 16:56:37 +0000 Subject: [cabfpub] Ballot 143 In-Reply-To: <54DE685D.2000500@startcom.org> References: <68a8241d150c4bc6bd624e08988e44fa@EX2.corp.digicert.com> <54DE685D.2000500@startcom.org> Message-ID: Eddy, I think that because the ballot on the validation working group was going to move forward faster than the one on operational existence, Jeremy inadvertently swapped ballot numbers 143 and 145. Let the record so reflect the currently used numbering. Ben From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Eddy Nigg Sent: Friday, February 13, 2015 2:11 PM To: CABFPub Subject: [cabfpub] Ballot 143 There appears to be a mistake with ballot number 143 which was previously assigned to "Remove the operational existence requirement for Government Entities" and later "Formalization of validation working group". Jeremy I believe both were initiated by you? -- Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. XMPP: startcom at startcom.org Blog: Join the Revolution! Twitter: Follow Me -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150216/29326584/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4954 bytes Desc: not available Url : https://cabforum.org/pipermail/public/attachments/20150216/29326584/attachment.bin From eddy_nigg at startcom.org Mon Feb 16 09:58:29 2015 From: eddy_nigg at startcom.org (Eddy Nigg) Date: Mon, 16 Feb 2015 18:58:29 +0200 Subject: [cabfpub] Ballot 143 In-Reply-To: References: <68a8241d150c4bc6bd624e08988e44fa@EX2.corp.digicert.com> <54DE685D.2000500@startcom.org> Message-ID: <54E221B5.4050607@startcom.org> On 02/16/2015 06:56 PM, Ben Wilson wrote: > > Eddy, > > I think that because the ballot on the validation working group was > going to move forward faster than the one on operational existence, > Jeremy inadvertently swapped ballot numbers 143 and 145. Let the > record so reflect the currently used numbering. > OK - so /Remove the operational existence requirement for Government Entities/ will become 145 now. -- Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. XMPP: startcom at startcom.org Blog: Join the Revolution! Twitter: Follow Me -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150216/edf2f230/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4313 bytes Desc: S/MIME Cryptographic Signature Url : https://cabforum.org/pipermail/public/attachments/20150216/edf2f230/attachment.bin From ben.wilson at digicert.com Mon Feb 16 09:59:30 2015 From: ben.wilson at digicert.com (Ben Wilson) Date: Mon, 16 Feb 2015 16:59:30 +0000 Subject: [cabfpub] UK's Companies House Liable for Misinformation Message-ID: FYI ? FWIW from Tom Smedinghoff From: Federated ID Management Task Force [mailto:BL-FIDM at MAIL.AMERICANBAR.ORG] On Behalf Of Smedinghoff, Tom Sent: Monday, February 16, 2015 8:49 AM To: BL-FIDM at MAIL.AMERICANBAR.ORG Subject: [ABA-IDM-TASK-FORCE] Liability of IdP? With respect to the issue of identity system participant liability, and the discussion regarding legislative approaches to the issue, a list participant alerted me to a recent UK decision that might be of interest. See Companies House liable for company's collapse and Government in ?9 million payout after single letter blunder causes business to collapse . In that case, Companies House (the UK government's official registrar of companies, and an executive agency of the UK Department of Business, Innovation and Skills) had provided (apparently negligently) false information to credit reference agencies indicating that a business was in liquidation. The result was that all of its suppliers canceled their orders within three weeks, and the 100-year old company was forced to shut down. The UK High Court held Companies House liable for the resulting damages, finding that it owed a duty of care to the business, and that there was a special relationship with the business because ?it is foreseeable that if a company is wrongly said on the register to be in liquidation, it will suffer serious harm.? Since the case involves identity attribute-like information, it appears to raise numerous issues of relevance for the current discussion, including the liability of identity providers and attribute providers, the nature of the duty they might owe to persons and businesses they identify, and the potential liability of a government agency. It will be interesting to see whether similar reasoning is applied to identity credentials asserting incorrect information. Tom Thomas J. Smedinghoff Locke Lord LLP 225 W. Wacker Drive, Suite 3000 Chicago, Illinois 60606 312-201-2021 Direct 312-545-1333 Mobile Tom.Smedinghoff at lockelord.com www.lockelord.com -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150216/c7eee6c0/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4954 bytes Desc: not available Url : https://cabforum.org/pipermail/public/attachments/20150216/c7eee6c0/attachment-0001.bin From douglas.beattie at globalsign.com Mon Feb 16 10:41:28 2015 From: douglas.beattie at globalsign.com (Doug Beattie) Date: Mon, 16 Feb 2015 17:41:28 +0000 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names In-Reply-To: <593c466c7fc34b4da114746b576d4396@DISIGEX.disig.local> References: <593c466c7fc34b4da114746b576d4396@DISIGEX.disig.local> Message-ID: GlobalSign abstains. Doug From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Tuesday, February 10, 2015 7:39 PM To: public at cabforum.org Subject: [cabfpub] Ballot 144 - Validation rules for .onion names Here's the ballot with the two typos fixed: Applicants want a CA-signed .onion address for several reasons, including: - Powerful web platform features are restricted to secure origins, which are currently not available to onion names (in part, because of the lack of IANA registration). Permitting EV certs for onion names will help provide a secure origin for the service, moving onion towards use of powerful web platform features. - Currently, access to .onion names over https from a standard browser results in the standard existing 'Invalid Certificate' warning. Training users to click through security warnings lowers the value of these warnings and will cause users to miss important security information. Removing these warnings for the user, through use of a digital certificate, will help users recognize and avoid real MITM attacks. - The public needs attribution of ownership of the .onion address to differentiate onion services, including potential phishing services. Because onion names are not easily recognizable strings, providing the public with additional information about the operator has significant security improvements, especially in regions where use of the incorrect name could have lethal consequences. The following motion has been proposed by Jeremy Rowley of DigiCert and endorsed by Ryan Sleevi of Google and Wayne Thayer of GoDaddy. --------------------- Motion Starts --------------------- 1) Amend Section 9.2.1 of the Baseline Requirements v. 1.2.3 as follows: 9.2.1 Subject Alternative Name Extension Certificate Field: extensions:subjectAltName Required/Optional: Required Contents: This 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. The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate. Wildcard FQDNs are permitted. As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name, the CA SHALL notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016. Also as of the Effective Date, the CA SHALL NOT issue a certificate with an Expiry Date later than 1 November 2015 with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name. Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Name. Effective May 1, 2015, each CA SHALL revoke all unexpired Certificates with an Internal Name using onion as the right-most label in an entry in the subjectAltName Extension or commonName field unless such Certificate was issued in accordance with Appendix F of the EV Guidelines. 2) Amend Section 9.2.2 and 11.7.1 of the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2 as follows: 9.2.2. Subject Alternative Name Extension Certificate field: subjectAltName:dNSName Required/Optional: Required Contents: This extension MUST contain one or more host Domain Name(s) owned or controlled by the Subject and to be associated with the Subject's server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). Wildcard certificates are not allowed for EV Certificates except as permitted under Appendix F. 11.7 Verification of Applicant's Domain Name 11.7.1. Verification Requirements (1) For each Fully-Qualified Domain Name listed in a Certificate, other than a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant (or the Applicant's Parent Company, Subsidiary Company, or Affiliate, collectively referred to as "Applicant" for the purposes of this section) either is the Domain Name Registrant or has control over the FQDN using a procedure specified in Section 11.1.1 of the Baseline Requirements, except that a CA MAY NOT verify a domain using the procedure described 11.1.1(7). For a Certificate issued to a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant's control over the .onion Domain Name in accordance with Appendix F. (2) Mixed Character Set Domain Names: EV Certificates MAY include Domain Names containing mixed character sets only in compliance with the rules set forth by the domain registrar. The CA MUST visually compare any Domain Names with mixed character sets with known high risk domains. If a similarity is found, then the EV Certificate Request MUST be flagged as High Risk. The CA must perform reasonably appropriate additional authentication and verification to be certain beyond reasonable doubt that the Applicant and the target in question are the same organization. 3) Add a new Appendix F to the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2: Appendix F - Issuance of Certificates for .onion Domain Names A CA may issue an EV Certificate with .onion in the right-most label of the Domain Name provided that issuance complies with the requirements set forth in this Appendix: 1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) The CAB Forum has created an extension of the TBSCertificate for use in conveying hashes of keys related to .onion addresses. The Tor Service Descriptor Hash extension has the following format: cabf-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 } TorServiceDescriptorSyntax ::= SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash TorServiceDescriptorHash:: = SEQUENCE { onionURI UTF8String algorithm AlgorithmIdentifier subjectPublicKeyHash BIT STRING } Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 6234) performed over the DER-encoding of an ASN.1 SubjectPublicKey of the .onion service and SubjectPublicKeyHash is the hash output. 2. The CA MUST verify the Applicant's control over the .onion Domain Name using one of the following: a. The CA MAY verify the Applicant's control over the .onion service by posting a specific value at a well-known URL under RFC5785. b. The CA MAY verify the Applicant's control over the .onion service by having the Applicant provide a Certificate Request signed using the .onion public key if the Attributes section of the certificationRequestInfo contains: (i) A caSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy, 2) is generated by the CA, and 3) delivered to the Applicant through a Verified Method of Communication and (ii) An applicantSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy and 2) is generated by the Applicant. The signing nonce attributes have the following format: caSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-caSigningNonce } } cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } applicantSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-applicantSigningNonce } } cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 } 4. Each Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name MUST conform to the requirements of these Guidelines, including the content requirements in Section 9 and Appendix B of the Baseline Requirements, except that the CA MAY include a wildcard character in the Subject Alternative Name Extension and Subject Common Name Field as the left-most character in the .onion Domain Name provided inclusion of the wildcard character complies with Section 11.1.3 of the Baseline Requirements. 5. CAs MUST NOT issue a Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name with a validity period longer than 15 months. Despite Section 9.2.1 of the Baseline Requirements deprecating the use of Internal Names, a CA MAY issue a Certificate containing an .onion name with an expiration date later than 1 November 2015 after (and only if) .onion is officially recognized by the IESG as a reserved TLD. 6. On or before May 1, 2015, each CA MUST revoke all Certificates issued with the Subject Alternative Name extension or Common Name field that includes a Domain Name where .onion is in the right-most label of the Domain Name unless the Certificate was issued in compliance with this Appendix F. ---- Motion Ends ----- The review period for this ballot shall commence at 2200 UTC on Thursday, 4 February 2015, and will close at 2200 UTC on Thursday, 11 February 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on Monday, 18 February 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150216/1f84711d/attachment-0001.html From douglas.beattie at globalsign.com Mon Feb 16 11:31:46 2015 From: douglas.beattie at globalsign.com (Doug Beattie) Date: Mon, 16 Feb 2015 18:31:46 +0000 Subject: [cabfpub] [cabfquest] Domain Validation Revision In-Reply-To: References: <54DE3BBE.9000203@eff.org> Message-ID: This suggestion for item 8 works for GlobalSign so you can replace our recommendation with the one below. Doug From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ben Wilson Sent: Friday, February 13, 2015 3:39 PM To: CABFPub Subject: Re: [cabfpub] [cabfquest] Domain Validation Revision Forwarding from questions list. From: questions-bounces at cabforum.org [mailto:questions-bounces at cabforum.org] On Behalf Of Jacob Hoffman-Andrews Sent: Friday, February 13, 2015 11:01 AM To: questions at cabforum.org Subject: Re: [cabfquest] [cabfpub] Domain Validation Revision Following up from a thread on cabfpub: On 02/12/2015 07:08 PM, Ryan Sleevi wrote: 8 concerns me for a couple reasons, even though it's moving in the right direction. - You require HTTPS, but that seems overkill, when you only need to perform a TLS handshake. That is, consider a mail server configured for SMTP-S - it seems that would be a viable configuration Agreed. As a concrete example, the ACME spec under discussion at IETF proposes a challenge type called "Domain Validation with Server Name Indication," or DVSNI for short: http://www.ietf.org/id/draft-barnes-acme-01.txt. We believe that DVSNI allows us to offer a higher level of assurance than item (6), "making an agreed-upon change to information found on an online Web page," since some sites allow arbitrary file upload, either by intent or by accident. We're planning to use it for the Let's Encrypt CA for that reason, so we'd like to make sure that item (8) allows for DVSNI. For example, here is a version of item (8) that we think would work: Having the Applicant demonstrate practical control over the FQDN by providing a TLS service on a host found in DNS for the FQDN. The CA SHALL initiate a TLS connection with that host and verify that the response contains unique, unguessable information proposed by the CA, in a well-specified format. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150216/320b1346/attachment.html From kirk_hall at trendmicro.com Mon Feb 16 14:57:33 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Mon, 16 Feb 2015 21:57:33 +0000 Subject: [cabfpub] Domain Validation Revision In-Reply-To: <54DDCC5D.50305@mozilla.org> References: <54DDCC5D.50305@mozilla.org> Message-ID: Gerv -- we always allowed attorney letters in the past. For DV/OV, it was an "any other method" means of domain confirmation. For EV, it was explicitly allowed under the EVGL (and there are still references to it in the template Attorney Letter attached to the EVGL), but by mistake we deleted the reference when we changed EVGL 11.7 simply to a cross reference to BR 11.1.1 ? we accidentally dropped the old reference to using attorney-accountant letters for EV domain confirmation (I can give you a version number reference to the old EVGL if you want to confirm). So the proposal just corrects that mistake and adds back in a method we have always permitted for domain confirmation. This is useful when the Domain Name Registrant has licensed the domain to the Customer, or when the parent-sub relationship is not reported correctly, etc. -----Original Message----- From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Gervase Markham Sent: Friday, February 13, 2015 2:05 AM To: Jeremy Rowley; CABFPub (public at cabforum.org) Subject: Re: [cabfpub] Domain Validation Revision > 3) permit > attorney/accountants to draft the domain authorization document. If I understand this correctly, then I am opposed. I don't see why a lawyer or an accountant is an appropriate authority on the subject of who controls a domain. Domain control can only be properly validated either by the registrar who issued the domain, the registrant listed in WHOIS, or some practical demonstration of control. No-one else's opinion matters. Gerv _______________________________________________ Public mailing list Public at cabforum.org https://cabforum.org/mailman/listinfo/public 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
-------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150216/8378394d/attachment.html From enric.castillo at anf.es Mon Feb 16 11:40:23 2015 From: enric.castillo at anf.es (Enric Castillo) Date: Mon, 16 Feb 2015 19:40:23 +0100 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names In-Reply-To: References: Message-ID: <54E23997.5080604@anf.es> ANF AC abstains ballot 144. ANF Autoridad de Certificaci?n *Enric Castillo* Director T?cnico +34 626818285 Gran Via de Les Corts Catalanes 996, Barcelona +593 0 998554992 12 de Octubre y Cordero, World Trade Center, Torre A, 1102, Quito ANF Autoridad de Certificaci?n www.anf.es *Aviso* Este mensaje se dirige exclusivamente a su destinatario y puede contener informaci?n privilegiada o confidencial y/o datos de car?cter personal, cuya difusi?n est? regulada por la Ley Org?nica de Protecci?n de Datos y la Ley de Servicios de la Sociedad de la Informaci?n. Si usted no es el destinatario indicado (o el responsable de la entrega al mismo), no debe copiar o entregar este mensaje a terceros bajo ning?n concepto. Si ha recibido este mensaje por error o lo ha conseguido por otros medios, le rogamos que nos lo comunique inmediatamente por esta misma v?a y proceda a su eliminaci?n irreversible. Las opiniones, conclusiones y dem?s informaciones incluidas en este mensaje que no est?n relacionadas con asuntos profesionales de ANF Autoridad de Certificaci?n no est?n respaldadas por la empresa. El 10/02/2015 a las 19:38, Jeremy Rowley escribi?: > > *Here?s the ballot with the two typos fixed:* > > Applicants want a CA-signed .onion address for several reasons, including: > > - Powerful web platform features are restricted to secure origins, > which are currently not available to onion names (in part, because of > the lack of IANA registration). Permitting EV certs for onion names > will help provide a secure origin for the service, moving onion > towards use of powerful web platform features. > > - Currently, access to .onion names over https from a standard browser > results in the standard existing 'Invalid Certificate' warning. > Training users to click through security warnings lowers the value of > these warnings and will cause users to miss important security > information. Removing these warnings for the user, through use of a > digital certificate, will help users recognize and avoid real MITM > attacks. > > - The public needs attribution of ownership of the .onion address to > differentiate onion services, including potential phishing services. > Because onion names are not easily recognizable strings, providing the > public with additional information about the operator has significant > security improvements, especially in regions where use of the > incorrect name could have lethal consequences. > > The following motion has been proposed by Jeremy Rowley of DigiCert > and endorsed by Ryan Sleevi of Google and Wayne Thayer of GoDaddy. > > --------------------- > > Motion Starts > > --------------------- > > 1) Amend Section 9.2.1 of the Baseline Requirements v. 1.2.3 as follows: > > 9.2.1 Subject Alternative Name Extension > > Certificate Field: extensions:subjectAltName > > Required/Optional: Required > > Contents: This 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. The CA MUST > confirm that the Applicant controls the Fully-Qualified Domain Name or > IP address or has been granted the right to use it by the Domain Name > Registrant or IP address assignee, as appropriate. > > Wildcard FQDNs are permitted. As of the Effective Date of these > Requirements, prior to the issuance of a Certificate with a > subjectAlternativeName extension or Subject commonName field > containing a Reserved IP Address or Internal Name, the CA SHALL notify > the Applicant that the use of such Certificates has been deprecated by > the CA / Browser Forum and that the practice will be eliminated by > October 2016. Also as of the Effective Date, the CA SHALL NOT issue a > certificate with an Expiry Date later than 1 November 2015 with a > subjectAlternativeName extension or Subject commonName field > containing a Reserved IP Address or Internal Name. Effective 1 October > 2016, CAs SHALL revoke all unexpired Certificates whose > subjectAlternativeName extension or Subject commonName field contains > a Reserved IP Address or Internal Name. _Effective May 1, 2015, each > CA SHALL revoke all unexpired Certificates with an Internal Name using > onion as the right-most label in an entry in the subjectAltName > Extension or commonName field unless such Certificate was issued in > accordance with Appendix F of the EV Guidelines._ > > 2) Amend Section 9.2.2 and 11.7.1 of the Guidelines for the Issuance > and Management of Extended Validation Certificates v1.5.2 as follows: > > 9.2.2. Subject Alternative Name Extension Certificate field: > subjectAltName:dNSName > > Required/Optional: Required > > Contents: This extension MUST contain one or more host Domain Name(s) > owned or controlled by the Subject and to be associated with the > Subject?s server. Such server MAY be owned and operated by the Subject > or another entity (e.g., a hosting service). Wildcard certificates are > not allowed for EV Certificates_except as permitted under Appendix F_. > > 11.7 Verification of Applicant?s Domain Name > > 11.7.1. Verification Requirements > > (1) For each Fully-Qualified Domain Name listed in a Certificate, > other than a Domain Name with .onion in the right-most label of the > Domain Name, the CA SHALL confirm that, as of the date the Certificate > was issued, the Applicant (or the Applicant?s Parent Company, > Subsidiary Company, or Affiliate, collectively referred to as > ?Applicant? for the purposes of this section) either is the Domain > Name Registrant or has control over the FQDN using a procedure > specified in Section 11.1.1 of the Baseline Requirements, except that > a CA MAY NOT verify a domain using the procedure described 11.1.1(7). > _For a Certificate issued to a Domain Name with .onion in the > right-most label of the Domain Name, the CA SHALL confirm that, as of > the date the Certificate was issued, the Applicant?s control over the > .onion Domain Name in accordance with Appendix F._ > > (2) Mixed Character Set Domain Names: EV Certificates MAY include > Domain Names containing mixed character sets only in compliance with > the rules set forth by the domain registrar. The CA MUST visually > compare any Domain Names with mixed character sets with known high > risk domains. If a similarity is found, then the EV Certificate > Request MUST be flagged as High Risk. The CA must perform reasonably > appropriate additional authentication and verification to be certain > beyond reasonable doubt that the Applicant and the target in question > are the same organization. > > 3) Add a new Appendix F to the Guidelines for the Issuance and > Management of Extended Validation Certificates v1.5.2: > > Appendix F ? Issuance of Certificates for .onion Domain Names > > A CA may issue an EV Certificate with .onion in the right-most label > of the Domain Name provided that issuance complies with the > requirements set forth in this Appendix: > > 1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) > > The CAB Forum has created an extension of the TBSCertificate for use > in conveying hashes of keys related to .onion addresses. The Tor > Service Descriptor Hash extension has the following format: > > cabf-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 } > > TorServiceDescriptorSyntax ::= > > SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash > > TorServiceDescriptorHash:: = SEQUENCE { > > onionURI UTF8String > > algorithm AlgorithmIdentifier > > subjectPublicKeyHash BIT STRING } > > Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC > 6234) performed over the DER-encoding of an ASN.1 SubjectPublicKey of > the .onion service and SubjectPublicKeyHash is the hash output. > > 2. The CA MUST verify the Applicant?s control over the .onion Domain > Name using one of the following: > > a. The CA MAY verify the Applicant?s control over the .onion service > by posting a specific value at a well-known URL under RFC5785. > > b. The CA MAY verify the Applicant?s control over the .onion service > by having the Applicant provide a Certificate Request signed using the > .onion public key if the Attributes section of the > certificationRequestInfo contains: > > (i) A caSigningNonce attribute that 1) contains a single value with at > least 64-bits of entropy, 2) is generated by the CA, and 3) delivered > to the Applicant through a Verified Method of Communication and > > (ii) An applicantSigningNonce attribute that 1) contains a single > value with at least 64-bits of entropy and 2) is generated by the > Applicant. > > The signing nonce attributes have the following format: > > caSigningNonce ATTRIBUTE ::= { > > WITH SYNTAX OCTET STRING > > EQUALITY MATCHING RULE octetStringMatch > > SINGLE VALUE TRUE > > ID { cabf-caSigningNonce } > > } > > cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } > > applicantSigningNonce ATTRIBUTE ::= { > > WITH SYNTAX OCTET STRING > > EQUALITY MATCHING RULE octetStringMatch > > SINGLE VALUE TRUE > > ID { cabf-applicantSigningNonce } > > } > > cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 } > > 4. Each Certificate that includes a Domain Name where .onion is in the > right-most label of the Domain Name MUST conform to the requirements > of these Guidelines, including the content requirements in Section 9 > and Appendix B of the Baseline Requirements, except that the CA MAY > include a wildcard character in the Subject Alternative Name Extension > and Subject Common Name Field as the left-most character in the .onion > Domain Name provided inclusion of the wildcard character complies with > Section 11.1.3 of the Baseline Requirements. > > 5. CAs MUST NOT issue a Certificate that includes a Domain Name where > .onion is in the right-most label of the Domain Name with a validity > period longer than 15 months. Despite Section 9.2.1 of the Baseline > Requirements deprecating the use of Internal Names, a CA MAY issue a > Certificate containing an .onion name with an expiration date later > than 1 November 2015 after (and only if) .onion is officially > recognized by the IESG as a reserved TLD. > > 6. On or before May 1, 2015, each CA MUST revoke all Certificates > issued with the Subject Alternative Name extension or Common Name > field that includes a Domain Name where .onion is in the right-most > label of the Domain Name unless the Certificate was issued in > compliance with this Appendix F. > > ---- > > Motion Ends > > ----- > > The review period for this ballot shall commence at 2200 UTC on > Thursday, 4 February 2015, and will close at 2200 UTC on Thursday, 11 > February 2015. Unless the motion is withdrawn during the review > period, the voting period will start immediately thereafter and will > close at 2200 UTC on Monday, 18 February 2015. Votes must be cast by > posting an on-list reply to this thread. > > A vote in favor of the motion must indicate a clear 'yes' in the > response. A vote against must indicate a clear 'no' in the response. A > vote to abstain must indicate a clear 'abstain' in the response. > Unclear responses will not be counted. The latest vote received from > any representative of a voting member before the close of the voting > period will be counted. Voting members are listed here: > https://cabforum.org/members/ > > In order for the motion to be adopted, two thirds or more of the votes > cast by members in the CA category and greater than 50% of the votes > cast by members in the browser category must be in favor. Quorum is > currently nine (9) members? at least nine members must participate in > the ballot, either by voting in favor, voting against, or abstaining. > > > > _______________________________________________ > 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/20150216/5e1438cd/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: logo-anf.png Type: image/png Size: 4746 bytes Desc: not available Url : https://cabforum.org/pipermail/public/attachments/20150216/5e1438cd/attachment-0001.png From enric.castillo at anf.es Mon Feb 16 11:41:22 2015 From: enric.castillo at anf.es (Enric Castillo) Date: Mon, 16 Feb 2015 19:41:22 +0100 Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group In-Reply-To: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> References: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> Message-ID: <54E239D2.1090001@anf.es> ANF AC votes yes. ANF Autoridad de Certificaci?n *Enric Castillo* Director T?cnico +34 626818285 Gran Via de Les Corts Catalanes 996, Barcelona +593 0 998554992 12 de Octubre y Cordero, World Trade Center, Torre A, 1102, Quito ANF Autoridad de Certificaci?n www.anf.es *Aviso* Este mensaje se dirige exclusivamente a su destinatario y puede contener informaci?n privilegiada o confidencial y/o datos de car?cter personal, cuya difusi?n est? regulada por la Ley Org?nica de Protecci?n de Datos y la Ley de Servicios de la Sociedad de la Informaci?n. Si usted no es el destinatario indicado (o el responsable de la entrega al mismo), no debe copiar o entregar este mensaje a terceros bajo ning?n concepto. Si ha recibido este mensaje por error o lo ha conseguido por otros medios, le rogamos que nos lo comunique inmediatamente por esta misma v?a y proceda a su eliminaci?n irreversible. Las opiniones, conclusiones y dem?s informaciones incluidas en este mensaje que no est?n relacionadas con asuntos profesionales de ANF Autoridad de Certificaci?n no est?n respaldadas por la empresa. El 04/02/2015 a las 22:05, Jeremy Rowley escribi?: > > Ballot 143 - Formalization of validation working group > > ---- > > Reason > > ---- > > In order to address validation issues and inconsistencies in both the > SSL Baseline Requirements and the EV Guidelines, the CAB Forum has > held an informal working group previously referred to as the Extended > Validation Working Group now known as the Validation Working Group, > would like to modify its scope to include validation in the Baseline > Requirements as well as the EV Guidelines. > > Jeremy Rowley of DigiCert made the following motion, which was > endorsed by Rich Smith of Comodo and Kirk Hall of TrendMicro > > ---- > > Motion begins > > ---- > > The CA-Browser Forum formally establishes the Validation Working Group > as an official working group of the CAB Forum, replacing the previous > informal EV working group. The scope of this working group is to > address issues arising under adopted CAB Forum standards related to > the validation of certificate information and the inclusion of > information in certificates. > > Scope: The Validation Working Group will consider all matters relating > to the validation and inclusion of information in certificates under > adopted CAB Forum guidelines. > > Deliverables: The Working Group shall produce one or more documents > offering options to the Forum for validation within the scope defined > above. > > ---- > > Motion Ends > > ---- > > The review period for this ballot shall commence at 2200 UTC on 5 Feb > 2015, and will close at 2200 UTC on 11 Feb 2015. Unless the motion is > withdrawn during the review period, the voting period will start > immediately thereafter and will close at 2200 UTC on 18 Feb 2015. > Votes must be cast by posting an on-list reply to this thread. > > A vote in favor of the motion must indicate a clear 'yes' in the > response. A vote against must indicate a clear 'no' in the response. A > vote to abstain must indicate a clear 'abstain' in the response. > Unclear responses will not be counted. The latest vote received from > any representative of a voting member before the close of the voting > period will be counted. Voting members are listed here: > https://cabforum.org/members/ > > In order for the motion to be adopted, two thirds or more of the votes > cast by members in the CA category and greater than 50% of the votes > cast by members in the browser category must be in favor. Quorum is > currently nine (9) members? at least nine members must participate in > the ballot, either by voting in favor, voting against, or abstaining. > > > > _______________________________________________ > 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/20150216/f91fb2b8/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: logo-anf.png Type: image/png Size: 4746 bytes Desc: not available Url : https://cabforum.org/pipermail/public/attachments/20150216/f91fb2b8/attachment.png From enric.castillo at anf.es Mon Feb 16 11:59:56 2015 From: enric.castillo at anf.es (Enric Castillo) Date: Mon, 16 Feb 2015 19:59:56 +0100 Subject: [cabfpub] IPv6 support In-Reply-To: <54DE8183.1060204@startcom.org> References: <14D026C7F297AD44AC82578DD818CDD038EEF0BA5B@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C01141460BD37468D1@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <14D026C7F297AD44AC82578DD818CDD038EEF0BFAD@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> <14D026C7F297AD44AC82578DD818CDD038EF1EA316@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> <54DE8183.1060204@startcom.org> Message-ID: <54E23E2C.70903@anf.es> We don't support IPv6 now for CRL and OCSP because the demand is so low by the moment. Talking with the infraestructure team, our changes are easy to implement and become fully compilance with IPv6. ANF Autoridad de Certificaci?n *Enric Castillo* Director T?cnico +34 626818285 Gran Via de Les Corts Catalanes 996, Barcelona +593 0 998554992 12 de Octubre y Cordero, World Trade Center, Torre A, 1102, Quito ANF Autoridad de Certificaci?n www.anf.es *Aviso* Este mensaje se dirige exclusivamente a su destinatario y puede contener informaci?n privilegiada o confidencial y/o datos de car?cter personal, cuya difusi?n est? regulada por la Ley Org?nica de Protecci?n de Datos y la Ley de Servicios de la Sociedad de la Informaci?n. Si usted no es el destinatario indicado (o el responsable de la entrega al mismo), no debe copiar o entregar este mensaje a terceros bajo ning?n concepto. Si ha recibido este mensaje por error o lo ha conseguido por otros medios, le rogamos que nos lo comunique inmediatamente por esta misma v?a y proceda a su eliminaci?n irreversible. Las opiniones, conclusiones y dem?s informaciones incluidas en este mensaje que no est?n relacionadas con asuntos profesionales de ANF Autoridad de Certificaci?n no est?n respaldadas por la empresa. El 13/02/2015 a las 23:58, Eddy Nigg escribi?: > > On 02/14/2015 12:33 AM, Dean Coclin wrote: >> You?ll probably realize after reading this that there isn?t much >> actionable material here as many members are ?scoping? or ?waiting >> for info? without any concrete response dates. We?ll keep this tally >> going and update as we get more info. >> >> Globalsign: Yes, can support >> >> Symantec: We don?t support this today. We?ve received very little >> demand for it from customers, but we?re in the process of scoping out >> the effort. >> >> Comodo:Yes, for CRL and OCSP >> >> TrendMicro:Yes >> GoDaddy: Waiting for info from network team >> >> Entrust:Yes for CRL and OCSP. >> >> Trustwave:We don?t support this today. Just started scoping the >> effort. Not many requests for this >> >> Digicert:We currently do not support it. Our connectivity providers >> support it, and it could be done with CRLs and OCSP, but we?d need to >> look for any gotchas before pulling the trigger. We?ve only had a >> couple of customers ask whether we support it. >> > > To add StartCom to the list, we could support it for almost > everything, but we have some historical CRL distribution points that > can't support IPv6 for now. It seems that OCSP would work, but CRLs > not 100%. > > Same as with Digicert, demand for IPv6 has been so low that we haven't > invested into it so far. > > -- > Regards > Signer: Eddy Nigg, COO/CTO > StartCom Ltd. > XMPP: startcom at startcom.org > Blog: Join the Revolution! > Twitter: Follow Me > > > > _______________________________________________ > 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/20150216/e55f39a5/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: logo-anf.png Type: image/png Size: 4746 bytes Desc: not available Url : https://cabforum.org/pipermail/public/attachments/20150216/e55f39a5/attachment-0001.png From realsky at cht.com.tw Tue Feb 17 03:02:09 2015 From: realsky at cht.com.tw (=?UTF-8?B?6Zmz56uL576k?=) Date: Tue, 17 Feb 2015 18:02:09 +0800 Subject: [cabfpub] Ballot 143 - Formalization of validation working group In-Reply-To: References: Message-ID: <00d701d04a98$cb5e6570$621b3050$@cht.com.tw> Chunghwa Telecom Co., Ltd. votes YES as Sincerely Yours, Li-Chun CHEN Engineer CISSP, CISA, CISM, PMP, Information & Communication Security Dept. Data Communication Business Group Chunghwa Telecom Co. Ltd. realsky at cht.com.tw +886-2-2344-4820#4025 From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of kirk_hall at trendmicro.com Sent: Friday, February 13, 2015 6:27 AM To: CABFPub (public at cabforum.org) Subject: [cabfpub] Ballot 143 - Formalization of validation working group Trend Micro votes yes. Kirk R. Hall Operations Director, Trust Services Trend Micro +1.503.753.3088 TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. 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/public/attachments/20150217/26c0ce7a/attachment.html From gerv at mozilla.org Tue Feb 17 04:12:35 2015 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 17 Feb 2015 11:12:35 +0000 Subject: [cabfpub] Domain Validation Revision In-Reply-To: References: <54DDCC5D.50305@mozilla.org> Message-ID: <54E32223.1070200@mozilla.org> On 16/02/15 21:57, kirk_hall at trendmicro.com wrote: > Gerv -- we always allowed attorney letters in the past. > > For DV/OV, it was an "any other method" means of domain confirmation. Who has used this method? Perhaps they could explain how they feel that this provides the "same level of assurance"? What expertise does an attorney have in determining actual domain control? > For EV, it was explicitly allowed under the EVGL (and there are still > references to it in the template Attorney Letter attached to the EVGL), > but /_by mistake_/ we deleted the reference when we changed EVGL 11.7 > simply to a cross reference to BR 11.1.1 ? we accidentally dropped the > old reference to using attorney-accountant letters for EV domain > confirmation (I can give you a version number reference to the old EVGL > if you want to confirm). That would be useful, please. > This is useful when the Domain Name Registrant has licensed the domain > to the Customer, or when the parent-sub relationship is not reported > correctly, etc. If they've licensed the domain to the customer, then surely the customer can demonstrate control in any of the normal ways? If they can't, then they don't actually have control of it, do they? Gerv From bruce.morton at entrust.com Tue Feb 17 05:27:36 2015 From: bruce.morton at entrust.com (Bruce Morton) Date: Tue, 17 Feb 2015 12:27:36 +0000 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names In-Reply-To: References: Message-ID: <452C99D20750E74083DBA441FF932385E4167C98@SOTTEXCH10.corp.ad.entrust.com> Entrust abstains. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Tuesday, February 10, 2015 1:39 PM To: public at cabforum.org Subject: [cabfpub] Ballot 144 - Validation rules for .onion names Here's the ballot with the two typos fixed: Applicants want a CA-signed .onion address for several reasons, including: - Powerful web platform features are restricted to secure origins, which are currently not available to onion names (in part, because of the lack of IANA registration). Permitting EV certs for onion names will help provide a secure origin for the service, moving onion towards use of powerful web platform features. - Currently, access to .onion names over https from a standard browser results in the standard existing 'Invalid Certificate' warning. Training users to click through security warnings lowers the value of these warnings and will cause users to miss important security information. Removing these warnings for the user, through use of a digital certificate, will help users recognize and avoid real MITM attacks. - The public needs attribution of ownership of the .onion address to differentiate onion services, including potential phishing services. Because onion names are not easily recognizable strings, providing the public with additional information about the operator has significant security improvements, especially in regions where use of the incorrect name could have lethal consequences. The following motion has been proposed by Jeremy Rowley of DigiCert and endorsed by Ryan Sleevi of Google and Wayne Thayer of GoDaddy. --------------------- Motion Starts --------------------- 1) Amend Section 9.2.1 of the Baseline Requirements v. 1.2.3 as follows: 9.2.1 Subject Alternative Name Extension Certificate Field: extensions:subjectAltName Required/Optional: Required Contents: This 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. The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate. Wildcard FQDNs are permitted. As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name, the CA SHALL notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016. Also as of the Effective Date, the CA SHALL NOT issue a certificate with an Expiry Date later than 1 November 2015 with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name. Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Name. Effective May 1, 2015, each CA SHALL revoke all unexpired Certificates with an Internal Name using onion as the right-most label in an entry in the subjectAltName Extension or commonName field unless such Certificate was issued in accordance with Appendix F of the EV Guidelines. 2) Amend Section 9.2.2 and 11.7.1 of the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2 as follows: 9.2.2. Subject Alternative Name Extension Certificate field: subjectAltName:dNSName Required/Optional: Required Contents: This extension MUST contain one or more host Domain Name(s) owned or controlled by the Subject and to be associated with the Subject's server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). Wildcard certificates are not allowed for EV Certificates except as permitted under Appendix F. 11.7 Verification of Applicant's Domain Name 11.7.1. Verification Requirements (1) For each Fully-Qualified Domain Name listed in a Certificate, other than a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant (or the Applicant's Parent Company, Subsidiary Company, or Affiliate, collectively referred to as "Applicant" for the purposes of this section) either is the Domain Name Registrant or has control over the FQDN using a procedure specified in Section 11.1.1 of the Baseline Requirements, except that a CA MAY NOT verify a domain using the procedure described 11.1.1(7). For a Certificate issued to a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant's control over the .onion Domain Name in accordance with Appendix F. (2) Mixed Character Set Domain Names: EV Certificates MAY include Domain Names containing mixed character sets only in compliance with the rules set forth by the domain registrar. The CA MUST visually compare any Domain Names with mixed character sets with known high risk domains. If a similarity is found, then the EV Certificate Request MUST be flagged as High Risk. The CA must perform reasonably appropriate additional authentication and verification to be certain beyond reasonable doubt that the Applicant and the target in question are the same organization. 3) Add a new Appendix F to the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2: Appendix F - Issuance of Certificates for .onion Domain Names A CA may issue an EV Certificate with .onion in the right-most label of the Domain Name provided that issuance complies with the requirements set forth in this Appendix: 1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) The CAB Forum has created an extension of the TBSCertificate for use in conveying hashes of keys related to .onion addresses. The Tor Service Descriptor Hash extension has the following format: cabf-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 } TorServiceDescriptorSyntax ::= SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash TorServiceDescriptorHash:: = SEQUENCE { onionURI UTF8String algorithm AlgorithmIdentifier subjectPublicKeyHash BIT STRING } Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 6234) performed over the DER-encoding of an ASN.1 SubjectPublicKey of the .onion service and SubjectPublicKeyHash is the hash output. 2. The CA MUST verify the Applicant's control over the .onion Domain Name using one of the following: a. The CA MAY verify the Applicant's control over the .onion service by posting a specific value at a well-known URL under RFC5785. b. The CA MAY verify the Applicant's control over the .onion service by having the Applicant provide a Certificate Request signed using the .onion public key if the Attributes section of the certificationRequestInfo contains: (i) A caSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy, 2) is generated by the CA, and 3) delivered to the Applicant through a Verified Method of Communication and (ii) An applicantSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy and 2) is generated by the Applicant. The signing nonce attributes have the following format: caSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-caSigningNonce } } cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } applicantSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-applicantSigningNonce } } cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 } 4. Each Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name MUST conform to the requirements of these Guidelines, including the content requirements in Section 9 and Appendix B of the Baseline Requirements, except that the CA MAY include a wildcard character in the Subject Alternative Name Extension and Subject Common Name Field as the left-most character in the .onion Domain Name provided inclusion of the wildcard character complies with Section 11.1.3 of the Baseline Requirements. 5. CAs MUST NOT issue a Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name with a validity period longer than 15 months. Despite Section 9.2.1 of the Baseline Requirements deprecating the use of Internal Names, a CA MAY issue a Certificate containing an .onion name with an expiration date later than 1 November 2015 after (and only if) .onion is officially recognized by the IESG as a reserved TLD. 6. On or before May 1, 2015, each CA MUST revoke all Certificates issued with the Subject Alternative Name extension or Common Name field that includes a Domain Name where .onion is in the right-most label of the Domain Name unless the Certificate was issued in compliance with this Appendix F. ---- Motion Ends ----- The review period for this ballot shall commence at 2200 UTC on Thursday, 4 February 2015, and will close at 2200 UTC on Thursday, 11 February 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on Monday, 18 February 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150217/4c539f0e/attachment-0001.html From haavardm at opera.com Tue Feb 17 06:05:54 2015 From: haavardm at opera.com (haavardm at work) Date: Tue, 17 Feb 2015 14:05:54 +0100 Subject: [cabfpub] Ballot 143 - Formalization of validation working group In-Reply-To: References: Message-ID: Opera votes YES. H?vard On Thu, Feb 12, 2015 at 11:26 PM, kirk_hall at trendmicro.com < kirk_hall at trendmicro.com> wrote: > Trend Micro votes yes. > > > > *Kirk R. Hall* > > Operations Director, Trust Services > > Trend Micro > > +1.503.753.3088 > > > > TREND MICRO EMAIL NOTICE > The information contained in this email and any attachments is confidential > and may be subject to copyright or other intellectual property protection. > If you are not the intended recipient, you are not authorized to use or > disclose this information, and we request that you notify us by reply mail or > telephone and delete the original message from your mail system. > > > _______________________________________________ > 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/20150217/40c86978/attachment.html From haavardm at opera.com Tue Feb 17 06:08:14 2015 From: haavardm at opera.com (haavardm at work) Date: Tue, 17 Feb 2015 14:08:14 +0100 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names Message-ID: Opera votes YES On Tue, Feb 10, 2015 at 7:38 PM, Jeremy Rowley wrote: > *Here?s the ballot with the two typos fixed:* > > > > Applicants want a CA-signed .onion address for several reasons, including: > > - Powerful web platform features are restricted to secure > origins, which are currently not available to onion names (in part, because > of the lack of IANA registration). Permitting EV certs for onion names > will help provide a secure origin for the service, moving onion towards use > of powerful web platform features. > > - Currently, access to .onion names over https from a > standard browser results in the standard existing 'Invalid Certificate' > warning. Training users to click through security warnings lowers the > value of these warnings and will cause users to miss important security > information. Removing these warnings for the user, through use of a > digital certificate, will help users recognize and avoid real MITM attacks. > > - The public needs attribution of ownership of the .onion > address to differentiate onion services, including potential phishing > services. Because onion names are not easily recognizable strings, > providing the public with additional information about the operator has > significant security improvements, especially in regions where use of the > incorrect name could have lethal consequences. > > > > The following motion has been proposed by Jeremy Rowley of DigiCert and > endorsed by Ryan Sleevi of Google and Wayne Thayer of GoDaddy. > > > > --------------------- > > Motion Starts > > --------------------- > > > > 1) Amend Section 9.2.1 of the Baseline Requirements v. 1.2.3 as follows: > > 9.2.1 Subject Alternative Name Extension > > Certificate Field: extensions:subjectAltName > > Required/Optional: Required > > Contents: This 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. The CA MUST confirm that > the Applicant controls the Fully-Qualified Domain Name or IP address or has > been granted the right to use it by the Domain Name Registrant or IP > address assignee, as appropriate. > > > > Wildcard FQDNs are permitted. As of the Effective Date of these > Requirements, prior to the issuance of a Certificate with a > subjectAlternativeName extension or Subject commonName field containing a > Reserved IP Address or Internal Name, the CA SHALL notify the Applicant > that the use of such Certificates has been deprecated by the CA / Browser > Forum and that the practice will be eliminated by October 2016. Also as of > the Effective Date, the CA SHALL NOT issue a certificate with an Expiry > Date later than 1 November 2015 with a subjectAlternativeName extension or > Subject commonName field containing a Reserved IP Address or Internal Name. > Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose > subjectAlternativeName extension or Subject commonName field contains a > Reserved IP Address or Internal Name. *Effective May 1, 2015, each CA > SHALL revoke all unexpired Certificates with an Internal Name using onion > as the right-most label in an entry in the subjectAltName Extension or > commonName field unless such Certificate was issued in accordance with > Appendix F of the EV Guidelines.* > > > > 2) Amend Section 9.2.2 and 11.7.1 of the Guidelines for the Issuance and > Management of Extended Validation Certificates v1.5.2 as follows: > > > > 9.2.2. Subject Alternative Name Extension Certificate field: > subjectAltName:dNSName > > Required/Optional: Required > > Contents: This extension MUST contain one or more host Domain Name(s) > owned or controlled by the Subject and to be associated with the Subject?s > server. Such server MAY be owned and operated by the Subject or another > entity (e.g., a hosting service). Wildcard certificates are not allowed for > EV Certificates* except as permitted under Appendix F*. > > > > 11.7 Verification of Applicant?s Domain Name > > > > 11.7.1. Verification Requirements > > > > (1) For each Fully-Qualified Domain Name listed in a Certificate, other > than a Domain Name with .onion in the right-most label of the Domain Name, > the CA SHALL confirm that, as of the date the Certificate was issued, the > Applicant (or the Applicant?s Parent Company, Subsidiary Company, or > Affiliate, collectively referred to as ?Applicant? for the purposes of this > section) either is the Domain Name Registrant or has control over the FQDN > using a procedure specified in Section 11.1.1 of the Baseline Requirements, > except that a CA MAY NOT verify a domain using the procedure described > 11.1.1(7). *For a Certificate issued to a Domain Name with .onion in the > right-most label of the Domain Name, the CA SHALL confirm that, as of the > date the Certificate was issued, the Applicant?s control over the .onion > Domain Name in accordance with Appendix F.* > > > > (2) Mixed Character Set Domain Names: EV Certificates MAY include Domain > Names containing mixed character sets only in compliance with the rules set > forth by the domain registrar. The CA MUST visually compare any Domain > Names with mixed character sets with known high risk domains. If a > similarity is found, then the EV Certificate Request MUST be flagged as > High Risk. The CA must perform reasonably appropriate additional > authentication and verification to be certain beyond reasonable doubt that > the Applicant and the target in question are the same organization. > > > > 3) Add a new Appendix F to the Guidelines for the Issuance and Management > of Extended Validation Certificates v1.5.2: > > > > Appendix F ? Issuance of Certificates for .onion Domain Names > > > > A CA may issue an EV Certificate with .onion in the right-most label of > the Domain Name provided that issuance complies with the requirements set > forth in this Appendix: > > 1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) > > The CAB Forum has created an extension of the TBSCertificate for use in > conveying hashes of keys related to .onion addresses. The Tor Service > Descriptor Hash extension has the following format: > > > > cabf-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 } > > > > TorServiceDescriptorSyntax ::= > > SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash > > > > TorServiceDescriptorHash:: = SEQUENCE { > > onionURI UTF8String > > algorithm AlgorithmIdentifier > > subjectPublicKeyHash BIT STRING } > > > > Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 6234) > performed over the DER-encoding of an ASN.1 SubjectPublicKey of the .onion > service and SubjectPublicKeyHash is the hash output. > > > > 2. The CA MUST verify the Applicant?s control over the .onion Domain > Name using one of the following: > > > > a. The CA MAY verify the Applicant?s control over the .onion service > by posting a specific value at a well-known URL under RFC5785. > > > > b. The CA MAY verify the Applicant?s control over the .onion service > by having the Applicant provide a Certificate Request signed using the > .onion public key if the Attributes section of the certificationRequestInfo > contains: > > > > (i) A caSigningNonce attribute that 1) contains a single value > with at least 64-bits of entropy, 2) is generated by the CA, and 3) > delivered to the Applicant through a Verified Method of Communication and > > (ii) An applicantSigningNonce attribute that 1) contains a > single value with at least 64-bits of entropy and 2) is generated by the > Applicant. > > > > The signing nonce attributes have the following format: > > > > caSigningNonce ATTRIBUTE ::= { > > WITH SYNTAX OCTET STRING > > EQUALITY MATCHING RULE octetStringMatch > > SINGLE VALUE TRUE > > ID { > cabf-caSigningNonce } > > } > > > > cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } > > > > applicantSigningNonce ATTRIBUTE ::= { > > WITH SYNTAX OCTET STRING > > EQUALITY MATCHING RULE octetStringMatch > > SINGLE VALUE TRUE > > ID { > cabf-applicantSigningNonce } > > } > > > > cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 } > > > > 4. Each Certificate that includes a Domain Name where .onion is in > the right-most label of the Domain Name MUST conform to the requirements of > these Guidelines, including the content requirements in Section 9 and > Appendix B of the Baseline Requirements, except that the CA MAY include a > wildcard character in the Subject Alternative Name Extension and Subject > Common Name Field as the left-most character in the .onion Domain Name > provided inclusion of the wildcard character complies with Section 11.1.3 > of the Baseline Requirements. > > > > 5. CAs MUST NOT issue a Certificate that includes a Domain Name where > .onion is in the right-most label of the Domain Name with a validity period > longer than 15 months. Despite Section 9.2.1 of the Baseline Requirements > deprecating the use of Internal Names, a CA MAY issue a Certificate > containing an .onion name with an expiration date later than 1 November > 2015 after (and only if) .onion is officially recognized by the IESG as a > reserved TLD. > > > > 6. On or before May 1, 2015, each CA MUST revoke all Certificates > issued with the Subject Alternative Name extension or Common Name field > that includes a Domain Name where .onion is in the right-most label of the > Domain Name unless the Certificate was issued in compliance with this > Appendix F. > > > > ---- > > Motion Ends > > ----- > > The review period for this ballot shall commence at 2200 UTC on Thursday, > 4 February 2015, and will close at 2200 UTC on Thursday, 11 February 2015. > Unless the motion is withdrawn during the review period, the voting period > will start immediately thereafter and will close at 2200 UTC on Monday, 18 > February 2015. Votes must be cast by posting an on-list reply to this > thread. > > A vote in favor of the motion must indicate a clear 'yes' in the response. > A vote against must indicate a clear 'no' in the response. A vote to > abstain must indicate a clear 'abstain' in the response. Unclear responses > will not be counted. The latest vote received from any representative of a > voting member before the close of the voting period will be counted. Voting > members are listed here: https://cabforum.org/members/ > > In order for the motion to be adopted, two thirds or more of the votes > cast by members in the CA category and greater than 50% of the votes cast > by members in the browser category must be in favor. Quorum is currently > nine (9) members? at least nine members must participate in the ballot, > either by voting in favor, voting against, or abstaining. > > > > > > _______________________________________________ > 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/20150217/f28b9b76/attachment-0001.html From md at ssc.lt Tue Feb 17 06:20:22 2015 From: md at ssc.lt (Moudrick M. Dadashov) Date: Tue, 17 Feb 2015 15:20:22 +0200 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names In-Reply-To: References: Message-ID: <54E34016.1010101@ssc.lt> SSC votes: "Yes". Thanks, M.D On 2/17/2015 3:08 PM, haavardm at work wrote: > Opera votes YES > > > On Tue, Feb 10, 2015 at 7:38 PM, Jeremy Rowley > > wrote: > > *Here?s the ballot with the two typos fixed:* > > Applicants want a CA-signed .onion address for several reasons, > including: > > - Powerful web platform features are restricted to secure origins, > which are currently not available to onion names (in part, because > of the lack of IANA registration). Permitting EV certs for onion > names will help provide a secure origin for the service, moving > onion towards use of powerful web platform features. > > - Currently, access to .onion names over https from a standard > browser results in the standard existing 'Invalid Certificate' > warning. Training users to click through security warnings lowers > the value of these warnings and will cause users to miss important > security information. Removing these warnings for the user, > through use of a digital certificate, will help users recognize > and avoid real MITM attacks. > > - The public needs attribution of ownership of the .onion address > to differentiate onion services, including potential phishing > services. Because onion names are not easily recognizable strings, > providing the public with additional information about the > operator has significant security improvements, especially in > regions where use of the incorrect name could have lethal > consequences. > > The following motion has been proposed by Jeremy Rowley of > DigiCert and endorsed by Ryan Sleevi of Google and Wayne Thayer of > GoDaddy. > > --------------------- > > Motion Starts > > --------------------- > > 1) Amend Section 9.2.1 of the Baseline Requirements v. 1.2.3 as > follows: > > 9.2.1 Subject Alternative Name Extension > > Certificate Field: extensions:subjectAltName > > Required/Optional: Required > > Contents: This 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. > The CA MUST confirm that the Applicant controls the > Fully-Qualified Domain Name or IP address or has been granted the > right to use it by the Domain Name Registrant or IP address > assignee, as appropriate. > > Wildcard FQDNs are permitted. As of the Effective Date of these > Requirements, prior to the issuance of a Certificate with a > subjectAlternativeName extension or Subject commonName field > containing a Reserved IP Address or Internal Name, the CA SHALL > notify the Applicant that the use of such Certificates has been > deprecated by the CA / Browser Forum and that the practice will be > eliminated by October 2016. Also as of the Effective Date, the CA > SHALL NOT issue a certificate with an Expiry Date later than 1 > November 2015 with a subjectAlternativeName extension or Subject > commonName field containing a Reserved IP Address or Internal > Name. Effective 1 October 2016, CAs SHALL revoke all unexpired > Certificates whose subjectAlternativeName extension or Subject > commonName field contains a Reserved IP Address or Internal Name. > _Effective May 1, 2015, each CA SHALL revoke all unexpired > Certificates with an Internal Name using onion as the right-most > label in an entry in the subjectAltName Extension or commonName > field unless such Certificate was issued in accordance with > Appendix F of the EV Guidelines._ > > 2) Amend Section 9.2.2 and 11.7.1 of the Guidelines for the > Issuance and Management of Extended Validation Certificates v1.5.2 > as follows: > > 9.2.2. Subject Alternative Name Extension Certificate field: > subjectAltName:dNSName > > Required/Optional: Required > > Contents: This extension MUST contain one or more host Domain > Name(s) owned or controlled by the Subject and to be associated > with the Subject?s server. Such server MAY be owned and operated > by the Subject or another entity (e.g., a hosting service). > Wildcard certificates are not allowed for EV Certificates_except > as permitted under Appendix F_. > > 11.7 Verification of Applicant?s Domain Name > > 11.7.1. Verification Requirements > > (1) For each Fully-Qualified Domain Name listed in a Certificate, > other than a Domain Name with .onion in the right-most label of > the Domain Name, the CA SHALL confirm that, as of the date the > Certificate was issued, the Applicant (or the Applicant?s Parent > Company, Subsidiary Company, or Affiliate, collectively referred > to as ?Applicant? for the purposes of this section) either is the > Domain Name Registrant or has control over the FQDN using a > procedure specified in Section 11.1.1 of the Baseline > Requirements, except that a CA MAY NOT verify a domain using the > procedure described 11.1.1(7). _For a Certificate issued to a > Domain Name with .onion in the right-most label of the Domain > Name, the CA SHALL confirm that, as of the date the Certificate > was issued, the Applicant?s control over the .onion Domain Name in > accordance with Appendix F._ > > (2) Mixed Character Set Domain Names: EV Certificates MAY include > Domain Names containing mixed character sets only in compliance > with the rules set forth by the domain registrar. The CA MUST > visually compare any Domain Names with mixed character sets with > known high risk domains. If a similarity is found, then the EV > Certificate Request MUST be flagged as High Risk. The CA must > perform reasonably appropriate additional authentication and > verification to be certain beyond reasonable doubt that the > Applicant and the target in question are the same organization. > > 3) Add a new Appendix F to the Guidelines for the Issuance and > Management of Extended Validation Certificates v1.5.2: > > Appendix F ? Issuance of Certificates for .onion Domain Names > > A CA may issue an EV Certificate with .onion in the right-most > label of the Domain Name provided that issuance complies with the > requirements set forth in this Appendix: > > 1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) > > The CAB Forum has created an extension of the TBSCertificate for > use in conveying hashes of keys related to .onion addresses. The > Tor Service Descriptor Hash extension has the following format: > > cabf-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 } > > TorServiceDescriptorSyntax ::= > > SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash > > TorServiceDescriptorHash:: = SEQUENCE { > > onionURI UTF8String > > algorithm AlgorithmIdentifier > > subjectPublicKeyHash BIT STRING } > > Where the AlgorithmIdentifier is a hashing algorithm (defined in > RFC 6234) performed over the DER-encoding of an ASN.1 > SubjectPublicKey of the .onion service and SubjectPublicKeyHash is > the hash output. > > 2. The CA MUST verify the Applicant?s control over the .onion > Domain Name using one of the following: > > a. The CA MAY verify the Applicant?s control over the .onion > service by posting a specific value at a well-known URL under > RFC5785. > > b. The CA MAY verify the Applicant?s control over the .onion > service by having the Applicant provide a Certificate Request > signed using the .onion public key if the Attributes section of > the certificationRequestInfo contains: > > (i) A caSigningNonce attribute that 1) contains a single value > with at least 64-bits of entropy, 2) is generated by the CA, and > 3) delivered to the Applicant through a Verified Method of > Communication and > > (ii) An applicantSigningNonce attribute that 1) contains a single > value with at least 64-bits of entropy and 2) is generated by the > Applicant. > > The signing nonce attributes have the following format: > > caSigningNonce ATTRIBUTE ::= { > > WITH SYNTAX OCTET STRING > > EQUALITY MATCHING RULE octetStringMatch > > SINGLE VALUE TRUE > > ID { cabf-caSigningNonce } > > } > > cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } > > applicantSigningNonce ATTRIBUTE ::= { > > WITH SYNTAX OCTET STRING > > EQUALITY MATCHING RULE octetStringMatch > > SINGLE VALUE TRUE > > ID { cabf-applicantSigningNonce } > > } > > cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 } > > 4. Each Certificate that includes a Domain Name where .onion is in > the right-most label of the Domain Name MUST conform to the > requirements of these Guidelines, including the content > requirements in Section 9 and Appendix B of the Baseline > Requirements, except that the CA MAY include a wildcard character > in the Subject Alternative Name Extension and Subject Common Name > Field as the left-most character in the .onion Domain Name > provided inclusion of the wildcard character complies with Section > 11.1.3 of the Baseline Requirements. > > 5. CAs MUST NOT issue a Certificate that includes a Domain Name > where .onion is in the right-most label of the Domain Name with a > validity period longer than 15 months. Despite Section 9.2.1 of > the Baseline Requirements deprecating the use of Internal Names, a > CA MAY issue a Certificate containing an .onion name with an > expiration date later than 1 November 2015 after (and only if) > .onion is officially recognized by the IESG as a reserved TLD. > > 6. On or before May 1, 2015, each CA MUST revoke all Certificates > issued with the Subject Alternative Name extension or Common Name > field that includes a Domain Name where .onion is in the > right-most label of the Domain Name unless the Certificate was > issued in compliance with this Appendix F. > > ---- > > Motion Ends > > ----- > > The review period for this ballot shall commence at 2200 UTC on > Thursday, 4 February 2015, and will close at 2200 UTC on Thursday, > 11 February 2015. Unless the motion is withdrawn during the review > period, the voting period will start immediately thereafter and > will close at 2200 UTC on Monday, 18 February 2015. Votes must be > cast by posting an on-list reply to this thread. > > A vote in favor of the motion must indicate a clear 'yes' in the > response. A vote against must indicate a clear 'no' in the > response. A vote to abstain must indicate a clear 'abstain' in the > response. Unclear responses will not be counted. The latest vote > received from any representative of a voting member before the > close of the voting period will be counted. Voting members are > listed here: https://cabforum.org/members/ > > In order for the motion to be adopted, two thirds or more of the > votes cast by members in the CA category and greater than 50% of > the votes cast by members in the browser category must be in > favor. Quorum is currently nine (9) members? at least nine members > must participate in the ballot, either by voting in favor, voting > against, or abstaining. > > > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public > > > > > _______________________________________________ > 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/20150217/9f6d3874/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3653 bytes Desc: S/MIME Cryptographic Signature Url : https://cabforum.org/pipermail/public/attachments/20150217/9f6d3874/attachment-0001.bin From realsky at cht.com.tw Tue Feb 17 06:56:23 2015 From: realsky at cht.com.tw (=?big5?B?s6+l37hz?=) Date: Tue, 17 Feb 2015 21:56:23 +0800 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names In-Reply-To: References: Message-ID: <004001d04ab9$842e5ae0$8c8b10a0$@cht.com.tw> Chunghwa Telecom Co., Ltd. vote ?No? not because we object supporting .onion names but because we think that a method suggested in the Appendix F for verifying the Applicant?s control over the .onion Domain Name has security problem. In the Appendix F, the method 2.b says 'The CA MAY verify the Applicant 's control over the .onion service by having the Applicant provide a Certificate Request signed using the .onion public key ?'. What we concerns is that if the .onion private key used to sign the PKCS#10 SSL Certificate Request is not the same one as the SSL server 's private key, it will cause security problem. For security reason, PKCS#10 Certificate Request need to be signed by the private key corresponding to the public key contained in the CertificationRequestInfo. Please refer to Note 2 of section 3 of RFC 2986 (the PKCS#10 standard), where it explains the security concern. Note 2 of section 3 of RFC 2986 is extracted as below: Note 2 - The signature on the certification request prevents an entity from requesting a certificate with another party's public key. Such an attack would give the entity the minor ability to pretend to be the originator of any message signed by the other party. This attack is significant only if the entity does not know the message being signed and the signed part of the message does not identify the signer. The entity would still not be able to decrypt messages intended for the other party, of course. Sincerely Yours, Li-Chun CHEN Engineer CISSP, CISA, CISM, PMP, Information & Communication Security Dept. Data Communication Business Group Chunghwa Telecom Co. Ltd. realsky at cht.com.tw +886-2-2344-4820#4025 From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Wednesday, February 11, 2015 2:39 AM To: public at cabforum.org Subject: [cabfpub] Ballot 144 - Validation rules for .onion names Here?s the ballot with the two typos fixed: Applicants want a CA-signed .onion address for several reasons, including: - Powerful web platform features are restricted to secure origins, which are currently not available to onion names (in part, because of the lack of IANA registration). Permitting EV certs for onion names will help provide a secure origin for the service, moving onion towards use of powerful web platform features. - Currently, access to .onion names over https from a standard browser results in the standard existing 'Invalid Certificate' warning. Training users to click through security warnings lowers the value of these warnings and will cause users to miss important security information. Removing these warnings for the user, through use of a digital certificate, will help users recognize and avoid real MITM attacks. - The public needs attribution of ownership of the .onion address to differentiate onion services, including potential phishing services. Because onion names are not easily recognizable strings, providing the public with additional information about the operator has significant security improvements, especially in regions where use of the incorrect name could have lethal consequences. The following motion has been proposed by Jeremy Rowley of DigiCert and endorsed by Ryan Sleevi of Google and Wayne Thayer of GoDaddy. --------------------- Motion Starts --------------------- 1) Amend Section 9.2.1 of the Baseline Requirements v. 1.2.3 as follows: 9.2.1 Subject Alternative Name Extension Certificate Field: extensions:subjectAltName Required/Optional: Required Contents: This 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. The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate. Wildcard FQDNs are permitted. As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name, the CA SHALL notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016. Also as of the Effective Date, the CA SHALL NOT issue a certificate with an Expiry Date later than 1 November 2015 with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name. Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Name. Effective May 1, 2015, each CA SHALL revoke all unexpired Certificates with an Internal Name using onion as the right-most label in an entry in the subjectAltName Extension or commonName field unless such Certificate was issued in accordance with Appendix F of the EV Guidelines. 2) Amend Section 9.2.2 and 11.7.1 of the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2 as follows: 9.2.2. Subject Alternative Name Extension Certificate field: subjectAltName: dNSName Required/Optional: Required Contents: This extension MUST contain one or more host Domain Name(s) owned or controlled by the Subject and to be associated with the Subject?s server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). Wildcard certificates are not allowed for EV Certificates except as permitted under Appendix F. 11.7 Verification of Applicant?s Domain Name 11.7.1. Verification Requirements (1) For each Fully-Qualified Domain Name listed in a Certificate, other than a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant (or the Applicant?s Parent Company, Subsidiary Company, or Affiliate, collectively referred to as ?Applicant? for the purposes of this section) either is the Domain Name Registrant or has control over the FQDN using a procedure specified in Section 11.1.1 of the Baseline Requirements, except that a CA MAY NOT verify a domain using the procedure described 11.1.1(7). For a Certificate issued to a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant?s control over the .onion Domain Name in accordance with Appendix F. (2) Mixed Character Set Domain Names: EV Certificates MAY include Domain Names containing mixed character sets only in compliance with the rules set forth by the domain registrar. The CA MUST visually compare any Domain Names with mixed character sets with known high risk domains. If a similarity is found, then the EV Certificate Request MUST be flagged as High Risk. The CA must perform reasonably appropriate additional authentication and verification to be certain beyond reasonable doubt that the Applicant and the target in question are the same organization. 3) Add a new Appendix F to the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2: Appendix F ? Issuance of Certificates for .onion Domain Names A CA may issue an EV Certificate with .onion in the right-most label of the Domain Name provided that issuance complies with the requirements set forth in this Appendix: 1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) The CAB Forum has created an extension of the TBSCertificate for use in conveying hashes of keys related to .onion addresses. The Tor Service Descriptor Hash extension has the following format: cabf-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 } TorServiceDescriptorSyntax ::= SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash TorServiceDescriptorHash:: = SEQUENCE { onionURI UTF8String algorithm AlgorithmIdentifier subjectPublicKeyHash BIT STRING } Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 6234) performed over the DER-encoding of an ASN.1 SubjectPublicKey of the .onion service and SubjectPublicKeyHash is the hash output. 2. The CA MUST verify the Applicant?s control over the .onion Domain Name using one of the following: a. The CA MAY verify the Applicant?s control over the .onion service by posting a specific value at a well-known URL under RFC5785. b. The CA MAY verify the Applicant?s control over the .onion service by having the Applicant provide a Certificate Request signed using the .onion public key if the Attributes section of the certificationRequestInfo contains: (i) A caSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy, 2) is generated by the CA, and 3) delivered to the Applicant through a Verified Method of Communication and (ii) An applicantSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy and 2) is generated by the Applicant. The signing nonce attributes have the following format: caSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-caSigningNonce } } cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } applicantSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-applicantSigningNonce } } cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 } 4. Each Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name MUST conform to the requirements of these Guidelines, including the content requirements in Section 9 and Appendix B of the Baseline Requirements, except that the CA MAY include a wildcard character in the Subject Alternative Name Extension and Subject Common Name Field as the left-most character in the .onion Domain Name provided inclusion of the wildcard character complies with Section 11.1.3 of the Baseline Requirements. 5. CAs MUST NOT issue a Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name with a validity period longer than 15 months. Despite Section 9.2.1 of the Baseline Requirements deprecating the use of Internal Names, a CA MAY issue a Certificate containing an .onion name with an expiration date later than 1 November 2015 after (and only if) .onion is officially recognized by the IESG as a reserved TLD. 6. On or before May 1, 2015, each CA MUST revoke all Certificates issued with the Subject Alternative Name extension or Common Name field that includes a Domain Name where .onion is in the right-most label of the Domain Name unless the Certificate was issued in compliance with this Appendix F. ---- Motion Ends ----- The review period for this ballot shall commence at 2200 UTC on Thursday, 4 February 2015, and will close at 2200 UTC on Thursday, 11 February 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on Monday, 18 February 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members? at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150217/9938bf15/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6450 bytes Desc: not available Url : https://cabforum.org/pipermail/public/attachments/20150217/9938bf15/attachment-0001.bin From robert.vande.rijt at logius.nl Tue Feb 17 07:00:11 2015 From: robert.vande.rijt at logius.nl (Rijt, R.A. van de (Robert) - Logius) Date: Tue, 17 Feb 2015 14:00:11 +0000 Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group In-Reply-To: References: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> Message-ID: Logius PKIoverheid votes yes. Regards, Robert From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Wednesday, February 4, 2015 4:05 PM To: CABFPub Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group Ballot 143 - Formalization of validation working group ---- Reason ---- In order to address validation issues and inconsistencies in both the SSL Baseline Requirements and the EV Guidelines, the CAB Forum has held an informal working group previously referred to as the Extended Validation Working Group now known as the Validation Working Group, would like to modify its scope to include validation in the Baseline Requirements as well as the EV Guidelines. Jeremy Rowley of DigiCert made the following motion, which was endorsed by Rich Smith of Comodo and Kirk Hall of TrendMicro ---- Motion begins ---- The CA-Browser Forum formally establishes the Validation Working Group as an official working group of the CAB Forum, replacing the previous informal EV working group. The scope of this working group is to address issues arising under adopted CAB Forum standards related to the validation of certificate information and the inclusion of information in certificates. Scope: The Validation Working Group will consider all matters relating to the validation and inclusion of information in certificates under adopted CAB Forum guidelines. Deliverables: The Working Group shall produce one or more documents offering options to the Forum for validation within the scope defined above. ---- Motion Ends ---- The review period for this ballot shall commence at 2200 UTC on 5 Feb 2015, and will close at 2200 UTC on 11 Feb 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on 18 Feb 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. ________________________________ Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten. This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages. . -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150217/d2abea35/attachment.html From tom at ritter.vg Tue Feb 17 08:13:30 2015 From: tom at ritter.vg (Tom Ritter) Date: Tue, 17 Feb 2015 09:13:30 -0600 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names In-Reply-To: <004001d04ab9$842e5ae0$8c8b10a0$@cht.com.tw> References: <004001d04ab9$842e5ae0$8c8b10a0$@cht.com.tw> Message-ID: On 17 February 2015 at 07:56, ??? wrote: > > > Chunghwa Telecom Co., Ltd. vote ?No? not because we object supporting > .onion names but because we think that a method suggested in the Appendix F > for verifying the Applicant?s control over the .onion Domain Name has > security problem. In the Appendix F, the method 2.b says 'The CA MAY verify > the Applicant 's control over the .onion service by having the Applicant > provide a Certificate Request signed using the .onion public key ?'. What we > concerns is that if the .onion private key used to sign the PKCS#10 SSL > Certificate Request is not the same one as the SSL server 's private key, it > will cause security problem. For security reason, PKCS#10 Certificate > Request need to be signed by the private key corresponding to the public key > contained in the CertificationRequestInfo. Please refer to Note 2 of section > 3 of RFC 2986 (the PKCS#10 standard), where it explains the security > concern. Note 2 of section 3 of RFC 2986 is extracted as below: Hi Li-Chun CHEN, It was always my understanding that this CSR (signed by the onion key) was in ADDITION to the CSR signed with the SSL private key, not in place of. I guess the text does not bear this out clearly, apologies. Otherwise, yes I agree that would be a problem. (The applicant could get a certificate for a .onion address they control but a SSL private key they do not. Doesn't really introduce a security vulnerability for anyone but themselves, but clearly not correct issuance.) -tom From erwann.abalea at opentrust.com Tue Feb 17 09:38:05 2015 From: erwann.abalea at opentrust.com (Erwann Abalea) Date: Tue, 17 Feb 2015 17:38:05 +0100 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: References: <54DD1DED.4090105@mozilla.org> <54DD289E.8040304@mozilla.org> <54DDC98E.8020907@mozilla.org> Message-ID: <54E36E6D.8070106@opentrust.com> Bonjour, Coming back on this email, as it seems it hasn't been fully answered. Le 13/02/2015 17:28, kirk_hall at trendmicro.com a ?crit : > > [...] > > I have to circle back to ?Why are we doing this?? > > ?Tor users want to visit websites anonymously. [That sounds like > something CAs should support if possible] > > ?Website owners do **not** want anonymity ? in fact, just the > opposite. They want EV certs with their identity information included > that will work for Tor users. > > ?For some reason, regular TLD certs (like .com certs) won?t work after > Tor users go through the Tor blender. [Does anyone know why that is > the case?] > A TorBrowser user can connect to https://www.facebook.com, it will have the nice padlock icon, and all the packets will go through the Tor mesh network. A "{elinks,chrome,IE,whatever}+tor+socks5-in-between" user can do the same action with the same guarantees. > ?But for some reason, Internal Name .onion certs **do** work for Tor > users after they go through the Tor blender. [Does anyone know why > this is so?] > > ?Tor does not want to apply for .onion as a TLD, and does not want to > be the registrar for .onion [Why not? That would solve everything by > making .onion a TLD, so all the current CA rules could apply. And > remember, website users are not looking for anonymity in their certs ? > they want EV certs with their identity displayed prominently in the > browsers.] > > ?The Tor process for assigning .onion domains does not require domains > to be unique. > IIUC, asking Tor to connect to some identified server creates a circuit, involving at least 3 nodes (entry, relay+, exit) to provide some anonymity. Asking Tor to connect to a .onion address involves requesting the nearest catalog of hidden services to get the Tor node hosting this hidden service, and the circuit will never go through an exit node, providing confidentiality. This confidentiality is already offered by TLS. -- Erwann ABALEA -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150217/8c8060c0/attachment-0001.html From robin at comodo.com Tue Feb 17 10:04:09 2015 From: robin at comodo.com (Robin Alden) Date: Tue, 17 Feb 2015 17:04:09 -0000 Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group In-Reply-To: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> References: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> Message-ID: <0a4901d04ad3$bef7f360$3ce7da20$@comodo.com> Comodo votes 'Yes'. Regards Robin Alden Comodo From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: 04 February 2015 21:05 To: CABFPub Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group Ballot 143 - Formalization of validation working group ---- Reason ---- In order to address validation issues and inconsistencies in both the SSL Baseline Requirements and the EV Guidelines, the CAB Forum has held an informal working group previously referred to as the Extended Validation Working Group now known as the Validation Working Group, would like to modify its scope to include validation in the Baseline Requirements as well as the EV Guidelines. Jeremy Rowley of DigiCert made the following motion, which was endorsed by Rich Smith of Comodo and Kirk Hall of TrendMicro ---- Motion begins ---- The CA-Browser Forum formally establishes the Validation Working Group as an official working group of the CAB Forum, replacing the previous informal EV working group. The scope of this working group is to address issues arising under adopted CAB Forum standards related to the validation of certificate information and the inclusion of information in certificates. Scope: The Validation Working Group will consider all matters relating to the validation and inclusion of information in certificates under adopted CAB Forum guidelines. Deliverables: The Working Group shall produce one or more documents offering options to the Forum for validation within the scope defined above. ---- Motion Ends ---- The review period for this ballot shall commence at 2200 UTC on 5 Feb 2015, and will close at 2200 UTC on 11 Feb 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on 18 Feb 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150217/75790759/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5156 bytes Desc: not available Url : https://cabforum.org/pipermail/public/attachments/20150217/75790759/attachment.bin From JRandall at trustwave.com Tue Feb 17 10:10:59 2015 From: JRandall at trustwave.com (John Randall) Date: Tue, 17 Feb 2015 17:10:59 +0000 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names Message-ID: Trustwave ABSTAINS Cheers- John From: Miskovic Peter > Date: Monday, February 16, 2015 at 8:34 AM To: "public at cabforum.org" > Subject: Re: [cabfpub] Ballot 144 - Validation rules for .onion names Ballot 144 - Validation rules for .onion names: Disig abstains. Regards, Peter Miskovic From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Tuesday, February 10, 2015 7:39 PM To: public at cabforum.org Subject: [cabfpub] Ballot 144 - Validation rules for .onion names Here?s the ballot with the two typos fixed: Applicants want a CA-signed .onion address for several reasons, including: - Powerful web platform features are restricted to secure origins, which are currently not available to onion names (in part, because of the lack of IANA registration). Permitting EV certs for onion names will help provide a secure origin for the service, moving onion towards use of powerful web platform features. - Currently, access to .onion names over https from a standard browser results in the standard existing 'Invalid Certificate' warning. Training users to click through security warnings lowers the value of these warnings and will cause users to miss important security information. Removing these warnings for the user, through use of a digital certificate, will help users recognize and avoid real MITM attacks. - The public needs attribution of ownership of the .onion address to differentiate onion services, including potential phishing services. Because onion names are not easily recognizable strings, providing the public with additional information about the operator has significant security improvements, especially in regions where use of the incorrect name could have lethal consequences. The following motion has been proposed by Jeremy Rowley of DigiCert and endorsed by Ryan Sleevi of Google and Wayne Thayer of GoDaddy. --------------------- Motion Starts --------------------- 1) Amend Section 9.2.1 of the Baseline Requirements v. 1.2.3 as follows: 9.2.1 Subject Alternative Name Extension Certificate Field: extensions:subjectAltName Required/Optional: Required Contents: This 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. The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate. Wildcard FQDNs are permitted. As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name, the CA SHALL notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016. Also as of the Effective Date, the CA SHALL NOT issue a certificate with an Expiry Date later than 1 November 2015 with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name. Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Name. Effective May 1, 2015, each CA SHALL revoke all unexpired Certificates with an Internal Name using onion as the right-most label in an entry in the subjectAltName Extension or commonName field unless such Certificate was issued in accordance with Appendix F of the EV Guidelines. 2) Amend Section 9.2.2 and 11.7.1 of the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2 as follows: 9.2.2. Subject Alternative Name Extension Certificate field: subjectAltName:dNSName Required/Optional: Required Contents: This extension MUST contain one or more host Domain Name(s) owned or controlled by the Subject and to be associated with the Subject?s server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). Wildcard certificates are not allowed for EV Certificates except as permitted under Appendix F. 11.7 Verification of Applicant?s Domain Name 11.7.1. Verification Requirements (1) For each Fully-Qualified Domain Name listed in a Certificate, other than a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant (or the Applicant?s Parent Company, Subsidiary Company, or Affiliate, collectively referred to as ?Applicant? for the purposes of this section) either is the Domain Name Registrant or has control over the FQDN using a procedure specified in Section 11.1.1 of the Baseline Requirements, except that a CA MAY NOT verify a domain using the procedure described 11.1.1(7). For a Certificate issued to a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant?s control over the .onion Domain Name in accordance with Appendix F. (2) Mixed Character Set Domain Names: EV Certificates MAY include Domain Names containing mixed character sets only in compliance with the rules set forth by the domain registrar. The CA MUST visually compare any Domain Names with mixed character sets with known high risk domains. If a similarity is found, then the EV Certificate Request MUST be flagged as High Risk. The CA must perform reasonably appropriate additional authentication and verification to be certain beyond reasonable doubt that the Applicant and the target in question are the same organization. 3) Add a new Appendix F to the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2: Appendix F ? Issuance of Certificates for .onion Domain Names A CA may issue an EV Certificate with .onion in the right-most label of the Domain Name provided that issuance complies with the requirements set forth in this Appendix: 1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) The CAB Forum has created an extension of the TBSCertificate for use in conveying hashes of keys related to .onion addresses. The Tor Service Descriptor Hash extension has the following format: cabf-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 } TorServiceDescriptorSyntax ::= SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash TorServiceDescriptorHash:: = SEQUENCE { onionURI UTF8String algorithm AlgorithmIdentifier subjectPublicKeyHash BIT STRING } Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 6234) performed over the DER-encoding of an ASN.1 SubjectPublicKey of the .onion service and SubjectPublicKeyHash is the hash output. 2. The CA MUST verify the Applicant?s control over the .onion Domain Name using one of the following: a. The CA MAY verify the Applicant?s control over the .onion service by posting a specific value at a well-known URL under RFC5785. b. The CA MAY verify the Applicant?s control over the .onion service by having the Applicant provide a Certificate Request signed using the .onion public key if the Attributes section of the certificationRequestInfo contains: (i) A caSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy, 2) is generated by the CA, and 3) delivered to the Applicant through a Verified Method of Communication and (ii) An applicantSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy and 2) is generated by the Applicant. The signing nonce attributes have the following format: caSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-caSigningNonce } } cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } applicantSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-applicantSigningNonce } } cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 } 4. Each Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name MUST conform to the requirements of these Guidelines, including the content requirements in Section 9 and Appendix B of the Baseline Requirements, except that the CA MAY include a wildcard character in the Subject Alternative Name Extension and Subject Common Name Field as the left-most character in the .onion Domain Name provided inclusion of the wildcard character complies with Section 11.1.3 of the Baseline Requirements. 5. CAs MUST NOT issue a Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name with a validity period longer than 15 months. Despite Section 9.2.1 of the Baseline Requirements deprecating the use of Internal Names, a CA MAY issue a Certificate containing an .onion name with an expiration date later than 1 November 2015 after (and only if) .onion is officially recognized by the IESG as a reserved TLD. 6. On or before May 1, 2015, each CA MUST revoke all Certificates issued with the Subject Alternative Name extension or Common Name field that includes a Domain Name where .onion is in the right-most label of the Domain Name unless the Certificate was issued in compliance with this Appendix F. ---- Motion Ends ----- The review period for this ballot shall commence at 2200 UTC on Thursday, 4 February 2015, and will close at 2200 UTC on Thursday, 11 February 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on Monday, 18 February 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members? at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. ________________________________ This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150217/6d803535/attachment-0001.html From S.Davidson at quovadisglobal.com Tue Feb 17 10:24:13 2015 From: S.Davidson at quovadisglobal.com (Stephen Davidson) Date: Tue, 17 Feb 2015 17:24:13 +0000 Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group In-Reply-To: References: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> Message-ID: QuoVadis votes yes. Best, Stephen From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Wednesday, February 4, 2015 4:05 PM To: CABFPub Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group Ballot 143 - Formalization of validation working group ---- Reason ---- In order to address validation issues and inconsistencies in both the SSL Baseline Requirements and the EV Guidelines, the CAB Forum has held an informal working group previously referred to as the Extended Validation Working Group now known as the Validation Working Group, would like to modify its scope to include validation in the Baseline Requirements as well as the EV Guidelines. Jeremy Rowley of DigiCert made the following motion, which was endorsed by Rich Smith of Comodo and Kirk Hall of TrendMicro ---- Motion begins ---- The CA-Browser Forum formally establishes the Validation Working Group as an official working group of the CAB Forum, replacing the previous informal EV working group. The scope of this working group is to address issues arising under adopted CAB Forum standards related to the validation of certificate information and the inclusion of information in certificates. Scope: The Validation Working Group will consider all matters relating to the validation and inclusion of information in certificates under adopted CAB Forum guidelines. Deliverables: The Working Group shall produce one or more documents offering options to the Forum for validation within the scope defined above. ---- Motion Ends ---- The review period for this ballot shall commence at 2200 UTC on 5 Feb 2015, and will close at 2200 UTC on 11 Feb 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on 18 Feb 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. _____ Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten. This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages. . -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150217/8303be83/attachment.html From robin at comodo.com Tue Feb 17 10:39:45 2015 From: robin at comodo.com (Robin Alden) Date: Tue, 17 Feb 2015 17:39:45 -0000 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names In-Reply-To: References: Message-ID: <0afe01d04ad8$b86d3320$29479960$@comodo.com> Comodo abstains. Regards Robin Alden Comodo From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: 10 February 2015 18:39 To: public at cabforum.org Subject: [cabfpub] Ballot 144 - Validation rules for .onion names Here's the ballot with the two typos fixed: Applicants want a CA-signed .onion address for several reasons, including: - Powerful web platform features are restricted to secure origins, which are currently not available to onion names (in part, because of the lack of IANA registration). Permitting EV certs for onion names will help provide a secure origin for the service, moving onion towards use of powerful web platform features. - Currently, access to .onion names over https from a standard browser results in the standard existing 'Invalid Certificate' warning. Training users to click through security warnings lowers the value of these warnings and will cause users to miss important security information. Removing these warnings for the user, through use of a digital certificate, will help users recognize and avoid real MITM attacks. - The public needs attribution of ownership of the .onion address to differentiate onion services, including potential phishing services. Because onion names are not easily recognizable strings, providing the public with additional information about the operator has significant security improvements, especially in regions where use of the incorrect name could have lethal consequences. The following motion has been proposed by Jeremy Rowley of DigiCert and endorsed by Ryan Sleevi of Google and Wayne Thayer of GoDaddy. --------------------- Motion Starts --------------------- 1) Amend Section 9.2.1 of the Baseline Requirements v. 1.2.3 as follows: 9.2.1 Subject Alternative Name Extension Certificate Field: extensions:subjectAltName Required/Optional: Required Contents: This 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. The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate. Wildcard FQDNs are permitted. As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name, the CA SHALL notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016. Also as of the Effective Date, the CA SHALL NOT issue a certificate with an Expiry Date later than 1 November 2015 with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name. Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Name. Effective May 1, 2015, each CA SHALL revoke all unexpired Certificates with an Internal Name using onion as the right-most label in an entry in the subjectAltName Extension or commonName field unless such Certificate was issued in accordance with Appendix F of the EV Guidelines. 2) Amend Section 9.2.2 and 11.7.1 of the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2 as follows: 9.2.2. Subject Alternative Name Extension Certificate field: subjectAltName:dNSName Required/Optional: Required Contents: This extension MUST contain one or more host Domain Name(s) owned or controlled by the Subject and to be associated with the Subject's server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). Wildcard certificates are not allowed for EV Certificates except as permitted under Appendix F. 11.7 Verification of Applicant's Domain Name 11.7.1. Verification Requirements (1) For each Fully-Qualified Domain Name listed in a Certificate, other than a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant (or the Applicant's Parent Company, Subsidiary Company, or Affiliate, collectively referred to as "Applicant" for the purposes of this section) either is the Domain Name Registrant or has control over the FQDN using a procedure specified in Section 11.1.1 of the Baseline Requirements, except that a CA MAY NOT verify a domain using the procedure described 11.1.1(7). For a Certificate issued to a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant's control over the .onion Domain Name in accordance with Appendix F. (2) Mixed Character Set Domain Names: EV Certificates MAY include Domain Names containing mixed character sets only in compliance with the rules set forth by the domain registrar. The CA MUST visually compare any Domain Names with mixed character sets with known high risk domains. If a similarity is found, then the EV Certificate Request MUST be flagged as High Risk. The CA must perform reasonably appropriate additional authentication and verification to be certain beyond reasonable doubt that the Applicant and the target in question are the same organization. 3) Add a new Appendix F to the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2: Appendix F - Issuance of Certificates for .onion Domain Names A CA may issue an EV Certificate with .onion in the right-most label of the Domain Name provided that issuance complies with the requirements set forth in this Appendix: 1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) The CAB Forum has created an extension of the TBSCertificate for use in conveying hashes of keys related to .onion addresses. The Tor Service Descriptor Hash extension has the following format: cabf-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 } TorServiceDescriptorSyntax ::= SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash TorServiceDescriptorHash:: = SEQUENCE { onionURI UTF8String algorithm AlgorithmIdentifier subjectPublicKeyHash BIT STRING } Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 6234) performed over the DER-encoding of an ASN.1 SubjectPublicKey of the .onion service and SubjectPublicKeyHash is the hash output. 2. The CA MUST verify the Applicant's control over the .onion Domain Name using one of the following: a. The CA MAY verify the Applicant's control over the .onion service by posting a specific value at a well-known URL under RFC5785. b. The CA MAY verify the Applicant's control over the .onion service by having the Applicant provide a Certificate Request signed using the .onion public key if the Attributes section of the certificationRequestInfo contains: (i) A caSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy, 2) is generated by the CA, and 3) delivered to the Applicant through a Verified Method of Communication and (ii) An applicantSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy and 2) is generated by the Applicant. The signing nonce attributes have the following format: caSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-caSigningNonce } } cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } applicantSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-applicantSigningNonce } } cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 } 4. Each Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name MUST conform to the requirements of these Guidelines, including the content requirements in Section 9 and Appendix B of the Baseline Requirements, except that the CA MAY include a wildcard character in the Subject Alternative Name Extension and Subject Common Name Field as the left-most character in the .onion Domain Name provided inclusion of the wildcard character complies with Section 11.1.3 of the Baseline Requirements. 5. CAs MUST NOT issue a Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name with a validity period longer than 15 months. Despite Section 9.2.1 of the Baseline Requirements deprecating the use of Internal Names, a CA MAY issue a Certificate containing an .onion name with an expiration date later than 1 November 2015 after (and only if) .onion is officially recognized by the IESG as a reserved TLD. 6. On or before May 1, 2015, each CA MUST revoke all Certificates issued with the Subject Alternative Name extension or Common Name field that includes a Domain Name where .onion is in the right-most label of the Domain Name unless the Certificate was issued in compliance with this Appendix F. ---- Motion Ends ----- The review period for this ballot shall commence at 2200 UTC on Thursday, 4 February 2015, and will close at 2200 UTC on Thursday, 11 February 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on Monday, 18 February 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150217/e7d4415a/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5156 bytes Desc: not available Url : https://cabforum.org/pipermail/public/attachments/20150217/e7d4415a/attachment-0001.bin From dtokgoz at e-tugra.com.tr Wed Feb 18 02:10:27 2015 From: dtokgoz at e-tugra.com.tr (=?iso-8859-9?Q?Davut_Tokg=F6z?=) Date: Wed, 18 Feb 2015 11:10:27 +0200 Subject: [cabfpub] Ballots 143 and 144 In-Reply-To: <54DDC2A3.2000200@staff.aruba.it> References: <763539E260C37C46A0D6B340B5434C3B0ADAE0DE@AEX06.ejsarea.net> <54DDC2A3.2000200@staff.aruba.it> Message-ID: <019301d04b5a$bce15c10$36a41430$@e-tugra.com.tr> E-tugra votes yes for ballot 143 and abstains for ballot 144 Davut Tokg?z -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150218/3f9bdee9/attachment.html From Dean_Coclin at symantec.com Wed Feb 18 08:40:40 2015 From: Dean_Coclin at symantec.com (Dean Coclin) Date: Wed, 18 Feb 2015 07:40:40 -0800 Subject: [cabfpub] Voting Reminder Message-ID: <14D026C7F297AD44AC82578DD818CDD038EF1EAA5C@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> Reminder: Voting closes later today on ballots 143 and 144. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150218/198c5dfe/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6130 bytes Desc: not available Url : https://cabforum.org/pipermail/public/attachments/20150218/198c5dfe/attachment.bin From Mads.Henriksveen at buypass.no Wed Feb 18 08:40:50 2015 From: Mads.Henriksveen at buypass.no (Mads Egil Henriksveen) Date: Wed, 18 Feb 2015 15:40:50 +0000 Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group In-Reply-To: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> References: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> Message-ID: Buypass votes YES Regards Mads From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: 4. februar 2015 22:05 To: CABFPub Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group Ballot 143 - Formalization of validation working group ---- Reason ---- In order to address validation issues and inconsistencies in both the SSL Baseline Requirements and the EV Guidelines, the CAB Forum has held an informal working group previously referred to as the Extended Validation Working Group now known as the Validation Working Group, would like to modify its scope to include validation in the Baseline Requirements as well as the EV Guidelines. Jeremy Rowley of DigiCert made the following motion, which was endorsed by Rich Smith of Comodo and Kirk Hall of TrendMicro ---- Motion begins ---- The CA-Browser Forum formally establishes the Validation Working Group as an official working group of the CAB Forum, replacing the previous informal EV working group. The scope of this working group is to address issues arising under adopted CAB Forum standards related to the validation of certificate information and the inclusion of information in certificates. Scope: The Validation Working Group will consider all matters relating to the validation and inclusion of information in certificates under adopted CAB Forum guidelines. Deliverables: The Working Group shall produce one or more documents offering options to the Forum for validation within the scope defined above. ---- Motion Ends ---- The review period for this ballot shall commence at 2200 UTC on 5 Feb 2015, and will close at 2200 UTC on 11 Feb 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on 18 Feb 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150218/e6ee6cae/attachment-0001.html From Dean_Coclin at symantec.com Wed Feb 18 08:51:09 2015 From: Dean_Coclin at symantec.com (Dean Coclin) Date: Wed, 18 Feb 2015 07:51:09 -0800 Subject: [cabfpub] Agenda for CA/B Forum call February 18, 2015 Message-ID: <14D026C7F297AD44AC82578DD818CDD038EF1EAA6F@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> Antitrust Statement: As you know, this meeting includes companies that compete against one another. This meeting is intended to discuss technical standards related to the provision of existing and new types of digital certificates without restricting competition in developing and marketing such certificates. This meeting is not intended to share competitively-sensitive information among competitors, and therefore all participants agree not to discuss or exchange information related to: (a) Pricing policies, pricing formulas, prices or other terms of sale; (b) Costs, cost structures, profit margins, (c) Pending or planned service offerings, (d) Customers, business, or marketing plans; or (e) The allocation of customers, territories, or products in any way. Note: Please announce yourself when you dial in. This helps in documenting attendance when recording is played back later. Here is the proposed agenda: Time Start(UTC) Stop Slot Description Notes / Presenters (Thur) 19 Feb 2015 0:01 16:00 16:01 1 Read Antitrust Statement Dean 0:02 16:01 16:03 2 Roll Call Dean 0:01 16:03 16:04 3 Review Agenda Dean 0:01 16:04 16:05 4 Approve Minutes of 5 Feb 2015 Latest version distributed by Dean on Feb 15th 0:20 16:05 16:25 5 Results of Ballots 143 and 144. Use of Abstention vote. Dean 0:05 16:25 16:30 6 IPv6: additional updates? Ryan S. 0:10 16:30 16:40 7 New Ballots: Operational existence and domain validation Jeremy 0:10 16:40 16:45 8 Working Groups-public discussion? 0:05 16:45 16:50 9 EV Working Group Status Update Jeremy 0:02 16:50 16:52 10 Code Signing Working Group Status Update Dean/Jeremy -Public draft 0:02 16:52 16:54 11 Policy Review Working Group Status Update Proposed ballot status 0:02 16:54 16:56 12 *New* Information Sharing Working Group Update Ben 0:03 16:56 16:59 13 Any Other Business - Cupertino Meeting-March 10-12: 32 attendees signed up so far 0:00 17:00 17:00 14 Next phone call - March 5, 2015 Should we skip the next call since F2F is the week after? 0:00 17:00 17:00 15 Adjourn -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150218/25af765a/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6130 bytes Desc: not available Url : https://cabforum.org/pipermail/public/attachments/20150218/25af765a/attachment-0001.bin From erwann.abalea at opentrust.com Wed Feb 18 09:14:25 2015 From: erwann.abalea at opentrust.com (Erwann Abalea) Date: Wed, 18 Feb 2015 17:14:25 +0100 Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group In-Reply-To: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> References: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> Message-ID: <54E4BA61.2000100@opentrust.com> OpenTrust votes Yes. -- Erwann ABALEA Le 04/02/2015 22:05, Jeremy Rowley a ?crit : > > Ballot 143 - Formalization of validation working group > > ---- > > Reason > > ---- > > In order to address validation issues and inconsistencies in both the > SSL Baseline Requirements and the EV Guidelines, the CAB Forum has > held an informal working group previously referred to as the Extended > Validation Working Group now known as the Validation Working Group, > would like to modify its scope to include validation in the Baseline > Requirements as well as the EV Guidelines. > > Jeremy Rowley of DigiCert made the following motion, which was > endorsed by Rich Smith of Comodo and Kirk Hall of TrendMicro > > ---- > > Motion begins > > ---- > > The CA-Browser Forum formally establishes the Validation Working Group > as an official working group of the CAB Forum, replacing the previous > informal EV working group. The scope of this working group is to > address issues arising under adopted CAB Forum standards related to > the validation of certificate information and the inclusion of > information in certificates. > > Scope: The Validation Working Group will consider all matters relating > to the validation and inclusion of information in certificates under > adopted CAB Forum guidelines. > > Deliverables: The Working Group shall produce one or more documents > offering options to the Forum for validation within the scope defined > above. > > ---- > > Motion Ends > > ---- > > The review period for this ballot shall commence at 2200 UTC on 5 Feb > 2015, and will close at 2200 UTC on 11 Feb 2015. Unless the motion is > withdrawn during the review period, the voting period will start > immediately thereafter and will close at 2200 UTC on 18 Feb 2015. > Votes must be cast by posting an on-list reply to this thread. > > A vote in favor of the motion must indicate a clear 'yes' in the > response. A vote against must indicate a clear 'no' in the response. A > vote to abstain must indicate a clear 'abstain' in the response. > Unclear responses will not be counted. The latest vote received from > any representative of a voting member before the close of the voting > period will be counted. Voting members are listed here: > https://cabforum.org/members/ > > In order for the motion to be adopted, two thirds or more of the votes > cast by members in the CA category and greater than 50% of the votes > cast by members in the browser category must be in favor. Quorum is > currently nine (9) members? at least nine members must participate in > the ballot, either by voting in favor, voting against, or abstaining. > > > > _______________________________________________ > 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/20150218/0ce58859/attachment.html From JAmaral at trustwave.com Wed Feb 18 09:24:20 2015 From: JAmaral at trustwave.com (John Amaral) Date: Wed, 18 Feb 2015 16:24:20 +0000 Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group In-Reply-To: References: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> Message-ID: <99A44CD64687DD4EB6D44264DBED7525507C0DBD@SKYMB2.trustwave.com> Trustwave votes YES Regards, John John Amaral SVP, Product Management t: +1 781.419.6344 m: +1 978.760.0144 Trustwave | SMART SECURITY ON DEMAND www.trustwave.com Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group Ballot 143 - Formalization of validation working group ---- Reason ---- In order to address validation issues and inconsistencies in both the SSL Baseline Requirements and the EV Guidelines, the CAB Forum has held an informal working group previously referred to as the Extended Validation Working Group now known as the Validation Working Group, would like to modify its scope to include validation in the Baseline Requirements as well as the EV Guidelines. Jeremy Rowley of DigiCert made the following motion, which was endorsed by Rich Smith of Comodo and Kirk Hall of TrendMicro ---- Motion begins ---- The CA-Browser Forum formally establishes the Validation Working Group as an official working group of the CAB Forum, replacing the previous informal EV working group. The scope of this working group is to address issues arising under adopted CAB Forum standards related to the validation of certificate information and the inclusion of information in certificates. Scope: The Validation Working Group will consider all matters relating to the validation and inclusion of information in certificates under adopted CAB Forum guidelines. Deliverables: The Working Group shall produce one or more documents offering options to the Forum for validation within the scope defined above. ---- Motion Ends ---- The review period for this ballot shall commence at 2200 UTC on 5 Feb 2015, and will close at 2200 UTC on 11 Feb 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on 18 Feb 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. ________________________________ This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150218/c710f367/attachment.html From Mads.Henriksveen at buypass.no Wed Feb 18 09:35:00 2015 From: Mads.Henriksveen at buypass.no (Mads Egil Henriksveen) Date: Wed, 18 Feb 2015 16:35:00 +0000 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names In-Reply-To: References: Message-ID: <55329794072a4622ad3ef4c589d95f70@Buyp-gvk-ex01.intra.buypass.no> Buypass votes YES. Regards Mads From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: 10. februar 2015 19:39 To: public at cabforum.org Subject: [cabfpub] Ballot 144 - Validation rules for .onion names Here's the ballot with the two typos fixed: Applicants want a CA-signed .onion address for several reasons, including: - Powerful web platform features are restricted to secure origins, which are currently not available to onion names (in part, because of the lack of IANA registration). Permitting EV certs for onion names will help provide a secure origin for the service, moving onion towards use of powerful web platform features. - Currently, access to .onion names over https from a standard browser results in the standard existing 'Invalid Certificate' warning. Training users to click through security warnings lowers the value of these warnings and will cause users to miss important security information. Removing these warnings for the user, through use of a digital certificate, will help users recognize and avoid real MITM attacks. - The public needs attribution of ownership of the .onion address to differentiate onion services, including potential phishing services. Because onion names are not easily recognizable strings, providing the public with additional information about the operator has significant security improvements, especially in regions where use of the incorrect name could have lethal consequences. The following motion has been proposed by Jeremy Rowley of DigiCert and endorsed by Ryan Sleevi of Google and Wayne Thayer of GoDaddy. --------------------- Motion Starts --------------------- 1) Amend Section 9.2.1 of the Baseline Requirements v. 1.2.3 as follows: 9.2.1 Subject Alternative Name Extension Certificate Field: extensions:subjectAltName Required/Optional: Required Contents: This 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. The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate. Wildcard FQDNs are permitted. As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name, the CA SHALL notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016. Also as of the Effective Date, the CA SHALL NOT issue a certificate with an Expiry Date later than 1 November 2015 with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name. Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Name. Effective May 1, 2015, each CA SHALL revoke all unexpired Certificates with an Internal Name using onion as the right-most label in an entry in the subjectAltName Extension or commonName field unless such Certificate was issued in accordance with Appendix F of the EV Guidelines. 2) Amend Section 9.2.2 and 11.7.1 of the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2 as follows: 9.2.2. Subject Alternative Name Extension Certificate field: subjectAltName:dNSName Required/Optional: Required Contents: This extension MUST contain one or more host Domain Name(s) owned or controlled by the Subject and to be associated with the Subject's server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). Wildcard certificates are not allowed for EV Certificates except as permitted under Appendix F. 11.7 Verification of Applicant's Domain Name 11.7.1. Verification Requirements (1) For each Fully-Qualified Domain Name listed in a Certificate, other than a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant (or the Applicant's Parent Company, Subsidiary Company, or Affiliate, collectively referred to as "Applicant" for the purposes of this section) either is the Domain Name Registrant or has control over the FQDN using a procedure specified in Section 11.1.1 of the Baseline Requirements, except that a CA MAY NOT verify a domain using the procedure described 11.1.1(7). For a Certificate issued to a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant's control over the .onion Domain Name in accordance with Appendix F. (2) Mixed Character Set Domain Names: EV Certificates MAY include Domain Names containing mixed character sets only in compliance with the rules set forth by the domain registrar. The CA MUST visually compare any Domain Names with mixed character sets with known high risk domains. If a similarity is found, then the EV Certificate Request MUST be flagged as High Risk. The CA must perform reasonably appropriate additional authentication and verification to be certain beyond reasonable doubt that the Applicant and the target in question are the same organization. 3) Add a new Appendix F to the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2: Appendix F - Issuance of Certificates for .onion Domain Names A CA may issue an EV Certificate with .onion in the right-most label of the Domain Name provided that issuance complies with the requirements set forth in this Appendix: 1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) The CAB Forum has created an extension of the TBSCertificate for use in conveying hashes of keys related to .onion addresses. The Tor Service Descriptor Hash extension has the following format: cabf-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 } TorServiceDescriptorSyntax ::= SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash TorServiceDescriptorHash:: = SEQUENCE { onionURI UTF8String algorithm AlgorithmIdentifier subjectPublicKeyHash BIT STRING } Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 6234) performed over the DER-encoding of an ASN.1 SubjectPublicKey of the .onion service and SubjectPublicKeyHash is the hash output. 2. The CA MUST verify the Applicant's control over the .onion Domain Name using one of the following: a. The CA MAY verify the Applicant's control over the .onion service by posting a specific value at a well-known URL under RFC5785. b. The CA MAY verify the Applicant's control over the .onion service by having the Applicant provide a Certificate Request signed using the .onion public key if the Attributes section of the certificationRequestInfo contains: (i) A caSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy, 2) is generated by the CA, and 3) delivered to the Applicant through a Verified Method of Communication and (ii) An applicantSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy and 2) is generated by the Applicant. The signing nonce attributes have the following format: caSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-caSigningNonce } } cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } applicantSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-applicantSigningNonce } } cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 } 4. Each Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name MUST conform to the requirements of these Guidelines, including the content requirements in Section 9 and Appendix B of the Baseline Requirements, except that the CA MAY include a wildcard character in the Subject Alternative Name Extension and Subject Common Name Field as the left-most character in the .onion Domain Name provided inclusion of the wildcard character complies with Section 11.1.3 of the Baseline Requirements. 5. CAs MUST NOT issue a Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name with a validity period longer than 15 months. Despite Section 9.2.1 of the Baseline Requirements deprecating the use of Internal Names, a CA MAY issue a Certificate containing an .onion name with an expiration date later than 1 November 2015 after (and only if) .onion is officially recognized by the IESG as a reserved TLD. 6. On or before May 1, 2015, each CA MUST revoke all Certificates issued with the Subject Alternative Name extension or Common Name field that includes a Domain Name where .onion is in the right-most label of the Domain Name unless the Certificate was issued in compliance with this Appendix F. ---- Motion Ends ----- The review period for this ballot shall commence at 2200 UTC on Thursday, 4 February 2015, and will close at 2200 UTC on Thursday, 11 February 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on Monday, 18 February 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150218/eee41a1d/attachment-0001.html From erwann.abalea at opentrust.com Wed Feb 18 12:07:44 2015 From: erwann.abalea at opentrust.com (Erwann Abalea) Date: Wed, 18 Feb 2015 20:07:44 +0100 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names In-Reply-To: References: Message-ID: <54E4E300.3050303@opentrust.com> OpenTrust votes NO. I've got nothing against Tor, I use it and operate a relay node, and I appreciate its value. However: * there's no constraint on service descriptor key sizes, and right now the keys are 1024bits RSA by default. The service descriptor key is what gives the hidden service its name (facebookcorewwwi.onion, for example), so it can't be changed without changing the hidden service name, and the service descriptor key size can't easily be changed (it's a manual and undocumented process, and I'm not sure a larger key will be accepted by Tor clients). The vast majority of onion keys are also RSA1024 ones. For example, the service descriptor key for the "facebookcorewwwi" service is also a 1024bits one. Whoever gets the private key can impersonate the hidden service. CABForum members must not certify public keys smaller than 2048 bits since 2013-12-31, let's not reintroduce them now. * the hidden service name that will be certified is generated using a truncated SHA1. Cryptographically, that's not a security problem so far because it uses the second preimage resistance of SHA1, and SHA1 has no real weakness regarding second preimage. It's a 2^80 work effort for an attacker to generate a key having the same hidden service name as an existing one. CABForum members have already agreed to avoid SHA1, with a deprecation plan, even for intermediate CA certificates, where we also rely on the second preimage resistance property of the hash function (with a 2^160 effort for an attacker because it's not truncated). Let's be consistent and avoid SHA1 all along. * the final goal of this ballot is to allow a Tor user to access a non hidden service using a hidden service name. Such a user can *already* access to the public facing classical version of this service, using its public name. A Tor user can already access https://www.whatever.com with its browser and the browser will be happy and get the green bar if the certificate is an EV one. I may fail to see the expected benefit, but that's it, I don't see it. -- Erwann ABALEA Le 10/02/2015 19:38, Jeremy Rowley a ?crit : > > *Here?s the ballot with the two typos fixed:* > > Applicants want a CA-signed .onion address for several reasons, including: > > - Powerful web platform features are restricted to secure origins, > which are currently not available to onion names (in part, because of > the lack of IANA registration). Permitting EV certs for onion names > will help provide a secure origin for the service, moving onion > towards use of powerful web platform features. > > - Currently, access to .onion names over https from a standard browser > results in the standard existing 'Invalid Certificate' warning. > Training users to click through security warnings lowers the value of > these warnings and will cause users to miss important security > information. Removing these warnings for the user, through use of a > digital certificate, will help users recognize and avoid real MITM > attacks. > > - The public needs attribution of ownership of the .onion address to > differentiate onion services, including potential phishing services. > Because onion names are not easily recognizable strings, providing the > public with additional information about the operator has significant > security improvements, especially in regions where use of the > incorrect name could have lethal consequences. > > The following motion has been proposed by Jeremy Rowley of DigiCert > and endorsed by Ryan Sleevi of Google and Wayne Thayer of GoDaddy. > > --------------------- > > Motion Starts > > --------------------- > > 1) Amend Section 9.2.1 of the Baseline Requirements v. 1.2.3 as follows: > > 9.2.1 Subject Alternative Name Extension > > Certificate Field: extensions:subjectAltName > > Required/Optional: Required > > Contents: This 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. The CA MUST > confirm that the Applicant controls the Fully-Qualified Domain Name or > IP address or has been granted the right to use it by the Domain Name > Registrant or IP address assignee, as appropriate. > > Wildcard FQDNs are permitted. As of the Effective Date of these > Requirements, prior to the issuance of a Certificate with a > subjectAlternativeName extension or Subject commonName field > containing a Reserved IP Address or Internal Name, the CA SHALL notify > the Applicant that the use of such Certificates has been deprecated by > the CA / Browser Forum and that the practice will be eliminated by > October 2016. Also as of the Effective Date, the CA SHALL NOT issue a > certificate with an Expiry Date later than 1 November 2015 with a > subjectAlternativeName extension or Subject commonName field > containing a Reserved IP Address or Internal Name. Effective 1 October > 2016, CAs SHALL revoke all unexpired Certificates whose > subjectAlternativeName extension or Subject commonName field contains > a Reserved IP Address or Internal Name. _Effective May 1, 2015, each > CA SHALL revoke all unexpired Certificates with an Internal Name using > onion as the right-most label in an entry in the subjectAltName > Extension or commonName field unless such Certificate was issued in > accordance with Appendix F of the EV Guidelines._ > > 2) Amend Section 9.2.2 and 11.7.1 of the Guidelines for the Issuance > and Management of Extended Validation Certificates v1.5.2 as follows: > > 9.2.2. Subject Alternative Name Extension Certificate field: > subjectAltName:dNSName > > Required/Optional: Required > > Contents: This extension MUST contain one or more host Domain Name(s) > owned or controlled by the Subject and to be associated with the > Subject?s server. Such server MAY be owned and operated by the Subject > or another entity (e.g., a hosting service). Wildcard certificates are > not allowed for EV Certificates_except as permitted under Appendix F_. > > 11.7 Verification of Applicant?s Domain Name > > 11.7.1. Verification Requirements > > (1) For each Fully-Qualified Domain Name listed in a Certificate, > other than a Domain Name with .onion in the right-most label of the > Domain Name, the CA SHALL confirm that, as of the date the Certificate > was issued, the Applicant (or the Applicant?s Parent Company, > Subsidiary Company, or Affiliate, collectively referred to as > ?Applicant? for the purposes of this section) either is the Domain > Name Registrant or has control over the FQDN using a procedure > specified in Section 11.1.1 of the Baseline Requirements, except that > a CA MAY NOT verify a domain using the procedure described 11.1.1(7). > _For a Certificate issued to a Domain Name with .onion in the > right-most label of the Domain Name, the CA SHALL confirm that, as of > the date the Certificate was issued, the Applicant?s control over the > .onion Domain Name in accordance with Appendix F._ > > (2) Mixed Character Set Domain Names: EV Certificates MAY include > Domain Names containing mixed character sets only in compliance with > the rules set forth by the domain registrar. The CA MUST visually > compare any Domain Names with mixed character sets with known high > risk domains. If a similarity is found, then the EV Certificate > Request MUST be flagged as High Risk. The CA must perform reasonably > appropriate additional authentication and verification to be certain > beyond reasonable doubt that the Applicant and the target in question > are the same organization. > > 3) Add a new Appendix F to the Guidelines for the Issuance and > Management of Extended Validation Certificates v1.5.2: > > Appendix F ? Issuance of Certificates for .onion Domain Names > > A CA may issue an EV Certificate with .onion in the right-most label > of the Domain Name provided that issuance complies with the > requirements set forth in this Appendix: > > 1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) > > The CAB Forum has created an extension of the TBSCertificate for use > in conveying hashes of keys related to .onion addresses. The Tor > Service Descriptor Hash extension has the following format: > > cabf-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 } > > TorServiceDescriptorSyntax ::= > > SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash > > TorServiceDescriptorHash:: = SEQUENCE { > > onionURI UTF8String > > algorithm AlgorithmIdentifier > > subjectPublicKeyHash BIT STRING } > > Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC > 6234) performed over the DER-encoding of an ASN.1 SubjectPublicKey of > the .onion service and SubjectPublicKeyHash is the hash output. > > 2. The CA MUST verify the Applicant?s control over the .onion Domain > Name using one of the following: > > a. The CA MAY verify the Applicant?s control over the .onion service > by posting a specific value at a well-known URL under RFC5785. > > b. The CA MAY verify the Applicant?s control over the .onion service > by having the Applicant provide a Certificate Request signed using the > .onion public key if the Attributes section of the > certificationRequestInfo contains: > > (i) A caSigningNonce attribute that 1) contains a single value with at > least 64-bits of entropy, 2) is generated by the CA, and 3) delivered > to the Applicant through a Verified Method of Communication and > > (ii) An applicantSigningNonce attribute that 1) contains a single > value with at least 64-bits of entropy and 2) is generated by the > Applicant. > > The signing nonce attributes have the following format: > > caSigningNonce ATTRIBUTE ::= { > > WITH SYNTAX OCTET STRING > > EQUALITY MATCHING RULE octetStringMatch > > SINGLE VALUE TRUE > > ID { cabf-caSigningNonce } > > } > > cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } > > applicantSigningNonce ATTRIBUTE ::= { > > WITH SYNTAX OCTET STRING > > EQUALITY MATCHING RULE octetStringMatch > > SINGLE VALUE TRUE > > ID { cabf-applicantSigningNonce } > > } > > cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 } > > 4. Each Certificate that includes a Domain Name where .onion is in the > right-most label of the Domain Name MUST conform to the requirements > of these Guidelines, including the content requirements in Section 9 > and Appendix B of the Baseline Requirements, except that the CA MAY > include a wildcard character in the Subject Alternative Name Extension > and Subject Common Name Field as the left-most character in the .onion > Domain Name provided inclusion of the wildcard character complies with > Section 11.1.3 of the Baseline Requirements. > > 5. CAs MUST NOT issue a Certificate that includes a Domain Name where > .onion is in the right-most label of the Domain Name with a validity > period longer than 15 months. Despite Section 9.2.1 of the Baseline > Requirements deprecating the use of Internal Names, a CA MAY issue a > Certificate containing an .onion name with an expiration date later > than 1 November 2015 after (and only if) .onion is officially > recognized by the IESG as a reserved TLD. > > 6. On or before May 1, 2015, each CA MUST revoke all Certificates > issued with the Subject Alternative Name extension or Common Name > field that includes a Domain Name where .onion is in the right-most > label of the Domain Name unless the Certificate was issued in > compliance with this Appendix F. > > ---- > > Motion Ends > > ----- > > The review period for this ballot shall commence at 2200 UTC on > Thursday, 4 February 2015, and will close at 2200 UTC on Thursday, 11 > February 2015. Unless the motion is withdrawn during the review > period, the voting period will start immediately thereafter and will > close at 2200 UTC on Monday, 18 February 2015. Votes must be cast by > posting an on-list reply to this thread. > > A vote in favor of the motion must indicate a clear 'yes' in the > response. A vote against must indicate a clear 'no' in the response. A > vote to abstain must indicate a clear 'abstain' in the response. > Unclear responses will not be counted. The latest vote received from > any representative of a voting member before the close of the voting > period will be counted. Voting members are listed here: > https://cabforum.org/members/ > > In order for the motion to be adopted, two thirds or more of the votes > cast by members in the CA category and greater than 50% of the votes > cast by members in the browser category must be in favor. Quorum is > currently nine (9) members? at least nine members must participate in > the ballot, either by voting in favor, voting against, or abstaining. > > > > _______________________________________________ > 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/20150218/edbf5903/attachment-0001.html From sleevi at google.com Wed Feb 18 15:00:41 2015 From: sleevi at google.com (Ryan Sleevi) Date: Wed, 18 Feb 2015 14:00:41 -0800 Subject: [cabfpub] Preballot for IPv6 Support In-Reply-To: References: Message-ID: In advance of tomorrow's call, I'd like to bring forward this pre-ballot again ---MOTION BEGINS--- Update Section 13.2.1 of the Baseline Requirements as follows: From: "The CA SHALL make revocation information for Subordinate Certificates and Subscriber Certificates available in accordance with Appendix B." To: "The CA SHALL make revocation information for Subordinate Certificates and Subscriber Certificates available in accordance with Appendix B. Effective March 1, 2016, the CA SHALL make this information available via both IPv4 and IPv6. For each DNS host included in accordance with Appendix B, lookups to the authoritative resolver MUST return valid A records if A records are requested and valid AAAA records if AAAA records are requested." Update Appendix B, Section 2(b) of the Baseline Requirements as follows: From: "This extension MUST be present and MUST NOT be marked critical. It MUST contain the HTTP URL of the CA?s CRL service." To: "This extension MUST be present and MUST NOT be marked critical. It MUST contain the HTTP URL of the CA?s CRL service. See Section 13.2.1 for details." ---MOTION ENDS--- The key changes from the previous pre-ballot are the wording changes suggested by Brian Smith, and attaching a concrete date - 1 year from now. From gerv at mozilla.org Thu Feb 19 03:11:59 2015 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 19 Feb 2015 10:11:59 +0000 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names In-Reply-To: <54E4E300.3050303@opentrust.com> References: <54E4E300.3050303@opentrust.com> Message-ID: <54E5B6EF.3000009@mozilla.org> Hi Erwann, On 18/02/15 19:07, Erwann Abalea wrote: > OpenTrust votes NO. >From reading your objections: does this mean you would be in favour after the Tor folk move to longer hashes and SHA-256? > * the final goal of this ballot is to allow a Tor user to access a non > hidden service using a hidden service name. Such a user can > *already* access to the public facing classical version of this > service, using its public name. Yes; however, people in the middle can both tell that the user is accessing the site, and can block their access. Gerv From Dean_Coclin at symantec.com Thu Feb 19 08:39:36 2015 From: Dean_Coclin at symantec.com (Dean Coclin) Date: Thu, 19 Feb 2015 07:39:36 -0800 Subject: [cabfpub] Ballot 143, 144 results Message-ID: <14D026C7F297AD44AC82578DD818CDD038EF343757@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> On Ballot 143, Formation of Validation Working Group, I counted 22 Yes votes, 0 No votes , 0 Abstentions from the CAs and 4 Yes votes from the browsers. Therefore, the ballot passes. On Ballot 144, Issuance to .Onion domains, I counted 6 Yes votes, 2 No votes and 13 Abstentions from the CAs and 3 Yes votes from the browsers. Therefore, the ballot passes. Detailed results are on the wiki ballot tracker. The Chair directs that the name of the working group be updated to the Validation Working Group and requests that Ben Wilson update the wiki and website to reflect this. The group's new charter should reflect the ballot results. Further, I ask that Jeremy update the EV Guidelines to adjust for Ballot 144 as appropriate (per the ballot). Thank you, Dean Coclin -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150219/c9b3d963/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6130 bytes Desc: not available Url : https://cabforum.org/pipermail/public/attachments/20150219/c9b3d963/attachment.bin From jeremy.rowley at digicert.com Thu Feb 19 08:43:43 2015 From: jeremy.rowley at digicert.com (Jeremy Rowley) Date: Thu, 19 Feb 2015 15:43:43 +0000 Subject: [cabfpub] Ballot 145 - Operational Existence for Government Entities Message-ID: Ballot 145 - Operational Existence for Government Entities ________________________________ Reason ________________________________ Because government entities aren't operating as businesses, they are often not listed with a QIIS, especially immediately after the entity is created by either statute or order. The legal existence of these entities is verifiable through a QGIS, but this source in many countries (especially Arabic and African countries) does not always list a date of creation of these entities. Operational existence exists to ensure organizations aren't fly-by-night scams/phishing entities. With government entities, these same risks are not present as they are created directly by government action. Jeremy Rowley of DigiCert made the following motion, which was endorsed by Rich Smith of Comodo and Cecilia Kam of Symantec. ________________________________ Motion begins ________________________________ Effective immediately, section 11.6.1 is modified as follows: 11.6.1 Verification Requirements. The CA MUST verify that the Applicant has the ability to engage in business by verifying the Applicant's, or Affiliate/Parent/Subsidiary Company's, operational existence. The CA MAY rely on its verification of a Government Entity's legal existence under Section 11.2 as verification of a Government Entity's operational existence. ________________________________ Motion Ends ________________________________ The review period for this ballot shall commence at 2200 UTC on 19 Feb 2015, and will close at 2200 UTC on 26 Feb 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on 5 Mar 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150219/d388a3e9/attachment-0001.html From wthayer at godaddy.com Thu Feb 19 09:54:28 2015 From: wthayer at godaddy.com (Wayne Thayer) Date: Thu, 19 Feb 2015 16:54:28 +0000 Subject: [cabfpub] Preballot for IPv6 Support In-Reply-To: References: Message-ID: Ryan, We didn't find any blockers that prevent GoDaddy from enabling support for IPv6. Like other CAs, we also don't see any demand for it today, but I agree that this is a collective action problem and CAs need to remove certificate validation from the list of problems that are blocking other parties from moving to IPv6. GoDaddy supports this ballot and I would be happy to endorse. Thanks, Wayne -----Original Message----- From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ryan Sleevi Sent: Wednesday, February 18, 2015 3:01 PM To: CABFPub Subject: Re: [cabfpub] Preballot for IPv6 Support In advance of tomorrow's call, I'd like to bring forward this pre-ballot again ---MOTION BEGINS--- Update Section 13.2.1 of the Baseline Requirements as follows: From: "The CA SHALL make revocation information for Subordinate Certificates and Subscriber Certificates available in accordance with Appendix B." To: "The CA SHALL make revocation information for Subordinate Certificates and Subscriber Certificates available in accordance with Appendix B. Effective March 1, 2016, the CA SHALL make this information available via both IPv4 and IPv6. For each DNS host included in accordance with Appendix B, lookups to the authoritative resolver MUST return valid A records if A records are requested and valid AAAA records if AAAA records are requested." Update Appendix B, Section 2(b) of the Baseline Requirements as follows: From: "This extension MUST be present and MUST NOT be marked critical. It MUST contain the HTTP URL of the CA?s CRL service." To: "This extension MUST be present and MUST NOT be marked critical. It MUST contain the HTTP URL of the CA?s CRL service. See Section 13.2.1 for details." ---MOTION ENDS--- The key changes from the previous pre-ballot are the wording changes suggested by Brian Smith, and attaching a concrete date - 1 year from now. _______________________________________________ Public mailing list Public at cabforum.org https://cabforum.org/mailman/listinfo/public From kirk_hall at trendmicro.com Thu Feb 19 09:59:51 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Thu, 19 Feb 2015 16:59:51 +0000 Subject: [cabfpub] When did the WebTrust/ETSI BR audit requirement become mandatory? Message-ID: On our Forum call today, we asked when a WebTrust/ETSI BR audit requirement become mandatory for CAs. Ballot 62 (Nov. 2011) adopted the BRs effective July 1, 2012. However, there were no audit criteria in place for some time. I did some quick research, and the answer is not clear as to when the audit criteria came into effect. The WebTrust draft audit requirements were completed by early 2013, and I see comments that Mozilla adopted the BR audit as a program requirement at the Mountain View meeting in Feb. 2013. Here is the current Mozilla requirement at Sec. 11: https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ As I recall, the initial Mozilla BR audit requirement was not clear as to exact effective date (what operational period must be covered by a CA's initial BR audit). I vaguely recall Mozilla clarifying the rule at our Feb. 2013 meeting at Mountain View that all CA operations occurring on or after Feb. 15, 2013 must be covered by a BR audit - so some CAs did partial-year initial BR audits to align their BR audits with their other audits. Based on all this, I would say all CAs should have full year BR audits in place by now. We can change our Bylaw on membership at Bylaw 2.1 to reflect this. Kirk R. Hall Operations Director, Trust Services Trend Micro +1.503.753.3088 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
-------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150219/1f6a9bb0/attachment.html From gerv at mozilla.org Thu Feb 19 10:33:27 2015 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 19 Feb 2015 17:33:27 +0000 Subject: [cabfpub] When did the WebTrust/ETSI BR audit requirement become mandatory? In-Reply-To: References: Message-ID: <54E61E67.6090409@mozilla.org> On 19/02/15 16:59, kirk_hall at trendmicro.com wrote: > Based on all this, I would say all CAs should have full year BR audits > in place by now. We can change our Bylaw on membership at Bylaw 2.1 to > reflect this. I agree with the former, but let me challenge for a moment whether it directly implies the goodness of the latter. Why do we have membership criteria at all? I would say that it's solely to prevent people or organizations signing up as members who are not actually doing things the forum concerns itself with. Therefore, our membership criteria should be as wide as possible consistent with that goal. We currently require a WebTrust or ETSI scheme audit. I think it's unlikely that an organization will seek and pay for such a thing unless they are actually a CA. So I would say our membership criteria are already rigorous enough. To put it another way: Mozilla's root program requirements are not the same thing as CAB Forum membership criteria. I suspect that a new CA won't get very far in practice without a BR audit, but the CAB Forum should not be judging the business model viability of potential members as a condition of membership. That seems a dangerous road to me. Gerv From kirk_hall at trendmicro.com Thu Feb 19 11:28:44 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Thu, 19 Feb 2015 18:28:44 +0000 Subject: [cabfpub] When did the WebTrust/ETSI BR audit requirement become mandatory? In-Reply-To: <54E61E67.6090409@mozilla.org> References: <54E61E67.6090409@mozilla.org> Message-ID: I partially agree, but I would put it this way: CA membership requirements are intended to make sure an applicant is a "real" CA. Today, both Mozilla and Microsoft require a CA to have a Baseline Requirements audit for its roots to be included in the trusted root store. Here is the Microsoft link: http://social.technet.microsoft.com/wiki/contents/articles/26675.windows-root-certificate-program-audit-requirements-for-cas.aspx Plus, the CA-Browser Forum itself requires all CAs to follow the BRs for their certs to be considered trustworthy (except that the Forum has no enforcement power ? that is left to the browsers through their root program requirements): These Baseline Requirements describe an integrated set of technologies, protocols, identity-proofing, lifecycle management, and auditing requirements that are necessary (but not sufficient) for the issuance and management of Publicly-Trusted Certificates; Certificates that are trusted by virtue of the fact that their corresponding Root Certificate is distributed in widely-available application software. The Requirements are not mandatory for Certification Authorities unless and until they become adopted and enforced by relying?party Application Software Suppliers. *** 1. Scope The Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates describe a subset of the requirements that a Certification Authority must meet in order to issue Publicly Trusted Certificates. Except where explicitly stated otherwise, these requirements apply only to relevant events that occur on or after the Effective Date. *** These Requirements are applicable to all Certification Authorities within a chain of trust. They are to be flowed down from the Root Certification Authority through successive Subordinate Certification Authorities. 2. Purpose The primary goal of these Requirements is to enable efficient and secure electronic communication, while addressing user concerns about the trustworthiness of Certificates. The Requirements also serve to inform users and help them to make informed decisions when relying on Certificates. No CA is required to join the Forum to operate ? the CAs only need to satisfy the browsers. But I can?t think of any reason why a CA would choose NOT to follow the BRs and get a BR audit if it wants to be considered a ?real? CA. And I don?t think the Forum would want to accept any new CA member that said ?I choose not to follow the BRs, and I choose not to get a BR audit? ? why would we want such a CA as a member? So it seems reasonable to update our bylaws to require a BR audit for membership. -----Original Message----- From: Gervase Markham [mailto:gerv at mozilla.org] Sent: Thursday, February 19, 2015 9:33 AM To: Kirk Hall (RD-US); CABFPub (public at cabforum.org) Subject: Re: [cabfpub] When did the WebTrust/ETSI BR audit requirement become mandatory? On 19/02/15 16:59, kirk_hall at trendmicro.com wrote: > Based on all this, I would say all CAs should have full year BR audits > in place by now. We can change our Bylaw on membership at Bylaw 2.1 > to reflect this. I agree with the former, but let me challenge for a moment whether it directly implies the goodness of the latter. Why do we have membership criteria at all? I would say that it's solely to prevent people or organizations signing up as members who are not actually doing things the forum concerns itself with. Therefore, our membership criteria should be as wide as possible consistent with that goal. We currently require a WebTrust or ETSI scheme audit. I think it's unlikely that an organization will seek and pay for such a thing unless they are actually a CA. So I would say our membership criteria are already rigorous enough. To put it another way: Mozilla's root program requirements are not the same thing as CAB Forum membership criteria. I suspect that a new CA won't get very far in practice without a BR audit, but the CAB Forum should not be judging the business model viability of potential members as a condition of membership. That seems a dangerous road to me. Gerv 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
-------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150219/9c91b2d0/attachment-0001.html From erwann.abalea at opentrust.com Thu Feb 19 11:44:47 2015 From: erwann.abalea at opentrust.com (Erwann Abalea) Date: Thu, 19 Feb 2015 19:44:47 +0100 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names In-Reply-To: <54E5B6EF.3000009@mozilla.org> References: <54E4E300.3050303@opentrust.com> <54E5B6EF.3000009@mozilla.org> Message-ID: <54E62F1F.9000109@opentrust.com> Bonjour Gerv, Le 19/02/2015 11:11, Gervase Markham a ?crit : > Hi Erwann, > > On 18/02/15 19:07, Erwann Abalea wrote: >> OpenTrust votes NO. > From reading your objections: does this mean you would be in favour > after the Tor folk move to longer hashes and SHA-256? Longer hashes may not be necessary, we lived with a 2^80 theoretical effort (collision resistance of a perfect hash function) for a while, and recently deprecated SHA1. But what was really deprecated? SHA1 in itself because it's old, despite its 2^160 resistance for intermediate certificates and CRLs? The idea of a 2^80 collision resistance? The latest estimated 2^61 collision resistance of SHA1? There was a reason to deprecate SHA1, there are consequences (we all heard of them and decided to drop legacy software, for good), there's a design behind our choices (or there should be). How does this truncated SHA1 fit this design? The other technical objection is that Tor is *full* of keys, and the vast majority of them are 1024 bits RSA keys. Some keys are ECC Curve25519 ones, but I don't know if they're used for signature or key exchange purpose. There are keys used to generate names, keys used to encrypt data exchanged between cells, keys used to sign distributed data, keys used to sign descriptor informations published by services, keys used to setup rendez-vous tokens to access hidden services, and maybe others. Keys smaller than 2048 bits are Evil(tm). It's written in stone, we track public 1024bits certificates and sue the CAs who produced them, we don't like DNSSEC partly because it's also full of 1024 bits keys. That's good, I'm fine with it. I'm not opposed to embrace Tor or any other similar security thing in CABForum's definition of a TLS certificate, but I'd like to be sure that we all know what is being introduced, the security consequences and guarantees of what we're doing. I really like Tor. But understanding Tor is hard, and I wouldn't be surprised if a non negligible number of the "abstain" votes was caused by this complexity. >> * the final goal of this ballot is to allow a Tor user to access a non >> hidden service using a hidden service name. Such a user can >> *already* access to the public facing classical version of this >> service, using its public name. > Yes; however, people in the middle can both tell that the user is > accessing the site, and can block their access. Tor is supposedly targeted for this situation. The exit node knows that someone wants to access the site and block it, the entry node knows that this specific user wants to access something and block it, but not both. In theory. From my understanding, accessing a Tor hidden service involves a longer path (3 nodes between the user and a rendezvous point, 3 nodes from this rendezvous point and the service), provides end-to-end encryption, and self-authentication. That's good. Does it solve the anonymity problem? Yes, for a hidden service. How does it work for a mixed hidden/non-hidden service? -- Erwann ABALEA From philliph at comodo.com Thu Feb 19 11:53:26 2015 From: philliph at comodo.com (Phillip Hallam-Baker) Date: Thu, 19 Feb 2015 13:53:26 -0500 Subject: [cabfpub] Lenovo installation of malicious root. Message-ID: <9CB5BBD9-58FA-4DC2-90E0-70F01911A4AC@comodo.com> I am sure many of you have seen this. If not you will, I have had a dozen people ping me about it in the past hour. https://www.eff.org/deeplinks/2015/02/further-evidence-lenovo-breaking-https-security-its-laptops Someone has to draw the line here or the politicians will do it for us. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150219/763d5df4/attachment.html From Rick_Andrews at symantec.com Thu Feb 19 12:25:46 2015 From: Rick_Andrews at symantec.com (Rick Andrews) Date: Thu, 19 Feb 2015 11:25:46 -0800 Subject: [cabfpub] Preballot for IPv6 Support In-Reply-To: References: Message-ID: <544B0DD62A64C1448B2DA253C01141460BD3E573A0@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> Ryan, It seems to me we need to add one more detail: it must be possible to make the lookups to the authoritative resolver (DNS) over IPv4 and IPv6. A client running on an IPv6-only network will first make a DNS call to get the AAAA record for the CA's OCSP or CRL service. So the CA needs to make sure that those DNS lookups can be served via IPv6. -Rick -----Original Message----- From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Wayne Thayer Sent: Thursday, February 19, 2015 8:54 AM To: CABFPub Subject: Re: [cabfpub] Preballot for IPv6 Support Ryan, We didn't find any blockers that prevent GoDaddy from enabling support for IPv6. Like other CAs, we also don't see any demand for it today, but I agree that this is a collective action problem and CAs need to remove certificate validation from the list of problems that are blocking other parties from moving to IPv6. GoDaddy supports this ballot and I would be happy to endorse. Thanks, Wayne -----Original Message----- From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ryan Sleevi Sent: Wednesday, February 18, 2015 3:01 PM To: CABFPub Subject: Re: [cabfpub] Preballot for IPv6 Support In advance of tomorrow's call, I'd like to bring forward this pre-ballot again ---MOTION BEGINS--- Update Section 13.2.1 of the Baseline Requirements as follows: From: "The CA SHALL make revocation information for Subordinate Certificates and Subscriber Certificates available in accordance with Appendix B." To: "The CA SHALL make revocation information for Subordinate Certificates and Subscriber Certificates available in accordance with Appendix B. Effective March 1, 2016, the CA SHALL make this information available via both IPv4 and IPv6. For each DNS host included in accordance with Appendix B, lookups to the authoritative resolver MUST return valid A records if A records are requested and valid AAAA records if AAAA records are requested." Update Appendix B, Section 2(b) of the Baseline Requirements as follows: From: "This extension MUST be present and MUST NOT be marked critical. It MUST contain the HTTP URL of the CA?s CRL service." To: "This extension MUST be present and MUST NOT be marked critical. It MUST contain the HTTP URL of the CA?s CRL service. See Section 13.2.1 for details." ---MOTION ENDS--- The key changes from the previous pre-ballot are the wording changes suggested by Brian Smith, and attaching a concrete date - 1 year from now. _______________________________________________ Public mailing list Public at cabforum.org https://cabforum.org/mailman/listinfo/public _______________________________________________ Public mailing list Public at cabforum.org https://cabforum.org/mailman/listinfo/public From sleevi at google.com Thu Feb 19 13:11:27 2015 From: sleevi at google.com (Ryan Sleevi) Date: Thu, 19 Feb 2015 12:11:27 -0800 Subject: [cabfpub] Preballot for IPv6 Support In-Reply-To: <544B0DD62A64C1448B2DA253C01141460BD3E573A0@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> References: <544B0DD62A64C1448B2DA253C01141460BD3E573A0@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> Message-ID: Good point. What good is server a AAAA record from a DNS server that doesn't listen on IPv6 On Thu, Feb 19, 2015 at 11:25 AM, Rick Andrews wrote: > Ryan, > > It seems to me we need to add one more detail: it must be possible to make the lookups to the authoritative resolver (DNS) over IPv4 and IPv6. A client running on an IPv6-only network will first make a DNS call to get the AAAA record for the CA's OCSP or CRL service. So the CA needs to make sure that those DNS lookups can be served via IPv6. > > -Rick > > -----Original Message----- > From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Wayne Thayer > Sent: Thursday, February 19, 2015 8:54 AM > To: CABFPub > Subject: Re: [cabfpub] Preballot for IPv6 Support > > Ryan, > > We didn't find any blockers that prevent GoDaddy from enabling support for IPv6. Like other CAs, we also don't see any demand for it today, but I agree that this is a collective action problem and CAs need to remove certificate validation from the list of problems that are blocking other parties from moving to IPv6. GoDaddy supports this ballot and I would be happy to endorse. > > Thanks, > > Wayne > > -----Original Message----- > From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ryan Sleevi > Sent: Wednesday, February 18, 2015 3:01 PM > To: CABFPub > Subject: Re: [cabfpub] Preballot for IPv6 Support > > In advance of tomorrow's call, I'd like to bring forward this pre-ballot again > > ---MOTION BEGINS--- > > Update Section 13.2.1 of the Baseline Requirements as follows: > > From: > "The CA SHALL make revocation information for Subordinate Certificates and Subscriber Certificates available in accordance with Appendix B." > > To: > > "The CA SHALL make revocation information for Subordinate Certificates and Subscriber Certificates available in accordance with Appendix B. > > Effective March 1, 2016, the CA SHALL make this information available via both IPv4 and IPv6. For each DNS host included in accordance with Appendix B, lookups to the authoritative resolver MUST return valid A records if A records are requested and valid AAAA records if AAAA records are requested." > > Update Appendix B, Section 2(b) of the Baseline Requirements as follows: > > From: > "This extension MUST be present and MUST NOT be marked critical. It MUST contain the HTTP URL of the CA?s CRL service." > > To: > "This extension MUST be present and MUST NOT be marked critical. It MUST contain the HTTP URL of the CA?s CRL service. See Section 13.2.1 for details." > > ---MOTION ENDS--- > > The key changes from the previous pre-ballot are the wording changes suggested by Brian Smith, and attaching a concrete date - 1 year from now. > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public From geoffk at apple.com Thu Feb 19 13:50:56 2015 From: geoffk at apple.com (Geoff Keating) Date: Thu, 19 Feb 2015 12:50:56 -0800 Subject: [cabfpub] Preballot for IPv6 Support In-Reply-To: References: <544B0DD62A64C1448B2DA253C01141460BD3E573A0@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> Message-ID: <6F77FE02-17AB-48F7-BFFB-59634699FA28@apple.com> > On 19 Feb 2015, at 12:11 pm, Ryan Sleevi wrote: > > Good point. What good is server a AAAA record from a DNS server that > doesn't listen on IPv6 An IPv6-only client can use a recursive DNS server which has both IPv6 and IPv4 addresses, for example Google Public DNS or Comcast's DNS servers, so this isn't as high a priority as OCSP (but still an important step). -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4103 bytes Desc: not available Url : https://cabforum.org/pipermail/public/attachments/20150219/3c4e24e0/attachment.bin From philliph at comodo.com Thu Feb 19 16:41:07 2015 From: philliph at comodo.com (Phillip Hallam-Baker) Date: Thu, 19 Feb 2015 18:41:07 -0500 Subject: [cabfpub] Preballot for IPv6 Support In-Reply-To: References: <544B0DD62A64C1448B2DA253C01141460BD3E573A0@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> Message-ID: <17B2AFA3-EAF1-4439-8CA3-49ECF5AD2200@comodo.com> Actually it would work fine since an IPv6 client would not talk to the authoritative directly anyway, it would go through a recursive that is probably dual stack unless you are playing the DNS64 game. > On Feb 19, 2015, at 3:11 PM, Ryan Sleevi wrote: > > Good point. What good is server a AAAA record from a DNS server that > doesn't listen on IPv6 > > On Thu, Feb 19, 2015 at 11:25 AM, Rick Andrews > wrote: >> Ryan, >> >> It seems to me we need to add one more detail: it must be possible to make the lookups to the authoritative resolver (DNS) over IPv4 and IPv6. A client running on an IPv6-only network will first make a DNS call to get the AAAA record for the CA's OCSP or CRL service. So the CA needs to make sure that those DNS lookups can be served via IPv6. >> >> -Rick >> >> -----Original Message----- >> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Wayne Thayer >> Sent: Thursday, February 19, 2015 8:54 AM >> To: CABFPub >> Subject: Re: [cabfpub] Preballot for IPv6 Support >> >> Ryan, >> >> We didn't find any blockers that prevent GoDaddy from enabling support for IPv6. Like other CAs, we also don't see any demand for it today, but I agree that this is a collective action problem and CAs need to remove certificate validation from the list of problems that are blocking other parties from moving to IPv6. GoDaddy supports this ballot and I would be happy to endorse. >> >> Thanks, >> >> Wayne >> >> -----Original Message----- >> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ryan Sleevi >> Sent: Wednesday, February 18, 2015 3:01 PM >> To: CABFPub >> Subject: Re: [cabfpub] Preballot for IPv6 Support >> >> In advance of tomorrow's call, I'd like to bring forward this pre-ballot again >> >> ---MOTION BEGINS--- >> >> Update Section 13.2.1 of the Baseline Requirements as follows: >> >> From: >> "The CA SHALL make revocation information for Subordinate Certificates and Subscriber Certificates available in accordance with Appendix B." >> >> To: >> >> "The CA SHALL make revocation information for Subordinate Certificates and Subscriber Certificates available in accordance with Appendix B. >> >> Effective March 1, 2016, the CA SHALL make this information available via both IPv4 and IPv6. For each DNS host included in accordance with Appendix B, lookups to the authoritative resolver MUST return valid A records if A records are requested and valid AAAA records if AAAA records are requested." >> >> Update Appendix B, Section 2(b) of the Baseline Requirements as follows: >> >> From: >> "This extension MUST be present and MUST NOT be marked critical. It MUST contain the HTTP URL of the CA?s CRL service." >> >> To: >> "This extension MUST be present and MUST NOT be marked critical. It MUST contain the HTTP URL of the CA?s CRL service. See Section 13.2.1 for details." >> >> ---MOTION ENDS--- >> >> The key changes from the previous pre-ballot are the wording changes suggested by Brian Smith, and attaching a concrete date - 1 year from now. >> _______________________________________________ >> Public mailing list >> Public at cabforum.org >> https://cabforum.org/mailman/listinfo/public >> _______________________________________________ >> Public mailing list >> Public at cabforum.org >> https://cabforum.org/mailman/listinfo/public >> _______________________________________________ >> Public mailing list >> Public at cabforum.org >> https://cabforum.org/mailman/listinfo/public > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public From sleevi at google.com Thu Feb 19 16:42:55 2015 From: sleevi at google.com (Ryan Sleevi) Date: Thu, 19 Feb 2015 15:42:55 -0800 Subject: [cabfpub] Preballot for IPv6 Support In-Reply-To: <17B2AFA3-EAF1-4439-8CA3-49ECF5AD2200@comodo.com> References: <544B0DD62A64C1448B2DA253C01141460BD3E573A0@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <17B2AFA3-EAF1-4439-8CA3-49ECF5AD2200@comodo.com> Message-ID: On Thu, Feb 19, 2015 at 3:41 PM, Phillip Hallam-Baker wrote: > Actually it would work fine since an IPv6 client would not talk to the authoritative directly anyway, it would go through a recursive that is probably dual stack unless you are playing the DNS64 game. In theory, yes. In practice, no. I know what the RFCs say. I also know that RFCs are invitations for users to go buckwild and do their own thing :) Rather than worry about the many weird and wild ways in which users, enterprises, and network operators configure things, I think being explicit here on the expectations of infrastructure is the best solution for all. From i-barreira at izenpe.net Fri Feb 20 00:33:17 2015 From: i-barreira at izenpe.net (i-barreira at izenpe.net) Date: Fri, 20 Feb 2015 08:33:17 +0100 Subject: [cabfpub] When did the WebTrust/ETSI BR audit requirement becomemandatory? Message-ID: <763539E260C37C46A0D6B340B5434C3B0ADAED2D@AEX06.ejsarea.net> Kirk, From the ETSI side, you know that the CAs that want to be ETSI audited according to the BRs can do it according to the TS 102 042 v 2.4.1 which is effective since February 2013. OTOH mandating the CAs to be certified against ETSI, up to the regulation, that was on a voluntary basis. The regulation was approved last year and it mandates the certification (not decided yet which ones) for those service providers that want to issue qualified services and become a Qualified TSP by July 2016 with a year to send the conformity assessment to the supervisory body. So, the answer is that by July 2016 (having a year to do so) all TSPs that issue qualified certificates and are ?under? the regulation shall be certified, probably against ETSI standards like the new ENs. I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. De: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] En nombre de kirk_hall at trendmicro.com Enviado el: jueves, 19 de febrero de 2015 18:00 Para: CABFPub (public at cabforum.org) Asunto: [cabfpub] When did the WebTrust/ETSI BR audit requirement becomemandatory? On our Forum call today, we asked when a WebTrust/ETSI BR audit requirement become mandatory for CAs. Ballot 62 (Nov. 2011) adopted the BRs effective July 1, 2012. However, there were no audit criteria in place for some time. I did some quick research, and the answer is not clear as to when the audit criteria came into effect. The WebTrust draft audit requirements were completed by early 2013, and I see comments that Mozilla adopted the BR audit as a program requirement at the Mountain View meeting in Feb. 2013. Here is the current Mozilla requirement at Sec. 11: https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ As I recall, the initial Mozilla BR audit requirement was not clear as to exact effective date (what operational period must be covered by a CA?s initial BR audit). I vaguely recall Mozilla clarifying the rule at our Feb. 2013 meeting at Mountain View that all CA operations occurring on or after Feb. 15, 2013 must be covered by a BR audit ? so some CAs did partial-year initial BR audits to align their BR audits with their other audits. Based on all this, I would say all CAs should have full year BR audits in place by now. We can change our Bylaw on membership at Bylaw 2.1 to reflect this. Kirk R. Hall Operations Director, Trust Services Trend Micro +1.503.753.3088 TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150220/4e5292a0/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 19121 bytes Desc: image001.png Url : https://cabforum.org/pipermail/public/attachments/20150220/4e5292a0/attachment-0001.png From rob.stradling at comodo.com Fri Feb 20 02:37:04 2015 From: rob.stradling at comodo.com (Rob Stradling) Date: Fri, 20 Feb 2015 09:37:04 +0000 Subject: [cabfpub] Preballot for IPv6 Support In-Reply-To: References: Message-ID: <54E70040.2050203@comodo.com> On 19/02/15 16:54, Wayne Thayer wrote: > Like other CAs, we also don't see any demand for it today, but I agree that this is a collective action problem and CAs need to remove certificate validation from the list of problems that are blocking other parties from moving to IPv6. GoDaddy supports this ballot and I would be happy to endorse. +1 Ryan, I would also be happy to endorse this ballot on behalf of Comodo. > Thanks, > > Wayne > > -----Original Message----- > From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ryan Sleevi > Sent: Wednesday, February 18, 2015 3:01 PM > To: CABFPub > Subject: Re: [cabfpub] Preballot for IPv6 Support > > In advance of tomorrow's call, I'd like to bring forward this pre-ballot again > > ---MOTION BEGINS--- > > Update Section 13.2.1 of the Baseline Requirements as follows: > > From: > "The CA SHALL make revocation information for Subordinate Certificates and Subscriber Certificates available in accordance with Appendix B." > > To: > > "The CA SHALL make revocation information for Subordinate Certificates and Subscriber Certificates available in accordance with Appendix B. > > Effective March 1, 2016, the CA SHALL make this information available via both IPv4 and IPv6. For each DNS host included in accordance with Appendix B, lookups to the authoritative resolver MUST return valid A records if A records are requested and valid AAAA records if AAAA records are requested." > > Update Appendix B, Section 2(b) of the Baseline Requirements as follows: > > From: > "This extension MUST be present and MUST NOT be marked critical. It MUST contain the HTTP URL of the CA?s CRL service." > > To: > "This extension MUST be present and MUST NOT be marked critical. It MUST contain the HTTP URL of the CA?s CRL service. See Section 13.2.1 for details." > > ---MOTION ENDS--- > > The key changes from the previous pre-ballot are the wording changes suggested by Brian Smith, and attaching a concrete date - 1 year from now. > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. From i-barreira at izenpe.net Fri Feb 20 02:54:51 2015 From: i-barreira at izenpe.net (i-barreira at izenpe.net) Date: Fri, 20 Feb 2015 10:54:51 +0100 Subject: [cabfpub] issues with DNSSEC Message-ID: <763539E260C37C46A0D6B340B5434C3B0AE7E2B1@AEX06.ejsarea.net> Hi, It affects BIND with DNSSEC validation https://kb.isc.org/article/AA-01235/74/CVE-2015-1349%3A-A-Problem-with-Trust-Anchor-Management-Can-Cause-named-to-Crash.html Regards I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150220/7e6b9d60/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 19121 bytes Desc: image001.png Url : https://cabforum.org/pipermail/public/attachments/20150220/7e6b9d60/attachment-0001.png From kirk_hall at trendmicro.com Fri Feb 20 09:51:39 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Fri, 20 Feb 2015 16:51:39 +0000 Subject: [cabfpub] When did the WebTrust/ETSI BR audit requirement become mandatory? In-Reply-To: References: Message-ID: Sorry, I should have clarified. Any CA can get a point in time or ?readiness? BR audit at any time, even just before starting operations. Plus any CA can get a 60 day or 90 day performance BR audit once they start operations ? in fact, that is the recommended method (i.e., don?t wait a whole year). In general, a CA can?t start selling certs to anyone until the CA has its roots in the browsers. And the browsers won?t add the roots until they see (at least) a WebTrust and a BR readiness audit ? so there really is no blocking effect on the membership rules from requiring the audits. A CA can?t be in operation (can?t be in the browsers) until that happens. Plus ? when my new CA, AffirmTrust (acquired by Trend Micro) applied to the Forum, we had our audits but no customers yet (because at that time, the Mozilla root review process was very slow). The Forum accepted us, but only on an observer basis, not member, until we started issuing certs to customers. From: Peter Bowen [mailto:pzbowen at gmail.com] Sent: Thursday, February 19, 2015 7:14 PM To: Kirk Hall (RD-US); CABFPub (public at cabforum.org) Cc: questions at cabforum.org Subject: Re: [cabfpub] When did the WebTrust/ETSI BR audit requirement become mandatory? (copying questions@ for visibility) On Thu, Feb 19, 2015 at 8:59 AM, kirk_hall at trendmicro.com > wrote: Based on all this, I would say all CAs should have full year BR audits in place by now. We can change our Bylaw on membership at Bylaw 2.1 to reflect this. Have you considered that it is possible a new CA might want to become a member before their first anniversary of operation? If you require a full year BR audit for membership, you are effectively excluding new CAs, as they presumably will start with a point in time then a partial year audit (given the requirement to get a period of time audit started within 90 days of issuing the first certificate). 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
-------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150220/dfae1d11/attachment.html From i-barreira at izenpe.net Fri Feb 20 11:53:44 2015 From: i-barreira at izenpe.net (=?utf-8?B?IkJhcnJlaXJhIElnbGVzaWFzLCBJw7FpZ28i?=) Date: Fri, 20 Feb 2015 19:53:44 +0100 Subject: [cabfpub] When did the WebTrust/ETSI BR audit requirement become mandatory? Message-ID: Kirk, any CA can sell certs without having any audit. It's up to the customers. It's their decission. You can add the CA manually Enviado de Samsung Mobile -------- Mensaje original -------- De: kirk_hall at trendmicro.com Fecha: Para: Peter Bowen ,"CABFPub (public at cabforum.org)" Cc: questions at cabforum.org Asunto: Re: [cabfpub] When did the WebTrust/ETSI BR audit requirement become mandatory? Sorry, I should have clarified. ? Any CA can get a point in time or ?readiness? BR audit at any time, even just before starting operations. ? Plus any CA can get a 60 day or 90 day performance BR audit once they start operations ? in fact, that is the recommended method (i.e., don?t wait a whole year). ? In general, a CA can?t start selling certs to anyone until the CA has its roots in the browsers.? And the browsers won?t add the roots until they see (at least) a WebTrust and a BR readiness audit ? so there really is no blocking effect on the membership rules from requiring the audits. ?A CA can?t be in operation (can?t be in the browsers) until that happens. ? Plus ? when my new CA, AffirmTrust (acquired by Trend Micro) applied to the Forum, we had our audits but no customers yet (because at that time, the Mozilla root review process was very slow).? The Forum accepted us, but only on an observer basis, not member, until we started issuing certs to customers. ? From: Peter Bowen [mailto:pzbowen at gmail.com] Sent: Thursday, February 19, 2015 7:14 PM To: Kirk Hall (RD-US); CABFPub (public at cabforum.org) Cc: questions at cabforum.org Subject: Re: [cabfpub] When did the WebTrust/ETSI BR audit requirement become mandatory? ? (copying questions@ for visibility) ? On Thu, Feb 19, 2015 at 8:59 AM, kirk_hall at trendmicro.com wrote: Based on all this, I would say all CAs should have full year BR audits in place by now.? We can change our Bylaw on membership at Bylaw 2.1 to reflect this. ? Have you considered that it is possible a new CA might want to become a member before their first anniversary of operation?? If you require a full year BR audit for membership, you are effectively excluding new CAs, as they presumably will start with a point in time then a partial year audit (given the requirement to get a period of time audit started within 90 days of issuing the first certificate). TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150220/9b96043e/attachment-0001.html From kirk_hall at trendmicro.com Fri Feb 20 12:01:55 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Fri, 20 Feb 2015 19:01:55 +0000 Subject: [cabfpub] When did the WebTrust/ETSI BR audit requirement become mandatory? In-Reply-To: References: Message-ID: That?s true ? but every person visiting the site would have to do the same thing. So as a practical matter, no commercial CA will proceed in selling certs generally without its roots being in the main browser root stores, which requires completed WebTrust/ETSI audits to be delivered to the browsers. And I don?t think the Forum needs to have ?private? CA members. From: "Barreira Iglesias, I?igo" [mailto:i-barreira at izenpe.net] Sent: Friday, February 20, 2015 10:54 AM To: Kirk Hall (RD-US); Peter Bowen; public at cabforum.org Cc: questions at cabforum.org Subject: Re: [cabfpub] When did the WebTrust/ETSI BR audit requirement become mandatory? Kirk, any CA can sell certs without having any audit. It's up to the customers. It's their decission. You can add the CA manually Enviado de Samsung Mobile -------- Mensaje original -------- De: kirk_hall at trendmicro.com Fecha: Para: Peter Bowen ,"CABFPub (public at cabforum.org)" Cc: questions at cabforum.org Asunto: Re: [cabfpub] When did the WebTrust/ETSI BR audit requirement become mandatory? Sorry, I should have clarified. Any CA can get a point in time or ?readiness? BR audit at any time, even just before starting operations. Plus any CA can get a 60 day or 90 day performance BR audit once they start operations ? in fact, that is the recommended method (i.e., don?t wait a whole year). In general, a CA can?t start selling certs to anyone until the CA has its roots in the browsers. And the browsers won?t add the roots until they see (at least) a WebTrust and a BR readiness audit ? so there really is no blocking effect on the membership rules from requiring the audits. A CA can?t be in operation (can?t be in the browsers) until that happens. Plus ? when my new CA, AffirmTrust (acquired by Trend Micro) applied to the Forum, we had our audits but no customers yet (because at that time, the Mozilla root review process was very slow). The Forum accepted us, but only on an observer basis, not member, until we started issuing certs to customers. From: Peter Bowen [mailto:pzbowen at gmail.com] Sent: Thursday, February 19, 2015 7:14 PM To: Kirk Hall (RD-US); CABFPub (public at cabforum.org) Cc: questions at cabforum.org Subject: Re: [cabfpub] When did the WebTrust/ETSI BR audit requirement become mandatory? (copying questions@ for visibility) On Thu, Feb 19, 2015 at 8:59 AM, kirk_hall at trendmicro.com > wrote: Based on all this, I would say all CAs should have full year BR audits in place by now. We can change our Bylaw on membership at Bylaw 2.1 to reflect this. Have you considered that it is possible a new CA might want to become a member before their first anniversary of operation? If you require a full year BR audit for membership, you are effectively excluding new CAs, as they presumably will start with a point in time then a partial year audit (given the requirement to get a period of time audit started within 90 days of issuing the first certificate). TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
-------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150220/aeb4aed7/attachment.html From eddy_nigg at startcom.org Fri Feb 20 14:10:06 2015 From: eddy_nigg at startcom.org (Eddy Nigg) Date: Fri, 20 Feb 2015 23:10:06 +0200 Subject: [cabfpub] When did the WebTrust/ETSI BR audit requirement become mandatory? In-Reply-To: References: Message-ID: <54E7A2AE.2040501@startcom.org> On 02/20/2015 09:01 PM, kirk_hall at trendmicro.com wrote: > > That's true -- but every person visiting the site would have to do the > same thing. So as a practical matter, no commercial CA will proceed > in selling certs generally without its roots being in the main browser > root stores, which requires completed WebTrust/ETSI audits to be > delivered to the browsers. And I don't think the Forum needs to have > "private" CA members. > The forum requires a CA to be supported by at least one major browser. But it can be a browser that isn't Mozilla - on the other hand why should WebTrust perform any other audits today than BR? -- Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. XMPP: startcom at startcom.org Blog: Join the Revolution! Twitter: Follow Me -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150220/b0674858/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4313 bytes Desc: S/MIME Cryptographic Signature Url : https://cabforum.org/pipermail/public/attachments/20150220/b0674858/attachment-0001.bin From kirk_hall at trendmicro.com Fri Feb 20 14:45:15 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Fri, 20 Feb 2015 21:45:15 +0000 Subject: [cabfpub] When did the WebTrust/ETSI BR audit requirement become mandatory? In-Reply-To: <54E7A2AE.2040501@startcom.org> References: <54E7A2AE.2040501@startcom.org> Message-ID: When you say "why" - do you mean "is regular WebTrust still required?" (it is, along with BR WebTrust), or are you suggesting that regular WebTrust should no longer be a requirement, just BR WebTrust? In an earlier string, this was asked and I recall Don Sheehy noted that the two audit regimes are somewhat overlapping in certain areas, but otherwise cover different issues and are both still needed. From: Eddy Nigg [mailto:eddy_nigg at startcom.org] Sent: Friday, February 20, 2015 1:10 PM To: Kirk Hall (RD-US); i-barreira; Peter Bowen; public at cabforum.org Subject: Re: [cabfpub] When did the WebTrust/ETSI BR audit requirement become mandatory? On 02/20/2015 09:01 PM, kirk_hall at trendmicro.com wrote: That's true - but every person visiting the site would have to do the same thing. So as a practical matter, no commercial CA will proceed in selling certs generally without its roots being in the main browser root stores, which requires completed WebTrust/ETSI audits to be delivered to the browsers. And I don't think the Forum needs to have "private" CA members. The forum requires a CA to be supported by at least one major browser. But it can be a browser that isn't Mozilla - on the other hand why should WebTrust perform any other audits today than BR? -- Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. XMPP: startcom at startcom.org Blog: Join the Revolution! Twitter: Follow Me 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
-------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150220/d1713b62/attachment.html From eddy_nigg at startcom.org Fri Feb 20 15:03:18 2015 From: eddy_nigg at startcom.org (Eddy Nigg) Date: Sat, 21 Feb 2015 00:03:18 +0200 Subject: [cabfpub] When did the WebTrust/ETSI BR audit requirement become mandatory? In-Reply-To: References: <54E7A2AE.2040501@startcom.org> Message-ID: <54E7AF26.8000706@startcom.org> On 02/20/2015 11:45 PM, kirk_hall at trendmicro.com wrote: > > When you say ?why? ? do you mean ?is regular WebTrust still required?? > (it is, along with BR WebTrust), or are you suggesting that regular > WebTrust should no longer be a requirement, just BR WebTrust? > I certainly would expect that this will become one (basic) audit eventually (and EV and others optional). -- Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. XMPP: startcom at startcom.org Blog: Join the Revolution! Twitter: Follow Me -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150221/0bd8ea25/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4313 bytes Desc: S/MIME Cryptographic Signature Url : https://cabforum.org/pipermail/public/attachments/20150221/0bd8ea25/attachment.bin From gerv at mozilla.org Mon Feb 23 07:10:10 2015 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 23 Feb 2015 14:10:10 +0000 Subject: [cabfpub] When did the WebTrust/ETSI BR audit requirement become mandatory? In-Reply-To: References: <54E61E67.6090409@mozilla.org> Message-ID: <54EB34C2.3040600@mozilla.org> On 19/02/15 18:28, kirk_hall at trendmicro.com wrote: > The > Requirements are not mandatory for Certification Authorities unless and > until they become adopted and enforced by relying?party Application > Software Suppliers. *** This sentence seems to me to say precisely what I am saying. Making a BR audit a condition of membership is moving towards making the BRs mandatory for CAs for a reason _other_ than "they are enforced by relying party Application Software Suppliers". Which would be contrary to this sentence. > No CA is required to join the Forum to operate ? the CAs only need to > satisfy the browsers. But I can?t think of any reason why a CA would > choose NOT to follow the BRs and get a BR audit if it wants to be > considered a ?real? CA. Well, perhaps there is some aspect of the BRs that they disagree with, or cannot follow for legal reasons, and wish to join in order to get things changed? I am also troubled by the general principle of "if you want a voice in getting these requirements changed, you have to abide by them first". The CAB Forum does not control the WebTrust audit criteria so this problem is not apparent when we use that as a membership filter. > And I don?t think the Forum would want to accept any new CA member that > said ?I choose not to follow the BRs, and I choose not to get a BR > audit? ? why would we want such a CA as a member? The CA/Browser Forum is not a gentleman's club; we don't get to blackball people because we don't like the way they do things. The CAB Forum also does not assess the suitability or trustworthiness of CAs for any particular role or task. Unless we think that the current criteria for CA membership are so loose that people are applying for membership who are not "real CAs", then there is no need to change the criteria. Gerv From bruce.morton at entrust.com Mon Feb 23 11:41:50 2015 From: bruce.morton at entrust.com (Bruce Morton) Date: Mon, 23 Feb 2015 18:41:50 +0000 Subject: [cabfpub] Lenovo installation of malicious root. In-Reply-To: <9CB5BBD9-58FA-4DC2-90E0-70F01911A4AC@comodo.com> References: <9CB5BBD9-58FA-4DC2-90E0-70F01911A4AC@comodo.com> Message-ID: <452C99D20750E74083DBA441FF932385E419DB78@SOTTEXCH10.corp.ad.entrust.com> Have we just come across an issue with operating systems/browsers and private roots? I suppose an attacker can install proxy software with their private root and examine all secured traffic. We don't need Lenovo to install this software, this could easily be done by any corner-store computer shop. Should private roots get the same trust indication as public trust roots? Public key pinning didn't even catch this issue as the private root seems to be trusted more than the public trust roots are. Thanks, Bruce. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Phillip Hallam-Baker Sent: Thursday, February 19, 2015 1:53 PM To: CABFPub Subject: [cabfpub] Lenovo installation of malicious root. I am sure many of you have seen this. If not you will, I have had a dozen people ping me about it in the past hour. https://www.eff.org/deeplinks/2015/02/further-evidence-lenovo-breaking-https-security-its-laptops Someone has to draw the line here or the politicians will do it for us. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150223/a6ba37d5/attachment.html From sleevi at google.com Mon Feb 23 12:05:25 2015 From: sleevi at google.com (Ryan Sleevi) Date: Mon, 23 Feb 2015 11:05:25 -0800 Subject: [cabfpub] Lenovo installation of malicious root. In-Reply-To: <452C99D20750E74083DBA441FF932385E419DB78@SOTTEXCH10.corp.ad.entrust.com> References: <9CB5BBD9-58FA-4DC2-90E0-70F01911A4AC@comodo.com> <452C99D20750E74083DBA441FF932385E419DB78@SOTTEXCH10.corp.ad.entrust.com> Message-ID: On Mon, Feb 23, 2015 at 10:41 AM, Bruce Morton wrote: > Have we just come across an issue with operating systems/browsers and > private roots? > Yes > > > I suppose an attacker can install proxy software with their private root and > examine all secured traffic. We don?t need Lenovo to install this software, > this could easily be done by any corner-store computer shop. > Correct > > > Should private roots get the same trust indication as public trust roots? > Yes. > > > Public key pinning didn?t even catch this issue as the private root seems to > be trusted more than the public trust roots are. Correct, because public key pinning is not designed to catch such issues, as it cannot catch such issues. http://www.chromium.org/Home/chromium-security/security-faq#TOC-How-does-key-pinning-interact-with-local-proxies-and-filters- > > > > Thanks, Bruce. > From palmer at google.com Mon Feb 23 12:37:30 2015 From: palmer at google.com (Chris Palmer) Date: Mon, 23 Feb 2015 11:37:30 -0800 Subject: [cabfpub] Lenovo installation of malicious root. In-Reply-To: References: <9CB5BBD9-58FA-4DC2-90E0-70F01911A4AC@comodo.com> <452C99D20750E74083DBA441FF932385E419DB78@SOTTEXCH10.corp.ad.entrust.com> Message-ID: Also, Comodo might want to tell us what is going on here: http://news.softpedia.com/news/Comodo-s-PrivDog-Breaks-HTTPS-Security-Possibly-Worse-than-Superfish-473968.shtml On Feb 23, 2015 11:05, "Ryan Sleevi" wrote: > On Mon, Feb 23, 2015 at 10:41 AM, Bruce Morton > wrote: > > Have we just come across an issue with operating systems/browsers and > > private roots? > > > > Yes > > > > > > > I suppose an attacker can install proxy software with their private root > and > > examine all secured traffic. We don?t need Lenovo to install this > software, > > this could easily be done by any corner-store computer shop. > > > > Correct > > > > > > > Should private roots get the same trust indication as public trust roots? > > > > Yes. > > > > > > > Public key pinning didn?t even catch this issue as the private root > seems to > > be trusted more than the public trust roots are. > > Correct, because public key pinning is not designed to catch such > issues, as it cannot catch such issues. > > > http://www.chromium.org/Home/chromium-security/security-faq#TOC-How-does-key-pinning-interact-with-local-proxies-and-filters- > > > > > > > > > Thanks, Bruce. > > > _______________________________________________ > 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/20150223/5caea548/attachment.html From ben.wilson at digicert.com Mon Feb 23 14:39:59 2015 From: ben.wilson at digicert.com (Ben Wilson) Date: Mon, 23 Feb 2015 21:39:59 +0000 Subject: [cabfpub] Version 1.5.3 redlined with Ballot 144 Changes Message-ID: All, Attached please find a Word version of the EV Guidelines redlined with changes from Ballot 144. Previous versions of the EV Guidelines in Word would cause some people's computers to crash while they were editing the EV Guidelines. Could a few of your take a look at this document and confirm that it is stable? Hopefully this version has eliminated that problem. Thanks, Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150223/b1d4e565/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: EV V1_5_3-redlined.doc Type: application/msword Size: 351744 bytes Desc: not available Url : https://cabforum.org/pipermail/public/attachments/20150223/b1d4e565/attachment-0001.doc -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4954 bytes Desc: not available Url : https://cabforum.org/pipermail/public/attachments/20150223/b1d4e565/attachment-0001.bin From Rick_Andrews at symantec.com Mon Feb 23 14:50:50 2015 From: Rick_Andrews at symantec.com (Rick Andrews) Date: Mon, 23 Feb 2015 13:50:50 -0800 Subject: [cabfpub] Version 1.5.3 redlined with Ballot 144 Changes In-Reply-To: References: Message-ID: <544B0DD62A64C1448B2DA253C01141460BD3FDC905@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> Ben, I got through the document without problems. I see two nits: "For a Certificate issued to a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant's control over the .onion Domain Name in accordance with Appendix F." That's not grammatically correct. Maybe say "the Applicant has control"? Appendix F: Number 1 isn't properly indented. -Rick From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ben Wilson Sent: Monday, February 23, 2015 1:40 PM To: CABFPub Subject: [cabfpub] Version 1.5.3 redlined with Ballot 144 Changes All, Attached please find a Word version of the EV Guidelines redlined with changes from Ballot 144. Previous versions of the EV Guidelines in Word would cause some people's computers to crash while they were editing the EV Guidelines. Could a few of your take a look at this document and confirm that it is stable? Hopefully this version has eliminated that problem. Thanks, Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150223/5d8319a2/attachment.html From ben.wilson at digicert.com Mon Feb 23 14:51:19 2015 From: ben.wilson at digicert.com (Ben Wilson) Date: Mon, 23 Feb 2015 21:51:19 +0000 Subject: [cabfpub] Version 1.2.4 of Baseline Requirements redlined with Ballot 144 Changes Message-ID: All, Similar to my request concerning version of the EV Guidelines just circulated, please confirm that this document (v. 1.2.4 of Baseline Requirements) is in order. Thanks, Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150223/a3fe9dd4/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: BRv1.2.4-redlined.doc Type: application/msword Size: 514560 bytes Desc: not available Url : https://cabforum.org/pipermail/public/attachments/20150223/a3fe9dd4/attachment-0001.doc -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4954 bytes Desc: not available Url : https://cabforum.org/pipermail/public/attachments/20150223/a3fe9dd4/attachment-0001.bin From ben.wilson at digicert.com Mon Feb 23 18:35:22 2015 From: ben.wilson at digicert.com (Ben Wilson) Date: Tue, 24 Feb 2015 01:35:22 +0000 Subject: [cabfpub] Version 1.2.4 of Baseline Requirements redlined with Ballot 144 Changes In-Reply-To: References: Message-ID: All, Peter Bowen reminded me that we need to update section 16.5 of the BRs - see https://bugzilla.cabforum.org/show_bug.cgi?id=10. I suppose that when I introduce a ballot to reformat the BRs to RFC 3647, that will take care of it. Ben From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ben Wilson Sent: Monday, February 23, 2015 2:51 PM To: CABFPub Subject: [cabfpub] Version 1.2.4 of Baseline Requirements redlined with Ballot 144 Changes All, Similar to my request concerning version of the EV Guidelines just circulated, please confirm that this document (v. 1.2.4 of Baseline Requirements) is in order. Thanks, Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150224/c92cf0e6/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4954 bytes Desc: not available Url : https://cabforum.org/pipermail/public/attachments/20150224/c92cf0e6/attachment.bin From robin at comodo.com Mon Feb 23 21:21:47 2015 From: robin at comodo.com (Robin Alden) Date: Mon, 23 Feb 2015 23:21:47 -0500 Subject: [cabfpub] Lenovo installation of malicious root. In-Reply-To: References: <9CB5BBD9-58FA-4DC2-90E0-70F01911A4AC@comodo.com> <452C99D20750E74083DBA441FF932385E419DB78@SOTTEXCH10.corp.ad.entrust.com> Message-ID: <00a901d04fe9$68eed040$3acc70c0$@comodo.com> Hi Chris, PrivDog is not a Comodo Group product. Comodo ships a version of PrivDog with Comodo Internet Security (CIS) and with Comodo browsers, but that is an earlier release which does not exhibit the identified behaviour. The PrivDog versions being downloaded and evaluated by security researchers is a newer stand-alone version that has never been distributed by Comodo. The issue is only present in PrivDog versions 3.0.96.0 and 3.0.97.0 and is apparently due to a bug in a third party library that PrivDog bought in. The PrivDog team has released an advisory with more information, available here: http://privdog.com/advisory.html I see that Hanno has updated his page somewhat, too, to remove the claim that it is Comodo distributing this flawed version of PrivDog. https://blog.hboeck.de/archives/865-Adware-Privdog-worse-than-Superfish.html c.f. http://web.archive.org/web/20150223010209/https://blog.hboeck.de/archives/865-Comodo-ships-Adware-Privdog-worse-than-Superfish.html Regards Robin Alden Comodo CA Ltd. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Chris Palmer Sent: 23 February 2015 14:38 To: Ryan Sleevi Cc: public at cabforum.org Subject: Re: [cabfpub] Lenovo installation of malicious root. Also, Comodo might want to tell us what is going on here: http://news.softpedia.com/news/Comodo-s-PrivDog-Breaks-HTTPS-Security-Possibly-Worse-than-Superfish-473968.shtml On Feb 23, 2015 11:05, "Ryan Sleevi" wrote: On Mon, Feb 23, 2015 at 10:41 AM, Bruce Morton wrote: > Have we just come across an issue with operating systems/browsers and > private roots? > Yes > > > I suppose an attacker can install proxy software with their private root and > examine all secured traffic. We don?t need Lenovo to install this software, > this could easily be done by any corner-store computer shop. > Correct > > > Should private roots get the same trust indication as public trust roots? > Yes. > > > Public key pinning didn?t even catch this issue as the private root seems to > be trusted more than the public trust roots are. Correct, because public key pinning is not designed to catch such issues, as it cannot catch such issues. http://www.chromium.org/Home/chromium-security/security-faq#TOC-How-does-key-pinning-interact-with-local-proxies-and-filters- > > > > Thanks, Bruce. > _______________________________________________ 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/20150223/593d33ca/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5776 bytes Desc: not available Url : https://cabforum.org/pipermail/public/attachments/20150223/593d33ca/attachment-0001.bin From kirk_hall at trendmicro.com Mon Feb 23 23:17:19 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Tue, 24 Feb 2015 06:17:19 +0000 Subject: [cabfpub] When did the WebTrust/ETSI BR audit requirement become mandatory? In-Reply-To: <54EC12E1.7030407@certizen.com> References: <54E61E67.6090409@mozilla.org> <54EB34C2.3040600@mozilla.org> <54EC12E1.7030407@certizen.com> Message-ID: There is no fee. -----Original Message----- From: Man Ho (Certizen) [mailto:manho at certizen.com] Sent: Monday, February 23, 2015 9:58 PM To: Gervase Markham; Kirk Hall (RD-US); CABFPub (public at cabforum.org) Subject: Re: [cabfpub] When did the WebTrust/ETSI BR audit requirement become mandatory? On 2/23/2015 10:10 PM, Gervase Markham wrote: > Well, perhaps there is some aspect of the BRs that they disagree with, > or cannot follow for legal reasons, and wish to join in order to get > things changed? > > I am also troubled by the general principle of "if you want a voice in > getting these requirements changed, you have to abide by them first". > The CAB Forum does not control the WebTrust audit criteria so this > problem is not apparent when we use that as a membership filter. +1 BTW, is there any membership fee for joining the CAB/Forum? -- Man Ho 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
From robin at comodo.com Tue Feb 24 05:46:29 2015 From: robin at comodo.com (Robin Alden) Date: Tue, 24 Feb 2015 07:46:29 -0500 Subject: [cabfpub] Lenovo installation of malicious root. In-Reply-To: <00a901d04fe9$68eed040$3acc70c0$@comodo.com> References: <9CB5BBD9-58FA-4DC2-90E0-70F01911A4AC@comodo.com> <452C99D20750E74083DBA441FF932385E419DB78@SOTTEXCH10.corp.ad.entrust.com> <00a901d04fe9$68eed040$3acc70c0$@comodo.com> Message-ID: <019c01d0502f$eb4fb9a0$c1ef2ce0$@comodo.com> That archive.org link I gave is dead. I?ve put a screen grab of the old page here: https://app.ccloud.com/#share/1783 &6ac37df3dbd2a650399cb25639157cbe017bc9b9 for comparison with https://blog.hboeck.de/archives/865-Adware-Privdog-worse-than-Superfish.html Regards Robin From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Robin Alden Sent: 23 February 2015 23:22 To: 'Chris Palmer'; 'Ryan Sleevi' Cc: public at cabforum.org Subject: Re: [cabfpub] Lenovo installation of malicious root. Hi Chris, PrivDog is not a Comodo Group product. Comodo ships a version of PrivDog with Comodo Internet Security (CIS) and with Comodo browsers, but that is an earlier release which does not exhibit the identified behaviour. The PrivDog versions being downloaded and evaluated by security researchers is a newer stand-alone version that has never been distributed by Comodo. The issue is only present in PrivDog versions 3.0.96.0 and 3.0.97.0 and is apparently due to a bug in a third party library that PrivDog bought in. The PrivDog team has released an advisory with more information, available here: http://privdog.com/advisory.html I see that Hanno has updated his page somewhat, too, to remove the claim that it is Comodo distributing this flawed version of PrivDog. https://blog.hboeck.de/archives/865-Adware-Privdog-worse-than-Superfish.html c.f. http://web.archive.org/web/20150223010209/https://blog.hboeck.de/archives/865-Comodo-ships-Adware-Privdog-worse-than-Superfish.html Regards Robin Alden Comodo CA Ltd. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Chris Palmer Sent: 23 February 2015 14:38 To: Ryan Sleevi Cc: public at cabforum.org Subject: Re: [cabfpub] Lenovo installation of malicious root. Also, Comodo might want to tell us what is going on here: http://news.softpedia.com/news/Comodo-s-PrivDog-Breaks-HTTPS-Security-Possibly-Worse-than-Superfish-473968.shtml -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150224/1e02c29e/attachment.html From ben.wilson at digicert.com Tue Feb 24 08:21:44 2015 From: ben.wilson at digicert.com (Ben Wilson) Date: Tue, 24 Feb 2015 15:21:44 +0000 Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Message-ID: <4214ab2ac59143c3a726ad7419792a45@EX2.corp.digicert.com> Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework The Certificate Policy Review Working Group was chartered by Ballot 128 to (i) consider existing and proposed standards, (ii) create a list of potential improvements based on the considered standards that improve the existing CAB Forum work product, (iii) evaluate the transition to a 3647 format based on the amount [of work involved]. One deliverable of the CP Review WG was to propose a ballot to improve CA infrastructure based on existing standards and documents and recommend whether to finish the 3647 conversion presented by Jeremy Rowley in January 2014. The CP Review WG has met and concluded that the best path forward for the Forum is to complete a conversion to the RFC 3647 for the Baseline Requirements with an initial step that merely moves existing content from the Baseline Requirements and the Network and Certificate System Security Requirements into the RFC 3647 format. Attached is an RFC-3647-formatted Certificate Policy for Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates. Comments embedded in the document contain either the source of the text (for content copied from the Baseline Requirements) or the current text (for provisions incorporated by reference from the Network and Certificate System Security Requirements ("NetSec"). It was decided that it was better to incorporate the NetSec requirements by reference rather than copying and pasting them in. In some limited instances the phrase "these Requirements" has been replaced with "this CP." However, "these Requirements" is mostly left in to preserve consistency with the current Baseline Requirements. Ben Wilson of DigiCert made the following motion, from and from have endorsed it. Motion Begins Be it resolved that the CA / Browser Forum adopts the attached CA/B Forum Certificate Policy v.1.2.5, effective immediately. Motion Ends The review period for this ballot shall commence at 2200 UTC on March 2015 and will close at 2200 UTC on March 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on March 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the ballot must indicate a clear 'yes' in the response. A vote against the ballot must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/. In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and more than one half of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or by abstaining for the vote to be valid. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150224/aa8c2403/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: CAB Forum BR 3647 CP Draft.doc Type: application/msword Size: 601600 bytes Desc: not available Url : https://cabforum.org/pipermail/public/attachments/20150224/aa8c2403/attachment-0001.doc -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4954 bytes Desc: not available Url : https://cabforum.org/pipermail/public/attachments/20150224/aa8c2403/attachment-0001.bin From THollebeek at trustwave.com Tue Feb 24 08:49:07 2015 From: THollebeek at trustwave.com (Tim Hollebeek) Date: Tue, 24 Feb 2015 15:49:07 +0000 Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework In-Reply-To: <4214ab2ac59143c3a726ad7419792a45@EX2.corp.digicert.com> References: <4214ab2ac59143c3a726ad7419792a45@EX2.corp.digicert.com> Message-ID: I'll endorse. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ben Wilson Sent: Tuesday, February 24, 2015 10:22 AM To: CABFPub Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework The Certificate Policy Review Working Group was chartered by Ballot 128 to (i) consider existing and proposed standards, (ii) create a list of potential improvements based on the considered standards that improve the existing CAB Forum work product, (iii) evaluate the transition to a 3647 format based on the amount [of work involved]. One deliverable of the CP Review WG was to propose a ballot to improve CA infrastructure based on existing standards and documents and recommend whether to finish the 3647 conversion presented by Jeremy Rowley in January 2014. The CP Review WG has met and concluded that the best path forward for the Forum is to complete a conversion to the RFC 3647 for the Baseline Requirements with an initial step that merely moves existing content from the Baseline Requirements and the Network and Certificate System Security Requirements into the RFC 3647 format. Attached is an RFC-3647-formatted Certificate Policy for Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates. Comments embedded in the document contain either the source of the text (for content copied from the Baseline Requirements) or the current text (for provisions incorporated by reference from the Network and Certificate System Security Requirements ("NetSec"). It was decided that it was better to incorporate the NetSec requirements by reference rather than copying and pasting them in. In some limited instances the phrase "these Requirements" has been replaced with "this CP." However, "these Requirements" is mostly left in to preserve consistency with the current Baseline Requirements. Ben Wilson of DigiCert made the following motion, from and from have endorsed it. Motion Begins Be it resolved that the CA / Browser Forum adopts the attached CA/B Forum Certificate Policy v.1.2.5, effective immediately. Motion Ends The review period for this ballot shall commence at 2200 UTC on March 2015 and will close at 2200 UTC on March 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on March 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the ballot must indicate a clear 'yes' in the response. A vote against the ballot must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/. In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and more than one half of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or by abstaining for the vote to be valid. ________________________________ This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150224/19d24f08/attachment.html From kirk_hall at trendmicro.com Tue Feb 24 09:51:48 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Tue, 24 Feb 2015 16:51:48 +0000 Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework In-Reply-To: <4214ab2ac59143c3a726ad7419792a45@EX2.corp.digicert.com> References: <4214ab2ac59143c3a726ad7419792a45@EX2.corp.digicert.com> Message-ID: Ben - first of all, thanks for the hard work on this one. I'm trying to figure out the benefit of locking the Forum into the RFC 3647 framework for the purpose of listing BR requirements. Is there really a benefit? Does it add to understanding and make CA compliance any easier? Or will it force us to put rules in odd places that actually make understanding a bit harder? I note the BR 8.2 already requires CAs to put their CPS into the format of RFC 2527 or 3647. See the first two sections of BR 8.2 below. That can facilitate comparison between the CPSs of different CAs, if anyone cares to do that. But is there any corresponding benefit from restructuring the BRs to an RFC 3647 format? What if a rule spans two or more different sections of the RFC 3647 format? I see that in your new organization of the BRs you have moved old BR 8.2.2 to a new Section 2.1 Repositories, not to new Section 2.2 Publication of Information. How did you make that choice? And is there an expectation that CAs will publish their CAA disclosure in new Sec. 2.2 of their CPS? I'm just afraid we will be handcuffing ourselves with these changes, and that there could be errors in internal cross-references. It is also a lot of work for everyone to review a complete rewrite of the BRs. Can you give us a convincing argument of why this is worth doing? Sorry I didn't ask this question earlier, but I hadn't really understood this was what the working group was doing - I thought you were just looking for GAPS in the BRs as compared to the RFC 3647 where we could ADD new provisions to the BRs - not a wholesale restructuring of the BRs. Thanks. BR 8.2.2 Disclosure The CA SHALL publicly disclose its Certificate Policy and/or Certification Practice Statement through an appropriate and readily accessible online means that is available on a 24x7 basis. The CA SHALL publicly disclose its CA business practices to the extent required by the CA's selected audit scheme (see Section 17.1). The disclosures MUST include all the material required by RFC 2527 or RFC 3647, and MUST be structured in accordance with either RFC 2527 or RFC 3647. Effective as of 15 April 2015, section 4.2 of a CA's Certificate Policy and/or Certification Practice Statement (section 4.1 for CAs still conforming to RFC 2527) SHALL state whether the CA reviews CAA Records, and if so, the CA's policy or practice on processing CAA Records for Fully Qualified Domain Names. The CA SHALL log all actions taken, if any, consistent with its processing practice. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ben Wilson Sent: Tuesday, February 24, 2015 7:22 AM To: CABFPub Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework The Certificate Policy Review Working Group was chartered by Ballot 128 to (i) consider existing and proposed standards, (ii) create a list of potential improvements based on the considered standards that improve the existing CAB Forum work product, (iii) evaluate the transition to a 3647 format based on the amount [of work involved]. One deliverable of the CP Review WG was to propose a ballot to improve CA infrastructure based on existing standards and documents and recommend whether to finish the 3647 conversion presented by Jeremy Rowley in January 2014. The CP Review WG has met and concluded that the best path forward for the Forum is to complete a conversion to the RFC 3647 for the Baseline Requirements with an initial step that merely moves existing content from the Baseline Requirements and the Network and Certificate System Security Requirements into the RFC 3647 format. Attached is an RFC-3647-formatted Certificate Policy for Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates. Comments embedded in the document contain either the source of the text (for content copied from the Baseline Requirements) or the current text (for provisions incorporated by reference from the Network and Certificate System Security Requirements ("NetSec"). It was decided that it was better to incorporate the NetSec requirements by reference rather than copying and pasting them in. In some limited instances the phrase "these Requirements" has been replaced with "this CP." However, "these Requirements" is mostly left in to preserve consistency with the current Baseline Requirements. Ben Wilson of DigiCert made the following motion, from and from have endorsed it. Motion Begins Be it resolved that the CA / Browser Forum adopts the attached CA/B Forum Certificate Policy v.1.2.5, effective immediately. Motion Ends The review period for this ballot shall commence at 2200 UTC on March 2015 and will close at 2200 UTC on March 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on March 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the ballot must indicate a clear 'yes' in the response. A vote against the ballot must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/. In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and more than one half of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or by abstaining for the vote to be valid. 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
-------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150224/8db11b23/attachment-0001.html From Dean_Coclin at symantec.com Tue Feb 24 09:59:05 2015 From: Dean_Coclin at symantec.com (Dean Coclin) Date: Tue, 24 Feb 2015 08:59:05 -0800 Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework In-Reply-To: References: <4214ab2ac59143c3a726ad7419792a45@EX2.corp.digicert.com> Message-ID: <14D026C7F297AD44AC82578DD818CDD038EF4A93E9@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> Some of the beneficiaries are Browser root programs and relying parties. Having the BRs in this format makes it easier for Jody, Kathleen and others to review CPS? and compare to the sections in the BRs for compliance. Jeremy has already taken a pass at doing this and a draft has been circulated. Dean From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of kirk_hall at trendmicro.com Sent: Tuesday, February 24, 2015 11:52 AM To: Ben Wilson; CABFPub Subject: Re: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Ben ? first of all, thanks for the hard work on this one. I?m trying to figure out the benefit of locking the Forum into the RFC 3647 framework for the purpose of listing BR requirements. Is there really a benefit? Does it add to understanding and make CA compliance any easier? Or will it force us to put rules in odd places that actually make understanding a bit harder? I note the BR 8.2 already requires CAs to put their CPS into the format of RFC 2527 or 3647. See the first two sections of BR 8.2 below. That can facilitate comparison between the CPSs of different CAs, if anyone cares to do that. But is there any corresponding benefit from restructuring the BRs to an RFC 3647 format? What if a rule spans two or more different sections of the RFC 3647 format? I see that in your new organization of the BRs you have moved old BR 8.2.2 to a new Section 2.1 Repositories, not to new Section 2.2 Publication of Information. How did you make that choice? And is there an expectation that CAs will publish their CAA disclosure in new Sec. 2.2 of their CPS? I?m just afraid we will be handcuffing ourselves with these changes, and that there could be errors in internal cross-references. It is also a lot of work for everyone to review a complete rewrite of the BRs. Can you give us a convincing argument of why this is worth doing? Sorry I didn?t ask this question earlier, but I hadn?t really understood this was what the working group was doing ? I thought you were just looking for GAPS in the BRs as compared to the RFC 3647 where we could ADD new provisions to the BRs ? not a wholesale restructuring of the BRs. Thanks. BR 8.2.2 Disclosure The CA SHALL publicly disclose its Certificate Policy and/or Certification Practice Statement through an appropriate and readily accessible online means that is available on a 24x7 basis. The CA SHALL publicly disclose its CA business practices to the extent required by the CA?s selected audit scheme (see Section 17.1). The disclosures MUST include all the material required by RFC 2527 or RFC 3647, and MUST be structured in accordance with either RFC 2527 or RFC 3647. Effective as of 15 April 2015, section 4.2 of a CA's Certificate Policy and/or Certification Practice Statement (section 4.1 for CAs still conforming to RFC 2527) SHALL state whether the CA reviews CAA Records, and if so, the CA?s policy or practice on processing CAA Records for Fully Qualified Domain Names. The CA SHALL log all actions taken, if any, consistent with its processing practice. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ben Wilson Sent: Tuesday, February 24, 2015 7:22 AM To: CABFPub Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework The Certificate Policy Review Working Group was chartered by Ballot 128 to (i) consider existing and proposed standards, (ii) create a list of potential improvements based on the considered standards that improve the existing CAB Forum work product, (iii) evaluate the transition to a 3647 format based on the amount [of work involved]. One deliverable of the CP Review WG was to propose a ballot to improve CA infrastructure based on existing standards and documents and recommend whether to finish the 3647 conversion presented by Jeremy Rowley in January 2014. The CP Review WG has met and concluded that the best path forward for the Forum is to complete a conversion to the RFC 3647 for the Baseline Requirements with an initial step that merely moves existing content from the Baseline Requirements and the Network and Certificate System Security Requirements into the RFC 3647 format. Attached is an RFC-3647-formatted Certificate Policy for Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates. Comments embedded in the document contain either the source of the text (for content copied from the Baseline Requirements) or the current text (for provisions incorporated by reference from the Network and Certificate System Security Requirements ("NetSec"). It was decided that it was better to incorporate the NetSec requirements by reference rather than copying and pasting them in. In some limited instances the phrase "these Requirements" has been replaced with "this CP." However, "these Requirements" is mostly left in to preserve consistency with the current Baseline Requirements. Ben Wilson of DigiCert made the following motion, from and from have endorsed it. Motion Begins Be it resolved that the CA / Browser Forum adopts the attached CA/B Forum Certificate Policy v.1.2.5, effective immediately. Motion Ends The review period for this ballot shall commence at 2200 UTC on March 2015 and will close at 2200 UTC on March 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on March 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the ballot must indicate a clear ?yes? in the response. A vote against the ballot must indicate a clear ?no? in the response. A vote to abstain must indicate a clear ?abstain? in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/. In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and more than one half of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members? at least nine members must participate in the ballot, either by voting in favor, voting against, or by abstaining for the vote to be valid. TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150224/95f20115/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6130 bytes Desc: not available Url : https://cabforum.org/pipermail/public/attachments/20150224/95f20115/attachment-0001.bin From jodycl at microsoft.com Tue Feb 24 10:24:03 2015 From: jodycl at microsoft.com (Jody Cloutier) Date: Tue, 24 Feb 2015 17:24:03 +0000 Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework In-Reply-To: References: <4214ab2ac59143c3a726ad7419792a45@EX2.corp.digicert.com> Message-ID: I'll endorse. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Tim Hollebeek Sent: Tuesday, February 24, 2015 7:49 AM To: Ben Wilson; CABFPub Subject: Re: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework I'll endorse. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ben Wilson Sent: Tuesday, February 24, 2015 10:22 AM To: CABFPub Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework The Certificate Policy Review Working Group was chartered by Ballot 128 to (i) consider existing and proposed standards, (ii) create a list of potential improvements based on the considered standards that improve the existing CAB Forum work product, (iii) evaluate the transition to a 3647 format based on the amount [of work involved]. One deliverable of the CP Review WG was to propose a ballot to improve CA infrastructure based on existing standards and documents and recommend whether to finish the 3647 conversion presented by Jeremy Rowley in January 2014. The CP Review WG has met and concluded that the best path forward for the Forum is to complete a conversion to the RFC 3647 for the Baseline Requirements with an initial step that merely moves existing content from the Baseline Requirements and the Network and Certificate System Security Requirements into the RFC 3647 format. Attached is an RFC-3647-formatted Certificate Policy for Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates. Comments embedded in the document contain either the source of the text (for content copied from the Baseline Requirements) or the current text (for provisions incorporated by reference from the Network and Certificate System Security Requirements ("NetSec"). It was decided that it was better to incorporate the NetSec requirements by reference rather than copying and pasting them in. In some limited instances the phrase "these Requirements" has been replaced with "this CP." However, "these Requirements" is mostly left in to preserve consistency with the current Baseline Requirements. Ben Wilson of DigiCert made the following motion, from and from have endorsed it. Motion Begins Be it resolved that the CA / Browser Forum adopts the attached CA/B Forum Certificate Policy v.1.2.5, effective immediately. Motion Ends The review period for this ballot shall commence at 2200 UTC on March 2015 and will close at 2200 UTC on March 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on March 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the ballot must indicate a clear 'yes' in the response. A vote against the ballot must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/. In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and more than one half of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or by abstaining for the vote to be valid. ________________________________ This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150224/15c3fd60/attachment.html From kirk_hall at trendmicro.com Tue Feb 24 10:56:12 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Tue, 24 Feb 2015 17:56:12 +0000 Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework In-Reply-To: <14D026C7F297AD44AC82578DD818CDD038EF4A93E9@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> References: <4214ab2ac59143c3a726ad7419792a45@EX2.corp.digicert.com> <14D026C7F297AD44AC82578DD818CDD038EF4A93E9@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> Message-ID: Fair point, but here is another consideration. Right now, all the WebTrust (and ETSI?) documents are laid out more or less in the same order as the current BRs and EVGL, and include references to the current numbering. If all numbering is changed, they will have to amend the WebTrust (and ETSI?) internal references ? maybe not a big deal ? but the order of the WebTrust requirements will no longer correspond to the order of the BRs. From: Dean Coclin [mailto:Dean_Coclin at symantec.com] Sent: Tuesday, February 24, 2015 8:59 AM To: Kirk Hall (RD-US); Ben Wilson; CABFPub Subject: RE: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Some of the beneficiaries are Browser root programs and relying parties. Having the BRs in this format makes it easier for Jody, Kathleen and others to review CPS? and compare to the sections in the BRs for compliance. Jeremy has already taken a pass at doing this and a draft has been circulated. Dean From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of kirk_hall at trendmicro.com Sent: Tuesday, February 24, 2015 11:52 AM To: Ben Wilson; CABFPub Subject: Re: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Ben ? first of all, thanks for the hard work on this one. I?m trying to figure out the benefit of locking the Forum into the RFC 3647 framework for the purpose of listing BR requirements. Is there really a benefit? Does it add to understanding and make CA compliance any easier? Or will it force us to put rules in odd places that actually make understanding a bit harder? I note the BR 8.2 already requires CAs to put their CPS into the format of RFC 2527 or 3647. See the first two sections of BR 8.2 below. That can facilitate comparison between the CPSs of different CAs, if anyone cares to do that. But is there any corresponding benefit from restructuring the BRs to an RFC 3647 format? What if a rule spans two or more different sections of the RFC 3647 format? I see that in your new organization of the BRs you have moved old BR 8.2.2 to a new Section 2.1 Repositories, not to new Section 2.2 Publication of Information. How did you make that choice? And is there an expectation that CAs will publish their CAA disclosure in new Sec. 2.2 of their CPS? I?m just afraid we will be handcuffing ourselves with these changes, and that there could be errors in internal cross-references. It is also a lot of work for everyone to review a complete rewrite of the BRs. Can you give us a convincing argument of why this is worth doing? Sorry I didn?t ask this question earlier, but I hadn?t really understood this was what the working group was doing ? I thought you were just looking for GAPS in the BRs as compared to the RFC 3647 where we could ADD new provisions to the BRs ? not a wholesale restructuring of the BRs. Thanks. BR 8.2.2 Disclosure The CA SHALL publicly disclose its Certificate Policy and/or Certification Practice Statement through an appropriate and readily accessible online means that is available on a 24x7 basis. The CA SHALL publicly disclose its CA business practices to the extent required by the CA?s selected audit scheme (see Section 17.1). The disclosures MUST include all the material required by RFC 2527 or RFC 3647, and MUST be structured in accordance with either RFC 2527 or RFC 3647. Effective as of 15 April 2015, section 4.2 of a CA's Certificate Policy and/or Certification Practice Statement (section 4.1 for CAs still conforming to RFC 2527) SHALL state whether the CA reviews CAA Records, and if so, the CA?s policy or practice on processing CAA Records for Fully Qualified Domain Names. The CA SHALL log all actions taken, if any, consistent with its processing practice. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ben Wilson Sent: Tuesday, February 24, 2015 7:22 AM To: CABFPub Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework The Certificate Policy Review Working Group was chartered by Ballot 128 to (i) consider existing and proposed standards, (ii) create a list of potential improvements based on the considered standards that improve the existing CAB Forum work product, (iii) evaluate the transition to a 3647 format based on the amount [of work involved]. One deliverable of the CP Review WG was to propose a ballot to improve CA infrastructure based on existing standards and documents and recommend whether to finish the 3647 conversion presented by Jeremy Rowley in January 2014. The CP Review WG has met and concluded that the best path forward for the Forum is to complete a conversion to the RFC 3647 for the Baseline Requirements with an initial step that merely moves existing content from the Baseline Requirements and the Network and Certificate System Security Requirements into the RFC 3647 format. Attached is an RFC-3647-formatted Certificate Policy for Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates. Comments embedded in the document contain either the source of the text (for content copied from the Baseline Requirements) or the current text (for provisions incorporated by reference from the Network and Certificate System Security Requirements ("NetSec"). It was decided that it was better to incorporate the NetSec requirements by reference rather than copying and pasting them in. In some limited instances the phrase "these Requirements" has been replaced with "this CP." However, "these Requirements" is mostly left in to preserve consistency with the current Baseline Requirements. Ben Wilson of DigiCert made the following motion, from and from have endorsed it. Motion Begins Be it resolved that the CA / Browser Forum adopts the attached CA/B Forum Certificate Policy v.1.2.5, effective immediately. Motion Ends The review period for this ballot shall commence at 2200 UTC on March 2015 and will close at 2200 UTC on March 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on March 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the ballot must indicate a clear ?yes? in the response. A vote against the ballot must indicate a clear ?no? in the response. A vote to abstain must indicate a clear ?abstain? in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/. In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and more than one half of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members? at least nine members must participate in the ballot, either by voting in favor, voting against, or by abstaining for the vote to be valid. TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
-------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150224/42c9d0a9/attachment-0001.html From ben.wilson at digicert.com Tue Feb 24 11:02:21 2015 From: ben.wilson at digicert.com (Ben Wilson) Date: Tue, 24 Feb 2015 18:02:21 +0000 Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework In-Reply-To: References: <4214ab2ac59143c3a726ad7419792a45@EX2.corp.digicert.com> Message-ID: <2f0cf1bb3e3c488ebf5e700d9629aa91@EX2.corp.digicert.com> That is how the original from Jeremy was introduced with his email dated November 7, 2013, but I assume that it can be moved to section 2.2. From: kirk_hall at trendmicro.com [mailto:kirk_hall at trendmicro.com] Sent: Tuesday, February 24, 2015 9:52 AM To: Ben Wilson; CABFPub Subject: RE: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Ben ? first of all, thanks for the hard work on this one. I?m trying to figure out the benefit of locking the Forum into the RFC 3647 framework for the purpose of listing BR requirements. Is there really a benefit? Does it add to understanding and make CA compliance any easier? Or will it force us to put rules in odd places that actually make understanding a bit harder? I note the BR 8.2 already requires CAs to put their CPS into the format of RFC 2527 or 3647. See the first two sections of BR 8.2 below. That can facilitate comparison between the CPSs of different CAs, if anyone cares to do that. But is there any corresponding benefit from restructuring the BRs to an RFC 3647 format? What if a rule spans two or more different sections of the RFC 3647 format? I see that in your new organization of the BRs you have moved old BR 8.2.2 to a new Section 2.1 Repositories, not to new Section 2.2 Publication of Information. How did you make that choice? And is there an expectation that CAs will publish their CAA disclosure in new Sec. 2.2 of their CPS? I?m just afraid we will be handcuffing ourselves with these changes, and that there could be errors in internal cross-references. It is also a lot of work for everyone to review a complete rewrite of the BRs. Can you give us a convincing argument of why this is worth doing? Sorry I didn?t ask this question earlier, but I hadn?t really understood this was what the working group was doing ? I thought you were just looking for GAPS in the BRs as compared to the RFC 3647 where we could ADD new provisions to the BRs ? not a wholesale restructuring of the BRs. Thanks. BR 8.2.2 Disclosure The CA SHALL publicly disclose its Certificate Policy and/or Certification Practice Statement through an appropriate and readily accessible online means that is available on a 24x7 basis. The CA SHALL publicly disclose its CA business practices to the extent required by the CA?s selected audit scheme (see Section 17.1). The disclosures MUST include all the material required by RFC 2527 or RFC 3647, and MUST be structured in accordance with either RFC 2527 or RFC 3647. Effective as of 15 April 2015, section 4.2 of a CA's Certificate Policy and/or Certification Practice Statement (section 4.1 for CAs still conforming to RFC 2527) SHALL state whether the CA reviews CAA Records, and if so, the CA?s policy or practice on processing CAA Records for Fully Qualified Domain Names. The CA SHALL log all actions taken, if any, consistent with its processing practice. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ben Wilson Sent: Tuesday, February 24, 2015 7:22 AM To: CABFPub Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework The Certificate Policy Review Working Group was chartered by Ballot 128 to (i) consider existing and proposed standards, (ii) create a list of potential improvements based on the considered standards that improve the existing CAB Forum work product, (iii) evaluate the transition to a 3647 format based on the amount [of work involved]. One deliverable of the CP Review WG was to propose a ballot to improve CA infrastructure based on existing standards and documents and recommend whether to finish the 3647 conversion presented by Jeremy Rowley in January 2014. The CP Review WG has met and concluded that the best path forward for the Forum is to complete a conversion to the RFC 3647 for the Baseline Requirements with an initial step that merely moves existing content from the Baseline Requirements and the Network and Certificate System Security Requirements into the RFC 3647 format. Attached is an RFC-3647-formatted Certificate Policy for Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates. Comments embedded in the document contain either the source of the text (for content copied from the Baseline Requirements) or the current text (for provisions incorporated by reference from the Network and Certificate System Security Requirements ("NetSec"). It was decided that it was better to incorporate the NetSec requirements by reference rather than copying and pasting them in. In some limited instances the phrase "these Requirements" has been replaced with "this CP." However, "these Requirements" is mostly left in to preserve consistency with the current Baseline Requirements. Ben Wilson of DigiCert made the following motion, from and from have endorsed it. Motion Begins Be it resolved that the CA / Browser Forum adopts the attached CA/B Forum Certificate Policy v.1.2.5, effective immediately. Motion Ends The review period for this ballot shall commence at 2200 UTC on March 2015 and will close at 2200 UTC on March 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on March 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the ballot must indicate a clear ?yes? in the response. A vote against the ballot must indicate a clear ?no? in the response. A vote to abstain must indicate a clear ?abstain? in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/. In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and more than one half of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members? at least nine members must participate in the ballot, either by voting in favor, voting against, or by abstaining for the vote to be valid. TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150224/5da76f0c/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4954 bytes Desc: not available Url : https://cabforum.org/pipermail/public/attachments/20150224/5da76f0c/attachment-0001.bin From kirk_hall at trendmicro.com Tue Feb 24 11:13:43 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Tue, 24 Feb 2015 18:13:43 +0000 Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework In-Reply-To: <2f0cf1bb3e3c488ebf5e700d9629aa91@EX2.corp.digicert.com> References: <4214ab2ac59143c3a726ad7419792a45@EX2.corp.digicert.com> <2f0cf1bb3e3c488ebf5e700d9629aa91@EX2.corp.digicert.com> Message-ID: Ben ? I was not arguing for any specific change. I was just raising the question of whether trying to fit the BRs into RFC 3647 created its own problems ? like where does a BR section go, and what should be done about a BR section that touches multiple sections of RFC 3647 (do you split up the current BR section, or just choose one place in the RFC 3647 format to put all the BR sections?). One other consideration ? there are many parts of the BRs (and EVGLs) that are not included in or relevant to a CA?s CPS ? they are either requirements, technical standards, or prohibitions, but they don?t have to be declared or included in a CPS. So in that sense, putting the BRs into RFC 3647 does not aid in review or comparison of CPSs across CAs, at least as to those sections? From: Ben Wilson [mailto:ben.wilson at digicert.com] Sent: Tuesday, February 24, 2015 10:02 AM To: Kirk Hall (RD-US); CABFPub Subject: RE: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework That is how the original from Jeremy was introduced with his email dated November 7, 2013, but I assume that it can be moved to section 2.2. From: kirk_hall at trendmicro.com [mailto:kirk_hall at trendmicro.com] Sent: Tuesday, February 24, 2015 9:52 AM To: Ben Wilson; CABFPub Subject: RE: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Ben ? first of all, thanks for the hard work on this one. I?m trying to figure out the benefit of locking the Forum into the RFC 3647 framework for the purpose of listing BR requirements. Is there really a benefit? Does it add to understanding and make CA compliance any easier? Or will it force us to put rules in odd places that actually make understanding a bit harder? I note the BR 8.2 already requires CAs to put their CPS into the format of RFC 2527 or 3647. See the first two sections of BR 8.2 below. That can facilitate comparison between the CPSs of different CAs, if anyone cares to do that. But is there any corresponding benefit from restructuring the BRs to an RFC 3647 format? What if a rule spans two or more different sections of the RFC 3647 format? I see that in your new organization of the BRs you have moved old BR 8.2.2 to a new Section 2.1 Repositories, not to new Section 2.2 Publication of Information. How did you make that choice? And is there an expectation that CAs will publish their CAA disclosure in new Sec. 2.2 of their CPS? I?m just afraid we will be handcuffing ourselves with these changes, and that there could be errors in internal cross-references. It is also a lot of work for everyone to review a complete rewrite of the BRs. Can you give us a convincing argument of why this is worth doing? Sorry I didn?t ask this question earlier, but I hadn?t really understood this was what the working group was doing ? I thought you were just looking for GAPS in the BRs as compared to the RFC 3647 where we could ADD new provisions to the BRs ? not a wholesale restructuring of the BRs. Thanks. BR 8.2.2 Disclosure The CA SHALL publicly disclose its Certificate Policy and/or Certification Practice Statement through an appropriate and readily accessible online means that is available on a 24x7 basis. The CA SHALL publicly disclose its CA business practices to the extent required by the CA?s selected audit scheme (see Section 17.1). The disclosures MUST include all the material required by RFC 2527 or RFC 3647, and MUST be structured in accordance with either RFC 2527 or RFC 3647. Effective as of 15 April 2015, section 4.2 of a CA's Certificate Policy and/or Certification Practice Statement (section 4.1 for CAs still conforming to RFC 2527) SHALL state whether the CA reviews CAA Records, and if so, the CA?s policy or practice on processing CAA Records for Fully Qualified Domain Names. The CA SHALL log all actions taken, if any, consistent with its processing practice. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ben Wilson Sent: Tuesday, February 24, 2015 7:22 AM To: CABFPub Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework The Certificate Policy Review Working Group was chartered by Ballot 128 to (i) consider existing and proposed standards, (ii) create a list of potential improvements based on the considered standards that improve the existing CAB Forum work product, (iii) evaluate the transition to a 3647 format based on the amount [of work involved]. One deliverable of the CP Review WG was to propose a ballot to improve CA infrastructure based on existing standards and documents and recommend whether to finish the 3647 conversion presented by Jeremy Rowley in January 2014. The CP Review WG has met and concluded that the best path forward for the Forum is to complete a conversion to the RFC 3647 for the Baseline Requirements with an initial step that merely moves existing content from the Baseline Requirements and the Network and Certificate System Security Requirements into the RFC 3647 format. Attached is an RFC-3647-formatted Certificate Policy for Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates. Comments embedded in the document contain either the source of the text (for content copied from the Baseline Requirements) or the current text (for provisions incorporated by reference from the Network and Certificate System Security Requirements ("NetSec"). It was decided that it was better to incorporate the NetSec requirements by reference rather than copying and pasting them in. In some limited instances the phrase "these Requirements" has been replaced with "this CP." However, "these Requirements" is mostly left in to preserve consistency with the current Baseline Requirements. Ben Wilson of DigiCert made the following motion, from and from have endorsed it. Motion Begins Be it resolved that the CA / Browser Forum adopts the attached CA/B Forum Certificate Policy v.1.2.5, effective immediately. Motion Ends The review period for this ballot shall commence at 2200 UTC on March 2015 and will close at 2200 UTC on March 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on March 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the ballot must indicate a clear ?yes? in the response. A vote against the ballot must indicate a clear ?no? in the response. A vote to abstain must indicate a clear ?abstain? in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/. In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and more than one half of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members? at least nine members must participate in the ballot, either by voting in favor, voting against, or by abstaining for the vote to be valid. TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
-------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150224/cd31ccae/attachment-0001.html From eddy_nigg at startcom.org Tue Feb 24 11:30:45 2015 From: eddy_nigg at startcom.org (Eddy Nigg) Date: Tue, 24 Feb 2015 20:30:45 +0200 Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework In-Reply-To: References: <4214ab2ac59143c3a726ad7419792a45@EX2.corp.digicert.com> <2f0cf1bb3e3c488ebf5e700d9629aa91@EX2.corp.digicert.com> Message-ID: <54ECC355.6030702@startcom.org> On 02/24/2015 08:13 PM, kirk_hall at trendmicro.com wrote: > One other consideration -- there are many parts of the BRs (and EVGLs) > that are not included in or relevant to a CA's CPS -- they are either > requirements, technical standards, or prohibitions, but they don't > have to be declared or included in a CPS. So in that sense, putting > the BRs into RFC 3647 does not aid in review or comparison of CPSs > across CAs, at least as to those sections... How about the BR in addition to a RFC 3647 structure document stating the relevant BR requirements? Meaning, two documents. -- Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. XMPP: startcom at startcom.org Blog: Join the Revolution! Twitter: Follow Me -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150224/3adcebf6/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4313 bytes Desc: S/MIME Cryptographic Signature Url : https://cabforum.org/pipermail/public/attachments/20150224/3adcebf6/attachment.bin From eddy_nigg at startcom.org Tue Feb 24 11:30:54 2015 From: eddy_nigg at startcom.org (Eddy Nigg) Date: Tue, 24 Feb 2015 20:30:54 +0200 Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework In-Reply-To: References: <4214ab2ac59143c3a726ad7419792a45@EX2.corp.digicert.com> <2f0cf1bb3e3c488ebf5e700d9629aa91@EX2.corp.digicert.com> Message-ID: <54ECC35E.8090405@startcom.org> On 02/24/2015 08:13 PM, kirk_hall at trendmicro.com wrote: > One other consideration -- there are many parts of the BRs (and EVGLs) > that are not included in or relevant to a CA's CPS -- they are either > requirements, technical standards, or prohibitions, but they don't > have to be declared or included in a CPS. So in that sense, putting > the BRs into RFC 3647 does not aid in review or comparison of CPSs > across CAs, at least as to those sections... How about the BR in addition to a RFC 3647 structured document stating the relevant BR requirements? Meaning, two documents. -- Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. XMPP: startcom at startcom.org Blog: Join the Revolution! Twitter: Follow Me -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150224/8af3014f/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4313 bytes Desc: S/MIME Cryptographic Signature Url : https://cabforum.org/pipermail/public/attachments/20150224/8af3014f/attachment.bin From ben.wilson at digicert.com Tue Feb 24 12:27:11 2015 From: ben.wilson at digicert.com (Ben Wilson) Date: Tue, 24 Feb 2015 19:27:11 +0000 Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework In-Reply-To: References: <4214ab2ac59143c3a726ad7419792a45@EX2.corp.digicert.com> <2f0cf1bb3e3c488ebf5e700d9629aa91@EX2.corp.digicert.com> Message-ID: <1c377341c18846f8b77a396438e97cf5@EX2.corp.digicert.com> Most of your comment is moot, because the work has already been done. That is why I focused on your comment about whether a particular section belongs in one section or another and responded that it could be moved. I suppose then that you are looking at the document and seeing lots of other items that belong somewhere else? I think Jeremy and I and the CP Review Working Group will be happy to accommodate such requests, but the stage we?re at now does not involve splitting sections up too much, although there are a couple of places where we?ve already done that without much trouble, such as in section 5.3.4. From: kirk_hall at trendmicro.com [mailto:kirk_hall at trendmicro.com] Sent: Tuesday, February 24, 2015 11:14 AM To: Ben Wilson; CABFPub Subject: RE: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Ben ? I was not arguing for any specific change. I was just raising the question of whether trying to fit the BRs into RFC 3647 created its own problems ? like where does a BR section go, and what should be done about a BR section that touches multiple sections of RFC 3647 (do you split up the current BR section, or just choose one place in the RFC 3647 format to put all the BR sections?). One other consideration ? there are many parts of the BRs (and EVGLs) that are not included in or relevant to a CA?s CPS ? they are either requirements, technical standards, or prohibitions, but they don?t have to be declared or included in a CPS. So in that sense, putting the BRs into RFC 3647 does not aid in review or comparison of CPSs across CAs, at least as to those sections? From: Ben Wilson [mailto:ben.wilson at digicert.com] Sent: Tuesday, February 24, 2015 10:02 AM To: Kirk Hall (RD-US); CABFPub Subject: RE: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework That is how the original from Jeremy was introduced with his email dated November 7, 2013, but I assume that it can be moved to section 2.2. From: kirk_hall at trendmicro.com [mailto:kirk_hall at trendmicro.com] Sent: Tuesday, February 24, 2015 9:52 AM To: Ben Wilson; CABFPub Subject: RE: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Ben ? first of all, thanks for the hard work on this one. I?m trying to figure out the benefit of locking the Forum into the RFC 3647 framework for the purpose of listing BR requirements. Is there really a benefit? Does it add to understanding and make CA compliance any easier? Or will it force us to put rules in odd places that actually make understanding a bit harder? I note the BR 8.2 already requires CAs to put their CPS into the format of RFC 2527 or 3647. See the first two sections of BR 8.2 below. That can facilitate comparison between the CPSs of different CAs, if anyone cares to do that. But is there any corresponding benefit from restructuring the BRs to an RFC 3647 format? What if a rule spans two or more different sections of the RFC 3647 format? I see that in your new organization of the BRs you have moved old BR 8.2.2 to a new Section 2.1 Repositories, not to new Section 2.2 Publication of Information. How did you make that choice? And is there an expectation that CAs will publish their CAA disclosure in new Sec. 2.2 of their CPS? I?m just afraid we will be handcuffing ourselves with these changes, and that there could be errors in internal cross-references. It is also a lot of work for everyone to review a complete rewrite of the BRs. Can you give us a convincing argument of why this is worth doing? Sorry I didn?t ask this question earlier, but I hadn?t really understood this was what the working group was doing ? I thought you were just looking for GAPS in the BRs as compared to the RFC 3647 where we could ADD new provisions to the BRs ? not a wholesale restructuring of the BRs. Thanks. BR 8.2.2 Disclosure The CA SHALL publicly disclose its Certificate Policy and/or Certification Practice Statement through an appropriate and readily accessible online means that is available on a 24x7 basis. The CA SHALL publicly disclose its CA business practices to the extent required by the CA?s selected audit scheme (see Section 17.1). The disclosures MUST include all the material required by RFC 2527 or RFC 3647, and MUST be structured in accordance with either RFC 2527 or RFC 3647. Effective as of 15 April 2015, section 4.2 of a CA's Certificate Policy and/or Certification Practice Statement (section 4.1 for CAs still conforming to RFC 2527) SHALL state whether the CA reviews CAA Records, and if so, the CA?s policy or practice on processing CAA Records for Fully Qualified Domain Names. The CA SHALL log all actions taken, if any, consistent with its processing practice. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ben Wilson Sent: Tuesday, February 24, 2015 7:22 AM To: CABFPub Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework The Certificate Policy Review Working Group was chartered by Ballot 128 to (i) consider existing and proposed standards, (ii) create a list of potential improvements based on the considered standards that improve the existing CAB Forum work product, (iii) evaluate the transition to a 3647 format based on the amount [of work involved]. One deliverable of the CP Review WG was to propose a ballot to improve CA infrastructure based on existing standards and documents and recommend whether to finish the 3647 conversion presented by Jeremy Rowley in January 2014. The CP Review WG has met and concluded that the best path forward for the Forum is to complete a conversion to the RFC 3647 for the Baseline Requirements with an initial step that merely moves existing content from the Baseline Requirements and the Network and Certificate System Security Requirements into the RFC 3647 format. Attached is an RFC-3647-formatted Certificate Policy for Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates. Comments embedded in the document contain either the source of the text (for content copied from the Baseline Requirements) or the current text (for provisions incorporated by reference from the Network and Certificate System Security Requirements ("NetSec"). It was decided that it was better to incorporate the NetSec requirements by reference rather than copying and pasting them in. In some limited instances the phrase "these Requirements" has been replaced with "this CP." However, "these Requirements" is mostly left in to preserve consistency with the current Baseline Requirements. Ben Wilson of DigiCert made the following motion, from and from have endorsed it. Motion Begins Be it resolved that the CA / Browser Forum adopts the attached CA/B Forum Certificate Policy v.1.2.5, effective immediately. Motion Ends The review period for this ballot shall commence at 2200 UTC on March 2015 and will close at 2200 UTC on March 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on March 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the ballot must indicate a clear ?yes? in the response. A vote against the ballot must indicate a clear ?no? in the response. A vote to abstain must indicate a clear ?abstain? in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/. In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and more than one half of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members? at least nine members must participate in the ballot, either by voting in favor, voting against, or by abstaining for the vote to be valid. TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150224/75b36b05/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4954 bytes Desc: not available Url : https://cabforum.org/pipermail/public/attachments/20150224/75b36b05/attachment-0001.bin From i-barreira at izenpe.net Wed Feb 25 00:54:41 2015 From: i-barreira at izenpe.net (i-barreira at izenpe.net) Date: Wed, 25 Feb 2015 08:54:41 +0100 Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC3647 Framework Message-ID: <763539E260C37C46A0D6B340B5434C3B0AE7EA23@AEX06.ejsarea.net> This is something that I complained time ago basically due to the timing needed to adopt the EN, which is not the same than the TS. BTW, ETSI also mandates that the CP/CPS shall be structured according to the RFC 3647 I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. De: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] En nombre de kirk_hall at trendmicro.com Enviado el: martes, 24 de febrero de 2015 18:56 Para: Dean Coclin; Ben Wilson; CABFPub Asunto: Re: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC3647 Framework Fair point, but here is another consideration. Right now, all the WebTrust (and ETSI?) documents are laid out more or less in the same order as the current BRs and EVGL, and include references to the current numbering. If all numbering is changed, they will have to amend the WebTrust (and ETSI?) internal references ? maybe not a big deal ? but the order of the WebTrust requirements will no longer correspond to the order of the BRs. From: Dean Coclin [mailto:Dean_Coclin at symantec.com] Sent: Tuesday, February 24, 2015 8:59 AM To: Kirk Hall (RD-US); Ben Wilson; CABFPub Subject: RE: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Some of the beneficiaries are Browser root programs and relying parties. Having the BRs in this format makes it easier for Jody, Kathleen and others to review CPS? and compare to the sections in the BRs for compliance. Jeremy has already taken a pass at doing this and a draft has been circulated. Dean From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of kirk_hall at trendmicro.com Sent: Tuesday, February 24, 2015 11:52 AM To: Ben Wilson; CABFPub Subject: Re: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Ben ? first of all, thanks for the hard work on this one. I?m trying to figure out the benefit of locking the Forum into the RFC 3647 framework for the purpose of listing BR requirements. Is there really a benefit? Does it add to understanding and make CA compliance any easier? Or will it force us to put rules in odd places that actually make understanding a bit harder? I note the BR 8.2 already requires CAs to put their CPS into the format of RFC 2527 or 3647. See the first two sections of BR 8.2 below. That can facilitate comparison between the CPSs of different CAs, if anyone cares to do that. But is there any corresponding benefit from restructuring the BRs to an RFC 3647 format? What if a rule spans two or more different sections of the RFC 3647 format? I see that in your new organization of the BRs you have moved old BR 8.2.2 to a new Section 2.1 Repositories, not to new Section 2.2 Publication of Information. How did you make that choice? And is there an expectation that CAs will publish their CAA disclosure in new Sec. 2.2 of their CPS? I?m just afraid we will be handcuffing ourselves with these changes, and that there could be errors in internal cross-references. It is also a lot of work for everyone to review a complete rewrite of the BRs. Can you give us a convincing argument of why this is worth doing? Sorry I didn?t ask this question earlier, but I hadn?t really understood this was what the working group was doing ? I thought you were just looking for GAPS in the BRs as compared to the RFC 3647 where we could ADD new provisions to the BRs ? not a wholesale restructuring of the BRs. Thanks. BR 8.2.2 Disclosure The CA SHALL publicly disclose its Certificate Policy and/or Certification Practice Statement through an appropriate and readily accessible online means that is available on a 24x7 basis. The CA SHALL publicly disclose its CA business practices to the extent required by the CA?s selected audit scheme (see Section 17.1). The disclosures MUST include all the material required by RFC 2527 or RFC 3647, and MUST be structured in accordance with either RFC 2527 or RFC 3647. Effective as of 15 April 2015, section 4.2 of a CA's Certificate Policy and/or Certification Practice Statement (section 4.1 for CAs still conforming to RFC 2527) SHALL state whether the CA reviews CAA Records, and if so, the CA?s policy or practice on processing CAA Records for Fully Qualified Domain Names. The CA SHALL log all actions taken, if any, consistent with its processing practice. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ben Wilson Sent: Tuesday, February 24, 2015 7:22 AM To: CABFPub Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework The Certificate Policy Review Working Group was chartered by Ballot 128 to (i) consider existing and proposed standards, (ii) create a list of potential improvements based on the considered standards that improve the existing CAB Forum work product, (iii) evaluate the transition to a 3647 format based on the amount [of work involved]. One deliverable of the CP Review WG was to propose a ballot to improve CA infrastructure based on existing standards and documents and recommend whether to finish the 3647 conversion presented by Jeremy Rowley in January 2014. The CP Review WG has met and concluded that the best path forward for the Forum is to complete a conversion to the RFC 3647 for the Baseline Requirements with an initial step that merely moves existing content from the Baseline Requirements and the Network and Certificate System Security Requirements into the RFC 3647 format. Attached is an RFC-3647-formatted Certificate Policy for Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates. Comments embedded in the document contain either the source of the text (for content copied from the Baseline Requirements) or the current text (for provisions incorporated by reference from the Network and Certificate System Security Requirements ("NetSec"). It was decided that it was better to incorporate the NetSec requirements by reference rather than copying and pasting them in. In some limited instances the phrase "these Requirements" has been replaced with "this CP." However, "these Requirements" is mostly left in to preserve consistency with the current Baseline Requirements. Ben Wilson of DigiCert made the following motion, from and from have endorsed it. Motion Begins Be it resolved that the CA / Browser Forum adopts the attached CA/B Forum Certificate Policy v.1.2.5, effective immediately. Motion Ends The review period for this ballot shall commence at 2200 UTC on March 2015 and will close at 2200 UTC on March 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on March 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the ballot must indicate a clear ?yes? in the response. A vote against the ballot must indicate a clear ?no? in the response. A vote to abstain must indicate a clear ?abstain? in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ . In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and more than one half of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members? at least nine members must participate in the ballot, either by voting in favor, voting against, or by abstaining for the vote to be valid. TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150225/5e75705e/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 19121 bytes Desc: image001.png Url : https://cabforum.org/pipermail/public/attachments/20150225/5e75705e/attachment-0001.png From ben.wilson at digicert.com Wed Feb 25 09:16:01 2015 From: ben.wilson at digicert.com (Ben Wilson) Date: Wed, 25 Feb 2015 16:16:01 +0000 Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC3647 Framework In-Reply-To: <763539E260C37C46A0D6B340B5434C3B0AE7EA23@AEX06.ejsarea.net> References: <763539E260C37C46A0D6B340B5434C3B0AE7EA23@AEX06.ejsarea.net> Message-ID: <265dc2dc2f67410bb12f97b420b7c4dc@EX2.corp.digicert.com> I?igo, The Working Group did consider your previous comments during its deliberations. We?re willing to help out in whatever way we can with transitioning the necessary cross-references in ETSI documents to the new section numbers. Once this has been accomplished, though, I don?t? think we?ll be doing this kind of moving sections around again. Ben From: i-barreira at izenpe.net [mailto:i-barreira at izenpe.net] Sent: Wednesday, February 25, 2015 12:55 AM To: kirk_hall at trendmicro.com; Dean_Coclin at symantec.com; Ben Wilson; public at cabforum.org Subject: RE: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC3647 Framework This is something that I complained time ago basically due to the timing needed to adopt the EN, which is not the same than the TS. BTW, ETSI also mandates that the CP/CPS shall be structured according to the RFC 3647 I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. De: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] En nombre de kirk_hall at trendmicro.com Enviado el: martes, 24 de febrero de 2015 18:56 Para: Dean Coclin; Ben Wilson; CABFPub Asunto: Re: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC3647 Framework Fair point, but here is another consideration. Right now, all the WebTrust (and ETSI?) documents are laid out more or less in the same order as the current BRs and EVGL, and include references to the current numbering. If all numbering is changed, they will have to amend the WebTrust (and ETSI?) internal references ? maybe not a big deal ? but the order of the WebTrust requirements will no longer correspond to the order of the BRs. From: Dean Coclin [mailto:Dean_Coclin at symantec.com] Sent: Tuesday, February 24, 2015 8:59 AM To: Kirk Hall (RD-US); Ben Wilson; CABFPub Subject: RE: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Some of the beneficiaries are Browser root programs and relying parties. Having the BRs in this format makes it easier for Jody, Kathleen and others to review CPS? and compare to the sections in the BRs for compliance. Jeremy has already taken a pass at doing this and a draft has been circulated. Dean From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of kirk_hall at trendmicro.com Sent: Tuesday, February 24, 2015 11:52 AM To: Ben Wilson; CABFPub Subject: Re: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Ben ? first of all, thanks for the hard work on this one. I?m trying to figure out the benefit of locking the Forum into the RFC 3647 framework for the purpose of listing BR requirements. Is there really a benefit? Does it add to understanding and make CA compliance any easier? Or will it force us to put rules in odd places that actually make understanding a bit harder? I note the BR 8.2 already requires CAs to put their CPS into the format of RFC 2527 or 3647. See the first two sections of BR 8.2 below. That can facilitate comparison between the CPSs of different CAs, if anyone cares to do that. But is there any corresponding benefit from restructuring the BRs to an RFC 3647 format? What if a rule spans two or more different sections of the RFC 3647 format? I see that in your new organization of the BRs you have moved old BR 8.2.2 to a new Section 2.1 Repositories, not to new Section 2.2 Publication of Information. How did you make that choice? And is there an expectation that CAs will publish their CAA disclosure in new Sec. 2.2 of their CPS? I?m just afraid we will be handcuffing ourselves with these changes, and that there could be errors in internal cross-references. It is also a lot of work for everyone to review a complete rewrite of the BRs. Can you give us a convincing argument of why this is worth doing? Sorry I didn?t ask this question earlier, but I hadn?t really understood this was what the working group was doing ? I thought you were just looking for GAPS in the BRs as compared to the RFC 3647 where we could ADD new provisions to the BRs ? not a wholesale restructuring of the BRs. Thanks. BR 8.2.2 Disclosure The CA SHALL publicly disclose its Certificate Policy and/or Certification Practice Statement through an appropriate and readily accessible online means that is available on a 24x7 basis. The CA SHALL publicly disclose its CA business practices to the extent required by the CA?s selected audit scheme (see Section 17.1). The disclosures MUST include all the material required by RFC 2527 or RFC 3647, and MUST be structured in accordance with either RFC 2527 or RFC 3647. Effective as of 15 April 2015, section 4.2 of a CA's Certificate Policy and/or Certification Practice Statement (section 4.1 for CAs still conforming to RFC 2527) SHALL state whether the CA reviews CAA Records, and if so, the CA?s policy or practice on processing CAA Records for Fully Qualified Domain Names. The CA SHALL log all actions taken, if any, consistent with its processing practice. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ben Wilson Sent: Tuesday, February 24, 2015 7:22 AM To: CABFPub Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework The Certificate Policy Review Working Group was chartered by Ballot 128 to (i) consider existing and proposed standards, (ii) create a list of potential improvements based on the considered standards that improve the existing CAB Forum work product, (iii) evaluate the transition to a 3647 format based on the amount [of work involved]. One deliverable of the CP Review WG was to propose a ballot to improve CA infrastructure based on existing standards and documents and recommend whether to finish the 3647 conversion presented by Jeremy Rowley in January 2014. The CP Review WG has met and concluded that the best path forward for the Forum is to complete a conversion to the RFC 3647 for the Baseline Requirements with an initial step that merely moves existing content from the Baseline Requirements and the Network and Certificate System Security Requirements into the RFC 3647 format. Attached is an RFC-3647-formatted Certificate Policy for Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates. Comments embedded in the document contain either the source of the text (for content copied from the Baseline Requirements) or the current text (for provisions incorporated by reference from the Network and Certificate System Security Requirements ("NetSec"). It was decided that it was better to incorporate the NetSec requirements by reference rather than copying and pasting them in. In some limited instances the phrase "these Requirements" has been replaced with "this CP." However, "these Requirements" is mostly left in to preserve consistency with the current Baseline Requirements. Ben Wilson of DigiCert made the following motion, from and from have endorsed it. Motion Begins Be it resolved that the CA / Browser Forum adopts the attached CA/B Forum Certificate Policy v.1.2.5, effective immediately. Motion Ends The review period for this ballot shall commence at 2200 UTC on March 2015 and will close at 2200 UTC on March 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on March 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the ballot must indicate a clear ?yes? in the response. A vote against the ballot must indicate a clear ?no? in the response. A vote to abstain must indicate a clear ?abstain? in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/. In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and more than one half of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members? at least nine members must participate in the ballot, either by voting in favor, voting against, or by abstaining for the vote to be valid. TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150225/c3f23723/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 19121 bytes Desc: not available Url : https://cabforum.org/pipermail/public/attachments/20150225/c3f23723/attachment-0001.png -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4954 bytes Desc: not available Url : https://cabforum.org/pipermail/public/attachments/20150225/c3f23723/attachment-0001.bin From ben.wilson at digicert.com Wed Feb 25 09:25:52 2015 From: ben.wilson at digicert.com (Ben Wilson) Date: Wed, 25 Feb 2015 16:25:52 +0000 Subject: [cabfpub] TurkTrust Root Renewal Request In-Reply-To: References: <20150218143046.4087891.82163.380@gmail.com> <20150218220100.4087891.76539.386@gmail.com> <20150219134909.4087891.28047.389@gmail.com> <20150225135154.4087891.14518.423@gmail.com> Message-ID: <3254c639926841ba86a367c16ee4ce51@EX2.corp.digicert.com> One practice that the CA/B Forum should consider is to forward select comments on proposed guidelines from the questions list over to the public list, but because of the IPR Policy concerns that it creates, the practice should include mitigations for third parties (not bound to the IPR Policy) injecting protected IP into the Forum's workstream. However, because I think the risk of that is small, I think it should be allowed as long as CABF members police themselves. -----Original Message----- From: dev-security-policy [mailto:dev-security-policy-bounces+ben=digicert.com at lists.mozilla.org] On Behalf Of Steve Roylance Sent: Wednesday, February 25, 2015 9:10 AM To: Peter Bowen Cc: fhw843 at gmail.com; mozilla-dev-security-policy at lists.mozilla.org; Kathleen Wilson Subject: RE: TurkTrust Root Renewal Request Thanks Peter. Yes my bad.. https://cabforum.org/current-work/code-signing-working-group/ has the questions e-mail at the bottom of the page. Steve > -----Original Message----- > From: dev-security-policy [mailto:dev-security-policy- > bounces+steve.roylance=globalsign.com at lists.mozilla.org] On Behalf Of > bounces+Peter > Bowen > Sent: 26 February 2015 00:00 > To: Steve Roylance > Cc: fhw843 at gmail.com; mozilla-dev-security-policy at lists.mozilla.org; > Kathleen Wilson > Subject: RE: TurkTrust Root Renewal Request > > Steve, > > Unless Peter is a member of the forum, the public list is a black > hole, as only members can post. The alternative, the questions list, > is not publicly readable, so is also a bad choice for open discussion. > > Therefore, while this thread is not the appropriate place, this forum > is probably the best place. > > Thanks, > Peter > On Feb 25, 2015 7:04 AM, "Steve Roylance" > > wrote: > > > Hi Peter. > > > > To better answer the issues you've raised, I'd suggest sending this > > topic to the public list in the CABforum. I'm not in the codesiging working > > group so I'm unable to help directly with answers to your points. I've > > not forwarded this mail as I'd rather that come directly from you. > > Details > > here:- https://cabforum.org/mailman/listinfo/public > > > > Not dodging the bullet, just highlighting a better target ;-) > > > > Steve > > > > > > > -----Original Message----- > > > From: Peter Kurrasch [mailto:fhw843 at gmail.com] > > > Sent: 25 February 2015 21:52 > > > To: Steve Roylance > > > Cc: Kathleen Wilson; mozilla-dev-security-policy at lists.mozilla.org > > > Subject: Re: TurkTrust Root Renewal Request > > > > > > Thanks for putting that together, Steve. Reading through the doc > > > it > > appears that > > > some of my concerns are addressed but I do have a few questions yet: > > > > > > 1) I saw that tucked away in section 10.3.2 item #3 is "key reuse" > > > but > > all it says is > > > "you have to promise not to do it". Is there any solid enforcement > > > for > > this, above > > > and beyond the "we found out about it" clause in section 13.1.5 > > > item > > > #4 > > or #6? > > > > > > 2) Is there a particular reason to not mention the prohibition on > > > key > > reuse in > > > section 9.5? > > > > > > 3) All of the EKU sections in Appendix B have a loophole for > > > companies > > that have > > > some sort of platform specific need to include other CA values, > > > but I > > don't know > > > what those use cases look like. From my standpoint it's more > > > secure for > > everyone > > > to have hard and fast rules for rigorous enforcement of security > > policies. As > > > written, such rigor goes out the window. Do you know of any good > > examples why > > > the loophole is necessary? > > > > > > > > > Bringing this discussion back to TurkTrust's request: > > > > > > 4) When might CABF approve the requirements and when might cert > > > issuers > > be > > > expected to comply? > > > > > > 5) What is reasonable to ask of TurkTrust to spell out in CP/CPS > > documents in > > > conjunction with this current request? I think it's reasonable to > > > ask > > for them to just > > > say what policies they plan to enforce. If they have no plans to > > > impose > > limits on > > > EKU's then just say it--give me a chance as an end user to make an > > informed > > > decision when I come across certs chained to their root. > > > > > > ? > > > > > > -------- Original Message -------- > > > From: Steve Roylance > > > Sent: Saturday, February 21, 2015 2:59 PM ? > > > > > > Hi Peter. > > > > > > I double checked, and everything looks good for the future (Please > > > see > > the > > > attached proposed Code Signing Requirements which has been > > > publically released by the CABForum) > > > > > > Specifically see Appendix B section F which covers MUST > > > requirements for > > CAs > > > and as such alleviates your concerns in that 'Server Auth' is not > > allowed to coexist > > > with code signing so it's not necessary to segregate by Root CA as > > > it's > > going to be > > > mandatory to segregate by issuing CA.. > > > > > > F. extkeyUsage (EKU) > > > The id-kp-codeSigning [RFC5280] value MUST be present. > > > The following EKUs MAY be present: documentSigning and emailProtection. > > > The value anyExtendedKeyUsage (2.5.29.37.0) MUST NOT be present. > > > Other values SHOULD NOT be present. If any other value is present, > > > the CA MUST have a business agreement with a Platform vendor > > > requiring that EKU > > in > > > order to issue a Platform-specific code signing certificate with > > > that > > EKU. > > > This extension SHOULD be marked non-critical. > > > The CA MUST set all other fields and extensions in accordance to > > > RFC > > 5280. > > > > > > Steve > > > > > > > -----Original Message----- > > > > From: Peter Kurrasch [mailto:fhw843 at gmail.com] > > > > Sent: 19 February 2015 13:49 > > > > To: Steve Roylance > > > > Cc: Kathleen Wilson; > > > > mozilla-dev-security-policy at lists.mozilla.org > > > > Subject: Re: TurkTrust Root Renewal Request > > > > > > > > My preference is to have key separation explicitly addressed by > > > > Mozilla and CABForum. From strictly a security perspective > > > > sharing keys is an all risk, no reward ?proposition. The only > > > > advantage I can see is in terms of convenience in different ways. > > > > > > > > I offer the following options for consideration: > > > > > > > > Bare minimum: for any ?root cert which intends to be used for > > > > both SSL and code, the CA shall provide a statement in the > > > > CP/CPS regarding any plans they have to limit end/leaf certs > > > > from having both EKU's. If it's just a policy thing or if an > > > > intermediate will provide a > > technical enforcement > > > mechanism, just write it down. > > > > If there is no plan/policy, just state that too. > > > > > > > > Minimum: enact a policy to disallow both EKU's from being used > > > > in a single end- entity cert. > > > > > > > > Better: separate intermediates are utilized for SSL and code. > > > > > > > > Ideal: separate roots for both SSL and code. > > > > > > > > The reason I favor something more than just policy statements > > > > are because people can make mistakes and should that happen it > > > > would be good to have the technical backstop. > > > > > > > > > > > > Kathleen--Would you feel comfortable asking TurkTrust to provide > > > > a statement clarifying their plans or intentions ?regarding these EKU's? > > > > > > > > Original Message > > > > From: Steve Roylance > > > > Sent: Wednesday, February 18, 2015 4:36 PM > > > > To: Peter Kurrasch > > > > Cc: Kathleen Wilson; > > > > mozilla-dev-security-policy at lists.mozilla.org > > > > Subject: Re: TurkTrust Root Renewal Request > > > > > > > > > > > > > On 18 Feb 2015, at 22:01, Peter Kurrasch wrote: > > > > > > > > > > ?Thanks for the update, Steve. Is there a requirement (current > > > > > or > > > > > forthcoming) for > > > > the CA to document how such segregation will be performed--or > > > > that there even is a plan to perform it? I didn't see any such > > > > language in the CP or CPS provided by TurkTrust so I don't know > > > > what they plan to > > do. > > > > > > > > > > > > > I don't know of any formal plans by CABForum to stipulate segregation. > > > > AFAIK it just happens naturally. Maybe if people feel strongly > > > > that can be looked at through enforced EKU usage in > > > > intermediates, however that sort of change would take far longer > > > > to enact due to the validity of intermediates being approx 10 > > > > years and the fact it's another > > slight against > > > RFC5280. > > > > > > > > > The risk I have in mind is when a server gets compromised thus > > > > > exposing the private keys. If the keys can be used to sign > > > > > objects I can then ?turn around and use them to sign malware and so forth. > > > > > What could be just a minor breach then becomes a bigger problem. > > > > > (I think we should assume that server compromises are a "regular" > > > > > occurrence even though we might not know how many or how often > > > > > or how serious they are.) > > > > > > > > > > > > > Here we are are all OK, as you are taking about end > > > > entities/leaf certificates and they always have the relevant EKU > > > > added by the CA so I don't see this as an issue. > > > > > > > > > I would argue that the best strategy is to have forced > > > > > separation at the root level, > > > > but I can appreciate that there are limits on the number of > > > > roots that ?CAs are allowed to submit. > > > > > > > > > > > > > > > Original Message > > > > > From: Steve Roylance > > > > > Sent: Wednesday, February 18, 2015 9:18 AM > > > > > To: Peter Kurrasch > > > > > Cc: Kathleen Wilson; > > > > > mozilla-dev-security-policy at lists.mozilla.org > > > > > Subject: RE: TurkTrust Root Renewal Request > > > > > > > > > > Hi Peter, > > > > > > > > > > In general this would be true if issuance of either or both > > > > > types of end entity > > > > certificate were directly from the same Root, however CA's, as > > > > best practice and from a product line perspective, segregate the > > > > usage of any end entity certificate types through an > > > > intermediate CA. In fact this is now mandated by the Baseline > > > > Requirements for SSL and forthcoming CodeSIgning requirements. > > > > Whilst any intermediate CA may or may not necessarily have EKUs > > > > which provide further protection, the additional hierarchical > > > > layer and key materials used offer the > > necessary > > > protection overall. > > > > > > > > > > The other reason is that Root Stores generally place a limit > > > > > on the number of > > > > Roots which can be entered so CA's need to be able to maximize > > > > their usage, especially where we are today with ongoing > > > > transitions in cryptography standards and key sizes. > > > > > > > > > > I hope that helps. > > > > > > > > > > Steve > > > > > > > > > >> -----Original Message----- > > > > >> From: dev-security-policy [mailto:dev-security-policy- > > > > >> bounces+steve.roylance=globalsign.com at lists.mozilla.org] On > > > > >> bounces+Behalf Of Peter > > > > >> Kurrasch > > > > >> Sent: 18 February 2015 14:31 > > > > >> To: Kathleen Wilson; > > > > >> mozilla-dev-security-policy at lists.mozilla.org > > > > >> Subject: Re: TurkTrust Root Renewal Request > > > > >> > > > > >> ?Allowing a single cert to be used for both websites and code > > > > >> signing is a dangerous proposition. What is the current > > > > >> thinking among the > > > > community? > > > > >> > > > > >> > > > > >> Original Message > > > > >> From: Kathleen Wilson > > > > >> Sent: Thursday, February 12, 2015 12:31 PM > > > > >> To: mozilla-dev-security-policy at lists.mozilla.org > > > > >> Subject: TurkTrust Root Renewal Request > > > > >> > > > > >> TurkTrust has applied to include the SHA-256 "T?RKTRUST > > > > >> Elektronik Sertifika Hizmet Sa?lay?c?s? H5" and "T?RKTRUST > > > > >> Elektronik Sertifika Hizmet Sa?lay?c?s? H6" root > > > > >> certificates; turn on the Websites trust bit for both roots, > > > > >> turn on the Code Signing trust bit for the H5 root, and > > > > >> enable > > > > EV treatment for the H6 root. > > > > >> TurkTrust's SHA-1 root certificates were included in NSS via > > > > >> Bugzilla Bug > > > > >> #380635 and Bug #433845. > > > > >> > > > > >> ? > > > > >> _______________________________________________ > > > > >> dev-security-policy mailing list > > > > >> dev-security-policy at lists.mozilla.org > > > > >> https://lists.mozilla.org/listinfo/dev-security-policy > > > > _______________________________________________ > > dev-security-policy mailing list > > dev-security-policy at lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-security-policy > > > > > _______________________________________________ > dev-security-policy mailing list > dev-security-policy at lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4954 bytes Desc: not available Url : https://cabforum.org/pipermail/public/attachments/20150225/8a8894ff/attachment.bin From i-barreira at izenpe.net Wed Feb 25 09:30:56 2015 From: i-barreira at izenpe.net (=?UTF-8?B?IkJhcnJlaXJhIElnbGVzaWFzLCBJw7FpZ28i?=) Date: Wed, 25 Feb 2015 17:30:56 +0100 Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline RequirementstoRFC3647 Framework Message-ID: <14g8suajpk83brdupqug404t.1424881854376@email.android.com> Yes, i know. ?I've been working on it :-) My concern is when i had to update the EN and the time we can have to do it. OTOH, in ETSI we're also thinking on the same idea Enviado de Samsung Mobile -------- Mensaje original -------- De: Ben Wilson Fecha: Para: i-barreira at izenpe.net,kirk_hall at trendmicro.com,Dean_Coclin at symantec.com,public at cabforum.org Asunto: RE: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements toRFC3647 Framework I?igo, The Working Group did consider your previous comments during its deliberations.? We?re willing to help out in whatever way we can with transitioning the necessary cross-references in ETSI documents to the new section numbers.? Once this has been accomplished, though, I don?t? think we?ll be doing this kind of moving sections around again.? Ben ? From: i-barreira at izenpe.net [mailto:i-barreira at izenpe.net] Sent: Wednesday, February 25, 2015 12:55 AM To: kirk_hall at trendmicro.com; Dean_Coclin at symantec.com; Ben Wilson; public at cabforum.org Subject: RE: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC3647 Framework ? This is something that I complained time ago basically due to the timing needed to adopt the EN, which is not the same than the TS. BTW, ETSI also mandates that the CP/CPS shall be structured according to the RFC 3647 ? ? I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 ? ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. ? De: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] En nombre de kirk_hall at trendmicro.com Enviado el: martes, 24 de febrero de 2015 18:56 Para: Dean Coclin; Ben Wilson; CABFPub Asunto: Re: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC3647 Framework ? Fair point, but here is another consideration. ?Right now, all the WebTrust (and ETSI?) documents are laid out more or less in the same order as the current BRs and EVGL, and include references to the current numbering.? If all numbering is changed, they will have to amend the WebTrust (and ETSI?) internal references ? maybe not a big deal ? but the order of the WebTrust requirements will no longer correspond to the order of the BRs. ? From: Dean Coclin [mailto:Dean_Coclin at symantec.com] Sent: Tuesday, February 24, 2015 8:59 AM To: Kirk Hall (RD-US); Ben Wilson; CABFPub Subject: RE: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework ? Some of the beneficiaries are Browser root programs and relying parties. Having the BRs in this format makes it easier for Jody, Kathleen and others to review CPS? and compare to the sections in the BRs for compliance. ? ? Jeremy has already taken a pass at doing this and a draft has been circulated. ? Dean ? From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of kirk_hall at trendmicro.com Sent: Tuesday, February 24, 2015 11:52 AM To: Ben Wilson; CABFPub Subject: Re: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework ? Ben ? first of all, thanks for the hard work on this one. ? I?m trying to figure out the benefit of locking the Forum into the RFC 3647 framework for the purpose of listing BR requirements.? Is there really a benefit?? Does it add to understanding and make CA compliance any easier?? Or will it force us to put rules in odd places that actually make understanding a bit harder? ? I note the BR 8.2 already requires CAs to put their CPS into the format of RFC 2527 or 3647.? See the first two sections of BR 8.2 below.? That can facilitate comparison between the CPSs of different CAs, if anyone cares to do that.? But is there any corresponding benefit from restructuring the BRs to an RFC 3647 format?? What if a rule spans two or more different sections of the RFC 3647 format? ? I see that in your new organization of the BRs you have moved old BR 8.2.2 to a new Section 2.1 Repositories, not to new Section 2.2 Publication of Information.? How did you make that choice?? And is there an expectation that CAs will publish their CAA disclosure in new Sec. 2.2 of their CPS? ? I?m just afraid we will be handcuffing ourselves with these changes, and that there could be errors in internal cross-references.? It is also a lot of work for everyone to review a complete rewrite of the BRs. ? Can you give us a convincing argument of why this is worth doing?? Sorry I didn?t ask this question earlier, but I hadn?t really understood this was what the working group was doing ? I thought you were just looking for GAPS in the BRs as compared to the RFC 3647 where we could ADD new provisions to the BRs ? not a wholesale restructuring of the BRs. ? Thanks. ? BR 8.2.2 Disclosure The CA SHALL publicly disclose its Certificate Policy and/or Certification Practice Statement through an appropriate and readily accessible online means that is available on a 24x7 basis. The CA SHALL publicly disclose its CA business practices to the extent required by the CA?s selected audit scheme (see Section 17.1). The disclosures MUST include all the material required by RFC 2527 or RFC 3647, and MUST be structured in accordance with either RFC 2527 or RFC 3647. Effective as of 15 April 2015, section 4.2 of a CA's Certificate Policy and/or Certification Practice Statement (section 4.1 for CAs still conforming to RFC 2527) SHALL state whether the CA reviews CAA Records, and if so, the CA?s policy or practice on processing CAA Records for Fully Qualified Domain Names. The CA SHALL log all actions taken, if any, consistent with its processing practice. ? From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ben Wilson Sent: Tuesday, February 24, 2015 7:22 AM To: CABFPub Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework ? Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework The Certificate Policy Review Working Group was chartered by Ballot 128 to (i) consider existing and proposed standards, (ii) create a list of potential improvements based on the considered standards that improve the existing CAB Forum work product, (iii) evaluate the transition to a 3647 format based on the amount [of work involved]. One deliverable of the CP Review WG was to propose a ballot to improve CA infrastructure based on existing standards and documents and recommend whether to finish the 3647 conversion presented by Jeremy Rowley in January 2014. The CP Review WG has met and concluded that the best path forward for the Forum is to complete a conversion to the RFC 3647 for the Baseline Requirements with an initial step that merely moves existing content from the Baseline Requirements and the Network and Certificate System Security Requirements into the RFC 3647 format. Attached is an RFC-3647-formatted Certificate Policy for Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates. Comments embedded in the document contain either the source of the text (for content copied from the Baseline Requirements) or the current text (for provisions incorporated by reference from the Network and Certificate System Security Requirements ("NetSec"). It was decided that it was better to incorporate the NetSec requirements by reference rather than copying and pasting them in. In some limited instances the phrase "these Requirements" has been replaced with "this CP." However, "these Requirements" is mostly left in to preserve consistency with the current Baseline Requirements. Ben Wilson of DigiCert made the following motion, from and from have endorsed it. Motion Begins Be it resolved that the CA / Browser Forum adopts the attached CA/B Forum Certificate Policy v.1.2.5, effective immediately. Motion Ends The review period for this ballot shall commence at 2200 UTC on March 2015 and will close at 2200 UTC on March 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on March 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the ballot must indicate a clear ?yes? in the response. A vote against the ballot must indicate a clear ?no? in the response. A vote to abstain must indicate a clear ?abstain? in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/. In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and more than one half of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members? at least nine members must participate in the ballot, either by voting in favor, voting against, or by abstaining for the vote to be valid. ? ? TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. ? ? TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. ? -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150225/f8806d27/attachment-0001.html From kirk_hall at trendmicro.com Wed Feb 25 10:51:49 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Wed, 25 Feb 2015 17:51:49 +0000 Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC3647 Framework In-Reply-To: <265dc2dc2f67410bb12f97b420b7c4dc@EX2.corp.digicert.com> References: <763539E260C37C46A0D6B340B5434C3B0AE7EA23@AEX06.ejsarea.net> <265dc2dc2f67410bb12f97b420b7c4dc@EX2.corp.digicert.com> Message-ID: Ben, out of curiosity ? did the Working Group consider simply making cross reference tables correlating the current BRs (and EVGL) and the RFC 3647 CPS framework? So that if a browser wanted to see which BR sections were relevant to a CPS in RFC 3647 format (and vice versa), they could just consult the table? It seems that would have been a simpler approach, and would recognize that a lot of the BRs are not relevant to a CA?s CPS or CPS format. From: Ben Wilson [mailto:ben.wilson at digicert.com] Sent: Wednesday, February 25, 2015 8:16 AM To: i-barreira at izenpe.net; Kirk Hall (RD-US); Dean_Coclin at symantec.com; public at cabforum.org Subject: RE: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC3647 Framework I?igo, The Working Group did consider your previous comments during its deliberations. We?re willing to help out in whatever way we can with transitioning the necessary cross-references in ETSI documents to the new section numbers. Once this has been accomplished, though, I don?t? think we?ll be doing this kind of moving sections around again. Ben From: i-barreira at izenpe.net [mailto:i-barreira at izenpe.net] Sent: Wednesday, February 25, 2015 12:55 AM To: kirk_hall at trendmicro.com; Dean_Coclin at symantec.com; Ben Wilson; public at cabforum.org Subject: RE: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC3647 Framework This is something that I complained time ago basically due to the timing needed to adopt the EN, which is not the same than the TS. BTW, ETSI also mandates that the CP/CPS shall be structured according to the RFC 3647 I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 [Descripci?n: cid:image001.png at 01CE3152.B4804EB0] ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. De: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] En nombre de kirk_hall at trendmicro.com Enviado el: martes, 24 de febrero de 2015 18:56 Para: Dean Coclin; Ben Wilson; CABFPub Asunto: Re: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC3647 Framework Fair point, but here is another consideration. Right now, all the WebTrust (and ETSI?) documents are laid out more or less in the same order as the current BRs and EVGL, and include references to the current numbering. If all numbering is changed, they will have to amend the WebTrust (and ETSI?) internal references ? maybe not a big deal ? but the order of the WebTrust requirements will no longer correspond to the order of the BRs. From: Dean Coclin [mailto:Dean_Coclin at symantec.com] Sent: Tuesday, February 24, 2015 8:59 AM To: Kirk Hall (RD-US); Ben Wilson; CABFPub Subject: RE: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Some of the beneficiaries are Browser root programs and relying parties. Having the BRs in this format makes it easier for Jody, Kathleen and others to review CPS? and compare to the sections in the BRs for compliance. Jeremy has already taken a pass at doing this and a draft has been circulated. Dean From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of kirk_hall at trendmicro.com Sent: Tuesday, February 24, 2015 11:52 AM To: Ben Wilson; CABFPub Subject: Re: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Ben ? first of all, thanks for the hard work on this one. I?m trying to figure out the benefit of locking the Forum into the RFC 3647 framework for the purpose of listing BR requirements. Is there really a benefit? Does it add to understanding and make CA compliance any easier? Or will it force us to put rules in odd places that actually make understanding a bit harder? I note the BR 8.2 already requires CAs to put their CPS into the format of RFC 2527 or 3647. See the first two sections of BR 8.2 below. That can facilitate comparison between the CPSs of different CAs, if anyone cares to do that. But is there any corresponding benefit from restructuring the BRs to an RFC 3647 format? What if a rule spans two or more different sections of the RFC 3647 format? I see that in your new organization of the BRs you have moved old BR 8.2.2 to a new Section 2.1 Repositories, not to new Section 2.2 Publication of Information. How did you make that choice? And is there an expectation that CAs will publish their CAA disclosure in new Sec. 2.2 of their CPS? I?m just afraid we will be handcuffing ourselves with these changes, and that there could be errors in internal cross-references. It is also a lot of work for everyone to review a complete rewrite of the BRs. Can you give us a convincing argument of why this is worth doing? Sorry I didn?t ask this question earlier, but I hadn?t really understood this was what the working group was doing ? I thought you were just looking for GAPS in the BRs as compared to the RFC 3647 where we could ADD new provisions to the BRs ? not a wholesale restructuring of the BRs. Thanks. BR 8.2.2 Disclosure The CA SHALL publicly disclose its Certificate Policy and/or Certification Practice Statement through an appropriate and readily accessible online means that is available on a 24x7 basis. The CA SHALL publicly disclose its CA business practices to the extent required by the CA?s selected audit scheme (see Section 17.1). The disclosures MUST include all the material required by RFC 2527 or RFC 3647, and MUST be structured in accordance with either RFC 2527 or RFC 3647. Effective as of 15 April 2015, section 4.2 of a CA's Certificate Policy and/or Certification Practice Statement (section 4.1 for CAs still conforming to RFC 2527) SHALL state whether the CA reviews CAA Records, and if so, the CA?s policy or practice on processing CAA Records for Fully Qualified Domain Names. The CA SHALL log all actions taken, if any, consistent with its processing practice. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ben Wilson Sent: Tuesday, February 24, 2015 7:22 AM To: CABFPub Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework The Certificate Policy Review Working Group was chartered by Ballot 128 to (i) consider existing and proposed standards, (ii) create a list of potential improvements based on the considered standards that improve the existing CAB Forum work product, (iii) evaluate the transition to a 3647 format based on the amount [of work involved]. One deliverable of the CP Review WG was to propose a ballot to improve CA infrastructure based on existing standards and documents and recommend whether to finish the 3647 conversion presented by Jeremy Rowley in January 2014. The CP Review WG has met and concluded that the best path forward for the Forum is to complete a conversion to the RFC 3647 for the Baseline Requirements with an initial step that merely moves existing content from the Baseline Requirements and the Network and Certificate System Security Requirements into the RFC 3647 format. Attached is an RFC-3647-formatted Certificate Policy for Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates. Comments embedded in the document contain either the source of the text (for content copied from the Baseline Requirements) or the current text (for provisions incorporated by reference from the Network and Certificate System Security Requirements ("NetSec"). It was decided that it was better to incorporate the NetSec requirements by reference rather than copying and pasting them in. In some limited instances the phrase "these Requirements" has been replaced with "this CP." However, "these Requirements" is mostly left in to preserve consistency with the current Baseline Requirements. Ben Wilson of DigiCert made the following motion, from and from have endorsed it. Motion Begins Be it resolved that the CA / Browser Forum adopts the attached CA/B Forum Certificate Policy v.1.2.5, effective immediately. Motion Ends The review period for this ballot shall commence at 2200 UTC on March 2015 and will close at 2200 UTC on March 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on March 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the ballot must indicate a clear ?yes? in the response. A vote against the ballot must indicate a clear ?no? in the response. A vote to abstain must indicate a clear ?abstain? in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/. In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and more than one half of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members? at least nine members must participate in the ballot, either by voting in favor, voting against, or by abstaining for the vote to be valid. TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
-------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150225/ee092f2e/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 19121 bytes Desc: image001.png Url : https://cabforum.org/pipermail/public/attachments/20150225/ee092f2e/attachment-0001.png From dosheehy at deloitte.ca Wed Feb 25 11:07:13 2015 From: dosheehy at deloitte.ca (Sheehy, Don (CA - Toronto)) Date: Wed, 25 Feb 2015 18:07:13 +0000 Subject: [cabfpub] When did the WebTrust/ETSI BR audit requirement become mandatory? In-Reply-To: <54E7AF26.8000706@startcom.org> References: <54E7A2AE.2040501@startcom.org> <54E7AF26.8000706@startcom.org> Message-ID: If one remembers the discussion that we had at the face to face and others , one would remember that there are CAs that are NOT public and NOT part of the trusted root programs that do not require the additional baseline audit. Given that, a merger into one set of standards is unlikely in the near future ( unless we decide to create WebTrust Pubic and non-public versions ? but that is unlikely). So at present you need to meet WebTrust and WebTrust BR + WebTrust EV ( If applicable). If your reporting year starts after last June 30 you will also need to meet the Network Security requirements. Don Donald E. Sheehy, CPA, CA, CISA, CRISC, CIPP/C, CITP Partner | Enterprise Risk Deloitte From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Eddy Nigg Sent: Friday, February 20, 2015 5:03 PM To: kirk_hall at trendmicro.com; i-barreira; Peter Bowen; public at cabforum.org Subject: Re: [cabfpub] When did the WebTrust/ETSI BR audit requirement become mandatory? On 02/20/2015 11:45 PM, kirk_hall at trendmicro.com wrote: When you say ?why? ? do you mean ?is regular WebTrust still required?? (it is, along with BR WebTrust), or are you suggesting that regular WebTrust should no longer be a requirement, just BR WebTrust? I certainly would expect that this will become one (basic) audit eventually (and EV and others optional). -- Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. XMPP: startcom at startcom.org Blog: Join the Revolution! Twitter: Follow Me Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s), are confidential, and may be privileged. If you are not the intended recipient, you are hereby notified that any review, retransmission, conversion to hard copy, copying, circulation or other use of this message and any attachments is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, and delete this message and any attachments from your system. Thank You If you do not wish to receive future commercial electronic messages from Deloitte, forward this email to unsubscribe at deloitte.ca Avertissement de confidentialit?: Ce message, ainsi que toutes ses pi?ces jointes, est destin? exclusivement au(x) destinataire(s) pr?vu(s), est confidentiel et peut contenir des renseignements privil?gi?s. Si vous n??tes pas le destinataire pr?vu de ce message, nous vous avisons par la pr?sente que la modification, la retransmission, la conversion en format papier, la reproduction, la diffusion ou toute autre utilisation de ce message et de ses pi?ces jointes sont strictement interdites. Si vous n??tes pas le destinataire pr?vu, veuillez en aviser imm?diatement l?exp?diteur en r?pondant ? ce courriel et supprimez ce message et toutes ses pi?ces jointes de votre syst?me. Merci. Si vous ne voulez pas recevoir d?autres messages ?lectroniques commerciaux de Deloitte ? l?avenir, veuillez envoyer ce courriel ? l?adresse unsubscribe at deloitte.ca -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150225/264b0493/attachment.html From ben.wilson at digicert.com Wed Feb 25 11:18:37 2015 From: ben.wilson at digicert.com (Ben Wilson) Date: Wed, 25 Feb 2015 18:18:37 +0000 Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC3647 Framework In-Reply-To: References: <763539E260C37C46A0D6B340B5434C3B0AE7EA23@AEX06.ejsarea.net> <265dc2dc2f67410bb12f97b420b7c4dc@EX2.corp.digicert.com> Message-ID: <19c62260d34c43c1bd93a1231808ed2d@EX2.corp.digicert.com> Yes ? and those charts were distributed. From: kirk_hall at trendmicro.com [mailto:kirk_hall at trendmicro.com] Sent: Wednesday, February 25, 2015 10:52 AM To: Ben Wilson; i-barreira at izenpe.net; Dean_Coclin at symantec.com; public at cabforum.org Subject: RE: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC3647 Framework Ben, out of curiosity ? did the Working Group consider simply making cross reference tables correlating the current BRs (and EVGL) and the RFC 3647 CPS framework? So that if a browser wanted to see which BR sections were relevant to a CPS in RFC 3647 format (and vice versa), they could just consult the table? It seems that would have been a simpler approach, and would recognize that a lot of the BRs are not relevant to a CA?s CPS or CPS format. From: Ben Wilson [mailto:ben.wilson at digicert.com] Sent: Wednesday, February 25, 2015 8:16 AM To: i-barreira at izenpe.net ; Kirk Hall (RD-US); Dean_Coclin at symantec.com ; public at cabforum.org Subject: RE: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC3647 Framework I?igo, The Working Group did consider your previous comments during its deliberations. We?re willing to help out in whatever way we can with transitioning the necessary cross-references in ETSI documents to the new section numbers. Once this has been accomplished, though, I don?t? think we?ll be doing this kind of moving sections around again. Ben From: i-barreira at izenpe.net [mailto:i-barreira at izenpe.net] Sent: Wednesday, February 25, 2015 12:55 AM To: kirk_hall at trendmicro.com ; Dean_Coclin at symantec.com ; Ben Wilson; public at cabforum.org Subject: RE: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC3647 Framework This is something that I complained time ago basically due to the timing needed to adopt the EN, which is not the same than the TS. BTW, ETSI also mandates that the CP/CPS shall be structured according to the RFC 3647 I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. De: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] En nombre de kirk_hall at trendmicro.com Enviado el: martes, 24 de febrero de 2015 18:56 Para: Dean Coclin; Ben Wilson; CABFPub Asunto: Re: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC3647 Framework Fair point, but here is another consideration. Right now, all the WebTrust (and ETSI?) documents are laid out more or less in the same order as the current BRs and EVGL, and include references to the current numbering. If all numbering is changed, they will have to amend the WebTrust (and ETSI?) internal references ? maybe not a big deal ? but the order of the WebTrust requirements will no longer correspond to the order of the BRs. From: Dean Coclin [mailto:Dean_Coclin at symantec.com] Sent: Tuesday, February 24, 2015 8:59 AM To: Kirk Hall (RD-US); Ben Wilson; CABFPub Subject: RE: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Some of the beneficiaries are Browser root programs and relying parties. Having the BRs in this format makes it easier for Jody, Kathleen and others to review CPS? and compare to the sections in the BRs for compliance. Jeremy has already taken a pass at doing this and a draft has been circulated. Dean From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of kirk_hall at trendmicro.com Sent: Tuesday, February 24, 2015 11:52 AM To: Ben Wilson; CABFPub Subject: Re: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Ben ? first of all, thanks for the hard work on this one. I?m trying to figure out the benefit of locking the Forum into the RFC 3647 framework for the purpose of listing BR requirements. Is there really a benefit? Does it add to understanding and make CA compliance any easier? Or will it force us to put rules in odd places that actually make understanding a bit harder? I note the BR 8.2 already requires CAs to put their CPS into the format of RFC 2527 or 3647. See the first two sections of BR 8.2 below. That can facilitate comparison between the CPSs of different CAs, if anyone cares to do that. But is there any corresponding benefit from restructuring the BRs to an RFC 3647 format? What if a rule spans two or more different sections of the RFC 3647 format? I see that in your new organization of the BRs you have moved old BR 8.2.2 to a new Section 2.1 Repositories, not to new Section 2.2 Publication of Information. How did you make that choice? And is there an expectation that CAs will publish their CAA disclosure in new Sec. 2.2 of their CPS? I?m just afraid we will be handcuffing ourselves with these changes, and that there could be errors in internal cross-references. It is also a lot of work for everyone to review a complete rewrite of the BRs. Can you give us a convincing argument of why this is worth doing? Sorry I didn?t ask this question earlier, but I hadn?t really understood this was what the working group was doing ? I thought you were just looking for GAPS in the BRs as compared to the RFC 3647 where we could ADD new provisions to the BRs ? not a wholesale restructuring of the BRs. Thanks. BR 8.2.2 Disclosure The CA SHALL publicly disclose its Certificate Policy and/or Certification Practice Statement through an appropriate and readily accessible online means that is available on a 24x7 basis. The CA SHALL publicly disclose its CA business practices to the extent required by the CA?s selected audit scheme (see Section 17.1). The disclosures MUST include all the material required by RFC 2527 or RFC 3647, and MUST be structured in accordance with either RFC 2527 or RFC 3647. Effective as of 15 April 2015, section 4.2 of a CA's Certificate Policy and/or Certification Practice Statement (section 4.1 for CAs still conforming to RFC 2527) SHALL state whether the CA reviews CAA Records, and if so, the CA?s policy or practice on processing CAA Records for Fully Qualified Domain Names. The CA SHALL log all actions taken, if any, consistent with its processing practice. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ben Wilson Sent: Tuesday, February 24, 2015 7:22 AM To: CABFPub Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework The Certificate Policy Review Working Group was chartered by Ballot 128 to (i) consider existing and proposed standards, (ii) create a list of potential improvements based on the considered standards that improve the existing CAB Forum work product, (iii) evaluate the transition to a 3647 format based on the amount [of work involved]. One deliverable of the CP Review WG was to propose a ballot to improve CA infrastructure based on existing standards and documents and recommend whether to finish the 3647 conversion presented by Jeremy Rowley in January 2014. The CP Review WG has met and concluded that the best path forward for the Forum is to complete a conversion to the RFC 3647 for the Baseline Requirements with an initial step that merely moves existing content from the Baseline Requirements and the Network and Certificate System Security Requirements into the RFC 3647 format. Attached is an RFC-3647-formatted Certificate Policy for Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates. Comments embedded in the document contain either the source of the text (for content copied from the Baseline Requirements) or the current text (for provisions incorporated by reference from the Network and Certificate System Security Requirements ("NetSec"). It was decided that it was better to incorporate the NetSec requirements by reference rather than copying and pasting them in. In some limited instances the phrase "these Requirements" has been replaced with "this CP." However, "these Requirements" is mostly left in to preserve consistency with the current Baseline Requirements. Ben Wilson of DigiCert made the following motion, from and from have endorsed it. Motion Begins Be it resolved that the CA / Browser Forum adopts the attached CA/B Forum Certificate Policy v.1.2.5, effective immediately. Motion Ends The review period for this ballot shall commence at 2200 UTC on March 2015 and will close at 2200 UTC on March 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on March 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the ballot must indicate a clear ?yes? in the response. A vote against the ballot must indicate a clear ?no? in the response. A vote to abstain must indicate a clear ?abstain? in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/. In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and more than one half of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members? at least nine members must participate in the ballot, either by voting in favor, voting against, or by abstaining for the vote to be valid. TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150225/225332eb/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 19121 bytes Desc: not available Url : https://cabforum.org/pipermail/public/attachments/20150225/225332eb/attachment-0001.png -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4954 bytes Desc: not available Url : https://cabforum.org/pipermail/public/attachments/20150225/225332eb/attachment-0001.bin From Dean_Coclin at symantec.com Wed Feb 25 16:41:10 2015 From: Dean_Coclin at symantec.com (Dean Coclin) Date: Wed, 25 Feb 2015 15:41:10 -0800 Subject: [cabfpub] DRAFT Minutes of CA/B Forum meeting Feb 19, 2015 Message-ID: <14D026C7F297AD44AC82578DD818CDD038EF4A9BCA@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> Attendees: Dean Coclin, Doug Beattie, Kirk Hall, Bruce Morton, Rick Andrews, Ben Wilson, Eddy Nigg, Volkan (TurkTrust), Robin Alden, Mads (BuyPass), Tim Shirley, Wayne Thayer, Connie Enke, Atilla Biller, Gerv Markham, Jeremy Rowley, Atsushi Inaba, Sisel (BuyPass), Kubra (TurkTrust), Davut (E-Tugra), Cecilia Kam. 1. Antitrust Statement was read. 2. Minutes of Feb 5th meeting were approved. Ben to post to website 3. Ballot Status: Ballots 143 and 144 were approved. Ben will update the website to reflect the new working group name. Ballot 144 requires changes to the EV Guidelines which Jeremy will amend and update. There were a large number of abstentions on ballot 144. Jeremy said that many people may have used that to help the ballot meet quorum and that they didn't have a strong interest in the ballot. 4. IPv6: Ryan put out a draft ballot on this topic. Dean sent out the results of a survey of CASC members on this topic which Gerv said was very useful. Gerv said it would be good for the Internet for the Forum to support IPv6 and that the ballot provides a generous amount of time to do this. Jeremy said some CAs use a CDN and that may not support IPv6. Wayne updated the group stating that GoDaddy can now support it. Rick stated that for the sake of a complete argument, why not let market forces control this? Let people choose a CA that supports it if they want. Gerv said that doesn't work because a user or third party doesn't have that choice. Rick said most browsers don't fail on OCSP failure so it's not blocking anything. 5. Membership Application of TrustCor Systems: The Forum received an application for membership from this entity. They have a WebTrust report from Princeton Audit Group which stated they are not actively issuing certificates yet. Dean sent the applicant a note asking for a site that uses one of their certs. He also sent a note to Don Sheehy about the auditor qualifications. Kirk asked if they have a BR audit which Dean will ask the applicant. Kirk suggested that if they don't fully qualify, they could be granted observer status. Wayne asked if we should update the membership rules to require a BR audit. Jeremy agreed that this should be updated and that when we do a bylaw update, this should be undertaken. Wayne also said that everyone on the Management list is also on the Questions list. 6. New Ballots: Operational Existence (145) and pre-ballot Domain Validation (146). Cecilia and Kirk said that the EV Working group proposed ballot 145 for Government entity purposes. Discussion period for 145 starts today. Ballot 146 is a proposal to eliminate the "any other method (7)" for domain validation. Jeremy said they are soliciting comments and should have a proposal ready by the face to face meeting. Kirk encouraged others to bring forward any other verification methods for domain validation. Jeremy said there is another ballot coming forward on using attorney opinion letters for legal existence. This should be out before the face to face meeting. 7. Working group publicity: To date, the working group mailing lists have not been public. The bylaws state (in one place) that minutes and agendas of working groups should be made public and (in another place) that the lists should be managed in the same fashion as the public list. Gerv said that some working groups weren't public because they were in existence before the bylaws. But we should make the archives publicly accessible. Wayne said we can publish the URL to subscribe to the list. Gerv said that when groups are re-chartered, we should create a new list to not violate anyone's expectation of privacy from the old list. Regarding the new Validation Working Group, Gerv suggested we re-subscribe all the old members to the new list and state that it would be made public. It has to be clear that active participation is limited to those that have signed the IPR. 8. EV WG update: Per #6 above. 9. Code Signing update: Public draft of BR issued. Some comments received which the working group will address before the face to face meeting. 10. Policy Review WG: A ballot will be proposed for the reconfiguration of the BRs to RFC 3647 format. 11. Info Sharing WG: Hasn't met in a while but needs to get back together soon. Members have had conflicts during the meeting time. 12. Any other business: Kirk said we have 32 members coming to the F2F meeting. Send agenda items to Dean. 13. Next meeting will be March 5th. Dean Coclin CA/B Forum Chair -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150225/910b1fe9/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6130 bytes Desc: not available Url : https://cabforum.org/pipermail/public/attachments/20150225/910b1fe9/attachment.bin From jeremy.rowley at digicert.com Wed Feb 25 17:28:51 2015 From: jeremy.rowley at digicert.com (Jeremy Rowley) Date: Thu, 26 Feb 2015 00:28:51 +0000 Subject: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc In-Reply-To: References: <763539E260C37C46A0D6B340B5434C3B0ACD81A9@AEX06.ejsarea.net> A <763539E260C37C46A0D6B340B5434C3B0ADAE0EB@AEX06.ejsarea.net> Message-ID: <2639008ebb224f54be8be02132375681@EX2.corp.digicert.com> Should this be added to the BRs instead of code signing? For auditor qualifications, we just incorporate the auditor qualifications by reference. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jody Cloutier Sent: Friday, February 13, 2015 1:28 PM To: i-barreira at izenpe.net; public at cabforum.org Subject: Re: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Thank you, Inigo, What seems to be happening is that organizations are applying the ETSI standard in cases in which either there is no National Standards Body, or where the national standards body does not certify the company. Building on the scenario below, Audit Co is not recognized by ISRAC, but Auditor Jones has a CISP certification, which I've already confirmed with ETSI is not sufficient. I think what would help here is to make the requirement much more specific: A Qualified Auditor is limited to an auditor that is employed by a company that is certified by a National Authority listed in either the Members or Associate Members link. This, much simplified language, seems to be what you are saying below, but the current language is such that Audit Co can argue that it can issue an ETSI audit because it's company is certified by another national authority that's not listed on the ETSI webpages anywhere. Jody From: i-barreira at izenpe.net [mailto:i-barreira at izenpe.net] Sent: Friday, February 13, 2015 12:16 AM To: Jody Cloutier; public at cabforum.org Subject: RE: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Dear Jody, I understand your concern because it?s not easy for you to manage all possible combinations regarding ETSI audits in different countries so will try to clarify your example. First of all, no AuditCo has to be member of ETSI, AuditCo can perform ETSI accredited audits without being member of ETSI, they only need to be accredited in their country as stated in Annex E requirements. So, For example, * Company A is a commercial CA that operates in Israel * Auditor Jones works for AuditCo, which is based in Israel * AuditCo is certified by some governmental agency as a qualified auditor IB--> AuditCo has to be accredited under its National Accreditation Body according to ISO 17021. In the case of Israel, to follow the example, in the associated members tab of the EA, you can find the Israeli accreditation body, called ISRAC. Then AuditCo should be listed there and meeting the requirements to perform ETSI audits according to the national scheme indicated by ISRAC * AuditCo is not an ETSI Member or Associate Member IB --> this is not necessary. No need to be an ETSI member to perform ETSI audits * Auditor Jones audits Company A using the ETSI 102042 standard, and Company A sends the auditor's attestation letter to Microsoft as evidence that Company A complied with the Program's requirements. IB--> this is perfectly valid if AuditCo is listed in ISRAC and is allowed to perform ETSI audits. Of course Auditor Jones has to be also accredited to perform these kind of audits, has to be "qualified", so it?s not only the company but also the auditor, but that?s an internal task of the AuditCo. Regarding of being member of not, this is voluntary, they can join ETSI or not and don?t think that solve the problem because joining ETSI does not mean that you?re "qualified" or "accredited" to perform an ETSI audit, it?s just indicate that you belong to a club for example. And of course, if company A needs an auditing company accredited in Israel and there?s none, they can look for in other countries. For example, in Spain there?s no accredited auditing bodies to perform ETSI audits listed in our NAB, called ENAC, so, we, Izenpe, had to look for another option. So, we contacted for the first 6 years with KPMG in the Netherlands, and the last 3, with TUV IT in Germany. And Izenpe has an accredited ETSI audits according to the, right now, German national scheme and we?re listed in Germany. We?ll debate this within ETSI ESI trying to find an easier solution. Regards I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 [Descripci?n: cid:image001.png at 01CE3152.B4804EB0] ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. De: Jody Cloutier [mailto:jodycl at microsoft.com] Enviado el: mi?rcoles, 11 de febrero de 2015 0:32 Para: Barreira Iglesias, I?igo; public at cabforum.org Asunto: RE: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Thank you, Inigo. I think the problem is that, under ETSI, it's difficult to discern what an "equivalent national scheme" is. This sets up the scenario in which an auditor is employed by an organization that is recognized somehow by the government, but is not affiliated with an ETSI member organization (http://www.european-accreditation.org/home ). Microsoft does not know whether or not this auditor is qualified or not. For example, * Company A is a commercial CA that operates in Israel * Auditor Jones works for AuditCo, which is based in Israel * AuditCo is certified by some governmental agency as a qualified auditor * AuditCo is not an ETSI Member or Associate Member * Auditor Jones audits Company A using the ETSI 102042 standard, and Company A sends the auditor's attestation letter to Microsoft as evidence that Company A complied with the Program's requirements. In this scenario, how does Microsoft know that Auditor Jones conducted a proper audit without expending significant resources to determine whether and according to what standard AuditCo and Auditor Jones was certified? Microsoft believes that it would be simpler if the requirements were that the Auditor must work for a company that is affiliated with an ETSI-approved member organization. If Company A needs an auditor and there is no qualified auditor in Israel, the company can use an auditor from a member organization via the cross-border conformity rules. Unless I am fundamentally misunderstanding the rules, the above is something that Microsoft is presently struggling with, and we'd like to try to make the rules easier to understand for potential partners and ourselves. Jody Cloutier Senior Security Program Manager Microsoft Trusted Root Certificate Program jody.cloutier at microsoft.com 425.443.8922 Operating Systems Group Global Risk and Compliance [https://brandtools.microsoft.com/Style%20Library/BT/Images/MicrosoftMasterLogo.png] From: i-barreira at izenpe.net [mailto:i-barreira at izenpe.net] Sent: Tuesday, February 10, 2015 3:09 AM To: Jody Cloutier; public at cabforum.org Subject: RE: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Hi Jody, Regarding your comment on ETSI audits, I have to say that the ETSI audits shall be performed by accredited auditors as mentioned in Annex E of the current ETSI TS 102 042. ETSI audits performed by not accredited auditors shall be considered invalid. Microsoft is accepting ETSI audits since the very beginning in its root program requirements indicating this requirement. ETSI is providing a list of accredited auditors as mere information because has to be maintained by every NAB (National Accreditation Body). It?s true that this has to be improved regarding the new regulation 910/2014 and the new ENs and will take some time, but at the moment, it?s clearly stated that the audits shall be performed by accredited auditors. Don?t hesitate in contacting me for any additional information or help. Sometimes I?ve received some emails from Tom or Kelvin asking for the qualification of some audits, so, as say, you can contact me regarding this issue. Regards I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 [Descripci?n: cid:image001.png at 01CE3152.B4804EB0] ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. De: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] En nombre de Jody Cloutier Enviado el: lunes, 09 de febrero de 2015 18:55 Para: CABFPub (public at cabforum.org) Asunto: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Microsoft comments on Section 17. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150226/8f5e2066/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 19121 bytes Desc: image001.png Url : https://cabforum.org/pipermail/public/attachments/20150226/8f5e2066/attachment-0002.png -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 1181 bytes Desc: image002.png Url : https://cabforum.org/pipermail/public/attachments/20150226/8f5e2066/attachment-0003.png From i-barreira at izenpe.net Thu Feb 26 00:53:58 2015 From: i-barreira at izenpe.net (i-barreira at izenpe.net) Date: Thu, 26 Feb 2015 08:53:58 +0100 Subject: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc In-Reply-To: <2639008ebb224f54be8be02132375681@EX2.corp.digicert.com> References: <763539E260C37C46A0D6B340B5434C3B0ACD81A9@AEX06.ejsarea.net> A <763539E260C37C46A0D6B340B5434C3B0ADAE0EB@AEX06.ejsarea.net> <2639008ebb224f54be8be02132375681@EX2.corp.digicert.com> Message-ID: <763539E260C37C46A0D6B340B5434C3B0AE7ECC9@AEX06.ejsarea.net> I think the auditors qualification should be added to the BRs as a general matter valid for all documents produced by the CABF for all type of audits. So, all audits should be conducted in the same way. I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. De: Jeremy Rowley [mailto:jeremy.rowley at digicert.com] Enviado el: jueves, 26 de febrero de 2015 1:29 Para: Jody Cloutier; Barreira Iglesias, I?igo; public at cabforum.org Asunto: RE: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Should this be added to the BRs instead of code signing? For auditor qualifications, we just incorporate the auditor qualifications by reference. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jody Cloutier Sent: Friday, February 13, 2015 1:28 PM To: i-barreira at izenpe.net; public at cabforum.org Subject: Re: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Thank you, Inigo, What seems to be happening is that organizations are applying the ETSI standard in cases in which either there is no National Standards Body, or where the national standards body does not certify the company. Building on the scenario below, Audit Co is not recognized by ISRAC, but Auditor Jones has a CISP certification, which I've already confirmed with ETSI is not sufficient. I think what would help here is to make the requirement much more specific: A Qualified Auditor is limited to an auditor that is employed by a company that is certified by a National Authority listed in either the Members or Associate Members link. This, much simplified language, seems to be what you are saying below, but the current language is such that Audit Co can argue that it can issue an ETSI audit because it's company is certified by another national authority that's not listed on the ETSI webpages anywhere. Jody From: i-barreira at izenpe.net [mailto:i-barreira at izenpe.net] Sent: Friday, February 13, 2015 12:16 AM To: Jody Cloutier; public at cabforum.org Subject: RE: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Dear Jody, I understand your concern because it?s not easy for you to manage all possible combinations regarding ETSI audits in different countries so will try to clarify your example. First of all, no AuditCo has to be member of ETSI, AuditCo can perform ETSI accredited audits without being member of ETSI, they only need to be accredited in their country as stated in Annex E requirements. So, For example, ? Company A is a commercial CA that operates in Israel ? Auditor Jones works for AuditCo, which is based in Israel ? AuditCo is certified by some governmental agency as a qualified auditor IB? AuditCo has to be accredited under its National Accreditation Body according to ISO 17021. In the case of Israel, to follow the example, in the associated members tab of the EA, you can find the Israeli accreditation body, called ISRAC. Then AuditCo should be listed there and meeting the requirements to perform ETSI audits according to the national scheme indicated by ISRAC ? AuditCo is not an ETSI Member or Associate Member IB ? this is not necessary. No need to be an ETSI member to perform ETSI audits ? Auditor Jones audits Company A using the ETSI 102042 standard, and Company A sends the auditor's attestation letter to Microsoft as evidence that Company A complied with the Program's requirements. IB? this is perfectly valid if AuditCo is listed in ISRAC and is allowed to perform ETSI audits. Of course Auditor Jones has to be also accredited to perform these kind of audits, has to be "qualified", so it?s not only the company but also the auditor, but that?s an internal task of the AuditCo. Regarding of being member of not, this is voluntary, they can join ETSI or not and don?t think that solve the problem because joining ETSI does not mean that you?re "qualified" or "accredited" to perform an ETSI audit, it?s just indicate that you belong to a club for example. And of course, if company A needs an auditing company accredited in Israel and there?s none, they can look for in other countries. For example, in Spain there?s no accredited auditing bodies to perform ETSI audits listed in our NAB, called ENAC, so, we, Izenpe, had to look for another option. So, we contacted for the first 6 years with KPMG in the Netherlands, and the last 3, with TUV IT in Germany. And Izenpe has an accredited ETSI audits according to the, right now, German national scheme and we?re listed in Germany. We?ll debate this within ETSI ESI trying to find an easier solution. Regards I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. De: Jody Cloutier [mailto:jodycl at microsoft.com] Enviado el: mi?rcoles, 11 de febrero de 2015 0:32 Para: Barreira Iglesias, I?igo; public at cabforum.org Asunto: RE: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Thank you, Inigo. I think the problem is that, under ETSI, it's difficult to discern what an "equivalent national scheme" is. This sets up the scenario in which an auditor is employed by an organization that is recognized somehow by the government, but is not affiliated with an ETSI member organization (http://www.european-accreditation.org/home ). Microsoft does not know whether or not this auditor is qualified or not. For example, ? Company A is a commercial CA that operates in Israel ? Auditor Jones works for AuditCo, which is based in Israel ? AuditCo is certified by some governmental agency as a qualified auditor ? AuditCo is not an ETSI Member or Associate Member ? Auditor Jones audits Company A using the ETSI 102042 standard, and Company A sends the auditor's attestation letter to Microsoft as evidence that Company A complied with the Program's requirements. In this scenario, how does Microsoft know that Auditor Jones conducted a proper audit without expending significant resources to determine whether and according to what standard AuditCo and Auditor Jones was certified? Microsoft believes that it would be simpler if the requirements were that the Auditor must work for a company that is affiliated with an ETSI-approved member organization. If Company A needs an auditor and there is no qualified auditor in Israel, the company can use an auditor from a member organization via the cross-border conformity rules. Unless I am fundamentally misunderstanding the rules, the above is something that Microsoft is presently struggling with, and we'd like to try to make the rules easier to understand for potential partners and ourselves. Jody Cloutier Senior Security Program Manager Microsoft Trusted Root Certificate Program jody.cloutier at microsoft.com 425.443.8922 Operating Systems Group Global Risk and Compliance From: i-barreira at izenpe.net [mailto:i-barreira at izenpe.net] Sent: Tuesday, February 10, 2015 3:09 AM To: Jody Cloutier; public at cabforum.org Subject: RE: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Hi Jody, Regarding your comment on ETSI audits, I have to say that the ETSI audits shall be performed by accredited auditors as mentioned in Annex E of the current ETSI TS 102 042. ETSI audits performed by not accredited auditors shall be considered invalid. Microsoft is accepting ETSI audits since the very beginning in its root program requirements indicating this requirement. ETSI is providing a list of accredited auditors as mere information because has to be maintained by every NAB (National Accreditation Body). It?s true that this has to be improved regarding the new regulation 910/2014 and the new ENs and will take some time, but at the moment, it?s clearly stated that the audits shall be performed by accredited auditors. Don?t hesitate in contacting me for any additional information or help. Sometimes I?ve received some emails from Tom or Kelvin asking for the qualification of some audits, so, as say, you can contact me regarding this issue. Regards I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. De: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] En nombre de Jody Cloutier Enviado el: lunes, 09 de febrero de 2015 18:55 Para: CABFPub (public at cabforum.org) Asunto: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Microsoft comments on Section 17. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150226/8b154230/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 19121 bytes Desc: image001.png Url : https://cabforum.org/pipermail/public/attachments/20150226/8b154230/attachment-0002.png -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 1181 bytes Desc: image002.png Url : https://cabforum.org/pipermail/public/attachments/20150226/8b154230/attachment-0003.png From mcaughron at apple.com Thu Feb 26 15:15:37 2015 From: mcaughron at apple.com (Mat Caughron) Date: Thu, 26 Feb 2015 14:15:37 -0800 Subject: [cabfpub] Updated Certificate Transparency + Extended Validation plan In-Reply-To: References: Message-ID: <2C97673F-8638-4592-8B0C-C7398D2221A7@apple.com> Greetings: It has been one year, has this CT plan been updated at all? Sincerely, Mat Caughron ? Product Security > On Feb 4, 2014, at 9:08 AM, Ben Laurie wrote: > > Enclosed, our revised plan. > > Comments welcome. > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4112 bytes Desc: not available Url : https://cabforum.org/pipermail/public/attachments/20150226/dcf152c3/attachment.bin From rob.stradling at comodo.com Thu Feb 26 15:24:25 2015 From: rob.stradling at comodo.com (Rob Stradling) Date: Thu, 26 Feb 2015 17:24:25 -0500 Subject: [cabfpub] Updated Certificate Transparency + Extended Validationplan In-Reply-To: <2C97673F-8638-4592-8B0C-C7398D2221A7@apple.com> References: <2C97673F-8638-4592-8B0C-C7398D2221A7@apple.com> Message-ID: <54EF9D19.9070105@comodo.com> On 26/02/15 17:15, Mat Caughron wrote: > Greetings: > > It has been one year, has this CT plan been updated at all? Hi Mat. Google's EV/CT Plan has been updated a couple of times since then. See here: http://www.certificate-transparency.org/ev-ct-plan > Sincerely, > > > Mat Caughron > ? Product Security > > > >> On Feb 4, 2014, at 9:08 AM, Ben Laurie wrote: >> >> Enclosed, our revised plan. >> >> Comments welcome. >> _______________________________________________ >> Public mailing list >> Public at cabforum.org >> https://cabforum.org/mailman/listinfo/public > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From mcaughron at apple.com Thu Feb 26 15:39:22 2015 From: mcaughron at apple.com (Mat Caughron) Date: Thu, 26 Feb 2015 14:39:22 -0800 Subject: [cabfpub] Updated Certificate Transparency + Extended Validationplan In-Reply-To: <54EF9D19.9070105@comodo.com> References: <2C97673F-8638-4592-8B0C-C7398D2221A7@apple.com> <54EF9D19.9070105@comodo.com> Message-ID: <0281DDB3-432A-4ABA-82B6-D757D92E6A4A@apple.com> Hello Rob, So presumably, the survey if conducted now would indicate a few more CA's on board than indicated here? http://www.certificate-transparency.org/feb-2014-survey-responses Mat Caughron ? Product Security mcaughron at appe.com > On Feb 26, 2015, at 2:24 PM, Rob Stradling wrote: > > On 26/02/15 17:15, Mat Caughron wrote: >> Greetings: >> >> It has been one year, has this CT plan been updated at all? > > Hi Mat. > > Google's EV/CT Plan has been updated a couple of times since then. See here: > http://www.certificate-transparency.org/ev-ct-plan > >> Sincerely, >> >> >> Mat Caughron >> ? Product Security >> >> >> >>> On Feb 4, 2014, at 9:08 AM, Ben Laurie wrote: >>> >>> Enclosed, our revised plan. >>> >>> Comments welcome. >>> _______________________________________________ >>> Public mailing list >>> Public at cabforum.org >>> https://cabforum.org/mailman/listinfo/public >> > > -- > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150226/24a87e07/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4112 bytes Desc: not available Url : https://cabforum.org/pipermail/public/attachments/20150226/24a87e07/attachment.bin From rob.stradling at comodo.com Thu Feb 26 21:18:18 2015 From: rob.stradling at comodo.com (Rob Stradling) Date: Thu, 26 Feb 2015 23:18:18 -0500 Subject: [cabfpub] Updated Certificate Transparency + ExtendedValidationplan In-Reply-To: <0281DDB3-432A-4ABA-82B6-D757D92E6A4A@apple.com> References: <2C97673F-8638-4592-8B0C-C7398D2221A7@apple.com> <54EF9D19.9070105@comodo.com> <0281DDB3-432A-4ABA-82B6-D757D92E6A4A@apple.com> Message-ID: <54EFF00A.5030805@comodo.com> Good question, Mat. I've just generated a report (see attached) that shows, per issuing CA, the number of certs with embedded SCTs that have been logged in the currently existing CT logs so far. That is one measurement of which CAs are "on board", but it's not the full story. On 26/02/15 17:39, Mat Caughron wrote: > Hello Rob, > > So presumably, the survey if conducted now would indicate a few more > CA's on board than indicated here? > http://www.certificate-transparency.org/feb-2014-survey-responses > > > > Mat Caughron > ? Product Security > mcaughron at appe.com > > > >> On Feb 26, 2015, at 2:24 PM, Rob Stradling > > wrote: >> >> On 26/02/15 17:15, Mat Caughron wrote: >>> Greetings: >>> >>> It has been one year, has this CT plan been updated at all? >> >> Hi Mat. >> >> Google's EV/CT Plan has been updated a couple of times since then. >> See here: >> http://www.certificate-transparency.org/ev-ct-plan >> >>> Sincerely, >>> >>> >>> Mat Caughron >>> ? Product Security >>> >>> >>> >>>> On Feb 4, 2014, at 9:08 AM, Ben Laurie wrote: >>>> >>>> Enclosed, our revised plan. >>>> >>>> Comments welcome. >>>> _______________________________________________ >>>> Public mailing list >>>> Public at cabforum.org >>>> https://cabforum.org/mailman/listinfo/public >>> >> >> -- >> Rob Stradling >> Senior Research & Development Scientist >> COMODO - Creating Trust Online > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. -------------- next part -------------- A non-text attachment was scrubbed... Name: certs_with_embedded_scts_per_ca.csv Type: text/csv Size: 6218 bytes Desc: not available Url : https://cabforum.org/pipermail/public/attachments/20150226/5eed1542/attachment-0001.bin From i-barreira at izenpe.net Fri Feb 27 00:40:15 2015 From: i-barreira at izenpe.net (i-barreira at izenpe.net) Date: Fri, 27 Feb 2015 08:40:15 +0100 Subject: [cabfpub] Updated Certificate Transparency + ExtendedValidationplan In-Reply-To: <54EFF00A.5030805@comodo.com> References: <2C97673F-8638-4592-8B0C-C7398D2221A7@apple.com> <54EF9D19.9070105@comodo.com> <0281DDB3-432A-4ABA-82B6-D757D92E6A4A@apple.com> <54EFF00A.5030805@comodo.com> Message-ID: <763539E260C37C46A0D6B340B5434C3B0AE7EF28@AEX06.ejsarea.net> And for example, Izepe indicated that were not interested in running a log server, and we?re running one :-) I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. -----Mensaje original----- De: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] En nombre de Rob Stradling Enviado el: viernes, 27 de febrero de 2015 5:18 Para: Mat Caughron CC: therightkey at ietf.org; certificate-transparency at googlegroups.com; CABFPub Asunto: Re: [cabfpub] Updated Certificate Transparency + ExtendedValidationplan Good question, Mat. I've just generated a report (see attached) that shows, per issuing CA, the number of certs with embedded SCTs that have been logged in the currently existing CT logs so far. That is one measurement of which CAs are "on board", but it's not the full story. On 26/02/15 17:39, Mat Caughron wrote: > Hello Rob, > > So presumably, the survey if conducted now would indicate a few more > CA's on board than indicated here? > http://www.certificate-transparency.org/feb-2014-survey-responses > > > > Mat Caughron > ? Product Security > mcaughron at appe.com > > > >> On Feb 26, 2015, at 2:24 PM, Rob Stradling > > wrote: >> >> On 26/02/15 17:15, Mat Caughron wrote: >>> Greetings: >>> >>> It has been one year, has this CT plan been updated at all? >> >> Hi Mat. >> >> Google's EV/CT Plan has been updated a couple of times since then. >> See here: >> http://www.certificate-transparency.org/ev-ct-plan >> >>> Sincerely, >>> >>> >>> Mat Caughron >>> ? Product Security >>> >>> >>> >>>> On Feb 4, 2014, at 9:08 AM, Ben Laurie wrote: >>>> >>>> Enclosed, our revised plan. >>>> >>>> Comments welcome. >>>> _______________________________________ >>>> ________ >>>> Public mailing list >>>> Public at cabforum.org >>>> https://cabforum.org/mailman/listinfo/public >>> >> >> -- >> Rob Stradling >> Senior Research & Development Scientist COMODO - Creating Trust >> Online > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. From bruce.morton at entrust.com Fri Feb 27 07:25:46 2015 From: bruce.morton at entrust.com (Bruce Morton) Date: Fri, 27 Feb 2015 14:25:46 +0000 Subject: [cabfpub] Ballot 145 - Operational Existence for Government Entities In-Reply-To: References: Message-ID: <452C99D20750E74083DBA441FF932385E41A749D@SOTTEXCH10.corp.ad.entrust.com> Entrust votes Yes. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Thursday, February 19, 2015 10:44 AM To: CABFPub Subject: [cabfpub] Ballot 145 - Operational Existence for Government Entities Ballot 145 - Operational Existence for Government Entities ________________________________ Reason ________________________________ Because government entities aren't operating as businesses, they are often not listed with a QIIS, especially immediately after the entity is created by either statute or order. The legal existence of these entities is verifiable through a QGIS, but this source in many countries (especially Arabic and African countries) does not always list a date of creation of these entities. Operational existence exists to ensure organizations aren't fly-by-night scams/phishing entities. With government entities, these same risks are not present as they are created directly by government action. Jeremy Rowley of DigiCert made the following motion, which was endorsed by Rich Smith of Comodo and Cecilia Kam of Symantec. ________________________________ Motion begins ________________________________ Effective immediately, section 11.6.1 is modified as follows: 11.6.1 Verification Requirements. The CA MUST verify that the Applicant has the ability to engage in business by verifying the Applicant's, or Affiliate/Parent/Subsidiary Company's, operational existence. The CA MAY rely on its verification of a Government Entity's legal existence under Section 11.2 as verification of a Government Entity's operational existence. ________________________________ Motion Ends ________________________________ The review period for this ballot shall commence at 2200 UTC on 19 Feb 2015, and will close at 2200 UTC on 26 Feb 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on 5 Mar 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150227/99a64cc2/attachment.html From kirk_hall at trendmicro.com Fri Feb 27 09:05:00 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Fri, 27 Feb 2015 16:05:00 +0000 Subject: [cabfpub] Ballot 145 - Operational Existence for Government Entities In-Reply-To: <452C99D20750E74083DBA441FF932385E41A749D@SOTTEXCH10.corp.ad.entrust.com> References: <452C99D20750E74083DBA441FF932385E41A749D@SOTTEXCH10.corp.ad.entrust.com> Message-ID: Trend Micro votes yes From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Thursday, February 19, 2015 10:44 AM To: CABFPub Subject: [cabfpub] Ballot 145 - Operational Existence for Government Entities Ballot 145 - Operational Existence for Government Entities ________________________________ Reason ________________________________ Because government entities aren't operating as businesses, they are often not listed with a QIIS, especially immediately after the entity is created by either statute or order. The legal existence of these entities is verifiable through a QGIS, but this source in many countries (especially Arabic and African countries) does not always list a date of creation of these entities. Operational existence exists to ensure organizations aren't fly-by-night scams/phishing entities. With government entities, these same risks are not present as they are created directly by government action. Jeremy Rowley of DigiCert made the following motion, which was endorsed by Rich Smith of Comodo and Cecilia Kam of Symantec. ________________________________ Motion begins ________________________________ Effective immediately, section 11.6.1 is modified as follows: 11.6.1 Verification Requirements. The CA MUST verify that the Applicant has the ability to engage in business by verifying the Applicant's, or Affiliate/Parent/Subsidiary Company's, operational existence. The CA MAY rely on its verification of a Government Entity's legal existence under Section 11.2 as verification of a Government Entity's operational existence. ________________________________ Motion Ends ________________________________ The review period for this ballot shall commence at 2200 UTC on 19 Feb 2015, and will close at 2200 UTC on 26 Feb 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on 5 Mar 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
-------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150227/32ee219c/attachment-0001.html From richard at wosign.com Fri Feb 27 09:13:34 2015 From: richard at wosign.com (Richard Wang) Date: Fri, 27 Feb 2015 16:13:34 +0000 Subject: [cabfpub] Ballot 145 - Operational Existence for Government Entities In-Reply-To: References: <452C99D20750E74083DBA441FF932385E41A749D@SOTTEXCH10.corp.ad.entrust.com> Message-ID: <43831CBB-7B89-4F6A-9EA8-714DD58A067E@wosign.com> > WoSign votes yes > > From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley > Sent: Thursday, February 19, 2015 10:44 AM > To: CABFPub > Subject: [cabfpub] Ballot 145 - Operational Existence for Government Entities > > Ballot 145 - Operational Existence for Government Entities > > Reason > > Because government entities aren?t operating as businesses, they are often not listed with a QIIS, especially immediately after the entity is created by either statute or order. The legal existence of these entities is verifiable through a QGIS, but this source in many countries (especially Arabic and African countries) does not always list a date of creation of these entities. Operational existence exists to ensure organizations aren?t fly-by-night scams/phishing entities. With government entities, these same risks are not present as they are created directly by government action. > > Jeremy Rowley of DigiCert made the following motion, which was endorsed by Rich Smith of Comodo and Cecilia Kam of Symantec. > > Motion begins > > Effective immediately, section 11.6.1 is modified as follows: > > 11.6.1 Verification Requirements. > > The CA MUST verify that the Applicant has the ability to engage in business by verifying the Applicant's, or Affiliate/Parent/Subsidiary Company's, operational existence. The CA MAY rely on its verification of a Government Entity?s legal existence under Section 11.2 as verification of a Government Entity?s operational existence. > > Motion Ends > > The review period for this ballot shall commence at 2200 UTC on 19 Feb 2015, and will close at 2200 UTC on 26 Feb 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on 5 Mar 2015. Votes must be cast by posting an on-list reply to this thread. > > A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ > > In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members? at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. > > > TREND MICRO EMAIL NOTICE > The information contained in this email and any attachments is confidential > and may be subject to copyright or other intellectual property protection. > If you are not the intended recipient, you are not authorized to use or > disclose this information, and we request that you notify us by reply mail or > telephone and delete the original message from your mail system. > _______________________________________________ > 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/20150227/2e1d11bd/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 7152 bytes Desc: not available Url : https://cabforum.org/pipermail/public/attachments/20150227/2e1d11bd/attachment.bin From Dean_Coclin at symantec.com Fri Feb 27 11:32:39 2015 From: Dean_Coclin at symantec.com (Dean Coclin) Date: Fri, 27 Feb 2015 10:32:39 -0800 Subject: [cabfpub] Ballot 145 - Operational Existence for Government Entities In-Reply-To: References: Message-ID: <14D026C7F297AD44AC82578DD818CDD038EF614DE0@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> Symantec votes YES. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Thursday, February 19, 2015 10:44 AM To: CABFPub Subject: [cabfpub] Ballot 145 - Operational Existence for Government Entities Ballot 145 - Operational Existence for Government Entities _____ Reason _____ Because government entities aren't operating as businesses, they are often not listed with a QIIS, especially immediately after the entity is created by either statute or order. The legal existence of these entities is verifiable through a QGIS, but this source in many countries (especially Arabic and African countries) does not always list a date of creation of these entities. Operational existence exists to ensure organizations aren't fly-by-night scams/phishing entities. With government entities, these same risks are not present as they are created directly by government action. Jeremy Rowley of DigiCert made the following motion, which was endorsed by Rich Smith of Comodo and Cecilia Kam of Symantec. _____ Motion begins _____ Effective immediately, section 11.6.1 is modified as follows: 11.6.1 Verification Requirements. The CA MUST verify that the Applicant has the ability to engage in business by verifying the Applicant's, or Affiliate/Parent/Subsidiary Company's, operational existence. The CA MAY rely on its verification of a Government Entity's legal existence under Section 11.2 as verification of a Government Entity's operational existence. _____ Motion Ends _____ The review period for this ballot shall commence at 2200 UTC on 19 Feb 2015, and will close at 2200 UTC on 26 Feb 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on 5 Mar 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150227/87daada7/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6130 bytes Desc: not available Url : https://cabforum.org/pipermail/public/attachments/20150227/87daada7/attachment-0001.bin From S.Davidson at quovadisglobal.com Fri Feb 27 11:42:27 2015 From: S.Davidson at quovadisglobal.com (Stephen Davidson) Date: Fri, 27 Feb 2015 18:42:27 +0000 Subject: [cabfpub] Ballot 145 - Operational Existence for Government Entities In-Reply-To: <452C99D20750E74083DBA441FF932385E41A749D@SOTTEXCH10.corp.ad.entrust.com> References: <452C99D20750E74083DBA441FF932385E41A749D@SOTTEXCH10.corp.ad.entrust.com> Message-ID: QuoVadis votes yes. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Thursday, February 19, 2015 10:44 AM To: CABFPub Subject: [cabfpub] Ballot 145 - Operational Existence for Government Entities Ballot 145 - Operational Existence for Government Entities _____ Reason _____ Because government entities aren't operating as businesses, they are often not listed with a QIIS, especially immediately after the entity is created by either statute or order. The legal existence of these entities is verifiable through a QGIS, but this source in many countries (especially Arabic and African countries) does not always list a date of creation of these entities. Operational existence exists to ensure organizations aren't fly-by-night scams/phishing entities. With government entities, these same risks are not present as they are created directly by government action. Jeremy Rowley of DigiCert made the following motion, which was endorsed by Rich Smith of Comodo and Cecilia Kam of Symantec. _____ Motion begins _____ Effective immediately, section 11.6.1 is modified as follows: 11.6.1 Verification Requirements. The CA MUST verify that the Applicant has the ability to engage in business by verifying the Applicant's, or Affiliate/Parent/Subsidiary Company's, operational existence. The CA MAY rely on its verification of a Government Entity's legal existence under Section 11.2 as verification of a Government Entity's operational existence. _____ Motion Ends _____ The review period for this ballot shall commence at 2200 UTC on 19 Feb 2015, and will close at 2200 UTC on 26 Feb 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on 5 Mar 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150227/f43dd24d/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5529 bytes Desc: not available Url : https://cabforum.org/pipermail/public/attachments/20150227/f43dd24d/attachment.bin From jeremy.rowley at digicert.com Fri Feb 27 11:44:33 2015 From: jeremy.rowley at digicert.com (Jeremy Rowley) Date: Fri, 27 Feb 2015 18:44:33 +0000 Subject: [cabfpub] Ballot 145 - Operational Existence for Government Entities In-Reply-To: <14D026C7F297AD44AC82578DD818CDD038EF614DE0@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> References: <14D026C7F297AD44AC82578DD818CDD038EF614DE0@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> Message-ID: <5e3148ac833b49f9a4a0363fa6fddbc5@EX2.corp.digicert.com> DigiCert votes YES From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Dean Coclin Sent: Friday, February 27, 2015 11:33 AM To: CABFPub Subject: Re: [cabfpub] Ballot 145 - Operational Existence for Government Entities Symantec votes YES. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Thursday, February 19, 2015 10:44 AM To: CABFPub Subject: [cabfpub] Ballot 145 - Operational Existence for Government Entities Ballot 145 - Operational Existence for Government Entities ________________________________ Reason ________________________________ Because government entities aren't operating as businesses, they are often not listed with a QIIS, especially immediately after the entity is created by either statute or order. The legal existence of these entities is verifiable through a QGIS, but this source in many countries (especially Arabic and African countries) does not always list a date of creation of these entities. Operational existence exists to ensure organizations aren't fly-by-night scams/phishing entities. With government entities, these same risks are not present as they are created directly by government action. Jeremy Rowley of DigiCert made the following motion, which was endorsed by Rich Smith of Comodo and Cecilia Kam of Symantec. ________________________________ Motion begins ________________________________ Effective immediately, section 11.6.1 is modified as follows: 11.6.1 Verification Requirements. The CA MUST verify that the Applicant has the ability to engage in business by verifying the Applicant's, or Affiliate/Parent/Subsidiary Company's, operational existence. The CA MAY rely on its verification of a Government Entity's legal existence under Section 11.2 as verification of a Government Entity's operational existence. ________________________________ Motion Ends ________________________________ The review period for this ballot shall commence at 2200 UTC on 19 Feb 2015, and will close at 2200 UTC on 26 Feb 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on 5 Mar 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150227/ac8e1cd9/attachment-0001.html From jodycl at microsoft.com Fri Feb 27 11:48:05 2015 From: jodycl at microsoft.com (Jody Cloutier) Date: Fri, 27 Feb 2015 18:48:05 +0000 Subject: [cabfpub] Ballot 145 - Operational Existence for Government Entities In-Reply-To: <5e3148ac833b49f9a4a0363fa6fddbc5@EX2.corp.digicert.com> References: <14D026C7F297AD44AC82578DD818CDD038EF614DE0@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> <5e3148ac833b49f9a4a0363fa6fddbc5@EX2.corp.digicert.com> Message-ID: Microsoft votes YES From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Friday, February 27, 2015 10:45 AM To: Dean Coclin; CABFPub Subject: Re: [cabfpub] Ballot 145 - Operational Existence for Government Entities DigiCert votes YES From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Dean Coclin Sent: Friday, February 27, 2015 11:33 AM To: CABFPub Subject: Re: [cabfpub] Ballot 145 - Operational Existence for Government Entities Symantec votes YES. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Thursday, February 19, 2015 10:44 AM To: CABFPub Subject: [cabfpub] Ballot 145 - Operational Existence for Government Entities Ballot 145 - Operational Existence for Government Entities ________________________________ Reason ________________________________ Because government entities aren't operating as businesses, they are often not listed with a QIIS, especially immediately after the entity is created by either statute or order. The legal existence of these entities is verifiable through a QGIS, but this source in many countries (especially Arabic and African countries) does not always list a date of creation of these entities. Operational existence exists to ensure organizations aren't fly-by-night scams/phishing entities. With government entities, these same risks are not present as they are created directly by government action. Jeremy Rowley of DigiCert made the following motion, which was endorsed by Rich Smith of Comodo and Cecilia Kam of Symantec. ________________________________ Motion begins ________________________________ Effective immediately, section 11.6.1 is modified as follows: 11.6.1 Verification Requirements. The CA MUST verify that the Applicant has the ability to engage in business by verifying the Applicant's, or Affiliate/Parent/Subsidiary Company's, operational existence. The CA MAY rely on its verification of a Government Entity's legal existence under Section 11.2 as verification of a Government Entity's operational existence. ________________________________ Motion Ends ________________________________ The review period for this ballot shall commence at 2200 UTC on 19 Feb 2015, and will close at 2200 UTC on 26 Feb 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on 5 Mar 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150227/057b3c2c/attachment.html From enric.castillo at anf.es Fri Feb 27 12:56:02 2015 From: enric.castillo at anf.es (Enric Castillo) Date: Fri, 27 Feb 2015 14:56:02 -0500 Subject: [cabfpub] Ballot 145 - Operational Existence for Government Entities In-Reply-To: References: Message-ID: <54F0CBD2.8010102@anf.es> ANF AC votes yes. ANF Autoridad de Certificaci?n *Enric Castillo* Director T?cnico +34 626818285 Gran Via de Les Corts Catalanes 996, Barcelona +593 0 998554992 12 de Octubre y Cordero, World Trade Center, Torre A, 1102, Quito ANF Autoridad de Certificaci?n www.anf.es *Aviso* Este mensaje se dirige exclusivamente a su destinatario y puede contener informaci?n privilegiada o confidencial y/o datos de car?cter personal, cuya difusi?n est? regulada por la Ley Org?nica de Protecci?n de Datos y la Ley de Servicios de la Sociedad de la Informaci?n. Si usted no es el destinatario indicado (o el responsable de la entrega al mismo), no debe copiar o entregar este mensaje a terceros bajo ning?n concepto. Si ha recibido este mensaje por error o lo ha conseguido por otros medios, le rogamos que nos lo comunique inmediatamente por esta misma v?a y proceda a su eliminaci?n irreversible. Las opiniones, conclusiones y dem?s informaciones incluidas en este mensaje que no est?n relacionadas con asuntos profesionales de ANF Autoridad de Certificaci?n no est?n respaldadas por la empresa. El 19/02/2015 a las 10:43, Jeremy Rowley escribi?: > > Ballot 145 - Operational Existence for Government Entities > > ------------------------------------------------------------------------ > > Reason > > ------------------------------------------------------------------------ > > Because government entities aren?t operating as businesses, they are > often not listed with a QIIS, especially immediately after the entity > is created by either statute or order. The legal existence of these > entities is verifiable through a QGIS, but this source in many > countries (especially Arabic and African countries) does not always > list a date of creation of these entities. Operational existence > exists to ensure organizations aren?t fly-by-night scams/phishing > entities. With government entities, these same risks are not present > as they are created directly by government action. > > Jeremy Rowley of DigiCert > made the following motion, which was endorsed by Rich Smith of Comodo > and Cecilia Kam of Symantec. > > ------------------------------------------------------------------------ > > Motion begins > > ------------------------------------------------------------------------ > > Effective immediately, section 11.6.1 is modified as follows: > > 11.6.1 Verification Requirements. > > The CA MUST verify that the Applicant has the ability to engage in > business by verifying the Applicant's, or Affiliate/Parent/Subsidiary > Company's, operational existence._The CA MAY rely on its verification > of a Government Entity?s legal existence under Section 11.2 as > verification of a Government Entity?s operational existence. _ > > ------------------------------------------------------------------------ > > Motion Ends > > ------------------------------------------------------------------------ > > The review period for this ballot shall commence at 2200 UTC on 19 Feb > 2015, and will close at 2200 UTC on 26 Feb 2015. Unless the motion is > withdrawn during the review period, the voting period will start > immediately thereafter and will close at 2200 UTC on 5 Mar 2015. Votes > must be cast by posting an on-list reply to this thread. > > A vote in favor of the motion must indicate a clear 'yes' in the > response. A vote against must indicate a clear 'no' in the response. A > vote to abstain must indicate a clear 'abstain' in the response. > Unclear responses will not be counted. The latest vote received from > any representative of a voting member before the close of the voting > period will be counted. Voting members are listed here: > https://cabforum.org/members/ > > In order for the motion to be adopted, two thirds or more of the votes > cast by members in the CA category and greater than 50% of the votes > cast by members in the browser category must be in favor. Quorum is > currently nine (9) members? at least nine members must participate in > the ballot, either by voting in favor, voting against, or abstaining. > > > > _______________________________________________ > 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/20150227/b82e2002/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: logo-anf.png Type: image/png Size: 4746 bytes Desc: not available Url : https://cabforum.org/pipermail/public/attachments/20150227/b82e2002/attachment.png From eddy_nigg at startcom.org Fri Feb 27 13:32:28 2015 From: eddy_nigg at startcom.org (Eddy Nigg) Date: Fri, 27 Feb 2015 22:32:28 +0200 Subject: [cabfpub] Ballot 145 - Operational Existence for Government Entities In-Reply-To: References: Message-ID: <54F0D45C.9050501@startcom.org> If you need more yes votes, here another one: StartCom votes YES On 02/19/2015 05:43 PM, Jeremy Rowley wrote: > > Ballot 145 - Operational Existence for Government Entities > > ------------------------------------------------------------------------ > > Reason > > ------------------------------------------------------------------------ > > Because government entities aren't operating as businesses, they are > often not listed with a QIIS, especially immediately after the entity > is created by either statute or order. The legal existence of these > entities is verifiable through a QGIS, but this source in many > countries (especially Arabic and African countries) does not always > list a date of creation of these entities. Operational existence > exists to ensure organizations aren't fly-by-night scams/phishing > entities. With government entities, these same risks are not present > as they are created directly by government action. > > Jeremy Rowley of DigiCert > made the following motion, which was endorsed by Rich Smith of Comodo > and Cecilia Kam of Symantec. > > ------------------------------------------------------------------------ > > Motion begins > > ------------------------------------------------------------------------ > > Effective immediately, section 11.6.1 is modified as follows: > > 11.6.1 Verification Requirements. > > The CA MUST verify that the Applicant has the ability to engage in > business by verifying the Applicant's, or Affiliate/Parent/Subsidiary > Company's, operational existence._The CA MAY rely on its verification > of a Government Entity's legal existence under Section 11.2 as > verification of a Government Entity's operational existence. _ > > ------------------------------------------------------------------------ > > Motion Ends > > ------------------------------------------------------------------------ > > The review period for this ballot shall commence at 2200 UTC on 19 Feb > 2015, and will close at 2200 UTC on 26 Feb 2015. Unless the motion is > withdrawn during the review period, the voting period will start > immediately thereafter and will close at 2200 UTC on 5 Mar 2015. Votes > must be cast by posting an on-list reply to this thread. > > A vote in favor of the motion must indicate a clear 'yes' in the > response. A vote against must indicate a clear 'no' in the response. A > vote to abstain must indicate a clear 'abstain' in the response. > Unclear responses will not be counted. The latest vote received from > any representative of a voting member before the close of the voting > period will be counted. Voting members are listed here: > https://cabforum.org/members/ > > In order for the motion to be adopted, two thirds or more of the votes > cast by members in the CA category and greater than 50% of the votes > cast by members in the browser category must be in favor. Quorum is > currently nine (9) members-- at least nine members must participate in > the ballot, either by voting in favor, voting against, or abstaining. > > > > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public -- Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. XMPP: startcom at startcom.org Blog: Join the Revolution! Twitter: Follow Me -------------- next part -------------- An HTML attachment was scrubbed... URL: https://cabforum.org/pipermail/public/attachments/20150227/27bfe6b5/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4313 bytes Desc: S/MIME Cryptographic Signature Url : https://cabforum.org/pipermail/public/attachments/20150227/27bfe6b5/attachment-0001.bin From rob.stradling at comodo.com Fri Feb 27 16:28:06 2015 From: rob.stradling at comodo.com (Rob Stradling) Date: Fri, 27 Feb 2015 18:28:06 -0500 Subject: [cabfpub] Updated Certificate Transparency + ExtendedValidationplan In-Reply-To: <54EFF00A.5030805@comodo.com> References: <2C97673F-8638-4592-8B0C-C7398D2221A7@apple.com> <54EF9D19.9070105@comodo.com> <0281DDB3-432A-4ABA-82B6-D757D92E6A4A@apple.com> <54EFF00A.5030805@comodo.com> Message-ID: <54F0FD86.3010608@comodo.com> Mat, BTW, do Apple have any plans to support CT in Safari? On 26/02/15 23:18, Rob Stradling wrote: > Good question, Mat. > > I've just generated a report (see attached) that shows, per issuing CA, > the number of certs with embedded SCTs that have been logged in the > currently existing CT logs so far. > > That is one measurement of which CAs are "on board", but it's not the > full story. > > On 26/02/15 17:39, Mat Caughron wrote: >> Hello Rob, >> >> So presumably, the survey if conducted now would indicate a few more >> CA's on board than indicated here? >> http://www.certificate-transparency.org/feb-2014-survey-responses >> >> >> >> Mat Caughron >> ? Product Security >> mcaughron at appe.com >> >> >> >>> On Feb 26, 2015, at 2:24 PM, Rob Stradling >> > wrote: >>> >>> On 26/02/15 17:15, Mat Caughron wrote: >>>> Greetings: >>>> >>>> It has been one year, has this CT plan been updated at all? >>> >>> Hi Mat. >>> >>> Google's EV/CT Plan has been updated a couple of times since then. >>> See here: >>> http://www.certificate-transparency.org/ev-ct-plan >>> >>>> Sincerely, >>>> >>>> >>>> Mat Caughron >>>> ? Product Security >>>> >>>> >>>> >>>>> On Feb 4, 2014, at 9:08 AM, Ben Laurie wrote: >>>>> >>>>> Enclosed, our revised plan. >>>>> >>>>> Comments welcome. >>>>> _______________________________________________ >>>>> >>>>> Public mailing list >>>>> Public at cabforum.org >>>>> https://cabforum.org/mailman/listinfo/public >>>> >>> >>> -- >>> Rob Stradling >>> Senior Research & Development Scientist >>> COMODO - Creating Trust Online >> > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. From kirk_hall at trendmicro.com Sun Feb 1 20:05:21 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Sun, 1 Feb 2015 20:05:21 +0000 Subject: [cabfpub] Ballot 145 - Formalization of Validation Working Group In-Reply-To: <54CA80B3.3050503@comodo.com> References: <54CA80B3.3050503@comodo.com> Message-ID: Trend Micro will also endorse. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Rich Smith Sent: Thursday, January 29, 2015 10:49 AM To: public at cabforum.org; jeremy.rowley at digicert.com Subject: Re: [cabfpub] Ballot 145 - Formalization of Validation Working Group I'll endorse. Rich On 1/29/2015 11:56 AM, Jeremy Rowley wrote: This is the ballot to formalize the validation working group and modify its scope to include validation and the inclusion of information in certificates. I'm looking for two endorsers Ballot 145 - Formalization of Validation Working Group Reason In order to address validation issues and inconsistencies in both the SSL Baseline Requirements and the EV Guidelines, the CAB Forum has held an informal working group previously referred to as the Extended Validation Working Group now known as the Validation Working Group, would like to modify its scope to include validation in the Baseline Requirements as well as the EV Guidelines. - Motion begins - The CA-Browser Forum formally establishes the Validation Working Group as an official working group of the CAB Forum, replacing the previous informal EV working group. The scope of this working group is to address issues arising under adopted CAB Forum standards related to the validation of certificate information and the inclusion of information in certificates. Scope: The Validation Working Group will consider all matters relating to the validation and inclusion of information in certificates under adopted CAB Forum guidelines. Deliverables: The Working Group shall produce one or more documents offering options to the Forum for validation within the scope defined above. -- Motion Ends -- The review period for this ballot shall commence at 2200 UTC on , and will close at 2200 UTC on . Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on . Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. _______________________________________________ Public mailing list Public at cabforum.org https://cabforum.org/mailman/listinfo/public 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
-------------- next part -------------- An HTML attachment was scrubbed... URL: From jeremy.rowley at digicert.com Wed Feb 4 20:51:56 2015 From: jeremy.rowley at digicert.com (Jeremy Rowley) Date: Wed, 4 Feb 2015 20:51:56 +0000 Subject: [cabfpub] Ballot .onion ballot Message-ID: The following is the finalized onion ballot. I made two changes since we spoke in the last meeting. The first is based on Tom Ritter's feedback. He mentioned that there might be several onion names for a single entity so adding an identifier in the data structure that links the onionURI to the nonce would be helpful. I've included it below. I also realized that without a change to the BRs, CAs could still issue .onion names under the BRs as an internal name OR under the EV Guidelines. Since the goal is to lock down .onion issuance, I added a restriction that all .onion names would need to be revoked by May 1 if the ballot passes. I assume everyone is still willing to endorse? --- Applicants want a CA-signed .onion address for several reasons, including: - Powerful web platform features are restricted to secure origins, which are currently not available to onion names (in part, because of the lack of IANA registration). Permitting EV certs for onion names will help provide a secure origin for the service, moving onion towards use of powerful web platform features. - Currently, access to .onion names over https from a standard browser results in the standard existing 'Invalid Certificate' warning. Training users to click through security warnings lowers the value of these warnings and will cause users to miss important security information. Removing these warnings for the user, through use of a digital certificate, will help users recognize and avoid real MITM attacks. - The public needs attribution of ownership of the .onion address to differentiate onion services, including potential phishing services. Because onion names are not easily recognizable strings, providing the public with additional information about the operator has significant security improvements, especially in regions where use of the incorrect name could have lethal consequences. The following motion has been proposed by Jeremy Rowley of DigiCert and endorsed by Ryan Sleevi of Google and Wayne Thayer of GoDaddy. --------------------- Motion Starts --------------------- Amend Section 9.2.1 of the Baseline Requirements v. 1.2.3 as follows: 9.2.1 Subject Alternative Name Extension Certificate Field: extensions:subjectAltName Required/Optional: Required Contents: This 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. The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate. Wildcard FQDNs are permitted. As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name, the CA SHALL notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016. Also as of the Effective Date, the CA SHALL NOT issue a certificate with an Expiry Date later than 1 November 2015 with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name. Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Name. Effective May 1, 2015, each CA SHALL revoke all unexpired Certificates with an Internal Name using onion as the left-most label in an entry in the subjectAltName Extension or commonName field unless such Certificate was issued in accordance with Appendix F of the EV Guidelines. Amend the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2 as follows: Amend Section 9.2.2 and 11.7.1 as follows: 9.2.2. Subject Alternative Name Extension Certificate field: subjectAltName:dNSName Required/Optional: Required Contents: This extension MUST contain one or more host Domain Name(s) owned or controlled by the Subject and to be associated with the Subject's server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). Wildcard certificates are not allowed for EV Certificates except as permitted under Appendix F. 11.7 Verification of Applicant's Domain Name 11.7.1. Verification Requirements (1) For each Fully-Qualified Domain Name listed in a Certificate, other than a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant (or the Applicant's Parent Company, Subsidiary Company, or Affiliate, collectively referred to as "Applicant" for the purposes of this section) either is the Domain Name Registrant or has control over the FQDN using a procedure specified in Section 11.1.1 of the Baseline Requirements, except that a CA MAY NOT verify a domain using the procedure described 11.1.1(7). For a Certificate issued to a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant's control over the .onion Domain Name in accordance with Appendix F. (2) Mixed Character Set Domain Names: EV Certificates MAY include Domain Names containing mixed character sets only in compliance with the rules set forth by the domain registrar. The CA MUST visually compare any Domain Names with mixed character sets with known high risk domains. If a similarity is found, then the EV Certificate Request MUST be flagged as High Risk. The CA must perform reasonably appropriate additional authentication and verification to be certain beyond reasonable doubt that the Applicant and the target in question are the same organization. Add a new Appendix F: Appendix F - Issuance of Certificates for .onion Domain Names A CA may issue an EV Certificate with .onion in the right-most label of the Domain Name provided that issuance complies with the requirements set forth in this Appendix: 1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) The CAB Forum has created an extension of the TBSCertificate for use in conveying hashes of keys related to .onion addresses. The Tor Service Descriptor Hash extension has the following format: cabf-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 } TorServiceDescriptorSyntax ::= SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash TorServiceDescriptorHash:: = SEQUENCE { onionURI UTF8String algorithm AlgorithmIdentifier subjectPublicKeyHash BIT STRING } Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 6234) performed over the DER-encoding of an ASN.1 SubjectPublicKey of the .onion service and SubjectPublicKeyHash is the hash output. 2. The CA MUST verify the Applicant's control over the .onion Domain Name using one of the following: a. The CA MAY verify the Applicant's control over the .onion service by posting a specific value at a well-known URL under RFC5785. b. The CA MAY verify the Applicant's control over the .onion service by having the Applicant provide a Certificate Request signed using the .onion public key if the Attributes section of the certificationRequestInfo contains: (i) A caSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy, 2) is generated by the CA, and 3) delivered to the Applicant through a Verified Method of Communication and (ii) An applicantSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy and 2) is generated by the Applicant. The signing nonce attributes have the following format: caSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-caSigningNonce } } cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } applicantSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-applicantSigningNonce } } cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 } 4. Each Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name MUST conform to the requirements of these Guidelines, including the content requirements in Section 9 and Appendix B of the Baseline Requirements, except that the CA MAY include a wildcard character in the Subject Alternative Name Extension and Subject Common Name Field as the leftmost character in the .onion Domain Name provided inclusion of the wildcard character complies with Section 11.1.3 of the Baseline Requirements. 5. CAs MUST NOT issue a Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name with a validity period longer than 15 months. Despite Section 9.2.1 of the Baseline Requirements deprecating the use of Internal Names, a CA MAY issue a Certificate containing an .onion name with an expiration date later than 1 November 2015 after (and only if) .onion is officially recognized by the IESG as a reserved TLD. 6. On or before February 15, 2015, each CA MUST revoke all Certificates issued with the Subject Alternative Name extension or Common Name field that includes a Domain Name where .onion is in the right-most label of the Domain Name unless the Certificate was issued in compliance with this Appendix F. ---- Motion Ends ----- The review period for this ballot shall commence at 2200 UTC on Thursday, 4 February 2015, and will close at 2200 UTC on Thursday, 11 February 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on Monday, 18 February 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeremy.rowley at digicert.com Wed Feb 4 21:05:19 2015 From: jeremy.rowley at digicert.com (Jeremy Rowley) Date: Wed, 4 Feb 2015 21:05:19 +0000 Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group Message-ID: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> Ballot 143 - Formalization of validation working group ---- Reason ---- In order to address validation issues and inconsistencies in both the SSL Baseline Requirements and the EV Guidelines, the CAB Forum has held an informal working group previously referred to as the Extended Validation Working Group now known as the Validation Working Group, would like to modify its scope to include validation in the Baseline Requirements as well as the EV Guidelines. Jeremy Rowley of DigiCert made the following motion, which was endorsed by Rich Smith of Comodo and Kirk Hall of TrendMicro ---- Motion begins ---- The CA-Browser Forum formally establishes the Validation Working Group as an official working group of the CAB Forum, replacing the previous informal EV working group. The scope of this working group is to address issues arising under adopted CAB Forum standards related to the validation of certificate information and the inclusion of information in certificates. Scope: The Validation Working Group will consider all matters relating to the validation and inclusion of information in certificates under adopted CAB Forum guidelines. Deliverables: The Working Group shall produce one or more documents offering options to the Forum for validation within the scope defined above. ---- Motion Ends ---- The review period for this ballot shall commence at 2200 UTC on 5 Feb 2015, and will close at 2200 UTC on 11 Feb 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on 18 Feb 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Dean_Coclin at symantec.com Wed Feb 4 21:16:11 2015 From: Dean_Coclin at symantec.com (Dean Coclin) Date: Wed, 4 Feb 2015 13:16:11 -0800 Subject: [cabfpub] Draft Agenda for CA/B Forum call February 5, 2015 Message-ID: <14D026C7F297AD44AC82578DD818CDD038EEF0B789@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> We have an open 10 min slot below if anyone has a topic they'd like to discuss. Antitrust Statement: As you know, this meeting includes companies that compete against one another. This meeting is intended to discuss technical standards related to the provision of existing and new types of digital certificates without restricting competition in developing and marketing such certificates. This meeting is not intended to share competitively-sensitive information among competitors, and therefore all participants agree not to discuss or exchange information related to: (a) Pricing policies, pricing formulas, prices or other terms of sale; (b) Costs, cost structures, profit margins, (c) Pending or planned service offerings, (d) Customers, business, or marketing plans; or (e) The allocation of customers, territories, or products in any way. Note: Please announce yourself when you dial in. This helps in documenting attendance when recording is played back later. Here is the proposed agenda: Time Start(UTC) Stop Slot Description Notes / Presenters (Thur) 5 Feb 2015 0:01 16:00 16:01 1 Read Antitrust Statement Dean 0:02 16:01 16:03 2 Roll Call Dean 0:01 16:03 16:04 3 Review Agenda Dean 0:01 16:04 16:05 4 Approve Minutes of 22 Jan 2015 Distributed by Kirk on Jan 23rd 0:20 16:05 16:25 5 Ballot Updates: EV Working Group change, .Onion Ballot, Other EV Ballots? Jeremy, Kirk 0:05 16:25 16:30 6 Vivaldi 0:07 16:30 16:37 7 Any more discussion on IPv6? Ryan 0:10 16:37 16:47 8 Open Slot 0:05 16:45 16:50 9 EV Working Group Status Update Jeremy 0:02 16:50 16:52 10 Code Signing Working Group Status Update Dean/Jeremy -Public draft 0:02 16:52 16:54 11 Policy Review Working Group Status Update Ben/Dean-Boston meeting Jan 27th postponed due to blizzard 0:02 16:54 16:56 12 *New* Information Sharing Working Group Update Ben 0:03 16:56 16:59 13 Any Other Business - Cupertino Meeting-March 10-12: 26 attendees signed up so far 0:00 17:00 17:00 14 Next phone call - February 19, 2015 0:00 17:00 17:00 15 Adjourn -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6130 bytes Desc: not available URL: From jeremy.rowley at digicert.com Wed Feb 4 21:19:45 2015 From: jeremy.rowley at digicert.com (Jeremy Rowley) Date: Wed, 4 Feb 2015 21:19:45 +0000 Subject: [cabfpub] Ballot .onion ballot In-Reply-To: References: Message-ID: <445290cba41444119f8c958eebbcc76a@EX2.corp.digicert.com> One correction. It should have read "right-most" not "left-most". (Fixed below) The following is the finalized onion ballot. I made two changes since we spoke in the last meeting. The first is based on Tom Ritter's feedback. He mentioned that there might be several onion names for a single entity so adding an identifier in the data structure that links the onionURI to the nonce would be helpful. I've included it below. I also realized that without a change to the BRs, CAs could still issue .onion names under the BRs as an internal name OR under the EV Guidelines. Since the goal is to lock down .onion issuance, I added a restriction that all .onion names would need to be revoked by May 1 if the ballot passes. I assume everyone is still willing to endorse? --- Applicants want a CA-signed .onion address for several reasons, including: - Powerful web platform features are restricted to secure origins, which are currently not available to onion names (in part, because of the lack of IANA registration). Permitting EV certs for onion names will help provide a secure origin for the service, moving onion towards use of powerful web platform features. - Currently, access to .onion names over https from a standard browser results in the standard existing 'Invalid Certificate' warning. Training users to click through security warnings lowers the value of these warnings and will cause users to miss important security information. Removing these warnings for the user, through use of a digital certificate, will help users recognize and avoid real MITM attacks. - The public needs attribution of ownership of the .onion address to differentiate onion services, including potential phishing services. Because onion names are not easily recognizable strings, providing the public with additional information about the operator has significant security improvements, especially in regions where use of the incorrect name could have lethal consequences. The following motion has been proposed by Jeremy Rowley of DigiCert and endorsed by Ryan Sleevi of Google and Wayne Thayer of GoDaddy. --------------------- Motion Starts --------------------- Amend Section 9.2.1 of the Baseline Requirements v. 1.2.3 as follows: 9.2.1 Subject Alternative Name Extension Certificate Field: extensions:subjectAltName Required/Optional: Required Contents: This 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. The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate. Wildcard FQDNs are permitted. As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name, the CA SHALL notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016. Also as of the Effective Date, the CA SHALL NOT issue a certificate with an Expiry Date later than 1 November 2015 with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name. Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Name. Effective May 1, 2015, each CA SHALL revoke all unexpired Certificates with an Internal Name using onion as the right-most label in an entry in the subjectAltName Extension or commonName field unless such Certificate was issued in accordance with Appendix F of the EV Guidelines. Amend the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2 as follows: Amend Section 9.2.2 and 11.7.1 as follows: 9.2.2. Subject Alternative Name Extension Certificate field: subjectAltName:dNSName Required/Optional: Required Contents: This extension MUST contain one or more host Domain Name(s) owned or controlled by the Subject and to be associated with the Subject's server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). Wildcard certificates are not allowed for EV Certificates except as permitted under Appendix F. 11.7 Verification of Applicant's Domain Name 11.7.1. Verification Requirements (1) For each Fully-Qualified Domain Name listed in a Certificate, other than a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant (or the Applicant's Parent Company, Subsidiary Company, or Affiliate, collectively referred to as "Applicant" for the purposes of this section) either is the Domain Name Registrant or has control over the FQDN using a procedure specified in Section 11.1.1 of the Baseline Requirements, except that a CA MAY NOT verify a domain using the procedure described 11.1.1(7). For a Certificate issued to a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant's control over the .onion Domain Name in accordance with Appendix F. (2) Mixed Character Set Domain Names: EV Certificates MAY include Domain Names containing mixed character sets only in compliance with the rules set forth by the domain registrar. The CA MUST visually compare any Domain Names with mixed character sets with known high risk domains. If a similarity is found, then the EV Certificate Request MUST be flagged as High Risk. The CA must perform reasonably appropriate additional authentication and verification to be certain beyond reasonable doubt that the Applicant and the target in question are the same organization. Add a new Appendix F: Appendix F - Issuance of Certificates for .onion Domain Names A CA may issue an EV Certificate with .onion in the right-most label of the Domain Name provided that issuance complies with the requirements set forth in this Appendix: 1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) The CAB Forum has created an extension of the TBSCertificate for use in conveying hashes of keys related to .onion addresses. The Tor Service Descriptor Hash extension has the following format: cabf-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 } TorServiceDescriptorSyntax ::= SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash TorServiceDescriptorHash:: = SEQUENCE { onionURI UTF8String algorithm AlgorithmIdentifier subjectPublicKeyHash BIT STRING } Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 6234) performed over the DER-encoding of an ASN.1 SubjectPublicKey of the .onion service and SubjectPublicKeyHash is the hash output. 2. The CA MUST verify the Applicant's control over the .onion Domain Name using one of the following: a. The CA MAY verify the Applicant's control over the .onion service by posting a specific value at a well-known URL under RFC5785. b. The CA MAY verify the Applicant's control over the .onion service by having the Applicant provide a Certificate Request signed using the .onion public key if the Attributes section of the certificationRequestInfo contains: (i) A caSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy, 2) is generated by the CA, and 3) delivered to the Applicant through a Verified Method of Communication and (ii) An applicantSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy and 2) is generated by the Applicant. The signing nonce attributes have the following format: caSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-caSigningNonce } } cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } applicantSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-applicantSigningNonce } } cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 } 4. Each Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name MUST conform to the requirements of these Guidelines, including the content requirements in Section 9 and Appendix B of the Baseline Requirements, except that the CA MAY include a wildcard character in the Subject Alternative Name Extension and Subject Common Name Field as the right-most character in the .onion Domain Name provided inclusion of the wildcard character complies with Section 11.1.3 of the Baseline Requirements. 5. CAs MUST NOT issue a Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name with a validity period longer than 15 months. Despite Section 9.2.1 of the Baseline Requirements deprecating the use of Internal Names, a CA MAY issue a Certificate containing an .onion name with an expiration date later than 1 November 2015 after (and only if) .onion is officially recognized by the IESG as a reserved TLD. 6. On or before February 15, 2015, each CA MUST revoke all Certificates issued with the Subject Alternative Name extension or Common Name field that includes a Domain Name where .onion is in the right-most label of the Domain Name unless the Certificate was issued in compliance with this Appendix F. ---- Motion Ends ----- The review period for this ballot shall commence at 2200 UTC on Thursday, 4 February 2015, and will close at 2200 UTC on Thursday, 11 February 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on Monday, 18 February 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sleevi at google.com Wed Feb 4 22:08:10 2015 From: sleevi at google.com (Ryan Sleevi) Date: Wed, 4 Feb 2015 14:08:10 -0800 Subject: [cabfpub] Ballot .onion ballot In-Reply-To: References: Message-ID: On Wed, Feb 4, 2015 at 12:51 PM, Jeremy Rowley wrote: > I assume everyone is still willing to endorse? Thanks for continuing to work on this. Indeed, willing to. However, note your added revocation clause is duplicated in point 6 (with the earlier Feb 15 date). I'm guessing you just forgot you already had this clause ;) For those considering: This restricts the existing set of capabilities to issue .onion from "Whatever you want" (under internal name rules) to "Under these rules", but does nothing to prolong past the internal names sunset (.onion is still an internal name unless IANA delegates it, and a separate ballot will be needed IF IANA decides to never delegate and reserve as a special-purpose domain) From jeremy.rowley at digicert.com Wed Feb 4 22:10:26 2015 From: jeremy.rowley at digicert.com (Jeremy Rowley) Date: Wed, 4 Feb 2015 22:10:26 +0000 Subject: [cabfpub] Ballot .onion ballot In-Reply-To: References: Message-ID: Thanks - I had it in EV, but that won't effect certs issued under the BRs. I just need to update the dates so they match :) And thanks for the clarification. That's indeed the purpose. If IANA chooses not the reserve the name, we'll need to have a separate discussion on how (and whether) to proceed. -----Original Message----- From: Ryan Sleevi [mailto:sleevi at google.com] Sent: Wednesday, February 4, 2015 3:08 PM To: Jeremy Rowley Cc: CABFPub Subject: Re: [cabfpub] Ballot .onion ballot On Wed, Feb 4, 2015 at 12:51 PM, Jeremy Rowley wrote: > I assume everyone is still willing to endorse? Thanks for continuing to work on this. Indeed, willing to. However, note your added revocation clause is duplicated in point 6 (with the earlier Feb 15 date). I'm guessing you just forgot you already had this clause ;) For those considering: This restricts the existing set of capabilities to issue .onion from "Whatever you want" (under internal name rules) to "Under these rules", but does nothing to prolong past the internal names sunset (.onion is still an internal name unless IANA delegates it, and a separate ballot will be needed IF IANA decides to never delegate and reserve as a special-purpose domain) From wthayer at godaddy.com Thu Feb 5 04:00:39 2015 From: wthayer at godaddy.com (Wayne Thayer) Date: Thu, 5 Feb 2015 04:00:39 +0000 Subject: [cabfpub] Ballot .onion ballot In-Reply-To: References: Message-ID: <8144CFC7-F7F4-4FB4-9CF1-716BB32E4BDC@godaddy.com> Yes, I?ll still endorse. On 2/4/15, 3:10 PM, "Jeremy Rowley" wrote: >I assume everyone is still willing to endorse? From adriano.santoni at staff.aruba.it Thu Feb 5 07:24:51 2015 From: adriano.santoni at staff.aruba.it (Adriano Santoni) Date: Thu, 05 Feb 2015 08:24:51 +0100 Subject: [cabfpub] Draft Agenda for CA/B Forum call February 5, 2015 In-Reply-To: <14D026C7F297AD44AC82578DD818CDD038EEF0B789@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> References: <14D026C7F297AD44AC82578DD818CDD038EEF0B789@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> Message-ID: <54D31AC3.4000009@staff.aruba.it> An HTML attachment was scrubbed... URL: From atsushi.inaba at globalsign.com Thu Feb 5 07:36:05 2015 From: atsushi.inaba at globalsign.com (Atsushi Inaba) Date: Thu, 5 Feb 2015 07:36:05 +0000 Subject: [cabfpub] Draft Agenda for CA/B Forum call February 5, 2015 In-Reply-To: <54D31AC3.4000009@staff.aruba.it> References: <14D026C7F297AD44AC82578DD818CDD038EEF0B789@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> <54D31AC3.4000009@staff.aruba.it> Message-ID: Hello, I suppose that Vivaldi means the browser released recently. Please forgive me if I'm wrong.... Kind regards, Atsushi Inaba From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Adriano Santoni Sent: Thursday, February 5, 2015 4:25 PM To: public at cabforum.org Subject: Re: [cabfpub] Draft Agenda for CA/B Forum call February 5, 2015 Hi all, what is "Vivaldi" ? Adriano Il 04/02/2015 22:16, Dean Coclin ha scritto: We have an open 10 min slot below if anyone has a topic they'd like to discuss. Antitrust Statement: As you know, this meeting includes companies that compete against one another. This meeting is intended to discuss technical standards related to the provision of existing and new types of digital certificates without restricting competition in developing and marketing such certificates. This meeting is not intended to share competitively-sensitive information among competitors, and therefore all participants agree not to discuss or exchange information related to: (a) Pricing policies, pricing formulas, prices or other terms of sale; (b) Costs, cost structures, profit margins, (c) Pending or planned service offerings, (d) Customers, business, or marketing plans; or (e) The allocation of customers, territories, or products in any way. Note: Please announce yourself when you dial in. This helps in documenting attendance when recording is played back later. Here is the proposed agenda: Time Start(UTC) Stop Slot Description Notes / Presenters (Thur) 5 Feb 2015 0:01 16:00 16:01 1 Read Antitrust Statement Dean 0:02 16:01 16:03 2 Roll Call Dean 0:01 16:03 16:04 3 Review Agenda Dean 0:01 16:04 16:05 4 Approve Minutes of 22 Jan 2015 Distributed by Kirk on Jan 23rd 0:20 16:05 16:25 5 Ballot Updates: EV Working Group change, .Onion Ballot, Other EV Ballots? Jeremy, Kirk 0:05 16:25 16:30 6 Vivaldi 0:07 16:30 16:37 7 Any more discussion on IPv6? Ryan 0:10 16:37 16:47 8 Open Slot 0:05 16:45 16:50 9 EV Working Group Status Update Jeremy 0:02 16:50 16:52 10 Code Signing Working Group Status Update Dean/Jeremy -Public draft 0:02 16:52 16:54 11 Policy Review Working Group Status Update Ben/Dean-Boston meeting Jan 27th postponed due to blizzard 0:02 16:54 16:56 12 *New* Information Sharing Working Group Update Ben 0:03 16:56 16:59 13 Any Other Business - Cupertino Meeting-March 10-12: 26 attendees signed up so far 0:00 17:00 17:00 14 Next phone call - February 19, 2015 0:00 17:00 17:00 15 Adjourn _______________________________________________ Public mailing list Public at cabforum.org https://cabforum.org/mailman/listinfo/public -- Adriano Santoni -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4315 bytes Desc: not available URL: From adriano.santoni at staff.aruba.it Thu Feb 5 07:45:57 2015 From: adriano.santoni at staff.aruba.it (Adriano Santoni) Date: Thu, 05 Feb 2015 08:45:57 +0100 Subject: [cabfpub] Draft Agenda for CA/B Forum call February 5, 2015 In-Reply-To: References: <14D026C7F297AD44AC82578DD818CDD038EEF0B789@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> <54D31AC3.4000009@staff.aruba.it> Message-ID: <54D31FB5.4070106@staff.aruba.it> An HTML attachment was scrubbed... URL: From erwann.abalea at opentrust.com Thu Feb 5 10:05:01 2015 From: erwann.abalea at opentrust.com (Erwann Abalea) Date: Thu, 05 Feb 2015 11:05:01 +0100 Subject: [cabfpub] Ballot .onion ballot In-Reply-To: <445290cba41444119f8c958eebbcc76a@EX2.corp.digicert.com> References: <445290cba41444119f8c958eebbcc76a@EX2.corp.digicert.com> Message-ID: <54D3404D.90808@opentrust.com> Bonjour, Le 04/02/2015 22:19, Jeremy Rowley a ?crit : [...] > Amend the Guidelines for the Issuance and Management of Extended > Validation Certificates v1.5.2 as follows: > > Amend Section 9.2.2 and 11.7.1 as follows: > > 9.2.2. Subject Alternative Name Extension Certificate field: > subjectAltName:dNSName > > Required/Optional: Required > > Contents: This extension MUST contain one or more host Domain Name(s) > owned or controlled by the Subject and to be associated with the > Subject's server. Such server MAY be owned and operated by the Subject > or another entity (e.g., a hosting service). Wildcard certificates are > not allowed for EV Certificates_except as permitted under Appendix F_. > So an EV certificate can't be a wildcard one, except under some new conditions, applicable only to .onion names. Not a small change. [...] > Add a new Appendix F: > > Appendix F -- Issuance of Certificates for .onion Domain Names > [...] > 4. Each Certificate that includes a Domain Name where .onion is in the > right-most label of the Domain Name MUST conform to the requirements > of these Guidelines, including the content requirements in Section 9 > and Appendix B of the Baseline Requirements, except that the CA MAY > include a wildcard character in the Subject Alternative Name Extension > and Subject Common Name Field as the right-most character in the > .onion Domain Name provided inclusion of the wildcard character > complies with Section 11.1.3 of the Baseline Requirements. > What does that mean? is *.onion accepted? is *.onion accepted? -- Erwann ABALEA -------------- next part -------------- An HTML attachment was scrubbed... URL: From gerv at mozilla.org Thu Feb 5 10:25:35 2015 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 05 Feb 2015 10:25:35 +0000 Subject: [cabfpub] Ballot .onion ballot In-Reply-To: <54D3404D.90808@opentrust.com> References: <445290cba41444119f8c958eebbcc76a@EX2.corp.digicert.com> <54D3404D.90808@opentrust.com> Message-ID: <54D3451F.4090201@mozilla.org> On 05/02/15 10:05, Erwann Abalea wrote: > What does that mean? > is *.onion accepted? > is *.onion accepted? You are right; this should say "left-most label" not "right-most character". Gerv From erwann.abalea at opentrust.com Thu Feb 5 14:13:59 2015 From: erwann.abalea at opentrust.com (Erwann Abalea) Date: Thu, 05 Feb 2015 15:13:59 +0100 Subject: [cabfpub] Ballot .onion ballot In-Reply-To: <54D3451F.4090201@mozilla.org> References: <445290cba41444119f8c958eebbcc76a@EX2.corp.digicert.com> <54D3404D.90808@opentrust.com> <54D3451F.4090201@mozilla.org> Message-ID: <54D37AA7.8040101@opentrust.com> Le 05/02/2015 11:25, Gervase Markham a ?crit : > On 05/02/15 10:05, Erwann Abalea wrote: >> What does that mean? >> is *.onion accepted? >> is *.onion accepted? > You are right; this should say "left-most label" not "right-most character". Even with this typo corrected, what is the rationale behind allowing wildcard EV certificates for .onion domains while rejecting wildcards for all other EV certs? Why should "*.facebookcorewwwi.onion" be allowed and "*.facebook.com" refused? -- Erwann ABALEA From gerv at mozilla.org Thu Feb 5 14:26:39 2015 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 05 Feb 2015 14:26:39 +0000 Subject: [cabfpub] Ballot .onion ballot In-Reply-To: <54D37AA7.8040101@opentrust.com> References: <445290cba41444119f8c958eebbcc76a@EX2.corp.digicert.com> <54D3404D.90808@opentrust.com> <54D3451F.4090201@mozilla.org> <54D37AA7.8040101@opentrust.com> Message-ID: <54D37D9F.1070907@mozilla.org> On 05/02/15 14:13, Erwann Abalea wrote: > Even with this typo corrected, what is the rationale behind allowing > wildcard EV certificates for .onion domains while rejecting wildcards > for all other EV certs? > > Why should "*.facebookcorewwwi.onion" be allowed and "*.facebook.com" > refused? I'm not the person who argued for a restriction on *.facebook.com EV, but the idea of no wildcard for EV, as I understand it, is that you then get e.g. EV "*.blogspot.com" and the actual person controlling fred.blogspot.com is not named in the EV cert fred.blogspot.com is using, thereby defeating the point of EV as being about identity. With .onion, there is a single private key (the one whose public fingerprint is facebookcorewwwi, in the case of Facebook) and so the idea of different mutually-untrusting entities owning and controlling different parts of the subdomain space doesn't really make much sense. So the above risk is not present. Gerv From jeremy.rowley at digicert.com Thu Feb 5 14:53:27 2015 From: jeremy.rowley at digicert.com (Jeremy Rowley) Date: Thu, 5 Feb 2015 14:53:27 +0000 Subject: [cabfpub] Ballot .onion ballot In-Reply-To: <54D3451F.4090201@mozilla.org> References: <445290cba41444119f8c958eebbcc76a@EX2.corp.digicert.com> <54D3404D.90808@opentrust.com> <54D3451F.4090201@mozilla.org> Message-ID: <2eebcc99c215491d9c19124f51c21f45@EX2.corp.digicert.com> Right - I changed both unintentionally. I'll make this correction and the correction Ryan Sleevi pointed out right after today's call. -----Original Message----- From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Gervase Markham Sent: Thursday, February 5, 2015 3:26 AM To: Erwann Abalea; public at cabforum.org Subject: Re: [cabfpub] Ballot .onion ballot On 05/02/15 10:05, Erwann Abalea wrote: > What does that mean? > is *.onion accepted? > is *.onion accepted? You are right; this should say "left-most label" not "right-most character". Gerv _______________________________________________ Public mailing list Public at cabforum.org https://cabforum.org/mailman/listinfo/public From gerv at mozilla.org Thu Feb 5 15:29:04 2015 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 05 Feb 2015 15:29:04 +0000 Subject: [cabfpub] Not coming to Switzerland in June :-( Message-ID: <54D38C40.90005@mozilla.org> Dear CAB Forum members, Unfortunately, Mozilla has scheduled a get-together the same week as the CAB Forum meeting in Switzerland at the end of June, so I will not be able to make it, or to dial in, and it's unlikely that any other Mozilla representative would be able to either. I don't want to have delusions of my own importance, but it has been noted before that it's important to have browser participation in face-to-face meetings. I also note that our friends at Google and Opera have not been attending in person recently, with their last attendances being: Opera: Meeting 30 (Sep 2013) Google: Meeting 28 (Feb 2013) Hence, I thought I'd note our planned absence so that if Microsoft were not planning to send anyone (and neither were Google or Opera), we could at least discuss whether the CAs in the group would prefer to meet alone, or would prefer to investigate an alternative week (by arrangement with our gracious hosts). Ryan? Jody? Sigbjorn? Gerv From douglas.beattie at globalsign.com Thu Feb 5 16:34:25 2015 From: douglas.beattie at globalsign.com (Doug Beattie) Date: Thu, 5 Feb 2015 16:34:25 +0000 Subject: [cabfpub] Preballot for IPv6 Support In-Reply-To: References: <548F4FAD.8070207@startcom.org> <65e414a19c364c0995474791821af203@EX2.corp.digicert.com> Message-ID: Ryan, GlobalSign, both GlobalSign proper and our CDN provider, support IPv4 and IPv6 for OCSP and CRLs today. Doug From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ryan Sleevi Sent: Wednesday, December 17, 2014 12:50 AM To: Jeremy Rowley Cc: CABFPub Subject: Re: [cabfpub] Preballot for IPv6 Support For the sake of the Forum and those questioning the value of this, I'd like to point out that this is not just theoretical for clients. Consider this message -http://seclists.org/nanog/2014/Dec/114 - to NANOG from one of the largest USP ISPs, Time Warner Cable about the trouble that they're having making a client that "Does PKI right" and the challenges they face (Robert's bio from the ARIN Advisory Council to fill in the value for $DAYJOB - https://www.arin.net/about_us/ac.html#rseastrom ) The lack of IPv6 universally penalizes a client that chooses to support revocation checking, because now in addition to supporting IPv6 on the server, server operators have to be aware of their CA's infrastructure support for IPv6. What's worse, if you look at the incentives, this penalizes the client. From the user's perspective, the choice to implement revocation checking is the fault of the device manufacturer/deployer (Time Warner), rather than an issue with the remote server. The remote server is unlikely to be told by end users that their site doesn't work when using Time Warner devices - instead, Time Warner will be told that the server doesn't work with them. These sorts of penalties have already been reported by browsers that have lead to questioning the revocation strategies, but this is yet another ecosystem affected. On Tue, Dec 16, 2014 at 8:29 PM, Jeremy Rowley > wrote: The proposal is more likely to force CAs into using their own infrastructure to provide revocation information than forcing CDNs and hosting providers to use IPv6, slowing OCSP response times. However, nothing wrong with gathering the information and looking at which CDNs and providers we need to get on board with the proposal. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ryan Sleevi Sent: Monday, December 15, 2014 2:59 PM To: Eddy Nigg Cc: CABFPub Subject: Re: [cabfpub] Preballot for IPv6 Support On Mon, Dec 15, 2014 at 1:16 PM, Eddy Nigg > wrote: On 12/15/2014 11:02 PM, Ryan Sleevi wrote: As discussed on our call last week, I'd like to put together a ballot requiring that CAs support IPv6 for their external (relying party facing) infrastructure. Funny that you want to start with that part first - most of the time that's the part CAs have the least control over it and depend on third parties. I'm not sure I follow this. CAs aren't required to delegate their infrastructure out to third-parties. If they chose to, then they have to pick third-parties who are capable of meeting the Baseline Requirements (e.g. the current 24/7 uptime requirements or the 10 second availability). If a new requirement comes down, the question is how long will it take for the CAs to either get their infrastructure updated, get their third parties to update, or transition to new third parties. That's fundamentally the question I'm asking. This is surely NOT a problem that's impossible. If CAs are telling third parties that they need IPv6 support, then eventually there will be IPv6 support. As both servers and clients transition to IPv6-only networks, the goal is to ensure that services RPs need are accessible. Hardly 5 % as of today - and I assume they all (must) support IPv4 in any case since the vast majority doesn't support IPv6. That's an assumption that is, in part, caused by the unavailability of some services over IPv4. This is a collective action problem, as the CA industry is quite familiar with, so I don't understand why "we don't support it today" is necessarily an argument for why "we shouldn't support it tomorrow". Before proposing dates/timelines, it'd be helpful to understand where the CA's current infrastructure and plans are, so that we can reach a happy medium. I believe this is premature by any standard. Of course CAs may and probably want to support IPv6 as soon as there is a real demand for it. It's also not overly difficult - but the real problem is the third party service providers involved including CDNs and ISPs which must provide IPv6 support first before the CA can. I fail to see how this is premature. It's exactly the same conversation that had to happen with SHA-1 - CAs weren't moving to support it, so eventually timelines had to be set. This is a classic collective action problem, and it's simply a question of what is a reasonable timeframe for CAs to move, and why. You've indicated "CDNs and ISPs must provide IPv6 support first". A number of them do. A number of them don't. The entire point of a preballot is to get a sense of what those numbers are, and for CAs that have contracts with those that do not support IPv6, how long would it take a reasonable CA to support it? You've indicated it's not overly difficult, so is it a matter of 3 months? 6 months? 10 years? That's the set of information that's useful to discuss, rather than assume it will happen. Consider "Real demand for it" being at least one browser with a non-trivial user base requesting it. But besides that I'm a bit curious why Google would have even the slightest interest in revocation checking services and how they are accessed considering that its products don't check revocation in first place :-) 1) This isn't just about revocation checking. As I noted in the preballot, it's also about authorityInfoAccess for intermediates. 2) As I explained in the preballot, this also applies to servers' ability to fetch fresh OCSP responses. I appreciate the feedback, Eddy, but your response seems mostly reactionary, without having read the proposal or justifications provided therein. It'd be helpful to know what concrete concerns you'd have and what it would take to address them. Regardless, I don't think it's a good state in the present form that, for counter-example, a CA could provide an OCSP responder or AIA caIssuers solely available over IPv6, when as you note, there's a non-trivial majority of clients with IPv4-only stacks. So consider this proposal as a way to close that ambiguity as well. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sleevi at google.com Thu Feb 5 16:42:54 2015 From: sleevi at google.com (Ryan Sleevi) Date: Thu, 5 Feb 2015 08:42:54 -0800 Subject: [cabfpub] Not coming to Switzerland in June :-( In-Reply-To: <54D38C40.90005@mozilla.org> References: <54D38C40.90005@mozilla.org> Message-ID: On Thu, Feb 5, 2015 at 7:29 AM, Gervase Markham wrote: > Dear CAB Forum members, > > Unfortunately, Mozilla has scheduled a get-together the same week as the > CAB Forum meeting in Switzerland at the end of June, so I will not be > able to make it, or to dial in, and it's unlikely that any other Mozilla > representative would be able to either. > > I don't want to have delusions of my own importance, but it has been > noted before that it's important to have browser participation in > face-to-face meetings. I also note that our friends at Google and Opera > have not been attending in person recently, with their last attendances > being: > > Opera: Meeting 30 (Sep 2013) > Google: Meeting 28 (Feb 2013) > > Hence, I thought I'd note our planned absence so that if Microsoft were > not planning to send anyone (and neither were Google or Opera), we could > at least discuss whether the CAs in the group would prefer to meet > alone, or would prefer to investigate an alternative week (by > arrangement with our gracious hosts). > > Ryan? Jody? Sigbjorn? > > Gerv Hi Gerv, Looks like you made a typo; we hosted the February 2014 F2F here in Mountain View, and, while unable to attend the Beijing F2F in September, I remotely dialed in for all of the non-WG-specific meetings (which we don't participate in anyways). It's unclear at this time with regards to the Switzerland F2F, but do you have alternate dates or times that might work better for you, so as to inform the discussion? From gerv at mozilla.org Thu Feb 5 16:46:20 2015 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 05 Feb 2015 16:46:20 +0000 Subject: [cabfpub] Not coming to Switzerland in June :-( In-Reply-To: References: <54D38C40.90005@mozilla.org> Message-ID: <54D39E5C.6030505@mozilla.org> On 05/02/15 16:42, Ryan Sleevi wrote: > Looks like you made a typo; we hosted the February 2014 F2F here in > Mountain View, Ah! I was fooled because https://www.cabforum.org/wiki/Meeting%2031 lists no Google people. > It's unclear at this time with regards to the Switzerland F2F, but do > you have alternate dates or times that might work better for you, so > as to inform the discussion? As noted on the call, both the week before and the week after could be made to work for me. Although ideally I'd not be away two weeks on the trot, so a further week either side would actually be a bit better. Gerv From Dean_Coclin at symantec.com Thu Feb 5 17:11:58 2015 From: Dean_Coclin at symantec.com (Dean Coclin) Date: Thu, 5 Feb 2015 09:11:58 -0800 Subject: [cabfpub] Code Signing Baseline Requirements - Final Draft for public exposure Message-ID: <14D026C7F297AD44AC82578DD818CDD038EEF0BA61@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> The Code Signing Working Group of the CA/Browser Forum announces the final draft of the Code Signing Baseline Requirements. This version takes into account comments received in the first round of public review as well as comments from WebTrust auditors. Additional changes/corrections were incorporated by the working group over the past 3 months. This version is being sent out to the public mailing list and will be posted on the CA/B Forum website for final comments until March 6th, 2015. Comments should be sent to: questions at cabforum.org. If there are no further comments, the group plans to propose a ballot to the CA/B Forum in mid-March to approve the Baseline Requirements. The team wishes to thank the following companies/organizations for participating in the working group: CACert Comodo Digicert Entrust ETSI Federal PKI Firmprofessional Globalsign Intarsys Izenpe Microsoft OTA Alliance Startcom Symantec SwissSign Travelport Trend Micro WebTrust WoSign >From the beginning, we have endeavored to keep the document formation process open and inclusive and we hope everyone feels that this contribution is significant to the improvement of Internet security. Dean Coclin CA/B Forum Chair -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Baseline requirements for codesigning - Feb 4 2015.doc Type: application/msword Size: 295424 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Baseline requirements for codesigning - Feb 4 2015 (3).pdf Type: application/pdf Size: 801597 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6130 bytes Desc: not available URL: From Dean_Coclin at symantec.com Thu Feb 5 17:38:57 2015 From: Dean_Coclin at symantec.com (Dean Coclin) Date: Thu, 5 Feb 2015 09:38:57 -0800 Subject: [cabfpub] Not coming to Switzerland in June :-( In-Reply-To: <54D39E5C.6030505@mozilla.org> References: <54D38C40.90005@mozilla.org> <54D39E5C.6030505@mozilla.org> Message-ID: <14D026C7F297AD44AC82578DD818CDD038EEF0BA8C@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> Clearly that list is incorrect (especially since Google hosted the meeting but probably felt they didn't need to sign up for their own venue). But luckily they are present in the Minutes. OK, Kirk and I will discuss this along with the host and put out some suggestions. Dean -----Original Message----- From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Gervase Markham Sent: Thursday, February 05, 2015 11:46 AM To: Ryan Sleevi Cc: CABFPub Subject: Re: [cabfpub] Not coming to Switzerland in June :-( On 05/02/15 16:42, Ryan Sleevi wrote: > Looks like you made a typo; we hosted the February 2014 F2F here in > Mountain View, Ah! I was fooled because https://www.cabforum.org/wiki/Meeting%2031 lists no Google people. > It's unclear at this time with regards to the Switzerland F2F, but do > you have alternate dates or times that might work better for you, so > as to inform the discussion? As noted on the call, both the week before and the week after could be made to work for me. Although ideally I'd not be away two weeks on the trot, so a further week either side would actually be a bit better. Gerv _______________________________________________ Public mailing list Public at cabforum.org https://cabforum.org/mailman/listinfo/public -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6130 bytes Desc: not available URL: From i-barreira at izenpe.net Thu Feb 5 17:44:16 2015 From: i-barreira at izenpe.net (i-barreira at izenpe.net) Date: Thu, 05 Feb 2015 18:44:16 +0100 Subject: [cabfpub] Not coming to Switzerland in June :-( In-Reply-To: A <14D026C7F297AD44AC82578DD818CDD038EEF0BA8C@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> References: <54D38C40.90005@mozilla.org> <54D39E5C.6030505@mozilla.org> A <14D026C7F297AD44AC82578DD818CDD038EEF0BA8C@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> Message-ID: <763539E260C37C46A0D6B340B5434C3B0ACD7C48@AEX06.ejsarea.net> We haven?t heard of the other browsers yet. We can check if we have had some F2F meetings without browsers. Don?t see a major impact since they can dialing in as Ryan did last time, or read the minutes at the end I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. -----Mensaje original----- De: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] En nombre de Dean Coclin Enviado el: jueves, 05 de febrero de 2015 18:39 Para: Gervase Markham; Ryan Sleevi CC: CABFPub Asunto: Re: [cabfpub] Not coming to Switzerland in June :-( Clearly that list is incorrect (especially since Google hosted the meeting but probably felt they didn't need to sign up for their own venue). But luckily they are present in the Minutes. OK, Kirk and I will discuss this along with the host and put out some suggestions. Dean -----Original Message----- From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Gervase Markham Sent: Thursday, February 05, 2015 11:46 AM To: Ryan Sleevi Cc: CABFPub Subject: Re: [cabfpub] Not coming to Switzerland in June :-( On 05/02/15 16:42, Ryan Sleevi wrote: > Looks like you made a typo; we hosted the February 2014 F2F here in > Mountain View, Ah! I was fooled because https://www.cabforum.org/wiki/Meeting%2031 lists no Google people. > It's unclear at this time with regards to the Switzerland F2F, but do > you have alternate dates or times that might work better for you, so > as to inform the discussion? As noted on the call, both the week before and the week after could be made to work for me. Although ideally I'd not be away two weeks on the trot, so a further week either side would actually be a bit better. Gerv _______________________________________________ Public mailing list Public at cabforum.org https://cabforum.org/mailman/listinfo/public From eddy_nigg at startcom.org Thu Feb 5 17:44:49 2015 From: eddy_nigg at startcom.org (Eddy Nigg) Date: Thu, 05 Feb 2015 19:44:49 +0200 Subject: [cabfpub] Ballot .onion ballot In-Reply-To: <54D37D9F.1070907@mozilla.org> References: <445290cba41444119f8c958eebbcc76a@EX2.corp.digicert.com> <54D3404D.90808@opentrust.com> <54D3451F.4090201@mozilla.org> <54D37AA7.8040101@opentrust.com> <54D37D9F.1070907@mozilla.org> Message-ID: <54D3AC11.6050607@startcom.org> On 02/05/2015 04:26 PM, Gervase Markham wrote: > I'm not the person who argued for a restriction on *.facebook.com EV I too might be wrong on this, but according to my memory I recall that you were the person arguing against it when we discussed it last time when we created the BR. :-) IIRC Wayne from Godaddy argued (correctly) that if wild cards should be restricted it would make most sense to have it supported by EV since it's the strongest verification standard currently. EV allows to include domain names of third parties (in my opinion incorrectly), so adding wild cards doesn't change that in any way really. We would be in favor for such a move and believe that wild cards have nothing lost in the non-verified (e.g. DV) settings due to their potential abuse. If at all, wild cards should be permitted with EV and prohibited for DV (if you want anything else than EV). -- Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. XMPP: startcom at startcom.org Blog: Join the Revolution! Twitter: Follow Me -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4313 bytes Desc: S/MIME Cryptographic Signature URL: From sleevi at google.com Thu Feb 5 18:10:33 2015 From: sleevi at google.com (Ryan Sleevi) Date: Thu, 5 Feb 2015 10:10:33 -0800 Subject: [cabfpub] Ballot .onion ballot In-Reply-To: <54D3AC11.6050607@startcom.org> References: <445290cba41444119f8c958eebbcc76a@EX2.corp.digicert.com> <54D3404D.90808@opentrust.com> <54D3451F.4090201@mozilla.org> <54D37AA7.8040101@opentrust.com> <54D37D9F.1070907@mozilla.org> <54D3AC11.6050607@startcom.org> Message-ID: On Thu, Feb 5, 2015 at 9:44 AM, Eddy Nigg wrote: > > On 02/05/2015 04:26 PM, Gervase Markham wrote: > > I'm not the person who argued for a restriction on *.facebook.com EV > > > I too might be wrong on this, but according to my memory I recall that you > were the person arguing against it when we discussed it last time when we > created the BR. :-) > > IIRC Wayne from Godaddy argued (correctly) that if wild cards should be > restricted it would make most sense to have it supported by EV since it's > the strongest verification standard currently. EV allows to include domain > names of third parties (in my opinion incorrectly), so adding wild cards > doesn't change that in any way really. > > We would be in favor for such a move and believe that wild cards have > nothing lost in the non-verified (e.g. DV) settings due to their potential > abuse. If at all, wild cards should be permitted with EV and prohibited for > DV (if you want anything else than EV). > At the risk of derailing the conversation, we'd be opposed to such a proposal (and have said so in the past) To the topic at hand - as it relates specifically to .onion names: The case for wildcards: - The use of origins (RFC 6454 for those unfamiliar with the core concept of web security) provides an effective means to separate privileges and reduce the risks of compromise (in the web sense; this means issues such as XSS) and the privileges granted - The use of separable origins can be beneficial-to-critical to high performance web pages (... unless/until the site is using HTTP/2), due to items such as connection pooling, request prioritization, etc The case against wildcards: - The primary argument against wildcards (for EV) is derived from Section 11.12.1 of EVG 1.5.2. EVG 1.5.2 requires all names be treated as High Risk (as defined in the BRs 1.2.3), which requires that the CA perform some degree of secondary checks (such as names listed on Miller Smiles or Safe Browsing). A wildcard cert allows an entity to request a potentially confusing name (bankofamericacom.facebook.com) that may phish the user. - The secondary argument against wildcards is derived from Section 11.7.1 p2 of EVG 1.5.2, the prohibition against mixed script. A wildcard allows a certificate holder to find any valid construction of IDNA/script at that subordinate domain that may exploit some confusible. Now, I don't feel that the case against is at all strong or relevant. It's long been public record that we don't view certificates as an effective means against phishing, for a wide variety of reasons, and so phishing-level arguments are, to us, particularly specious. The argument against mixed script is also questionable, in as much as it's possible with DV, and it's an issue that browsers (and their rules regarding presentation of punycode vs native scripts) are already handling. For !browser clients, it might be relevant, but I would argue that the EVGs are not exactly relevant to the !browser case. To the broader question about whether wildcards should be prevented or allowed in the EVGs, I suspect this will be the same tension and misaligned interests as the insurance discussion. CAs may perceive one set of value propositions, browsers another. The lack of wildcard support allows for greater price controls, which on a purely business level is a boon, but on a practical security level, would be unfortunate if CAs place profit over security. However, if this does represent some set of concern for CAs (although I would argue unwarranted, for the reasons explained above), then I suspect it can be removed. It just means anyone wanting to use hidden services for accessibility (e.g. as Facebook is doing) will need to invest sizably more, or work out an appropriate cost structure with the CA that allows for bulk purchase, neither of which do much to change the security landscape any. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jodycl at microsoft.com Mon Feb 9 17:54:31 2015 From: jodycl at microsoft.com (Jody Cloutier) Date: Mon, 9 Feb 2015 17:54:31 +0000 Subject: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Message-ID: Microsoft comments on Section 17. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Baseline requirements for codesigning - Feb 4 2015.doc Type: application/msword Size: 310272 bytes Desc: Baseline requirements for codesigning - Feb 4 2015.doc URL: From benedikt at cacert.org Mon Feb 9 23:05:11 2015 From: benedikt at cacert.org (Benedikt Heintel) Date: Tue, 10 Feb 2015 00:05:11 +0100 Subject: [cabfpub] Audit over CA/B BR and WebTrust needed? Message-ID: <54D93D27.6020807@cacert.org> Dear group, Planning the next steps forward, getting our root certificates in the trust stores, we wonder what are the minimum requirements certification wise. Do we need CA/B Baseline Requirements and WebTrust Certification? Is it necessary to go for CA/B BR and ETSI TS 102 042? Is CA/B BR enough? Best Regards Benedikt -- Benedikt Heintel - benedikt at cacert.org CAcert Assurer for People & Organizations CAcert internal Auditor CAcert.org - Secure Together http://www.cacert.org -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3870 bytes Desc: S/MIME Cryptographic Signature URL: From sleevi at google.com Mon Feb 9 23:11:07 2015 From: sleevi at google.com (Ryan Sleevi) Date: Mon, 9 Feb 2015 15:11:07 -0800 Subject: [cabfpub] Audit over CA/B BR and WebTrust needed? In-Reply-To: <54D93D27.6020807@cacert.org> References: <54D93D27.6020807@cacert.org> Message-ID: On Feb 9, 2015 3:05 PM, "Benedikt Heintel" wrote: > > Dear group, > > Planning the next steps forward, getting our root certificates in the > trust stores, we wonder what are the minimum requirements certification > wise. > > Do we need CA/B Baseline Requirements and WebTrust Certification? > Is it necessary to go for CA/B BR and ETSI TS 102 042? Is CA/B BR enough? > > Best Regards > Benedikt > -- > Benedikt Heintel - benedikt at cacert.org > CAcert Assurer for People & Organizations > CAcert internal Auditor > > CAcert.org - Secure Together > http://www.cacert.org > > > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public > That's nominally a question for each root to answer as to what their individual acceptance policies are. To be enabled for the SSL trust bits in Mozilla, for example, you must complete an appropriate audit scheme that incorporates the CA/B Forum Baseline Requirements, as well as comply with the Mozilla Root Inclusion policy. The acceptable audit schemes are listed in https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ For WebTrust, this means Principles and Criteria for CAs 2.0 _and_ SSL BR audit 1.1. -------------- next part -------------- An HTML attachment was scrubbed... URL: From i-barreira at izenpe.net Tue Feb 10 09:17:33 2015 From: i-barreira at izenpe.net (i-barreira at izenpe.net) Date: Tue, 10 Feb 2015 10:17:33 +0100 Subject: [cabfpub] Audit over CA/B BR and WebTrust needed? In-Reply-To: References: <54D93D27.6020807@cacert.org> Message-ID: <763539E260C37C46A0D6B340B5434C3B0ACD8128@AEX06.ejsarea.net> If you have access to the wiki there you can find the different requirements of the browsers plus the information from ETSI and Webtrust. I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. De: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] En nombre de Ryan Sleevi Enviado el: martes, 10 de febrero de 2015 0:11 Para: Benedikt Heintel CC: CABFPub Asunto: Re: [cabfpub] Audit over CA/B BR and WebTrust needed? On Feb 9, 2015 3:05 PM, "Benedikt Heintel" wrote: > > Dear group, > > Planning the next steps forward, getting our root certificates in the > trust stores, we wonder what are the minimum requirements certification > wise. > > Do we need CA/B Baseline Requirements and WebTrust Certification? > Is it necessary to go for CA/B BR and ETSI TS 102 042? Is CA/B BR enough? > > Best Regards > Benedikt > -- > Benedikt Heintel - benedikt at cacert.org > CAcert Assurer for People & Organizations > CAcert internal Auditor > > CAcert.org - Secure Together > http://www.cacert.org > > > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public > That's nominally a question for each root to answer as to what their individual acceptance policies are. To be enabled for the SSL trust bits in Mozilla, for example, you must complete an appropriate audit scheme that incorporates the CA/B Forum Baseline Requirements, as well as comply with the Mozilla Root Inclusion policy. The acceptable audit schemes are listed in https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ For WebTrust, this means Principles and Criteria for CAs 2.0 _and_ SSL BR audit 1.1. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 19121 bytes Desc: image001.png URL: From i-barreira at izenpe.net Tue Feb 10 11:09:24 2015 From: i-barreira at izenpe.net (i-barreira at izenpe.net) Date: Tue, 10 Feb 2015 12:09:24 +0100 Subject: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Message-ID: <763539E260C37C46A0D6B340B5434C3B0ACD81A9@AEX06.ejsarea.net> Hi Jody, Regarding your comment on ETSI audits, I have to say that the ETSI audits shall be performed by accredited auditors as mentioned in Annex E of the current ETSI TS 102 042. ETSI audits performed by not accredited auditors shall be considered invalid. Microsoft is accepting ETSI audits since the very beginning in its root program requirements indicating this requirement. ETSI is providing a list of accredited auditors as mere information because has to be maintained by every NAB (National Accreditation Body). It?s true that this has to be improved regarding the new regulation 910/2014 and the new ENs and will take some time, but at the moment, it?s clearly stated that the audits shall be performed by accredited auditors. Don?t hesitate in contacting me for any additional information or help. Sometimes I?ve received some emails from Tom or Kelvin asking for the qualification of some audits, so, as say, you can contact me regarding this issue. Regards I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. De: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] En nombre de Jody Cloutier Enviado el: lunes, 09 de febrero de 2015 18:55 Para: CABFPub (public at cabforum.org) Asunto: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Microsoft comments on Section 17. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 19121 bytes Desc: image001.png URL: From ben.wilson at digicert.com Tue Feb 10 14:20:29 2015 From: ben.wilson at digicert.com (Ben Wilson) Date: Tue, 10 Feb 2015 14:20:29 +0000 Subject: [cabfpub] Audit over CA/B BR and WebTrust needed? In-Reply-To: <763539E260C37C46A0D6B340B5434C3B0ACD8128@AEX06.ejsarea.net> References: <54D93D27.6020807@cacert.org> <763539E260C37C46A0D6B340B5434C3B0ACD8128@AEX06.ejsarea.net> Message-ID: <5e42a240cc6d404ba88cda81558d7f4e@EX2.corp.digicert.com> I tried to port that all over from the wiki to the public web site. You can find information here - https://cabforum.org/browser-os-info/ and here - https://cabforum.org/audit-criteria/. Going forward, if our website isn?t clear, then we need update the information so that it is. Any member representative interested in improving our web pages should contact me. Thanks, Ben From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of i-barreira at izenpe.net Sent: Tuesday, February 10, 2015 2:18 AM To: sleevi at google.com; benedikt at cacert.org Cc: public at cabforum.org Subject: Re: [cabfpub] Audit over CA/B BR and WebTrust needed? If you have access to the wiki there you can find the different requirements of the browsers plus the information from ETSI and Webtrust. I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. De: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] En nombre de Ryan Sleevi Enviado el: martes, 10 de febrero de 2015 0:11 Para: Benedikt Heintel CC: CABFPub Asunto: Re: [cabfpub] Audit over CA/B BR and WebTrust needed? On Feb 9, 2015 3:05 PM, "Benedikt Heintel" > wrote: > > Dear group, > > Planning the next steps forward, getting our root certificates in the > trust stores, we wonder what are the minimum requirements certification > wise. > > Do we need CA/B Baseline Requirements and WebTrust Certification? > Is it necessary to go for CA/B BR and ETSI TS 102 042? Is CA/B BR enough? > > Best Regards > Benedikt > -- > Benedikt Heintel - benedikt at cacert.org > CAcert Assurer for People & Organizations > CAcert internal Auditor > > CAcert.org - Secure Together > http://www.cacert.org > > > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public > That's nominally a question for each root to answer as to what their individual acceptance policies are. To be enabled for the SSL trust bits in Mozilla, for example, you must complete an appropriate audit scheme that incorporates the CA/B Forum Baseline Requirements, as well as comply with the Mozilla Root Inclusion policy. The acceptable audit schemes are listed in https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ For WebTrust, this means Principles and Criteria for CAs 2.0 _and_ SSL BR audit 1.1. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 19121 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4954 bytes Desc: not available URL: From jeremy.rowley at digicert.com Tue Feb 10 18:38:52 2015 From: jeremy.rowley at digicert.com (Jeremy Rowley) Date: Tue, 10 Feb 2015 18:38:52 +0000 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names Message-ID: Here's the ballot with the two typos fixed: Applicants want a CA-signed .onion address for several reasons, including: - Powerful web platform features are restricted to secure origins, which are currently not available to onion names (in part, because of the lack of IANA registration). Permitting EV certs for onion names will help provide a secure origin for the service, moving onion towards use of powerful web platform features. - Currently, access to .onion names over https from a standard browser results in the standard existing 'Invalid Certificate' warning. Training users to click through security warnings lowers the value of these warnings and will cause users to miss important security information. Removing these warnings for the user, through use of a digital certificate, will help users recognize and avoid real MITM attacks. - The public needs attribution of ownership of the .onion address to differentiate onion services, including potential phishing services. Because onion names are not easily recognizable strings, providing the public with additional information about the operator has significant security improvements, especially in regions where use of the incorrect name could have lethal consequences. The following motion has been proposed by Jeremy Rowley of DigiCert and endorsed by Ryan Sleevi of Google and Wayne Thayer of GoDaddy. --------------------- Motion Starts --------------------- 1) Amend Section 9.2.1 of the Baseline Requirements v. 1.2.3 as follows: 9.2.1 Subject Alternative Name Extension Certificate Field: extensions:subjectAltName Required/Optional: Required Contents: This 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. The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate. Wildcard FQDNs are permitted. As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name, the CA SHALL notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016. Also as of the Effective Date, the CA SHALL NOT issue a certificate with an Expiry Date later than 1 November 2015 with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name. Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Name. Effective May 1, 2015, each CA SHALL revoke all unexpired Certificates with an Internal Name using onion as the right-most label in an entry in the subjectAltName Extension or commonName field unless such Certificate was issued in accordance with Appendix F of the EV Guidelines. 2) Amend Section 9.2.2 and 11.7.1 of the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2 as follows: 9.2.2. Subject Alternative Name Extension Certificate field: subjectAltName:dNSName Required/Optional: Required Contents: This extension MUST contain one or more host Domain Name(s) owned or controlled by the Subject and to be associated with the Subject's server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). Wildcard certificates are not allowed for EV Certificates except as permitted under Appendix F. 11.7 Verification of Applicant's Domain Name 11.7.1. Verification Requirements (1) For each Fully-Qualified Domain Name listed in a Certificate, other than a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant (or the Applicant's Parent Company, Subsidiary Company, or Affiliate, collectively referred to as "Applicant" for the purposes of this section) either is the Domain Name Registrant or has control over the FQDN using a procedure specified in Section 11.1.1 of the Baseline Requirements, except that a CA MAY NOT verify a domain using the procedure described 11.1.1(7). For a Certificate issued to a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant's control over the .onion Domain Name in accordance with Appendix F. (2) Mixed Character Set Domain Names: EV Certificates MAY include Domain Names containing mixed character sets only in compliance with the rules set forth by the domain registrar. The CA MUST visually compare any Domain Names with mixed character sets with known high risk domains. If a similarity is found, then the EV Certificate Request MUST be flagged as High Risk. The CA must perform reasonably appropriate additional authentication and verification to be certain beyond reasonable doubt that the Applicant and the target in question are the same organization. 3) Add a new Appendix F to the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2: Appendix F - Issuance of Certificates for .onion Domain Names A CA may issue an EV Certificate with .onion in the right-most label of the Domain Name provided that issuance complies with the requirements set forth in this Appendix: 1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) The CAB Forum has created an extension of the TBSCertificate for use in conveying hashes of keys related to .onion addresses. The Tor Service Descriptor Hash extension has the following format: cabf-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 } TorServiceDescriptorSyntax ::= SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash TorServiceDescriptorHash:: = SEQUENCE { onionURI UTF8String algorithm AlgorithmIdentifier subjectPublicKeyHash BIT STRING } Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 6234) performed over the DER-encoding of an ASN.1 SubjectPublicKey of the .onion service and SubjectPublicKeyHash is the hash output. 2. The CA MUST verify the Applicant's control over the .onion Domain Name using one of the following: a. The CA MAY verify the Applicant's control over the .onion service by posting a specific value at a well-known URL under RFC5785. b. The CA MAY verify the Applicant's control over the .onion service by having the Applicant provide a Certificate Request signed using the .onion public key if the Attributes section of the certificationRequestInfo contains: (i) A caSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy, 2) is generated by the CA, and 3) delivered to the Applicant through a Verified Method of Communication and (ii) An applicantSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy and 2) is generated by the Applicant. The signing nonce attributes have the following format: caSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-caSigningNonce } } cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } applicantSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-applicantSigningNonce } } cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 } 4. Each Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name MUST conform to the requirements of these Guidelines, including the content requirements in Section 9 and Appendix B of the Baseline Requirements, except that the CA MAY include a wildcard character in the Subject Alternative Name Extension and Subject Common Name Field as the left-most character in the .onion Domain Name provided inclusion of the wildcard character complies with Section 11.1.3 of the Baseline Requirements. 5. CAs MUST NOT issue a Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name with a validity period longer than 15 months. Despite Section 9.2.1 of the Baseline Requirements deprecating the use of Internal Names, a CA MAY issue a Certificate containing an .onion name with an expiration date later than 1 November 2015 after (and only if) .onion is officially recognized by the IESG as a reserved TLD. 6. On or before May 1, 2015, each CA MUST revoke all Certificates issued with the Subject Alternative Name extension or Common Name field that includes a Domain Name where .onion is in the right-most label of the Domain Name unless the Certificate was issued in compliance with this Appendix F. ---- Motion Ends ----- The review period for this ballot shall commence at 2200 UTC on Thursday, 4 February 2015, and will close at 2200 UTC on Thursday, 11 February 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on Monday, 18 February 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.wilson at digicert.com Tue Feb 10 21:02:17 2015 From: ben.wilson at digicert.com (Ben Wilson) Date: Tue, 10 Feb 2015 21:02:17 +0000 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names In-Reply-To: References: Message-ID: <5c04557077cf4564979bc37e501297de@EX2.corp.digicert.com> I'll post this to the public page with a correction stating that the review period ends and the voting period of the ballot begins to run from Wednesday, 11 Feb., to Wednesday, 18 Feb. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Tuesday, February 10, 2015 11:39 AM To: public at cabforum.org Subject: [cabfpub] Ballot 144 - Validation rules for .onion names Here's the ballot with the two typos fixed: Applicants want a CA-signed .onion address for several reasons, including: - Powerful web platform features are restricted to secure origins, which are currently not available to onion names (in part, because of the lack of IANA registration). Permitting EV certs for onion names will help provide a secure origin for the service, moving onion towards use of powerful web platform features. - Currently, access to .onion names over https from a standard browser results in the standard existing 'Invalid Certificate' warning. Training users to click through security warnings lowers the value of these warnings and will cause users to miss important security information. Removing these warnings for the user, through use of a digital certificate, will help users recognize and avoid real MITM attacks. - The public needs attribution of ownership of the .onion address to differentiate onion services, including potential phishing services. Because onion names are not easily recognizable strings, providing the public with additional information about the operator has significant security improvements, especially in regions where use of the incorrect name could have lethal consequences. The following motion has been proposed by Jeremy Rowley of DigiCert and endorsed by Ryan Sleevi of Google and Wayne Thayer of GoDaddy. --------------------- Motion Starts --------------------- 1) Amend Section 9.2.1 of the Baseline Requirements v. 1.2.3 as follows: 9.2.1 Subject Alternative Name Extension Certificate Field: extensions:subjectAltName Required/Optional: Required Contents: This 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. The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate. Wildcard FQDNs are permitted. As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name, the CA SHALL notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016. Also as of the Effective Date, the CA SHALL NOT issue a certificate with an Expiry Date later than 1 November 2015 with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name. Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Name. Effective May 1, 2015, each CA SHALL revoke all unexpired Certificates with an Internal Name using onion as the right-most label in an entry in the subjectAltName Extension or commonName field unless such Certificate was issued in accordance with Appendix F of the EV Guidelines. 2) Amend Section 9.2.2 and 11.7.1 of the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2 as follows: 9.2.2. Subject Alternative Name Extension Certificate field: subjectAltName:dNSName Required/Optional: Required Contents: This extension MUST contain one or more host Domain Name(s) owned or controlled by the Subject and to be associated with the Subject's server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). Wildcard certificates are not allowed for EV Certificates except as permitted under Appendix F. 11.7 Verification of Applicant's Domain Name 11.7.1. Verification Requirements (1) For each Fully-Qualified Domain Name listed in a Certificate, other than a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant (or the Applicant's Parent Company, Subsidiary Company, or Affiliate, collectively referred to as "Applicant" for the purposes of this section) either is the Domain Name Registrant or has control over the FQDN using a procedure specified in Section 11.1.1 of the Baseline Requirements, except that a CA MAY NOT verify a domain using the procedure described 11.1.1(7). For a Certificate issued to a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant's control over the .onion Domain Name in accordance with Appendix F. (2) Mixed Character Set Domain Names: EV Certificates MAY include Domain Names containing mixed character sets only in compliance with the rules set forth by the domain registrar. The CA MUST visually compare any Domain Names with mixed character sets with known high risk domains. If a similarity is found, then the EV Certificate Request MUST be flagged as High Risk. The CA must perform reasonably appropriate additional authentication and verification to be certain beyond reasonable doubt that the Applicant and the target in question are the same organization. 3) Add a new Appendix F to the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2: Appendix F - Issuance of Certificates for .onion Domain Names A CA may issue an EV Certificate with .onion in the right-most label of the Domain Name provided that issuance complies with the requirements set forth in this Appendix: 1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) The CAB Forum has created an extension of the TBSCertificate for use in conveying hashes of keys related to .onion addresses. The Tor Service Descriptor Hash extension has the following format: cabf-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 } TorServiceDescriptorSyntax ::= SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash TorServiceDescriptorHash:: = SEQUENCE { onionURI UTF8String algorithm AlgorithmIdentifier subjectPublicKeyHash BIT STRING } Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 6234) performed over the DER-encoding of an ASN.1 SubjectPublicKey of the .onion service and SubjectPublicKeyHash is the hash output. 2. The CA MUST verify the Applicant's control over the .onion Domain Name using one of the following: a. The CA MAY verify the Applicant's control over the .onion service by posting a specific value at a well-known URL under RFC5785. b. The CA MAY verify the Applicant's control over the .onion service by having the Applicant provide a Certificate Request signed using the .onion public key if the Attributes section of the certificationRequestInfo contains: (i) A caSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy, 2) is generated by the CA, and 3) delivered to the Applicant through a Verified Method of Communication and (ii) An applicantSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy and 2) is generated by the Applicant. The signing nonce attributes have the following format: caSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-caSigningNonce } } cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } applicantSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-applicantSigningNonce } } cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 } 4. Each Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name MUST conform to the requirements of these Guidelines, including the content requirements in Section 9 and Appendix B of the Baseline Requirements, except that the CA MAY include a wildcard character in the Subject Alternative Name Extension and Subject Common Name Field as the left-most character in the .onion Domain Name provided inclusion of the wildcard character complies with Section 11.1.3 of the Baseline Requirements. 5. CAs MUST NOT issue a Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name with a validity period longer than 15 months. Despite Section 9.2.1 of the Baseline Requirements deprecating the use of Internal Names, a CA MAY issue a Certificate containing an .onion name with an expiration date later than 1 November 2015 after (and only if) .onion is officially recognized by the IESG as a reserved TLD. 6. On or before May 1, 2015, each CA MUST revoke all Certificates issued with the Subject Alternative Name extension or Common Name field that includes a Domain Name where .onion is in the right-most label of the Domain Name unless the Certificate was issued in compliance with this Appendix F. ---- Motion Ends ----- The review period for this ballot shall commence at 2200 UTC on Thursday, 4 February 2015, and will close at 2200 UTC on Thursday, 11 February 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on Monday, 18 February 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4954 bytes Desc: not available URL: From jodycl at microsoft.com Tue Feb 10 23:32:19 2015 From: jodycl at microsoft.com (Jody Cloutier) Date: Tue, 10 Feb 2015 23:32:19 +0000 Subject: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc In-Reply-To: <763539E260C37C46A0D6B340B5434C3B0ACD81A9@AEX06.ejsarea.net> References: <763539E260C37C46A0D6B340B5434C3B0ACD81A9@AEX06.ejsarea.net> Message-ID: Thank you, Inigo. I think the problem is that, under ETSI, it's difficult to discern what an "equivalent national scheme" is. This sets up the scenario in which an auditor is employed by an organization that is recognized somehow by the government, but is not affiliated with an ETSI member organization (http://www.european-accreditation.org/home ). Microsoft does not know whether or not this auditor is qualified or not. For example, ? Company A is a commercial CA that operates in Israel ? Auditor Jones works for AuditCo, which is based in Israel ? AuditCo is certified by some governmental agency as a qualified auditor ? AuditCo is not an ETSI Member or Associate Member ? Auditor Jones audits Company A using the ETSI 102042 standard, and Company A sends the auditor's attestation letter to Microsoft as evidence that Company A complied with the Program's requirements. In this scenario, how does Microsoft know that Auditor Jones conducted a proper audit without expending significant resources to determine whether and according to what standard AuditCo and Auditor Jones was certified? Microsoft believes that it would be simpler if the requirements were that the Auditor must work for a company that is affiliated with an ETSI-approved member organization. If Company A needs an auditor and there is no qualified auditor in Israel, the company can use an auditor from a member organization via the cross-border conformity rules. Unless I am fundamentally misunderstanding the rules, the above is something that Microsoft is presently struggling with, and we'd like to try to make the rules easier to understand for potential partners and ourselves. Jody Cloutier Senior Security Program Manager Microsoft Trusted Root Certificate Program jody.cloutier at microsoft.com 425.443.8922 Operating Systems Group Global Risk and Compliance [https://brandtools.microsoft.com/Style%20Library/BT/Images/MicrosoftMasterLogo.png] From: i-barreira at izenpe.net [mailto:i-barreira at izenpe.net] Sent: Tuesday, February 10, 2015 3:09 AM To: Jody Cloutier; public at cabforum.org Subject: RE: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Hi Jody, Regarding your comment on ETSI audits, I have to say that the ETSI audits shall be performed by accredited auditors as mentioned in Annex E of the current ETSI TS 102 042. ETSI audits performed by not accredited auditors shall be considered invalid. Microsoft is accepting ETSI audits since the very beginning in its root program requirements indicating this requirement. ETSI is providing a list of accredited auditors as mere information because has to be maintained by every NAB (National Accreditation Body). It?s true that this has to be improved regarding the new regulation 910/2014 and the new ENs and will take some time, but at the moment, it?s clearly stated that the audits shall be performed by accredited auditors. Don?t hesitate in contacting me for any additional information or help. Sometimes I?ve received some emails from Tom or Kelvin asking for the qualification of some audits, so, as say, you can contact me regarding this issue. Regards I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 [Descripci?n: cid:image001.png at 01CE3152.B4804EB0] ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. De: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] En nombre de Jody Cloutier Enviado el: lunes, 09 de febrero de 2015 18:55 Para: CABFPub (public at cabforum.org) Asunto: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Microsoft comments on Section 17. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 19121 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 1181 bytes Desc: image002.png URL: From haavardm at opera.com Wed Feb 11 14:32:07 2015 From: haavardm at opera.com (haavardm at work) Date: Wed, 11 Feb 2015 15:32:07 +0100 Subject: [cabfpub] Not coming to Switzerland in June :-( In-Reply-To: <54D38C40.90005@mozilla.org> References: <54D38C40.90005@mozilla.org> Message-ID: Hi Gerv, Depending on a few internal factors, we are considering sending one representative to the Switzerland meeting. If so, either me or Sigbj?rn will attend. Cheers, H?vard On Thu, Feb 5, 2015 at 4:29 PM, Gervase Markham wrote: > Dear CAB Forum members, > > Unfortunately, Mozilla has scheduled a get-together the same week as the > CAB Forum meeting in Switzerland at the end of June, so I will not be > able to make it, or to dial in, and it's unlikely that any other Mozilla > representative would be able to either. > > I don't want to have delusions of my own importance, but it has been > noted before that it's important to have browser participation in > face-to-face meetings. I also note that our friends at Google and Opera > have not been attending in person recently, with their last attendances > being: > > Opera: Meeting 30 (Sep 2013) > Google: Meeting 28 (Feb 2013) > > Hence, I thought I'd note our planned absence so that if Microsoft were > not planning to send anyone (and neither were Google or Opera), we could > at least discuss whether the CAs in the group would prefer to meet > alone, or would prefer to investigate an alternative week (by > arrangement with our gracious hosts). > > Ryan? Jody? Sigbjorn? > > Gerv > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.wilson at digicert.com Wed Feb 11 21:21:37 2015 From: ben.wilson at digicert.com (Ben Wilson) Date: Wed, 11 Feb 2015 21:21:37 +0000 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names In-Reply-To: <5c04557077cf4564979bc37e501297de@EX2.corp.digicert.com> References: <5c04557077cf4564979bc37e501297de@EX2.corp.digicert.com> Message-ID: <3ff9a59417eb41ff98aed77794f075e2@EX2.corp.digicert.com> I've posted the ballot here - https://cabforum.org/2015/02/11/ballot-144-validation-rules-dot-onion-names/ Voting begins in 40 minutes and lasts for 7 days. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ben Wilson Sent: Tuesday, February 10, 2015 2:02 PM To: public at cabforum.org Subject: Re: [cabfpub] Ballot 144 - Validation rules for .onion names I'll post this to the public page with a correction stating that the review period ends and the voting period of the ballot begins to run from Wednesday, 11 Feb., to Wednesday, 18 Feb. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Tuesday, February 10, 2015 11:39 AM To: public at cabforum.org Subject: [cabfpub] Ballot 144 - Validation rules for .onion names Here's the ballot with the two typos fixed: Applicants want a CA-signed .onion address for several reasons, including: - Powerful web platform features are restricted to secure origins, which are currently not available to onion names (in part, because of the lack of IANA registration). Permitting EV certs for onion names will help provide a secure origin for the service, moving onion towards use of powerful web platform features. - Currently, access to .onion names over https from a standard browser results in the standard existing 'Invalid Certificate' warning. Training users to click through security warnings lowers the value of these warnings and will cause users to miss important security information. Removing these warnings for the user, through use of a digital certificate, will help users recognize and avoid real MITM attacks. - The public needs attribution of ownership of the .onion address to differentiate onion services, including potential phishing services. Because onion names are not easily recognizable strings, providing the public with additional information about the operator has significant security improvements, especially in regions where use of the incorrect name could have lethal consequences. The following motion has been proposed by Jeremy Rowley of DigiCert and endorsed by Ryan Sleevi of Google and Wayne Thayer of GoDaddy. --------------------- Motion Starts --------------------- 1) Amend Section 9.2.1 of the Baseline Requirements v. 1.2.3 as follows: 9.2.1 Subject Alternative Name Extension Certificate Field: extensions:subjectAltName Required/Optional: Required Contents: This 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. The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate. Wildcard FQDNs are permitted. As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name, the CA SHALL notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016. Also as of the Effective Date, the CA SHALL NOT issue a certificate with an Expiry Date later than 1 November 2015 with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name. Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Name. Effective May 1, 2015, each CA SHALL revoke all unexpired Certificates with an Internal Name using onion as the right-most label in an entry in the subjectAltName Extension or commonName field unless such Certificate was issued in accordance with Appendix F of the EV Guidelines. 2) Amend Section 9.2.2 and 11.7.1 of the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2 as follows: 9.2.2. Subject Alternative Name Extension Certificate field: subjectAltName:dNSName Required/Optional: Required Contents: This extension MUST contain one or more host Domain Name(s) owned or controlled by the Subject and to be associated with the Subject's server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). Wildcard certificates are not allowed for EV Certificates except as permitted under Appendix F. 11.7 Verification of Applicant's Domain Name 11.7.1. Verification Requirements (1) For each Fully-Qualified Domain Name listed in a Certificate, other than a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant (or the Applicant's Parent Company, Subsidiary Company, or Affiliate, collectively referred to as "Applicant" for the purposes of this section) either is the Domain Name Registrant or has control over the FQDN using a procedure specified in Section 11.1.1 of the Baseline Requirements, except that a CA MAY NOT verify a domain using the procedure described 11.1.1(7). For a Certificate issued to a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant's control over the .onion Domain Name in accordance with Appendix F. (2) Mixed Character Set Domain Names: EV Certificates MAY include Domain Names containing mixed character sets only in compliance with the rules set forth by the domain registrar. The CA MUST visually compare any Domain Names with mixed character sets with known high risk domains. If a similarity is found, then the EV Certificate Request MUST be flagged as High Risk. The CA must perform reasonably appropriate additional authentication and verification to be certain beyond reasonable doubt that the Applicant and the target in question are the same organization. 3) Add a new Appendix F to the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2: Appendix F - Issuance of Certificates for .onion Domain Names A CA may issue an EV Certificate with .onion in the right-most label of the Domain Name provided that issuance complies with the requirements set forth in this Appendix: 1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) The CAB Forum has created an extension of the TBSCertificate for use in conveying hashes of keys related to .onion addresses. The Tor Service Descriptor Hash extension has the following format: cabf-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 } TorServiceDescriptorSyntax ::= SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash TorServiceDescriptorHash:: = SEQUENCE { onionURI UTF8String algorithm AlgorithmIdentifier subjectPublicKeyHash BIT STRING } Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 6234) performed over the DER-encoding of an ASN.1 SubjectPublicKey of the .onion service and SubjectPublicKeyHash is the hash output. 2. The CA MUST verify the Applicant's control over the .onion Domain Name using one of the following: a. The CA MAY verify the Applicant's control over the .onion service by posting a specific value at a well-known URL under RFC5785. b. The CA MAY verify the Applicant's control over the .onion service by having the Applicant provide a Certificate Request signed using the .onion public key if the Attributes section of the certificationRequestInfo contains: (i) A caSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy, 2) is generated by the CA, and 3) delivered to the Applicant through a Verified Method of Communication and (ii) An applicantSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy and 2) is generated by the Applicant. The signing nonce attributes have the following format: caSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-caSigningNonce } } cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } applicantSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-applicantSigningNonce } } cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 } 4. Each Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name MUST conform to the requirements of these Guidelines, including the content requirements in Section 9 and Appendix B of the Baseline Requirements, except that the CA MAY include a wildcard character in the Subject Alternative Name Extension and Subject Common Name Field as the left-most character in the .onion Domain Name provided inclusion of the wildcard character complies with Section 11.1.3 of the Baseline Requirements. 5. CAs MUST NOT issue a Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name with a validity period longer than 15 months. Despite Section 9.2.1 of the Baseline Requirements deprecating the use of Internal Names, a CA MAY issue a Certificate containing an .onion name with an expiration date later than 1 November 2015 after (and only if) .onion is officially recognized by the IESG as a reserved TLD. 6. On or before May 1, 2015, each CA MUST revoke all Certificates issued with the Subject Alternative Name extension or Common Name field that includes a Domain Name where .onion is in the right-most label of the Domain Name unless the Certificate was issued in compliance with this Appendix F. ---- Motion Ends ----- The review period for this ballot shall commence at 2200 UTC on Thursday, 4 February 2015, and will close at 2200 UTC on Thursday, 11 February 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on Monday, 18 February 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4954 bytes Desc: not available URL: From arno.fiedler at nimbus-berlin.com Thu Feb 12 08:44:33 2015 From: arno.fiedler at nimbus-berlin.com (Arno Fiedler) Date: Thu, 12 Feb 2015 09:44:33 +0100 Subject: [cabfpub] CA-Day in Berlin on 09.06.15 In-Reply-To: References: <54D93D27.6020807@cacert.org> Message-ID: <54DC67F1.7030209@nimbus-berlin.com> Hello, please save the date: TSP Compliance Info-Day "eIDAS and Trust Service Provider Conformity Assessment" Organizer: T?VIT, Bundesdruckerei, Date: Tuesday, 09.06.2015 from 10:00 AM to 05:00 PM Venue: T?VIT at Microsoft Berlin, Unter den Linden Best regards Arno Fiedler -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: arno_fiedler.vcf Type: text/x-vcard Size: 302 bytes Desc: not available URL: From kirk_hall at trendmicro.com Thu Feb 12 20:43:36 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Thu, 12 Feb 2015 20:43:36 +0000 Subject: [cabfpub] Ballot 144 -.onion domains Message-ID: Jeremy and Ben - sorry we didn't ask these questions last week, but I was travelling and didn't realize the comment period had begun. (1) We are concerned that under Ballot 144 there could be two .onion certs with the SAME domain but identifying two DIFFERENT subjects. For example, Evil Corp. and Angel Corp. could each submit a request for a .onion cert and get the same domain: [same 16 digit hash of their public keys].onion if their public keys hash to the same value. One cert would say O=Evil Corp. the other would say O=Angel Corp., so that a .onion domain would not be uniquely identified with one subject. While unlikely, it could happen. How does Tor resolve this if the same .onion domain is assigned to multiple, different subjects? If someone types in [16 digit hash].onion and that could lead to multiple Tor locations, how does Tor decide where to direct the user? (2) Does this also create an opportunity for a hacker? For example, one of the .onion domains in the SANs field of the Facebook cert you created is *.xx.fbcdn23dssr3jqnq.onion - could a hacker create a public key that would hash to the same value in order to get a cert with the same .onion domain and imitate the Facebook cert? (This is maybe the more serious case.) (3) Another concern is there is no central registry to identify the owner of a .onion domain (of course, there could be multiple owners of the domain under the scenario above). If there is no Subject info in the O field, etc., with no registry there is no real way to contact the domain (or cert owner). Any information you can provide on these point will be very helpful. 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
-------------- next part -------------- An HTML attachment was scrubbed... URL: From kirk_hall at trendmicro.com Thu Feb 12 20:45:45 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Thu, 12 Feb 2015 20:45:45 +0000 Subject: [cabfpub] Ballot 144 -.onion domains Message-ID: Here are screen shots of the Facebook.com cert, if anyone hasn't seen it. The .onion domains are in the second shot in the SANs field. [cid:image001.png at 01D046C1.D1682440] [cid:image002.png at 01D046C1.D1682440] From: Kirk Hall (RD-US) Sent: Thursday, February 12, 2015 12:44 PM To: Jeremy Rowley (jeremy.rowley at digicert.com); Ben Wilson (Ben.Wilson at digicert.com) Cc: CABFPub (public at cabforum.org) Subject: Ballot 144 -.onion domains Jeremy and Ben - sorry we didn't ask these questions last week, but I was travelling and didn't realize the comment period had begun. (1) We are concerned that under Ballot 144 there could be two .onion certs with the SAME domain but identifying two DIFFERENT subjects. For example, Evil Corp. and Angel Corp. could each submit a request for a .onion cert and get the same domain: [same 16 digit hash of their public keys].onion if their public keys hash to the same value. One cert would say O=Evil Corp. the other would say O=Angel Corp., so that a .onion domain would not be uniquely identified with one subject. While unlikely, it could happen. How does Tor resolve this if the same .onion domain is assigned to multiple, different subjects? If someone types in [16 digit hash].onion and that could lead to multiple Tor locations, how does Tor decide where to direct the user? (2) Does this also create an opportunity for a hacker? For example, one of the .onion domains in the SANs field of the Facebook cert you created is *.xx.fbcdn23dssr3jqnq.onion - could a hacker create a public key that would hash to the same value in order to get a cert with the same .onion domain and imitate the Facebook cert? (This is maybe the more serious case.) (3) Another concern is there is no central registry to identify the owner of a .onion domain (of course, there could be multiple owners of the domain under the scenario above). If there is no Subject info in the O field, etc., with no registry there is no real way to contact the domain (or cert owner). Any information you can provide on these point will be very helpful. 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
-------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 49635 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 51544 bytes Desc: image002.png URL: From sleevi at google.com Thu Feb 12 21:01:58 2015 From: sleevi at google.com (Ryan Sleevi) Date: Thu, 12 Feb 2015 13:01:58 -0800 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: References: Message-ID: On Feb 12, 2015 12:43 PM, "kirk_hall at trendmicro.com" < kirk_hall at trendmicro.com> wrote: > > Jeremy and Ben ? sorry we didn?t ask these questions last week, but I was travelling and didn?t realize the comment period had begun. > > > > (1) We are concerned that under Ballot 144 there could be two .onion certs with the SAME domain but identifying two DIFFERENT subjects. > > > > For example, Evil Corp. and Angel Corp. could each submit a request for a .onion cert and get the same domain: [same 16 digit hash of their public keys].onion if their public keys hash to the same value. One cert would say O=Evil Corp. the other would say O=Angel Corp., so that a .onion domain would not be uniquely identified with one subject. While unlikely, it could happen. > > > > How does Tor resolve this if the same .onion domain is assigned to multiple, different subjects? If someone types in [16 digit hash].onion and that could lead to multiple Tor locations, how does Tor decide where to direct the user? > > Hi Kirk, While not Jeremy, this is actually why I suggested that the full public key be included within the issued certificate itself, so as to highlight any hash collision attempts on the onion private key (e.g. by funkily encoding key parameters or by using key confusion). On a practical level, it's far out there from the realm of being feasible, but it's enough of an issue that I felt important that this should be included in the issued cert, so that sites could use, for example, certificate transparency to monitor for such things. On the TOR side, the protocol is being revved to deal with this, but it is described more at https://trac.torproject.org/projects/tor/wiki/doc/HiddenServiceNames So from the issuance side, the mitigations are including the full public key as well as requiring the EV validation, rather than DV. > > (2) Does this also create an opportunity for a hacker? For example, one of the .onion domains in the SANs field of the Facebook cert you created is *.xx.fbcdn23dssr3jqnq.onion ? could a hacker create a public key that would hash to the same value in order to get a cert with the same .onion domain and imitate the Facebook cert? (This is maybe the more serious case.) > Isn't this a restatement of 1? Or at least, the answers there would still apply. > (3) Another concern is there is no central registry to identify the owner of a .onion domain (of course, there could be multiple owners of the domain under the scenario above). If there is no Subject info in the O field, etc., with no registry there is no real way to contact the domain (or cert owner). > I'm not entirely sure I follow? Note during the discussion phase also included discussion about requiring one or more DNS names from the IANA zone as well, which seems like it would mitigate this concern. > > > Any information you can provide on these point will be very helpful. > I think it is important when considering these that, as of today, any CA can issue any name under .onion under the "Internal Names" exception. This proposal merely restricts it from being "any rules you want" to "more stringent verification required" It still treats .onion as an internal name, in as much as they still sunset and must be revoked. If this ballot fails, every CA will still be able to issue .onion names to any party they wish, including parties who have no relationship whatsoever to the onion HS. That is, if this fails, there is no requirement for attackers to execute a hash collision or factor a private key - they just need to find a CA willing to issue under the "Internal Names" rule (which, as you know, is typically validated at a level less than EV, such as OV). That's why I think this ballot is good - it doesn't prolong or extend risk, it actually _restricts_ issuance in this space until internal names are sunset, at which point, no more of these certs will be issued, no matter the rules. In practice, I expect discussion and standardization to continue, and we may see DigiCert issue a ballot in half a year that looks to extend such issuance, but that's not this ballot, thankfully, so we don't have to solve all of these issues right away. > > > > > TREND MICRO EMAIL NOTICE > The information contained in this email and any attachments is confidential > and may be subject to copyright or other intellectual property protection. > If you are not the intended recipient, you are not authorized to use or > disclose this information, and we request that you notify us by reply mail or > telephone and delete the original message from your mail system. > > > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gerv at mozilla.org Thu Feb 12 21:41:01 2015 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 12 Feb 2015 21:41:01 +0000 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: References: Message-ID: <54DD1DED.4090105@mozilla.org> On 12/02/15 20:43, kirk_hall at trendmicro.com wrote: > For example, Evil Corp. and Angel Corp. could each submit a request for > a .onion cert and get the same domain: _[same 16 digit hash of their > public keys].onion_ if their public keys hash to the same value. One > cert would say O=Evil Corp. the other would say O=Angel Corp., so that a > .onion domain would not be uniquely identified with one subject. While > unlikely, it could happen. Have you been able to put a figure on the likelihood of this occurrence? I think I could calculate it, but I'm interested in what figure you came up with that led to your concern. > (2) Does this also create an opportunity for a hacker? For example, > one of the .onion domains in the SANs field of the Facebook cert you > created is _*.xx.fbcdn23dssr3jqnq.onion_ ? could a hacker create a > public key that would hash to the same value in order to get a cert with > the same .onion domain and imitate the Facebook cert? (This is maybe > the more serious case.) Being able to create some text which hashes to a specific, defined value that you are targetting would be what's called a Preimage attack: http://en.wikipedia.org/wiki/Preimage_attack SHA-1 has no known preimage attacks. Tor .onion names use 80 bits of the SHA-1 hash, which is not the full hash, so it's possible that they might be slightly easier to attack. While there are no known attacks, my understanding is that the Tor people are looking at moving to SHA-256 as a precautionary measure. > (3) Another concern is there is no central registry to identify the > owner of a .onion domain (of course, there could be multiple owners of > the domain under the scenario above). If there is no Subject info in > the O field, etc., with no registry there is no real way to contact the > domain (or cert owner). .onion certs are going to be EV, right? So they would have Subject info in the O field. Gerv From Dean_Coclin at symantec.com Thu Feb 12 22:04:09 2015 From: Dean_Coclin at symantec.com (Dean Coclin) Date: Thu, 12 Feb 2015 14:04:09 -0800 Subject: [cabfpub] Voting period: Ballots 143 and 144 Message-ID: <14D026C7F297AD44AC82578DD818CDD038EF1E9E65@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> Just a reminder that the voting period is underway for Ballots 143 (Validation Working Group) and 144 (.onion) and closes on February 18th. Dean -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6130 bytes Desc: not available URL: From kirk_hall at trendmicro.com Thu Feb 12 22:18:35 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Thu, 12 Feb 2015 22:18:35 +0000 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: <54DD1DED.4090105@mozilla.org> References: <54DD1DED.4090105@mozilla.org> Message-ID: Responding both the Ryan and Gerv. Ryan -- you are correct that concerns (1) and (2) are related -- (1) relates to accidental clashes that give different customers the same domain. Gerv -- you are right, the change is extremely small -- but giving the same domain to different customers is something not allowed today, so it would be quite a change to allow it. This link has some information on the subject, but I really don?t understand the explanation of why clashes aren?t a concern. https://trac.torproject.org/projects/tor/wiki/doc/HiddenServiceNames On (2) ? this concern is of an intentional clash created by a hacker for evil purpose ? a much more serious issue. I notice that in Facebook?s existing .onion cert, they managed to get the following .onion domain: *.m.facebookcorewwwi.onion See screen shot below or attached. I?m sure that didn?t happen randomly, so there must have been some very serious computing that happened to get that particular 16 digit ?random? hash of a Facebook public key, facebookcorewwwi. If Facebook can reverse engineer to get that .onion domain, couldn?t a hacker (or googlegoogle.onion, for another example) do the same and get a duplicate cert with the same domain? [cid:image001.png at 01D046CE.C86B58F0] -----Original Message----- From: Gervase Markham [mailto:gerv at mozilla.org] Sent: Thursday, February 12, 2015 1:41 PM To: Kirk Hall (RD-US); Jeremy Rowley (jeremy.rowley at digicert.com); Ben Wilson (Ben.Wilson at digicert.com) Cc: CABFPub (public at cabforum.org) Subject: Re: [cabfpub] Ballot 144 -.onion domains On 12/02/15 20:43, kirk_hall at trendmicro.com wrote: > For example, Evil Corp. and Angel Corp. could each submit a request > for a .onion cert and get the same domain: _[same 16 digit hash of > their public keys].onion_ if their public keys hash to the same value. > One cert would say O=Evil Corp. the other would say O=Angel Corp., so > that a .onion domain would not be uniquely identified with one > subject. While unlikely, it could happen. Have you been able to put a figure on the likelihood of this occurrence? I think I could calculate it, but I'm interested in what figure you came up with that led to your concern. > (2) Does this also create an opportunity for a hacker? For example, > one of the .onion domains in the SANs field of the Facebook cert you > created is _*.xx.fbcdn23dssr3jqnq.onion_ ? could a hacker create a > public key that would hash to the same value in order to get a cert > with the same .onion domain and imitate the Facebook cert? (This is > maybe the more serious case.) Being able to create some text which hashes to a specific, defined value that you are targetting would be what's called a Preimage attack: http://en.wikipedia.org/wiki/Preimage_attack SHA-1 has no known preimage attacks. Tor .onion names use 80 bits of the SHA-1 hash, which is not the full hash, so it's possible that they might be slightly easier to attack. While there are no known attacks, my understanding is that the Tor people are looking at moving to SHA-256 as a precautionary measure. > (3) Another concern is there is no central registry to identify the > owner of a .onion domain (of course, there could be multiple owners of > the domain under the scenario above). If there is no Subject info in > the O field, etc., with no registry there is no real way to contact > the domain (or cert owner). .onion certs are going to be EV, right? So they would have Subject info in the O field. Gerv 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
-------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 51544 bytes Desc: image001.png URL: From gerv at mozilla.org Thu Feb 12 22:26:38 2015 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 12 Feb 2015 22:26:38 +0000 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: References: <54DD1DED.4090105@mozilla.org> Message-ID: <54DD289E.8040304@mozilla.org> Hi Kirk, On 12/02/15 22:18, kirk_hall at trendmicro.com wrote: > Ryan -- you are correct that concerns (1) and (2) are related -- (1) > relates to accidental clashes that give different customers the same > domain. Gerv -- you are right, the change is extremely small -- but > giving the same domain to different customers is something not allowed > today, so it would be quite a change to allow it. How unlikely would it need to be for you not to use the word "allow"? At the moment, it's possible for two different customers to generate the same public/private key pair, and so they would be able to impersonate each other. But, assuming there's no flaws in the RNG, it is pretty unlikely. Would you say that the CAB Forum "allows" this? > This link has some information on the subject, but I really don?t > understand the explanation of why clashes aren?t a concern. > > https://trac.torproject.org/projects/tor/wiki/doc/HiddenServiceNames Yes, I'm not sure I understand that either. Ryan? > On (2) ? this concern is of an intentional clash created by a hacker for > evil purpose ? a much more serious issue. I notice that in Facebook?s > existing .onion cert, they managed to get the following .onion domain: > > *.m.facebookcorewwwi.onion > > I?m sure that didn?t happen randomly, so there must have been some very > serious computing that happened to get that particular 16 digit ?random? > hash of a Facebook public key, _facebookcorewwwi_. Yes, it did. Facebook are on record as saying that they threw a lot of computing power at the problem, and then reviewed all the options generated which started with "facebook" and picked the one they liked best. The engineer said something like: "I feel we were very lucky in generating a good name." I rather wish they hadn't, actually, because it confuses people into thinking it's possible to just pick a good name and use it, which it isn't. > If Facebook can > reverse engineer to get that .onion domain, couldn?t a hacker (or > googlegoogle.onion, for another example) do the same and get a duplicate > cert with the same domain? No. What Facebook did was generate a lot of hashes starting "facebook", reviewed them, picked the one they liked best and then invented a "reason" for why it's that one: "Facebook's Core WWW Infrastructure". However, generating a second one which exactly matched the name Facebook picked is a much harder process. Gerv From kirk_hall at trendmicro.com Thu Feb 12 22:26:40 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Thu, 12 Feb 2015 22:26:40 +0000 Subject: [cabfpub] Ballot 143 - Formalization of validation working group Message-ID: Trend Micro votes yes. Kirk R. Hall Operations Director, Trust Services Trend Micro +1.503.753.3088 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
-------------- next part -------------- An HTML attachment was scrubbed... URL: From THollebeek at trustwave.com Thu Feb 12 22:33:23 2015 From: THollebeek at trustwave.com (Tim Hollebeek) Date: Thu, 12 Feb 2015 22:33:23 +0000 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: References: <54DD1DED.4090105@mozilla.org> Message-ID: The 40-bit attack only applies in a scenario like the following: 1. I generate 2^40 RSA key pairs. I now (probably) have two RSA key pairs with the same 80-bit URL. 2. I convince someone to use one of the two as their hidden service name I now have a second RSA key pair that can masquerade as the first. But that?s not horribly useful to me, as I also have the first key pair as well! I can convince them to use the key I generated (#2), without having to first generate a collision, and achieve the same result. There is an actual issue (the pre-image attack), where I just generate key pairs until I do collide, but: 1. That?s 2^80 / #hiddenservices key pairs. That?s a lot. 2. I have no control over which hidden service I accidentally collide with. If hidden services become widely used and there are lots of them, this conceivably becomes an issues sometime in the future, which is why I expressed concern about it on the management call. It really is time for the Tor folks to fix this before it becomes a problem. But the existing state of the .onion world is so bad, that allowing EV certificates and HTTPS for Tor is a significant improvement. The size and potential weakness of the onion hashes merit continuing attention, and perhaps a timeline to phase them out, but they?re not a practical attack today. -Tim From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of kirk_hall at trendmicro.com Sent: Thursday, February 12, 2015 5:19 PM To: Gervase Markham; Jeremy Rowley (jeremy.rowley at digicert.com); Ben Wilson (Ben.Wilson at digicert.com) Cc: CABFPub (public at cabforum.org) Subject: Re: [cabfpub] Ballot 144 -.onion domains Responding both the Ryan and Gerv. Ryan -- you are correct that concerns (1) and (2) are related -- (1) relates to accidental clashes that give different customers the same domain. Gerv -- you are right, the change is extremely small -- but giving the same domain to different customers is something not allowed today, so it would be quite a change to allow it. This link has some information on the subject, but I really don?t understand the explanation of why clashes aren?t a concern. https://trac.torproject.org/projects/tor/wiki/doc/HiddenServiceNames On (2) ? this concern is of an intentional clash created by a hacker for evil purpose ? a much more serious issue. I notice that in Facebook?s existing .onion cert, they managed to get the following .onion domain: *.m.facebookcorewwwi.onion See screen shot below or attached. I?m sure that didn?t happen randomly, so there must have been some very serious computing that happened to get that particular 16 digit ?random? hash of a Facebook public key, facebookcorewwwi. If Facebook can reverse engineer to get that .onion domain, couldn?t a hacker (or googlegoogle.onion, for another example) do the same and get a duplicate cert with the same domain? [cid:image001.png at 01D046E8.B2667340] -----Original Message----- From: Gervase Markham [mailto:gerv at mozilla.org] Sent: Thursday, February 12, 2015 1:41 PM To: Kirk Hall (RD-US); Jeremy Rowley (jeremy.rowley at digicert.com); Ben Wilson (Ben.Wilson at digicert.com) Cc: CABFPub (public at cabforum.org) Subject: Re: [cabfpub] Ballot 144 -.onion domains On 12/02/15 20:43, kirk_hall at trendmicro.com wrote: > For example, Evil Corp. and Angel Corp. could each submit a request > for a .onion cert and get the same domain: _[same 16 digit hash of > their public keys].onion_ if their public keys hash to the same value. > One cert would say O=Evil Corp. the other would say O=Angel Corp., so > that a .onion domain would not be uniquely identified with one > subject. While unlikely, it could happen. Have you been able to put a figure on the likelihood of this occurrence? I think I could calculate it, but I'm interested in what figure you came up with that led to your concern. > (2) Does this also create an opportunity for a hacker? For example, > one of the .onion domains in the SANs field of the Facebook cert you > created is _*.xx.fbcdn23dssr3jqnq.onion_ ? could a hacker create a > public key that would hash to the same value in order to get a cert > with the same .onion domain and imitate the Facebook cert? (This is > maybe the more serious case.) Being able to create some text which hashes to a specific, defined value that you are targetting would be what's called a Preimage attack: http://en.wikipedia.org/wiki/Preimage_attack SHA-1 has no known preimage attacks. Tor .onion names use 80 bits of the SHA-1 hash, which is not the full hash, so it's possible that they might be slightly easier to attack. While there are no known attacks, my understanding is that the Tor people are looking at moving to SHA-256 as a precautionary measure. > (3) Another concern is there is no central registry to identify the > owner of a .onion domain (of course, there could be multiple owners of > the domain under the scenario above). If there is no Subject info in > the O field, etc., with no registry there is no real way to contact > the domain (or cert owner). .onion certs are going to be EV, right? So they would have Subject info in the O field. Gerv TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. ________________________________ This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 51544 bytes Desc: image001.png URL: From jeremy.rowley at digicert.com Fri Feb 13 00:58:58 2015 From: jeremy.rowley at digicert.com (Jeremy Rowley) Date: Fri, 13 Feb 2015 00:58:58 +0000 Subject: [cabfpub] Ballot 143 - Formalization of validation working group In-Reply-To: References: Message-ID: <608ba22f4b5d42ec9926ed95d6548299@EX2.corp.digicert.com> DigiCert votes yes From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of kirk_hall at trendmicro.com Sent: Thursday, February 12, 2015 3:27 PM To: CABFPub (public at cabforum.org) Subject: [cabfpub] Ballot 143 - Formalization of validation working group Trend Micro votes yes. Kirk R. Hall Operations Director, Trust Services Trend Micro +1.503.753.3088 TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeremy.rowley at digicert.com Fri Feb 13 01:14:01 2015 From: jeremy.rowley at digicert.com (Jeremy Rowley) Date: Fri, 13 Feb 2015 01:14:01 +0000 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: References: Message-ID: <50b4fdabaa7a4c7e9d1c3b962071f9af@EX2.corp.digicert.com> One caveat is that another ballot is not required if the IESG officially recognizes .onion a reserved name. From: Ryan Sleevi [mailto:sleevi at google.com] Sent: Thursday, February 12, 2015 2:02 PM To: kirk_hall at trendmicro.com Cc: Jeremy Rowley; CABFPub; Ben Wilson Subject: Re: [cabfpub] Ballot 144 -.onion domains On Feb 12, 2015 12:43 PM, "kirk_hall at trendmicro.com" > wrote: > > Jeremy and Ben ? sorry we didn?t ask these questions last week, but I was travelling and didn?t realize the comment period had begun. > > > > (1) We are concerned that under Ballot 144 there could be two .onion certs with the SAME domain but identifying two DIFFERENT subjects. > > > > For example, Evil Corp. and Angel Corp. could each submit a request for a .onion cert and get the same domain: [same 16 digit hash of their public keys].onion if their public keys hash to the same value. One cert would say O=Evil Corp. the other would say O=Angel Corp., so that a .onion domain would not be uniquely identified with one subject. While unlikely, it could happen. > > > > How does Tor resolve this if the same .onion domain is assigned to multiple, different subjects? If someone types in [16 digit hash].onion and that could lead to multiple Tor locations, how does Tor decide where to direct the user? > > Hi Kirk, While not Jeremy, this is actually why I suggested that the full public key be included within the issued certificate itself, so as to highlight any hash collision attempts on the onion private key (e.g. by funkily encoding key parameters or by using key confusion). On a practical level, it's far out there from the realm of being feasible, but it's enough of an issue that I felt important that this should be included in the issued cert, so that sites could use, for example, certificate transparency to monitor for such things. On the TOR side, the protocol is being revved to deal with this, but it is described more at https://trac.torproject.org/projects/tor/wiki/doc/HiddenServiceNames So from the issuance side, the mitigations are including the full public key as well as requiring the EV validation, rather than DV. > > (2) Does this also create an opportunity for a hacker? For example, one of the .onion domains in the SANs field of the Facebook cert you created is *.xx.fbcdn23dssr3jqnq.onion ? could a hacker create a public key that would hash to the same value in order to get a cert with the same .onion domain and imitate the Facebook cert? (This is maybe the more serious case.) > Isn't this a restatement of 1? Or at least, the answers there would still apply. > (3) Another concern is there is no central registry to identify the owner of a .onion domain (of course, there could be multiple owners of the domain under the scenario above). If there is no Subject info in the O field, etc., with no registry there is no real way to contact the domain (or cert owner). > I'm not entirely sure I follow? Note during the discussion phase also included discussion about requiring one or more DNS names from the IANA zone as well, which seems like it would mitigate this concern. > > > Any information you can provide on these point will be very helpful. > I think it is important when considering these that, as of today, any CA can issue any name under .onion under the "Internal Names" exception. This proposal merely restricts it from being "any rules you want" to "more stringent verification required" It still treats .onion as an internal name, in as much as they still sunset and must be revoked. If this ballot fails, every CA will still be able to issue .onion names to any party they wish, including parties who have no relationship whatsoever to the onion HS. That is, if this fails, there is no requirement for attackers to execute a hash collision or factor a private key - they just need to find a CA willing to issue under the "Internal Names" rule (which, as you know, is typically validated at a level less than EV, such as OV). That's why I think this ballot is good - it doesn't prolong or extend risk, it actually _restricts_ issuance in this space until internal names are sunset, at which point, no more of these certs will be issued, no matter the rules. In practice, I expect discussion and standardization to continue, and we may see DigiCert issue a ballot in half a year that looks to extend such issuance, but that's not this ballot, thankfully, so we don't have to solve all of these issues right away. > > > > > TREND MICRO EMAIL NOTICE > The information contained in this email and any attachments is confidential > and may be subject to copyright or other intellectual property protection. > If you are not the intended recipient, you are not authorized to use or > disclose this information, and we request that you notify us by reply mail or > telephone and delete the original message from your mail system. > > > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sleevi at google.com Fri Feb 13 01:18:06 2015 From: sleevi at google.com (Ryan Sleevi) Date: Thu, 12 Feb 2015 17:18:06 -0800 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: <50b4fdabaa7a4c7e9d1c3b962071f9af@EX2.corp.digicert.com> References: <50b4fdabaa7a4c7e9d1c3b962071f9af@EX2.corp.digicert.com> Message-ID: On Thu, Feb 12, 2015 at 5:14 PM, Jeremy Rowley wrote: > One caveat is that another ballot is not required if the IESG officially > recognizes .onion a reserved name. Yes it does. Per BR 1.2.3 Internal Name: A string of characters (not an IP address) in a Common Name or Subject Alternative Name field of a Certificate that cannot be verified as globally unique within the public DNS at the time of certificate issuance because it does not end with a Top Level Domain registered in IANA?s Root Zone Database. An IESG reservation would not result in it being added to the IANA Root Zone Database. You can see this is already the case for RFC 6761 names not being present in the Root Zone Database at [1] [1] https://www.iana.org/domains/root/files From jeremy.rowley at digicert.com Fri Feb 13 01:43:22 2015 From: jeremy.rowley at digicert.com (Jeremy Rowley) Date: Fri, 13 Feb 2015 01:43:22 +0000 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: References: <50b4fdabaa7a4c7e9d1c3b962071f9af@EX2.corp.digicert.com> Message-ID: <258fee1ba76546188b462cc2c6ba0327@EX2.corp.digicert.com> #5 in the ballot: 5. CAs MUST NOT issue a Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name with a validity period longer than 15 months. Despite Section 9.2.1 of the Baseline Requirements deprecating the use of Internal Names, a CA MAY issue a Certificate containing an .onion name with an expiration date later than 1 November 2015 after (and only if) .onion is officially recognized by the IESG as a reserved TLD. -----Original Message----- From: Ryan Sleevi [mailto:sleevi at google.com] Sent: Thursday, February 12, 2015 6:18 PM To: Jeremy Rowley Cc: kirk_hall at trendmicro.com; CABFPub; Ben Wilson Subject: Re: [cabfpub] Ballot 144 -.onion domains On Thu, Feb 12, 2015 at 5:14 PM, Jeremy Rowley wrote: > One caveat is that another ballot is not required if the IESG > officially recognizes .onion a reserved name. Yes it does. Per BR 1.2.3 Internal Name: A string of characters (not an IP address) in a Common Name or Subject Alternative Name field of a Certificate that cannot be verified as globally unique within the public DNS at the time of certificate issuance because it does not end with a Top Level Domain registered in IANA?s Root Zone Database. An IESG reservation would not result in it being added to the IANA Root Zone Database. You can see this is already the case for RFC 6761 names not being present in the Root Zone Database at [1] [1] https://www.iana.org/domains/root/files From jeremy.rowley at digicert.com Fri Feb 13 02:26:21 2015 From: jeremy.rowley at digicert.com (Jeremy Rowley) Date: Fri, 13 Feb 2015 02:26:21 +0000 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names In-Reply-To: References: Message-ID: <95e76d821df3405eb58dcb116081b82b@EX2.corp.digicert.com> DigiCert votes "Yes" From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Tuesday, February 10, 2015 11:39 AM To: public at cabforum.org Subject: [cabfpub] Ballot 144 - Validation rules for .onion names Here's the ballot with the two typos fixed: Applicants want a CA-signed .onion address for several reasons, including: - Powerful web platform features are restricted to secure origins, which are currently not available to onion names (in part, because of the lack of IANA registration). Permitting EV certs for onion names will help provide a secure origin for the service, moving onion towards use of powerful web platform features. - Currently, access to .onion names over https from a standard browser results in the standard existing 'Invalid Certificate' warning. Training users to click through security warnings lowers the value of these warnings and will cause users to miss important security information. Removing these warnings for the user, through use of a digital certificate, will help users recognize and avoid real MITM attacks. - The public needs attribution of ownership of the .onion address to differentiate onion services, including potential phishing services. Because onion names are not easily recognizable strings, providing the public with additional information about the operator has significant security improvements, especially in regions where use of the incorrect name could have lethal consequences. The following motion has been proposed by Jeremy Rowley of DigiCert and endorsed by Ryan Sleevi of Google and Wayne Thayer of GoDaddy. --------------------- Motion Starts --------------------- 1) Amend Section 9.2.1 of the Baseline Requirements v. 1.2.3 as follows: 9.2.1 Subject Alternative Name Extension Certificate Field: extensions:subjectAltName Required/Optional: Required Contents: This 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. The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate. Wildcard FQDNs are permitted. As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name, the CA SHALL notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016. Also as of the Effective Date, the CA SHALL NOT issue a certificate with an Expiry Date later than 1 November 2015 with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name. Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Name. Effective May 1, 2015, each CA SHALL revoke all unexpired Certificates with an Internal Name using onion as the right-most label in an entry in the subjectAltName Extension or commonName field unless such Certificate was issued in accordance with Appendix F of the EV Guidelines. 2) Amend Section 9.2.2 and 11.7.1 of the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2 as follows: 9.2.2. Subject Alternative Name Extension Certificate field: subjectAltName:dNSName Required/Optional: Required Contents: This extension MUST contain one or more host Domain Name(s) owned or controlled by the Subject and to be associated with the Subject's server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). Wildcard certificates are not allowed for EV Certificates except as permitted under Appendix F. 11.7 Verification of Applicant's Domain Name 11.7.1. Verification Requirements (1) For each Fully-Qualified Domain Name listed in a Certificate, other than a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant (or the Applicant's Parent Company, Subsidiary Company, or Affiliate, collectively referred to as "Applicant" for the purposes of this section) either is the Domain Name Registrant or has control over the FQDN using a procedure specified in Section 11.1.1 of the Baseline Requirements, except that a CA MAY NOT verify a domain using the procedure described 11.1.1(7). For a Certificate issued to a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant's control over the .onion Domain Name in accordance with Appendix F. (2) Mixed Character Set Domain Names: EV Certificates MAY include Domain Names containing mixed character sets only in compliance with the rules set forth by the domain registrar. The CA MUST visually compare any Domain Names with mixed character sets with known high risk domains. If a similarity is found, then the EV Certificate Request MUST be flagged as High Risk. The CA must perform reasonably appropriate additional authentication and verification to be certain beyond reasonable doubt that the Applicant and the target in question are the same organization. 3) Add a new Appendix F to the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2: Appendix F - Issuance of Certificates for .onion Domain Names A CA may issue an EV Certificate with .onion in the right-most label of the Domain Name provided that issuance complies with the requirements set forth in this Appendix: 1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) The CAB Forum has created an extension of the TBSCertificate for use in conveying hashes of keys related to .onion addresses. The Tor Service Descriptor Hash extension has the following format: cabf-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 } TorServiceDescriptorSyntax ::= SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash TorServiceDescriptorHash:: = SEQUENCE { onionURI UTF8String algorithm AlgorithmIdentifier subjectPublicKeyHash BIT STRING } Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 6234) performed over the DER-encoding of an ASN.1 SubjectPublicKey of the .onion service and SubjectPublicKeyHash is the hash output. 2. The CA MUST verify the Applicant's control over the .onion Domain Name using one of the following: a. The CA MAY verify the Applicant's control over the .onion service by posting a specific value at a well-known URL under RFC5785. b. The CA MAY verify the Applicant's control over the .onion service by having the Applicant provide a Certificate Request signed using the .onion public key if the Attributes section of the certificationRequestInfo contains: (i) A caSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy, 2) is generated by the CA, and 3) delivered to the Applicant through a Verified Method of Communication and (ii) An applicantSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy and 2) is generated by the Applicant. The signing nonce attributes have the following format: caSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-caSigningNonce } } cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } applicantSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-applicantSigningNonce } } cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 } 4. Each Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name MUST conform to the requirements of these Guidelines, including the content requirements in Section 9 and Appendix B of the Baseline Requirements, except that the CA MAY include a wildcard character in the Subject Alternative Name Extension and Subject Common Name Field as the left-most character in the .onion Domain Name provided inclusion of the wildcard character complies with Section 11.1.3 of the Baseline Requirements. 5. CAs MUST NOT issue a Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name with a validity period longer than 15 months. Despite Section 9.2.1 of the Baseline Requirements deprecating the use of Internal Names, a CA MAY issue a Certificate containing an .onion name with an expiration date later than 1 November 2015 after (and only if) .onion is officially recognized by the IESG as a reserved TLD. 6. On or before May 1, 2015, each CA MUST revoke all Certificates issued with the Subject Alternative Name extension or Common Name field that includes a Domain Name where .onion is in the right-most label of the Domain Name unless the Certificate was issued in compliance with this Appendix F. ---- Motion Ends ----- The review period for this ballot shall commence at 2200 UTC on Thursday, 4 February 2015, and will close at 2200 UTC on Thursday, 11 February 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on Monday, 18 February 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirk_hall at trendmicro.com Fri Feb 13 02:33:12 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Fri, 13 Feb 2015 02:33:12 +0000 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: <54DD289E.8040304@mozilla.org> References: <54DD1DED.4090105@mozilla.org> <54DD289E.8040304@mozilla.org> Message-ID: Gerv, you made an interesting point below in response to my message: [Kirk] If Facebook can reverse engineer to get that .onion domain, couldn?t a hacker (or googlegoogle.onion, for another example) do the same and get a duplicate cert with the same domain? [Gerv] No. What Facebook did was generate a lot of hashes starting "facebook", reviewed them, picked the one they liked best and then invented a "reason" for why it's that one: "Facebook's Core WWW Infrastructure". However, generating a second one which exactly matched the name Facebook picked is a much harder process. Fair enough. But if Facebook can engineer *multiple* public keys that hash so the first 8 characters of ALL of them are ?facebook?, I?m guessing its not that hard and a hacker could do the same thing (or get the first 5 as yahoo, the first 6 as google, or the first 8 as microsoft). After that, the rest of the characters could be random or meaningful, but the potential harm (trickery in the domain name) is already done. Under the ballot, CAs have no obligation to scan or verify a *meaningful* .onion domain and look for phishing or fraud attempts. I was under the impression that .onion domain names were ALWAYS 12 random characters (which avoids fraud); now I see that people who want a specific .onion name can arguably game the system to get a meaningful name that they want (and it might not even be their own name ? gervmarkham1 for example). Under BR 9.2.4g, CAs are not permitted to issue certs with unverified names in the OU field: The CA SHALL implement a process that prevents an OU attribute from including a name, DBA, tradename, trademark, address, location, or other text that refers to a specific natural person or Legal Entity unless the CA has verified this information in accordance with Section 11.2 and the Certificate also contains subject:organizationName, subject:localityName, and subject:countryName attributes, also verified in accordance with Section 11.2. Of course, the OU field is not very important because it?s almost never visible to users. In contrast, a .onion domain name will be displayed to Tor users, and could cause confusion. Should we require CAs to follow the rules of BR 9.2.4g so that .onion domains that include meaningful names are verified? Or better yet, not allow .onion domains to be meaningful (require them to be random only)? 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
-------------- next part -------------- An HTML attachment was scrubbed... URL: From sleevi at google.com Fri Feb 13 02:43:57 2015 From: sleevi at google.com (Ryan Sleevi) Date: Thu, 12 Feb 2015 18:43:57 -0800 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: References: <54DD1DED.4090105@mozilla.org> <54DD289E.8040304@mozilla.org> Message-ID: On Thu, Feb 12, 2015 at 6:33 PM, kirk_hall at trendmicro.com < kirk_hall at trendmicro.com> wrote: > > In contrast, a .onion domain name will be displayed to Tor users, and > could cause confusion. Should we require CAs to follow the rules of BR > 9.2.4g so that .onion domains that include meaningful names are verified? > Or better yet, not allow .onion domains to be meaningful (require them to > be random only)? > How do you define meaningful? How do you define random? In quantifiable ways that can either be audited or inspected by third-parties (e.g. via Certificate Transparency) facebookcorewwwi is a random name. That it has symbolic meaning in English is something that happens with any random system, given sufficient time. Would these concerns go away if Item #5 was removed from the ballot (the automatic extension if IESG reserves)? While I think this discussion is useful to a degree, I do have some concerns: - Under the current provisions, anyone can issue for .onion, so this is by no means worse in any quantifiable way - Under the current provisions, using a .onion with HTTP is objectively less secure than using a .onion name with HTTPS - A .onion name is based upon an RSA-1024 bit key, which is the only security protection in play here. - A .onion name is denied access to privacy-and-security enhancing technologies (due to browsers restricting access to features not delivered over secure transports) - The concerns regarding 'spoofability' of a .onion name exist independent of any discussion in the Forum. That is, it is, at it's core, a TOR protocol "issue" (I'm not sure I would call it that, but for sake of discussion...) - Anyone using .onion names can create facebookwwwcore1.onion, given sufficient time and energy - DNS spoofing exists entirely in the Baseline Requirements (CAs are only required to document their procedures regarding high risk requests. They are not prohibited from issuing such phishy names, per 11.5 of the BR 1.2.3) - DNS spoofing exists entirely in the EV Guidelines (CAs are only required to inspect mixed-script domains, per 11.7.1 p2 of the EVG 1.5.2) Nothing prohibits facebookcorewwwi.com and facebookcorewww1.com from purchasing certificates, EV or DV, provided they demonstrate control over that namespace. Why would or should .onion be any different? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeremy.rowley at digicert.com Fri Feb 13 02:44:39 2015 From: jeremy.rowley at digicert.com (Jeremy Rowley) Date: Fri, 13 Feb 2015 02:44:39 +0000 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: References: <54DD1DED.4090105@mozilla.org> <54DD289E.8040304@mozilla.org> Message-ID: Actually, this illustrates exactly why EV is being used for these. Someone might be able to generate a name that looks similar to the facebook onion name. Without EV, you couldn?t convey which is the actual onion service run by facebook, making it easier to conduct phishing attacks. All onion names are meaningful in that they tie the service to a particular key. With EV, you have a way to tie the key directly to an existing organization. From: kirk_hall at trendmicro.com [mailto:kirk_hall at trendmicro.com] Sent: Thursday, February 12, 2015 7:33 PM To: Gervase Markham; Jeremy Rowley; Ben Wilson Cc: CABFPub (public at cabforum.org) Subject: RE: [cabfpub] Ballot 144 -.onion domains Gerv, you made an interesting point below in response to my message: [Kirk] If Facebook can reverse engineer to get that .onion domain, couldn?t a hacker (or googlegoogle.onion, for another example) do the same and get a duplicate cert with the same domain? [Gerv] No. What Facebook did was generate a lot of hashes starting "facebook", reviewed them, picked the one they liked best and then invented a "reason" for why it's that one: "Facebook's Core WWW Infrastructure". However, generating a second one which exactly matched the name Facebook picked is a much harder process. Fair enough. But if Facebook can engineer *multiple* public keys that hash so the first 8 characters of ALL of them are ?facebook?, I?m guessing its not that hard and a hacker could do the same thing (or get the first 5 as yahoo, the first 6 as google, or the first 8 as microsoft). After that, the rest of the characters could be random or meaningful, but the potential harm (trickery in the domain name) is already done. Under the ballot, CAs have no obligation to scan or verify a *meaningful* .onion domain and look for phishing or fraud attempts. I was under the impression that .onion domain names were ALWAYS 12 random characters (which avoids fraud); now I see that people who want a specific .onion name can arguably game the system to get a meaningful name that they want (and it might not even be their own name ? gervmarkham1 for example). Under BR 9.2.4g, CAs are not permitted to issue certs with unverified names in the OU field: The CA SHALL implement a process that prevents an OU attribute from including a name, DBA, tradename, trademark, address, location, or other text that refers to a specific natural person or Legal Entity unless the CA has verified this information in accordance with Section 11.2 and the Certificate also contains subject:organizationName, subject:localityName, and subject:countryName attributes, also verified in accordance with Section 11.2. Of course, the OU field is not very important because it?s almost never visible to users. In contrast, a .onion domain name will be displayed to Tor users, and could cause confusion. Should we require CAs to follow the rules of BR 9.2.4g so that .onion domains that include meaningful names are verified? Or better yet, not allow .onion domains to be meaningful (require them to be random only)? TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeremy.rowley at digicert.com Fri Feb 13 02:55:02 2015 From: jeremy.rowley at digicert.com (Jeremy Rowley) Date: Fri, 13 Feb 2015 02:55:02 +0000 Subject: [cabfpub] Domain Validation Revision Message-ID: Attached is a draft proposal from the EV working group about revising the domain validation in the BRs. The intent is 1) to eliminate the "any other option" (as it made domain validation essentially meaningless, 2) tighten up the domain validation language, and 3) permit attorney/accountants to draft the domain authorization document. Note that revising this section will automatically revise domain validation in EV. Also note that this is a draft from the working group and not yet a proposed ballot. Jeremy -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Domain Validation Revision Proposal.docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Size: 20594 bytes Desc: Domain Validation Revision Proposal.docx URL: From sleevi at google.com Fri Feb 13 03:08:50 2015 From: sleevi at google.com (Ryan Sleevi) Date: Thu, 12 Feb 2015 19:08:50 -0800 Subject: [cabfpub] Domain Validation Revision In-Reply-To: References: Message-ID: Jeremy, I'm excited to see momentum towards removing the the "Any other option" language, so I'm glad to hear the EV working group is tackling this. In line with "tightening up" the requirements, it would be nice to see Section 7 tightened to go from "Making a change on any file on a web server" to being a specific path (e.g. a .well-known URI) Incidentally, due to other discussions, I'm curious how 2 and 3 tangibly differ (given that the Registrar will provide WHOIS information). Even if they are kept separate, does it make sense to add "through a Reliable Method of Communication" to Section 3, as you have with 1/2? Regarding the language "agreed-upon", this does seem to give significant leeway for CAs to be lax in ways that attackers may exploit. Consistent with your "tightening up" goal, should Items 6 and 7 be explicit that the CA must dictate what change to make? Otherwise, I am concerned that the attacker can "propose" a change (using a portion of the system that they control) and then be issued a certificate. As I've mentioned in the past, it would be nice to see an explicit whitelist for these two methods, consistent with the whitelist for email addresses in Section 4. Put differently, I can see 7 being a little fuzzy-on-the-edges, even though it does approach a more restrictive subset. It would be great to explicitly specify record types that may be used to perform this demonstration (e.g. a TXT record with some CA-dictated value, making a change to a CNAME/A/AAAA in some meaningful way, etc) 8 concerns me for a couple reasons, even though it's moving in the right direction. - You require HTTPS, but that seems overkill, when you only need to perform a TLS handshake. That is, consider a mail server configured for SMTP-S - it seems that would be a viable configuration - It would seem that anyone that can get a port forwarded on a particular address can now get a certificate on that address. For things like STUN-TCP services, this seems quite bad! - The definition of "test certificate" is, from experience, a bit of a handwave that varies from CA to CA. It would be nice to put some explicit technical profile in place here (e.g. a critical poison extension, a requirement that EKUs are present but not serverAuth/clientAuth, issued from a CA independent of the issuing CA's 'trusted' hierarchy) that would prevent relying parties from believing the test certificate is "real" These are just some initial reactions from the proposal; more may come in time. On Thu, Feb 12, 2015 at 6:55 PM, Jeremy Rowley wrote: > Attached is a draft proposal from the EV working group about revising the > domain validation in the BRs. The intent is 1) to eliminate the ?any other > option? (as it made domain validation essentially meaningless, 2) tighten up > the domain validation language, and 3) permit attorney/accountants to draft > the domain authorization document. > > > > Note that revising this section will automatically revise domain validation > in EV. Also note that this is a draft from the working group and not yet a > proposed ballot. > > > > Jeremy > > > > > > > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public > From jeremy.rowley at digicert.com Fri Feb 13 03:37:18 2015 From: jeremy.rowley at digicert.com (Jeremy Rowley) Date: Fri, 13 Feb 2015 03:37:18 +0000 Subject: [cabfpub] Domain Validation Revision In-Reply-To: References: Message-ID: <64bba0d4f05e48fe9673b25b87dd400d@EX2.corp.digicert.com> Thanks Ryan, In line with "tightening up" the requirements, it would be nice to see Section 7 tightened to go from "Making a change on any file on a web server" to being a specific path (e.g. a .well-known URI) [JR] We discussed this, but I can't remember what the objection was. I'll bring it back to the working group unless someone else chimes in. Incidentally, due to other discussions, I'm curious how 2 and 3 tangibly differ (given that the Registrar will provide WHOIS information). Even if they are kept separate, does it make sense to add "through a Reliable Method of Communication" to Section 3, as you have with 1/2? [JR] For 2 sometimes we call up the registrar to get info on how to contact the registrant (such as when the domain is private). However, we could probably combine them to a single bullet point and apply reliable method of communication to both. Regarding the language "agreed-upon", this does seem to give significant leeway for CAs to be lax in ways that attackers may exploit. Consistent with your "tightening up" goal, should Items 6 and 7 be explicit that the CA must dictate what change to make? Otherwise, I am concerned that the attacker can "propose" a change (using a portion of the system that they control) and then be issued a certificate. As I've mentioned in the past, it would be nice to see an explicit whitelist for these two methods, consistent with the whitelist for email addresses in Section 4. [JR] Agreed. By posting this to the mailing list, we're hoping that CAs will indicate exactly what they want covered so we can narrow the scope of these two sections. I probably should have mentioned that in the original email... Put differently, I can see 7 being a little fuzzy-on-the-edges, even though it does approach a more restrictive subset. It would be great to explicitly specify record types that may be used to perform this demonstration (e.g. a TXT record with some CA-dictated value, making a change to a CNAME/A/AAAA in some meaningful way, etc) [JR] I'll have the working group come up with an initial list. If anyone has specific ways they verify though DNS, please email it to me for consideration. 8 concerns me for a couple reasons, even though it's moving in the right direction. - You require HTTPS, but that seems overkill, when you only need to perform a TLS handshake. That is, consider a mail server configured for SMTP-S - it seems that would be a viable configuration - It would seem that anyone that can get a port forwarded on a particular address can now get a certificate on that address. For things like STUN-TCP services, this seems quite bad! - The definition of "test certificate" is, from experience, a bit of a handwave that varies from CA to CA. It would be nice to put some explicit technical profile in place here (e.g. a critical poison extension, a requirement that EKUs are present but not serverAuth/clientAuth, issued from a CA independent of the issuing CA's 'trusted' hierarchy) that would prevent relying parties from believing the test certificate is "real" [JR] This was added by GlobalSign so I'll let them comment. These are just some initial reactions from the proposal; more may come in time. On Thu, Feb 12, 2015 at 6:55 PM, Jeremy Rowley wrote: > Attached is a draft proposal from the EV working group about revising > the domain validation in the BRs. The intent is 1) to eliminate the > ?any other option? (as it made domain validation essentially > meaningless, 2) tighten up the domain validation language, and 3) > permit attorney/accountants to draft the domain authorization document. > > > > Note that revising this section will automatically revise domain > validation in EV. Also note that this is a draft from the working > group and not yet a proposed ballot. > > > > Jeremy > > > > > > > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public > From kirk_hall at trendmicro.com Fri Feb 13 06:22:59 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Fri, 13 Feb 2015 06:22:59 +0000 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: References: <54DD1DED.4090105@mozilla.org> <54DD289E.8040304@mozilla.org> Message-ID: BR 11.5 High Risk Requests The CA SHALL develop, maintain, and implement documented procedures that identify and require additional verification activity for High Risk Certificate Requests prior to the Certificate?s approval, as reasonably necessary to ensure that such requests are properly verified under these Requirements. High Risk Certificate Request: A Request that the CA flags for additional scrutiny by reference to internal criteria and databases maintained by the CA, which may include names at higher risk for phishing or other fraudulent usage, names contained in previously rejected certificate requests or revoked Certificates, names listed on the Miller Smiles phishing list or the Google Safe Browsing list, or names that the CA identifies using its own risk-mitigation criteria. We won?t issue certs for microsoft.example.com, googleserver.example.com, etc., even though our customer owns example.com. I think the same concerns would apply to .onion certs, for the same reason. From: Ryan Sleevi [mailto:sleevi at google.com] Sent: Thursday, February 12, 2015 6:44 PM To: Kirk Hall (RD-US) Cc: Gervase Markham; Jeremy Rowley (jeremy.rowley at digicert.com); Ben Wilson (Ben.Wilson at digicert.com); CABFPub (public at cabforum.org) Subject: Re: [cabfpub] Ballot 144 -.onion domains On Thu, Feb 12, 2015 at 6:33 PM, kirk_hall at trendmicro.com > wrote: In contrast, a .onion domain name will be displayed to Tor users, and could cause confusion. Should we require CAs to follow the rules of BR 9.2.4g so that .onion domains that include meaningful names are verified? Or better yet, not allow .onion domains to be meaningful (require them to be random only)? How do you define meaningful? How do you define random? In quantifiable ways that can either be audited or inspected by third-parties (e.g. via Certificate Transparency) facebookcorewwwi is a random name. That it has symbolic meaning in English is something that happens with any random system, given sufficient time. Would these concerns go away if Item #5 was removed from the ballot (the automatic extension if IESG reserves)? While I think this discussion is useful to a degree, I do have some concerns: - Under the current provisions, anyone can issue for .onion, so this is by no means worse in any quantifiable way - Under the current provisions, using a .onion with HTTP is objectively less secure than using a .onion name with HTTPS - A .onion name is based upon an RSA-1024 bit key, which is the only security protection in play here. - A .onion name is denied access to privacy-and-security enhancing technologies (due to browsers restricting access to features not delivered over secure transports) - The concerns regarding 'spoofability' of a .onion name exist independent of any discussion in the Forum. That is, it is, at it's core, a TOR protocol "issue" (I'm not sure I would call it that, but for sake of discussion...) - Anyone using .onion names can create facebookwwwcore1.onion, given sufficient time and energy - DNS spoofing exists entirely in the Baseline Requirements (CAs are only required to document their procedures regarding high risk requests. They are not prohibited from issuing such phishy names, per 11.5 of the BR 1.2.3) - DNS spoofing exists entirely in the EV Guidelines (CAs are only required to inspect mixed-script domains, per 11.7.1 p2 of the EVG 1.5.2) Nothing prohibits facebookcorewwwi.com and facebookcorewww1.com from purchasing certificates, EV or DV, provided they demonstrate control over that namespace. Why would or should .onion be any different? 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
-------------- next part -------------- An HTML attachment was scrubbed... URL: From sleevi at google.com Fri Feb 13 07:18:08 2015 From: sleevi at google.com (Ryan Sleevi) Date: Thu, 12 Feb 2015 23:18:08 -0800 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: References: <54DD1DED.4090105@mozilla.org> <54DD289E.8040304@mozilla.org> Message-ID: Right, I'm aware you, as an individual CA, may not, but the BRs 1) Don't place any requirements beyond documenting and having a procedure for those flagged High Risk. The procedures may simply be "We require a phone call and a pinky promise to be good" 2) Don't place any requirements on the criteria for a request being flagged as High Risk, other than all EV certs are automatically high risk. Thus while you won't issue for microsoft.example.com or googleserver.example.com (and, to be fair, TrendMicro certainly will issue certs for those names, since it seems you will sell *.example.com), another CA may, and without violating any requirements. This is true whether the CA is issuing for DV or EV. I'm not trying to be stubborn here, but again, it is worth reiterating that nothing in the BRs or EVGs requires that a CA treat a request for facebook1.com any different than facebook2.com, or fbcdn.com any different than fcbdn.com, beyond the ambiguous and underspecified "addition verification activity", and if and only if the CA deems it high risk (which they may not). They do not prohibit a CA from issuing these certs, so I see no reason why .onion should be any different, especially since certificates are not an anti-phishing tool. My goal in arguing for these certs is I believe they are a great tool to increase online privacy and security, and, from a validation and verification space, are not weaker than the existing DV and EV practices. Indeed, in very real ways, this proposal is actually stronger than some of the verification practices CAs currently use (e.g. it requires a cryptographic key binding the name, rather than the insecure and unauthenticated reliance on DNS) I am concerned that the questions on criteria from my previous mail were somewhat ignored. I definitely think that if there are opportunities to improve this ballot, we should take them. However, your previous comment regarding "randomness" doesn't really establish actionable, auditable, objective criteria, and proposes to require more than the BRs require or CAs practice. I'm not sure how we can reasonably satisfy your concerns because of this, nor whether the absence of a solution for a problem the BRs don't address means you will vote to leave .onion unvalidated and unregulated, and, as a consequence, untrusted by some UAs (notably, Chrome). On Feb 12, 2015 10:23 PM, "kirk_hall at trendmicro.com" < kirk_hall at trendmicro.com> wrote: > *BR 11.5 High Risk Requests* > > The CA SHALL develop, maintain, and implement documented procedures that > identify and require additional verification activity for High Risk > Certificate Requests prior to the Certificate?s approval, as reasonably > necessary to ensure that such requests are properly verified under these > Requirements. > > > > *High Risk Certificate Request: *A Request that the CA flags for > additional scrutiny by reference to internal criteria and databases > maintained by the CA, which may include names at higher risk for phishing > or other fraudulent usage, names contained in previously rejected > certificate requests or revoked Certificates, names listed on the Miller > Smiles phishing list or the Google Safe Browsing list, or names that the CA > identifies using its own risk-mitigation criteria. > > > > We won?t issue certs for microsoft.example.com, googleserver.example.com, > etc., even though our customer owns example.com. I think the same > concerns would apply to .onion certs, for the same reason. > > > > *From:* Ryan Sleevi [mailto:sleevi at google.com] > *Sent:* Thursday, February 12, 2015 6:44 PM > *To:* Kirk Hall (RD-US) > *Cc:* Gervase Markham; Jeremy Rowley (jeremy.rowley at digicert.com); Ben > Wilson (Ben.Wilson at digicert.com); CABFPub (public at cabforum.org) > *Subject:* Re: [cabfpub] Ballot 144 -.onion domains > > > > > > > > On Thu, Feb 12, 2015 at 6:33 PM, kirk_hall at trendmicro.com < > kirk_hall at trendmicro.com> wrote: > > In contrast, a .onion domain name will be displayed to Tor users, and > could cause confusion. Should we require CAs to follow the rules of BR > 9.2.4g so that .onion domains that include meaningful names are verified? > Or better yet, not allow .onion domains to be meaningful (require them to > be random only)? > > > > How do you define meaningful? How do you define random? In quantifiable > ways that can either be audited or inspected by third-parties (e.g. via > Certificate Transparency) > > > > facebookcorewwwi is a random name. That it has symbolic meaning in English > is something that happens with any random system, given sufficient time. > > > > Would these concerns go away if Item #5 was removed from the ballot (the > automatic extension if IESG reserves)? > > > > While I think this discussion is useful to a degree, I do have some > concerns: > > > > - Under the current provisions, anyone can issue for .onion, so this is by > no means worse in any quantifiable way > > > > - Under the current provisions, using a .onion with HTTP is objectively > less secure than using a .onion name with HTTPS > > - A .onion name is based upon an RSA-1024 bit key, which is the only > security protection in play here. > > - A .onion name is denied access to privacy-and-security enhancing > technologies (due to browsers restricting access to features not delivered > over secure transports) > > > > - The concerns regarding 'spoofability' of a .onion name exist independent > of any discussion in the Forum. That is, it is, at it's core, a TOR > protocol "issue" (I'm not sure I would call it that, but for sake of > discussion...) > > - Anyone using .onion names can create facebookwwwcore1.onion, given > sufficient time and energy > > - DNS spoofing exists entirely in the Baseline Requirements (CAs are > only required to document their procedures regarding high risk requests. > They are not prohibited from issuing such phishy names, per 11.5 of the BR > 1.2.3) > > - DNS spoofing exists entirely in the EV Guidelines (CAs are only > required to inspect mixed-script domains, per 11.7.1 p2 of the EVG 1.5.2) > > > > Nothing prohibits facebookcorewwwi.com and facebookcorewww1.com from > purchasing certificates, EV or DV, provided they demonstrate control over > that namespace. Why would or should .onion be any different? > > > TREND MICRO EMAIL NOTICE > The information contained in this email and any attachments is confidential > and may be subject to copyright or other intellectual property protection. > If you are not the intended recipient, you are not authorized to use or > disclose this information, and we request that you notify us by reply mail or > telephone and delete the original message from your mail system. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From i-barreira at izenpe.net Fri Feb 13 08:05:11 2015 From: i-barreira at izenpe.net (i-barreira at izenpe.net) Date: Fri, 13 Feb 2015 09:05:11 +0100 Subject: [cabfpub] ballots 143 and 144 Message-ID: <763539E260C37C46A0D6B340B5434C3B0ADAE0DE@AEX06.ejsarea.net> Izenpe votes as follow 143: yes 144: abstains I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 19121 bytes Desc: image001.png URL: From i-barreira at izenpe.net Fri Feb 13 08:16:20 2015 From: i-barreira at izenpe.net (i-barreira at izenpe.net) Date: Fri, 13 Feb 2015 09:16:20 +0100 Subject: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc In-Reply-To: A References: <763539E260C37C46A0D6B340B5434C3B0ACD81A9@AEX06.ejsarea.net> A Message-ID: <763539E260C37C46A0D6B340B5434C3B0ADAE0EB@AEX06.ejsarea.net> Dear Jody, I understand your concern because it?s not easy for you to manage all possible combinations regarding ETSI audits in different countries so will try to clarify your example. First of all, no AuditCo has to be member of ETSI, AuditCo can perform ETSI accredited audits without being member of ETSI, they only need to be accredited in their country as stated in Annex E requirements. So, For example, ? Company A is a commercial CA that operates in Israel ? Auditor Jones works for AuditCo, which is based in Israel ? AuditCo is certified by some governmental agency as a qualified auditor IB? AuditCo has to be accredited under its National Accreditation Body according to ISO 17021. In the case of Israel, to follow the example, in the associated members tab of the EA, you can find the Israeli accreditation body, called ISRAC. Then AuditCo should be listed there and meeting the requirements to perform ETSI audits according to the national scheme indicated by ISRAC ? AuditCo is not an ETSI Member or Associate Member IB ? this is not necessary. No need to be an ETSI member to perform ETSI audits ? Auditor Jones audits Company A using the ETSI 102042 standard, and Company A sends the auditor's attestation letter to Microsoft as evidence that Company A complied with the Program's requirements. IB? this is perfectly valid if AuditCo is listed in ISRAC and is allowed to perform ETSI audits. Of course Auditor Jones has to be also accredited to perform these kind of audits, has to be "qualified", so it?s not only the company but also the auditor, but that?s an internal task of the AuditCo. Regarding of being member of not, this is voluntary, they can join ETSI or not and don?t think that solve the problem because joining ETSI does not mean that you?re "qualified" or "accredited" to perform an ETSI audit, it?s just indicate that you belong to a club for example. And of course, if company A needs an auditing company accredited in Israel and there?s none, they can look for in other countries. For example, in Spain there?s no accredited auditing bodies to perform ETSI audits listed in our NAB, called ENAC, so, we, Izenpe, had to look for another option. So, we contacted for the first 6 years with KPMG in the Netherlands, and the last 3, with TUV IT in Germany. And Izenpe has an accredited ETSI audits according to the, right now, German national scheme and we?re listed in Germany. We?ll debate this within ETSI ESI trying to find an easier solution. Regards I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. De: Jody Cloutier [mailto:jodycl at microsoft.com] Enviado el: mi?rcoles, 11 de febrero de 2015 0:32 Para: Barreira Iglesias, I?igo; public at cabforum.org Asunto: RE: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Thank you, Inigo. I think the problem is that, under ETSI, it's difficult to discern what an "equivalent national scheme" is. This sets up the scenario in which an auditor is employed by an organization that is recognized somehow by the government, but is not affiliated with an ETSI member organization (http://www.european-accreditation.org/home ). Microsoft does not know whether or not this auditor is qualified or not. For example, ? Company A is a commercial CA that operates in Israel ? Auditor Jones works for AuditCo, which is based in Israel ? AuditCo is certified by some governmental agency as a qualified auditor ? AuditCo is not an ETSI Member or Associate Member ? Auditor Jones audits Company A using the ETSI 102042 standard, and Company A sends the auditor's attestation letter to Microsoft as evidence that Company A complied with the Program's requirements. In this scenario, how does Microsoft know that Auditor Jones conducted a proper audit without expending significant resources to determine whether and according to what standard AuditCo and Auditor Jones was certified? Microsoft believes that it would be simpler if the requirements were that the Auditor must work for a company that is affiliated with an ETSI-approved member organization. If Company A needs an auditor and there is no qualified auditor in Israel, the company can use an auditor from a member organization via the cross-border conformity rules. Unless I am fundamentally misunderstanding the rules, the above is something that Microsoft is presently struggling with, and we'd like to try to make the rules easier to understand for potential partners and ourselves. Jody Cloutier Senior Security Program Manager Microsoft Trusted Root Certificate Program jody.cloutier at microsoft.com 425.443.8922 Operating Systems Group Global Risk and Compliance From: i-barreira at izenpe.net [mailto:i-barreira at izenpe.net] Sent: Tuesday, February 10, 2015 3:09 AM To: Jody Cloutier; public at cabforum.org Subject: RE: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Hi Jody, Regarding your comment on ETSI audits, I have to say that the ETSI audits shall be performed by accredited auditors as mentioned in Annex E of the current ETSI TS 102 042. ETSI audits performed by not accredited auditors shall be considered invalid. Microsoft is accepting ETSI audits since the very beginning in its root program requirements indicating this requirement. ETSI is providing a list of accredited auditors as mere information because has to be maintained by every NAB (National Accreditation Body). It?s true that this has to be improved regarding the new regulation 910/2014 and the new ENs and will take some time, but at the moment, it?s clearly stated that the audits shall be performed by accredited auditors. Don?t hesitate in contacting me for any additional information or help. Sometimes I?ve received some emails from Tom or Kelvin asking for the qualification of some audits, so, as say, you can contact me regarding this issue. Regards I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. De: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] En nombre de Jody Cloutier Enviado el: lunes, 09 de febrero de 2015 18:55 Para: CABFPub (public at cabforum.org) Asunto: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Microsoft comments on Section 17. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 19121 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 1181 bytes Desc: image002.png URL: From adriano.santoni at staff.aruba.it Fri Feb 13 09:23:47 2015 From: adriano.santoni at staff.aruba.it (Adriano Santoni) Date: Fri, 13 Feb 2015 10:23:47 +0100 Subject: [cabfpub] Ballots 143 and 144 In-Reply-To: <763539E260C37C46A0D6B340B5434C3B0ADAE0DE@AEX06.ejsarea.net> References: <763539E260C37C46A0D6B340B5434C3B0ADAE0DE@AEX06.ejsarea.net> Message-ID: <54DDC2A3.2000200@staff.aruba.it> An HTML attachment was scrubbed... URL: From gerv at mozilla.org Fri Feb 13 09:53:18 2015 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 13 Feb 2015 09:53:18 +0000 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: References: <54DD1DED.4090105@mozilla.org> <54DD289E.8040304@mozilla.org> Message-ID: <54DDC98E.8020907@mozilla.org> Hi Kirk, On 13/02/15 02:33, kirk_hall at trendmicro.com wrote: > Fair enough. But if Facebook can engineer **multiple** public keys that > hash so the first 8 characters of ALL of them are ?facebook?, I?m > guessing its not that hard and a hacker could do the same thing (or get > the first 5 as yahoo, the first 6 as google, or the first 8 as > microsoft). After that, the rest of the characters could be random or > meaningful, but the potential harm (trickery in the domain name) is > already done. .onion names represent 80 bits of data (half of the 160 bits of a SHA-1 hash) and are 16 characters, so each character represents 5 bits. This means that to fix the first character would require generating about 32 (2 ^ 5) keys. Not many. But to fix the first two characters would require 32 ^ 2 = 1024 keys. Each additional character you want to fix makes the job 32 times harder. Therefore, getting even one key where the first 8 hash characters are "facebook" requires approx. 1 x 10^12 keys to be generated (that's 100,000,000,000). Facebook has a lot of computing power, so they could do this. This is not out of the reach of others, but would be expensive. I'm not sure a phisher would consider this the most cost-effective method of phishing. > Under the ballot, CAs have no obligation to scan or verify a > **meaningful** .onion domain and look for phishing or fraud attempts. Do they have such an obligation for normal domain names? If so, why does that obligation not extend to .onion names? > I > was under the impression that .onion domain names were ALWAYS 12 random > characters (which avoids fraud); now I see that people who want a > specific .onion name can arguably game the system to get a meaningful > name that they want (and it might not even be their own name ? > gervmarkham1 for example). The longer the required "meaningful" portion is, the harder it is to find a name beginning with it. As I said, each extra character you want makes it 32 times harder. So getting an 8-character prefix ("facebook") requires approx. 1 x 10^12 keys to be generated. Getting an 11 character prefix ("gervmarkham") requires 3.6 x 10^16 - i.e. it's 32,678 times harder. 11 characters would have been out of the reach of even Facebook. > In contrast, a .onion domain name will be displayed to Tor users, and > could cause confusion. Should we require CAs to follow the rules of BR > 9.2.4g so that .onion domains that include meaningful names are > verified? Or better yet, not allow .onion domains to be meaningful > (require them to be random only)? I think the idea of requiring "randomness" would not be any better. Let's say we required Facebook to be: 5jdgiu3sn4j2lkqq.onion. It would be equally as easy for someone to generate a key matching the first 8 letters of this as it is for someone to generate one matching the word "facebook". So for the same effort as above, I could generate: 5jdgiu3sya3mldpz.onion I'm not convinced that a user is going to recognise the difference between those two better than the difference between two strings starting "facebook". This is fundamentally why the proposal is that onion names be EV only - because looking at the domain name is not a good way of determining the owner, whether it's random or mnemonic. Gerv From gerv at mozilla.org Fri Feb 13 10:05:17 2015 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 13 Feb 2015 10:05:17 +0000 Subject: [cabfpub] Domain Validation Revision In-Reply-To: References: Message-ID: <54DDCC5D.50305@mozilla.org> On 13/02/15 02:55, Jeremy Rowley wrote: > Attached is a draft proposal from the EV working group about revising > the domain validation in the BRs. The intent is 1) to eliminate the > ?any other option? (as it made domain validation essentially > meaningless, I don't agree that the "any other option" makes domain validation essentially meaningless. The current text is as follows: "Using any other method of confirmation, provided that the CA maintains documented evidence that the method of confirmation establishes that the Applicant is the Domain Name Registrant or has control over the FQDN to at least the same level of assurance as those methods previously described." This basically means that CAs can innovate in the way they do domain control as long as the level of assurance remains the same, and it makes the CA responsible for confirming that this is so. (And if a CA was using this clause, I would expect the auditor auditing them to the BRs to review their documentation and make an assessment as to whether the level of assurance was equivalent.) Given that this is an area of CA operations where there are patents on some methods of doing things, open-endedness is IMO important to make sure that the BRs are not used as a device to force CAs to acquire patent licenses due to limited options. I have no objection to listing more methods that the CAB Forum explicitly finds to be acceptable, but I think removing the flexibility is a backwards step. > 3) permit > attorney/accountants to draft the domain authorization document. If I understand this correctly, then I am opposed. I don't see why a lawyer or an accountant is an appropriate authority on the subject of who controls a domain. Domain control can only be properly validated either by the registrar who issued the domain, the registrant listed in WHOIS, or some practical demonstration of control. No-one else's opinion matters. Gerv From bruce.morton at entrust.com Fri Feb 13 13:17:57 2015 From: bruce.morton at entrust.com (Bruce Morton) Date: Fri, 13 Feb 2015 13:17:57 +0000 Subject: [cabfpub] Domain Validation Revision In-Reply-To: References: Message-ID: <452C99D20750E74083DBA441FF932385E4162A8B@SOTTEXCH10.corp.ad.entrust.com> Some comments: Item 1 would originally allow confirmation of the domain name registrant using a WHOIS review. Now this must be done using a Reliable Method of Communications which does not appear to be compatible. Items 2, 3 and 4 now state "Confirming authorization of the Certificate's issuance". The purpose of section 11.1.1 is to confirm "the Applicant either is the Domain Name Registrant or has control." I don't think we need the new language about certificate's issuance. Thanks, Bruce. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Thursday, February 12, 2015 9:55 PM To: CABFPub (public at cabforum.org) Subject: [cabfpub] Domain Validation Revision Attached is a draft proposal from the EV working group about revising the domain validation in the BRs. The intent is 1) to eliminate the "any other option" (as it made domain validation essentially meaningless, 2) tighten up the domain validation language, and 3) permit attorney/accountants to draft the domain authorization document. Note that revising this section will automatically revise domain validation in EV. Also note that this is a draft from the working group and not yet a proposed ballot. Jeremy -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruce.morton at entrust.com Fri Feb 13 13:46:05 2015 From: bruce.morton at entrust.com (Bruce Morton) Date: Fri, 13 Feb 2015 13:46:05 +0000 Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group In-Reply-To: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> References: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> Message-ID: <452C99D20750E74083DBA441FF932385E4162C54@SOTTEXCH10.corp.ad.entrust.com> Entrust votes Yes. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Wednesday, February 04, 2015 4:05 PM To: CABFPub Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group Ballot 143 - Formalization of validation working group ---- Reason ---- In order to address validation issues and inconsistencies in both the SSL Baseline Requirements and the EV Guidelines, the CAB Forum has held an informal working group previously referred to as the Extended Validation Working Group now known as the Validation Working Group, would like to modify its scope to include validation in the Baseline Requirements as well as the EV Guidelines. Jeremy Rowley of DigiCert made the following motion, which was endorsed by Rich Smith of Comodo and Kirk Hall of TrendMicro ---- Motion begins ---- The CA-Browser Forum formally establishes the Validation Working Group as an official working group of the CAB Forum, replacing the previous informal EV working group. The scope of this working group is to address issues arising under adopted CAB Forum standards related to the validation of certificate information and the inclusion of information in certificates. Scope: The Validation Working Group will consider all matters relating to the validation and inclusion of information in certificates under adopted CAB Forum guidelines. Deliverables: The Working Group shall produce one or more documents offering options to the Forum for validation within the scope defined above. ---- Motion Ends ---- The review period for this ballot shall commence at 2200 UTC on 5 Feb 2015, and will close at 2200 UTC on 11 Feb 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on 18 Feb 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: From volkan.nergiz at turktrust.com.tr Fri Feb 13 15:18:42 2015 From: volkan.nergiz at turktrust.com.tr (Volkan Nergiz) Date: Fri, 13 Feb 2015 17:18:42 +0200 Subject: [cabfpub] Ballots 143 and 144 Message-ID: <00db01d047a0$59e3dfb0$0dab9f10$@turktrust.com.tr> T?RKTRUST votes YES for Ballot 143 and ABSTAIN for Ballot 144. Volkan NERG?Z Quality Management System Specialist TURKTRUST Information Security Services Inc. Address: Hollanda Caddesi 696. Sokak No: 7 Y?ld?z, ?ankaya 06550 - ANKARA Phone: (312) 439 10 00 - 226 Fax: (312) 439 10 01 E-Mail: volkan.nergiz at turktrust.com.tr Web: www.turktrust.com.tr -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 1906 bytes Desc: not available URL: From kirk_hall at trendmicro.com Fri Feb 13 16:28:29 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Fri, 13 Feb 2015 16:28:29 +0000 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: <54DDC98E.8020907@mozilla.org> References: <54DD1DED.4090105@mozilla.org> <54DD289E.8040304@mozilla.org> <54DDC98E.8020907@mozilla.org> Message-ID: Thanks, Gerv ? but if it wasn?t too hard for Facebook to generate multiple ?facebook? .onion domains (presumably using automated methods), I?m not convinced it would be hard for hackers. And I?m still troubled that the .onion plan allows multiple customers to obtain the same .onion domain (meaning there could be multiple certs for the same .onion domain that belong to different subjects). I have to circle back to ?Why are we doing this?? ? Tor users want to visit websites anonymously. [That sounds like something CAs should support if possible] ? Website owners do *not* want anonymity ? in fact, just the opposite. They want EV certs with their identity information included that will work for Tor users. ? For some reason, regular TLD certs (like .com certs) won?t work after Tor users go through the Tor blender. [Does anyone know why that is the case?] ? But for some reason, Internal Name .onion certs *do* work for Tor users after they go through the Tor blender. [Does anyone know why this is so?] ? Tor does not want to apply for .onion as a TLD, and does not want to be the registrar for .onion [Why not? That would solve everything by making .onion a TLD, so all the current CA rules could apply. And remember, website users are not looking for anonymity in their certs ? they want EV certs with their identity displayed prominently in the browsers.] ? The Tor process for assigning .onion domains does not require domains to be unique. Why won?t regular TLD certs work in Tor? Why do .onion Internal Name certs work in Tor? Could Tor fix this discrepancy so we don?t have to continue allowing Internal Name certs for the .onion case? If two or more website owners receive the same .onion domain (either by accident, or by design of some of the website owners who choose what their .onion domain will be, like Facebook did), how does Tor resolve this clash? Where does it send users? I really don?t understand why we have to create an exception to the rules to accommodate this case. -----Original Message----- From: Gervase Markham [mailto:gerv at mozilla.org] Sent: Friday, February 13, 2015 1:53 AM To: Kirk Hall (RD-US); Jeremy Rowley (jeremy.rowley at digicert.com); Ben Wilson (Ben.Wilson at digicert.com) Cc: CABFPub (public at cabforum.org) Subject: Re: [cabfpub] Ballot 144 -.onion domains Hi Kirk, On 13/02/15 02:33, kirk_hall at trendmicro.com wrote: > Fair enough. But if Facebook can engineer **multiple** public keys > that hash so the first 8 characters of ALL of them are ?facebook?, I?m > guessing its not that hard and a hacker could do the same thing (or > get the first 5 as yahoo, the first 6 as google, or the first 8 as > microsoft). After that, the rest of the characters could be random or > meaningful, but the potential harm (trickery in the domain name) is > already done. .onion names represent 80 bits of data (half of the 160 bits of a SHA-1 hash) and are 16 characters, so each character represents 5 bits. This means that to fix the first character would require generating about 32 (2 ^ 5) keys. Not many. But to fix the first two characters would require 32 ^ 2 = 1024 keys. Each additional character you want to fix makes the job 32 times harder. Therefore, getting even one key where the first 8 hash characters are "facebook" requires approx. 1 x 10^12 keys to be generated (that's 100,000,000,000). Facebook has a lot of computing power, so they could do this. This is not out of the reach of others, but would be expensive. I'm not sure a phisher would consider this the most cost-effective method of phishing. > Under the ballot, CAs have no obligation to scan or verify a > **meaningful** .onion domain and look for phishing or fraud attempts. Do they have such an obligation for normal domain names? If so, why does that obligation not extend to .onion names? > I > was under the impression that .onion domain names were ALWAYS 12 > random characters (which avoids fraud); now I see that people who want > a specific .onion name can arguably game the system to get a > meaningful name that they want (and it might not even be their own > name ? > gervmarkham1 for example). The longer the required "meaningful" portion is, the harder it is to find a name beginning with it. As I said, each extra character you want makes it 32 times harder. So getting an 8-character prefix ("facebook") requires approx. 1 x 10^12 keys to be generated. Getting an 11 character prefix ("gervmarkham") requires 3.6 x 10^16 - i.e. it's 32,678 times harder. 11 characters would have been out of the reach of even Facebook. > In contrast, a .onion domain name will be displayed to Tor users, and > could cause confusion. Should we require CAs to follow the rules of > BR 9.2.4g so that .onion domains that include meaningful names are > verified? Or better yet, not allow .onion domains to be meaningful > (require them to be random only)? I think the idea of requiring "randomness" would not be any better. Let's say we required Facebook to be: 5jdgiu3sn4j2lkqq.onion. It would be equally as easy for someone to generate a key matching the first 8 letters of this as it is for someone to generate one matching the word "facebook". So for the same effort as above, I could generate: 5jdgiu3sya3mldpz.onion I'm not convinced that a user is going to recognise the difference between those two better than the difference between two strings starting "facebook". This is fundamentally why the proposal is that onion names be EV only - because looking at the domain name is not a good way of determining the owner, whether it's random or mnemonic. Gerv 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
-------------- next part -------------- An HTML attachment was scrubbed... URL: From gerv at mozilla.org Fri Feb 13 16:45:16 2015 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 13 Feb 2015 16:45:16 +0000 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: References: <54DD1DED.4090105@mozilla.org> <54DD289E.8040304@mozilla.org> <54DDC98E.8020907@mozilla.org> Message-ID: <54DE2A1C.9050601@mozilla.org> On 13/02/15 16:28, kirk_hall at trendmicro.com wrote: > Thanks, Gerv ? but if it wasn?t too hard for Facebook to generate > multiple ?facebook? .onion domains (presumably using automated methods), > I?m not convinced it would be hard for hackers. I will again try and convince you that the laws of probability mean it would be extremely, extremely hard -> impossible. > And I?m still troubled > that the .onion plan allows multiple customers to obtain the same .onion > domain (meaning there could be multiple certs for the same .onion domain > that belong to different subjects). I don't think that's true, for any useful meaning of the term "allow". There is a level of "vanishingly unlikely" which we can equate to "impossible". If I wanted to get a cert for facebookcorewwwi.onion, I would need to generate approximately 2^80 certificates to have a reasonable chance of finding one with the right hash. 2^80 is: 120,892,581,961,463,000,000,000. That's approximately a million times the number of grains of sand in the world. Making some estimates, it would require Amazon to run all of their 2 million AWS machines generating only keypairs for a thousand years. So it's possible that if I just start generating certs, I might get one which matches, but it's vanishingly unlikely for any reasonable scenario, even if I have lots and lots of computers and lots and lots of money. > ? For some reason, regular TLD certs (like .com > certs) won?t work after Tor users go through the Tor blender. [Does > anyone know why that is the case?] Because unless CAs issue for .onion, the domain name in any certificate the site is able to obtain doesn't match the domain name they are using. > ? But for some reason, Internal Name .onion certs > **do** work for Tor users after they go through the Tor blender. [Does > anyone know why this is so?] Because the domain names match. > ? Tor does not want to apply for .onion as a TLD, and > does not want to be the registrar for .onion [Why not? That would solve > everything by making .onion a TLD, so all the current CA rules could > apply. It is not meaningful to have a "registrar" for a namespace where everyone picks their own name, at random, by generating a keypair. > ? The Tor process for assigning .onion domains does > not require domains to be unique. The laws of chance, as noted above, means that a collision is highly, highly, highly unlikely. > If two or more website owners receive the same .onion domain (either by > accident, or by design of some of the website owners who choose what > their .onion domain will be, like Facebook did), As noted in previous emails, it would require gargantuan computing power to obtain a cert which matched an existing cert. Gerv From tom at ritter.vg Fri Feb 13 16:52:43 2015 From: tom at ritter.vg (Tom Ritter) Date: Fri, 13 Feb 2015 10:52:43 -0600 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: References: <54DD1DED.4090105@mozilla.org> <54DD289E.8040304@mozilla.org> <54DDC98E.8020907@mozilla.org> Message-ID: Damn, Gerv replied before I could. I'll add a couple notes: On 13 February 2015 at 10:28, kirk_hall at trendmicro.com < kirk_hall at trendmicro.com> wrote: > * Tor does not want to apply for .onion as a TLD, and > does not want to be the registrar for .onion [Why not? That would solve > everything by making .onion a TLD, so all the current CA rules could > apply. And remember, website users are not looking for anonymity in their > certs - they want EV certs with their identity displayed prominently in the > browsers.] > Tor will consider applying for .onion the next time the TLD rigamarole comes up. I don't believe you can just shoot off an application at this point, the process is closed until it is opened again, and no announcements on when that will be. (I could be wrong there, but that's my belief.) As Gerv said, it's strange and difficult to try and register for a generic term that you don't intend to actually process registrations for, that would not be publicly accessible. There was a big debate a few years ago I don't know the status of, but how would people feel if I wanted to register for [looks around the room, sees a picture frame] .frames and then never use it? Anyway, besides all that, the application fee is $180K and that doesn't include the cost in terms of manpower (internal and external) to apply. If anyone is willing to sponsor the costs of doing so for a non-profit, Tor will be happy to chat. > * The Tor process for assigning .onion domains does > not require domains to be unique. > Technically, no. The math makes it diminishingly small, but just on the verge of attackable. It's weak. We know. We're working on fixing it. I would say; however, that while the Tor process for assigning .onion does not require domains to be unique - the CA issuance process can. These are going to be in Certificate Transparency logs, you can go look. -tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom at ritter.vg Fri Feb 13 16:55:20 2015 From: tom at ritter.vg (Tom Ritter) Date: Fri, 13 Feb 2015 10:55:20 -0600 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names In-Reply-To: <95e76d821df3405eb58dcb116081b82b@EX2.corp.digicert.com> References: <95e76d821df3405eb58dcb116081b82b@EX2.corp.digicert.com> Message-ID: I'll voice my support for this. =) -tom On 12 February 2015 at 20:26, Jeremy Rowley wrote: > DigiCert votes "Yes" > > > > From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On > Behalf Of Jeremy Rowley > Sent: Tuesday, February 10, 2015 11:39 AM > To: public at cabforum.org > Subject: [cabfpub] Ballot 144 - Validation rules for .onion names > > > > Here's the ballot with the two typos fixed: > > > > Applicants want a CA-signed .onion address for several reasons, including: > > - Powerful web platform features are restricted to secure > origins, which are currently not available to onion names (in part, because > of the lack of IANA registration). Permitting EV certs for onion names will > help provide a secure origin for the service, moving onion towards use of > powerful web platform features. > > - Currently, access to .onion names over https from a standard > browser results in the standard existing 'Invalid Certificate' warning. > Training users to click through security warnings lowers the value of these > warnings and will cause users to miss important security information. > Removing these warnings for the user, through use of a digital certificate, > will help users recognize and avoid real MITM attacks. > > - The public needs attribution of ownership of the .onion > address to differentiate onion services, including potential phishing > services. Because onion names are not easily recognizable strings, providing > the public with additional information about the operator has significant > security improvements, especially in regions where use of the incorrect name > could have lethal consequences. > > > > The following motion has been proposed by Jeremy Rowley of DigiCert and > endorsed by Ryan Sleevi of Google and Wayne Thayer of GoDaddy. > > > > --------------------- > > Motion Starts > > --------------------- > > > > 1) Amend Section 9.2.1 of the Baseline Requirements v. 1.2.3 as follows: > > 9.2.1 Subject Alternative Name Extension > > Certificate Field: extensions:subjectAltName > > Required/Optional: Required > > Contents: This 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. The CA MUST confirm that the > Applicant controls the Fully-Qualified Domain Name or IP address or has been > granted the right to use it by the Domain Name Registrant or IP address > assignee, as appropriate. > > > > Wildcard FQDNs are permitted. As of the Effective Date of these > Requirements, prior to the issuance of a Certificate with a > subjectAlternativeName extension or Subject commonName field containing a > Reserved IP Address or Internal Name, the CA SHALL notify the Applicant that > the use of such Certificates has been deprecated by the CA / Browser Forum > and that the practice will be eliminated by October 2016. Also as of the > Effective Date, the CA SHALL NOT issue a certificate with an Expiry Date > later than 1 November 2015 with a subjectAlternativeName extension or > Subject commonName field containing a Reserved IP Address or Internal Name. > Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose > subjectAlternativeName extension or Subject commonName field contains a > Reserved IP Address or Internal Name. Effective May 1, 2015, each CA SHALL > revoke all unexpired Certificates with an Internal Name using onion as the > right-most label in an entry in the subjectAltName Extension or commonName > field unless such Certificate was issued in accordance with Appendix F of > the EV Guidelines. > > > > 2) Amend Section 9.2.2 and 11.7.1 of the Guidelines for the Issuance and > Management of Extended Validation Certificates v1.5.2 as follows: > > > > 9.2.2. Subject Alternative Name Extension Certificate field: > subjectAltName:dNSName > > Required/Optional: Required > > Contents: This extension MUST contain one or more host Domain Name(s) owned > or controlled by the Subject and to be associated with the Subject's server. > Such server MAY be owned and operated by the Subject or another entity > (e.g., a hosting service). Wildcard certificates are not allowed for EV > Certificates except as permitted under Appendix F. > > > > 11.7 Verification of Applicant's Domain Name > > > > 11.7.1. Verification Requirements > > > > (1) For each Fully-Qualified Domain Name listed in a Certificate, other than > a Domain Name with .onion in the right-most label of the Domain Name, the CA > SHALL confirm that, as of the date the Certificate was issued, the Applicant > (or the Applicant's Parent Company, Subsidiary Company, or Affiliate, > collectively referred to as "Applicant" for the purposes of this section) > either is the Domain Name Registrant or has control over the FQDN using a > procedure specified in Section 11.1.1 of the Baseline Requirements, except > that a CA MAY NOT verify a domain using the procedure described 11.1.1(7). > For a Certificate issued to a Domain Name with .onion in the right-most > label of the Domain Name, the CA SHALL confirm that, as of the date the > Certificate was issued, the Applicant's control over the .onion Domain Name > in accordance with Appendix F. > > > > (2) Mixed Character Set Domain Names: EV Certificates MAY include Domain > Names containing mixed character sets only in compliance with the rules set > forth by the domain registrar. The CA MUST visually compare any Domain Names > with mixed character sets with known high risk domains. If a similarity is > found, then the EV Certificate Request MUST be flagged as High Risk. The CA > must perform reasonably appropriate additional authentication and > verification to be certain beyond reasonable doubt that the Applicant and > the target in question are the same organization. > > > > 3) Add a new Appendix F to the Guidelines for the Issuance and Management of > Extended Validation Certificates v1.5.2: > > > > Appendix F - Issuance of Certificates for .onion Domain Names > > > > A CA may issue an EV Certificate with .onion in the right-most label of the > Domain Name provided that issuance complies with the requirements set forth > in this Appendix: > > 1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) > > The CAB Forum has created an extension of the TBSCertificate for use in > conveying hashes of keys related to .onion addresses. The Tor Service > Descriptor Hash extension has the following format: > > > > cabf-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 } > > > > TorServiceDescriptorSyntax ::= > > SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash > > > > TorServiceDescriptorHash:: = SEQUENCE { > > onionURI UTF8String > > algorithm AlgorithmIdentifier > > subjectPublicKeyHash BIT STRING } > > > > Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 6234) > performed over the DER-encoding of an ASN.1 SubjectPublicKey of the .onion > service and SubjectPublicKeyHash is the hash output. > > > > 2. The CA MUST verify the Applicant's control over the .onion Domain > Name using one of the following: > > > > a. The CA MAY verify the Applicant's control over the .onion service by > posting a specific value at a well-known URL under RFC5785. > > > > b. The CA MAY verify the Applicant's control over the .onion service by > having the Applicant provide a Certificate Request signed using the .onion > public key if the Attributes section of the certificationRequestInfo > contains: > > > > (i) A caSigningNonce attribute that 1) contains a single value > with at least 64-bits of entropy, 2) is generated by the CA, and 3) > delivered to the Applicant through a Verified Method of Communication and > > (ii) An applicantSigningNonce attribute that 1) contains a single > value with at least 64-bits of entropy and 2) is generated by the Applicant. > > > > The signing nonce attributes have the following format: > > > > caSigningNonce ATTRIBUTE ::= { > > WITH SYNTAX OCTET STRING > > EQUALITY MATCHING RULE octetStringMatch > > SINGLE VALUE TRUE > > ID { > cabf-caSigningNonce } > > } > > > > cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } > > > > applicantSigningNonce ATTRIBUTE ::= { > > WITH SYNTAX OCTET STRING > > EQUALITY MATCHING RULE octetStringMatch > > SINGLE VALUE TRUE > > ID { > cabf-applicantSigningNonce } > > } > > > > cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 } > > > > 4. Each Certificate that includes a Domain Name where .onion is in the > right-most label of the Domain Name MUST conform to the requirements of > these Guidelines, including the content requirements in Section 9 and > Appendix B of the Baseline Requirements, except that the CA MAY include a > wildcard character in the Subject Alternative Name Extension and Subject > Common Name Field as the left-most character in the .onion Domain Name > provided inclusion of the wildcard character complies with Section 11.1.3 of > the Baseline Requirements. > > > > 5. CAs MUST NOT issue a Certificate that includes a Domain Name where > .onion is in the right-most label of the Domain Name with a validity period > longer than 15 months. Despite Section 9.2.1 of the Baseline Requirements > deprecating the use of Internal Names, a CA MAY issue a Certificate > containing an .onion name with an expiration date later than 1 November 2015 > after (and only if) .onion is officially recognized by the IESG as a > reserved TLD. > > > > 6. On or before May 1, 2015, each CA MUST revoke all Certificates issued > with the Subject Alternative Name extension or Common Name field that > includes a Domain Name where .onion is in the right-most label of the Domain > Name unless the Certificate was issued in compliance with this Appendix F. > > > > ---- > > Motion Ends > > ----- > > The review period for this ballot shall commence at 2200 UTC on Thursday, 4 > February 2015, and will close at 2200 UTC on Thursday, 11 February 2015. > Unless the motion is withdrawn during the review period, the voting period > will start immediately thereafter and will close at 2200 UTC on Monday, 18 > February 2015. Votes must be cast by posting an on-list reply to this > thread. > > A vote in favor of the motion must indicate a clear 'yes' in the response. A > vote against must indicate a clear 'no' in the response. A vote to abstain > must indicate a clear 'abstain' in the response. Unclear responses will not > be counted. The latest vote received from any representative of a voting > member before the close of the voting period will be counted. Voting members > are listed here: https://cabforum.org/members/ > > In order for the motion to be adopted, two thirds or more of the votes cast > by members in the CA category and greater than 50% of the votes cast by > members in the browser category must be in favor. Quorum is currently nine > (9) members- at least nine members must participate in the ballot, either by > voting in favor, voting against, or abstaining. > > > > > > > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public > From gerv at mozilla.org Fri Feb 13 17:08:41 2015 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 13 Feb 2015 17:08:41 +0000 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: References: <54DD1DED.4090105@mozilla.org> <54DD289E.8040304@mozilla.org> <54DDC98E.8020907@mozilla.org> Message-ID: <54DE2F99.9010004@mozilla.org> On 13/02/15 16:52, Tom Ritter wrote: > Tor will consider applying for .onion the next time the TLD rigamarole > comes up. I personally think the RFC reservation is a better, quicker and cheaper route than an ICANN application. > Technically, no. The math makes it diminishingly small, but just on the > verge of attackable. ...by an extremely well-resourced adversary? Was my maths in my email to Kirk correct? If so, that seems currently beyond attackable to me. But perhaps I missed something. Gerv From tom at ritter.vg Fri Feb 13 17:12:06 2015 From: tom at ritter.vg (Tom Ritter) Date: Fri, 13 Feb 2015 11:12:06 -0600 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: <54DE2F99.9010004@mozilla.org> References: <54DD1DED.4090105@mozilla.org> <54DD289E.8040304@mozilla.org> <54DDC98E.8020907@mozilla.org> <54DE2F99.9010004@mozilla.org> Message-ID: On 13 February 2015 at 11:08, Gervase Markham wrote: > On 13/02/15 16:52, Tom Ritter wrote: >> Tor will consider applying for .onion the next time the TLD rigamarole >> comes up. > > I personally think the RFC reservation is a better, quicker and cheaper > route than an ICANN application. > >> Technically, no. The math makes it diminishingly small, but just on the >> verge of attackable. > > ...by an extremely well-resourced adversary? Was my maths in my email to > Kirk correct? If so, that seems currently beyond attackable to me. But > perhaps I missed something. No, I think it is correct. And yes, a well-resourced adversary. I think I've seen estimates that the bitcoin network as a whole turns over 2^80 in some reasonable amount of time; government agencies; a very large botnet; someone at Google gets bored ;) -tom From gerv at mozilla.org Fri Feb 13 17:18:13 2015 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 13 Feb 2015 17:18:13 +0000 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: References: <54DD1DED.4090105@mozilla.org> <54DD289E.8040304@mozilla.org> <54DDC98E.8020907@mozilla.org> <54DE2F99.9010004@mozilla.org> Message-ID: <54DE31D5.5030306@mozilla.org> On 13/02/15 17:12, Tom Ritter wrote: > No, I think it is correct. And yes, a well-resourced adversary. I > think I've seen estimates that the bitcoin network as a whole turns > over 2^80 in some reasonable amount of time; government agencies; a > very large botnet; someone at Google gets bored ;) 2^80 CPU cycles, hashes, or keypair generations? I estimated keypair generation at 1000 cycles, but it could be more expensive than that. Gerv From TShirley at trustwave.com Fri Feb 13 17:24:54 2015 From: TShirley at trustwave.com (Tim Shirley) Date: Fri, 13 Feb 2015 17:24:54 +0000 Subject: [cabfpub] Domain Validation Revision In-Reply-To: References: Message-ID: <252D51A38EFF0D4B991378E55299BFD15F7AE1AF@SKYMB1.trustwave.com> While we're in this section, do we want to consider removing the "registrant" address from item 3 as one of the WHOIS options? I only mention it because Mozilla lists only the technical and administrative fields as acceptable options at https://wiki.mozilla.org/CA:Problematic_Practices#Email_Address_Prefixes_for_DV_Certs. Or was that simply an oversight on Mozilla's part? I realize specific browser programs can and do make their requirements more stringent than the Baseline Requirements, and that this is not even a requirement from Mozilla as of yet. But that page says discussion is underway to make it mandatory, and if indeed Mozilla does not consider the registrant field to be acceptable for validating domain control, then it might reduce potential confusion to include the same restriction here. Regards, Tim From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Thursday, February 12, 2015 9:55 PM To: CABFPub (public at cabforum.org) Subject: [cabfpub] Domain Validation Revision Attached is a draft proposal from the EV working group about revising the domain validation in the BRs. The intent is 1) to eliminate the "any other option" (as it made domain validation essentially meaningless, 2) tighten up the domain validation language, and 3) permit attorney/accountants to draft the domain authorization document. Note that revising this section will automatically revise domain validation in EV. Also note that this is a draft from the working group and not yet a proposed ballot. Jeremy ________________________________ This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom at ritter.vg Fri Feb 13 17:39:35 2015 From: tom at ritter.vg (Tom Ritter) Date: Fri, 13 Feb 2015 11:39:35 -0600 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: <54DE31D5.5030306@mozilla.org> References: <54DD1DED.4090105@mozilla.org> <54DD289E.8040304@mozilla.org> <54DDC98E.8020907@mozilla.org> <54DE2F99.9010004@mozilla.org> <54DE31D5.5030306@mozilla.org> Message-ID: On 13 February 2015 at 11:18, Gervase Markham wrote: > On 13/02/15 17:12, Tom Ritter wrote: >> No, I think it is correct. And yes, a well-resourced adversary. I >> think I've seen estimates that the bitcoin network as a whole turns >> over 2^80 in some reasonable amount of time; government agencies; a >> very large botnet; someone at Google gets bored ;) > > 2^80 CPU cycles, hashes, or keypair generations? I estimated keypair > generation at 1000 cycles, but it could be more expensive than that. Alright, let me do some handwaving and back-of-the-envelope calculations. Bitcoin network appears to be at about 300,000 Trillion hashes/second, and a hash is ~64 cycles, we'll use a key gen as 1000 cycles so a keypair is 15 times as difficult. (pow(2,80) * 15) / (300000 * pow(2,40)) / 3600 / 24 / 365.25 = 1.7412731006160165 years In another expression, the bitcoin network is at 4048030.71 petaflops, which was more than the top 500 public supercomputers in the world combined. Except that's not accurate because it was in 2013 when bitcoin was even smaller. [0] So if you controlled the entire bitcoin network (HAH!), and my back of the envelope handwaving is roughly correct, you could collide a .onion address in about a year, year and a half. If you were Google, and you had the _best_ super computer in the world, it would take you (4048030.71 * 1000) / 54902.4 = ~73,731 times longer[1]. So I came out to be a little more than Gerv (1,000 years vs my 73,000) but either way we're not talking something trivial. Like I said - this is much weaker than we want for our cryptosystems. But it's not so weak that it's practically exploitable today or in the next couple years. If we're still using it in 2 years I'll be very disappointed. And unlike the internet, it is actually much easier to upgrade the whole Tor network in a relative short timespan (6 months-year). -tom [0] http://www.forbes.com/sites/reuvencohen/2013/11/28/global-bitcoin-computing-power-now-256-times-faster-than-top-500-supercomputers-combined/ [1]http://www.top500.org/lists/2014/11/ From kirk_hall at trendmicro.com Fri Feb 13 17:51:28 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Fri, 13 Feb 2015 17:51:28 +0000 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: References: <54DD1DED.4090105@mozilla.org> <54DD289E.8040304@mozilla.org> <54DDC98E.8020907@mozilla.org> <54DE2F99.9010004@mozilla.org> <54DE31D5.5030306@mozilla.org> Message-ID: Terrific calculations, Tom -- but I'm wondering how hard it was for Facebook to get their multiple .onion domains that included "facebook". Yes, I'm concerned about the possibility of an exact clash, but I'm also concerned about the ability of a hacker to get a .onion domain that includes names commonly sought by hackers. Perhaps Tor limit final .onion domains to random letters and numbers using the same pattern scanning methods that CAs use. -----Original Message----- From: Tom Ritter [mailto:tom at ritter.vg] Sent: Friday, February 13, 2015 9:40 AM To: Gervase Markham Cc: Kirk Hall (RD-US); Jeremy Rowley (jeremy.rowley at digicert.com); Ben Wilson (Ben.Wilson at digicert.com); CABFPub (public at cabforum.org) Subject: Re: [cabfpub] Ballot 144 -.onion domains On 13 February 2015 at 11:18, Gervase Markham wrote: > On 13/02/15 17:12, Tom Ritter wrote: >> No, I think it is correct. And yes, a well-resourced adversary. I >> think I've seen estimates that the bitcoin network as a whole turns >> over 2^80 in some reasonable amount of time; government agencies; a >> very large botnet; someone at Google gets bored ;) > > 2^80 CPU cycles, hashes, or keypair generations? I estimated keypair > generation at 1000 cycles, but it could be more expensive than that. Alright, let me do some handwaving and back-of-the-envelope calculations. Bitcoin network appears to be at about 300,000 Trillion hashes/second, and a hash is ~64 cycles, we'll use a key gen as 1000 cycles so a keypair is 15 times as difficult. (pow(2,80) * 15) / (300000 * pow(2,40)) / 3600 / 24 / 365.25 = 1.7412731006160165 years In another expression, the bitcoin network is at 4048030.71 petaflops, which was more than the top 500 public supercomputers in the world combined. Except that's not accurate because it was in 2013 when bitcoin was even smaller. [0] So if you controlled the entire bitcoin network (HAH!), and my back of the envelope handwaving is roughly correct, you could collide a .onion address in about a year, year and a half. If you were Google, and you had the _best_ super computer in the world, it would take you (4048030.71 * 1000) / 54902.4 = ~73,731 times longer[1]. So I came out to be a little more than Gerv (1,000 years vs my 73,000) but either way we're not talking something trivial. Like I said - this is much weaker than we want for our cryptosystems. But it's not so weak that it's practically exploitable today or in the next couple years. If we're still using it in 2 years I'll be very disappointed. And unlike the internet, it is actually much easier to upgrade the whole Tor network in a relative short timespan (6 months-year). -tom [0] http://www.forbes.com/sites/reuvencohen/2013/11/28/global-bitcoin-computing-power-now-256-times-faster-than-top-500-supercomputers-combined/ [1]http://www.top500.org/lists/2014/11/ 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
From gerv at mozilla.org Fri Feb 13 17:58:00 2015 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 13 Feb 2015 17:58:00 +0000 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: References: <54DD1DED.4090105@mozilla.org> <54DD289E.8040304@mozilla.org> <54DDC98E.8020907@mozilla.org> <54DE2F99.9010004@mozilla.org> <54DE31D5.5030306@mozilla.org> Message-ID: <54DE3B28.5030109@mozilla.org> On 13/02/15 17:51, kirk_hall at trendmicro.com wrote: > Terrific calculations, Tom -- but I'm wondering how hard it was for > Facebook to get their multiple .onion domains that included > "facebook". > > Yes, I'm concerned about the possibility of an exact clash, but I'm > also concerned about the ability of a hacker to get a .onion domain > that includes names commonly sought by hackers. Insofar as this issue is in scope for the CAB Forum, why can't we solve it using exactly the same mechanisms we use to solve it for non-onion domain names? Gerv From wthayer at godaddy.com Fri Feb 13 18:03:12 2015 From: wthayer at godaddy.com (Wayne Thayer) Date: Fri, 13 Feb 2015 18:03:12 +0000 Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group In-Reply-To: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> References: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> Message-ID: GoDaddy votes Yes. Thanks, Wayne From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Wednesday, February 04, 2015 2:05 PM To: CABFPub Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group Ballot 143 - Formalization of validation working group ---- Reason ---- In order to address validation issues and inconsistencies in both the SSL Baseline Requirements and the EV Guidelines, the CAB Forum has held an informal working group previously referred to as the Extended Validation Working Group now known as the Validation Working Group, would like to modify its scope to include validation in the Baseline Requirements as well as the EV Guidelines. Jeremy Rowley of DigiCert made the following motion, which was endorsed by Rich Smith of Comodo and Kirk Hall of TrendMicro ---- Motion begins ---- The CA-Browser Forum formally establishes the Validation Working Group as an official working group of the CAB Forum, replacing the previous informal EV working group. The scope of this working group is to address issues arising under adopted CAB Forum standards related to the validation of certificate information and the inclusion of information in certificates. Scope: The Validation Working Group will consider all matters relating to the validation and inclusion of information in certificates under adopted CAB Forum guidelines. Deliverables: The Working Group shall produce one or more documents offering options to the Forum for validation within the scope defined above. ---- Motion Ends ---- The review period for this ballot shall commence at 2200 UTC on 5 Feb 2015, and will close at 2200 UTC on 11 Feb 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on 18 Feb 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: From douglas.beattie at globalsign.com Fri Feb 13 18:45:52 2015 From: douglas.beattie at globalsign.com (Doug Beattie) Date: Fri, 13 Feb 2015 18:45:52 +0000 Subject: [cabfpub] Domain Validation Revision In-Reply-To: References: Message-ID: > -----Original Message----- > From: public-bounces at cabforum.org [mailto:public- > bounces at cabforum.org] On Behalf Of Ryan Sleevi > Sent: Thursday, February 12, 2015 10:09 PM > To: Jeremy Rowley > Cc: CABFPub (public at cabforum.org) > Subject: Re: [cabfpub] Domain Validation Revision > > > 8 concerns me for a couple reasons, even though it's moving in the right > direction. > - You require HTTPS, but that seems overkill, when you only need to perform > a TLS handshake. That is, consider a mail server configured for SMTP-S - it > seems that would be a viable configuration Sure, we can change this to be just TLS handshake. > - It would seem that anyone that can get a port forwarded on a particular > address can now get a certificate on that address. For things like STUN-TCP > services, this seems quite bad! We might want to align this with the final approach regarding making a change on the web server at a well-known URI and/or list a small number of approved ports. We'll need to circle back on this later when the other updates are closer to consensus. > - The definition of "test certificate" is, from experience, a bit of a handwave > that varies from CA to CA. It would be nice to put some explicit technical > profile in place here (e.g. a critical poison extension, a requirement that EKUs > are present but not serverAuth/clientAuth, issued from a CA independent of > the issuing CA's 'trusted' hierarchy) that would prevent relying parties from > believing the test certificate is "real" Sure, we can define what we mean by a "test" certificate to cover these. Proposed new wording for item 8): Having the Applicant demonstrate practical control over the FQDN by the Applicant requesting and then installing a Test TLS Certificate issued by the CA on the FQDN which is accessed via a TLS handshake by the CA New Definition in section 4: Test TLS Certificate: A certificate which contains a poison extension, does not have serverAuth/clientAuth, is issued under a root not in browser public key stores, or similar such methods which would render a cert unusable for TLS server use. From kirk_hall at trendmicro.com Fri Feb 13 19:25:06 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Fri, 13 Feb 2015 19:25:06 +0000 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: <54DE3B28.5030109@mozilla.org> References: <54DD1DED.4090105@mozilla.org> <54DD289E.8040304@mozilla.org> <54DDC98E.8020907@mozilla.org> <54DE2F99.9010004@mozilla.org> <54DE31D5.5030306@mozilla.org> <54DE3B28.5030109@mozilla.org> Message-ID: Maybe you're right on that point, Gerv. One other question: Does Tor do revocation checking for .onion certs? I'm guessing not for privacy reasons... I know some browsers have given up some revocation checking (a mistake in my opinion), but if we know an application never checks for revocation as a matter of policy, that would concern me. There would be no way to remove a bad cert (used for fraud or abuse, or misissued to the wrong party) from the Tor system, even if the CA revokes it. -----Original Message----- From: Gervase Markham [mailto:gerv at mozilla.org] Sent: Friday, February 13, 2015 9:58 AM To: Kirk Hall (RD-US); Tom Ritter Cc: Jeremy Rowley (jeremy.rowley at digicert.com); Ben Wilson (Ben.Wilson at digicert.com); CABFPub (public at cabforum.org) Subject: Re: [cabfpub] Ballot 144 -.onion domains On 13/02/15 17:51, kirk_hall at trendmicro.com wrote: > Terrific calculations, Tom -- but I'm wondering how hard it was for > Facebook to get their multiple .onion domains that included > "facebook". > > Yes, I'm concerned about the possibility of an exact clash, but I'm > also concerned about the ability of a hacker to get a .onion domain > that includes names commonly sought by hackers. Insofar as this issue is in scope for the CAB Forum, why can't we solve it using exactly the same mechanisms we use to solve it for non-onion domain names? Gerv 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
From tom at ritter.vg Fri Feb 13 19:38:28 2015 From: tom at ritter.vg (Tom Ritter) Date: Fri, 13 Feb 2015 13:38:28 -0600 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: References: <54DD1DED.4090105@mozilla.org> <54DD289E.8040304@mozilla.org> <54DDC98E.8020907@mozilla.org> <54DE2F99.9010004@mozilla.org> <54DE31D5.5030306@mozilla.org> <54DE3B28.5030109@mozilla.org> Message-ID: On 13 February 2015 at 13:25, kirk_hall at trendmicro.com wrote: > Maybe you're right on that point, Gerv. > > One other question: Does Tor do revocation checking for .onion certs? I'm guessing not for privacy reasons... I know some browsers have given up some revocation checking (a mistake in my opinion), but if we know an application never checks for revocation as a matter of policy, that would concern me. There would be no way to remove a bad cert (used for fraud or abuse, or misissued to the wrong party) from the Tor system, even if the CA revokes it. I do not believe that Tor Browser edits Firefox's configuration for revocation. I expected to see something here: https://gitweb.torproject.org/tor-browser.git/tree/browser/app/profile/000-tor-browser.js?h=tor-browser-31.4.0esr-4.5-1 - but the absence and other bug reports I've seen make me believe it's left as the default. -tom From kirk_hall at trendmicro.com Fri Feb 13 19:42:46 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Fri, 13 Feb 2015 19:42:46 +0000 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: References: <54DD1DED.4090105@mozilla.org> <54DD289E.8040304@mozilla.org> <54DDC98E.8020907@mozilla.org> <54DE2F99.9010004@mozilla.org> <54DE31D5.5030306@mozilla.org> <54DE3B28.5030109@mozilla.org> Message-ID: I'm over my ski tips, but... wouldn't revocation checking (by the user's client) potentially reveal which websites the Tor user is viewing? -----Original Message----- From: Tom Ritter [mailto:tom at ritter.vg] Sent: Friday, February 13, 2015 11:38 AM To: Kirk Hall (RD-US) Cc: Gervase Markham; Jeremy Rowley (jeremy.rowley at digicert.com); Ben Wilson (Ben.Wilson at digicert.com); CABFPub (public at cabforum.org) Subject: Re: [cabfpub] Ballot 144 -.onion domains On 13 February 2015 at 13:25, kirk_hall at trendmicro.com wrote: > Maybe you're right on that point, Gerv. > > One other question: Does Tor do revocation checking for .onion certs? I'm guessing not for privacy reasons... I know some browsers have given up some revocation checking (a mistake in my opinion), but if we know an application never checks for revocation as a matter of policy, that would concern me. There would be no way to remove a bad cert (used for fraud or abuse, or misissued to the wrong party) from the Tor system, even if the CA revokes it. I do not believe that Tor Browser edits Firefox's configuration for revocation. I expected to see something here: https://gitweb.torproject.org/tor-browser.git/tree/browser/app/profile/000-tor-browser.js?h=tor-browser-31.4.0esr-4.5-1 - but the absence and other bug reports I've seen make me believe it's left as the default. -tom 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
From tom at ritter.vg Fri Feb 13 19:51:41 2015 From: tom at ritter.vg (Tom Ritter) Date: Fri, 13 Feb 2015 13:51:41 -0600 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: References: <54DD1DED.4090105@mozilla.org> <54DD289E.8040304@mozilla.org> <54DDC98E.8020907@mozilla.org> <54DE2F99.9010004@mozilla.org> <54DE31D5.5030306@mozilla.org> <54DE3B28.5030109@mozilla.org> Message-ID: On Feb 13, 2015 1:42 PM, "kirk_hall at trendmicro.com" < kirk_hall at trendmicro.com> wrote: > > I'm over my ski tips, but... wouldn't revocation checking (by the user's client) potentially reveal which websites the Tor user is viewing? To the CA? Yes. But you're not going to learn anything other than that a Tor user visited the site at that time. The exit IP is a Tor IP, and TorBrowser is designed to present a uniform presentation to prevent fingerprinting. I think they may even use a different circuit so the IP wouldn't even match the IP the website sees, but I'm not certain. -tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From douglas.beattie at globalsign.com Fri Feb 13 20:27:42 2015 From: douglas.beattie at globalsign.com (Doug Beattie) Date: Fri, 13 Feb 2015 20:27:42 +0000 Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group In-Reply-To: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> References: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> Message-ID: GlobalSign votes YES Doug From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Wednesday, February 4, 2015 4:05 PM To: CABFPub Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group Ballot 143 - Formalization of validation working group ---- Reason ---- In order to address validation issues and inconsistencies in both the SSL Baseline Requirements and the EV Guidelines, the CAB Forum has held an informal working group previously referred to as the Extended Validation Working Group now known as the Validation Working Group, would like to modify its scope to include validation in the Baseline Requirements as well as the EV Guidelines. Jeremy Rowley of DigiCert made the following motion, which was endorsed by Rich Smith of Comodo and Kirk Hall of TrendMicro ---- Motion begins ---- The CA-Browser Forum formally establishes the Validation Working Group as an official working group of the CAB Forum, replacing the previous informal EV working group. The scope of this working group is to address issues arising under adopted CAB Forum standards related to the validation of certificate information and the inclusion of information in certificates. Scope: The Validation Working Group will consider all matters relating to the validation and inclusion of information in certificates under adopted CAB Forum guidelines. Deliverables: The Working Group shall produce one or more documents offering options to the Forum for validation within the scope defined above. ---- Motion Ends ---- The review period for this ballot shall commence at 2200 UTC on 5 Feb 2015, and will close at 2200 UTC on 11 Feb 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on 18 Feb 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jodycl at microsoft.com Fri Feb 13 20:28:14 2015 From: jodycl at microsoft.com (Jody Cloutier) Date: Fri, 13 Feb 2015 20:28:14 +0000 Subject: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc In-Reply-To: <763539E260C37C46A0D6B340B5434C3B0ADAE0EB@AEX06.ejsarea.net> References: <763539E260C37C46A0D6B340B5434C3B0ACD81A9@AEX06.ejsarea.net> A <763539E260C37C46A0D6B340B5434C3B0ADAE0EB@AEX06.ejsarea.net> Message-ID: Thank you, Inigo, What seems to be happening is that organizations are applying the ETSI standard in cases in which either there is no National Standards Body, or where the national standards body does not certify the company. Building on the scenario below, Audit Co is not recognized by ISRAC, but Auditor Jones has a CISP certification, which I've already confirmed with ETSI is not sufficient. I think what would help here is to make the requirement much more specific: A Qualified Auditor is limited to an auditor that is employed by a company that is certified by a National Authority listed in either the Members or Associate Members link. This, much simplified language, seems to be what you are saying below, but the current language is such that Audit Co can argue that it can issue an ETSI audit because it's company is certified by another national authority that's not listed on the ETSI webpages anywhere. Jody From: i-barreira at izenpe.net [mailto:i-barreira at izenpe.net] Sent: Friday, February 13, 2015 12:16 AM To: Jody Cloutier; public at cabforum.org Subject: RE: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Dear Jody, I understand your concern because it?s not easy for you to manage all possible combinations regarding ETSI audits in different countries so will try to clarify your example. First of all, no AuditCo has to be member of ETSI, AuditCo can perform ETSI accredited audits without being member of ETSI, they only need to be accredited in their country as stated in Annex E requirements. So, For example, * Company A is a commercial CA that operates in Israel * Auditor Jones works for AuditCo, which is based in Israel * AuditCo is certified by some governmental agency as a qualified auditor IB--> AuditCo has to be accredited under its National Accreditation Body according to ISO 17021. In the case of Israel, to follow the example, in the associated members tab of the EA, you can find the Israeli accreditation body, called ISRAC. Then AuditCo should be listed there and meeting the requirements to perform ETSI audits according to the national scheme indicated by ISRAC * AuditCo is not an ETSI Member or Associate Member IB --> this is not necessary. No need to be an ETSI member to perform ETSI audits * Auditor Jones audits Company A using the ETSI 102042 standard, and Company A sends the auditor's attestation letter to Microsoft as evidence that Company A complied with the Program's requirements. IB--> this is perfectly valid if AuditCo is listed in ISRAC and is allowed to perform ETSI audits. Of course Auditor Jones has to be also accredited to perform these kind of audits, has to be "qualified", so it?s not only the company but also the auditor, but that?s an internal task of the AuditCo. Regarding of being member of not, this is voluntary, they can join ETSI or not and don?t think that solve the problem because joining ETSI does not mean that you?re "qualified" or "accredited" to perform an ETSI audit, it?s just indicate that you belong to a club for example. And of course, if company A needs an auditing company accredited in Israel and there?s none, they can look for in other countries. For example, in Spain there?s no accredited auditing bodies to perform ETSI audits listed in our NAB, called ENAC, so, we, Izenpe, had to look for another option. So, we contacted for the first 6 years with KPMG in the Netherlands, and the last 3, with TUV IT in Germany. And Izenpe has an accredited ETSI audits according to the, right now, German national scheme and we?re listed in Germany. We?ll debate this within ETSI ESI trying to find an easier solution. Regards I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 [Descripci?n: cid:image001.png at 01CE3152.B4804EB0] ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. De: Jody Cloutier [mailto:jodycl at microsoft.com] Enviado el: mi?rcoles, 11 de febrero de 2015 0:32 Para: Barreira Iglesias, I?igo; public at cabforum.org Asunto: RE: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Thank you, Inigo. I think the problem is that, under ETSI, it's difficult to discern what an "equivalent national scheme" is. This sets up the scenario in which an auditor is employed by an organization that is recognized somehow by the government, but is not affiliated with an ETSI member organization (http://www.european-accreditation.org/home ). Microsoft does not know whether or not this auditor is qualified or not. For example, * Company A is a commercial CA that operates in Israel * Auditor Jones works for AuditCo, which is based in Israel * AuditCo is certified by some governmental agency as a qualified auditor * AuditCo is not an ETSI Member or Associate Member * Auditor Jones audits Company A using the ETSI 102042 standard, and Company A sends the auditor's attestation letter to Microsoft as evidence that Company A complied with the Program's requirements. In this scenario, how does Microsoft know that Auditor Jones conducted a proper audit without expending significant resources to determine whether and according to what standard AuditCo and Auditor Jones was certified? Microsoft believes that it would be simpler if the requirements were that the Auditor must work for a company that is affiliated with an ETSI-approved member organization. If Company A needs an auditor and there is no qualified auditor in Israel, the company can use an auditor from a member organization via the cross-border conformity rules. Unless I am fundamentally misunderstanding the rules, the above is something that Microsoft is presently struggling with, and we'd like to try to make the rules easier to understand for potential partners and ourselves. Jody Cloutier Senior Security Program Manager Microsoft Trusted Root Certificate Program jody.cloutier at microsoft.com 425.443.8922 Operating Systems Group Global Risk and Compliance [https://brandtools.microsoft.com/Style%20Library/BT/Images/MicrosoftMasterLogo.png] From: i-barreira at izenpe.net [mailto:i-barreira at izenpe.net] Sent: Tuesday, February 10, 2015 3:09 AM To: Jody Cloutier; public at cabforum.org Subject: RE: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Hi Jody, Regarding your comment on ETSI audits, I have to say that the ETSI audits shall be performed by accredited auditors as mentioned in Annex E of the current ETSI TS 102 042. ETSI audits performed by not accredited auditors shall be considered invalid. Microsoft is accepting ETSI audits since the very beginning in its root program requirements indicating this requirement. ETSI is providing a list of accredited auditors as mere information because has to be maintained by every NAB (National Accreditation Body). It?s true that this has to be improved regarding the new regulation 910/2014 and the new ENs and will take some time, but at the moment, it?s clearly stated that the audits shall be performed by accredited auditors. Don?t hesitate in contacting me for any additional information or help. Sometimes I?ve received some emails from Tom or Kelvin asking for the qualification of some audits, so, as say, you can contact me regarding this issue. Regards I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 [Descripci?n: cid:image001.png at 01CE3152.B4804EB0] ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. De: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] En nombre de Jody Cloutier Enviado el: lunes, 09 de febrero de 2015 18:55 Para: CABFPub (public at cabforum.org) Asunto: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Microsoft comments on Section 17. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 19121 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 1181 bytes Desc: image002.png URL: From jodycl at microsoft.com Fri Feb 13 20:29:41 2015 From: jodycl at microsoft.com (Jody Cloutier) Date: Fri, 13 Feb 2015 20:29:41 +0000 Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group In-Reply-To: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> References: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> Message-ID: Microsoft votes yes., From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Wednesday, February 4, 2015 1:05 PM To: CABFPub Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group Ballot 143 - Formalization of validation working group ---- Reason ---- In order to address validation issues and inconsistencies in both the SSL Baseline Requirements and the EV Guidelines, the CAB Forum has held an informal working group previously referred to as the Extended Validation Working Group now known as the Validation Working Group, would like to modify its scope to include validation in the Baseline Requirements as well as the EV Guidelines. Jeremy Rowley of DigiCert made the following motion, which was endorsed by Rich Smith of Comodo and Kirk Hall of TrendMicro ---- Motion begins ---- The CA-Browser Forum formally establishes the Validation Working Group as an official working group of the CAB Forum, replacing the previous informal EV working group. The scope of this working group is to address issues arising under adopted CAB Forum standards related to the validation of certificate information and the inclusion of information in certificates. Scope: The Validation Working Group will consider all matters relating to the validation and inclusion of information in certificates under adopted CAB Forum guidelines. Deliverables: The Working Group shall produce one or more documents offering options to the Forum for validation within the scope defined above. ---- Motion Ends ---- The review period for this ballot shall commence at 2200 UTC on 5 Feb 2015, and will close at 2200 UTC on 11 Feb 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on 18 Feb 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.wilson at digicert.com Fri Feb 13 20:38:57 2015 From: ben.wilson at digicert.com (Ben Wilson) Date: Fri, 13 Feb 2015 20:38:57 +0000 Subject: [cabfpub] [cabfquest] Domain Validation Revision In-Reply-To: <54DE3BBE.9000203@eff.org> References: <54DE3BBE.9000203@eff.org> Message-ID: Forwarding from questions list. From: questions-bounces at cabforum.org [mailto:questions-bounces at cabforum.org] On Behalf Of Jacob Hoffman-Andrews Sent: Friday, February 13, 2015 11:01 AM To: questions at cabforum.org Subject: Re: [cabfquest] [cabfpub] Domain Validation Revision Following up from a thread on cabfpub: On 02/12/2015 07:08 PM, Ryan Sleevi wrote: 8 concerns me for a couple reasons, even though it's moving in the right direction. - You require HTTPS, but that seems overkill, when you only need to perform a TLS handshake. That is, consider a mail server configured for SMTP-S - it seems that would be a viable configuration Agreed. As a concrete example, the ACME spec under discussion at IETF proposes a challenge type called "Domain Validation with Server Name Indication," or DVSNI for short: http://www.ietf.org/id/draft-barnes-acme-01.txt. We believe that DVSNI allows us to offer a higher level of assurance than item (6), "making an agreed-upon change to information found on an online Web page," since some sites allow arbitrary file upload, either by intent or by accident. We're planning to use it for the Let's Encrypt CA for that reason, so we'd like to make sure that item (8) allows for DVSNI. For example, here is a version of item (8) that we think would work: Having the Applicant demonstrate practical control over the FQDN by providing a TLS service on a host found in DNS for the FQDN. The CA SHALL initiate a TLS connection with that host and verify that the response contains unique, unguessable information proposed by the CA, in a well-specified format. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4954 bytes Desc: not available URL: From md at ssc.lt Fri Feb 13 21:00:24 2015 From: md at ssc.lt (Moudrick M. Dadashov) Date: Fri, 13 Feb 2015 23:00:24 +0200 Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group In-Reply-To: <452C99D20750E74083DBA441FF932385E4162C54@SOTTEXCH10.corp.ad.entrust.com> References: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> <452C99D20750E74083DBA441FF932385E4162C54@SOTTEXCH10.corp.ad.entrust.com> Message-ID: <54DE65E8.20202@ssc.lt> SSC votes: "Yes". Thanks, M.D. On 2/13/2015 3:46 PM, Bruce Morton wrote: > > Entrust votes Yes. > > *From:* public-bounces at cabforum.org > [mailto:public-bounces at cabforum.org] *On Behalf Of *Jeremy Rowley > *Sent:* Wednesday, February 04, 2015 4:05 PM > *To:* CABFPub > *Subject:* [cabfpub] Ballot 143 - Formalization of Validation Working > Group > > Ballot 143 - Formalization of validation working group > > ---- > > Reason > > ---- > > In order to address validation issues and inconsistencies in both the > SSL Baseline Requirements and the EV Guidelines, the CAB Forum has > held an informal working group previously referred to as the Extended > Validation Working Group now known as the Validation Working Group, > would like to modify its scope to include validation in the Baseline > Requirements as well as the EV Guidelines. > > Jeremy Rowley of DigiCert made the following motion, which was > endorsed by Rich Smith of Comodo and Kirk Hall of TrendMicro > > ---- > > Motion begins > > ---- > > The CA-Browser Forum formally establishes the Validation Working Group > as an official working group of the CAB Forum, replacing the previous > informal EV working group. The scope of this working group is to > address issues arising under adopted CAB Forum standards related to > the validation of certificate information and the inclusion of > information in certificates. > > Scope: The Validation Working Group will consider all matters relating > to the validation and inclusion of information in certificates under > adopted CAB Forum guidelines. > > Deliverables: The Working Group shall produce one or more documents > offering options to the Forum for validation within the scope defined > above. > > ---- > > Motion Ends > > ---- > > The review period for this ballot shall commence at 2200 UTC on 5 Feb > 2015, and will close at 2200 UTC on 11 Feb 2015. Unless the motion is > withdrawn during the review period, the voting period will start > immediately thereafter and will close at 2200 UTC on 18 Feb 2015. > Votes must be cast by posting an on-list reply to this thread. > > A vote in favor of the motion must indicate a clear 'yes' in the > response. A vote against must indicate a clear 'no' in the response. A > vote to abstain must indicate a clear 'abstain' in the response. > Unclear responses will not be counted. The latest vote received from > any representative of a voting member before the close of the voting > period will be counted. Voting members are listed here: > https://cabforum.org/members/ > > In order for the motion to be adopted, two thirds or more of the votes > cast by members in the CA category and greater than 50% of the votes > cast by members in the browser category must be in favor. Quorum is > currently nine (9) members? at least nine members must participate in > the ballot, either by voting in favor, voting against, or abstaining. > > > > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3653 bytes Desc: S/MIME Cryptographic Signature URL: From eddy_nigg at startcom.org Fri Feb 13 21:10:53 2015 From: eddy_nigg at startcom.org (Eddy Nigg) Date: Fri, 13 Feb 2015 23:10:53 +0200 Subject: [cabfpub] Ballot 143 In-Reply-To: <68a8241d150c4bc6bd624e08988e44fa@EX2.corp.digicert.com> References: <68a8241d150c4bc6bd624e08988e44fa@EX2.corp.digicert.com> Message-ID: <54DE685D.2000500@startcom.org> There appears to be a mistake with ballot number 143 which was previously assigned to "Remove the operational existence requirement for Government Entities" and later "Formalization of validation working group". Jeremy I believe both were initiated by you? -- Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. XMPP: startcom at startcom.org Blog: Join the Revolution! Twitter: Follow Me -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4313 bytes Desc: S/MIME Cryptographic Signature URL: From Dean_Coclin at symantec.com Fri Feb 13 21:31:20 2015 From: Dean_Coclin at symantec.com (Dean Coclin) Date: Fri, 13 Feb 2015 13:31:20 -0800 Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group In-Reply-To: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> References: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> Message-ID: <14D026C7F297AD44AC82578DD818CDD038EF1EA29E@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> Symantec votes YES. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Wednesday, February 04, 2015 4:05 PM To: CABFPub Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group Ballot 143 - Formalization of validation working group ---- Reason ---- In order to address validation issues and inconsistencies in both the SSL Baseline Requirements and the EV Guidelines, the CAB Forum has held an informal working group previously referred to as the Extended Validation Working Group now known as the Validation Working Group, would like to modify its scope to include validation in the Baseline Requirements as well as the EV Guidelines. Jeremy Rowley of DigiCert made the following motion, which was endorsed by Rich Smith of Comodo and Kirk Hall of TrendMicro ---- Motion begins ---- The CA-Browser Forum formally establishes the Validation Working Group as an official working group of the CAB Forum, replacing the previous informal EV working group. The scope of this working group is to address issues arising under adopted CAB Forum standards related to the validation of certificate information and the inclusion of information in certificates. Scope: The Validation Working Group will consider all matters relating to the validation and inclusion of information in certificates under adopted CAB Forum guidelines. Deliverables: The Working Group shall produce one or more documents offering options to the Forum for validation within the scope defined above. ---- Motion Ends ---- The review period for this ballot shall commence at 2200 UTC on 5 Feb 2015, and will close at 2200 UTC on 11 Feb 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on 18 Feb 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6130 bytes Desc: not available URL: From eddy_nigg at startcom.org Fri Feb 13 21:47:34 2015 From: eddy_nigg at startcom.org (Eddy Nigg) Date: Fri, 13 Feb 2015 23:47:34 +0200 Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group In-Reply-To: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> References: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> Message-ID: <54DE70F6.1070706@startcom.org> On 02/04/2015 11:05 PM, Jeremy Rowley wrote: > > Ballot 143 - Formalization of validation working group > StartCom votes YES to this ballot. -- Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. XMPP: startcom at startcom.org Blog: Join the Revolution! Twitter: Follow Me -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4313 bytes Desc: S/MIME Cryptographic Signature URL: From Dean_Coclin at symantec.com Fri Feb 13 22:33:48 2015 From: Dean_Coclin at symantec.com (Dean Coclin) Date: Fri, 13 Feb 2015 14:33:48 -0800 Subject: [cabfpub] IPv6 support References: <14D026C7F297AD44AC82578DD818CDD038EEF0BA5B@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C01141460BD37468D1@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <14D026C7F297AD44AC82578DD818CDD038EEF0BFAD@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> Message-ID: <14D026C7F297AD44AC82578DD818CDD038EF1EA316@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> Ryan, As discussed on the last CA/B call, I was asked to poll the CASC members on their support of IPv6. The results are below. You'll probably realize after reading this that there isn't much actionable material here as many members are "scoping" or "waiting for info" without any concrete response dates. We'll keep this tally going and update as we get more info. Globalsign: Yes, can support Symantec: We don't support this today. We've received very little demand for it from customers, but we're in the process of scoping out the effort. Comodo: Yes, for CRL and OCSP Trend Micro: Yes GoDaddy: Waiting for info from network team Entrust: Yes for CRL and OCSP. Trustwave: We don't support this today. Just started scoping the effort. Not many requests for this Digicert: We currently do not support it. Our connectivity providers support it, and it could be done with CRLs and OCSP, but we'd need to look for any gotchas before pulling the trigger. We've only had a couple of customers ask whether we support it. Thanks, Dean -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6130 bytes Desc: not available URL: From kirk_hall at trendmicro.com Fri Feb 13 22:52:38 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Fri, 13 Feb 2015 22:52:38 +0000 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names Message-ID: Trend Micro abstains Kirk R. Hall Operations Director, Trust Services Trend Micro +1.503.753.3088 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
-------------- next part -------------- An HTML attachment was scrubbed... URL: From eddy_nigg at startcom.org Fri Feb 13 22:58:11 2015 From: eddy_nigg at startcom.org (Eddy Nigg) Date: Sat, 14 Feb 2015 00:58:11 +0200 Subject: [cabfpub] IPv6 support In-Reply-To: <14D026C7F297AD44AC82578DD818CDD038EF1EA316@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> References: <14D026C7F297AD44AC82578DD818CDD038EEF0BA5B@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C01141460BD37468D1@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <14D026C7F297AD44AC82578DD818CDD038EEF0BFAD@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> <14D026C7F297AD44AC82578DD818CDD038EF1EA316@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> Message-ID: <54DE8183.1060204@startcom.org> On 02/14/2015 12:33 AM, Dean Coclin wrote: > You'll probably realize after reading this that there isn't much > actionable material here as many members are "scoping" or "waiting for > info" without any concrete response dates. We'll keep this tally > going and update as we get more info. > > Globalsign: Yes, can support > > Symantec: We don't support this today. We've received very little > demand for it from customers, but we're in the process of scoping out > the effort. > > Comodo:Yes, for CRL and OCSP > > TrendMicro:Yes > GoDaddy: Waiting for info from network team > > Entrust:Yes for CRL and OCSP. > > Trustwave:We don't support this today. Just started scoping the > effort. Not many requests for this > > Digicert:We currently do not support it. Our connectivity providers > support it, and it could be done with CRLs and OCSP, but we'd need to > look for any gotchas before pulling the trigger. We've only had a > couple of customers ask whether we support it. > To add StartCom to the list, we could support it for almost everything, but we have some historical CRL distribution points that can't support IPv6 for now. It seems that OCSP would work, but CRLs not 100%. Same as with Digicert, demand for IPv6 has been so low that we haven't invested into it so far. -- Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. XMPP: startcom at startcom.org Blog: Join the Revolution! Twitter: Follow Me -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4313 bytes Desc: S/MIME Cryptographic Signature URL: From wthayer at godaddy.com Sat Feb 14 00:02:09 2015 From: wthayer at godaddy.com (Wayne Thayer) Date: Sat, 14 Feb 2015 00:02:09 +0000 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names In-Reply-To: References: Message-ID: GoDaddy votes Yes. Thanks, Wayne From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Tuesday, February 10, 2015 11:39 AM To: public at cabforum.org Subject: [cabfpub] Ballot 144 - Validation rules for .onion names Here's the ballot with the two typos fixed: Applicants want a CA-signed .onion address for several reasons, including: - Powerful web platform features are restricted to secure origins, which are currently not available to onion names (in part, because of the lack of IANA registration). Permitting EV certs for onion names will help provide a secure origin for the service, moving onion towards use of powerful web platform features. - Currently, access to .onion names over https from a standard browser results in the standard existing 'Invalid Certificate' warning. Training users to click through security warnings lowers the value of these warnings and will cause users to miss important security information. Removing these warnings for the user, through use of a digital certificate, will help users recognize and avoid real MITM attacks. - The public needs attribution of ownership of the .onion address to differentiate onion services, including potential phishing services. Because onion names are not easily recognizable strings, providing the public with additional information about the operator has significant security improvements, especially in regions where use of the incorrect name could have lethal consequences. The following motion has been proposed by Jeremy Rowley of DigiCert and endorsed by Ryan Sleevi of Google and Wayne Thayer of GoDaddy. --------------------- Motion Starts --------------------- 1) Amend Section 9.2.1 of the Baseline Requirements v. 1.2.3 as follows: 9.2.1 Subject Alternative Name Extension Certificate Field: extensions:subjectAltName Required/Optional: Required Contents: This 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. The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate. Wildcard FQDNs are permitted. As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name, the CA SHALL notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016. Also as of the Effective Date, the CA SHALL NOT issue a certificate with an Expiry Date later than 1 November 2015 with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name. Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Name. Effective May 1, 2015, each CA SHALL revoke all unexpired Certificates with an Internal Name using onion as the right-most label in an entry in the subjectAltName Extension or commonName field unless such Certificate was issued in accordance with Appendix F of the EV Guidelines. 2) Amend Section 9.2.2 and 11.7.1 of the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2 as follows: 9.2.2. Subject Alternative Name Extension Certificate field: subjectAltName:dNSName Required/Optional: Required Contents: This extension MUST contain one or more host Domain Name(s) owned or controlled by the Subject and to be associated with the Subject's server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). Wildcard certificates are not allowed for EV Certificates except as permitted under Appendix F. 11.7 Verification of Applicant's Domain Name 11.7.1. Verification Requirements (1) For each Fully-Qualified Domain Name listed in a Certificate, other than a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant (or the Applicant's Parent Company, Subsidiary Company, or Affiliate, collectively referred to as "Applicant" for the purposes of this section) either is the Domain Name Registrant or has control over the FQDN using a procedure specified in Section 11.1.1 of the Baseline Requirements, except that a CA MAY NOT verify a domain using the procedure described 11.1.1(7). For a Certificate issued to a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant's control over the .onion Domain Name in accordance with Appendix F. (2) Mixed Character Set Domain Names: EV Certificates MAY include Domain Names containing mixed character sets only in compliance with the rules set forth by the domain registrar. The CA MUST visually compare any Domain Names with mixed character sets with known high risk domains. If a similarity is found, then the EV Certificate Request MUST be flagged as High Risk. The CA must perform reasonably appropriate additional authentication and verification to be certain beyond reasonable doubt that the Applicant and the target in question are the same organization. 3) Add a new Appendix F to the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2: Appendix F - Issuance of Certificates for .onion Domain Names A CA may issue an EV Certificate with .onion in the right-most label of the Domain Name provided that issuance complies with the requirements set forth in this Appendix: 1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) The CAB Forum has created an extension of the TBSCertificate for use in conveying hashes of keys related to .onion addresses. The Tor Service Descriptor Hash extension has the following format: cabf-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 } TorServiceDescriptorSyntax ::= SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash TorServiceDescriptorHash:: = SEQUENCE { onionURI UTF8String algorithm AlgorithmIdentifier subjectPublicKeyHash BIT STRING } Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 6234) performed over the DER-encoding of an ASN.1 SubjectPublicKey of the .onion service and SubjectPublicKeyHash is the hash output. 2. The CA MUST verify the Applicant's control over the .onion Domain Name using one of the following: a. The CA MAY verify the Applicant's control over the .onion service by posting a specific value at a well-known URL under RFC5785. b. The CA MAY verify the Applicant's control over the .onion service by having the Applicant provide a Certificate Request signed using the .onion public key if the Attributes section of the certificationRequestInfo contains: (i) A caSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy, 2) is generated by the CA, and 3) delivered to the Applicant through a Verified Method of Communication and (ii) An applicantSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy and 2) is generated by the Applicant. The signing nonce attributes have the following format: caSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-caSigningNonce } } cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } applicantSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-applicantSigningNonce } } cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 } 4. Each Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name MUST conform to the requirements of these Guidelines, including the content requirements in Section 9 and Appendix B of the Baseline Requirements, except that the CA MAY include a wildcard character in the Subject Alternative Name Extension and Subject Common Name Field as the left-most character in the .onion Domain Name provided inclusion of the wildcard character complies with Section 11.1.3 of the Baseline Requirements. 5. CAs MUST NOT issue a Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name with a validity period longer than 15 months. Despite Section 9.2.1 of the Baseline Requirements deprecating the use of Internal Names, a CA MAY issue a Certificate containing an .onion name with an expiration date later than 1 November 2015 after (and only if) .onion is officially recognized by the IESG as a reserved TLD. 6. On or before May 1, 2015, each CA MUST revoke all Certificates issued with the Subject Alternative Name extension or Common Name field that includes a Domain Name where .onion is in the right-most label of the Domain Name unless the Certificate was issued in compliance with this Appendix F. ---- Motion Ends ----- The review period for this ballot shall commence at 2200 UTC on Thursday, 4 February 2015, and will close at 2200 UTC on Thursday, 11 February 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on Monday, 18 February 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Patrick.Tronnier at oati.net Sat Feb 14 03:53:43 2015 From: Patrick.Tronnier at oati.net (Patrick Tronnier) Date: Sat, 14 Feb 2015 03:53:43 +0000 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names In-Reply-To: <5c04557077cf4564979bc37e501297de@EX2.corp.digicert.com> References: , <5c04557077cf4564979bc37e501297de@EX2.corp.digicert.com> Message-ID: <4F1C24C0-B730-495E-AE84-098FC341323E@oati.net> OATI abstains. Thanks, With kind regards, Patrick Tronnier Principal Security Architect & Sr. Director of Quality Assurance Phone: 763.201.2000 Fax: 763.201.5333 Direct Line: 763.201.2052 Open Access Technology International, Inc. 3660 Technology Drive NE, Minneapolis, MN 55418 CONFIDENTIAL INFORMATION: This email and any attachment(s) contain confidential and/or proprietary information of Open Access Technology International, Inc. Do not copy or distribute without the prior written consent of OATI. If you are not a named recipient to the message, please notify the sender immediately and do not retain the message in any form, printed or electronic. On Feb 10, 2015, at 3:03 PM, Ben Wilson > wrote: I?ll post this to the public page with a correction stating that the review period ends and the voting period of the ballot begins to run from Wednesday, 11 Feb., to Wednesday, 18 Feb. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Tuesday, February 10, 2015 11:39 AM To: public at cabforum.org Subject: [cabfpub] Ballot 144 - Validation rules for .onion names Here?s the ballot with the two typos fixed: Applicants want a CA-signed .onion address for several reasons, including: - Powerful web platform features are restricted to secure origins, which are currently not available to onion names (in part, because of the lack of IANA registration). Permitting EV certs for onion names will help provide a secure origin for the service, moving onion towards use of powerful web platform features. - Currently, access to .onion names over https from a standard browser results in the standard existing 'Invalid Certificate' warning. Training users to click through security warnings lowers the value of these warnings and will cause users to miss important security information. Removing these warnings for the user, through use of a digital certificate, will help users recognize and avoid real MITM attacks. - The public needs attribution of ownership of the .onion address to differentiate onion services, including potential phishing services. Because onion names are not easily recognizable strings, providing the public with additional information about the operator has significant security improvements, especially in regions where use of the incorrect name could have lethal consequences. The following motion has been proposed by Jeremy Rowley of DigiCert and endorsed by Ryan Sleevi of Google and Wayne Thayer of GoDaddy. --------------------- Motion Starts --------------------- 1) Amend Section 9.2.1 of the Baseline Requirements v. 1.2.3 as follows: 9.2.1 Subject Alternative Name Extension Certificate Field: extensions:subjectAltName Required/Optional: Required Contents: This 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. The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate. Wildcard FQDNs are permitted. As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name, the CA SHALL notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016. Also as of the Effective Date, the CA SHALL NOT issue a certificate with an Expiry Date later than 1 November 2015 with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name. Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Name. Effective May 1, 2015, each CA SHALL revoke all unexpired Certificates with an Internal Name using onion as the right-most label in an entry in the subjectAltName Extension or commonName field unless such Certificate was issued in accordance with Appendix F of the EV Guidelines. 2) Amend Section 9.2.2 and 11.7.1 of the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2 as follows: 9.2.2. Subject Alternative Name Extension Certificate field: subjectAltName:dNSName Required/Optional: Required Contents: This extension MUST contain one or more host Domain Name(s) owned or controlled by the Subject and to be associated with the Subject?s server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). Wildcard certificates are not allowed for EV Certificates except as permitted under Appendix F. 11.7 Verification of Applicant?s Domain Name 11.7.1. Verification Requirements (1) For each Fully-Qualified Domain Name listed in a Certificate, other than a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant (or the Applicant?s Parent Company, Subsidiary Company, or Affiliate, collectively referred to as ?Applicant? for the purposes of this section) either is the Domain Name Registrant or has control over the FQDN using a procedure specified in Section 11.1.1 of the Baseline Requirements, except that a CA MAY NOT verify a domain using the procedure described 11.1.1(7). For a Certificate issued to a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant?s control over the .onion Domain Name in accordance with Appendix F. (2) Mixed Character Set Domain Names: EV Certificates MAY include Domain Names containing mixed character sets only in compliance with the rules set forth by the domain registrar. The CA MUST visually compare any Domain Names with mixed character sets with known high risk domains. If a similarity is found, then the EV Certificate Request MUST be flagged as High Risk. The CA must perform reasonably appropriate additional authentication and verification to be certain beyond reasonable doubt that the Applicant and the target in question are the same organization. 3) Add a new Appendix F to the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2: Appendix F ? Issuance of Certificates for .onion Domain Names A CA may issue an EV Certificate with .onion in the right-most label of the Domain Name provided that issuance complies with the requirements set forth in this Appendix: 1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) The CAB Forum has created an extension of the TBSCertificate for use in conveying hashes of keys related to .onion addresses. The Tor Service Descriptor Hash extension has the following format: cabf-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 } TorServiceDescriptorSyntax ::= SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash TorServiceDescriptorHash:: = SEQUENCE { onionURI UTF8String algorithm AlgorithmIdentifier subjectPublicKeyHash BIT STRING } Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 6234) performed over the DER-encoding of an ASN.1 SubjectPublicKey of the .onion service and SubjectPublicKeyHash is the hash output. 2. The CA MUST verify the Applicant?s control over the .onion Domain Name using one of the following: a. The CA MAY verify the Applicant?s control over the .onion service by posting a specific value at a well-known URL under RFC5785. b. The CA MAY verify the Applicant?s control over the .onion service by having the Applicant provide a Certificate Request signed using the .onion public key if the Attributes section of the certificationRequestInfo contains: (i) A caSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy, 2) is generated by the CA, and 3) delivered to the Applicant through a Verified Method of Communication and (ii) An applicantSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy and 2) is generated by the Applicant. The signing nonce attributes have the following format: caSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-caSigningNonce } } cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } applicantSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-applicantSigningNonce } } cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 } 4. Each Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name MUST conform to the requirements of these Guidelines, including the content requirements in Section 9 and Appendix B of the Baseline Requirements, except that the CA MAY include a wildcard character in the Subject Alternative Name Extension and Subject Common Name Field as the left-most character in the .onion Domain Name provided inclusion of the wildcard character complies with Section 11.1.3 of the Baseline Requirements. 5. CAs MUST NOT issue a Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name with a validity period longer than 15 months. Despite Section 9.2.1 of the Baseline Requirements deprecating the use of Internal Names, a CA MAY issue a Certificate containing an .onion name with an expiration date later than 1 November 2015 after (and only if) .onion is officially recognized by the IESG as a reserved TLD. 6. On or before May 1, 2015, each CA MUST revoke all Certificates issued with the Subject Alternative Name extension or Common Name field that includes a Domain Name where .onion is in the right-most label of the Domain Name unless the Certificate was issued in compliance with this Appendix F. ---- Motion Ends ----- The review period for this ballot shall commence at 2200 UTC on Thursday, 4 February 2015, and will close at 2200 UTC on Thursday, 11 February 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on Monday, 18 February 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members? at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. _______________________________________________ Public mailing list Public at cabforum.org https://cabforum.org/mailman/listinfo/public From richard at wosign.com Sat Feb 14 03:52:38 2015 From: richard at wosign.com (Richard Wang) Date: Sat, 14 Feb 2015 03:52:38 +0000 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names In-Reply-To: References: Message-ID: <84AFFBBCB7046F44B89AAD7AC09C4A06153353E5@ex2.corp.wosign.com> WoSign vote ?abstains? Best Regards, Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5075 bytes Desc: not available URL: From richard at wosign.com Sat Feb 14 03:53:37 2015 From: richard at wosign.com (Richard Wang) Date: Sat, 14 Feb 2015 03:53:37 +0000 Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group In-Reply-To: <54DE70F6.1070706@startcom.org> References: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> <54DE70F6.1070706@startcom.org> Message-ID: <84AFFBBCB7046F44B89AAD7AC09C4A0615335403@ex2.corp.wosign.com> WoSign votes YES Best Regards, Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5075 bytes Desc: not available URL: From eddy_nigg at startcom.org Sun Feb 15 18:01:57 2015 From: eddy_nigg at startcom.org (Eddy Nigg) Date: Sun, 15 Feb 2015 20:01:57 +0200 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names In-Reply-To: References: Message-ID: <54E0DF15.6060006@startcom.org> StartCom abstains as well for now. On 02/14/2015 12:52 AM, kirk_hall at trendmicro.com wrote: > > Trend Micro abstains > > */Kirk R. Hall/* > > Operations Director, Trust Services > > Trend Micro > > +1.503.753.3088 > -- Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. XMPP: startcom at startcom.org Blog: Join the Revolution! Twitter: Follow Me -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4313 bytes Desc: S/MIME Cryptographic Signature URL: From Dean_Coclin at symantec.com Sun Feb 15 20:50:13 2015 From: Dean_Coclin at symantec.com (Dean Coclin) Date: Sun, 15 Feb 2015 12:50:13 -0800 Subject: [cabfpub] Minutes of recent CA/B Forum meetings Message-ID: <14D026C7F297AD44AC82578DD818CDD038EF1EA3EE@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> It occurred to me that I may not have sent to the public list the minutes from recent meetings. They can be found here: https://cabforum.org/2015/01/22/2015-01-22-minutes/ https://cabforum.org/2015/01/08/2015-01-08-minutes/ All previous meeting minutes are located here: https://cabforum.org/category/proceedings/minutes/ Dean Coclin CA/B Forum Chair -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6130 bytes Desc: not available URL: From Dean_Coclin at symantec.com Sun Feb 15 21:39:31 2015 From: Dean_Coclin at symantec.com (Dean Coclin) Date: Sun, 15 Feb 2015 13:39:31 -0800 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names In-Reply-To: References: Message-ID: <14D026C7F297AD44AC82578DD818CDD038EF1EA3F7@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> Symantec votes YES From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Tuesday, February 10, 2015 1:39 PM To: public at cabforum.org Subject: [cabfpub] Ballot 144 - Validation rules for .onion names Here's the ballot with the two typos fixed: Applicants want a CA-signed .onion address for several reasons, including: - Powerful web platform features are restricted to secure origins, which are currently not available to onion names (in part, because of the lack of IANA registration). Permitting EV certs for onion names will help provide a secure origin for the service, moving onion towards use of powerful web platform features. - Currently, access to .onion names over https from a standard browser results in the standard existing 'Invalid Certificate' warning. Training users to click through security warnings lowers the value of these warnings and will cause users to miss important security information. Removing these warnings for the user, through use of a digital certificate, will help users recognize and avoid real MITM attacks. - The public needs attribution of ownership of the .onion address to differentiate onion services, including potential phishing services. Because onion names are not easily recognizable strings, providing the public with additional information about the operator has significant security improvements, especially in regions where use of the incorrect name could have lethal consequences. The following motion has been proposed by Jeremy Rowley of DigiCert and endorsed by Ryan Sleevi of Google and Wayne Thayer of GoDaddy. --------------------- Motion Starts --------------------- 1) Amend Section 9.2.1 of the Baseline Requirements v. 1.2.3 as follows: 9.2.1 Subject Alternative Name Extension Certificate Field: extensions:subjectAltName Required/Optional: Required Contents: This 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. The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate. Wildcard FQDNs are permitted. As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name, the CA SHALL notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016. Also as of the Effective Date, the CA SHALL NOT issue a certificate with an Expiry Date later than 1 November 2015 with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name. Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Name. Effective May 1, 2015, each CA SHALL revoke all unexpired Certificates with an Internal Name using onion as the right-most label in an entry in the subjectAltName Extension or commonName field unless such Certificate was issued in accordance with Appendix F of the EV Guidelines. 2) Amend Section 9.2.2 and 11.7.1 of the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2 as follows: 9.2.2. Subject Alternative Name Extension Certificate field: subjectAltName:dNSName Required/Optional: Required Contents: This extension MUST contain one or more host Domain Name(s) owned or controlled by the Subject and to be associated with the Subject's server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). Wildcard certificates are not allowed for EV Certificates except as permitted under Appendix F. 11.7 Verification of Applicant's Domain Name 11.7.1. Verification Requirements (1) For each Fully-Qualified Domain Name listed in a Certificate, other than a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant (or the Applicant's Parent Company, Subsidiary Company, or Affiliate, collectively referred to as "Applicant" for the purposes of this section) either is the Domain Name Registrant or has control over the FQDN using a procedure specified in Section 11.1.1 of the Baseline Requirements, except that a CA MAY NOT verify a domain using the procedure described 11.1.1(7). For a Certificate issued to a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant's control over the .onion Domain Name in accordance with Appendix F. (2) Mixed Character Set Domain Names: EV Certificates MAY include Domain Names containing mixed character sets only in compliance with the rules set forth by the domain registrar. The CA MUST visually compare any Domain Names with mixed character sets with known high risk domains. If a similarity is found, then the EV Certificate Request MUST be flagged as High Risk. The CA must perform reasonably appropriate additional authentication and verification to be certain beyond reasonable doubt that the Applicant and the target in question are the same organization. 3) Add a new Appendix F to the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2: Appendix F - Issuance of Certificates for .onion Domain Names A CA may issue an EV Certificate with .onion in the right-most label of the Domain Name provided that issuance complies with the requirements set forth in this Appendix: 1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) The CAB Forum has created an extension of the TBSCertificate for use in conveying hashes of keys related to .onion addresses. The Tor Service Descriptor Hash extension has the following format: cabf-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 } TorServiceDescriptorSyntax ::= SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash TorServiceDescriptorHash:: = SEQUENCE { onionURI UTF8String algorithm AlgorithmIdentifier subjectPublicKeyHash BIT STRING } Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 6234) performed over the DER-encoding of an ASN.1 SubjectPublicKey of the .onion service and SubjectPublicKeyHash is the hash output. 2. The CA MUST verify the Applicant's control over the .onion Domain Name using one of the following: a. The CA MAY verify the Applicant's control over the .onion service by posting a specific value at a well-known URL under RFC5785. b. The CA MAY verify the Applicant's control over the .onion service by having the Applicant provide a Certificate Request signed using the .onion public key if the Attributes section of the certificationRequestInfo contains: (i) A caSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy, 2) is generated by the CA, and 3) delivered to the Applicant through a Verified Method of Communication and (ii) An applicantSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy and 2) is generated by the Applicant. The signing nonce attributes have the following format: caSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-caSigningNonce } } cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } applicantSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-applicantSigningNonce } } cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 } 4. Each Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name MUST conform to the requirements of these Guidelines, including the content requirements in Section 9 and Appendix B of the Baseline Requirements, except that the CA MAY include a wildcard character in the Subject Alternative Name Extension and Subject Common Name Field as the left-most character in the .onion Domain Name provided inclusion of the wildcard character complies with Section 11.1.3 of the Baseline Requirements. 5. CAs MUST NOT issue a Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name with a validity period longer than 15 months. Despite Section 9.2.1 of the Baseline Requirements deprecating the use of Internal Names, a CA MAY issue a Certificate containing an .onion name with an expiration date later than 1 November 2015 after (and only if) .onion is officially recognized by the IESG as a reserved TLD. 6. On or before May 1, 2015, each CA MUST revoke all Certificates issued with the Subject Alternative Name extension or Common Name field that includes a Domain Name where .onion is in the right-most label of the Domain Name unless the Certificate was issued in compliance with this Appendix F. ---- Motion Ends ----- The review period for this ballot shall commence at 2200 UTC on Thursday, 4 February 2015, and will close at 2200 UTC on Thursday, 11 February 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on Monday, 18 February 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6130 bytes Desc: not available URL: From sleevi at google.com Mon Feb 16 00:44:08 2015 From: sleevi at google.com (Ryan Sleevi) Date: Sun, 15 Feb 2015 16:44:08 -0800 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names In-Reply-To: <14D026C7F297AD44AC82578DD818CDD038EF1EA3F7@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> References: <14D026C7F297AD44AC82578DD818CDD038EF1EA3F7@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> Message-ID: Google votes YES. On Sun, Feb 15, 2015 at 1:39 PM, Dean Coclin wrote: > Symantec votes YES > > > > From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On > Behalf Of Jeremy Rowley > Sent: Tuesday, February 10, 2015 1:39 PM > To: public at cabforum.org > Subject: [cabfpub] Ballot 144 - Validation rules for .onion names > > > > Here?s the ballot with the two typos fixed: > > > > Applicants want a CA-signed .onion address for several reasons, including: > > - Powerful web platform features are restricted to secure > origins, which are currently not available to onion names (in part, because > of the lack of IANA registration). Permitting EV certs for onion names will > help provide a secure origin for the service, moving onion towards use of > powerful web platform features. > > - Currently, access to .onion names over https from a standard > browser results in the standard existing 'Invalid Certificate' warning. > Training users to click through security warnings lowers the value of these > warnings and will cause users to miss important security information. > Removing these warnings for the user, through use of a digital certificate, > will help users recognize and avoid real MITM attacks. > > - The public needs attribution of ownership of the .onion > address to differentiate onion services, including potential phishing > services. Because onion names are not easily recognizable strings, providing > the public with additional information about the operator has significant > security improvements, especially in regions where use of the incorrect name > could have lethal consequences. > > > > The following motion has been proposed by Jeremy Rowley of DigiCert and > endorsed by Ryan Sleevi of Google and Wayne Thayer of GoDaddy. > > > > --------------------- > > Motion Starts > > --------------------- > > > > 1) Amend Section 9.2.1 of the Baseline Requirements v. 1.2.3 as follows: > > 9.2.1 Subject Alternative Name Extension > > Certificate Field: extensions:subjectAltName > > Required/Optional: Required > > Contents: This 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. The CA MUST confirm that the > Applicant controls the Fully-Qualified Domain Name or IP address or has been > granted the right to use it by the Domain Name Registrant or IP address > assignee, as appropriate. > > > > Wildcard FQDNs are permitted. As of the Effective Date of these > Requirements, prior to the issuance of a Certificate with a > subjectAlternativeName extension or Subject commonName field containing a > Reserved IP Address or Internal Name, the CA SHALL notify the Applicant that > the use of such Certificates has been deprecated by the CA / Browser Forum > and that the practice will be eliminated by October 2016. Also as of the > Effective Date, the CA SHALL NOT issue a certificate with an Expiry Date > later than 1 November 2015 with a subjectAlternativeName extension or > Subject commonName field containing a Reserved IP Address or Internal Name. > Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose > subjectAlternativeName extension or Subject commonName field contains a > Reserved IP Address or Internal Name. Effective May 1, 2015, each CA SHALL > revoke all unexpired Certificates with an Internal Name using onion as the > right-most label in an entry in the subjectAltName Extension or commonName > field unless such Certificate was issued in accordance with Appendix F of > the EV Guidelines. > > > > 2) Amend Section 9.2.2 and 11.7.1 of the Guidelines for the Issuance and > Management of Extended Validation Certificates v1.5.2 as follows: > > > > 9.2.2. Subject Alternative Name Extension Certificate field: > subjectAltName:dNSName > > Required/Optional: Required > > Contents: This extension MUST contain one or more host Domain Name(s) owned > or controlled by the Subject and to be associated with the Subject?s server. > Such server MAY be owned and operated by the Subject or another entity > (e.g., a hosting service). Wildcard certificates are not allowed for EV > Certificates except as permitted under Appendix F. > > > > 11.7 Verification of Applicant?s Domain Name > > > > 11.7.1. Verification Requirements > > > > (1) For each Fully-Qualified Domain Name listed in a Certificate, other than > a Domain Name with .onion in the right-most label of the Domain Name, the CA > SHALL confirm that, as of the date the Certificate was issued, the Applicant > (or the Applicant?s Parent Company, Subsidiary Company, or Affiliate, > collectively referred to as ?Applicant? for the purposes of this section) > either is the Domain Name Registrant or has control over the FQDN using a > procedure specified in Section 11.1.1 of the Baseline Requirements, except > that a CA MAY NOT verify a domain using the procedure described 11.1.1(7). > For a Certificate issued to a Domain Name with .onion in the right-most > label of the Domain Name, the CA SHALL confirm that, as of the date the > Certificate was issued, the Applicant?s control over the .onion Domain Name > in accordance with Appendix F. > > > > (2) Mixed Character Set Domain Names: EV Certificates MAY include Domain > Names containing mixed character sets only in compliance with the rules set > forth by the domain registrar. The CA MUST visually compare any Domain Names > with mixed character sets with known high risk domains. If a similarity is > found, then the EV Certificate Request MUST be flagged as High Risk. The CA > must perform reasonably appropriate additional authentication and > verification to be certain beyond reasonable doubt that the Applicant and > the target in question are the same organization. > > > > 3) Add a new Appendix F to the Guidelines for the Issuance and Management of > Extended Validation Certificates v1.5.2: > > > > Appendix F ? Issuance of Certificates for .onion Domain Names > > > > A CA may issue an EV Certificate with .onion in the right-most label of the > Domain Name provided that issuance complies with the requirements set forth > in this Appendix: > > 1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) > > The CAB Forum has created an extension of the TBSCertificate for use in > conveying hashes of keys related to .onion addresses. The Tor Service > Descriptor Hash extension has the following format: > > > > cabf-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 } > > > > TorServiceDescriptorSyntax ::= > > SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash > > > > TorServiceDescriptorHash:: = SEQUENCE { > > onionURI UTF8String > > algorithm AlgorithmIdentifier > > subjectPublicKeyHash BIT STRING } > > > > Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 6234) > performed over the DER-encoding of an ASN.1 SubjectPublicKey of the .onion > service and SubjectPublicKeyHash is the hash output. > > > > 2. The CA MUST verify the Applicant?s control over the .onion Domain > Name using one of the following: > > > > a. The CA MAY verify the Applicant?s control over the .onion service by > posting a specific value at a well-known URL under RFC5785. > > > > b. The CA MAY verify the Applicant?s control over the .onion service by > having the Applicant provide a Certificate Request signed using the .onion > public key if the Attributes section of the certificationRequestInfo > contains: > > > > (i) A caSigningNonce attribute that 1) contains a single value > with at least 64-bits of entropy, 2) is generated by the CA, and 3) > delivered to the Applicant through a Verified Method of Communication and > > (ii) An applicantSigningNonce attribute that 1) contains a single > value with at least 64-bits of entropy and 2) is generated by the Applicant. > > > > The signing nonce attributes have the following format: > > > > caSigningNonce ATTRIBUTE ::= { > > WITH SYNTAX OCTET STRING > > EQUALITY MATCHING RULE octetStringMatch > > SINGLE VALUE TRUE > > ID { > cabf-caSigningNonce } > > } > > > > cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } > > > > applicantSigningNonce ATTRIBUTE ::= { > > WITH SYNTAX OCTET STRING > > EQUALITY MATCHING RULE octetStringMatch > > SINGLE VALUE TRUE > > ID { > cabf-applicantSigningNonce } > > } > > > > cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 } > > > > 4. Each Certificate that includes a Domain Name where .onion is in the > right-most label of the Domain Name MUST conform to the requirements of > these Guidelines, including the content requirements in Section 9 and > Appendix B of the Baseline Requirements, except that the CA MAY include a > wildcard character in the Subject Alternative Name Extension and Subject > Common Name Field as the left-most character in the .onion Domain Name > provided inclusion of the wildcard character complies with Section 11.1.3 of > the Baseline Requirements. > > > > 5. CAs MUST NOT issue a Certificate that includes a Domain Name where > .onion is in the right-most label of the Domain Name with a validity period > longer than 15 months. Despite Section 9.2.1 of the Baseline Requirements > deprecating the use of Internal Names, a CA MAY issue a Certificate > containing an .onion name with an expiration date later than 1 November 2015 > after (and only if) .onion is officially recognized by the IESG as a > reserved TLD. > > > > 6. On or before May 1, 2015, each CA MUST revoke all Certificates issued > with the Subject Alternative Name extension or Common Name field that > includes a Domain Name where .onion is in the right-most label of the Domain > Name unless the Certificate was issued in compliance with this Appendix F. > > > > ---- > > Motion Ends > > ----- > > The review period for this ballot shall commence at 2200 UTC on Thursday, 4 > February 2015, and will close at 2200 UTC on Thursday, 11 February 2015. > Unless the motion is withdrawn during the review period, the voting period > will start immediately thereafter and will close at 2200 UTC on Monday, 18 > February 2015. Votes must be cast by posting an on-list reply to this > thread. > > A vote in favor of the motion must indicate a clear 'yes' in the response. A > vote against must indicate a clear 'no' in the response. A vote to abstain > must indicate a clear 'abstain' in the response. Unclear responses will not > be counted. The latest vote received from any representative of a voting > member before the close of the voting period will be counted. Voting members > are listed here: https://cabforum.org/members/ > > In order for the motion to be adopted, two thirds or more of the votes cast > by members in the CA category and greater than 50% of the votes cast by > members in the browser category must be in favor. Quorum is currently nine > (9) members? at least nine members must participate in the ballot, either by > voting in favor, voting against, or abstaining. > > > > > > > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public > From sleevi at google.com Mon Feb 16 00:49:52 2015 From: sleevi at google.com (Ryan Sleevi) Date: Sun, 15 Feb 2015 16:49:52 -0800 Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group In-Reply-To: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> References: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> Message-ID: Jeremy, To confirm, will this newly-formalized WG be operated consistent with Section 5.3 of our Bylaws? Specifically: "With the approval of the Chair, Working Groups may establish separate list-servs, wikis, and web pages for their communications, but all such separate list-servs must be managed in the same fashion as the Public Mail List." The existing EV WG does not operate according to the above, so I'm wanting to know how this newly formalized group will be handled if the motion succeeds. Cheers, From jeremy.rowley at digicert.com Mon Feb 16 01:09:18 2015 From: jeremy.rowley at digicert.com (Jeremy Rowley) Date: Mon, 16 Feb 2015 01:09:18 +0000 Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group In-Reply-To: References: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> Message-ID: <4560f1b512db41a98c4ddb3198adad2d@EX2.corp.digicert.com> Yes - that is the plan. -----Original Message----- From: Ryan Sleevi [mailto:sleevi at google.com] Sent: Sunday, February 15, 2015 5:50 PM To: Jeremy Rowley Cc: CABFPub Subject: Re: [cabfpub] Ballot 143 - Formalization of Validation Working Group Jeremy, To confirm, will this newly-formalized WG be operated consistent with Section 5.3 of our Bylaws? Specifically: "With the approval of the Chair, Working Groups may establish separate list-servs, wikis, and web pages for their communications, but all such separate list-servs must be managed in the same fashion as the Public Mail List." The existing EV WG does not operate according to the above, so I'm wanting to know how this newly formalized group will be handled if the motion succeeds. Cheers, From sleevi at google.com Mon Feb 16 01:10:33 2015 From: sleevi at google.com (Ryan Sleevi) Date: Sun, 15 Feb 2015 17:10:33 -0800 Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group In-Reply-To: <4560f1b512db41a98c4ddb3198adad2d@EX2.corp.digicert.com> References: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> <4560f1b512db41a98c4ddb3198adad2d@EX2.corp.digicert.com> Message-ID: In that case, Google votes YES. On Sun, Feb 15, 2015 at 5:09 PM, Jeremy Rowley wrote: > Yes - that is the plan. > > -----Original Message----- > From: Ryan Sleevi [mailto:sleevi at google.com] > Sent: Sunday, February 15, 2015 5:50 PM > To: Jeremy Rowley > Cc: CABFPub > Subject: Re: [cabfpub] Ballot 143 - Formalization of Validation Working Group > > Jeremy, > > To confirm, will this newly-formalized WG be operated consistent with Section 5.3 of our Bylaws? Specifically: > > "With the approval of the Chair, Working Groups may establish separate list-servs, wikis, and web pages for their communications, but all such separate list-servs must be managed in the same fashion as the Public Mail List." > > The existing EV WG does not operate according to the above, so I'm wanting to know how this newly formalized group will be handled if the motion succeeds. > > Cheers, From i-barreira at izenpe.net Mon Feb 16 09:50:51 2015 From: i-barreira at izenpe.net (i-barreira at izenpe.net) Date: Mon, 16 Feb 2015 10:50:51 +0100 Subject: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc In-Reply-To: A References: <763539E260C37C46A0D6B340B5434C3B0ACD81A9@AEX06.ejsarea.net> A <763539E260C37C46A0D6B340B5434C3B0ADAE0EB@AEX06.ejsarea.net> A Message-ID: <763539E260C37C46A0D6B340B5434C3B0ADAE39F@AEX06.ejsarea.net> Jody, The auditor can be certified, can have a CISA, ISO27001 lead auditor, CISSP, etc. but does not entitled him to perform an ETSI audit. Of course is good to have, but is the auditing body that is allowed to perform an ETSI audit. And in their internal reqs they request their auditors to have those certifications or others. That has to be defined by the National Accreditation Body on the requirements to fulfill by the auditing body, in this case AuditCo. If AuditCo meets the requirements, then it can be incorporated in the list of its NAB and therefore perform ETSI audits if ETSI is one of the admitted ones (otherwise you can?t be on the list, of course). Once AuditCo is accredited in its NAB according to whatever national scheme able to performing ETSI audits, then you can hire them even if you?re not, as a CA, belonging to that country. Again, if we take Izenpe as a CA that wants to have an ETSI accredited audit (of course I can have ETSI audit but not accredited) then I have to look for Auditing bodies accredited in their countries (in Spain we don?t have), then I found that in Germany, TUV IT is accredited in its NAB according to the ISO standards requested and able to perform ETSI audits. And yes, it?s not easy, not for me as a CA and not for you as a RP. As said, we?re working on improving the language (the requisites are not so easy as it depends on every country). Hopefully I can provide some inputs for the F2F I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. De: Jody Cloutier [mailto:jodycl at microsoft.com] Enviado el: viernes, 13 de febrero de 2015 21:28 Para: Barreira Iglesias, I?igo; public at cabforum.org Asunto: RE: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Thank you, Inigo, What seems to be happening is that organizations are applying the ETSI standard in cases in which either there is no National Standards Body, or where the national standards body does not certify the company. Building on the scenario below, Audit Co is not recognized by ISRAC, but Auditor Jones has a CISP certification, which I've already confirmed with ETSI is not sufficient. I think what would help here is to make the requirement much more specific: A Qualified Auditor is limited to an auditor that is employed by a company that is certified by a National Authority listed in either the Members or Associate Members link. This, much simplified language, seems to be what you are saying below, but the current language is such that Audit Co can argue that it can issue an ETSI audit because it's company is certified by another national authority that's not listed on the ETSI webpages anywhere. Jody From: i-barreira at izenpe.net [mailto:i-barreira at izenpe.net] Sent: Friday, February 13, 2015 12:16 AM To: Jody Cloutier; public at cabforum.org Subject: RE: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Dear Jody, I understand your concern because it?s not easy for you to manage all possible combinations regarding ETSI audits in different countries so will try to clarify your example. First of all, no AuditCo has to be member of ETSI, AuditCo can perform ETSI accredited audits without being member of ETSI, they only need to be accredited in their country as stated in Annex E requirements. So, For example, ? Company A is a commercial CA that operates in Israel ? Auditor Jones works for AuditCo, which is based in Israel ? AuditCo is certified by some governmental agency as a qualified auditor IB? AuditCo has to be accredited under its National Accreditation Body according to ISO 17021. In the case of Israel, to follow the example, in the associated members tab of the EA, you can find the Israeli accreditation body, called ISRAC. Then AuditCo should be listed there and meeting the requirements to perform ETSI audits according to the national scheme indicated by ISRAC ? AuditCo is not an ETSI Member or Associate Member IB ? this is not necessary. No need to be an ETSI member to perform ETSI audits ? Auditor Jones audits Company A using the ETSI 102042 standard, and Company A sends the auditor's attestation letter to Microsoft as evidence that Company A complied with the Program's requirements. IB? this is perfectly valid if AuditCo is listed in ISRAC and is allowed to perform ETSI audits. Of course Auditor Jones has to be also accredited to perform these kind of audits, has to be "qualified", so it?s not only the company but also the auditor, but that?s an internal task of the AuditCo. Regarding of being member of not, this is voluntary, they can join ETSI or not and don?t think that solve the problem because joining ETSI does not mean that you?re "qualified" or "accredited" to perform an ETSI audit, it?s just indicate that you belong to a club for example. And of course, if company A needs an auditing company accredited in Israel and there?s none, they can look for in other countries. For example, in Spain there?s no accredited auditing bodies to perform ETSI audits listed in our NAB, called ENAC, so, we, Izenpe, had to look for another option. So, we contacted for the first 6 years with KPMG in the Netherlands, and the last 3, with TUV IT in Germany. And Izenpe has an accredited ETSI audits according to the, right now, German national scheme and we?re listed in Germany. We?ll debate this within ETSI ESI trying to find an easier solution. Regards I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. De: Jody Cloutier [mailto:jodycl at microsoft.com] Enviado el: mi?rcoles, 11 de febrero de 2015 0:32 Para: Barreira Iglesias, I?igo; public at cabforum.org Asunto: RE: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Thank you, Inigo. I think the problem is that, under ETSI, it's difficult to discern what an "equivalent national scheme" is. This sets up the scenario in which an auditor is employed by an organization that is recognized somehow by the government, but is not affiliated with an ETSI member organization (http://www.european-accreditation.org/home ). Microsoft does not know whether or not this auditor is qualified or not. For example, ? Company A is a commercial CA that operates in Israel ? Auditor Jones works for AuditCo, which is based in Israel ? AuditCo is certified by some governmental agency as a qualified auditor ? AuditCo is not an ETSI Member or Associate Member ? Auditor Jones audits Company A using the ETSI 102042 standard, and Company A sends the auditor's attestation letter to Microsoft as evidence that Company A complied with the Program's requirements. In this scenario, how does Microsoft know that Auditor Jones conducted a proper audit without expending significant resources to determine whether and according to what standard AuditCo and Auditor Jones was certified? Microsoft believes that it would be simpler if the requirements were that the Auditor must work for a company that is affiliated with an ETSI-approved member organization. If Company A needs an auditor and there is no qualified auditor in Israel, the company can use an auditor from a member organization via the cross-border conformity rules. Unless I am fundamentally misunderstanding the rules, the above is something that Microsoft is presently struggling with, and we'd like to try to make the rules easier to understand for potential partners and ourselves. Jody Cloutier Senior Security Program Manager Microsoft Trusted Root Certificate Program jody.cloutier at microsoft.com 425.443.8922 Operating Systems Group Global Risk and Compliance From: i-barreira at izenpe.net [mailto:i-barreira at izenpe.net] Sent: Tuesday, February 10, 2015 3:09 AM To: Jody Cloutier; public at cabforum.org Subject: RE: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Hi Jody, Regarding your comment on ETSI audits, I have to say that the ETSI audits shall be performed by accredited auditors as mentioned in Annex E of the current ETSI TS 102 042. ETSI audits performed by not accredited auditors shall be considered invalid. Microsoft is accepting ETSI audits since the very beginning in its root program requirements indicating this requirement. ETSI is providing a list of accredited auditors as mere information because has to be maintained by every NAB (National Accreditation Body). It?s true that this has to be improved regarding the new regulation 910/2014 and the new ENs and will take some time, but at the moment, it?s clearly stated that the audits shall be performed by accredited auditors. Don?t hesitate in contacting me for any additional information or help. Sometimes I?ve received some emails from Tom or Kelvin asking for the qualification of some audits, so, as say, you can contact me regarding this issue. Regards I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. De: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] En nombre de Jody Cloutier Enviado el: lunes, 09 de febrero de 2015 18:55 Para: CABFPub (public at cabforum.org) Asunto: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Microsoft comments on Section 17. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 19121 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 1181 bytes Desc: image002.png URL: From gerv at mozilla.org Mon Feb 16 11:02:35 2015 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 16 Feb 2015 11:02:35 +0000 Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group In-Reply-To: References: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> <4560f1b512db41a98c4ddb3198adad2d@EX2.corp.digicert.com> Message-ID: <54E1CE4B.8030800@mozilla.org> On 16/02/15 01:10, Ryan Sleevi wrote: > In that case, Google votes YES. Mozilla votes YES. Gerv From gerv at mozilla.org Mon Feb 16 11:02:56 2015 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 16 Feb 2015 11:02:56 +0000 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names In-Reply-To: References: Message-ID: <54E1CE60.9020304@mozilla.org> Mozilla votes YES. Gerv From Peter.Miskovic at disig.sk Mon Feb 16 16:32:27 2015 From: Peter.Miskovic at disig.sk (Miskovic Peter) Date: Mon, 16 Feb 2015 16:32:27 +0000 Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group In-Reply-To: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> References: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> Message-ID: <3bb806d9da2b4517bc1e0e0726d3cce2@DISIGEX.disig.local> Ballot 143 - Formalization of Validation Working Group: Disig votes "YES". Regards, Peter Miskovic From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Wednesday, February 04, 2015 10:05 PM To: CABFPub Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group Ballot 143 - Formalization of validation working group ---- Reason ---- In order to address validation issues and inconsistencies in both the SSL Baseline Requirements and the EV Guidelines, the CAB Forum has held an informal working group previously referred to as the Extended Validation Working Group now known as the Validation Working Group, would like to modify its scope to include validation in the Baseline Requirements as well as the EV Guidelines. Jeremy Rowley of DigiCert made the following motion, which was endorsed by Rich Smith of Comodo and Kirk Hall of TrendMicro ---- Motion begins ---- The CA-Browser Forum formally establishes the Validation Working Group as an official working group of the CAB Forum, replacing the previous informal EV working group. The scope of this working group is to address issues arising under adopted CAB Forum standards related to the validation of certificate information and the inclusion of information in certificates. Scope: The Validation Working Group will consider all matters relating to the validation and inclusion of information in certificates under adopted CAB Forum guidelines. Deliverables: The Working Group shall produce one or more documents offering options to the Forum for validation within the scope defined above. ---- Motion Ends ---- The review period for this ballot shall commence at 2200 UTC on 5 Feb 2015, and will close at 2200 UTC on 11 Feb 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on 18 Feb 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Peter.Miskovic at disig.sk Mon Feb 16 16:34:12 2015 From: Peter.Miskovic at disig.sk (Miskovic Peter) Date: Mon, 16 Feb 2015 16:34:12 +0000 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names In-Reply-To: References: Message-ID: <593c466c7fc34b4da114746b576d4396@DISIGEX.disig.local> Ballot 144 - Validation rules for .onion names: Disig abstains. Regards, Peter Miskovic From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Tuesday, February 10, 2015 7:39 PM To: public at cabforum.org Subject: [cabfpub] Ballot 144 - Validation rules for .onion names Here's the ballot with the two typos fixed: Applicants want a CA-signed .onion address for several reasons, including: - Powerful web platform features are restricted to secure origins, which are currently not available to onion names (in part, because of the lack of IANA registration). Permitting EV certs for onion names will help provide a secure origin for the service, moving onion towards use of powerful web platform features. - Currently, access to .onion names over https from a standard browser results in the standard existing 'Invalid Certificate' warning. Training users to click through security warnings lowers the value of these warnings and will cause users to miss important security information. Removing these warnings for the user, through use of a digital certificate, will help users recognize and avoid real MITM attacks. - The public needs attribution of ownership of the .onion address to differentiate onion services, including potential phishing services. Because onion names are not easily recognizable strings, providing the public with additional information about the operator has significant security improvements, especially in regions where use of the incorrect name could have lethal consequences. The following motion has been proposed by Jeremy Rowley of DigiCert and endorsed by Ryan Sleevi of Google and Wayne Thayer of GoDaddy. --------------------- Motion Starts --------------------- 1) Amend Section 9.2.1 of the Baseline Requirements v. 1.2.3 as follows: 9.2.1 Subject Alternative Name Extension Certificate Field: extensions:subjectAltName Required/Optional: Required Contents: This 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. The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate. Wildcard FQDNs are permitted. As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name, the CA SHALL notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016. Also as of the Effective Date, the CA SHALL NOT issue a certificate with an Expiry Date later than 1 November 2015 with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name. Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Name. Effective May 1, 2015, each CA SHALL revoke all unexpired Certificates with an Internal Name using onion as the right-most label in an entry in the subjectAltName Extension or commonName field unless such Certificate was issued in accordance with Appendix F of the EV Guidelines. 2) Amend Section 9.2.2 and 11.7.1 of the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2 as follows: 9.2.2. Subject Alternative Name Extension Certificate field: subjectAltName:dNSName Required/Optional: Required Contents: This extension MUST contain one or more host Domain Name(s) owned or controlled by the Subject and to be associated with the Subject's server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). Wildcard certificates are not allowed for EV Certificates except as permitted under Appendix F. 11.7 Verification of Applicant's Domain Name 11.7.1. Verification Requirements (1) For each Fully-Qualified Domain Name listed in a Certificate, other than a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant (or the Applicant's Parent Company, Subsidiary Company, or Affiliate, collectively referred to as "Applicant" for the purposes of this section) either is the Domain Name Registrant or has control over the FQDN using a procedure specified in Section 11.1.1 of the Baseline Requirements, except that a CA MAY NOT verify a domain using the procedure described 11.1.1(7). For a Certificate issued to a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant's control over the .onion Domain Name in accordance with Appendix F. (2) Mixed Character Set Domain Names: EV Certificates MAY include Domain Names containing mixed character sets only in compliance with the rules set forth by the domain registrar. The CA MUST visually compare any Domain Names with mixed character sets with known high risk domains. If a similarity is found, then the EV Certificate Request MUST be flagged as High Risk. The CA must perform reasonably appropriate additional authentication and verification to be certain beyond reasonable doubt that the Applicant and the target in question are the same organization. 3) Add a new Appendix F to the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2: Appendix F - Issuance of Certificates for .onion Domain Names A CA may issue an EV Certificate with .onion in the right-most label of the Domain Name provided that issuance complies with the requirements set forth in this Appendix: 1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) The CAB Forum has created an extension of the TBSCertificate for use in conveying hashes of keys related to .onion addresses. The Tor Service Descriptor Hash extension has the following format: cabf-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 } TorServiceDescriptorSyntax ::= SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash TorServiceDescriptorHash:: = SEQUENCE { onionURI UTF8String algorithm AlgorithmIdentifier subjectPublicKeyHash BIT STRING } Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 6234) performed over the DER-encoding of an ASN.1 SubjectPublicKey of the .onion service and SubjectPublicKeyHash is the hash output. 2. The CA MUST verify the Applicant's control over the .onion Domain Name using one of the following: a. The CA MAY verify the Applicant's control over the .onion service by posting a specific value at a well-known URL under RFC5785. b. The CA MAY verify the Applicant's control over the .onion service by having the Applicant provide a Certificate Request signed using the .onion public key if the Attributes section of the certificationRequestInfo contains: (i) A caSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy, 2) is generated by the CA, and 3) delivered to the Applicant through a Verified Method of Communication and (ii) An applicantSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy and 2) is generated by the Applicant. The signing nonce attributes have the following format: caSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-caSigningNonce } } cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } applicantSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-applicantSigningNonce } } cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 } 4. Each Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name MUST conform to the requirements of these Guidelines, including the content requirements in Section 9 and Appendix B of the Baseline Requirements, except that the CA MAY include a wildcard character in the Subject Alternative Name Extension and Subject Common Name Field as the left-most character in the .onion Domain Name provided inclusion of the wildcard character complies with Section 11.1.3 of the Baseline Requirements. 5. CAs MUST NOT issue a Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name with a validity period longer than 15 months. Despite Section 9.2.1 of the Baseline Requirements deprecating the use of Internal Names, a CA MAY issue a Certificate containing an .onion name with an expiration date later than 1 November 2015 after (and only if) .onion is officially recognized by the IESG as a reserved TLD. 6. On or before May 1, 2015, each CA MUST revoke all Certificates issued with the Subject Alternative Name extension or Common Name field that includes a Domain Name where .onion is in the right-most label of the Domain Name unless the Certificate was issued in compliance with this Appendix F. ---- Motion Ends ----- The review period for this ballot shall commence at 2200 UTC on Thursday, 4 February 2015, and will close at 2200 UTC on Thursday, 11 February 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on Monday, 18 February 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.wilson at digicert.com Mon Feb 16 16:56:37 2015 From: ben.wilson at digicert.com (Ben Wilson) Date: Mon, 16 Feb 2015 16:56:37 +0000 Subject: [cabfpub] Ballot 143 In-Reply-To: <54DE685D.2000500@startcom.org> References: <68a8241d150c4bc6bd624e08988e44fa@EX2.corp.digicert.com> <54DE685D.2000500@startcom.org> Message-ID: Eddy, I think that because the ballot on the validation working group was going to move forward faster than the one on operational existence, Jeremy inadvertently swapped ballot numbers 143 and 145. Let the record so reflect the currently used numbering. Ben From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Eddy Nigg Sent: Friday, February 13, 2015 2:11 PM To: CABFPub Subject: [cabfpub] Ballot 143 There appears to be a mistake with ballot number 143 which was previously assigned to "Remove the operational existence requirement for Government Entities" and later "Formalization of validation working group". Jeremy I believe both were initiated by you? -- Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. XMPP: startcom at startcom.org Blog: Join the Revolution! Twitter: Follow Me -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4954 bytes Desc: not available URL: From eddy_nigg at startcom.org Mon Feb 16 16:58:29 2015 From: eddy_nigg at startcom.org (Eddy Nigg) Date: Mon, 16 Feb 2015 18:58:29 +0200 Subject: [cabfpub] Ballot 143 In-Reply-To: References: <68a8241d150c4bc6bd624e08988e44fa@EX2.corp.digicert.com> <54DE685D.2000500@startcom.org> Message-ID: <54E221B5.4050607@startcom.org> On 02/16/2015 06:56 PM, Ben Wilson wrote: > > Eddy, > > I think that because the ballot on the validation working group was > going to move forward faster than the one on operational existence, > Jeremy inadvertently swapped ballot numbers 143 and 145. Let the > record so reflect the currently used numbering. > OK - so /Remove the operational existence requirement for Government Entities/ will become 145 now. -- Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. XMPP: startcom at startcom.org Blog: Join the Revolution! Twitter: Follow Me -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4313 bytes Desc: S/MIME Cryptographic Signature URL: From ben.wilson at digicert.com Mon Feb 16 16:59:30 2015 From: ben.wilson at digicert.com (Ben Wilson) Date: Mon, 16 Feb 2015 16:59:30 +0000 Subject: [cabfpub] UK's Companies House Liable for Misinformation Message-ID: FYI ? FWIW from Tom Smedinghoff From: Federated ID Management Task Force [mailto:BL-FIDM at MAIL.AMERICANBAR.ORG] On Behalf Of Smedinghoff, Tom Sent: Monday, February 16, 2015 8:49 AM To: BL-FIDM at MAIL.AMERICANBAR.ORG Subject: [ABA-IDM-TASK-FORCE] Liability of IdP? With respect to the issue of identity system participant liability, and the discussion regarding legislative approaches to the issue, a list participant alerted me to a recent UK decision that might be of interest. See Companies House liable for company's collapse and Government in ?9 million payout after single letter blunder causes business to collapse . In that case, Companies House (the UK government's official registrar of companies, and an executive agency of the UK Department of Business, Innovation and Skills) had provided (apparently negligently) false information to credit reference agencies indicating that a business was in liquidation. The result was that all of its suppliers canceled their orders within three weeks, and the 100-year old company was forced to shut down. The UK High Court held Companies House liable for the resulting damages, finding that it owed a duty of care to the business, and that there was a special relationship with the business because ?it is foreseeable that if a company is wrongly said on the register to be in liquidation, it will suffer serious harm.? Since the case involves identity attribute-like information, it appears to raise numerous issues of relevance for the current discussion, including the liability of identity providers and attribute providers, the nature of the duty they might owe to persons and businesses they identify, and the potential liability of a government agency. It will be interesting to see whether similar reasoning is applied to identity credentials asserting incorrect information. Tom Thomas J. Smedinghoff Locke Lord LLP 225 W. Wacker Drive, Suite 3000 Chicago, Illinois 60606 312-201-2021 Direct 312-545-1333 Mobile Tom.Smedinghoff at lockelord.com www.lockelord.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4954 bytes Desc: not available URL: From douglas.beattie at globalsign.com Mon Feb 16 17:41:28 2015 From: douglas.beattie at globalsign.com (Doug Beattie) Date: Mon, 16 Feb 2015 17:41:28 +0000 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names In-Reply-To: <593c466c7fc34b4da114746b576d4396@DISIGEX.disig.local> References: <593c466c7fc34b4da114746b576d4396@DISIGEX.disig.local> Message-ID: GlobalSign abstains. Doug From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Tuesday, February 10, 2015 7:39 PM To: public at cabforum.org Subject: [cabfpub] Ballot 144 - Validation rules for .onion names Here's the ballot with the two typos fixed: Applicants want a CA-signed .onion address for several reasons, including: - Powerful web platform features are restricted to secure origins, which are currently not available to onion names (in part, because of the lack of IANA registration). Permitting EV certs for onion names will help provide a secure origin for the service, moving onion towards use of powerful web platform features. - Currently, access to .onion names over https from a standard browser results in the standard existing 'Invalid Certificate' warning. Training users to click through security warnings lowers the value of these warnings and will cause users to miss important security information. Removing these warnings for the user, through use of a digital certificate, will help users recognize and avoid real MITM attacks. - The public needs attribution of ownership of the .onion address to differentiate onion services, including potential phishing services. Because onion names are not easily recognizable strings, providing the public with additional information about the operator has significant security improvements, especially in regions where use of the incorrect name could have lethal consequences. The following motion has been proposed by Jeremy Rowley of DigiCert and endorsed by Ryan Sleevi of Google and Wayne Thayer of GoDaddy. --------------------- Motion Starts --------------------- 1) Amend Section 9.2.1 of the Baseline Requirements v. 1.2.3 as follows: 9.2.1 Subject Alternative Name Extension Certificate Field: extensions:subjectAltName Required/Optional: Required Contents: This 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. The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate. Wildcard FQDNs are permitted. As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name, the CA SHALL notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016. Also as of the Effective Date, the CA SHALL NOT issue a certificate with an Expiry Date later than 1 November 2015 with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name. Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Name. Effective May 1, 2015, each CA SHALL revoke all unexpired Certificates with an Internal Name using onion as the right-most label in an entry in the subjectAltName Extension or commonName field unless such Certificate was issued in accordance with Appendix F of the EV Guidelines. 2) Amend Section 9.2.2 and 11.7.1 of the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2 as follows: 9.2.2. Subject Alternative Name Extension Certificate field: subjectAltName:dNSName Required/Optional: Required Contents: This extension MUST contain one or more host Domain Name(s) owned or controlled by the Subject and to be associated with the Subject's server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). Wildcard certificates are not allowed for EV Certificates except as permitted under Appendix F. 11.7 Verification of Applicant's Domain Name 11.7.1. Verification Requirements (1) For each Fully-Qualified Domain Name listed in a Certificate, other than a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant (or the Applicant's Parent Company, Subsidiary Company, or Affiliate, collectively referred to as "Applicant" for the purposes of this section) either is the Domain Name Registrant or has control over the FQDN using a procedure specified in Section 11.1.1 of the Baseline Requirements, except that a CA MAY NOT verify a domain using the procedure described 11.1.1(7). For a Certificate issued to a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant's control over the .onion Domain Name in accordance with Appendix F. (2) Mixed Character Set Domain Names: EV Certificates MAY include Domain Names containing mixed character sets only in compliance with the rules set forth by the domain registrar. The CA MUST visually compare any Domain Names with mixed character sets with known high risk domains. If a similarity is found, then the EV Certificate Request MUST be flagged as High Risk. The CA must perform reasonably appropriate additional authentication and verification to be certain beyond reasonable doubt that the Applicant and the target in question are the same organization. 3) Add a new Appendix F to the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2: Appendix F - Issuance of Certificates for .onion Domain Names A CA may issue an EV Certificate with .onion in the right-most label of the Domain Name provided that issuance complies with the requirements set forth in this Appendix: 1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) The CAB Forum has created an extension of the TBSCertificate for use in conveying hashes of keys related to .onion addresses. The Tor Service Descriptor Hash extension has the following format: cabf-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 } TorServiceDescriptorSyntax ::= SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash TorServiceDescriptorHash:: = SEQUENCE { onionURI UTF8String algorithm AlgorithmIdentifier subjectPublicKeyHash BIT STRING } Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 6234) performed over the DER-encoding of an ASN.1 SubjectPublicKey of the .onion service and SubjectPublicKeyHash is the hash output. 2. The CA MUST verify the Applicant's control over the .onion Domain Name using one of the following: a. The CA MAY verify the Applicant's control over the .onion service by posting a specific value at a well-known URL under RFC5785. b. The CA MAY verify the Applicant's control over the .onion service by having the Applicant provide a Certificate Request signed using the .onion public key if the Attributes section of the certificationRequestInfo contains: (i) A caSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy, 2) is generated by the CA, and 3) delivered to the Applicant through a Verified Method of Communication and (ii) An applicantSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy and 2) is generated by the Applicant. The signing nonce attributes have the following format: caSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-caSigningNonce } } cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } applicantSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-applicantSigningNonce } } cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 } 4. Each Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name MUST conform to the requirements of these Guidelines, including the content requirements in Section 9 and Appendix B of the Baseline Requirements, except that the CA MAY include a wildcard character in the Subject Alternative Name Extension and Subject Common Name Field as the left-most character in the .onion Domain Name provided inclusion of the wildcard character complies with Section 11.1.3 of the Baseline Requirements. 5. CAs MUST NOT issue a Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name with a validity period longer than 15 months. Despite Section 9.2.1 of the Baseline Requirements deprecating the use of Internal Names, a CA MAY issue a Certificate containing an .onion name with an expiration date later than 1 November 2015 after (and only if) .onion is officially recognized by the IESG as a reserved TLD. 6. On or before May 1, 2015, each CA MUST revoke all Certificates issued with the Subject Alternative Name extension or Common Name field that includes a Domain Name where .onion is in the right-most label of the Domain Name unless the Certificate was issued in compliance with this Appendix F. ---- Motion Ends ----- The review period for this ballot shall commence at 2200 UTC on Thursday, 4 February 2015, and will close at 2200 UTC on Thursday, 11 February 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on Monday, 18 February 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: From douglas.beattie at globalsign.com Mon Feb 16 18:31:46 2015 From: douglas.beattie at globalsign.com (Doug Beattie) Date: Mon, 16 Feb 2015 18:31:46 +0000 Subject: [cabfpub] [cabfquest] Domain Validation Revision In-Reply-To: References: <54DE3BBE.9000203@eff.org> Message-ID: This suggestion for item 8 works for GlobalSign so you can replace our recommendation with the one below. Doug From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ben Wilson Sent: Friday, February 13, 2015 3:39 PM To: CABFPub Subject: Re: [cabfpub] [cabfquest] Domain Validation Revision Forwarding from questions list. From: questions-bounces at cabforum.org [mailto:questions-bounces at cabforum.org] On Behalf Of Jacob Hoffman-Andrews Sent: Friday, February 13, 2015 11:01 AM To: questions at cabforum.org Subject: Re: [cabfquest] [cabfpub] Domain Validation Revision Following up from a thread on cabfpub: On 02/12/2015 07:08 PM, Ryan Sleevi wrote: 8 concerns me for a couple reasons, even though it's moving in the right direction. - You require HTTPS, but that seems overkill, when you only need to perform a TLS handshake. That is, consider a mail server configured for SMTP-S - it seems that would be a viable configuration Agreed. As a concrete example, the ACME spec under discussion at IETF proposes a challenge type called "Domain Validation with Server Name Indication," or DVSNI for short: http://www.ietf.org/id/draft-barnes-acme-01.txt. We believe that DVSNI allows us to offer a higher level of assurance than item (6), "making an agreed-upon change to information found on an online Web page," since some sites allow arbitrary file upload, either by intent or by accident. We're planning to use it for the Let's Encrypt CA for that reason, so we'd like to make sure that item (8) allows for DVSNI. For example, here is a version of item (8) that we think would work: Having the Applicant demonstrate practical control over the FQDN by providing a TLS service on a host found in DNS for the FQDN. The CA SHALL initiate a TLS connection with that host and verify that the response contains unique, unguessable information proposed by the CA, in a well-specified format. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirk_hall at trendmicro.com Mon Feb 16 21:57:33 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Mon, 16 Feb 2015 21:57:33 +0000 Subject: [cabfpub] Domain Validation Revision In-Reply-To: <54DDCC5D.50305@mozilla.org> References: <54DDCC5D.50305@mozilla.org> Message-ID: Gerv -- we always allowed attorney letters in the past. For DV/OV, it was an "any other method" means of domain confirmation. For EV, it was explicitly allowed under the EVGL (and there are still references to it in the template Attorney Letter attached to the EVGL), but by mistake we deleted the reference when we changed EVGL 11.7 simply to a cross reference to BR 11.1.1 ? we accidentally dropped the old reference to using attorney-accountant letters for EV domain confirmation (I can give you a version number reference to the old EVGL if you want to confirm). So the proposal just corrects that mistake and adds back in a method we have always permitted for domain confirmation. This is useful when the Domain Name Registrant has licensed the domain to the Customer, or when the parent-sub relationship is not reported correctly, etc. -----Original Message----- From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Gervase Markham Sent: Friday, February 13, 2015 2:05 AM To: Jeremy Rowley; CABFPub (public at cabforum.org) Subject: Re: [cabfpub] Domain Validation Revision > 3) permit > attorney/accountants to draft the domain authorization document. If I understand this correctly, then I am opposed. I don't see why a lawyer or an accountant is an appropriate authority on the subject of who controls a domain. Domain control can only be properly validated either by the registrar who issued the domain, the registrant listed in WHOIS, or some practical demonstration of control. No-one else's opinion matters. Gerv _______________________________________________ Public mailing list Public at cabforum.org https://cabforum.org/mailman/listinfo/public 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
-------------- next part -------------- An HTML attachment was scrubbed... URL: From enric.castillo at anf.es Mon Feb 16 18:40:23 2015 From: enric.castillo at anf.es (Enric Castillo) Date: Mon, 16 Feb 2015 19:40:23 +0100 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names In-Reply-To: References: Message-ID: <54E23997.5080604@anf.es> ANF AC abstains ballot 144. ANF Autoridad de Certificaci?n *Enric Castillo* Director T?cnico +34 626818285 Gran Via de Les Corts Catalanes 996, Barcelona +593 0 998554992 12 de Octubre y Cordero, World Trade Center, Torre A, 1102, Quito ANF Autoridad de Certificaci?n www.anf.es *Aviso* Este mensaje se dirige exclusivamente a su destinatario y puede contener informaci?n privilegiada o confidencial y/o datos de car?cter personal, cuya difusi?n est? regulada por la Ley Org?nica de Protecci?n de Datos y la Ley de Servicios de la Sociedad de la Informaci?n. Si usted no es el destinatario indicado (o el responsable de la entrega al mismo), no debe copiar o entregar este mensaje a terceros bajo ning?n concepto. Si ha recibido este mensaje por error o lo ha conseguido por otros medios, le rogamos que nos lo comunique inmediatamente por esta misma v?a y proceda a su eliminaci?n irreversible. Las opiniones, conclusiones y dem?s informaciones incluidas en este mensaje que no est?n relacionadas con asuntos profesionales de ANF Autoridad de Certificaci?n no est?n respaldadas por la empresa. El 10/02/2015 a las 19:38, Jeremy Rowley escribi?: > > *Here?s the ballot with the two typos fixed:* > > Applicants want a CA-signed .onion address for several reasons, including: > > - Powerful web platform features are restricted to secure origins, > which are currently not available to onion names (in part, because of > the lack of IANA registration). Permitting EV certs for onion names > will help provide a secure origin for the service, moving onion > towards use of powerful web platform features. > > - Currently, access to .onion names over https from a standard browser > results in the standard existing 'Invalid Certificate' warning. > Training users to click through security warnings lowers the value of > these warnings and will cause users to miss important security > information. Removing these warnings for the user, through use of a > digital certificate, will help users recognize and avoid real MITM > attacks. > > - The public needs attribution of ownership of the .onion address to > differentiate onion services, including potential phishing services. > Because onion names are not easily recognizable strings, providing the > public with additional information about the operator has significant > security improvements, especially in regions where use of the > incorrect name could have lethal consequences. > > The following motion has been proposed by Jeremy Rowley of DigiCert > and endorsed by Ryan Sleevi of Google and Wayne Thayer of GoDaddy. > > --------------------- > > Motion Starts > > --------------------- > > 1) Amend Section 9.2.1 of the Baseline Requirements v. 1.2.3 as follows: > > 9.2.1 Subject Alternative Name Extension > > Certificate Field: extensions:subjectAltName > > Required/Optional: Required > > Contents: This 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. The CA MUST > confirm that the Applicant controls the Fully-Qualified Domain Name or > IP address or has been granted the right to use it by the Domain Name > Registrant or IP address assignee, as appropriate. > > Wildcard FQDNs are permitted. As of the Effective Date of these > Requirements, prior to the issuance of a Certificate with a > subjectAlternativeName extension or Subject commonName field > containing a Reserved IP Address or Internal Name, the CA SHALL notify > the Applicant that the use of such Certificates has been deprecated by > the CA / Browser Forum and that the practice will be eliminated by > October 2016. Also as of the Effective Date, the CA SHALL NOT issue a > certificate with an Expiry Date later than 1 November 2015 with a > subjectAlternativeName extension or Subject commonName field > containing a Reserved IP Address or Internal Name. Effective 1 October > 2016, CAs SHALL revoke all unexpired Certificates whose > subjectAlternativeName extension or Subject commonName field contains > a Reserved IP Address or Internal Name. _Effective May 1, 2015, each > CA SHALL revoke all unexpired Certificates with an Internal Name using > onion as the right-most label in an entry in the subjectAltName > Extension or commonName field unless such Certificate was issued in > accordance with Appendix F of the EV Guidelines._ > > 2) Amend Section 9.2.2 and 11.7.1 of the Guidelines for the Issuance > and Management of Extended Validation Certificates v1.5.2 as follows: > > 9.2.2. Subject Alternative Name Extension Certificate field: > subjectAltName:dNSName > > Required/Optional: Required > > Contents: This extension MUST contain one or more host Domain Name(s) > owned or controlled by the Subject and to be associated with the > Subject?s server. Such server MAY be owned and operated by the Subject > or another entity (e.g., a hosting service). Wildcard certificates are > not allowed for EV Certificates_except as permitted under Appendix F_. > > 11.7 Verification of Applicant?s Domain Name > > 11.7.1. Verification Requirements > > (1) For each Fully-Qualified Domain Name listed in a Certificate, > other than a Domain Name with .onion in the right-most label of the > Domain Name, the CA SHALL confirm that, as of the date the Certificate > was issued, the Applicant (or the Applicant?s Parent Company, > Subsidiary Company, or Affiliate, collectively referred to as > ?Applicant? for the purposes of this section) either is the Domain > Name Registrant or has control over the FQDN using a procedure > specified in Section 11.1.1 of the Baseline Requirements, except that > a CA MAY NOT verify a domain using the procedure described 11.1.1(7). > _For a Certificate issued to a Domain Name with .onion in the > right-most label of the Domain Name, the CA SHALL confirm that, as of > the date the Certificate was issued, the Applicant?s control over the > .onion Domain Name in accordance with Appendix F._ > > (2) Mixed Character Set Domain Names: EV Certificates MAY include > Domain Names containing mixed character sets only in compliance with > the rules set forth by the domain registrar. The CA MUST visually > compare any Domain Names with mixed character sets with known high > risk domains. If a similarity is found, then the EV Certificate > Request MUST be flagged as High Risk. The CA must perform reasonably > appropriate additional authentication and verification to be certain > beyond reasonable doubt that the Applicant and the target in question > are the same organization. > > 3) Add a new Appendix F to the Guidelines for the Issuance and > Management of Extended Validation Certificates v1.5.2: > > Appendix F ? Issuance of Certificates for .onion Domain Names > > A CA may issue an EV Certificate with .onion in the right-most label > of the Domain Name provided that issuance complies with the > requirements set forth in this Appendix: > > 1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) > > The CAB Forum has created an extension of the TBSCertificate for use > in conveying hashes of keys related to .onion addresses. The Tor > Service Descriptor Hash extension has the following format: > > cabf-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 } > > TorServiceDescriptorSyntax ::= > > SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash > > TorServiceDescriptorHash:: = SEQUENCE { > > onionURI UTF8String > > algorithm AlgorithmIdentifier > > subjectPublicKeyHash BIT STRING } > > Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC > 6234) performed over the DER-encoding of an ASN.1 SubjectPublicKey of > the .onion service and SubjectPublicKeyHash is the hash output. > > 2. The CA MUST verify the Applicant?s control over the .onion Domain > Name using one of the following: > > a. The CA MAY verify the Applicant?s control over the .onion service > by posting a specific value at a well-known URL under RFC5785. > > b. The CA MAY verify the Applicant?s control over the .onion service > by having the Applicant provide a Certificate Request signed using the > .onion public key if the Attributes section of the > certificationRequestInfo contains: > > (i) A caSigningNonce attribute that 1) contains a single value with at > least 64-bits of entropy, 2) is generated by the CA, and 3) delivered > to the Applicant through a Verified Method of Communication and > > (ii) An applicantSigningNonce attribute that 1) contains a single > value with at least 64-bits of entropy and 2) is generated by the > Applicant. > > The signing nonce attributes have the following format: > > caSigningNonce ATTRIBUTE ::= { > > WITH SYNTAX OCTET STRING > > EQUALITY MATCHING RULE octetStringMatch > > SINGLE VALUE TRUE > > ID { cabf-caSigningNonce } > > } > > cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } > > applicantSigningNonce ATTRIBUTE ::= { > > WITH SYNTAX OCTET STRING > > EQUALITY MATCHING RULE octetStringMatch > > SINGLE VALUE TRUE > > ID { cabf-applicantSigningNonce } > > } > > cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 } > > 4. Each Certificate that includes a Domain Name where .onion is in the > right-most label of the Domain Name MUST conform to the requirements > of these Guidelines, including the content requirements in Section 9 > and Appendix B of the Baseline Requirements, except that the CA MAY > include a wildcard character in the Subject Alternative Name Extension > and Subject Common Name Field as the left-most character in the .onion > Domain Name provided inclusion of the wildcard character complies with > Section 11.1.3 of the Baseline Requirements. > > 5. CAs MUST NOT issue a Certificate that includes a Domain Name where > .onion is in the right-most label of the Domain Name with a validity > period longer than 15 months. Despite Section 9.2.1 of the Baseline > Requirements deprecating the use of Internal Names, a CA MAY issue a > Certificate containing an .onion name with an expiration date later > than 1 November 2015 after (and only if) .onion is officially > recognized by the IESG as a reserved TLD. > > 6. On or before May 1, 2015, each CA MUST revoke all Certificates > issued with the Subject Alternative Name extension or Common Name > field that includes a Domain Name where .onion is in the right-most > label of the Domain Name unless the Certificate was issued in > compliance with this Appendix F. > > ---- > > Motion Ends > > ----- > > The review period for this ballot shall commence at 2200 UTC on > Thursday, 4 February 2015, and will close at 2200 UTC on Thursday, 11 > February 2015. Unless the motion is withdrawn during the review > period, the voting period will start immediately thereafter and will > close at 2200 UTC on Monday, 18 February 2015. Votes must be cast by > posting an on-list reply to this thread. > > A vote in favor of the motion must indicate a clear 'yes' in the > response. A vote against must indicate a clear 'no' in the response. A > vote to abstain must indicate a clear 'abstain' in the response. > Unclear responses will not be counted. The latest vote received from > any representative of a voting member before the close of the voting > period will be counted. Voting members are listed here: > https://cabforum.org/members/ > > In order for the motion to be adopted, two thirds or more of the votes > cast by members in the CA category and greater than 50% of the votes > cast by members in the browser category must be in favor. Quorum is > currently nine (9) members? at least nine members must participate in > the ballot, either by voting in favor, voting against, or abstaining. > > > > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo-anf.png Type: image/png Size: 4746 bytes Desc: not available URL: From enric.castillo at anf.es Mon Feb 16 18:41:22 2015 From: enric.castillo at anf.es (Enric Castillo) Date: Mon, 16 Feb 2015 19:41:22 +0100 Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group In-Reply-To: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> References: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> Message-ID: <54E239D2.1090001@anf.es> ANF AC votes yes. ANF Autoridad de Certificaci?n *Enric Castillo* Director T?cnico +34 626818285 Gran Via de Les Corts Catalanes 996, Barcelona +593 0 998554992 12 de Octubre y Cordero, World Trade Center, Torre A, 1102, Quito ANF Autoridad de Certificaci?n www.anf.es *Aviso* Este mensaje se dirige exclusivamente a su destinatario y puede contener informaci?n privilegiada o confidencial y/o datos de car?cter personal, cuya difusi?n est? regulada por la Ley Org?nica de Protecci?n de Datos y la Ley de Servicios de la Sociedad de la Informaci?n. Si usted no es el destinatario indicado (o el responsable de la entrega al mismo), no debe copiar o entregar este mensaje a terceros bajo ning?n concepto. Si ha recibido este mensaje por error o lo ha conseguido por otros medios, le rogamos que nos lo comunique inmediatamente por esta misma v?a y proceda a su eliminaci?n irreversible. Las opiniones, conclusiones y dem?s informaciones incluidas en este mensaje que no est?n relacionadas con asuntos profesionales de ANF Autoridad de Certificaci?n no est?n respaldadas por la empresa. El 04/02/2015 a las 22:05, Jeremy Rowley escribi?: > > Ballot 143 - Formalization of validation working group > > ---- > > Reason > > ---- > > In order to address validation issues and inconsistencies in both the > SSL Baseline Requirements and the EV Guidelines, the CAB Forum has > held an informal working group previously referred to as the Extended > Validation Working Group now known as the Validation Working Group, > would like to modify its scope to include validation in the Baseline > Requirements as well as the EV Guidelines. > > Jeremy Rowley of DigiCert made the following motion, which was > endorsed by Rich Smith of Comodo and Kirk Hall of TrendMicro > > ---- > > Motion begins > > ---- > > The CA-Browser Forum formally establishes the Validation Working Group > as an official working group of the CAB Forum, replacing the previous > informal EV working group. The scope of this working group is to > address issues arising under adopted CAB Forum standards related to > the validation of certificate information and the inclusion of > information in certificates. > > Scope: The Validation Working Group will consider all matters relating > to the validation and inclusion of information in certificates under > adopted CAB Forum guidelines. > > Deliverables: The Working Group shall produce one or more documents > offering options to the Forum for validation within the scope defined > above. > > ---- > > Motion Ends > > ---- > > The review period for this ballot shall commence at 2200 UTC on 5 Feb > 2015, and will close at 2200 UTC on 11 Feb 2015. Unless the motion is > withdrawn during the review period, the voting period will start > immediately thereafter and will close at 2200 UTC on 18 Feb 2015. > Votes must be cast by posting an on-list reply to this thread. > > A vote in favor of the motion must indicate a clear 'yes' in the > response. A vote against must indicate a clear 'no' in the response. A > vote to abstain must indicate a clear 'abstain' in the response. > Unclear responses will not be counted. The latest vote received from > any representative of a voting member before the close of the voting > period will be counted. Voting members are listed here: > https://cabforum.org/members/ > > In order for the motion to be adopted, two thirds or more of the votes > cast by members in the CA category and greater than 50% of the votes > cast by members in the browser category must be in favor. Quorum is > currently nine (9) members? at least nine members must participate in > the ballot, either by voting in favor, voting against, or abstaining. > > > > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo-anf.png Type: image/png Size: 4746 bytes Desc: not available URL: From enric.castillo at anf.es Mon Feb 16 18:59:56 2015 From: enric.castillo at anf.es (Enric Castillo) Date: Mon, 16 Feb 2015 19:59:56 +0100 Subject: [cabfpub] IPv6 support In-Reply-To: <54DE8183.1060204@startcom.org> References: <14D026C7F297AD44AC82578DD818CDD038EEF0BA5B@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C01141460BD37468D1@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <14D026C7F297AD44AC82578DD818CDD038EEF0BFAD@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> <14D026C7F297AD44AC82578DD818CDD038EF1EA316@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> <54DE8183.1060204@startcom.org> Message-ID: <54E23E2C.70903@anf.es> We don't support IPv6 now for CRL and OCSP because the demand is so low by the moment. Talking with the infraestructure team, our changes are easy to implement and become fully compilance with IPv6. ANF Autoridad de Certificaci?n *Enric Castillo* Director T?cnico +34 626818285 Gran Via de Les Corts Catalanes 996, Barcelona +593 0 998554992 12 de Octubre y Cordero, World Trade Center, Torre A, 1102, Quito ANF Autoridad de Certificaci?n www.anf.es *Aviso* Este mensaje se dirige exclusivamente a su destinatario y puede contener informaci?n privilegiada o confidencial y/o datos de car?cter personal, cuya difusi?n est? regulada por la Ley Org?nica de Protecci?n de Datos y la Ley de Servicios de la Sociedad de la Informaci?n. Si usted no es el destinatario indicado (o el responsable de la entrega al mismo), no debe copiar o entregar este mensaje a terceros bajo ning?n concepto. Si ha recibido este mensaje por error o lo ha conseguido por otros medios, le rogamos que nos lo comunique inmediatamente por esta misma v?a y proceda a su eliminaci?n irreversible. Las opiniones, conclusiones y dem?s informaciones incluidas en este mensaje que no est?n relacionadas con asuntos profesionales de ANF Autoridad de Certificaci?n no est?n respaldadas por la empresa. El 13/02/2015 a las 23:58, Eddy Nigg escribi?: > > On 02/14/2015 12:33 AM, Dean Coclin wrote: >> You?ll probably realize after reading this that there isn?t much >> actionable material here as many members are ?scoping? or ?waiting >> for info? without any concrete response dates. We?ll keep this tally >> going and update as we get more info. >> >> Globalsign: Yes, can support >> >> Symantec: We don?t support this today. We?ve received very little >> demand for it from customers, but we?re in the process of scoping out >> the effort. >> >> Comodo:Yes, for CRL and OCSP >> >> TrendMicro:Yes >> GoDaddy: Waiting for info from network team >> >> Entrust:Yes for CRL and OCSP. >> >> Trustwave:We don?t support this today. Just started scoping the >> effort. Not many requests for this >> >> Digicert:We currently do not support it. Our connectivity providers >> support it, and it could be done with CRLs and OCSP, but we?d need to >> look for any gotchas before pulling the trigger. We?ve only had a >> couple of customers ask whether we support it. >> > > To add StartCom to the list, we could support it for almost > everything, but we have some historical CRL distribution points that > can't support IPv6 for now. It seems that OCSP would work, but CRLs > not 100%. > > Same as with Digicert, demand for IPv6 has been so low that we haven't > invested into it so far. > > -- > Regards > Signer: Eddy Nigg, COO/CTO > StartCom Ltd. > XMPP: startcom at startcom.org > Blog: Join the Revolution! > Twitter: Follow Me > > > > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo-anf.png Type: image/png Size: 4746 bytes Desc: not available URL: From realsky at cht.com.tw Tue Feb 17 10:02:09 2015 From: realsky at cht.com.tw (=?UTF-8?B?6Zmz56uL576k?=) Date: Tue, 17 Feb 2015 18:02:09 +0800 Subject: [cabfpub] Ballot 143 - Formalization of validation working group In-Reply-To: References: Message-ID: <00d701d04a98$cb5e6570$621b3050$@cht.com.tw> Chunghwa Telecom Co., Ltd. votes YES as Sincerely Yours, Li-Chun CHEN Engineer CISSP, CISA, CISM, PMP, Information & Communication Security Dept. Data Communication Business Group Chunghwa Telecom Co. Ltd. realsky at cht.com.tw +886-2-2344-4820#4025 From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of kirk_hall at trendmicro.com Sent: Friday, February 13, 2015 6:27 AM To: CABFPub (public at cabforum.org) Subject: [cabfpub] Ballot 143 - Formalization of validation working group Trend Micro votes yes. Kirk R. Hall Operations Director, Trust Services Trend Micro +1.503.753.3088 TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. 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: From gerv at mozilla.org Tue Feb 17 11:12:35 2015 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 17 Feb 2015 11:12:35 +0000 Subject: [cabfpub] Domain Validation Revision In-Reply-To: References: <54DDCC5D.50305@mozilla.org> Message-ID: <54E32223.1070200@mozilla.org> On 16/02/15 21:57, kirk_hall at trendmicro.com wrote: > Gerv -- we always allowed attorney letters in the past. > > For DV/OV, it was an "any other method" means of domain confirmation. Who has used this method? Perhaps they could explain how they feel that this provides the "same level of assurance"? What expertise does an attorney have in determining actual domain control? > For EV, it was explicitly allowed under the EVGL (and there are still > references to it in the template Attorney Letter attached to the EVGL), > but /_by mistake_/ we deleted the reference when we changed EVGL 11.7 > simply to a cross reference to BR 11.1.1 ? we accidentally dropped the > old reference to using attorney-accountant letters for EV domain > confirmation (I can give you a version number reference to the old EVGL > if you want to confirm). That would be useful, please. > This is useful when the Domain Name Registrant has licensed the domain > to the Customer, or when the parent-sub relationship is not reported > correctly, etc. If they've licensed the domain to the customer, then surely the customer can demonstrate control in any of the normal ways? If they can't, then they don't actually have control of it, do they? Gerv From bruce.morton at entrust.com Tue Feb 17 12:27:36 2015 From: bruce.morton at entrust.com (Bruce Morton) Date: Tue, 17 Feb 2015 12:27:36 +0000 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names In-Reply-To: References: Message-ID: <452C99D20750E74083DBA441FF932385E4167C98@SOTTEXCH10.corp.ad.entrust.com> Entrust abstains. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Tuesday, February 10, 2015 1:39 PM To: public at cabforum.org Subject: [cabfpub] Ballot 144 - Validation rules for .onion names Here's the ballot with the two typos fixed: Applicants want a CA-signed .onion address for several reasons, including: - Powerful web platform features are restricted to secure origins, which are currently not available to onion names (in part, because of the lack of IANA registration). Permitting EV certs for onion names will help provide a secure origin for the service, moving onion towards use of powerful web platform features. - Currently, access to .onion names over https from a standard browser results in the standard existing 'Invalid Certificate' warning. Training users to click through security warnings lowers the value of these warnings and will cause users to miss important security information. Removing these warnings for the user, through use of a digital certificate, will help users recognize and avoid real MITM attacks. - The public needs attribution of ownership of the .onion address to differentiate onion services, including potential phishing services. Because onion names are not easily recognizable strings, providing the public with additional information about the operator has significant security improvements, especially in regions where use of the incorrect name could have lethal consequences. The following motion has been proposed by Jeremy Rowley of DigiCert and endorsed by Ryan Sleevi of Google and Wayne Thayer of GoDaddy. --------------------- Motion Starts --------------------- 1) Amend Section 9.2.1 of the Baseline Requirements v. 1.2.3 as follows: 9.2.1 Subject Alternative Name Extension Certificate Field: extensions:subjectAltName Required/Optional: Required Contents: This 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. The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate. Wildcard FQDNs are permitted. As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name, the CA SHALL notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016. Also as of the Effective Date, the CA SHALL NOT issue a certificate with an Expiry Date later than 1 November 2015 with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name. Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Name. Effective May 1, 2015, each CA SHALL revoke all unexpired Certificates with an Internal Name using onion as the right-most label in an entry in the subjectAltName Extension or commonName field unless such Certificate was issued in accordance with Appendix F of the EV Guidelines. 2) Amend Section 9.2.2 and 11.7.1 of the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2 as follows: 9.2.2. Subject Alternative Name Extension Certificate field: subjectAltName:dNSName Required/Optional: Required Contents: This extension MUST contain one or more host Domain Name(s) owned or controlled by the Subject and to be associated with the Subject's server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). Wildcard certificates are not allowed for EV Certificates except as permitted under Appendix F. 11.7 Verification of Applicant's Domain Name 11.7.1. Verification Requirements (1) For each Fully-Qualified Domain Name listed in a Certificate, other than a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant (or the Applicant's Parent Company, Subsidiary Company, or Affiliate, collectively referred to as "Applicant" for the purposes of this section) either is the Domain Name Registrant or has control over the FQDN using a procedure specified in Section 11.1.1 of the Baseline Requirements, except that a CA MAY NOT verify a domain using the procedure described 11.1.1(7). For a Certificate issued to a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant's control over the .onion Domain Name in accordance with Appendix F. (2) Mixed Character Set Domain Names: EV Certificates MAY include Domain Names containing mixed character sets only in compliance with the rules set forth by the domain registrar. The CA MUST visually compare any Domain Names with mixed character sets with known high risk domains. If a similarity is found, then the EV Certificate Request MUST be flagged as High Risk. The CA must perform reasonably appropriate additional authentication and verification to be certain beyond reasonable doubt that the Applicant and the target in question are the same organization. 3) Add a new Appendix F to the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2: Appendix F - Issuance of Certificates for .onion Domain Names A CA may issue an EV Certificate with .onion in the right-most label of the Domain Name provided that issuance complies with the requirements set forth in this Appendix: 1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) The CAB Forum has created an extension of the TBSCertificate for use in conveying hashes of keys related to .onion addresses. The Tor Service Descriptor Hash extension has the following format: cabf-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 } TorServiceDescriptorSyntax ::= SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash TorServiceDescriptorHash:: = SEQUENCE { onionURI UTF8String algorithm AlgorithmIdentifier subjectPublicKeyHash BIT STRING } Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 6234) performed over the DER-encoding of an ASN.1 SubjectPublicKey of the .onion service and SubjectPublicKeyHash is the hash output. 2. The CA MUST verify the Applicant's control over the .onion Domain Name using one of the following: a. The CA MAY verify the Applicant's control over the .onion service by posting a specific value at a well-known URL under RFC5785. b. The CA MAY verify the Applicant's control over the .onion service by having the Applicant provide a Certificate Request signed using the .onion public key if the Attributes section of the certificationRequestInfo contains: (i) A caSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy, 2) is generated by the CA, and 3) delivered to the Applicant through a Verified Method of Communication and (ii) An applicantSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy and 2) is generated by the Applicant. The signing nonce attributes have the following format: caSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-caSigningNonce } } cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } applicantSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-applicantSigningNonce } } cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 } 4. Each Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name MUST conform to the requirements of these Guidelines, including the content requirements in Section 9 and Appendix B of the Baseline Requirements, except that the CA MAY include a wildcard character in the Subject Alternative Name Extension and Subject Common Name Field as the left-most character in the .onion Domain Name provided inclusion of the wildcard character complies with Section 11.1.3 of the Baseline Requirements. 5. CAs MUST NOT issue a Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name with a validity period longer than 15 months. Despite Section 9.2.1 of the Baseline Requirements deprecating the use of Internal Names, a CA MAY issue a Certificate containing an .onion name with an expiration date later than 1 November 2015 after (and only if) .onion is officially recognized by the IESG as a reserved TLD. 6. On or before May 1, 2015, each CA MUST revoke all Certificates issued with the Subject Alternative Name extension or Common Name field that includes a Domain Name where .onion is in the right-most label of the Domain Name unless the Certificate was issued in compliance with this Appendix F. ---- Motion Ends ----- The review period for this ballot shall commence at 2200 UTC on Thursday, 4 February 2015, and will close at 2200 UTC on Thursday, 11 February 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on Monday, 18 February 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: From haavardm at opera.com Tue Feb 17 13:05:54 2015 From: haavardm at opera.com (haavardm at work) Date: Tue, 17 Feb 2015 14:05:54 +0100 Subject: [cabfpub] Ballot 143 - Formalization of validation working group In-Reply-To: References: Message-ID: Opera votes YES. H?vard On Thu, Feb 12, 2015 at 11:26 PM, kirk_hall at trendmicro.com < kirk_hall at trendmicro.com> wrote: > Trend Micro votes yes. > > > > *Kirk R. Hall* > > Operations Director, Trust Services > > Trend Micro > > +1.503.753.3088 > > > > TREND MICRO EMAIL NOTICE > The information contained in this email and any attachments is confidential > and may be subject to copyright or other intellectual property protection. > If you are not the intended recipient, you are not authorized to use or > disclose this information, and we request that you notify us by reply mail or > telephone and delete the original message from your mail system. > > > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From haavardm at opera.com Tue Feb 17 13:08:14 2015 From: haavardm at opera.com (haavardm at work) Date: Tue, 17 Feb 2015 14:08:14 +0100 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names Message-ID: Opera votes YES On Tue, Feb 10, 2015 at 7:38 PM, Jeremy Rowley wrote: > *Here?s the ballot with the two typos fixed:* > > > > Applicants want a CA-signed .onion address for several reasons, including: > > - Powerful web platform features are restricted to secure > origins, which are currently not available to onion names (in part, because > of the lack of IANA registration). Permitting EV certs for onion names > will help provide a secure origin for the service, moving onion towards use > of powerful web platform features. > > - Currently, access to .onion names over https from a > standard browser results in the standard existing 'Invalid Certificate' > warning. Training users to click through security warnings lowers the > value of these warnings and will cause users to miss important security > information. Removing these warnings for the user, through use of a > digital certificate, will help users recognize and avoid real MITM attacks. > > - The public needs attribution of ownership of the .onion > address to differentiate onion services, including potential phishing > services. Because onion names are not easily recognizable strings, > providing the public with additional information about the operator has > significant security improvements, especially in regions where use of the > incorrect name could have lethal consequences. > > > > The following motion has been proposed by Jeremy Rowley of DigiCert and > endorsed by Ryan Sleevi of Google and Wayne Thayer of GoDaddy. > > > > --------------------- > > Motion Starts > > --------------------- > > > > 1) Amend Section 9.2.1 of the Baseline Requirements v. 1.2.3 as follows: > > 9.2.1 Subject Alternative Name Extension > > Certificate Field: extensions:subjectAltName > > Required/Optional: Required > > Contents: This 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. The CA MUST confirm that > the Applicant controls the Fully-Qualified Domain Name or IP address or has > been granted the right to use it by the Domain Name Registrant or IP > address assignee, as appropriate. > > > > Wildcard FQDNs are permitted. As of the Effective Date of these > Requirements, prior to the issuance of a Certificate with a > subjectAlternativeName extension or Subject commonName field containing a > Reserved IP Address or Internal Name, the CA SHALL notify the Applicant > that the use of such Certificates has been deprecated by the CA / Browser > Forum and that the practice will be eliminated by October 2016. Also as of > the Effective Date, the CA SHALL NOT issue a certificate with an Expiry > Date later than 1 November 2015 with a subjectAlternativeName extension or > Subject commonName field containing a Reserved IP Address or Internal Name. > Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose > subjectAlternativeName extension or Subject commonName field contains a > Reserved IP Address or Internal Name. *Effective May 1, 2015, each CA > SHALL revoke all unexpired Certificates with an Internal Name using onion > as the right-most label in an entry in the subjectAltName Extension or > commonName field unless such Certificate was issued in accordance with > Appendix F of the EV Guidelines.* > > > > 2) Amend Section 9.2.2 and 11.7.1 of the Guidelines for the Issuance and > Management of Extended Validation Certificates v1.5.2 as follows: > > > > 9.2.2. Subject Alternative Name Extension Certificate field: > subjectAltName:dNSName > > Required/Optional: Required > > Contents: This extension MUST contain one or more host Domain Name(s) > owned or controlled by the Subject and to be associated with the Subject?s > server. Such server MAY be owned and operated by the Subject or another > entity (e.g., a hosting service). Wildcard certificates are not allowed for > EV Certificates* except as permitted under Appendix F*. > > > > 11.7 Verification of Applicant?s Domain Name > > > > 11.7.1. Verification Requirements > > > > (1) For each Fully-Qualified Domain Name listed in a Certificate, other > than a Domain Name with .onion in the right-most label of the Domain Name, > the CA SHALL confirm that, as of the date the Certificate was issued, the > Applicant (or the Applicant?s Parent Company, Subsidiary Company, or > Affiliate, collectively referred to as ?Applicant? for the purposes of this > section) either is the Domain Name Registrant or has control over the FQDN > using a procedure specified in Section 11.1.1 of the Baseline Requirements, > except that a CA MAY NOT verify a domain using the procedure described > 11.1.1(7). *For a Certificate issued to a Domain Name with .onion in the > right-most label of the Domain Name, the CA SHALL confirm that, as of the > date the Certificate was issued, the Applicant?s control over the .onion > Domain Name in accordance with Appendix F.* > > > > (2) Mixed Character Set Domain Names: EV Certificates MAY include Domain > Names containing mixed character sets only in compliance with the rules set > forth by the domain registrar. The CA MUST visually compare any Domain > Names with mixed character sets with known high risk domains. If a > similarity is found, then the EV Certificate Request MUST be flagged as > High Risk. The CA must perform reasonably appropriate additional > authentication and verification to be certain beyond reasonable doubt that > the Applicant and the target in question are the same organization. > > > > 3) Add a new Appendix F to the Guidelines for the Issuance and Management > of Extended Validation Certificates v1.5.2: > > > > Appendix F ? Issuance of Certificates for .onion Domain Names > > > > A CA may issue an EV Certificate with .onion in the right-most label of > the Domain Name provided that issuance complies with the requirements set > forth in this Appendix: > > 1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) > > The CAB Forum has created an extension of the TBSCertificate for use in > conveying hashes of keys related to .onion addresses. The Tor Service > Descriptor Hash extension has the following format: > > > > cabf-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 } > > > > TorServiceDescriptorSyntax ::= > > SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash > > > > TorServiceDescriptorHash:: = SEQUENCE { > > onionURI UTF8String > > algorithm AlgorithmIdentifier > > subjectPublicKeyHash BIT STRING } > > > > Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 6234) > performed over the DER-encoding of an ASN.1 SubjectPublicKey of the .onion > service and SubjectPublicKeyHash is the hash output. > > > > 2. The CA MUST verify the Applicant?s control over the .onion Domain > Name using one of the following: > > > > a. The CA MAY verify the Applicant?s control over the .onion service > by posting a specific value at a well-known URL under RFC5785. > > > > b. The CA MAY verify the Applicant?s control over the .onion service > by having the Applicant provide a Certificate Request signed using the > .onion public key if the Attributes section of the certificationRequestInfo > contains: > > > > (i) A caSigningNonce attribute that 1) contains a single value > with at least 64-bits of entropy, 2) is generated by the CA, and 3) > delivered to the Applicant through a Verified Method of Communication and > > (ii) An applicantSigningNonce attribute that 1) contains a > single value with at least 64-bits of entropy and 2) is generated by the > Applicant. > > > > The signing nonce attributes have the following format: > > > > caSigningNonce ATTRIBUTE ::= { > > WITH SYNTAX OCTET STRING > > EQUALITY MATCHING RULE octetStringMatch > > SINGLE VALUE TRUE > > ID { > cabf-caSigningNonce } > > } > > > > cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } > > > > applicantSigningNonce ATTRIBUTE ::= { > > WITH SYNTAX OCTET STRING > > EQUALITY MATCHING RULE octetStringMatch > > SINGLE VALUE TRUE > > ID { > cabf-applicantSigningNonce } > > } > > > > cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 } > > > > 4. Each Certificate that includes a Domain Name where .onion is in > the right-most label of the Domain Name MUST conform to the requirements of > these Guidelines, including the content requirements in Section 9 and > Appendix B of the Baseline Requirements, except that the CA MAY include a > wildcard character in the Subject Alternative Name Extension and Subject > Common Name Field as the left-most character in the .onion Domain Name > provided inclusion of the wildcard character complies with Section 11.1.3 > of the Baseline Requirements. > > > > 5. CAs MUST NOT issue a Certificate that includes a Domain Name where > .onion is in the right-most label of the Domain Name with a validity period > longer than 15 months. Despite Section 9.2.1 of the Baseline Requirements > deprecating the use of Internal Names, a CA MAY issue a Certificate > containing an .onion name with an expiration date later than 1 November > 2015 after (and only if) .onion is officially recognized by the IESG as a > reserved TLD. > > > > 6. On or before May 1, 2015, each CA MUST revoke all Certificates > issued with the Subject Alternative Name extension or Common Name field > that includes a Domain Name where .onion is in the right-most label of the > Domain Name unless the Certificate was issued in compliance with this > Appendix F. > > > > ---- > > Motion Ends > > ----- > > The review period for this ballot shall commence at 2200 UTC on Thursday, > 4 February 2015, and will close at 2200 UTC on Thursday, 11 February 2015. > Unless the motion is withdrawn during the review period, the voting period > will start immediately thereafter and will close at 2200 UTC on Monday, 18 > February 2015. Votes must be cast by posting an on-list reply to this > thread. > > A vote in favor of the motion must indicate a clear 'yes' in the response. > A vote against must indicate a clear 'no' in the response. A vote to > abstain must indicate a clear 'abstain' in the response. Unclear responses > will not be counted. The latest vote received from any representative of a > voting member before the close of the voting period will be counted. Voting > members are listed here: https://cabforum.org/members/ > > In order for the motion to be adopted, two thirds or more of the votes > cast by members in the CA category and greater than 50% of the votes cast > by members in the browser category must be in favor. Quorum is currently > nine (9) members? at least nine members must participate in the ballot, > either by voting in favor, voting against, or abstaining. > > > > > > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From md at ssc.lt Tue Feb 17 13:20:22 2015 From: md at ssc.lt (Moudrick M. Dadashov) Date: Tue, 17 Feb 2015 15:20:22 +0200 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names In-Reply-To: References: Message-ID: <54E34016.1010101@ssc.lt> SSC votes: "Yes". Thanks, M.D On 2/17/2015 3:08 PM, haavardm at work wrote: > Opera votes YES > > > On Tue, Feb 10, 2015 at 7:38 PM, Jeremy Rowley > > wrote: > > *Here?s the ballot with the two typos fixed:* > > Applicants want a CA-signed .onion address for several reasons, > including: > > - Powerful web platform features are restricted to secure origins, > which are currently not available to onion names (in part, because > of the lack of IANA registration). Permitting EV certs for onion > names will help provide a secure origin for the service, moving > onion towards use of powerful web platform features. > > - Currently, access to .onion names over https from a standard > browser results in the standard existing 'Invalid Certificate' > warning. Training users to click through security warnings lowers > the value of these warnings and will cause users to miss important > security information. Removing these warnings for the user, > through use of a digital certificate, will help users recognize > and avoid real MITM attacks. > > - The public needs attribution of ownership of the .onion address > to differentiate onion services, including potential phishing > services. Because onion names are not easily recognizable strings, > providing the public with additional information about the > operator has significant security improvements, especially in > regions where use of the incorrect name could have lethal > consequences. > > The following motion has been proposed by Jeremy Rowley of > DigiCert and endorsed by Ryan Sleevi of Google and Wayne Thayer of > GoDaddy. > > --------------------- > > Motion Starts > > --------------------- > > 1) Amend Section 9.2.1 of the Baseline Requirements v. 1.2.3 as > follows: > > 9.2.1 Subject Alternative Name Extension > > Certificate Field: extensions:subjectAltName > > Required/Optional: Required > > Contents: This 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. > The CA MUST confirm that the Applicant controls the > Fully-Qualified Domain Name or IP address or has been granted the > right to use it by the Domain Name Registrant or IP address > assignee, as appropriate. > > Wildcard FQDNs are permitted. As of the Effective Date of these > Requirements, prior to the issuance of a Certificate with a > subjectAlternativeName extension or Subject commonName field > containing a Reserved IP Address or Internal Name, the CA SHALL > notify the Applicant that the use of such Certificates has been > deprecated by the CA / Browser Forum and that the practice will be > eliminated by October 2016. Also as of the Effective Date, the CA > SHALL NOT issue a certificate with an Expiry Date later than 1 > November 2015 with a subjectAlternativeName extension or Subject > commonName field containing a Reserved IP Address or Internal > Name. Effective 1 October 2016, CAs SHALL revoke all unexpired > Certificates whose subjectAlternativeName extension or Subject > commonName field contains a Reserved IP Address or Internal Name. > _Effective May 1, 2015, each CA SHALL revoke all unexpired > Certificates with an Internal Name using onion as the right-most > label in an entry in the subjectAltName Extension or commonName > field unless such Certificate was issued in accordance with > Appendix F of the EV Guidelines._ > > 2) Amend Section 9.2.2 and 11.7.1 of the Guidelines for the > Issuance and Management of Extended Validation Certificates v1.5.2 > as follows: > > 9.2.2. Subject Alternative Name Extension Certificate field: > subjectAltName:dNSName > > Required/Optional: Required > > Contents: This extension MUST contain one or more host Domain > Name(s) owned or controlled by the Subject and to be associated > with the Subject?s server. Such server MAY be owned and operated > by the Subject or another entity (e.g., a hosting service). > Wildcard certificates are not allowed for EV Certificates_except > as permitted under Appendix F_. > > 11.7 Verification of Applicant?s Domain Name > > 11.7.1. Verification Requirements > > (1) For each Fully-Qualified Domain Name listed in a Certificate, > other than a Domain Name with .onion in the right-most label of > the Domain Name, the CA SHALL confirm that, as of the date the > Certificate was issued, the Applicant (or the Applicant?s Parent > Company, Subsidiary Company, or Affiliate, collectively referred > to as ?Applicant? for the purposes of this section) either is the > Domain Name Registrant or has control over the FQDN using a > procedure specified in Section 11.1.1 of the Baseline > Requirements, except that a CA MAY NOT verify a domain using the > procedure described 11.1.1(7). _For a Certificate issued to a > Domain Name with .onion in the right-most label of the Domain > Name, the CA SHALL confirm that, as of the date the Certificate > was issued, the Applicant?s control over the .onion Domain Name in > accordance with Appendix F._ > > (2) Mixed Character Set Domain Names: EV Certificates MAY include > Domain Names containing mixed character sets only in compliance > with the rules set forth by the domain registrar. The CA MUST > visually compare any Domain Names with mixed character sets with > known high risk domains. If a similarity is found, then the EV > Certificate Request MUST be flagged as High Risk. The CA must > perform reasonably appropriate additional authentication and > verification to be certain beyond reasonable doubt that the > Applicant and the target in question are the same organization. > > 3) Add a new Appendix F to the Guidelines for the Issuance and > Management of Extended Validation Certificates v1.5.2: > > Appendix F ? Issuance of Certificates for .onion Domain Names > > A CA may issue an EV Certificate with .onion in the right-most > label of the Domain Name provided that issuance complies with the > requirements set forth in this Appendix: > > 1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) > > The CAB Forum has created an extension of the TBSCertificate for > use in conveying hashes of keys related to .onion addresses. The > Tor Service Descriptor Hash extension has the following format: > > cabf-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 } > > TorServiceDescriptorSyntax ::= > > SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash > > TorServiceDescriptorHash:: = SEQUENCE { > > onionURI UTF8String > > algorithm AlgorithmIdentifier > > subjectPublicKeyHash BIT STRING } > > Where the AlgorithmIdentifier is a hashing algorithm (defined in > RFC 6234) performed over the DER-encoding of an ASN.1 > SubjectPublicKey of the .onion service and SubjectPublicKeyHash is > the hash output. > > 2. The CA MUST verify the Applicant?s control over the .onion > Domain Name using one of the following: > > a. The CA MAY verify the Applicant?s control over the .onion > service by posting a specific value at a well-known URL under > RFC5785. > > b. The CA MAY verify the Applicant?s control over the .onion > service by having the Applicant provide a Certificate Request > signed using the .onion public key if the Attributes section of > the certificationRequestInfo contains: > > (i) A caSigningNonce attribute that 1) contains a single value > with at least 64-bits of entropy, 2) is generated by the CA, and > 3) delivered to the Applicant through a Verified Method of > Communication and > > (ii) An applicantSigningNonce attribute that 1) contains a single > value with at least 64-bits of entropy and 2) is generated by the > Applicant. > > The signing nonce attributes have the following format: > > caSigningNonce ATTRIBUTE ::= { > > WITH SYNTAX OCTET STRING > > EQUALITY MATCHING RULE octetStringMatch > > SINGLE VALUE TRUE > > ID { cabf-caSigningNonce } > > } > > cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } > > applicantSigningNonce ATTRIBUTE ::= { > > WITH SYNTAX OCTET STRING > > EQUALITY MATCHING RULE octetStringMatch > > SINGLE VALUE TRUE > > ID { cabf-applicantSigningNonce } > > } > > cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 } > > 4. Each Certificate that includes a Domain Name where .onion is in > the right-most label of the Domain Name MUST conform to the > requirements of these Guidelines, including the content > requirements in Section 9 and Appendix B of the Baseline > Requirements, except that the CA MAY include a wildcard character > in the Subject Alternative Name Extension and Subject Common Name > Field as the left-most character in the .onion Domain Name > provided inclusion of the wildcard character complies with Section > 11.1.3 of the Baseline Requirements. > > 5. CAs MUST NOT issue a Certificate that includes a Domain Name > where .onion is in the right-most label of the Domain Name with a > validity period longer than 15 months. Despite Section 9.2.1 of > the Baseline Requirements deprecating the use of Internal Names, a > CA MAY issue a Certificate containing an .onion name with an > expiration date later than 1 November 2015 after (and only if) > .onion is officially recognized by the IESG as a reserved TLD. > > 6. On or before May 1, 2015, each CA MUST revoke all Certificates > issued with the Subject Alternative Name extension or Common Name > field that includes a Domain Name where .onion is in the > right-most label of the Domain Name unless the Certificate was > issued in compliance with this Appendix F. > > ---- > > Motion Ends > > ----- > > The review period for this ballot shall commence at 2200 UTC on > Thursday, 4 February 2015, and will close at 2200 UTC on Thursday, > 11 February 2015. Unless the motion is withdrawn during the review > period, the voting period will start immediately thereafter and > will close at 2200 UTC on Monday, 18 February 2015. Votes must be > cast by posting an on-list reply to this thread. > > A vote in favor of the motion must indicate a clear 'yes' in the > response. A vote against must indicate a clear 'no' in the > response. A vote to abstain must indicate a clear 'abstain' in the > response. Unclear responses will not be counted. The latest vote > received from any representative of a voting member before the > close of the voting period will be counted. Voting members are > listed here: https://cabforum.org/members/ > > In order for the motion to be adopted, two thirds or more of the > votes cast by members in the CA category and greater than 50% of > the votes cast by members in the browser category must be in > favor. Quorum is currently nine (9) members? at least nine members > must participate in the ballot, either by voting in favor, voting > against, or abstaining. > > > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public > > > > > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3653 bytes Desc: S/MIME Cryptographic Signature URL: From realsky at cht.com.tw Tue Feb 17 13:56:23 2015 From: realsky at cht.com.tw (=?big5?B?s6+l37hz?=) Date: Tue, 17 Feb 2015 21:56:23 +0800 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names In-Reply-To: References: Message-ID: <004001d04ab9$842e5ae0$8c8b10a0$@cht.com.tw> Chunghwa Telecom Co., Ltd. vote ?No? not because we object supporting .onion names but because we think that a method suggested in the Appendix F for verifying the Applicant?s control over the .onion Domain Name has security problem. In the Appendix F, the method 2.b says 'The CA MAY verify the Applicant 's control over the .onion service by having the Applicant provide a Certificate Request signed using the .onion public key ?'. What we concerns is that if the .onion private key used to sign the PKCS#10 SSL Certificate Request is not the same one as the SSL server 's private key, it will cause security problem. For security reason, PKCS#10 Certificate Request need to be signed by the private key corresponding to the public key contained in the CertificationRequestInfo. Please refer to Note 2 of section 3 of RFC 2986 (the PKCS#10 standard), where it explains the security concern. Note 2 of section 3 of RFC 2986 is extracted as below: Note 2 - The signature on the certification request prevents an entity from requesting a certificate with another party's public key. Such an attack would give the entity the minor ability to pretend to be the originator of any message signed by the other party. This attack is significant only if the entity does not know the message being signed and the signed part of the message does not identify the signer. The entity would still not be able to decrypt messages intended for the other party, of course. Sincerely Yours, Li-Chun CHEN Engineer CISSP, CISA, CISM, PMP, Information & Communication Security Dept. Data Communication Business Group Chunghwa Telecom Co. Ltd. realsky at cht.com.tw +886-2-2344-4820#4025 From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Wednesday, February 11, 2015 2:39 AM To: public at cabforum.org Subject: [cabfpub] Ballot 144 - Validation rules for .onion names Here?s the ballot with the two typos fixed: Applicants want a CA-signed .onion address for several reasons, including: - Powerful web platform features are restricted to secure origins, which are currently not available to onion names (in part, because of the lack of IANA registration). Permitting EV certs for onion names will help provide a secure origin for the service, moving onion towards use of powerful web platform features. - Currently, access to .onion names over https from a standard browser results in the standard existing 'Invalid Certificate' warning. Training users to click through security warnings lowers the value of these warnings and will cause users to miss important security information. Removing these warnings for the user, through use of a digital certificate, will help users recognize and avoid real MITM attacks. - The public needs attribution of ownership of the .onion address to differentiate onion services, including potential phishing services. Because onion names are not easily recognizable strings, providing the public with additional information about the operator has significant security improvements, especially in regions where use of the incorrect name could have lethal consequences. The following motion has been proposed by Jeremy Rowley of DigiCert and endorsed by Ryan Sleevi of Google and Wayne Thayer of GoDaddy. --------------------- Motion Starts --------------------- 1) Amend Section 9.2.1 of the Baseline Requirements v. 1.2.3 as follows: 9.2.1 Subject Alternative Name Extension Certificate Field: extensions:subjectAltName Required/Optional: Required Contents: This 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. The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate. Wildcard FQDNs are permitted. As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name, the CA SHALL notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016. Also as of the Effective Date, the CA SHALL NOT issue a certificate with an Expiry Date later than 1 November 2015 with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name. Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Name. Effective May 1, 2015, each CA SHALL revoke all unexpired Certificates with an Internal Name using onion as the right-most label in an entry in the subjectAltName Extension or commonName field unless such Certificate was issued in accordance with Appendix F of the EV Guidelines. 2) Amend Section 9.2.2 and 11.7.1 of the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2 as follows: 9.2.2. Subject Alternative Name Extension Certificate field: subjectAltName: dNSName Required/Optional: Required Contents: This extension MUST contain one or more host Domain Name(s) owned or controlled by the Subject and to be associated with the Subject?s server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). Wildcard certificates are not allowed for EV Certificates except as permitted under Appendix F. 11.7 Verification of Applicant?s Domain Name 11.7.1. Verification Requirements (1) For each Fully-Qualified Domain Name listed in a Certificate, other than a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant (or the Applicant?s Parent Company, Subsidiary Company, or Affiliate, collectively referred to as ?Applicant? for the purposes of this section) either is the Domain Name Registrant or has control over the FQDN using a procedure specified in Section 11.1.1 of the Baseline Requirements, except that a CA MAY NOT verify a domain using the procedure described 11.1.1(7). For a Certificate issued to a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant?s control over the .onion Domain Name in accordance with Appendix F. (2) Mixed Character Set Domain Names: EV Certificates MAY include Domain Names containing mixed character sets only in compliance with the rules set forth by the domain registrar. The CA MUST visually compare any Domain Names with mixed character sets with known high risk domains. If a similarity is found, then the EV Certificate Request MUST be flagged as High Risk. The CA must perform reasonably appropriate additional authentication and verification to be certain beyond reasonable doubt that the Applicant and the target in question are the same organization. 3) Add a new Appendix F to the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2: Appendix F ? Issuance of Certificates for .onion Domain Names A CA may issue an EV Certificate with .onion in the right-most label of the Domain Name provided that issuance complies with the requirements set forth in this Appendix: 1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) The CAB Forum has created an extension of the TBSCertificate for use in conveying hashes of keys related to .onion addresses. The Tor Service Descriptor Hash extension has the following format: cabf-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 } TorServiceDescriptorSyntax ::= SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash TorServiceDescriptorHash:: = SEQUENCE { onionURI UTF8String algorithm AlgorithmIdentifier subjectPublicKeyHash BIT STRING } Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 6234) performed over the DER-encoding of an ASN.1 SubjectPublicKey of the .onion service and SubjectPublicKeyHash is the hash output. 2. The CA MUST verify the Applicant?s control over the .onion Domain Name using one of the following: a. The CA MAY verify the Applicant?s control over the .onion service by posting a specific value at a well-known URL under RFC5785. b. The CA MAY verify the Applicant?s control over the .onion service by having the Applicant provide a Certificate Request signed using the .onion public key if the Attributes section of the certificationRequestInfo contains: (i) A caSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy, 2) is generated by the CA, and 3) delivered to the Applicant through a Verified Method of Communication and (ii) An applicantSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy and 2) is generated by the Applicant. The signing nonce attributes have the following format: caSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-caSigningNonce } } cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } applicantSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-applicantSigningNonce } } cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 } 4. Each Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name MUST conform to the requirements of these Guidelines, including the content requirements in Section 9 and Appendix B of the Baseline Requirements, except that the CA MAY include a wildcard character in the Subject Alternative Name Extension and Subject Common Name Field as the left-most character in the .onion Domain Name provided inclusion of the wildcard character complies with Section 11.1.3 of the Baseline Requirements. 5. CAs MUST NOT issue a Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name with a validity period longer than 15 months. Despite Section 9.2.1 of the Baseline Requirements deprecating the use of Internal Names, a CA MAY issue a Certificate containing an .onion name with an expiration date later than 1 November 2015 after (and only if) .onion is officially recognized by the IESG as a reserved TLD. 6. On or before May 1, 2015, each CA MUST revoke all Certificates issued with the Subject Alternative Name extension or Common Name field that includes a Domain Name where .onion is in the right-most label of the Domain Name unless the Certificate was issued in compliance with this Appendix F. ---- Motion Ends ----- The review period for this ballot shall commence at 2200 UTC on Thursday, 4 February 2015, and will close at 2200 UTC on Thursday, 11 February 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on Monday, 18 February 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members? at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6450 bytes Desc: not available URL: From robert.vande.rijt at logius.nl Tue Feb 17 14:00:11 2015 From: robert.vande.rijt at logius.nl (Rijt, R.A. van de (Robert) - Logius) Date: Tue, 17 Feb 2015 14:00:11 +0000 Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group In-Reply-To: References: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> Message-ID: Logius PKIoverheid votes yes. Regards, Robert From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Wednesday, February 4, 2015 4:05 PM To: CABFPub Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group Ballot 143 - Formalization of validation working group ---- Reason ---- In order to address validation issues and inconsistencies in both the SSL Baseline Requirements and the EV Guidelines, the CAB Forum has held an informal working group previously referred to as the Extended Validation Working Group now known as the Validation Working Group, would like to modify its scope to include validation in the Baseline Requirements as well as the EV Guidelines. Jeremy Rowley of DigiCert made the following motion, which was endorsed by Rich Smith of Comodo and Kirk Hall of TrendMicro ---- Motion begins ---- The CA-Browser Forum formally establishes the Validation Working Group as an official working group of the CAB Forum, replacing the previous informal EV working group. The scope of this working group is to address issues arising under adopted CAB Forum standards related to the validation of certificate information and the inclusion of information in certificates. Scope: The Validation Working Group will consider all matters relating to the validation and inclusion of information in certificates under adopted CAB Forum guidelines. Deliverables: The Working Group shall produce one or more documents offering options to the Forum for validation within the scope defined above. ---- Motion Ends ---- The review period for this ballot shall commence at 2200 UTC on 5 Feb 2015, and will close at 2200 UTC on 11 Feb 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on 18 Feb 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. ________________________________ Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten. This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages. . -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom at ritter.vg Tue Feb 17 15:13:30 2015 From: tom at ritter.vg (Tom Ritter) Date: Tue, 17 Feb 2015 09:13:30 -0600 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names In-Reply-To: <004001d04ab9$842e5ae0$8c8b10a0$@cht.com.tw> References: <004001d04ab9$842e5ae0$8c8b10a0$@cht.com.tw> Message-ID: On 17 February 2015 at 07:56, ??? wrote: > > > Chunghwa Telecom Co., Ltd. vote ?No? not because we object supporting > .onion names but because we think that a method suggested in the Appendix F > for verifying the Applicant?s control over the .onion Domain Name has > security problem. In the Appendix F, the method 2.b says 'The CA MAY verify > the Applicant 's control over the .onion service by having the Applicant > provide a Certificate Request signed using the .onion public key ?'. What we > concerns is that if the .onion private key used to sign the PKCS#10 SSL > Certificate Request is not the same one as the SSL server 's private key, it > will cause security problem. For security reason, PKCS#10 Certificate > Request need to be signed by the private key corresponding to the public key > contained in the CertificationRequestInfo. Please refer to Note 2 of section > 3 of RFC 2986 (the PKCS#10 standard), where it explains the security > concern. Note 2 of section 3 of RFC 2986 is extracted as below: Hi Li-Chun CHEN, It was always my understanding that this CSR (signed by the onion key) was in ADDITION to the CSR signed with the SSL private key, not in place of. I guess the text does not bear this out clearly, apologies. Otherwise, yes I agree that would be a problem. (The applicant could get a certificate for a .onion address they control but a SSL private key they do not. Doesn't really introduce a security vulnerability for anyone but themselves, but clearly not correct issuance.) -tom From erwann.abalea at opentrust.com Tue Feb 17 16:38:05 2015 From: erwann.abalea at opentrust.com (Erwann Abalea) Date: Tue, 17 Feb 2015 17:38:05 +0100 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: References: <54DD1DED.4090105@mozilla.org> <54DD289E.8040304@mozilla.org> <54DDC98E.8020907@mozilla.org> Message-ID: <54E36E6D.8070106@opentrust.com> Bonjour, Coming back on this email, as it seems it hasn't been fully answered. Le 13/02/2015 17:28, kirk_hall at trendmicro.com a ?crit : > > [...] > > I have to circle back to ?Why are we doing this?? > > ?Tor users want to visit websites anonymously. [That sounds like > something CAs should support if possible] > > ?Website owners do **not** want anonymity ? in fact, just the > opposite. They want EV certs with their identity information included > that will work for Tor users. > > ?For some reason, regular TLD certs (like .com certs) won?t work after > Tor users go through the Tor blender. [Does anyone know why that is > the case?] > A TorBrowser user can connect to https://www.facebook.com, it will have the nice padlock icon, and all the packets will go through the Tor mesh network. A "{elinks,chrome,IE,whatever}+tor+socks5-in-between" user can do the same action with the same guarantees. > ?But for some reason, Internal Name .onion certs **do** work for Tor > users after they go through the Tor blender. [Does anyone know why > this is so?] > > ?Tor does not want to apply for .onion as a TLD, and does not want to > be the registrar for .onion [Why not? That would solve everything by > making .onion a TLD, so all the current CA rules could apply. And > remember, website users are not looking for anonymity in their certs ? > they want EV certs with their identity displayed prominently in the > browsers.] > > ?The Tor process for assigning .onion domains does not require domains > to be unique. > IIUC, asking Tor to connect to some identified server creates a circuit, involving at least 3 nodes (entry, relay+, exit) to provide some anonymity. Asking Tor to connect to a .onion address involves requesting the nearest catalog of hidden services to get the Tor node hosting this hidden service, and the circuit will never go through an exit node, providing confidentiality. This confidentiality is already offered by TLS. -- Erwann ABALEA -------------- next part -------------- An HTML attachment was scrubbed... URL: From robin at comodo.com Tue Feb 17 17:04:09 2015 From: robin at comodo.com (Robin Alden) Date: Tue, 17 Feb 2015 17:04:09 -0000 Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group In-Reply-To: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> References: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> Message-ID: <0a4901d04ad3$bef7f360$3ce7da20$@comodo.com> Comodo votes 'Yes'. Regards Robin Alden Comodo From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: 04 February 2015 21:05 To: CABFPub Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group Ballot 143 - Formalization of validation working group ---- Reason ---- In order to address validation issues and inconsistencies in both the SSL Baseline Requirements and the EV Guidelines, the CAB Forum has held an informal working group previously referred to as the Extended Validation Working Group now known as the Validation Working Group, would like to modify its scope to include validation in the Baseline Requirements as well as the EV Guidelines. Jeremy Rowley of DigiCert made the following motion, which was endorsed by Rich Smith of Comodo and Kirk Hall of TrendMicro ---- Motion begins ---- The CA-Browser Forum formally establishes the Validation Working Group as an official working group of the CAB Forum, replacing the previous informal EV working group. The scope of this working group is to address issues arising under adopted CAB Forum standards related to the validation of certificate information and the inclusion of information in certificates. Scope: The Validation Working Group will consider all matters relating to the validation and inclusion of information in certificates under adopted CAB Forum guidelines. Deliverables: The Working Group shall produce one or more documents offering options to the Forum for validation within the scope defined above. ---- Motion Ends ---- The review period for this ballot shall commence at 2200 UTC on 5 Feb 2015, and will close at 2200 UTC on 11 Feb 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on 18 Feb 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5156 bytes Desc: not available URL: From JRandall at trustwave.com Tue Feb 17 17:10:59 2015 From: JRandall at trustwave.com (John Randall) Date: Tue, 17 Feb 2015 17:10:59 +0000 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names Message-ID: Trustwave ABSTAINS Cheers- John From: Miskovic Peter > Date: Monday, February 16, 2015 at 8:34 AM To: "public at cabforum.org" > Subject: Re: [cabfpub] Ballot 144 - Validation rules for .onion names Ballot 144 - Validation rules for .onion names: Disig abstains. Regards, Peter Miskovic From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Tuesday, February 10, 2015 7:39 PM To: public at cabforum.org Subject: [cabfpub] Ballot 144 - Validation rules for .onion names Here?s the ballot with the two typos fixed: Applicants want a CA-signed .onion address for several reasons, including: - Powerful web platform features are restricted to secure origins, which are currently not available to onion names (in part, because of the lack of IANA registration). Permitting EV certs for onion names will help provide a secure origin for the service, moving onion towards use of powerful web platform features. - Currently, access to .onion names over https from a standard browser results in the standard existing 'Invalid Certificate' warning. Training users to click through security warnings lowers the value of these warnings and will cause users to miss important security information. Removing these warnings for the user, through use of a digital certificate, will help users recognize and avoid real MITM attacks. - The public needs attribution of ownership of the .onion address to differentiate onion services, including potential phishing services. Because onion names are not easily recognizable strings, providing the public with additional information about the operator has significant security improvements, especially in regions where use of the incorrect name could have lethal consequences. The following motion has been proposed by Jeremy Rowley of DigiCert and endorsed by Ryan Sleevi of Google and Wayne Thayer of GoDaddy. --------------------- Motion Starts --------------------- 1) Amend Section 9.2.1 of the Baseline Requirements v. 1.2.3 as follows: 9.2.1 Subject Alternative Name Extension Certificate Field: extensions:subjectAltName Required/Optional: Required Contents: This 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. The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate. Wildcard FQDNs are permitted. As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name, the CA SHALL notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016. Also as of the Effective Date, the CA SHALL NOT issue a certificate with an Expiry Date later than 1 November 2015 with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name. Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Name. Effective May 1, 2015, each CA SHALL revoke all unexpired Certificates with an Internal Name using onion as the right-most label in an entry in the subjectAltName Extension or commonName field unless such Certificate was issued in accordance with Appendix F of the EV Guidelines. 2) Amend Section 9.2.2 and 11.7.1 of the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2 as follows: 9.2.2. Subject Alternative Name Extension Certificate field: subjectAltName:dNSName Required/Optional: Required Contents: This extension MUST contain one or more host Domain Name(s) owned or controlled by the Subject and to be associated with the Subject?s server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). Wildcard certificates are not allowed for EV Certificates except as permitted under Appendix F. 11.7 Verification of Applicant?s Domain Name 11.7.1. Verification Requirements (1) For each Fully-Qualified Domain Name listed in a Certificate, other than a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant (or the Applicant?s Parent Company, Subsidiary Company, or Affiliate, collectively referred to as ?Applicant? for the purposes of this section) either is the Domain Name Registrant or has control over the FQDN using a procedure specified in Section 11.1.1 of the Baseline Requirements, except that a CA MAY NOT verify a domain using the procedure described 11.1.1(7). For a Certificate issued to a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant?s control over the .onion Domain Name in accordance with Appendix F. (2) Mixed Character Set Domain Names: EV Certificates MAY include Domain Names containing mixed character sets only in compliance with the rules set forth by the domain registrar. The CA MUST visually compare any Domain Names with mixed character sets with known high risk domains. If a similarity is found, then the EV Certificate Request MUST be flagged as High Risk. The CA must perform reasonably appropriate additional authentication and verification to be certain beyond reasonable doubt that the Applicant and the target in question are the same organization. 3) Add a new Appendix F to the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2: Appendix F ? Issuance of Certificates for .onion Domain Names A CA may issue an EV Certificate with .onion in the right-most label of the Domain Name provided that issuance complies with the requirements set forth in this Appendix: 1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) The CAB Forum has created an extension of the TBSCertificate for use in conveying hashes of keys related to .onion addresses. The Tor Service Descriptor Hash extension has the following format: cabf-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 } TorServiceDescriptorSyntax ::= SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash TorServiceDescriptorHash:: = SEQUENCE { onionURI UTF8String algorithm AlgorithmIdentifier subjectPublicKeyHash BIT STRING } Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 6234) performed over the DER-encoding of an ASN.1 SubjectPublicKey of the .onion service and SubjectPublicKeyHash is the hash output. 2. The CA MUST verify the Applicant?s control over the .onion Domain Name using one of the following: a. The CA MAY verify the Applicant?s control over the .onion service by posting a specific value at a well-known URL under RFC5785. b. The CA MAY verify the Applicant?s control over the .onion service by having the Applicant provide a Certificate Request signed using the .onion public key if the Attributes section of the certificationRequestInfo contains: (i) A caSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy, 2) is generated by the CA, and 3) delivered to the Applicant through a Verified Method of Communication and (ii) An applicantSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy and 2) is generated by the Applicant. The signing nonce attributes have the following format: caSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-caSigningNonce } } cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } applicantSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-applicantSigningNonce } } cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 } 4. Each Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name MUST conform to the requirements of these Guidelines, including the content requirements in Section 9 and Appendix B of the Baseline Requirements, except that the CA MAY include a wildcard character in the Subject Alternative Name Extension and Subject Common Name Field as the left-most character in the .onion Domain Name provided inclusion of the wildcard character complies with Section 11.1.3 of the Baseline Requirements. 5. CAs MUST NOT issue a Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name with a validity period longer than 15 months. Despite Section 9.2.1 of the Baseline Requirements deprecating the use of Internal Names, a CA MAY issue a Certificate containing an .onion name with an expiration date later than 1 November 2015 after (and only if) .onion is officially recognized by the IESG as a reserved TLD. 6. On or before May 1, 2015, each CA MUST revoke all Certificates issued with the Subject Alternative Name extension or Common Name field that includes a Domain Name where .onion is in the right-most label of the Domain Name unless the Certificate was issued in compliance with this Appendix F. ---- Motion Ends ----- The review period for this ballot shall commence at 2200 UTC on Thursday, 4 February 2015, and will close at 2200 UTC on Thursday, 11 February 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on Monday, 18 February 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members? at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. ________________________________ This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. -------------- next part -------------- An HTML attachment was scrubbed... URL: From S.Davidson at quovadisglobal.com Tue Feb 17 17:24:13 2015 From: S.Davidson at quovadisglobal.com (Stephen Davidson) Date: Tue, 17 Feb 2015 17:24:13 +0000 Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group In-Reply-To: References: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> Message-ID: QuoVadis votes yes. Best, Stephen From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Wednesday, February 4, 2015 4:05 PM To: CABFPub Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group Ballot 143 - Formalization of validation working group ---- Reason ---- In order to address validation issues and inconsistencies in both the SSL Baseline Requirements and the EV Guidelines, the CAB Forum has held an informal working group previously referred to as the Extended Validation Working Group now known as the Validation Working Group, would like to modify its scope to include validation in the Baseline Requirements as well as the EV Guidelines. Jeremy Rowley of DigiCert made the following motion, which was endorsed by Rich Smith of Comodo and Kirk Hall of TrendMicro ---- Motion begins ---- The CA-Browser Forum formally establishes the Validation Working Group as an official working group of the CAB Forum, replacing the previous informal EV working group. The scope of this working group is to address issues arising under adopted CAB Forum standards related to the validation of certificate information and the inclusion of information in certificates. Scope: The Validation Working Group will consider all matters relating to the validation and inclusion of information in certificates under adopted CAB Forum guidelines. Deliverables: The Working Group shall produce one or more documents offering options to the Forum for validation within the scope defined above. ---- Motion Ends ---- The review period for this ballot shall commence at 2200 UTC on 5 Feb 2015, and will close at 2200 UTC on 11 Feb 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on 18 Feb 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. _____ Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten. This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages. . -------------- next part -------------- An HTML attachment was scrubbed... URL: From robin at comodo.com Tue Feb 17 17:39:45 2015 From: robin at comodo.com (Robin Alden) Date: Tue, 17 Feb 2015 17:39:45 -0000 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names In-Reply-To: References: Message-ID: <0afe01d04ad8$b86d3320$29479960$@comodo.com> Comodo abstains. Regards Robin Alden Comodo From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: 10 February 2015 18:39 To: public at cabforum.org Subject: [cabfpub] Ballot 144 - Validation rules for .onion names Here's the ballot with the two typos fixed: Applicants want a CA-signed .onion address for several reasons, including: - Powerful web platform features are restricted to secure origins, which are currently not available to onion names (in part, because of the lack of IANA registration). Permitting EV certs for onion names will help provide a secure origin for the service, moving onion towards use of powerful web platform features. - Currently, access to .onion names over https from a standard browser results in the standard existing 'Invalid Certificate' warning. Training users to click through security warnings lowers the value of these warnings and will cause users to miss important security information. Removing these warnings for the user, through use of a digital certificate, will help users recognize and avoid real MITM attacks. - The public needs attribution of ownership of the .onion address to differentiate onion services, including potential phishing services. Because onion names are not easily recognizable strings, providing the public with additional information about the operator has significant security improvements, especially in regions where use of the incorrect name could have lethal consequences. The following motion has been proposed by Jeremy Rowley of DigiCert and endorsed by Ryan Sleevi of Google and Wayne Thayer of GoDaddy. --------------------- Motion Starts --------------------- 1) Amend Section 9.2.1 of the Baseline Requirements v. 1.2.3 as follows: 9.2.1 Subject Alternative Name Extension Certificate Field: extensions:subjectAltName Required/Optional: Required Contents: This 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. The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate. Wildcard FQDNs are permitted. As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name, the CA SHALL notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016. Also as of the Effective Date, the CA SHALL NOT issue a certificate with an Expiry Date later than 1 November 2015 with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name. Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Name. Effective May 1, 2015, each CA SHALL revoke all unexpired Certificates with an Internal Name using onion as the right-most label in an entry in the subjectAltName Extension or commonName field unless such Certificate was issued in accordance with Appendix F of the EV Guidelines. 2) Amend Section 9.2.2 and 11.7.1 of the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2 as follows: 9.2.2. Subject Alternative Name Extension Certificate field: subjectAltName:dNSName Required/Optional: Required Contents: This extension MUST contain one or more host Domain Name(s) owned or controlled by the Subject and to be associated with the Subject's server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). Wildcard certificates are not allowed for EV Certificates except as permitted under Appendix F. 11.7 Verification of Applicant's Domain Name 11.7.1. Verification Requirements (1) For each Fully-Qualified Domain Name listed in a Certificate, other than a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant (or the Applicant's Parent Company, Subsidiary Company, or Affiliate, collectively referred to as "Applicant" for the purposes of this section) either is the Domain Name Registrant or has control over the FQDN using a procedure specified in Section 11.1.1 of the Baseline Requirements, except that a CA MAY NOT verify a domain using the procedure described 11.1.1(7). For a Certificate issued to a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant's control over the .onion Domain Name in accordance with Appendix F. (2) Mixed Character Set Domain Names: EV Certificates MAY include Domain Names containing mixed character sets only in compliance with the rules set forth by the domain registrar. The CA MUST visually compare any Domain Names with mixed character sets with known high risk domains. If a similarity is found, then the EV Certificate Request MUST be flagged as High Risk. The CA must perform reasonably appropriate additional authentication and verification to be certain beyond reasonable doubt that the Applicant and the target in question are the same organization. 3) Add a new Appendix F to the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2: Appendix F - Issuance of Certificates for .onion Domain Names A CA may issue an EV Certificate with .onion in the right-most label of the Domain Name provided that issuance complies with the requirements set forth in this Appendix: 1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) The CAB Forum has created an extension of the TBSCertificate for use in conveying hashes of keys related to .onion addresses. The Tor Service Descriptor Hash extension has the following format: cabf-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 } TorServiceDescriptorSyntax ::= SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash TorServiceDescriptorHash:: = SEQUENCE { onionURI UTF8String algorithm AlgorithmIdentifier subjectPublicKeyHash BIT STRING } Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 6234) performed over the DER-encoding of an ASN.1 SubjectPublicKey of the .onion service and SubjectPublicKeyHash is the hash output. 2. The CA MUST verify the Applicant's control over the .onion Domain Name using one of the following: a. The CA MAY verify the Applicant's control over the .onion service by posting a specific value at a well-known URL under RFC5785. b. The CA MAY verify the Applicant's control over the .onion service by having the Applicant provide a Certificate Request signed using the .onion public key if the Attributes section of the certificationRequestInfo contains: (i) A caSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy, 2) is generated by the CA, and 3) delivered to the Applicant through a Verified Method of Communication and (ii) An applicantSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy and 2) is generated by the Applicant. The signing nonce attributes have the following format: caSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-caSigningNonce } } cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } applicantSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-applicantSigningNonce } } cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 } 4. Each Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name MUST conform to the requirements of these Guidelines, including the content requirements in Section 9 and Appendix B of the Baseline Requirements, except that the CA MAY include a wildcard character in the Subject Alternative Name Extension and Subject Common Name Field as the left-most character in the .onion Domain Name provided inclusion of the wildcard character complies with Section 11.1.3 of the Baseline Requirements. 5. CAs MUST NOT issue a Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name with a validity period longer than 15 months. Despite Section 9.2.1 of the Baseline Requirements deprecating the use of Internal Names, a CA MAY issue a Certificate containing an .onion name with an expiration date later than 1 November 2015 after (and only if) .onion is officially recognized by the IESG as a reserved TLD. 6. On or before May 1, 2015, each CA MUST revoke all Certificates issued with the Subject Alternative Name extension or Common Name field that includes a Domain Name where .onion is in the right-most label of the Domain Name unless the Certificate was issued in compliance with this Appendix F. ---- Motion Ends ----- The review period for this ballot shall commence at 2200 UTC on Thursday, 4 February 2015, and will close at 2200 UTC on Thursday, 11 February 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on Monday, 18 February 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5156 bytes Desc: not available URL: From dtokgoz at e-tugra.com.tr Wed Feb 18 09:10:27 2015 From: dtokgoz at e-tugra.com.tr (=?iso-8859-9?Q?Davut_Tokg=F6z?=) Date: Wed, 18 Feb 2015 11:10:27 +0200 Subject: [cabfpub] Ballots 143 and 144 In-Reply-To: <54DDC2A3.2000200@staff.aruba.it> References: <763539E260C37C46A0D6B340B5434C3B0ADAE0DE@AEX06.ejsarea.net> <54DDC2A3.2000200@staff.aruba.it> Message-ID: <019301d04b5a$bce15c10$36a41430$@e-tugra.com.tr> E-tugra votes yes for ballot 143 and abstains for ballot 144 Davut Tokg?z -------------- next part -------------- An HTML attachment was scrubbed... URL: From Dean_Coclin at symantec.com Wed Feb 18 15:40:40 2015 From: Dean_Coclin at symantec.com (Dean Coclin) Date: Wed, 18 Feb 2015 07:40:40 -0800 Subject: [cabfpub] Voting Reminder Message-ID: <14D026C7F297AD44AC82578DD818CDD038EF1EAA5C@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> Reminder: Voting closes later today on ballots 143 and 144. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6130 bytes Desc: not available URL: From Mads.Henriksveen at buypass.no Wed Feb 18 15:40:50 2015 From: Mads.Henriksveen at buypass.no (Mads Egil Henriksveen) Date: Wed, 18 Feb 2015 15:40:50 +0000 Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group In-Reply-To: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> References: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> Message-ID: Buypass votes YES Regards Mads From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: 4. februar 2015 22:05 To: CABFPub Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group Ballot 143 - Formalization of validation working group ---- Reason ---- In order to address validation issues and inconsistencies in both the SSL Baseline Requirements and the EV Guidelines, the CAB Forum has held an informal working group previously referred to as the Extended Validation Working Group now known as the Validation Working Group, would like to modify its scope to include validation in the Baseline Requirements as well as the EV Guidelines. Jeremy Rowley of DigiCert made the following motion, which was endorsed by Rich Smith of Comodo and Kirk Hall of TrendMicro ---- Motion begins ---- The CA-Browser Forum formally establishes the Validation Working Group as an official working group of the CAB Forum, replacing the previous informal EV working group. The scope of this working group is to address issues arising under adopted CAB Forum standards related to the validation of certificate information and the inclusion of information in certificates. Scope: The Validation Working Group will consider all matters relating to the validation and inclusion of information in certificates under adopted CAB Forum guidelines. Deliverables: The Working Group shall produce one or more documents offering options to the Forum for validation within the scope defined above. ---- Motion Ends ---- The review period for this ballot shall commence at 2200 UTC on 5 Feb 2015, and will close at 2200 UTC on 11 Feb 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on 18 Feb 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Dean_Coclin at symantec.com Wed Feb 18 15:51:09 2015 From: Dean_Coclin at symantec.com (Dean Coclin) Date: Wed, 18 Feb 2015 07:51:09 -0800 Subject: [cabfpub] Agenda for CA/B Forum call February 18, 2015 Message-ID: <14D026C7F297AD44AC82578DD818CDD038EF1EAA6F@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> Antitrust Statement: As you know, this meeting includes companies that compete against one another. This meeting is intended to discuss technical standards related to the provision of existing and new types of digital certificates without restricting competition in developing and marketing such certificates. This meeting is not intended to share competitively-sensitive information among competitors, and therefore all participants agree not to discuss or exchange information related to: (a) Pricing policies, pricing formulas, prices or other terms of sale; (b) Costs, cost structures, profit margins, (c) Pending or planned service offerings, (d) Customers, business, or marketing plans; or (e) The allocation of customers, territories, or products in any way. Note: Please announce yourself when you dial in. This helps in documenting attendance when recording is played back later. Here is the proposed agenda: Time Start(UTC) Stop Slot Description Notes / Presenters (Thur) 19 Feb 2015 0:01 16:00 16:01 1 Read Antitrust Statement Dean 0:02 16:01 16:03 2 Roll Call Dean 0:01 16:03 16:04 3 Review Agenda Dean 0:01 16:04 16:05 4 Approve Minutes of 5 Feb 2015 Latest version distributed by Dean on Feb 15th 0:20 16:05 16:25 5 Results of Ballots 143 and 144. Use of Abstention vote. Dean 0:05 16:25 16:30 6 IPv6: additional updates? Ryan S. 0:10 16:30 16:40 7 New Ballots: Operational existence and domain validation Jeremy 0:10 16:40 16:45 8 Working Groups-public discussion? 0:05 16:45 16:50 9 EV Working Group Status Update Jeremy 0:02 16:50 16:52 10 Code Signing Working Group Status Update Dean/Jeremy -Public draft 0:02 16:52 16:54 11 Policy Review Working Group Status Update Proposed ballot status 0:02 16:54 16:56 12 *New* Information Sharing Working Group Update Ben 0:03 16:56 16:59 13 Any Other Business - Cupertino Meeting-March 10-12: 32 attendees signed up so far 0:00 17:00 17:00 14 Next phone call - March 5, 2015 Should we skip the next call since F2F is the week after? 0:00 17:00 17:00 15 Adjourn -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6130 bytes Desc: not available URL: From erwann.abalea at opentrust.com Wed Feb 18 16:14:25 2015 From: erwann.abalea at opentrust.com (Erwann Abalea) Date: Wed, 18 Feb 2015 17:14:25 +0100 Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group In-Reply-To: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> References: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> Message-ID: <54E4BA61.2000100@opentrust.com> OpenTrust votes Yes. -- Erwann ABALEA Le 04/02/2015 22:05, Jeremy Rowley a ?crit : > > Ballot 143 - Formalization of validation working group > > ---- > > Reason > > ---- > > In order to address validation issues and inconsistencies in both the > SSL Baseline Requirements and the EV Guidelines, the CAB Forum has > held an informal working group previously referred to as the Extended > Validation Working Group now known as the Validation Working Group, > would like to modify its scope to include validation in the Baseline > Requirements as well as the EV Guidelines. > > Jeremy Rowley of DigiCert made the following motion, which was > endorsed by Rich Smith of Comodo and Kirk Hall of TrendMicro > > ---- > > Motion begins > > ---- > > The CA-Browser Forum formally establishes the Validation Working Group > as an official working group of the CAB Forum, replacing the previous > informal EV working group. The scope of this working group is to > address issues arising under adopted CAB Forum standards related to > the validation of certificate information and the inclusion of > information in certificates. > > Scope: The Validation Working Group will consider all matters relating > to the validation and inclusion of information in certificates under > adopted CAB Forum guidelines. > > Deliverables: The Working Group shall produce one or more documents > offering options to the Forum for validation within the scope defined > above. > > ---- > > Motion Ends > > ---- > > The review period for this ballot shall commence at 2200 UTC on 5 Feb > 2015, and will close at 2200 UTC on 11 Feb 2015. Unless the motion is > withdrawn during the review period, the voting period will start > immediately thereafter and will close at 2200 UTC on 18 Feb 2015. > Votes must be cast by posting an on-list reply to this thread. > > A vote in favor of the motion must indicate a clear 'yes' in the > response. A vote against must indicate a clear 'no' in the response. A > vote to abstain must indicate a clear 'abstain' in the response. > Unclear responses will not be counted. The latest vote received from > any representative of a voting member before the close of the voting > period will be counted. Voting members are listed here: > https://cabforum.org/members/ > > In order for the motion to be adopted, two thirds or more of the votes > cast by members in the CA category and greater than 50% of the votes > cast by members in the browser category must be in favor. Quorum is > currently nine (9) members? at least nine members must participate in > the ballot, either by voting in favor, voting against, or abstaining. > > > > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public -------------- next part -------------- An HTML attachment was scrubbed... URL: From JAmaral at trustwave.com Wed Feb 18 16:24:20 2015 From: JAmaral at trustwave.com (John Amaral) Date: Wed, 18 Feb 2015 16:24:20 +0000 Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group In-Reply-To: References: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> Message-ID: <99A44CD64687DD4EB6D44264DBED7525507C0DBD@SKYMB2.trustwave.com> Trustwave votes YES Regards, John John Amaral SVP, Product Management t: +1 781.419.6344 m: +1 978.760.0144 Trustwave | SMART SECURITY ON DEMAND www.trustwave.com Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group Ballot 143 - Formalization of validation working group ---- Reason ---- In order to address validation issues and inconsistencies in both the SSL Baseline Requirements and the EV Guidelines, the CAB Forum has held an informal working group previously referred to as the Extended Validation Working Group now known as the Validation Working Group, would like to modify its scope to include validation in the Baseline Requirements as well as the EV Guidelines. Jeremy Rowley of DigiCert made the following motion, which was endorsed by Rich Smith of Comodo and Kirk Hall of TrendMicro ---- Motion begins ---- The CA-Browser Forum formally establishes the Validation Working Group as an official working group of the CAB Forum, replacing the previous informal EV working group. The scope of this working group is to address issues arising under adopted CAB Forum standards related to the validation of certificate information and the inclusion of information in certificates. Scope: The Validation Working Group will consider all matters relating to the validation and inclusion of information in certificates under adopted CAB Forum guidelines. Deliverables: The Working Group shall produce one or more documents offering options to the Forum for validation within the scope defined above. ---- Motion Ends ---- The review period for this ballot shall commence at 2200 UTC on 5 Feb 2015, and will close at 2200 UTC on 11 Feb 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on 18 Feb 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. ________________________________ This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Mads.Henriksveen at buypass.no Wed Feb 18 16:35:00 2015 From: Mads.Henriksveen at buypass.no (Mads Egil Henriksveen) Date: Wed, 18 Feb 2015 16:35:00 +0000 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names In-Reply-To: References: Message-ID: <55329794072a4622ad3ef4c589d95f70@Buyp-gvk-ex01.intra.buypass.no> Buypass votes YES. Regards Mads From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: 10. februar 2015 19:39 To: public at cabforum.org Subject: [cabfpub] Ballot 144 - Validation rules for .onion names Here's the ballot with the two typos fixed: Applicants want a CA-signed .onion address for several reasons, including: - Powerful web platform features are restricted to secure origins, which are currently not available to onion names (in part, because of the lack of IANA registration). Permitting EV certs for onion names will help provide a secure origin for the service, moving onion towards use of powerful web platform features. - Currently, access to .onion names over https from a standard browser results in the standard existing 'Invalid Certificate' warning. Training users to click through security warnings lowers the value of these warnings and will cause users to miss important security information. Removing these warnings for the user, through use of a digital certificate, will help users recognize and avoid real MITM attacks. - The public needs attribution of ownership of the .onion address to differentiate onion services, including potential phishing services. Because onion names are not easily recognizable strings, providing the public with additional information about the operator has significant security improvements, especially in regions where use of the incorrect name could have lethal consequences. The following motion has been proposed by Jeremy Rowley of DigiCert and endorsed by Ryan Sleevi of Google and Wayne Thayer of GoDaddy. --------------------- Motion Starts --------------------- 1) Amend Section 9.2.1 of the Baseline Requirements v. 1.2.3 as follows: 9.2.1 Subject Alternative Name Extension Certificate Field: extensions:subjectAltName Required/Optional: Required Contents: This 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. The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate. Wildcard FQDNs are permitted. As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name, the CA SHALL notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016. Also as of the Effective Date, the CA SHALL NOT issue a certificate with an Expiry Date later than 1 November 2015 with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name. Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Name. Effective May 1, 2015, each CA SHALL revoke all unexpired Certificates with an Internal Name using onion as the right-most label in an entry in the subjectAltName Extension or commonName field unless such Certificate was issued in accordance with Appendix F of the EV Guidelines. 2) Amend Section 9.2.2 and 11.7.1 of the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2 as follows: 9.2.2. Subject Alternative Name Extension Certificate field: subjectAltName:dNSName Required/Optional: Required Contents: This extension MUST contain one or more host Domain Name(s) owned or controlled by the Subject and to be associated with the Subject's server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). Wildcard certificates are not allowed for EV Certificates except as permitted under Appendix F. 11.7 Verification of Applicant's Domain Name 11.7.1. Verification Requirements (1) For each Fully-Qualified Domain Name listed in a Certificate, other than a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant (or the Applicant's Parent Company, Subsidiary Company, or Affiliate, collectively referred to as "Applicant" for the purposes of this section) either is the Domain Name Registrant or has control over the FQDN using a procedure specified in Section 11.1.1 of the Baseline Requirements, except that a CA MAY NOT verify a domain using the procedure described 11.1.1(7). For a Certificate issued to a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant's control over the .onion Domain Name in accordance with Appendix F. (2) Mixed Character Set Domain Names: EV Certificates MAY include Domain Names containing mixed character sets only in compliance with the rules set forth by the domain registrar. The CA MUST visually compare any Domain Names with mixed character sets with known high risk domains. If a similarity is found, then the EV Certificate Request MUST be flagged as High Risk. The CA must perform reasonably appropriate additional authentication and verification to be certain beyond reasonable doubt that the Applicant and the target in question are the same organization. 3) Add a new Appendix F to the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2: Appendix F - Issuance of Certificates for .onion Domain Names A CA may issue an EV Certificate with .onion in the right-most label of the Domain Name provided that issuance complies with the requirements set forth in this Appendix: 1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) The CAB Forum has created an extension of the TBSCertificate for use in conveying hashes of keys related to .onion addresses. The Tor Service Descriptor Hash extension has the following format: cabf-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 } TorServiceDescriptorSyntax ::= SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash TorServiceDescriptorHash:: = SEQUENCE { onionURI UTF8String algorithm AlgorithmIdentifier subjectPublicKeyHash BIT STRING } Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 6234) performed over the DER-encoding of an ASN.1 SubjectPublicKey of the .onion service and SubjectPublicKeyHash is the hash output. 2. The CA MUST verify the Applicant's control over the .onion Domain Name using one of the following: a. The CA MAY verify the Applicant's control over the .onion service by posting a specific value at a well-known URL under RFC5785. b. The CA MAY verify the Applicant's control over the .onion service by having the Applicant provide a Certificate Request signed using the .onion public key if the Attributes section of the certificationRequestInfo contains: (i) A caSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy, 2) is generated by the CA, and 3) delivered to the Applicant through a Verified Method of Communication and (ii) An applicantSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy and 2) is generated by the Applicant. The signing nonce attributes have the following format: caSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-caSigningNonce } } cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } applicantSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-applicantSigningNonce } } cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 } 4. Each Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name MUST conform to the requirements of these Guidelines, including the content requirements in Section 9 and Appendix B of the Baseline Requirements, except that the CA MAY include a wildcard character in the Subject Alternative Name Extension and Subject Common Name Field as the left-most character in the .onion Domain Name provided inclusion of the wildcard character complies with Section 11.1.3 of the Baseline Requirements. 5. CAs MUST NOT issue a Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name with a validity period longer than 15 months. Despite Section 9.2.1 of the Baseline Requirements deprecating the use of Internal Names, a CA MAY issue a Certificate containing an .onion name with an expiration date later than 1 November 2015 after (and only if) .onion is officially recognized by the IESG as a reserved TLD. 6. On or before May 1, 2015, each CA MUST revoke all Certificates issued with the Subject Alternative Name extension or Common Name field that includes a Domain Name where .onion is in the right-most label of the Domain Name unless the Certificate was issued in compliance with this Appendix F. ---- Motion Ends ----- The review period for this ballot shall commence at 2200 UTC on Thursday, 4 February 2015, and will close at 2200 UTC on Thursday, 11 February 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on Monday, 18 February 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: From erwann.abalea at opentrust.com Wed Feb 18 19:07:44 2015 From: erwann.abalea at opentrust.com (Erwann Abalea) Date: Wed, 18 Feb 2015 20:07:44 +0100 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names In-Reply-To: References: Message-ID: <54E4E300.3050303@opentrust.com> OpenTrust votes NO. I've got nothing against Tor, I use it and operate a relay node, and I appreciate its value. However: * there's no constraint on service descriptor key sizes, and right now the keys are 1024bits RSA by default. The service descriptor key is what gives the hidden service its name (facebookcorewwwi.onion, for example), so it can't be changed without changing the hidden service name, and the service descriptor key size can't easily be changed (it's a manual and undocumented process, and I'm not sure a larger key will be accepted by Tor clients). The vast majority of onion keys are also RSA1024 ones. For example, the service descriptor key for the "facebookcorewwwi" service is also a 1024bits one. Whoever gets the private key can impersonate the hidden service. CABForum members must not certify public keys smaller than 2048 bits since 2013-12-31, let's not reintroduce them now. * the hidden service name that will be certified is generated using a truncated SHA1. Cryptographically, that's not a security problem so far because it uses the second preimage resistance of SHA1, and SHA1 has no real weakness regarding second preimage. It's a 2^80 work effort for an attacker to generate a key having the same hidden service name as an existing one. CABForum members have already agreed to avoid SHA1, with a deprecation plan, even for intermediate CA certificates, where we also rely on the second preimage resistance property of the hash function (with a 2^160 effort for an attacker because it's not truncated). Let's be consistent and avoid SHA1 all along. * the final goal of this ballot is to allow a Tor user to access a non hidden service using a hidden service name. Such a user can *already* access to the public facing classical version of this service, using its public name. A Tor user can already access https://www.whatever.com with its browser and the browser will be happy and get the green bar if the certificate is an EV one. I may fail to see the expected benefit, but that's it, I don't see it. -- Erwann ABALEA Le 10/02/2015 19:38, Jeremy Rowley a ?crit : > > *Here?s the ballot with the two typos fixed:* > > Applicants want a CA-signed .onion address for several reasons, including: > > - Powerful web platform features are restricted to secure origins, > which are currently not available to onion names (in part, because of > the lack of IANA registration). Permitting EV certs for onion names > will help provide a secure origin for the service, moving onion > towards use of powerful web platform features. > > - Currently, access to .onion names over https from a standard browser > results in the standard existing 'Invalid Certificate' warning. > Training users to click through security warnings lowers the value of > these warnings and will cause users to miss important security > information. Removing these warnings for the user, through use of a > digital certificate, will help users recognize and avoid real MITM > attacks. > > - The public needs attribution of ownership of the .onion address to > differentiate onion services, including potential phishing services. > Because onion names are not easily recognizable strings, providing the > public with additional information about the operator has significant > security improvements, especially in regions where use of the > incorrect name could have lethal consequences. > > The following motion has been proposed by Jeremy Rowley of DigiCert > and endorsed by Ryan Sleevi of Google and Wayne Thayer of GoDaddy. > > --------------------- > > Motion Starts > > --------------------- > > 1) Amend Section 9.2.1 of the Baseline Requirements v. 1.2.3 as follows: > > 9.2.1 Subject Alternative Name Extension > > Certificate Field: extensions:subjectAltName > > Required/Optional: Required > > Contents: This 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. The CA MUST > confirm that the Applicant controls the Fully-Qualified Domain Name or > IP address or has been granted the right to use it by the Domain Name > Registrant or IP address assignee, as appropriate. > > Wildcard FQDNs are permitted. As of the Effective Date of these > Requirements, prior to the issuance of a Certificate with a > subjectAlternativeName extension or Subject commonName field > containing a Reserved IP Address or Internal Name, the CA SHALL notify > the Applicant that the use of such Certificates has been deprecated by > the CA / Browser Forum and that the practice will be eliminated by > October 2016. Also as of the Effective Date, the CA SHALL NOT issue a > certificate with an Expiry Date later than 1 November 2015 with a > subjectAlternativeName extension or Subject commonName field > containing a Reserved IP Address or Internal Name. Effective 1 October > 2016, CAs SHALL revoke all unexpired Certificates whose > subjectAlternativeName extension or Subject commonName field contains > a Reserved IP Address or Internal Name. _Effective May 1, 2015, each > CA SHALL revoke all unexpired Certificates with an Internal Name using > onion as the right-most label in an entry in the subjectAltName > Extension or commonName field unless such Certificate was issued in > accordance with Appendix F of the EV Guidelines._ > > 2) Amend Section 9.2.2 and 11.7.1 of the Guidelines for the Issuance > and Management of Extended Validation Certificates v1.5.2 as follows: > > 9.2.2. Subject Alternative Name Extension Certificate field: > subjectAltName:dNSName > > Required/Optional: Required > > Contents: This extension MUST contain one or more host Domain Name(s) > owned or controlled by the Subject and to be associated with the > Subject?s server. Such server MAY be owned and operated by the Subject > or another entity (e.g., a hosting service). Wildcard certificates are > not allowed for EV Certificates_except as permitted under Appendix F_. > > 11.7 Verification of Applicant?s Domain Name > > 11.7.1. Verification Requirements > > (1) For each Fully-Qualified Domain Name listed in a Certificate, > other than a Domain Name with .onion in the right-most label of the > Domain Name, the CA SHALL confirm that, as of the date the Certificate > was issued, the Applicant (or the Applicant?s Parent Company, > Subsidiary Company, or Affiliate, collectively referred to as > ?Applicant? for the purposes of this section) either is the Domain > Name Registrant or has control over the FQDN using a procedure > specified in Section 11.1.1 of the Baseline Requirements, except that > a CA MAY NOT verify a domain using the procedure described 11.1.1(7). > _For a Certificate issued to a Domain Name with .onion in the > right-most label of the Domain Name, the CA SHALL confirm that, as of > the date the Certificate was issued, the Applicant?s control over the > .onion Domain Name in accordance with Appendix F._ > > (2) Mixed Character Set Domain Names: EV Certificates MAY include > Domain Names containing mixed character sets only in compliance with > the rules set forth by the domain registrar. The CA MUST visually > compare any Domain Names with mixed character sets with known high > risk domains. If a similarity is found, then the EV Certificate > Request MUST be flagged as High Risk. The CA must perform reasonably > appropriate additional authentication and verification to be certain > beyond reasonable doubt that the Applicant and the target in question > are the same organization. > > 3) Add a new Appendix F to the Guidelines for the Issuance and > Management of Extended Validation Certificates v1.5.2: > > Appendix F ? Issuance of Certificates for .onion Domain Names > > A CA may issue an EV Certificate with .onion in the right-most label > of the Domain Name provided that issuance complies with the > requirements set forth in this Appendix: > > 1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) > > The CAB Forum has created an extension of the TBSCertificate for use > in conveying hashes of keys related to .onion addresses. The Tor > Service Descriptor Hash extension has the following format: > > cabf-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 } > > TorServiceDescriptorSyntax ::= > > SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash > > TorServiceDescriptorHash:: = SEQUENCE { > > onionURI UTF8String > > algorithm AlgorithmIdentifier > > subjectPublicKeyHash BIT STRING } > > Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC > 6234) performed over the DER-encoding of an ASN.1 SubjectPublicKey of > the .onion service and SubjectPublicKeyHash is the hash output. > > 2. The CA MUST verify the Applicant?s control over the .onion Domain > Name using one of the following: > > a. The CA MAY verify the Applicant?s control over the .onion service > by posting a specific value at a well-known URL under RFC5785. > > b. The CA MAY verify the Applicant?s control over the .onion service > by having the Applicant provide a Certificate Request signed using the > .onion public key if the Attributes section of the > certificationRequestInfo contains: > > (i) A caSigningNonce attribute that 1) contains a single value with at > least 64-bits of entropy, 2) is generated by the CA, and 3) delivered > to the Applicant through a Verified Method of Communication and > > (ii) An applicantSigningNonce attribute that 1) contains a single > value with at least 64-bits of entropy and 2) is generated by the > Applicant. > > The signing nonce attributes have the following format: > > caSigningNonce ATTRIBUTE ::= { > > WITH SYNTAX OCTET STRING > > EQUALITY MATCHING RULE octetStringMatch > > SINGLE VALUE TRUE > > ID { cabf-caSigningNonce } > > } > > cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } > > applicantSigningNonce ATTRIBUTE ::= { > > WITH SYNTAX OCTET STRING > > EQUALITY MATCHING RULE octetStringMatch > > SINGLE VALUE TRUE > > ID { cabf-applicantSigningNonce } > > } > > cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 } > > 4. Each Certificate that includes a Domain Name where .onion is in the > right-most label of the Domain Name MUST conform to the requirements > of these Guidelines, including the content requirements in Section 9 > and Appendix B of the Baseline Requirements, except that the CA MAY > include a wildcard character in the Subject Alternative Name Extension > and Subject Common Name Field as the left-most character in the .onion > Domain Name provided inclusion of the wildcard character complies with > Section 11.1.3 of the Baseline Requirements. > > 5. CAs MUST NOT issue a Certificate that includes a Domain Name where > .onion is in the right-most label of the Domain Name with a validity > period longer than 15 months. Despite Section 9.2.1 of the Baseline > Requirements deprecating the use of Internal Names, a CA MAY issue a > Certificate containing an .onion name with an expiration date later > than 1 November 2015 after (and only if) .onion is officially > recognized by the IESG as a reserved TLD. > > 6. On or before May 1, 2015, each CA MUST revoke all Certificates > issued with the Subject Alternative Name extension or Common Name > field that includes a Domain Name where .onion is in the right-most > label of the Domain Name unless the Certificate was issued in > compliance with this Appendix F. > > ---- > > Motion Ends > > ----- > > The review period for this ballot shall commence at 2200 UTC on > Thursday, 4 February 2015, and will close at 2200 UTC on Thursday, 11 > February 2015. Unless the motion is withdrawn during the review > period, the voting period will start immediately thereafter and will > close at 2200 UTC on Monday, 18 February 2015. Votes must be cast by > posting an on-list reply to this thread. > > A vote in favor of the motion must indicate a clear 'yes' in the > response. A vote against must indicate a clear 'no' in the response. A > vote to abstain must indicate a clear 'abstain' in the response. > Unclear responses will not be counted. The latest vote received from > any representative of a voting member before the close of the voting > period will be counted. Voting members are listed here: > https://cabforum.org/members/ > > In order for the motion to be adopted, two thirds or more of the votes > cast by members in the CA category and greater than 50% of the votes > cast by members in the browser category must be in favor. Quorum is > currently nine (9) members? at least nine members must participate in > the ballot, either by voting in favor, voting against, or abstaining. > > > > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public -------------- next part -------------- An HTML attachment was scrubbed... URL: From sleevi at google.com Wed Feb 18 22:00:41 2015 From: sleevi at google.com (Ryan Sleevi) Date: Wed, 18 Feb 2015 14:00:41 -0800 Subject: [cabfpub] Preballot for IPv6 Support In-Reply-To: References: Message-ID: In advance of tomorrow's call, I'd like to bring forward this pre-ballot again ---MOTION BEGINS--- Update Section 13.2.1 of the Baseline Requirements as follows: From: "The CA SHALL make revocation information for Subordinate Certificates and Subscriber Certificates available in accordance with Appendix B." To: "The CA SHALL make revocation information for Subordinate Certificates and Subscriber Certificates available in accordance with Appendix B. Effective March 1, 2016, the CA SHALL make this information available via both IPv4 and IPv6. For each DNS host included in accordance with Appendix B, lookups to the authoritative resolver MUST return valid A records if A records are requested and valid AAAA records if AAAA records are requested." Update Appendix B, Section 2(b) of the Baseline Requirements as follows: From: "This extension MUST be present and MUST NOT be marked critical. It MUST contain the HTTP URL of the CA?s CRL service." To: "This extension MUST be present and MUST NOT be marked critical. It MUST contain the HTTP URL of the CA?s CRL service. See Section 13.2.1 for details." ---MOTION ENDS--- The key changes from the previous pre-ballot are the wording changes suggested by Brian Smith, and attaching a concrete date - 1 year from now. From gerv at mozilla.org Thu Feb 19 10:11:59 2015 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 19 Feb 2015 10:11:59 +0000 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names In-Reply-To: <54E4E300.3050303@opentrust.com> References: <54E4E300.3050303@opentrust.com> Message-ID: <54E5B6EF.3000009@mozilla.org> Hi Erwann, On 18/02/15 19:07, Erwann Abalea wrote: > OpenTrust votes NO. >From reading your objections: does this mean you would be in favour after the Tor folk move to longer hashes and SHA-256? > * the final goal of this ballot is to allow a Tor user to access a non > hidden service using a hidden service name. Such a user can > *already* access to the public facing classical version of this > service, using its public name. Yes; however, people in the middle can both tell that the user is accessing the site, and can block their access. Gerv From Dean_Coclin at symantec.com Thu Feb 19 15:39:36 2015 From: Dean_Coclin at symantec.com (Dean Coclin) Date: Thu, 19 Feb 2015 07:39:36 -0800 Subject: [cabfpub] Ballot 143, 144 results Message-ID: <14D026C7F297AD44AC82578DD818CDD038EF343757@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> On Ballot 143, Formation of Validation Working Group, I counted 22 Yes votes, 0 No votes , 0 Abstentions from the CAs and 4 Yes votes from the browsers. Therefore, the ballot passes. On Ballot 144, Issuance to .Onion domains, I counted 6 Yes votes, 2 No votes and 13 Abstentions from the CAs and 3 Yes votes from the browsers. Therefore, the ballot passes. Detailed results are on the wiki ballot tracker. The Chair directs that the name of the working group be updated to the Validation Working Group and requests that Ben Wilson update the wiki and website to reflect this. The group's new charter should reflect the ballot results. Further, I ask that Jeremy update the EV Guidelines to adjust for Ballot 144 as appropriate (per the ballot). Thank you, Dean Coclin -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6130 bytes Desc: not available URL: From jeremy.rowley at digicert.com Thu Feb 19 15:43:43 2015 From: jeremy.rowley at digicert.com (Jeremy Rowley) Date: Thu, 19 Feb 2015 15:43:43 +0000 Subject: [cabfpub] Ballot 145 - Operational Existence for Government Entities Message-ID: Ballot 145 - Operational Existence for Government Entities ________________________________ Reason ________________________________ Because government entities aren't operating as businesses, they are often not listed with a QIIS, especially immediately after the entity is created by either statute or order. The legal existence of these entities is verifiable through a QGIS, but this source in many countries (especially Arabic and African countries) does not always list a date of creation of these entities. Operational existence exists to ensure organizations aren't fly-by-night scams/phishing entities. With government entities, these same risks are not present as they are created directly by government action. Jeremy Rowley of DigiCert made the following motion, which was endorsed by Rich Smith of Comodo and Cecilia Kam of Symantec. ________________________________ Motion begins ________________________________ Effective immediately, section 11.6.1 is modified as follows: 11.6.1 Verification Requirements. The CA MUST verify that the Applicant has the ability to engage in business by verifying the Applicant's, or Affiliate/Parent/Subsidiary Company's, operational existence. The CA MAY rely on its verification of a Government Entity's legal existence under Section 11.2 as verification of a Government Entity's operational existence. ________________________________ Motion Ends ________________________________ The review period for this ballot shall commence at 2200 UTC on 19 Feb 2015, and will close at 2200 UTC on 26 Feb 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on 5 Mar 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wthayer at godaddy.com Thu Feb 19 16:54:28 2015 From: wthayer at godaddy.com (Wayne Thayer) Date: Thu, 19 Feb 2015 16:54:28 +0000 Subject: [cabfpub] Preballot for IPv6 Support In-Reply-To: References: Message-ID: Ryan, We didn't find any blockers that prevent GoDaddy from enabling support for IPv6. Like other CAs, we also don't see any demand for it today, but I agree that this is a collective action problem and CAs need to remove certificate validation from the list of problems that are blocking other parties from moving to IPv6. GoDaddy supports this ballot and I would be happy to endorse. Thanks, Wayne -----Original Message----- From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ryan Sleevi Sent: Wednesday, February 18, 2015 3:01 PM To: CABFPub Subject: Re: [cabfpub] Preballot for IPv6 Support In advance of tomorrow's call, I'd like to bring forward this pre-ballot again ---MOTION BEGINS--- Update Section 13.2.1 of the Baseline Requirements as follows: From: "The CA SHALL make revocation information for Subordinate Certificates and Subscriber Certificates available in accordance with Appendix B." To: "The CA SHALL make revocation information for Subordinate Certificates and Subscriber Certificates available in accordance with Appendix B. Effective March 1, 2016, the CA SHALL make this information available via both IPv4 and IPv6. For each DNS host included in accordance with Appendix B, lookups to the authoritative resolver MUST return valid A records if A records are requested and valid AAAA records if AAAA records are requested." Update Appendix B, Section 2(b) of the Baseline Requirements as follows: From: "This extension MUST be present and MUST NOT be marked critical. It MUST contain the HTTP URL of the CA?s CRL service." To: "This extension MUST be present and MUST NOT be marked critical. It MUST contain the HTTP URL of the CA?s CRL service. See Section 13.2.1 for details." ---MOTION ENDS--- The key changes from the previous pre-ballot are the wording changes suggested by Brian Smith, and attaching a concrete date - 1 year from now. _______________________________________________ Public mailing list Public at cabforum.org https://cabforum.org/mailman/listinfo/public From kirk_hall at trendmicro.com Thu Feb 19 16:59:51 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Thu, 19 Feb 2015 16:59:51 +0000 Subject: [cabfpub] When did the WebTrust/ETSI BR audit requirement become mandatory? Message-ID: On our Forum call today, we asked when a WebTrust/ETSI BR audit requirement become mandatory for CAs. Ballot 62 (Nov. 2011) adopted the BRs effective July 1, 2012. However, there were no audit criteria in place for some time. I did some quick research, and the answer is not clear as to when the audit criteria came into effect. The WebTrust draft audit requirements were completed by early 2013, and I see comments that Mozilla adopted the BR audit as a program requirement at the Mountain View meeting in Feb. 2013. Here is the current Mozilla requirement at Sec. 11: https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ As I recall, the initial Mozilla BR audit requirement was not clear as to exact effective date (what operational period must be covered by a CA's initial BR audit). I vaguely recall Mozilla clarifying the rule at our Feb. 2013 meeting at Mountain View that all CA operations occurring on or after Feb. 15, 2013 must be covered by a BR audit - so some CAs did partial-year initial BR audits to align their BR audits with their other audits. Based on all this, I would say all CAs should have full year BR audits in place by now. We can change our Bylaw on membership at Bylaw 2.1 to reflect this. Kirk R. Hall Operations Director, Trust Services Trend Micro +1.503.753.3088 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
-------------- next part -------------- An HTML attachment was scrubbed... URL: From gerv at mozilla.org Thu Feb 19 17:33:27 2015 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 19 Feb 2015 17:33:27 +0000 Subject: [cabfpub] When did the WebTrust/ETSI BR audit requirement become mandatory? In-Reply-To: References: Message-ID: <54E61E67.6090409@mozilla.org> On 19/02/15 16:59, kirk_hall at trendmicro.com wrote: > Based on all this, I would say all CAs should have full year BR audits > in place by now. We can change our Bylaw on membership at Bylaw 2.1 to > reflect this. I agree with the former, but let me challenge for a moment whether it directly implies the goodness of the latter. Why do we have membership criteria at all? I would say that it's solely to prevent people or organizations signing up as members who are not actually doing things the forum concerns itself with. Therefore, our membership criteria should be as wide as possible consistent with that goal. We currently require a WebTrust or ETSI scheme audit. I think it's unlikely that an organization will seek and pay for such a thing unless they are actually a CA. So I would say our membership criteria are already rigorous enough. To put it another way: Mozilla's root program requirements are not the same thing as CAB Forum membership criteria. I suspect that a new CA won't get very far in practice without a BR audit, but the CAB Forum should not be judging the business model viability of potential members as a condition of membership. That seems a dangerous road to me. Gerv From kirk_hall at trendmicro.com Thu Feb 19 18:28:44 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Thu, 19 Feb 2015 18:28:44 +0000 Subject: [cabfpub] When did the WebTrust/ETSI BR audit requirement become mandatory? In-Reply-To: <54E61E67.6090409@mozilla.org> References: <54E61E67.6090409@mozilla.org> Message-ID: I partially agree, but I would put it this way: CA membership requirements are intended to make sure an applicant is a "real" CA. Today, both Mozilla and Microsoft require a CA to have a Baseline Requirements audit for its roots to be included in the trusted root store. Here is the Microsoft link: http://social.technet.microsoft.com/wiki/contents/articles/26675.windows-root-certificate-program-audit-requirements-for-cas.aspx Plus, the CA-Browser Forum itself requires all CAs to follow the BRs for their certs to be considered trustworthy (except that the Forum has no enforcement power ? that is left to the browsers through their root program requirements): These Baseline Requirements describe an integrated set of technologies, protocols, identity-proofing, lifecycle management, and auditing requirements that are necessary (but not sufficient) for the issuance and management of Publicly-Trusted Certificates; Certificates that are trusted by virtue of the fact that their corresponding Root Certificate is distributed in widely-available application software. The Requirements are not mandatory for Certification Authorities unless and until they become adopted and enforced by relying?party Application Software Suppliers. *** 1. Scope The Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates describe a subset of the requirements that a Certification Authority must meet in order to issue Publicly Trusted Certificates. Except where explicitly stated otherwise, these requirements apply only to relevant events that occur on or after the Effective Date. *** These Requirements are applicable to all Certification Authorities within a chain of trust. They are to be flowed down from the Root Certification Authority through successive Subordinate Certification Authorities. 2. Purpose The primary goal of these Requirements is to enable efficient and secure electronic communication, while addressing user concerns about the trustworthiness of Certificates. The Requirements also serve to inform users and help them to make informed decisions when relying on Certificates. No CA is required to join the Forum to operate ? the CAs only need to satisfy the browsers. But I can?t think of any reason why a CA would choose NOT to follow the BRs and get a BR audit if it wants to be considered a ?real? CA. And I don?t think the Forum would want to accept any new CA member that said ?I choose not to follow the BRs, and I choose not to get a BR audit? ? why would we want such a CA as a member? So it seems reasonable to update our bylaws to require a BR audit for membership. -----Original Message----- From: Gervase Markham [mailto:gerv at mozilla.org] Sent: Thursday, February 19, 2015 9:33 AM To: Kirk Hall (RD-US); CABFPub (public at cabforum.org) Subject: Re: [cabfpub] When did the WebTrust/ETSI BR audit requirement become mandatory? On 19/02/15 16:59, kirk_hall at trendmicro.com wrote: > Based on all this, I would say all CAs should have full year BR audits > in place by now. We can change our Bylaw on membership at Bylaw 2.1 > to reflect this. I agree with the former, but let me challenge for a moment whether it directly implies the goodness of the latter. Why do we have membership criteria at all? I would say that it's solely to prevent people or organizations signing up as members who are not actually doing things the forum concerns itself with. Therefore, our membership criteria should be as wide as possible consistent with that goal. We currently require a WebTrust or ETSI scheme audit. I think it's unlikely that an organization will seek and pay for such a thing unless they are actually a CA. So I would say our membership criteria are already rigorous enough. To put it another way: Mozilla's root program requirements are not the same thing as CAB Forum membership criteria. I suspect that a new CA won't get very far in practice without a BR audit, but the CAB Forum should not be judging the business model viability of potential members as a condition of membership. That seems a dangerous road to me. Gerv 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
-------------- next part -------------- An HTML attachment was scrubbed... URL: From erwann.abalea at opentrust.com Thu Feb 19 18:44:47 2015 From: erwann.abalea at opentrust.com (Erwann Abalea) Date: Thu, 19 Feb 2015 19:44:47 +0100 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names In-Reply-To: <54E5B6EF.3000009@mozilla.org> References: <54E4E300.3050303@opentrust.com> <54E5B6EF.3000009@mozilla.org> Message-ID: <54E62F1F.9000109@opentrust.com> Bonjour Gerv, Le 19/02/2015 11:11, Gervase Markham a ?crit : > Hi Erwann, > > On 18/02/15 19:07, Erwann Abalea wrote: >> OpenTrust votes NO. > From reading your objections: does this mean you would be in favour > after the Tor folk move to longer hashes and SHA-256? Longer hashes may not be necessary, we lived with a 2^80 theoretical effort (collision resistance of a perfect hash function) for a while, and recently deprecated SHA1. But what was really deprecated? SHA1 in itself because it's old, despite its 2^160 resistance for intermediate certificates and CRLs? The idea of a 2^80 collision resistance? The latest estimated 2^61 collision resistance of SHA1? There was a reason to deprecate SHA1, there are consequences (we all heard of them and decided to drop legacy software, for good), there's a design behind our choices (or there should be). How does this truncated SHA1 fit this design? The other technical objection is that Tor is *full* of keys, and the vast majority of them are 1024 bits RSA keys. Some keys are ECC Curve25519 ones, but I don't know if they're used for signature or key exchange purpose. There are keys used to generate names, keys used to encrypt data exchanged between cells, keys used to sign distributed data, keys used to sign descriptor informations published by services, keys used to setup rendez-vous tokens to access hidden services, and maybe others. Keys smaller than 2048 bits are Evil(tm). It's written in stone, we track public 1024bits certificates and sue the CAs who produced them, we don't like DNSSEC partly because it's also full of 1024 bits keys. That's good, I'm fine with it. I'm not opposed to embrace Tor or any other similar security thing in CABForum's definition of a TLS certificate, but I'd like to be sure that we all know what is being introduced, the security consequences and guarantees of what we're doing. I really like Tor. But understanding Tor is hard, and I wouldn't be surprised if a non negligible number of the "abstain" votes was caused by this complexity. >> * the final goal of this ballot is to allow a Tor user to access a non >> hidden service using a hidden service name. Such a user can >> *already* access to the public facing classical version of this >> service, using its public name. > Yes; however, people in the middle can both tell that the user is > accessing the site, and can block their access. Tor is supposedly targeted for this situation. The exit node knows that someone wants to access the site and block it, the entry node knows that this specific user wants to access something and block it, but not both. In theory. From my understanding, accessing a Tor hidden service involves a longer path (3 nodes between the user and a rendezvous point, 3 nodes from this rendezvous point and the service), provides end-to-end encryption, and self-authentication. That's good. Does it solve the anonymity problem? Yes, for a hidden service. How does it work for a mixed hidden/non-hidden service? -- Erwann ABALEA From philliph at comodo.com Thu Feb 19 18:53:26 2015 From: philliph at comodo.com (Phillip Hallam-Baker) Date: Thu, 19 Feb 2015 13:53:26 -0500 Subject: [cabfpub] Lenovo installation of malicious root. Message-ID: <9CB5BBD9-58FA-4DC2-90E0-70F01911A4AC@comodo.com> I am sure many of you have seen this. If not you will, I have had a dozen people ping me about it in the past hour. https://www.eff.org/deeplinks/2015/02/further-evidence-lenovo-breaking-https-security-its-laptops Someone has to draw the line here or the politicians will do it for us. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Rick_Andrews at symantec.com Thu Feb 19 19:25:46 2015 From: Rick_Andrews at symantec.com (Rick Andrews) Date: Thu, 19 Feb 2015 11:25:46 -0800 Subject: [cabfpub] Preballot for IPv6 Support In-Reply-To: References: Message-ID: <544B0DD62A64C1448B2DA253C01141460BD3E573A0@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> Ryan, It seems to me we need to add one more detail: it must be possible to make the lookups to the authoritative resolver (DNS) over IPv4 and IPv6. A client running on an IPv6-only network will first make a DNS call to get the AAAA record for the CA's OCSP or CRL service. So the CA needs to make sure that those DNS lookups can be served via IPv6. -Rick -----Original Message----- From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Wayne Thayer Sent: Thursday, February 19, 2015 8:54 AM To: CABFPub Subject: Re: [cabfpub] Preballot for IPv6 Support Ryan, We didn't find any blockers that prevent GoDaddy from enabling support for IPv6. Like other CAs, we also don't see any demand for it today, but I agree that this is a collective action problem and CAs need to remove certificate validation from the list of problems that are blocking other parties from moving to IPv6. GoDaddy supports this ballot and I would be happy to endorse. Thanks, Wayne -----Original Message----- From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ryan Sleevi Sent: Wednesday, February 18, 2015 3:01 PM To: CABFPub Subject: Re: [cabfpub] Preballot for IPv6 Support In advance of tomorrow's call, I'd like to bring forward this pre-ballot again ---MOTION BEGINS--- Update Section 13.2.1 of the Baseline Requirements as follows: From: "The CA SHALL make revocation information for Subordinate Certificates and Subscriber Certificates available in accordance with Appendix B." To: "The CA SHALL make revocation information for Subordinate Certificates and Subscriber Certificates available in accordance with Appendix B. Effective March 1, 2016, the CA SHALL make this information available via both IPv4 and IPv6. For each DNS host included in accordance with Appendix B, lookups to the authoritative resolver MUST return valid A records if A records are requested and valid AAAA records if AAAA records are requested." Update Appendix B, Section 2(b) of the Baseline Requirements as follows: From: "This extension MUST be present and MUST NOT be marked critical. It MUST contain the HTTP URL of the CA?s CRL service." To: "This extension MUST be present and MUST NOT be marked critical. It MUST contain the HTTP URL of the CA?s CRL service. See Section 13.2.1 for details." ---MOTION ENDS--- The key changes from the previous pre-ballot are the wording changes suggested by Brian Smith, and attaching a concrete date - 1 year from now. _______________________________________________ Public mailing list Public at cabforum.org https://cabforum.org/mailman/listinfo/public _______________________________________________ Public mailing list Public at cabforum.org https://cabforum.org/mailman/listinfo/public From sleevi at google.com Thu Feb 19 20:11:27 2015 From: sleevi at google.com (Ryan Sleevi) Date: Thu, 19 Feb 2015 12:11:27 -0800 Subject: [cabfpub] Preballot for IPv6 Support In-Reply-To: <544B0DD62A64C1448B2DA253C01141460BD3E573A0@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> References: <544B0DD62A64C1448B2DA253C01141460BD3E573A0@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> Message-ID: Good point. What good is server a AAAA record from a DNS server that doesn't listen on IPv6 On Thu, Feb 19, 2015 at 11:25 AM, Rick Andrews wrote: > Ryan, > > It seems to me we need to add one more detail: it must be possible to make the lookups to the authoritative resolver (DNS) over IPv4 and IPv6. A client running on an IPv6-only network will first make a DNS call to get the AAAA record for the CA's OCSP or CRL service. So the CA needs to make sure that those DNS lookups can be served via IPv6. > > -Rick > > -----Original Message----- > From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Wayne Thayer > Sent: Thursday, February 19, 2015 8:54 AM > To: CABFPub > Subject: Re: [cabfpub] Preballot for IPv6 Support > > Ryan, > > We didn't find any blockers that prevent GoDaddy from enabling support for IPv6. Like other CAs, we also don't see any demand for it today, but I agree that this is a collective action problem and CAs need to remove certificate validation from the list of problems that are blocking other parties from moving to IPv6. GoDaddy supports this ballot and I would be happy to endorse. > > Thanks, > > Wayne > > -----Original Message----- > From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ryan Sleevi > Sent: Wednesday, February 18, 2015 3:01 PM > To: CABFPub > Subject: Re: [cabfpub] Preballot for IPv6 Support > > In advance of tomorrow's call, I'd like to bring forward this pre-ballot again > > ---MOTION BEGINS--- > > Update Section 13.2.1 of the Baseline Requirements as follows: > > From: > "The CA SHALL make revocation information for Subordinate Certificates and Subscriber Certificates available in accordance with Appendix B." > > To: > > "The CA SHALL make revocation information for Subordinate Certificates and Subscriber Certificates available in accordance with Appendix B. > > Effective March 1, 2016, the CA SHALL make this information available via both IPv4 and IPv6. For each DNS host included in accordance with Appendix B, lookups to the authoritative resolver MUST return valid A records if A records are requested and valid AAAA records if AAAA records are requested." > > Update Appendix B, Section 2(b) of the Baseline Requirements as follows: > > From: > "This extension MUST be present and MUST NOT be marked critical. It MUST contain the HTTP URL of the CA?s CRL service." > > To: > "This extension MUST be present and MUST NOT be marked critical. It MUST contain the HTTP URL of the CA?s CRL service. See Section 13.2.1 for details." > > ---MOTION ENDS--- > > The key changes from the previous pre-ballot are the wording changes suggested by Brian Smith, and attaching a concrete date - 1 year from now. > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public From geoffk at apple.com Thu Feb 19 20:50:56 2015 From: geoffk at apple.com (Geoff Keating) Date: Thu, 19 Feb 2015 12:50:56 -0800 Subject: [cabfpub] Preballot for IPv6 Support In-Reply-To: References: <544B0DD62A64C1448B2DA253C01141460BD3E573A0@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> Message-ID: <6F77FE02-17AB-48F7-BFFB-59634699FA28@apple.com> > On 19 Feb 2015, at 12:11 pm, Ryan Sleevi wrote: > > Good point. What good is server a AAAA record from a DNS server that > doesn't listen on IPv6 An IPv6-only client can use a recursive DNS server which has both IPv6 and IPv4 addresses, for example Google Public DNS or Comcast's DNS servers, so this isn't as high a priority as OCSP (but still an important step). -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4103 bytes Desc: not available URL: From philliph at comodo.com Thu Feb 19 23:41:07 2015 From: philliph at comodo.com (Phillip Hallam-Baker) Date: Thu, 19 Feb 2015 18:41:07 -0500 Subject: [cabfpub] Preballot for IPv6 Support In-Reply-To: References: <544B0DD62A64C1448B2DA253C01141460BD3E573A0@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> Message-ID: <17B2AFA3-EAF1-4439-8CA3-49ECF5AD2200@comodo.com> Actually it would work fine since an IPv6 client would not talk to the authoritative directly anyway, it would go through a recursive that is probably dual stack unless you are playing the DNS64 game. > On Feb 19, 2015, at 3:11 PM, Ryan Sleevi wrote: > > Good point. What good is server a AAAA record from a DNS server that > doesn't listen on IPv6 > > On Thu, Feb 19, 2015 at 11:25 AM, Rick Andrews > wrote: >> Ryan, >> >> It seems to me we need to add one more detail: it must be possible to make the lookups to the authoritative resolver (DNS) over IPv4 and IPv6. A client running on an IPv6-only network will first make a DNS call to get the AAAA record for the CA's OCSP or CRL service. So the CA needs to make sure that those DNS lookups can be served via IPv6. >> >> -Rick >> >> -----Original Message----- >> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Wayne Thayer >> Sent: Thursday, February 19, 2015 8:54 AM >> To: CABFPub >> Subject: Re: [cabfpub] Preballot for IPv6 Support >> >> Ryan, >> >> We didn't find any blockers that prevent GoDaddy from enabling support for IPv6. Like other CAs, we also don't see any demand for it today, but I agree that this is a collective action problem and CAs need to remove certificate validation from the list of problems that are blocking other parties from moving to IPv6. GoDaddy supports this ballot and I would be happy to endorse. >> >> Thanks, >> >> Wayne >> >> -----Original Message----- >> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ryan Sleevi >> Sent: Wednesday, February 18, 2015 3:01 PM >> To: CABFPub >> Subject: Re: [cabfpub] Preballot for IPv6 Support >> >> In advance of tomorrow's call, I'd like to bring forward this pre-ballot again >> >> ---MOTION BEGINS--- >> >> Update Section 13.2.1 of the Baseline Requirements as follows: >> >> From: >> "The CA SHALL make revocation information for Subordinate Certificates and Subscriber Certificates available in accordance with Appendix B." >> >> To: >> >> "The CA SHALL make revocation information for Subordinate Certificates and Subscriber Certificates available in accordance with Appendix B. >> >> Effective March 1, 2016, the CA SHALL make this information available via both IPv4 and IPv6. For each DNS host included in accordance with Appendix B, lookups to the authoritative resolver MUST return valid A records if A records are requested and valid AAAA records if AAAA records are requested." >> >> Update Appendix B, Section 2(b) of the Baseline Requirements as follows: >> >> From: >> "This extension MUST be present and MUST NOT be marked critical. It MUST contain the HTTP URL of the CA?s CRL service." >> >> To: >> "This extension MUST be present and MUST NOT be marked critical. It MUST contain the HTTP URL of the CA?s CRL service. See Section 13.2.1 for details." >> >> ---MOTION ENDS--- >> >> The key changes from the previous pre-ballot are the wording changes suggested by Brian Smith, and attaching a concrete date - 1 year from now. >> _______________________________________________ >> Public mailing list >> Public at cabforum.org >> https://cabforum.org/mailman/listinfo/public >> _______________________________________________ >> Public mailing list >> Public at cabforum.org >> https://cabforum.org/mailman/listinfo/public >> _______________________________________________ >> Public mailing list >> Public at cabforum.org >> https://cabforum.org/mailman/listinfo/public > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public From sleevi at google.com Thu Feb 19 23:42:55 2015 From: sleevi at google.com (Ryan Sleevi) Date: Thu, 19 Feb 2015 15:42:55 -0800 Subject: [cabfpub] Preballot for IPv6 Support In-Reply-To: <17B2AFA3-EAF1-4439-8CA3-49ECF5AD2200@comodo.com> References: <544B0DD62A64C1448B2DA253C01141460BD3E573A0@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <17B2AFA3-EAF1-4439-8CA3-49ECF5AD2200@comodo.com> Message-ID: On Thu, Feb 19, 2015 at 3:41 PM, Phillip Hallam-Baker wrote: > Actually it would work fine since an IPv6 client would not talk to the authoritative directly anyway, it would go through a recursive that is probably dual stack unless you are playing the DNS64 game. In theory, yes. In practice, no. I know what the RFCs say. I also know that RFCs are invitations for users to go buckwild and do their own thing :) Rather than worry about the many weird and wild ways in which users, enterprises, and network operators configure things, I think being explicit here on the expectations of infrastructure is the best solution for all. From i-barreira at izenpe.net Fri Feb 20 07:33:17 2015 From: i-barreira at izenpe.net (i-barreira at izenpe.net) Date: Fri, 20 Feb 2015 08:33:17 +0100 Subject: [cabfpub] When did the WebTrust/ETSI BR audit requirement becomemandatory? Message-ID: <763539E260C37C46A0D6B340B5434C3B0ADAED2D@AEX06.ejsarea.net> Kirk, From the ETSI side, you know that the CAs that want to be ETSI audited according to the BRs can do it according to the TS 102 042 v 2.4.1 which is effective since February 2013. OTOH mandating the CAs to be certified against ETSI, up to the regulation, that was on a voluntary basis. The regulation was approved last year and it mandates the certification (not decided yet which ones) for those service providers that want to issue qualified services and become a Qualified TSP by July 2016 with a year to send the conformity assessment to the supervisory body. So, the answer is that by July 2016 (having a year to do so) all TSPs that issue qualified certificates and are ?under? the regulation shall be certified, probably against ETSI standards like the new ENs. I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. De: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] En nombre de kirk_hall at trendmicro.com Enviado el: jueves, 19 de febrero de 2015 18:00 Para: CABFPub (public at cabforum.org) Asunto: [cabfpub] When did the WebTrust/ETSI BR audit requirement becomemandatory? On our Forum call today, we asked when a WebTrust/ETSI BR audit requirement become mandatory for CAs. Ballot 62 (Nov. 2011) adopted the BRs effective July 1, 2012. However, there were no audit criteria in place for some time. I did some quick research, and the answer is not clear as to when the audit criteria came into effect. The WebTrust draft audit requirements were completed by early 2013, and I see comments that Mozilla adopted the BR audit as a program requirement at the Mountain View meeting in Feb. 2013. Here is the current Mozilla requirement at Sec. 11: https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ As I recall, the initial Mozilla BR audit requirement was not clear as to exact effective date (what operational period must be covered by a CA?s initial BR audit). I vaguely recall Mozilla clarifying the rule at our Feb. 2013 meeting at Mountain View that all CA operations occurring on or after Feb. 15, 2013 must be covered by a BR audit ? so some CAs did partial-year initial BR audits to align their BR audits with their other audits. Based on all this, I would say all CAs should have full year BR audits in place by now. We can change our Bylaw on membership at Bylaw 2.1 to reflect this. Kirk R. Hall Operations Director, Trust Services Trend Micro +1.503.753.3088 TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 19121 bytes Desc: image001.png URL: From rob.stradling at comodo.com Fri Feb 20 09:37:04 2015 From: rob.stradling at comodo.com (Rob Stradling) Date: Fri, 20 Feb 2015 09:37:04 +0000 Subject: [cabfpub] Preballot for IPv6 Support In-Reply-To: References: Message-ID: <54E70040.2050203@comodo.com> On 19/02/15 16:54, Wayne Thayer wrote: > Like other CAs, we also don't see any demand for it today, but I agree that this is a collective action problem and CAs need to remove certificate validation from the list of problems that are blocking other parties from moving to IPv6. GoDaddy supports this ballot and I would be happy to endorse. +1 Ryan, I would also be happy to endorse this ballot on behalf of Comodo. > Thanks, > > Wayne > > -----Original Message----- > From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ryan Sleevi > Sent: Wednesday, February 18, 2015 3:01 PM > To: CABFPub > Subject: Re: [cabfpub] Preballot for IPv6 Support > > In advance of tomorrow's call, I'd like to bring forward this pre-ballot again > > ---MOTION BEGINS--- > > Update Section 13.2.1 of the Baseline Requirements as follows: > > From: > "The CA SHALL make revocation information for Subordinate Certificates and Subscriber Certificates available in accordance with Appendix B." > > To: > > "The CA SHALL make revocation information for Subordinate Certificates and Subscriber Certificates available in accordance with Appendix B. > > Effective March 1, 2016, the CA SHALL make this information available via both IPv4 and IPv6. For each DNS host included in accordance with Appendix B, lookups to the authoritative resolver MUST return valid A records if A records are requested and valid AAAA records if AAAA records are requested." > > Update Appendix B, Section 2(b) of the Baseline Requirements as follows: > > From: > "This extension MUST be present and MUST NOT be marked critical. It MUST contain the HTTP URL of the CA?s CRL service." > > To: > "This extension MUST be present and MUST NOT be marked critical. It MUST contain the HTTP URL of the CA?s CRL service. See Section 13.2.1 for details." > > ---MOTION ENDS--- > > The key changes from the previous pre-ballot are the wording changes suggested by Brian Smith, and attaching a concrete date - 1 year from now. > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. From i-barreira at izenpe.net Fri Feb 20 09:54:51 2015 From: i-barreira at izenpe.net (i-barreira at izenpe.net) Date: Fri, 20 Feb 2015 10:54:51 +0100 Subject: [cabfpub] issues with DNSSEC Message-ID: <763539E260C37C46A0D6B340B5434C3B0AE7E2B1@AEX06.ejsarea.net> Hi, It affects BIND with DNSSEC validation https://kb.isc.org/article/AA-01235/74/CVE-2015-1349%3A-A-Problem-with-Trust-Anchor-Management-Can-Cause-named-to-Crash.html Regards I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 19121 bytes Desc: image001.png URL: From kirk_hall at trendmicro.com Fri Feb 20 16:51:39 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Fri, 20 Feb 2015 16:51:39 +0000 Subject: [cabfpub] When did the WebTrust/ETSI BR audit requirement become mandatory? In-Reply-To: References: Message-ID: Sorry, I should have clarified. Any CA can get a point in time or ?readiness? BR audit at any time, even just before starting operations. Plus any CA can get a 60 day or 90 day performance BR audit once they start operations ? in fact, that is the recommended method (i.e., don?t wait a whole year). In general, a CA can?t start selling certs to anyone until the CA has its roots in the browsers. And the browsers won?t add the roots until they see (at least) a WebTrust and a BR readiness audit ? so there really is no blocking effect on the membership rules from requiring the audits. A CA can?t be in operation (can?t be in the browsers) until that happens. Plus ? when my new CA, AffirmTrust (acquired by Trend Micro) applied to the Forum, we had our audits but no customers yet (because at that time, the Mozilla root review process was very slow). The Forum accepted us, but only on an observer basis, not member, until we started issuing certs to customers. From: Peter Bowen [mailto:pzbowen at gmail.com] Sent: Thursday, February 19, 2015 7:14 PM To: Kirk Hall (RD-US); CABFPub (public at cabforum.org) Cc: questions at cabforum.org Subject: Re: [cabfpub] When did the WebTrust/ETSI BR audit requirement become mandatory? (copying questions@ for visibility) On Thu, Feb 19, 2015 at 8:59 AM, kirk_hall at trendmicro.com > wrote: Based on all this, I would say all CAs should have full year BR audits in place by now. We can change our Bylaw on membership at Bylaw 2.1 to reflect this. Have you considered that it is possible a new CA might want to become a member before their first anniversary of operation? If you require a full year BR audit for membership, you are effectively excluding new CAs, as they presumably will start with a point in time then a partial year audit (given the requirement to get a period of time audit started within 90 days of issuing the first certificate). 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
-------------- next part -------------- An HTML attachment was scrubbed... URL: From i-barreira at izenpe.net Fri Feb 20 18:53:44 2015 From: i-barreira at izenpe.net (=?utf-8?B?IkJhcnJlaXJhIElnbGVzaWFzLCBJw7FpZ28i?=) Date: Fri, 20 Feb 2015 19:53:44 +0100 Subject: [cabfpub] When did the WebTrust/ETSI BR audit requirement become mandatory? Message-ID: Kirk, any CA can sell certs without having any audit. It's up to the customers. It's their decission. You can add the CA manually Enviado de Samsung Mobile -------- Mensaje original -------- De: kirk_hall at trendmicro.com Fecha: Para: Peter Bowen ,"CABFPub (public at cabforum.org)" Cc: questions at cabforum.org Asunto: Re: [cabfpub] When did the WebTrust/ETSI BR audit requirement become mandatory? Sorry, I should have clarified. ? Any CA can get a point in time or ?readiness? BR audit at any time, even just before starting operations. ? Plus any CA can get a 60 day or 90 day performance BR audit once they start operations ? in fact, that is the recommended method (i.e., don?t wait a whole year). ? In general, a CA can?t start selling certs to anyone until the CA has its roots in the browsers.? And the browsers won?t add the roots until they see (at least) a WebTrust and a BR readiness audit ? so there really is no blocking effect on the membership rules from requiring the audits. ?A CA can?t be in operation (can?t be in the browsers) until that happens. ? Plus ? when my new CA, AffirmTrust (acquired by Trend Micro) applied to the Forum, we had our audits but no customers yet (because at that time, the Mozilla root review process was very slow).? The Forum accepted us, but only on an observer basis, not member, until we started issuing certs to customers. ? From: Peter Bowen [mailto:pzbowen at gmail.com] Sent: Thursday, February 19, 2015 7:14 PM To: Kirk Hall (RD-US); CABFPub (public at cabforum.org) Cc: questions at cabforum.org Subject: Re: [cabfpub] When did the WebTrust/ETSI BR audit requirement become mandatory? ? (copying questions@ for visibility) ? On Thu, Feb 19, 2015 at 8:59 AM, kirk_hall at trendmicro.com wrote: Based on all this, I would say all CAs should have full year BR audits in place by now.? We can change our Bylaw on membership at Bylaw 2.1 to reflect this. ? Have you considered that it is possible a new CA might want to become a member before their first anniversary of operation?? If you require a full year BR audit for membership, you are effectively excluding new CAs, as they presumably will start with a point in time then a partial year audit (given the requirement to get a period of time audit started within 90 days of issuing the first certificate). TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirk_hall at trendmicro.com Fri Feb 20 19:01:55 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Fri, 20 Feb 2015 19:01:55 +0000 Subject: [cabfpub] When did the WebTrust/ETSI BR audit requirement become mandatory? In-Reply-To: References: Message-ID: That?s true ? but every person visiting the site would have to do the same thing. So as a practical matter, no commercial CA will proceed in selling certs generally without its roots being in the main browser root stores, which requires completed WebTrust/ETSI audits to be delivered to the browsers. And I don?t think the Forum needs to have ?private? CA members. From: "Barreira Iglesias, I?igo" [mailto:i-barreira at izenpe.net] Sent: Friday, February 20, 2015 10:54 AM To: Kirk Hall (RD-US); Peter Bowen; public at cabforum.org Cc: questions at cabforum.org Subject: Re: [cabfpub] When did the WebTrust/ETSI BR audit requirement become mandatory? Kirk, any CA can sell certs without having any audit. It's up to the customers. It's their decission. You can add the CA manually Enviado de Samsung Mobile -------- Mensaje original -------- De: kirk_hall at trendmicro.com Fecha: Para: Peter Bowen ,"CABFPub (public at cabforum.org)" Cc: questions at cabforum.org Asunto: Re: [cabfpub] When did the WebTrust/ETSI BR audit requirement become mandatory? Sorry, I should have clarified. Any CA can get a point in time or ?readiness? BR audit at any time, even just before starting operations. Plus any CA can get a 60 day or 90 day performance BR audit once they start operations ? in fact, that is the recommended method (i.e., don?t wait a whole year). In general, a CA can?t start selling certs to anyone until the CA has its roots in the browsers. And the browsers won?t add the roots until they see (at least) a WebTrust and a BR readiness audit ? so there really is no blocking effect on the membership rules from requiring the audits. A CA can?t be in operation (can?t be in the browsers) until that happens. Plus ? when my new CA, AffirmTrust (acquired by Trend Micro) applied to the Forum, we had our audits but no customers yet (because at that time, the Mozilla root review process was very slow). The Forum accepted us, but only on an observer basis, not member, until we started issuing certs to customers. From: Peter Bowen [mailto:pzbowen at gmail.com] Sent: Thursday, February 19, 2015 7:14 PM To: Kirk Hall (RD-US); CABFPub (public at cabforum.org) Cc: questions at cabforum.org Subject: Re: [cabfpub] When did the WebTrust/ETSI BR audit requirement become mandatory? (copying questions@ for visibility) On Thu, Feb 19, 2015 at 8:59 AM, kirk_hall at trendmicro.com > wrote: Based on all this, I would say all CAs should have full year BR audits in place by now. We can change our Bylaw on membership at Bylaw 2.1 to reflect this. Have you considered that it is possible a new CA might want to become a member before their first anniversary of operation? If you require a full year BR audit for membership, you are effectively excluding new CAs, as they presumably will start with a point in time then a partial year audit (given the requirement to get a period of time audit started within 90 days of issuing the first certificate). TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
-------------- next part -------------- An HTML attachment was scrubbed... URL: From eddy_nigg at startcom.org Fri Feb 20 21:10:06 2015 From: eddy_nigg at startcom.org (Eddy Nigg) Date: Fri, 20 Feb 2015 23:10:06 +0200 Subject: [cabfpub] When did the WebTrust/ETSI BR audit requirement become mandatory? In-Reply-To: References: Message-ID: <54E7A2AE.2040501@startcom.org> On 02/20/2015 09:01 PM, kirk_hall at trendmicro.com wrote: > > That's true -- but every person visiting the site would have to do the > same thing. So as a practical matter, no commercial CA will proceed > in selling certs generally without its roots being in the main browser > root stores, which requires completed WebTrust/ETSI audits to be > delivered to the browsers. And I don't think the Forum needs to have > "private" CA members. > The forum requires a CA to be supported by at least one major browser. But it can be a browser that isn't Mozilla - on the other hand why should WebTrust perform any other audits today than BR? -- Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. XMPP: startcom at startcom.org Blog: Join the Revolution! Twitter: Follow Me -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4313 bytes Desc: S/MIME Cryptographic Signature URL: From kirk_hall at trendmicro.com Fri Feb 20 21:45:15 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Fri, 20 Feb 2015 21:45:15 +0000 Subject: [cabfpub] When did the WebTrust/ETSI BR audit requirement become mandatory? In-Reply-To: <54E7A2AE.2040501@startcom.org> References: <54E7A2AE.2040501@startcom.org> Message-ID: When you say "why" - do you mean "is regular WebTrust still required?" (it is, along with BR WebTrust), or are you suggesting that regular WebTrust should no longer be a requirement, just BR WebTrust? In an earlier string, this was asked and I recall Don Sheehy noted that the two audit regimes are somewhat overlapping in certain areas, but otherwise cover different issues and are both still needed. From: Eddy Nigg [mailto:eddy_nigg at startcom.org] Sent: Friday, February 20, 2015 1:10 PM To: Kirk Hall (RD-US); i-barreira; Peter Bowen; public at cabforum.org Subject: Re: [cabfpub] When did the WebTrust/ETSI BR audit requirement become mandatory? On 02/20/2015 09:01 PM, kirk_hall at trendmicro.com wrote: That's true - but every person visiting the site would have to do the same thing. So as a practical matter, no commercial CA will proceed in selling certs generally without its roots being in the main browser root stores, which requires completed WebTrust/ETSI audits to be delivered to the browsers. And I don't think the Forum needs to have "private" CA members. The forum requires a CA to be supported by at least one major browser. But it can be a browser that isn't Mozilla - on the other hand why should WebTrust perform any other audits today than BR? -- Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. XMPP: startcom at startcom.org Blog: Join the Revolution! Twitter: Follow Me 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
-------------- next part -------------- An HTML attachment was scrubbed... URL: From eddy_nigg at startcom.org Fri Feb 20 22:03:18 2015 From: eddy_nigg at startcom.org (Eddy Nigg) Date: Sat, 21 Feb 2015 00:03:18 +0200 Subject: [cabfpub] When did the WebTrust/ETSI BR audit requirement become mandatory? In-Reply-To: References: <54E7A2AE.2040501@startcom.org> Message-ID: <54E7AF26.8000706@startcom.org> On 02/20/2015 11:45 PM, kirk_hall at trendmicro.com wrote: > > When you say ?why? ? do you mean ?is regular WebTrust still required?? > (it is, along with BR WebTrust), or are you suggesting that regular > WebTrust should no longer be a requirement, just BR WebTrust? > I certainly would expect that this will become one (basic) audit eventually (and EV and others optional). -- Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. XMPP: startcom at startcom.org Blog: Join the Revolution! Twitter: Follow Me -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4313 bytes Desc: S/MIME Cryptographic Signature URL: From gerv at mozilla.org Mon Feb 23 14:10:10 2015 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 23 Feb 2015 14:10:10 +0000 Subject: [cabfpub] When did the WebTrust/ETSI BR audit requirement become mandatory? In-Reply-To: References: <54E61E67.6090409@mozilla.org> Message-ID: <54EB34C2.3040600@mozilla.org> On 19/02/15 18:28, kirk_hall at trendmicro.com wrote: > The > Requirements are not mandatory for Certification Authorities unless and > until they become adopted and enforced by relying?party Application > Software Suppliers. *** This sentence seems to me to say precisely what I am saying. Making a BR audit a condition of membership is moving towards making the BRs mandatory for CAs for a reason _other_ than "they are enforced by relying party Application Software Suppliers". Which would be contrary to this sentence. > No CA is required to join the Forum to operate ? the CAs only need to > satisfy the browsers. But I can?t think of any reason why a CA would > choose NOT to follow the BRs and get a BR audit if it wants to be > considered a ?real? CA. Well, perhaps there is some aspect of the BRs that they disagree with, or cannot follow for legal reasons, and wish to join in order to get things changed? I am also troubled by the general principle of "if you want a voice in getting these requirements changed, you have to abide by them first". The CAB Forum does not control the WebTrust audit criteria so this problem is not apparent when we use that as a membership filter. > And I don?t think the Forum would want to accept any new CA member that > said ?I choose not to follow the BRs, and I choose not to get a BR > audit? ? why would we want such a CA as a member? The CA/Browser Forum is not a gentleman's club; we don't get to blackball people because we don't like the way they do things. The CAB Forum also does not assess the suitability or trustworthiness of CAs for any particular role or task. Unless we think that the current criteria for CA membership are so loose that people are applying for membership who are not "real CAs", then there is no need to change the criteria. Gerv From bruce.morton at entrust.com Mon Feb 23 18:41:50 2015 From: bruce.morton at entrust.com (Bruce Morton) Date: Mon, 23 Feb 2015 18:41:50 +0000 Subject: [cabfpub] Lenovo installation of malicious root. In-Reply-To: <9CB5BBD9-58FA-4DC2-90E0-70F01911A4AC@comodo.com> References: <9CB5BBD9-58FA-4DC2-90E0-70F01911A4AC@comodo.com> Message-ID: <452C99D20750E74083DBA441FF932385E419DB78@SOTTEXCH10.corp.ad.entrust.com> Have we just come across an issue with operating systems/browsers and private roots? I suppose an attacker can install proxy software with their private root and examine all secured traffic. We don't need Lenovo to install this software, this could easily be done by any corner-store computer shop. Should private roots get the same trust indication as public trust roots? Public key pinning didn't even catch this issue as the private root seems to be trusted more than the public trust roots are. Thanks, Bruce. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Phillip Hallam-Baker Sent: Thursday, February 19, 2015 1:53 PM To: CABFPub Subject: [cabfpub] Lenovo installation of malicious root. I am sure many of you have seen this. If not you will, I have had a dozen people ping me about it in the past hour. https://www.eff.org/deeplinks/2015/02/further-evidence-lenovo-breaking-https-security-its-laptops Someone has to draw the line here or the politicians will do it for us. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sleevi at google.com Mon Feb 23 19:05:25 2015 From: sleevi at google.com (Ryan Sleevi) Date: Mon, 23 Feb 2015 11:05:25 -0800 Subject: [cabfpub] Lenovo installation of malicious root. In-Reply-To: <452C99D20750E74083DBA441FF932385E419DB78@SOTTEXCH10.corp.ad.entrust.com> References: <9CB5BBD9-58FA-4DC2-90E0-70F01911A4AC@comodo.com> <452C99D20750E74083DBA441FF932385E419DB78@SOTTEXCH10.corp.ad.entrust.com> Message-ID: On Mon, Feb 23, 2015 at 10:41 AM, Bruce Morton wrote: > Have we just come across an issue with operating systems/browsers and > private roots? > Yes > > > I suppose an attacker can install proxy software with their private root and > examine all secured traffic. We don?t need Lenovo to install this software, > this could easily be done by any corner-store computer shop. > Correct > > > Should private roots get the same trust indication as public trust roots? > Yes. > > > Public key pinning didn?t even catch this issue as the private root seems to > be trusted more than the public trust roots are. Correct, because public key pinning is not designed to catch such issues, as it cannot catch such issues. http://www.chromium.org/Home/chromium-security/security-faq#TOC-How-does-key-pinning-interact-with-local-proxies-and-filters- > > > > Thanks, Bruce. > From palmer at google.com Mon Feb 23 19:37:30 2015 From: palmer at google.com (Chris Palmer) Date: Mon, 23 Feb 2015 11:37:30 -0800 Subject: [cabfpub] Lenovo installation of malicious root. In-Reply-To: References: <9CB5BBD9-58FA-4DC2-90E0-70F01911A4AC@comodo.com> <452C99D20750E74083DBA441FF932385E419DB78@SOTTEXCH10.corp.ad.entrust.com> Message-ID: Also, Comodo might want to tell us what is going on here: http://news.softpedia.com/news/Comodo-s-PrivDog-Breaks-HTTPS-Security-Possibly-Worse-than-Superfish-473968.shtml On Feb 23, 2015 11:05, "Ryan Sleevi" wrote: > On Mon, Feb 23, 2015 at 10:41 AM, Bruce Morton > wrote: > > Have we just come across an issue with operating systems/browsers and > > private roots? > > > > Yes > > > > > > > I suppose an attacker can install proxy software with their private root > and > > examine all secured traffic. We don?t need Lenovo to install this > software, > > this could easily be done by any corner-store computer shop. > > > > Correct > > > > > > > Should private roots get the same trust indication as public trust roots? > > > > Yes. > > > > > > > Public key pinning didn?t even catch this issue as the private root > seems to > > be trusted more than the public trust roots are. > > Correct, because public key pinning is not designed to catch such > issues, as it cannot catch such issues. > > > http://www.chromium.org/Home/chromium-security/security-faq#TOC-How-does-key-pinning-interact-with-local-proxies-and-filters- > > > > > > > > > Thanks, Bruce. > > > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.wilson at digicert.com Mon Feb 23 21:39:59 2015 From: ben.wilson at digicert.com (Ben Wilson) Date: Mon, 23 Feb 2015 21:39:59 +0000 Subject: [cabfpub] Version 1.5.3 redlined with Ballot 144 Changes Message-ID: All, Attached please find a Word version of the EV Guidelines redlined with changes from Ballot 144. Previous versions of the EV Guidelines in Word would cause some people's computers to crash while they were editing the EV Guidelines. Could a few of your take a look at this document and confirm that it is stable? Hopefully this version has eliminated that problem. Thanks, Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: EV V1_5_3-redlined.doc Type: application/msword Size: 351744 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4954 bytes Desc: not available URL: From Rick_Andrews at symantec.com Mon Feb 23 21:50:50 2015 From: Rick_Andrews at symantec.com (Rick Andrews) Date: Mon, 23 Feb 2015 13:50:50 -0800 Subject: [cabfpub] Version 1.5.3 redlined with Ballot 144 Changes In-Reply-To: References: Message-ID: <544B0DD62A64C1448B2DA253C01141460BD3FDC905@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> Ben, I got through the document without problems. I see two nits: "For a Certificate issued to a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant's control over the .onion Domain Name in accordance with Appendix F." That's not grammatically correct. Maybe say "the Applicant has control"? Appendix F: Number 1 isn't properly indented. -Rick From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ben Wilson Sent: Monday, February 23, 2015 1:40 PM To: CABFPub Subject: [cabfpub] Version 1.5.3 redlined with Ballot 144 Changes All, Attached please find a Word version of the EV Guidelines redlined with changes from Ballot 144. Previous versions of the EV Guidelines in Word would cause some people's computers to crash while they were editing the EV Guidelines. Could a few of your take a look at this document and confirm that it is stable? Hopefully this version has eliminated that problem. Thanks, Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.wilson at digicert.com Mon Feb 23 21:51:19 2015 From: ben.wilson at digicert.com (Ben Wilson) Date: Mon, 23 Feb 2015 21:51:19 +0000 Subject: [cabfpub] Version 1.2.4 of Baseline Requirements redlined with Ballot 144 Changes Message-ID: All, Similar to my request concerning version of the EV Guidelines just circulated, please confirm that this document (v. 1.2.4 of Baseline Requirements) is in order. Thanks, Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: BRv1.2.4-redlined.doc Type: application/msword Size: 514560 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4954 bytes Desc: not available URL: From ben.wilson at digicert.com Tue Feb 24 01:35:22 2015 From: ben.wilson at digicert.com (Ben Wilson) Date: Tue, 24 Feb 2015 01:35:22 +0000 Subject: [cabfpub] Version 1.2.4 of Baseline Requirements redlined with Ballot 144 Changes In-Reply-To: References: Message-ID: All, Peter Bowen reminded me that we need to update section 16.5 of the BRs - see https://bugzilla.cabforum.org/show_bug.cgi?id=10. I suppose that when I introduce a ballot to reformat the BRs to RFC 3647, that will take care of it. Ben From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ben Wilson Sent: Monday, February 23, 2015 2:51 PM To: CABFPub Subject: [cabfpub] Version 1.2.4 of Baseline Requirements redlined with Ballot 144 Changes All, Similar to my request concerning version of the EV Guidelines just circulated, please confirm that this document (v. 1.2.4 of Baseline Requirements) is in order. Thanks, Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4954 bytes Desc: not available URL: From robin at comodo.com Tue Feb 24 04:21:47 2015 From: robin at comodo.com (Robin Alden) Date: Mon, 23 Feb 2015 23:21:47 -0500 Subject: [cabfpub] Lenovo installation of malicious root. In-Reply-To: References: <9CB5BBD9-58FA-4DC2-90E0-70F01911A4AC@comodo.com> <452C99D20750E74083DBA441FF932385E419DB78@SOTTEXCH10.corp.ad.entrust.com> Message-ID: <00a901d04fe9$68eed040$3acc70c0$@comodo.com> Hi Chris, PrivDog is not a Comodo Group product. Comodo ships a version of PrivDog with Comodo Internet Security (CIS) and with Comodo browsers, but that is an earlier release which does not exhibit the identified behaviour. The PrivDog versions being downloaded and evaluated by security researchers is a newer stand-alone version that has never been distributed by Comodo. The issue is only present in PrivDog versions 3.0.96.0 and 3.0.97.0 and is apparently due to a bug in a third party library that PrivDog bought in. The PrivDog team has released an advisory with more information, available here: http://privdog.com/advisory.html I see that Hanno has updated his page somewhat, too, to remove the claim that it is Comodo distributing this flawed version of PrivDog. https://blog.hboeck.de/archives/865-Adware-Privdog-worse-than-Superfish.html c.f. http://web.archive.org/web/20150223010209/https://blog.hboeck.de/archives/865-Comodo-ships-Adware-Privdog-worse-than-Superfish.html Regards Robin Alden Comodo CA Ltd. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Chris Palmer Sent: 23 February 2015 14:38 To: Ryan Sleevi Cc: public at cabforum.org Subject: Re: [cabfpub] Lenovo installation of malicious root. Also, Comodo might want to tell us what is going on here: http://news.softpedia.com/news/Comodo-s-PrivDog-Breaks-HTTPS-Security-Possibly-Worse-than-Superfish-473968.shtml On Feb 23, 2015 11:05, "Ryan Sleevi" wrote: On Mon, Feb 23, 2015 at 10:41 AM, Bruce Morton wrote: > Have we just come across an issue with operating systems/browsers and > private roots? > Yes > > > I suppose an attacker can install proxy software with their private root and > examine all secured traffic. We don?t need Lenovo to install this software, > this could easily be done by any corner-store computer shop. > Correct > > > Should private roots get the same trust indication as public trust roots? > Yes. > > > Public key pinning didn?t even catch this issue as the private root seems to > be trusted more than the public trust roots are. Correct, because public key pinning is not designed to catch such issues, as it cannot catch such issues. http://www.chromium.org/Home/chromium-security/security-faq#TOC-How-does-key-pinning-interact-with-local-proxies-and-filters- > > > > Thanks, Bruce. > _______________________________________________ Public mailing list Public at cabforum.org https://cabforum.org/mailman/listinfo/public -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5776 bytes Desc: not available URL: From kirk_hall at trendmicro.com Tue Feb 24 06:17:19 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Tue, 24 Feb 2015 06:17:19 +0000 Subject: [cabfpub] When did the WebTrust/ETSI BR audit requirement become mandatory? In-Reply-To: <54EC12E1.7030407@certizen.com> References: <54E61E67.6090409@mozilla.org> <54EB34C2.3040600@mozilla.org> <54EC12E1.7030407@certizen.com> Message-ID: There is no fee. -----Original Message----- From: Man Ho (Certizen) [mailto:manho at certizen.com] Sent: Monday, February 23, 2015 9:58 PM To: Gervase Markham; Kirk Hall (RD-US); CABFPub (public at cabforum.org) Subject: Re: [cabfpub] When did the WebTrust/ETSI BR audit requirement become mandatory? On 2/23/2015 10:10 PM, Gervase Markham wrote: > Well, perhaps there is some aspect of the BRs that they disagree with, > or cannot follow for legal reasons, and wish to join in order to get > things changed? > > I am also troubled by the general principle of "if you want a voice in > getting these requirements changed, you have to abide by them first". > The CAB Forum does not control the WebTrust audit criteria so this > problem is not apparent when we use that as a membership filter. +1 BTW, is there any membership fee for joining the CAB/Forum? -- Man Ho 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
From robin at comodo.com Tue Feb 24 12:46:29 2015 From: robin at comodo.com (Robin Alden) Date: Tue, 24 Feb 2015 07:46:29 -0500 Subject: [cabfpub] Lenovo installation of malicious root. In-Reply-To: <00a901d04fe9$68eed040$3acc70c0$@comodo.com> References: <9CB5BBD9-58FA-4DC2-90E0-70F01911A4AC@comodo.com> <452C99D20750E74083DBA441FF932385E419DB78@SOTTEXCH10.corp.ad.entrust.com> <00a901d04fe9$68eed040$3acc70c0$@comodo.com> Message-ID: <019c01d0502f$eb4fb9a0$c1ef2ce0$@comodo.com> That archive.org link I gave is dead. I?ve put a screen grab of the old page here: https://app.ccloud.com/#share/1783 &6ac37df3dbd2a650399cb25639157cbe017bc9b9 for comparison with https://blog.hboeck.de/archives/865-Adware-Privdog-worse-than-Superfish.html Regards Robin From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Robin Alden Sent: 23 February 2015 23:22 To: 'Chris Palmer'; 'Ryan Sleevi' Cc: public at cabforum.org Subject: Re: [cabfpub] Lenovo installation of malicious root. Hi Chris, PrivDog is not a Comodo Group product. Comodo ships a version of PrivDog with Comodo Internet Security (CIS) and with Comodo browsers, but that is an earlier release which does not exhibit the identified behaviour. The PrivDog versions being downloaded and evaluated by security researchers is a newer stand-alone version that has never been distributed by Comodo. The issue is only present in PrivDog versions 3.0.96.0 and 3.0.97.0 and is apparently due to a bug in a third party library that PrivDog bought in. The PrivDog team has released an advisory with more information, available here: http://privdog.com/advisory.html I see that Hanno has updated his page somewhat, too, to remove the claim that it is Comodo distributing this flawed version of PrivDog. https://blog.hboeck.de/archives/865-Adware-Privdog-worse-than-Superfish.html c.f. http://web.archive.org/web/20150223010209/https://blog.hboeck.de/archives/865-Comodo-ships-Adware-Privdog-worse-than-Superfish.html Regards Robin Alden Comodo CA Ltd. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Chris Palmer Sent: 23 February 2015 14:38 To: Ryan Sleevi Cc: public at cabforum.org Subject: Re: [cabfpub] Lenovo installation of malicious root. Also, Comodo might want to tell us what is going on here: http://news.softpedia.com/news/Comodo-s-PrivDog-Breaks-HTTPS-Security-Possibly-Worse-than-Superfish-473968.shtml -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.wilson at digicert.com Tue Feb 24 15:21:44 2015 From: ben.wilson at digicert.com (Ben Wilson) Date: Tue, 24 Feb 2015 15:21:44 +0000 Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Message-ID: <4214ab2ac59143c3a726ad7419792a45@EX2.corp.digicert.com> Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework The Certificate Policy Review Working Group was chartered by Ballot 128 to (i) consider existing and proposed standards, (ii) create a list of potential improvements based on the considered standards that improve the existing CAB Forum work product, (iii) evaluate the transition to a 3647 format based on the amount [of work involved]. One deliverable of the CP Review WG was to propose a ballot to improve CA infrastructure based on existing standards and documents and recommend whether to finish the 3647 conversion presented by Jeremy Rowley in January 2014. The CP Review WG has met and concluded that the best path forward for the Forum is to complete a conversion to the RFC 3647 for the Baseline Requirements with an initial step that merely moves existing content from the Baseline Requirements and the Network and Certificate System Security Requirements into the RFC 3647 format. Attached is an RFC-3647-formatted Certificate Policy for Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates. Comments embedded in the document contain either the source of the text (for content copied from the Baseline Requirements) or the current text (for provisions incorporated by reference from the Network and Certificate System Security Requirements ("NetSec"). It was decided that it was better to incorporate the NetSec requirements by reference rather than copying and pasting them in. In some limited instances the phrase "these Requirements" has been replaced with "this CP." However, "these Requirements" is mostly left in to preserve consistency with the current Baseline Requirements. Ben Wilson of DigiCert made the following motion, from and from have endorsed it. Motion Begins Be it resolved that the CA / Browser Forum adopts the attached CA/B Forum Certificate Policy v.1.2.5, effective immediately. Motion Ends The review period for this ballot shall commence at 2200 UTC on March 2015 and will close at 2200 UTC on March 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on March 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the ballot must indicate a clear 'yes' in the response. A vote against the ballot must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/. In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and more than one half of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or by abstaining for the vote to be valid. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: CAB Forum BR 3647 CP Draft.doc Type: application/msword Size: 601600 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4954 bytes Desc: not available URL: From THollebeek at trustwave.com Tue Feb 24 15:49:07 2015 From: THollebeek at trustwave.com (Tim Hollebeek) Date: Tue, 24 Feb 2015 15:49:07 +0000 Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework In-Reply-To: <4214ab2ac59143c3a726ad7419792a45@EX2.corp.digicert.com> References: <4214ab2ac59143c3a726ad7419792a45@EX2.corp.digicert.com> Message-ID: I'll endorse. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ben Wilson Sent: Tuesday, February 24, 2015 10:22 AM To: CABFPub Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework The Certificate Policy Review Working Group was chartered by Ballot 128 to (i) consider existing and proposed standards, (ii) create a list of potential improvements based on the considered standards that improve the existing CAB Forum work product, (iii) evaluate the transition to a 3647 format based on the amount [of work involved]. One deliverable of the CP Review WG was to propose a ballot to improve CA infrastructure based on existing standards and documents and recommend whether to finish the 3647 conversion presented by Jeremy Rowley in January 2014. The CP Review WG has met and concluded that the best path forward for the Forum is to complete a conversion to the RFC 3647 for the Baseline Requirements with an initial step that merely moves existing content from the Baseline Requirements and the Network and Certificate System Security Requirements into the RFC 3647 format. Attached is an RFC-3647-formatted Certificate Policy for Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates. Comments embedded in the document contain either the source of the text (for content copied from the Baseline Requirements) or the current text (for provisions incorporated by reference from the Network and Certificate System Security Requirements ("NetSec"). It was decided that it was better to incorporate the NetSec requirements by reference rather than copying and pasting them in. In some limited instances the phrase "these Requirements" has been replaced with "this CP." However, "these Requirements" is mostly left in to preserve consistency with the current Baseline Requirements. Ben Wilson of DigiCert made the following motion, from and from have endorsed it. Motion Begins Be it resolved that the CA / Browser Forum adopts the attached CA/B Forum Certificate Policy v.1.2.5, effective immediately. Motion Ends The review period for this ballot shall commence at 2200 UTC on March 2015 and will close at 2200 UTC on March 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on March 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the ballot must indicate a clear 'yes' in the response. A vote against the ballot must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/. In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and more than one half of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or by abstaining for the vote to be valid. ________________________________ This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirk_hall at trendmicro.com Tue Feb 24 16:51:48 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Tue, 24 Feb 2015 16:51:48 +0000 Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework In-Reply-To: <4214ab2ac59143c3a726ad7419792a45@EX2.corp.digicert.com> References: <4214ab2ac59143c3a726ad7419792a45@EX2.corp.digicert.com> Message-ID: Ben - first of all, thanks for the hard work on this one. I'm trying to figure out the benefit of locking the Forum into the RFC 3647 framework for the purpose of listing BR requirements. Is there really a benefit? Does it add to understanding and make CA compliance any easier? Or will it force us to put rules in odd places that actually make understanding a bit harder? I note the BR 8.2 already requires CAs to put their CPS into the format of RFC 2527 or 3647. See the first two sections of BR 8.2 below. That can facilitate comparison between the CPSs of different CAs, if anyone cares to do that. But is there any corresponding benefit from restructuring the BRs to an RFC 3647 format? What if a rule spans two or more different sections of the RFC 3647 format? I see that in your new organization of the BRs you have moved old BR 8.2.2 to a new Section 2.1 Repositories, not to new Section 2.2 Publication of Information. How did you make that choice? And is there an expectation that CAs will publish their CAA disclosure in new Sec. 2.2 of their CPS? I'm just afraid we will be handcuffing ourselves with these changes, and that there could be errors in internal cross-references. It is also a lot of work for everyone to review a complete rewrite of the BRs. Can you give us a convincing argument of why this is worth doing? Sorry I didn't ask this question earlier, but I hadn't really understood this was what the working group was doing - I thought you were just looking for GAPS in the BRs as compared to the RFC 3647 where we could ADD new provisions to the BRs - not a wholesale restructuring of the BRs. Thanks. BR 8.2.2 Disclosure The CA SHALL publicly disclose its Certificate Policy and/or Certification Practice Statement through an appropriate and readily accessible online means that is available on a 24x7 basis. The CA SHALL publicly disclose its CA business practices to the extent required by the CA's selected audit scheme (see Section 17.1). The disclosures MUST include all the material required by RFC 2527 or RFC 3647, and MUST be structured in accordance with either RFC 2527 or RFC 3647. Effective as of 15 April 2015, section 4.2 of a CA's Certificate Policy and/or Certification Practice Statement (section 4.1 for CAs still conforming to RFC 2527) SHALL state whether the CA reviews CAA Records, and if so, the CA's policy or practice on processing CAA Records for Fully Qualified Domain Names. The CA SHALL log all actions taken, if any, consistent with its processing practice. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ben Wilson Sent: Tuesday, February 24, 2015 7:22 AM To: CABFPub Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework The Certificate Policy Review Working Group was chartered by Ballot 128 to (i) consider existing and proposed standards, (ii) create a list of potential improvements based on the considered standards that improve the existing CAB Forum work product, (iii) evaluate the transition to a 3647 format based on the amount [of work involved]. One deliverable of the CP Review WG was to propose a ballot to improve CA infrastructure based on existing standards and documents and recommend whether to finish the 3647 conversion presented by Jeremy Rowley in January 2014. The CP Review WG has met and concluded that the best path forward for the Forum is to complete a conversion to the RFC 3647 for the Baseline Requirements with an initial step that merely moves existing content from the Baseline Requirements and the Network and Certificate System Security Requirements into the RFC 3647 format. Attached is an RFC-3647-formatted Certificate Policy for Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates. Comments embedded in the document contain either the source of the text (for content copied from the Baseline Requirements) or the current text (for provisions incorporated by reference from the Network and Certificate System Security Requirements ("NetSec"). It was decided that it was better to incorporate the NetSec requirements by reference rather than copying and pasting them in. In some limited instances the phrase "these Requirements" has been replaced with "this CP." However, "these Requirements" is mostly left in to preserve consistency with the current Baseline Requirements. Ben Wilson of DigiCert made the following motion, from and from have endorsed it. Motion Begins Be it resolved that the CA / Browser Forum adopts the attached CA/B Forum Certificate Policy v.1.2.5, effective immediately. Motion Ends The review period for this ballot shall commence at 2200 UTC on March 2015 and will close at 2200 UTC on March 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on March 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the ballot must indicate a clear 'yes' in the response. A vote against the ballot must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/. In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and more than one half of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or by abstaining for the vote to be valid. 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
-------------- next part -------------- An HTML attachment was scrubbed... URL: From Dean_Coclin at symantec.com Tue Feb 24 16:59:05 2015 From: Dean_Coclin at symantec.com (Dean Coclin) Date: Tue, 24 Feb 2015 08:59:05 -0800 Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework In-Reply-To: References: <4214ab2ac59143c3a726ad7419792a45@EX2.corp.digicert.com> Message-ID: <14D026C7F297AD44AC82578DD818CDD038EF4A93E9@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> Some of the beneficiaries are Browser root programs and relying parties. Having the BRs in this format makes it easier for Jody, Kathleen and others to review CPS? and compare to the sections in the BRs for compliance. Jeremy has already taken a pass at doing this and a draft has been circulated. Dean From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of kirk_hall at trendmicro.com Sent: Tuesday, February 24, 2015 11:52 AM To: Ben Wilson; CABFPub Subject: Re: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Ben ? first of all, thanks for the hard work on this one. I?m trying to figure out the benefit of locking the Forum into the RFC 3647 framework for the purpose of listing BR requirements. Is there really a benefit? Does it add to understanding and make CA compliance any easier? Or will it force us to put rules in odd places that actually make understanding a bit harder? I note the BR 8.2 already requires CAs to put their CPS into the format of RFC 2527 or 3647. See the first two sections of BR 8.2 below. That can facilitate comparison between the CPSs of different CAs, if anyone cares to do that. But is there any corresponding benefit from restructuring the BRs to an RFC 3647 format? What if a rule spans two or more different sections of the RFC 3647 format? I see that in your new organization of the BRs you have moved old BR 8.2.2 to a new Section 2.1 Repositories, not to new Section 2.2 Publication of Information. How did you make that choice? And is there an expectation that CAs will publish their CAA disclosure in new Sec. 2.2 of their CPS? I?m just afraid we will be handcuffing ourselves with these changes, and that there could be errors in internal cross-references. It is also a lot of work for everyone to review a complete rewrite of the BRs. Can you give us a convincing argument of why this is worth doing? Sorry I didn?t ask this question earlier, but I hadn?t really understood this was what the working group was doing ? I thought you were just looking for GAPS in the BRs as compared to the RFC 3647 where we could ADD new provisions to the BRs ? not a wholesale restructuring of the BRs. Thanks. BR 8.2.2 Disclosure The CA SHALL publicly disclose its Certificate Policy and/or Certification Practice Statement through an appropriate and readily accessible online means that is available on a 24x7 basis. The CA SHALL publicly disclose its CA business practices to the extent required by the CA?s selected audit scheme (see Section 17.1). The disclosures MUST include all the material required by RFC 2527 or RFC 3647, and MUST be structured in accordance with either RFC 2527 or RFC 3647. Effective as of 15 April 2015, section 4.2 of a CA's Certificate Policy and/or Certification Practice Statement (section 4.1 for CAs still conforming to RFC 2527) SHALL state whether the CA reviews CAA Records, and if so, the CA?s policy or practice on processing CAA Records for Fully Qualified Domain Names. The CA SHALL log all actions taken, if any, consistent with its processing practice. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ben Wilson Sent: Tuesday, February 24, 2015 7:22 AM To: CABFPub Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework The Certificate Policy Review Working Group was chartered by Ballot 128 to (i) consider existing and proposed standards, (ii) create a list of potential improvements based on the considered standards that improve the existing CAB Forum work product, (iii) evaluate the transition to a 3647 format based on the amount [of work involved]. One deliverable of the CP Review WG was to propose a ballot to improve CA infrastructure based on existing standards and documents and recommend whether to finish the 3647 conversion presented by Jeremy Rowley in January 2014. The CP Review WG has met and concluded that the best path forward for the Forum is to complete a conversion to the RFC 3647 for the Baseline Requirements with an initial step that merely moves existing content from the Baseline Requirements and the Network and Certificate System Security Requirements into the RFC 3647 format. Attached is an RFC-3647-formatted Certificate Policy for Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates. Comments embedded in the document contain either the source of the text (for content copied from the Baseline Requirements) or the current text (for provisions incorporated by reference from the Network and Certificate System Security Requirements ("NetSec"). It was decided that it was better to incorporate the NetSec requirements by reference rather than copying and pasting them in. In some limited instances the phrase "these Requirements" has been replaced with "this CP." However, "these Requirements" is mostly left in to preserve consistency with the current Baseline Requirements. Ben Wilson of DigiCert made the following motion, from and from have endorsed it. Motion Begins Be it resolved that the CA / Browser Forum adopts the attached CA/B Forum Certificate Policy v.1.2.5, effective immediately. Motion Ends The review period for this ballot shall commence at 2200 UTC on March 2015 and will close at 2200 UTC on March 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on March 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the ballot must indicate a clear ?yes? in the response. A vote against the ballot must indicate a clear ?no? in the response. A vote to abstain must indicate a clear ?abstain? in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/. In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and more than one half of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members? at least nine members must participate in the ballot, either by voting in favor, voting against, or by abstaining for the vote to be valid. TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6130 bytes Desc: not available URL: From jodycl at microsoft.com Tue Feb 24 17:24:03 2015 From: jodycl at microsoft.com (Jody Cloutier) Date: Tue, 24 Feb 2015 17:24:03 +0000 Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework In-Reply-To: References: <4214ab2ac59143c3a726ad7419792a45@EX2.corp.digicert.com> Message-ID: I'll endorse. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Tim Hollebeek Sent: Tuesday, February 24, 2015 7:49 AM To: Ben Wilson; CABFPub Subject: Re: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework I'll endorse. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ben Wilson Sent: Tuesday, February 24, 2015 10:22 AM To: CABFPub Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework The Certificate Policy Review Working Group was chartered by Ballot 128 to (i) consider existing and proposed standards, (ii) create a list of potential improvements based on the considered standards that improve the existing CAB Forum work product, (iii) evaluate the transition to a 3647 format based on the amount [of work involved]. One deliverable of the CP Review WG was to propose a ballot to improve CA infrastructure based on existing standards and documents and recommend whether to finish the 3647 conversion presented by Jeremy Rowley in January 2014. The CP Review WG has met and concluded that the best path forward for the Forum is to complete a conversion to the RFC 3647 for the Baseline Requirements with an initial step that merely moves existing content from the Baseline Requirements and the Network and Certificate System Security Requirements into the RFC 3647 format. Attached is an RFC-3647-formatted Certificate Policy for Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates. Comments embedded in the document contain either the source of the text (for content copied from the Baseline Requirements) or the current text (for provisions incorporated by reference from the Network and Certificate System Security Requirements ("NetSec"). It was decided that it was better to incorporate the NetSec requirements by reference rather than copying and pasting them in. In some limited instances the phrase "these Requirements" has been replaced with "this CP." However, "these Requirements" is mostly left in to preserve consistency with the current Baseline Requirements. Ben Wilson of DigiCert made the following motion, from and from have endorsed it. Motion Begins Be it resolved that the CA / Browser Forum adopts the attached CA/B Forum Certificate Policy v.1.2.5, effective immediately. Motion Ends The review period for this ballot shall commence at 2200 UTC on March 2015 and will close at 2200 UTC on March 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on March 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the ballot must indicate a clear 'yes' in the response. A vote against the ballot must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/. In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and more than one half of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or by abstaining for the vote to be valid. ________________________________ This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirk_hall at trendmicro.com Tue Feb 24 17:56:12 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Tue, 24 Feb 2015 17:56:12 +0000 Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework In-Reply-To: <14D026C7F297AD44AC82578DD818CDD038EF4A93E9@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> References: <4214ab2ac59143c3a726ad7419792a45@EX2.corp.digicert.com> <14D026C7F297AD44AC82578DD818CDD038EF4A93E9@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> Message-ID: Fair point, but here is another consideration. Right now, all the WebTrust (and ETSI?) documents are laid out more or less in the same order as the current BRs and EVGL, and include references to the current numbering. If all numbering is changed, they will have to amend the WebTrust (and ETSI?) internal references ? maybe not a big deal ? but the order of the WebTrust requirements will no longer correspond to the order of the BRs. From: Dean Coclin [mailto:Dean_Coclin at symantec.com] Sent: Tuesday, February 24, 2015 8:59 AM To: Kirk Hall (RD-US); Ben Wilson; CABFPub Subject: RE: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Some of the beneficiaries are Browser root programs and relying parties. Having the BRs in this format makes it easier for Jody, Kathleen and others to review CPS? and compare to the sections in the BRs for compliance. Jeremy has already taken a pass at doing this and a draft has been circulated. Dean From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of kirk_hall at trendmicro.com Sent: Tuesday, February 24, 2015 11:52 AM To: Ben Wilson; CABFPub Subject: Re: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Ben ? first of all, thanks for the hard work on this one. I?m trying to figure out the benefit of locking the Forum into the RFC 3647 framework for the purpose of listing BR requirements. Is there really a benefit? Does it add to understanding and make CA compliance any easier? Or will it force us to put rules in odd places that actually make understanding a bit harder? I note the BR 8.2 already requires CAs to put their CPS into the format of RFC 2527 or 3647. See the first two sections of BR 8.2 below. That can facilitate comparison between the CPSs of different CAs, if anyone cares to do that. But is there any corresponding benefit from restructuring the BRs to an RFC 3647 format? What if a rule spans two or more different sections of the RFC 3647 format? I see that in your new organization of the BRs you have moved old BR 8.2.2 to a new Section 2.1 Repositories, not to new Section 2.2 Publication of Information. How did you make that choice? And is there an expectation that CAs will publish their CAA disclosure in new Sec. 2.2 of their CPS? I?m just afraid we will be handcuffing ourselves with these changes, and that there could be errors in internal cross-references. It is also a lot of work for everyone to review a complete rewrite of the BRs. Can you give us a convincing argument of why this is worth doing? Sorry I didn?t ask this question earlier, but I hadn?t really understood this was what the working group was doing ? I thought you were just looking for GAPS in the BRs as compared to the RFC 3647 where we could ADD new provisions to the BRs ? not a wholesale restructuring of the BRs. Thanks. BR 8.2.2 Disclosure The CA SHALL publicly disclose its Certificate Policy and/or Certification Practice Statement through an appropriate and readily accessible online means that is available on a 24x7 basis. The CA SHALL publicly disclose its CA business practices to the extent required by the CA?s selected audit scheme (see Section 17.1). The disclosures MUST include all the material required by RFC 2527 or RFC 3647, and MUST be structured in accordance with either RFC 2527 or RFC 3647. Effective as of 15 April 2015, section 4.2 of a CA's Certificate Policy and/or Certification Practice Statement (section 4.1 for CAs still conforming to RFC 2527) SHALL state whether the CA reviews CAA Records, and if so, the CA?s policy or practice on processing CAA Records for Fully Qualified Domain Names. The CA SHALL log all actions taken, if any, consistent with its processing practice. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ben Wilson Sent: Tuesday, February 24, 2015 7:22 AM To: CABFPub Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework The Certificate Policy Review Working Group was chartered by Ballot 128 to (i) consider existing and proposed standards, (ii) create a list of potential improvements based on the considered standards that improve the existing CAB Forum work product, (iii) evaluate the transition to a 3647 format based on the amount [of work involved]. One deliverable of the CP Review WG was to propose a ballot to improve CA infrastructure based on existing standards and documents and recommend whether to finish the 3647 conversion presented by Jeremy Rowley in January 2014. The CP Review WG has met and concluded that the best path forward for the Forum is to complete a conversion to the RFC 3647 for the Baseline Requirements with an initial step that merely moves existing content from the Baseline Requirements and the Network and Certificate System Security Requirements into the RFC 3647 format. Attached is an RFC-3647-formatted Certificate Policy for Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates. Comments embedded in the document contain either the source of the text (for content copied from the Baseline Requirements) or the current text (for provisions incorporated by reference from the Network and Certificate System Security Requirements ("NetSec"). It was decided that it was better to incorporate the NetSec requirements by reference rather than copying and pasting them in. In some limited instances the phrase "these Requirements" has been replaced with "this CP." However, "these Requirements" is mostly left in to preserve consistency with the current Baseline Requirements. Ben Wilson of DigiCert made the following motion, from and from have endorsed it. Motion Begins Be it resolved that the CA / Browser Forum adopts the attached CA/B Forum Certificate Policy v.1.2.5, effective immediately. Motion Ends The review period for this ballot shall commence at 2200 UTC on March 2015 and will close at 2200 UTC on March 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on March 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the ballot must indicate a clear ?yes? in the response. A vote against the ballot must indicate a clear ?no? in the response. A vote to abstain must indicate a clear ?abstain? in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/. In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and more than one half of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members? at least nine members must participate in the ballot, either by voting in favor, voting against, or by abstaining for the vote to be valid. TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
-------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.wilson at digicert.com Tue Feb 24 18:02:21 2015 From: ben.wilson at digicert.com (Ben Wilson) Date: Tue, 24 Feb 2015 18:02:21 +0000 Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework In-Reply-To: References: <4214ab2ac59143c3a726ad7419792a45@EX2.corp.digicert.com> Message-ID: <2f0cf1bb3e3c488ebf5e700d9629aa91@EX2.corp.digicert.com> That is how the original from Jeremy was introduced with his email dated November 7, 2013, but I assume that it can be moved to section 2.2. From: kirk_hall at trendmicro.com [mailto:kirk_hall at trendmicro.com] Sent: Tuesday, February 24, 2015 9:52 AM To: Ben Wilson; CABFPub Subject: RE: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Ben ? first of all, thanks for the hard work on this one. I?m trying to figure out the benefit of locking the Forum into the RFC 3647 framework for the purpose of listing BR requirements. Is there really a benefit? Does it add to understanding and make CA compliance any easier? Or will it force us to put rules in odd places that actually make understanding a bit harder? I note the BR 8.2 already requires CAs to put their CPS into the format of RFC 2527 or 3647. See the first two sections of BR 8.2 below. That can facilitate comparison between the CPSs of different CAs, if anyone cares to do that. But is there any corresponding benefit from restructuring the BRs to an RFC 3647 format? What if a rule spans two or more different sections of the RFC 3647 format? I see that in your new organization of the BRs you have moved old BR 8.2.2 to a new Section 2.1 Repositories, not to new Section 2.2 Publication of Information. How did you make that choice? And is there an expectation that CAs will publish their CAA disclosure in new Sec. 2.2 of their CPS? I?m just afraid we will be handcuffing ourselves with these changes, and that there could be errors in internal cross-references. It is also a lot of work for everyone to review a complete rewrite of the BRs. Can you give us a convincing argument of why this is worth doing? Sorry I didn?t ask this question earlier, but I hadn?t really understood this was what the working group was doing ? I thought you were just looking for GAPS in the BRs as compared to the RFC 3647 where we could ADD new provisions to the BRs ? not a wholesale restructuring of the BRs. Thanks. BR 8.2.2 Disclosure The CA SHALL publicly disclose its Certificate Policy and/or Certification Practice Statement through an appropriate and readily accessible online means that is available on a 24x7 basis. The CA SHALL publicly disclose its CA business practices to the extent required by the CA?s selected audit scheme (see Section 17.1). The disclosures MUST include all the material required by RFC 2527 or RFC 3647, and MUST be structured in accordance with either RFC 2527 or RFC 3647. Effective as of 15 April 2015, section 4.2 of a CA's Certificate Policy and/or Certification Practice Statement (section 4.1 for CAs still conforming to RFC 2527) SHALL state whether the CA reviews CAA Records, and if so, the CA?s policy or practice on processing CAA Records for Fully Qualified Domain Names. The CA SHALL log all actions taken, if any, consistent with its processing practice. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ben Wilson Sent: Tuesday, February 24, 2015 7:22 AM To: CABFPub Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework The Certificate Policy Review Working Group was chartered by Ballot 128 to (i) consider existing and proposed standards, (ii) create a list of potential improvements based on the considered standards that improve the existing CAB Forum work product, (iii) evaluate the transition to a 3647 format based on the amount [of work involved]. One deliverable of the CP Review WG was to propose a ballot to improve CA infrastructure based on existing standards and documents and recommend whether to finish the 3647 conversion presented by Jeremy Rowley in January 2014. The CP Review WG has met and concluded that the best path forward for the Forum is to complete a conversion to the RFC 3647 for the Baseline Requirements with an initial step that merely moves existing content from the Baseline Requirements and the Network and Certificate System Security Requirements into the RFC 3647 format. Attached is an RFC-3647-formatted Certificate Policy for Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates. Comments embedded in the document contain either the source of the text (for content copied from the Baseline Requirements) or the current text (for provisions incorporated by reference from the Network and Certificate System Security Requirements ("NetSec"). It was decided that it was better to incorporate the NetSec requirements by reference rather than copying and pasting them in. In some limited instances the phrase "these Requirements" has been replaced with "this CP." However, "these Requirements" is mostly left in to preserve consistency with the current Baseline Requirements. Ben Wilson of DigiCert made the following motion, from and from have endorsed it. Motion Begins Be it resolved that the CA / Browser Forum adopts the attached CA/B Forum Certificate Policy v.1.2.5, effective immediately. Motion Ends The review period for this ballot shall commence at 2200 UTC on March 2015 and will close at 2200 UTC on March 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on March 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the ballot must indicate a clear ?yes? in the response. A vote against the ballot must indicate a clear ?no? in the response. A vote to abstain must indicate a clear ?abstain? in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/. In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and more than one half of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members? at least nine members must participate in the ballot, either by voting in favor, voting against, or by abstaining for the vote to be valid. TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4954 bytes Desc: not available URL: From kirk_hall at trendmicro.com Tue Feb 24 18:13:43 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Tue, 24 Feb 2015 18:13:43 +0000 Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework In-Reply-To: <2f0cf1bb3e3c488ebf5e700d9629aa91@EX2.corp.digicert.com> References: <4214ab2ac59143c3a726ad7419792a45@EX2.corp.digicert.com> <2f0cf1bb3e3c488ebf5e700d9629aa91@EX2.corp.digicert.com> Message-ID: Ben ? I was not arguing for any specific change. I was just raising the question of whether trying to fit the BRs into RFC 3647 created its own problems ? like where does a BR section go, and what should be done about a BR section that touches multiple sections of RFC 3647 (do you split up the current BR section, or just choose one place in the RFC 3647 format to put all the BR sections?). One other consideration ? there are many parts of the BRs (and EVGLs) that are not included in or relevant to a CA?s CPS ? they are either requirements, technical standards, or prohibitions, but they don?t have to be declared or included in a CPS. So in that sense, putting the BRs into RFC 3647 does not aid in review or comparison of CPSs across CAs, at least as to those sections? From: Ben Wilson [mailto:ben.wilson at digicert.com] Sent: Tuesday, February 24, 2015 10:02 AM To: Kirk Hall (RD-US); CABFPub Subject: RE: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework That is how the original from Jeremy was introduced with his email dated November 7, 2013, but I assume that it can be moved to section 2.2. From: kirk_hall at trendmicro.com [mailto:kirk_hall at trendmicro.com] Sent: Tuesday, February 24, 2015 9:52 AM To: Ben Wilson; CABFPub Subject: RE: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Ben ? first of all, thanks for the hard work on this one. I?m trying to figure out the benefit of locking the Forum into the RFC 3647 framework for the purpose of listing BR requirements. Is there really a benefit? Does it add to understanding and make CA compliance any easier? Or will it force us to put rules in odd places that actually make understanding a bit harder? I note the BR 8.2 already requires CAs to put their CPS into the format of RFC 2527 or 3647. See the first two sections of BR 8.2 below. That can facilitate comparison between the CPSs of different CAs, if anyone cares to do that. But is there any corresponding benefit from restructuring the BRs to an RFC 3647 format? What if a rule spans two or more different sections of the RFC 3647 format? I see that in your new organization of the BRs you have moved old BR 8.2.2 to a new Section 2.1 Repositories, not to new Section 2.2 Publication of Information. How did you make that choice? And is there an expectation that CAs will publish their CAA disclosure in new Sec. 2.2 of their CPS? I?m just afraid we will be handcuffing ourselves with these changes, and that there could be errors in internal cross-references. It is also a lot of work for everyone to review a complete rewrite of the BRs. Can you give us a convincing argument of why this is worth doing? Sorry I didn?t ask this question earlier, but I hadn?t really understood this was what the working group was doing ? I thought you were just looking for GAPS in the BRs as compared to the RFC 3647 where we could ADD new provisions to the BRs ? not a wholesale restructuring of the BRs. Thanks. BR 8.2.2 Disclosure The CA SHALL publicly disclose its Certificate Policy and/or Certification Practice Statement through an appropriate and readily accessible online means that is available on a 24x7 basis. The CA SHALL publicly disclose its CA business practices to the extent required by the CA?s selected audit scheme (see Section 17.1). The disclosures MUST include all the material required by RFC 2527 or RFC 3647, and MUST be structured in accordance with either RFC 2527 or RFC 3647. Effective as of 15 April 2015, section 4.2 of a CA's Certificate Policy and/or Certification Practice Statement (section 4.1 for CAs still conforming to RFC 2527) SHALL state whether the CA reviews CAA Records, and if so, the CA?s policy or practice on processing CAA Records for Fully Qualified Domain Names. The CA SHALL log all actions taken, if any, consistent with its processing practice. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ben Wilson Sent: Tuesday, February 24, 2015 7:22 AM To: CABFPub Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework The Certificate Policy Review Working Group was chartered by Ballot 128 to (i) consider existing and proposed standards, (ii) create a list of potential improvements based on the considered standards that improve the existing CAB Forum work product, (iii) evaluate the transition to a 3647 format based on the amount [of work involved]. One deliverable of the CP Review WG was to propose a ballot to improve CA infrastructure based on existing standards and documents and recommend whether to finish the 3647 conversion presented by Jeremy Rowley in January 2014. The CP Review WG has met and concluded that the best path forward for the Forum is to complete a conversion to the RFC 3647 for the Baseline Requirements with an initial step that merely moves existing content from the Baseline Requirements and the Network and Certificate System Security Requirements into the RFC 3647 format. Attached is an RFC-3647-formatted Certificate Policy for Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates. Comments embedded in the document contain either the source of the text (for content copied from the Baseline Requirements) or the current text (for provisions incorporated by reference from the Network and Certificate System Security Requirements ("NetSec"). It was decided that it was better to incorporate the NetSec requirements by reference rather than copying and pasting them in. In some limited instances the phrase "these Requirements" has been replaced with "this CP." However, "these Requirements" is mostly left in to preserve consistency with the current Baseline Requirements. Ben Wilson of DigiCert made the following motion, from and from have endorsed it. Motion Begins Be it resolved that the CA / Browser Forum adopts the attached CA/B Forum Certificate Policy v.1.2.5, effective immediately. Motion Ends The review period for this ballot shall commence at 2200 UTC on March 2015 and will close at 2200 UTC on March 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on March 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the ballot must indicate a clear ?yes? in the response. A vote against the ballot must indicate a clear ?no? in the response. A vote to abstain must indicate a clear ?abstain? in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/. In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and more than one half of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members? at least nine members must participate in the ballot, either by voting in favor, voting against, or by abstaining for the vote to be valid. TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
-------------- next part -------------- An HTML attachment was scrubbed... URL: From eddy_nigg at startcom.org Tue Feb 24 18:30:45 2015 From: eddy_nigg at startcom.org (Eddy Nigg) Date: Tue, 24 Feb 2015 20:30:45 +0200 Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework In-Reply-To: References: <4214ab2ac59143c3a726ad7419792a45@EX2.corp.digicert.com> <2f0cf1bb3e3c488ebf5e700d9629aa91@EX2.corp.digicert.com> Message-ID: <54ECC355.6030702@startcom.org> On 02/24/2015 08:13 PM, kirk_hall at trendmicro.com wrote: > One other consideration -- there are many parts of the BRs (and EVGLs) > that are not included in or relevant to a CA's CPS -- they are either > requirements, technical standards, or prohibitions, but they don't > have to be declared or included in a CPS. So in that sense, putting > the BRs into RFC 3647 does not aid in review or comparison of CPSs > across CAs, at least as to those sections... How about the BR in addition to a RFC 3647 structure document stating the relevant BR requirements? Meaning, two documents. -- Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. XMPP: startcom at startcom.org Blog: Join the Revolution! Twitter: Follow Me -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4313 bytes Desc: S/MIME Cryptographic Signature URL: From eddy_nigg at startcom.org Tue Feb 24 18:30:54 2015 From: eddy_nigg at startcom.org (Eddy Nigg) Date: Tue, 24 Feb 2015 20:30:54 +0200 Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework In-Reply-To: References: <4214ab2ac59143c3a726ad7419792a45@EX2.corp.digicert.com> <2f0cf1bb3e3c488ebf5e700d9629aa91@EX2.corp.digicert.com> Message-ID: <54ECC35E.8090405@startcom.org> On 02/24/2015 08:13 PM, kirk_hall at trendmicro.com wrote: > One other consideration -- there are many parts of the BRs (and EVGLs) > that are not included in or relevant to a CA's CPS -- they are either > requirements, technical standards, or prohibitions, but they don't > have to be declared or included in a CPS. So in that sense, putting > the BRs into RFC 3647 does not aid in review or comparison of CPSs > across CAs, at least as to those sections... How about the BR in addition to a RFC 3647 structured document stating the relevant BR requirements? Meaning, two documents. -- Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. XMPP: startcom at startcom.org Blog: Join the Revolution! Twitter: Follow Me -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4313 bytes Desc: S/MIME Cryptographic Signature URL: From ben.wilson at digicert.com Tue Feb 24 19:27:11 2015 From: ben.wilson at digicert.com (Ben Wilson) Date: Tue, 24 Feb 2015 19:27:11 +0000 Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework In-Reply-To: References: <4214ab2ac59143c3a726ad7419792a45@EX2.corp.digicert.com> <2f0cf1bb3e3c488ebf5e700d9629aa91@EX2.corp.digicert.com> Message-ID: <1c377341c18846f8b77a396438e97cf5@EX2.corp.digicert.com> Most of your comment is moot, because the work has already been done. That is why I focused on your comment about whether a particular section belongs in one section or another and responded that it could be moved. I suppose then that you are looking at the document and seeing lots of other items that belong somewhere else? I think Jeremy and I and the CP Review Working Group will be happy to accommodate such requests, but the stage we?re at now does not involve splitting sections up too much, although there are a couple of places where we?ve already done that without much trouble, such as in section 5.3.4. From: kirk_hall at trendmicro.com [mailto:kirk_hall at trendmicro.com] Sent: Tuesday, February 24, 2015 11:14 AM To: Ben Wilson; CABFPub Subject: RE: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Ben ? I was not arguing for any specific change. I was just raising the question of whether trying to fit the BRs into RFC 3647 created its own problems ? like where does a BR section go, and what should be done about a BR section that touches multiple sections of RFC 3647 (do you split up the current BR section, or just choose one place in the RFC 3647 format to put all the BR sections?). One other consideration ? there are many parts of the BRs (and EVGLs) that are not included in or relevant to a CA?s CPS ? they are either requirements, technical standards, or prohibitions, but they don?t have to be declared or included in a CPS. So in that sense, putting the BRs into RFC 3647 does not aid in review or comparison of CPSs across CAs, at least as to those sections? From: Ben Wilson [mailto:ben.wilson at digicert.com] Sent: Tuesday, February 24, 2015 10:02 AM To: Kirk Hall (RD-US); CABFPub Subject: RE: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework That is how the original from Jeremy was introduced with his email dated November 7, 2013, but I assume that it can be moved to section 2.2. From: kirk_hall at trendmicro.com [mailto:kirk_hall at trendmicro.com] Sent: Tuesday, February 24, 2015 9:52 AM To: Ben Wilson; CABFPub Subject: RE: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Ben ? first of all, thanks for the hard work on this one. I?m trying to figure out the benefit of locking the Forum into the RFC 3647 framework for the purpose of listing BR requirements. Is there really a benefit? Does it add to understanding and make CA compliance any easier? Or will it force us to put rules in odd places that actually make understanding a bit harder? I note the BR 8.2 already requires CAs to put their CPS into the format of RFC 2527 or 3647. See the first two sections of BR 8.2 below. That can facilitate comparison between the CPSs of different CAs, if anyone cares to do that. But is there any corresponding benefit from restructuring the BRs to an RFC 3647 format? What if a rule spans two or more different sections of the RFC 3647 format? I see that in your new organization of the BRs you have moved old BR 8.2.2 to a new Section 2.1 Repositories, not to new Section 2.2 Publication of Information. How did you make that choice? And is there an expectation that CAs will publish their CAA disclosure in new Sec. 2.2 of their CPS? I?m just afraid we will be handcuffing ourselves with these changes, and that there could be errors in internal cross-references. It is also a lot of work for everyone to review a complete rewrite of the BRs. Can you give us a convincing argument of why this is worth doing? Sorry I didn?t ask this question earlier, but I hadn?t really understood this was what the working group was doing ? I thought you were just looking for GAPS in the BRs as compared to the RFC 3647 where we could ADD new provisions to the BRs ? not a wholesale restructuring of the BRs. Thanks. BR 8.2.2 Disclosure The CA SHALL publicly disclose its Certificate Policy and/or Certification Practice Statement through an appropriate and readily accessible online means that is available on a 24x7 basis. The CA SHALL publicly disclose its CA business practices to the extent required by the CA?s selected audit scheme (see Section 17.1). The disclosures MUST include all the material required by RFC 2527 or RFC 3647, and MUST be structured in accordance with either RFC 2527 or RFC 3647. Effective as of 15 April 2015, section 4.2 of a CA's Certificate Policy and/or Certification Practice Statement (section 4.1 for CAs still conforming to RFC 2527) SHALL state whether the CA reviews CAA Records, and if so, the CA?s policy or practice on processing CAA Records for Fully Qualified Domain Names. The CA SHALL log all actions taken, if any, consistent with its processing practice. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ben Wilson Sent: Tuesday, February 24, 2015 7:22 AM To: CABFPub Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework The Certificate Policy Review Working Group was chartered by Ballot 128 to (i) consider existing and proposed standards, (ii) create a list of potential improvements based on the considered standards that improve the existing CAB Forum work product, (iii) evaluate the transition to a 3647 format based on the amount [of work involved]. One deliverable of the CP Review WG was to propose a ballot to improve CA infrastructure based on existing standards and documents and recommend whether to finish the 3647 conversion presented by Jeremy Rowley in January 2014. The CP Review WG has met and concluded that the best path forward for the Forum is to complete a conversion to the RFC 3647 for the Baseline Requirements with an initial step that merely moves existing content from the Baseline Requirements and the Network and Certificate System Security Requirements into the RFC 3647 format. Attached is an RFC-3647-formatted Certificate Policy for Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates. Comments embedded in the document contain either the source of the text (for content copied from the Baseline Requirements) or the current text (for provisions incorporated by reference from the Network and Certificate System Security Requirements ("NetSec"). It was decided that it was better to incorporate the NetSec requirements by reference rather than copying and pasting them in. In some limited instances the phrase "these Requirements" has been replaced with "this CP." However, "these Requirements" is mostly left in to preserve consistency with the current Baseline Requirements. Ben Wilson of DigiCert made the following motion, from and from have endorsed it. Motion Begins Be it resolved that the CA / Browser Forum adopts the attached CA/B Forum Certificate Policy v.1.2.5, effective immediately. Motion Ends The review period for this ballot shall commence at 2200 UTC on March 2015 and will close at 2200 UTC on March 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on March 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the ballot must indicate a clear ?yes? in the response. A vote against the ballot must indicate a clear ?no? in the response. A vote to abstain must indicate a clear ?abstain? in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/. In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and more than one half of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members? at least nine members must participate in the ballot, either by voting in favor, voting against, or by abstaining for the vote to be valid. TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4954 bytes Desc: not available URL: From i-barreira at izenpe.net Wed Feb 25 07:54:41 2015 From: i-barreira at izenpe.net (i-barreira at izenpe.net) Date: Wed, 25 Feb 2015 08:54:41 +0100 Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC3647 Framework Message-ID: <763539E260C37C46A0D6B340B5434C3B0AE7EA23@AEX06.ejsarea.net> This is something that I complained time ago basically due to the timing needed to adopt the EN, which is not the same than the TS. BTW, ETSI also mandates that the CP/CPS shall be structured according to the RFC 3647 I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. De: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] En nombre de kirk_hall at trendmicro.com Enviado el: martes, 24 de febrero de 2015 18:56 Para: Dean Coclin; Ben Wilson; CABFPub Asunto: Re: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC3647 Framework Fair point, but here is another consideration. Right now, all the WebTrust (and ETSI?) documents are laid out more or less in the same order as the current BRs and EVGL, and include references to the current numbering. If all numbering is changed, they will have to amend the WebTrust (and ETSI?) internal references ? maybe not a big deal ? but the order of the WebTrust requirements will no longer correspond to the order of the BRs. From: Dean Coclin [mailto:Dean_Coclin at symantec.com] Sent: Tuesday, February 24, 2015 8:59 AM To: Kirk Hall (RD-US); Ben Wilson; CABFPub Subject: RE: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Some of the beneficiaries are Browser root programs and relying parties. Having the BRs in this format makes it easier for Jody, Kathleen and others to review CPS? and compare to the sections in the BRs for compliance. Jeremy has already taken a pass at doing this and a draft has been circulated. Dean From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of kirk_hall at trendmicro.com Sent: Tuesday, February 24, 2015 11:52 AM To: Ben Wilson; CABFPub Subject: Re: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Ben ? first of all, thanks for the hard work on this one. I?m trying to figure out the benefit of locking the Forum into the RFC 3647 framework for the purpose of listing BR requirements. Is there really a benefit? Does it add to understanding and make CA compliance any easier? Or will it force us to put rules in odd places that actually make understanding a bit harder? I note the BR 8.2 already requires CAs to put their CPS into the format of RFC 2527 or 3647. See the first two sections of BR 8.2 below. That can facilitate comparison between the CPSs of different CAs, if anyone cares to do that. But is there any corresponding benefit from restructuring the BRs to an RFC 3647 format? What if a rule spans two or more different sections of the RFC 3647 format? I see that in your new organization of the BRs you have moved old BR 8.2.2 to a new Section 2.1 Repositories, not to new Section 2.2 Publication of Information. How did you make that choice? And is there an expectation that CAs will publish their CAA disclosure in new Sec. 2.2 of their CPS? I?m just afraid we will be handcuffing ourselves with these changes, and that there could be errors in internal cross-references. It is also a lot of work for everyone to review a complete rewrite of the BRs. Can you give us a convincing argument of why this is worth doing? Sorry I didn?t ask this question earlier, but I hadn?t really understood this was what the working group was doing ? I thought you were just looking for GAPS in the BRs as compared to the RFC 3647 where we could ADD new provisions to the BRs ? not a wholesale restructuring of the BRs. Thanks. BR 8.2.2 Disclosure The CA SHALL publicly disclose its Certificate Policy and/or Certification Practice Statement through an appropriate and readily accessible online means that is available on a 24x7 basis. The CA SHALL publicly disclose its CA business practices to the extent required by the CA?s selected audit scheme (see Section 17.1). The disclosures MUST include all the material required by RFC 2527 or RFC 3647, and MUST be structured in accordance with either RFC 2527 or RFC 3647. Effective as of 15 April 2015, section 4.2 of a CA's Certificate Policy and/or Certification Practice Statement (section 4.1 for CAs still conforming to RFC 2527) SHALL state whether the CA reviews CAA Records, and if so, the CA?s policy or practice on processing CAA Records for Fully Qualified Domain Names. The CA SHALL log all actions taken, if any, consistent with its processing practice. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ben Wilson Sent: Tuesday, February 24, 2015 7:22 AM To: CABFPub Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework The Certificate Policy Review Working Group was chartered by Ballot 128 to (i) consider existing and proposed standards, (ii) create a list of potential improvements based on the considered standards that improve the existing CAB Forum work product, (iii) evaluate the transition to a 3647 format based on the amount [of work involved]. One deliverable of the CP Review WG was to propose a ballot to improve CA infrastructure based on existing standards and documents and recommend whether to finish the 3647 conversion presented by Jeremy Rowley in January 2014. The CP Review WG has met and concluded that the best path forward for the Forum is to complete a conversion to the RFC 3647 for the Baseline Requirements with an initial step that merely moves existing content from the Baseline Requirements and the Network and Certificate System Security Requirements into the RFC 3647 format. Attached is an RFC-3647-formatted Certificate Policy for Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates. Comments embedded in the document contain either the source of the text (for content copied from the Baseline Requirements) or the current text (for provisions incorporated by reference from the Network and Certificate System Security Requirements ("NetSec"). It was decided that it was better to incorporate the NetSec requirements by reference rather than copying and pasting them in. In some limited instances the phrase "these Requirements" has been replaced with "this CP." However, "these Requirements" is mostly left in to preserve consistency with the current Baseline Requirements. Ben Wilson of DigiCert made the following motion, from and from have endorsed it. Motion Begins Be it resolved that the CA / Browser Forum adopts the attached CA/B Forum Certificate Policy v.1.2.5, effective immediately. Motion Ends The review period for this ballot shall commence at 2200 UTC on March 2015 and will close at 2200 UTC on March 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on March 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the ballot must indicate a clear ?yes? in the response. A vote against the ballot must indicate a clear ?no? in the response. A vote to abstain must indicate a clear ?abstain? in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ . In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and more than one half of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members? at least nine members must participate in the ballot, either by voting in favor, voting against, or by abstaining for the vote to be valid. TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 19121 bytes Desc: image001.png URL: From ben.wilson at digicert.com Wed Feb 25 16:16:01 2015 From: ben.wilson at digicert.com (Ben Wilson) Date: Wed, 25 Feb 2015 16:16:01 +0000 Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC3647 Framework In-Reply-To: <763539E260C37C46A0D6B340B5434C3B0AE7EA23@AEX06.ejsarea.net> References: <763539E260C37C46A0D6B340B5434C3B0AE7EA23@AEX06.ejsarea.net> Message-ID: <265dc2dc2f67410bb12f97b420b7c4dc@EX2.corp.digicert.com> I?igo, The Working Group did consider your previous comments during its deliberations. We?re willing to help out in whatever way we can with transitioning the necessary cross-references in ETSI documents to the new section numbers. Once this has been accomplished, though, I don?t? think we?ll be doing this kind of moving sections around again. Ben From: i-barreira at izenpe.net [mailto:i-barreira at izenpe.net] Sent: Wednesday, February 25, 2015 12:55 AM To: kirk_hall at trendmicro.com; Dean_Coclin at symantec.com; Ben Wilson; public at cabforum.org Subject: RE: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC3647 Framework This is something that I complained time ago basically due to the timing needed to adopt the EN, which is not the same than the TS. BTW, ETSI also mandates that the CP/CPS shall be structured according to the RFC 3647 I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. De: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] En nombre de kirk_hall at trendmicro.com Enviado el: martes, 24 de febrero de 2015 18:56 Para: Dean Coclin; Ben Wilson; CABFPub Asunto: Re: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC3647 Framework Fair point, but here is another consideration. Right now, all the WebTrust (and ETSI?) documents are laid out more or less in the same order as the current BRs and EVGL, and include references to the current numbering. If all numbering is changed, they will have to amend the WebTrust (and ETSI?) internal references ? maybe not a big deal ? but the order of the WebTrust requirements will no longer correspond to the order of the BRs. From: Dean Coclin [mailto:Dean_Coclin at symantec.com] Sent: Tuesday, February 24, 2015 8:59 AM To: Kirk Hall (RD-US); Ben Wilson; CABFPub Subject: RE: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Some of the beneficiaries are Browser root programs and relying parties. Having the BRs in this format makes it easier for Jody, Kathleen and others to review CPS? and compare to the sections in the BRs for compliance. Jeremy has already taken a pass at doing this and a draft has been circulated. Dean From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of kirk_hall at trendmicro.com Sent: Tuesday, February 24, 2015 11:52 AM To: Ben Wilson; CABFPub Subject: Re: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Ben ? first of all, thanks for the hard work on this one. I?m trying to figure out the benefit of locking the Forum into the RFC 3647 framework for the purpose of listing BR requirements. Is there really a benefit? Does it add to understanding and make CA compliance any easier? Or will it force us to put rules in odd places that actually make understanding a bit harder? I note the BR 8.2 already requires CAs to put their CPS into the format of RFC 2527 or 3647. See the first two sections of BR 8.2 below. That can facilitate comparison between the CPSs of different CAs, if anyone cares to do that. But is there any corresponding benefit from restructuring the BRs to an RFC 3647 format? What if a rule spans two or more different sections of the RFC 3647 format? I see that in your new organization of the BRs you have moved old BR 8.2.2 to a new Section 2.1 Repositories, not to new Section 2.2 Publication of Information. How did you make that choice? And is there an expectation that CAs will publish their CAA disclosure in new Sec. 2.2 of their CPS? I?m just afraid we will be handcuffing ourselves with these changes, and that there could be errors in internal cross-references. It is also a lot of work for everyone to review a complete rewrite of the BRs. Can you give us a convincing argument of why this is worth doing? Sorry I didn?t ask this question earlier, but I hadn?t really understood this was what the working group was doing ? I thought you were just looking for GAPS in the BRs as compared to the RFC 3647 where we could ADD new provisions to the BRs ? not a wholesale restructuring of the BRs. Thanks. BR 8.2.2 Disclosure The CA SHALL publicly disclose its Certificate Policy and/or Certification Practice Statement through an appropriate and readily accessible online means that is available on a 24x7 basis. The CA SHALL publicly disclose its CA business practices to the extent required by the CA?s selected audit scheme (see Section 17.1). The disclosures MUST include all the material required by RFC 2527 or RFC 3647, and MUST be structured in accordance with either RFC 2527 or RFC 3647. Effective as of 15 April 2015, section 4.2 of a CA's Certificate Policy and/or Certification Practice Statement (section 4.1 for CAs still conforming to RFC 2527) SHALL state whether the CA reviews CAA Records, and if so, the CA?s policy or practice on processing CAA Records for Fully Qualified Domain Names. The CA SHALL log all actions taken, if any, consistent with its processing practice. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ben Wilson Sent: Tuesday, February 24, 2015 7:22 AM To: CABFPub Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework The Certificate Policy Review Working Group was chartered by Ballot 128 to (i) consider existing and proposed standards, (ii) create a list of potential improvements based on the considered standards that improve the existing CAB Forum work product, (iii) evaluate the transition to a 3647 format based on the amount [of work involved]. One deliverable of the CP Review WG was to propose a ballot to improve CA infrastructure based on existing standards and documents and recommend whether to finish the 3647 conversion presented by Jeremy Rowley in January 2014. The CP Review WG has met and concluded that the best path forward for the Forum is to complete a conversion to the RFC 3647 for the Baseline Requirements with an initial step that merely moves existing content from the Baseline Requirements and the Network and Certificate System Security Requirements into the RFC 3647 format. Attached is an RFC-3647-formatted Certificate Policy for Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates. Comments embedded in the document contain either the source of the text (for content copied from the Baseline Requirements) or the current text (for provisions incorporated by reference from the Network and Certificate System Security Requirements ("NetSec"). It was decided that it was better to incorporate the NetSec requirements by reference rather than copying and pasting them in. In some limited instances the phrase "these Requirements" has been replaced with "this CP." However, "these Requirements" is mostly left in to preserve consistency with the current Baseline Requirements. Ben Wilson of DigiCert made the following motion, from and from have endorsed it. Motion Begins Be it resolved that the CA / Browser Forum adopts the attached CA/B Forum Certificate Policy v.1.2.5, effective immediately. Motion Ends The review period for this ballot shall commence at 2200 UTC on March 2015 and will close at 2200 UTC on March 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on March 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the ballot must indicate a clear ?yes? in the response. A vote against the ballot must indicate a clear ?no? in the response. A vote to abstain must indicate a clear ?abstain? in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/. In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and more than one half of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members? at least nine members must participate in the ballot, either by voting in favor, voting against, or by abstaining for the vote to be valid. TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 19121 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4954 bytes Desc: not available URL: From ben.wilson at digicert.com Wed Feb 25 16:25:52 2015 From: ben.wilson at digicert.com (Ben Wilson) Date: Wed, 25 Feb 2015 16:25:52 +0000 Subject: [cabfpub] TurkTrust Root Renewal Request In-Reply-To: References: <20150218143046.4087891.82163.380@gmail.com> <20150218220100.4087891.76539.386@gmail.com> <20150219134909.4087891.28047.389@gmail.com> <20150225135154.4087891.14518.423@gmail.com> Message-ID: <3254c639926841ba86a367c16ee4ce51@EX2.corp.digicert.com> One practice that the CA/B Forum should consider is to forward select comments on proposed guidelines from the questions list over to the public list, but because of the IPR Policy concerns that it creates, the practice should include mitigations for third parties (not bound to the IPR Policy) injecting protected IP into the Forum's workstream. However, because I think the risk of that is small, I think it should be allowed as long as CABF members police themselves. -----Original Message----- From: dev-security-policy [mailto:dev-security-policy-bounces+ben=digicert.com at lists.mozilla.org] On Behalf Of Steve Roylance Sent: Wednesday, February 25, 2015 9:10 AM To: Peter Bowen Cc: fhw843 at gmail.com; mozilla-dev-security-policy at lists.mozilla.org; Kathleen Wilson Subject: RE: TurkTrust Root Renewal Request Thanks Peter. Yes my bad.. https://cabforum.org/current-work/code-signing-working-group/ has the questions e-mail at the bottom of the page. Steve > -----Original Message----- > From: dev-security-policy [mailto:dev-security-policy- > bounces+steve.roylance=globalsign.com at lists.mozilla.org] On Behalf Of > bounces+Peter > Bowen > Sent: 26 February 2015 00:00 > To: Steve Roylance > Cc: fhw843 at gmail.com; mozilla-dev-security-policy at lists.mozilla.org; > Kathleen Wilson > Subject: RE: TurkTrust Root Renewal Request > > Steve, > > Unless Peter is a member of the forum, the public list is a black > hole, as only members can post. The alternative, the questions list, > is not publicly readable, so is also a bad choice for open discussion. > > Therefore, while this thread is not the appropriate place, this forum > is probably the best place. > > Thanks, > Peter > On Feb 25, 2015 7:04 AM, "Steve Roylance" > > wrote: > > > Hi Peter. > > > > To better answer the issues you've raised, I'd suggest sending this > > topic to the public list in the CABforum. I'm not in the codesiging working > > group so I'm unable to help directly with answers to your points. I've > > not forwarded this mail as I'd rather that come directly from you. > > Details > > here:- https://cabforum.org/mailman/listinfo/public > > > > Not dodging the bullet, just highlighting a better target ;-) > > > > Steve > > > > > > > -----Original Message----- > > > From: Peter Kurrasch [mailto:fhw843 at gmail.com] > > > Sent: 25 February 2015 21:52 > > > To: Steve Roylance > > > Cc: Kathleen Wilson; mozilla-dev-security-policy at lists.mozilla.org > > > Subject: Re: TurkTrust Root Renewal Request > > > > > > Thanks for putting that together, Steve. Reading through the doc > > > it > > appears that > > > some of my concerns are addressed but I do have a few questions yet: > > > > > > 1) I saw that tucked away in section 10.3.2 item #3 is "key reuse" > > > but > > all it says is > > > "you have to promise not to do it". Is there any solid enforcement > > > for > > this, above > > > and beyond the "we found out about it" clause in section 13.1.5 > > > item > > > #4 > > or #6? > > > > > > 2) Is there a particular reason to not mention the prohibition on > > > key > > reuse in > > > section 9.5? > > > > > > 3) All of the EKU sections in Appendix B have a loophole for > > > companies > > that have > > > some sort of platform specific need to include other CA values, > > > but I > > don't know > > > what those use cases look like. From my standpoint it's more > > > secure for > > everyone > > > to have hard and fast rules for rigorous enforcement of security > > policies. As > > > written, such rigor goes out the window. Do you know of any good > > examples why > > > the loophole is necessary? > > > > > > > > > Bringing this discussion back to TurkTrust's request: > > > > > > 4) When might CABF approve the requirements and when might cert > > > issuers > > be > > > expected to comply? > > > > > > 5) What is reasonable to ask of TurkTrust to spell out in CP/CPS > > documents in > > > conjunction with this current request? I think it's reasonable to > > > ask > > for them to just > > > say what policies they plan to enforce. If they have no plans to > > > impose > > limits on > > > EKU's then just say it--give me a chance as an end user to make an > > informed > > > decision when I come across certs chained to their root. > > > > > > ? > > > > > > -------- Original Message -------- > > > From: Steve Roylance > > > Sent: Saturday, February 21, 2015 2:59 PM ? > > > > > > Hi Peter. > > > > > > I double checked, and everything looks good for the future (Please > > > see > > the > > > attached proposed Code Signing Requirements which has been > > > publically released by the CABForum) > > > > > > Specifically see Appendix B section F which covers MUST > > > requirements for > > CAs > > > and as such alleviates your concerns in that 'Server Auth' is not > > allowed to coexist > > > with code signing so it's not necessary to segregate by Root CA as > > > it's > > going to be > > > mandatory to segregate by issuing CA.. > > > > > > F. extkeyUsage (EKU) > > > The id-kp-codeSigning [RFC5280] value MUST be present. > > > The following EKUs MAY be present: documentSigning and emailProtection. > > > The value anyExtendedKeyUsage (2.5.29.37.0) MUST NOT be present. > > > Other values SHOULD NOT be present. If any other value is present, > > > the CA MUST have a business agreement with a Platform vendor > > > requiring that EKU > > in > > > order to issue a Platform-specific code signing certificate with > > > that > > EKU. > > > This extension SHOULD be marked non-critical. > > > The CA MUST set all other fields and extensions in accordance to > > > RFC > > 5280. > > > > > > Steve > > > > > > > -----Original Message----- > > > > From: Peter Kurrasch [mailto:fhw843 at gmail.com] > > > > Sent: 19 February 2015 13:49 > > > > To: Steve Roylance > > > > Cc: Kathleen Wilson; > > > > mozilla-dev-security-policy at lists.mozilla.org > > > > Subject: Re: TurkTrust Root Renewal Request > > > > > > > > My preference is to have key separation explicitly addressed by > > > > Mozilla and CABForum. From strictly a security perspective > > > > sharing keys is an all risk, no reward ?proposition. The only > > > > advantage I can see is in terms of convenience in different ways. > > > > > > > > I offer the following options for consideration: > > > > > > > > Bare minimum: for any ?root cert which intends to be used for > > > > both SSL and code, the CA shall provide a statement in the > > > > CP/CPS regarding any plans they have to limit end/leaf certs > > > > from having both EKU's. If it's just a policy thing or if an > > > > intermediate will provide a > > technical enforcement > > > mechanism, just write it down. > > > > If there is no plan/policy, just state that too. > > > > > > > > Minimum: enact a policy to disallow both EKU's from being used > > > > in a single end- entity cert. > > > > > > > > Better: separate intermediates are utilized for SSL and code. > > > > > > > > Ideal: separate roots for both SSL and code. > > > > > > > > The reason I favor something more than just policy statements > > > > are because people can make mistakes and should that happen it > > > > would be good to have the technical backstop. > > > > > > > > > > > > Kathleen--Would you feel comfortable asking TurkTrust to provide > > > > a statement clarifying their plans or intentions ?regarding these EKU's? > > > > > > > > Original Message > > > > From: Steve Roylance > > > > Sent: Wednesday, February 18, 2015 4:36 PM > > > > To: Peter Kurrasch > > > > Cc: Kathleen Wilson; > > > > mozilla-dev-security-policy at lists.mozilla.org > > > > Subject: Re: TurkTrust Root Renewal Request > > > > > > > > > > > > > On 18 Feb 2015, at 22:01, Peter Kurrasch wrote: > > > > > > > > > > ?Thanks for the update, Steve. Is there a requirement (current > > > > > or > > > > > forthcoming) for > > > > the CA to document how such segregation will be performed--or > > > > that there even is a plan to perform it? I didn't see any such > > > > language in the CP or CPS provided by TurkTrust so I don't know > > > > what they plan to > > do. > > > > > > > > > > > > > I don't know of any formal plans by CABForum to stipulate segregation. > > > > AFAIK it just happens naturally. Maybe if people feel strongly > > > > that can be looked at through enforced EKU usage in > > > > intermediates, however that sort of change would take far longer > > > > to enact due to the validity of intermediates being approx 10 > > > > years and the fact it's another > > slight against > > > RFC5280. > > > > > > > > > The risk I have in mind is when a server gets compromised thus > > > > > exposing the private keys. If the keys can be used to sign > > > > > objects I can then ?turn around and use them to sign malware and so forth. > > > > > What could be just a minor breach then becomes a bigger problem. > > > > > (I think we should assume that server compromises are a "regular" > > > > > occurrence even though we might not know how many or how often > > > > > or how serious they are.) > > > > > > > > > > > > > Here we are are all OK, as you are taking about end > > > > entities/leaf certificates and they always have the relevant EKU > > > > added by the CA so I don't see this as an issue. > > > > > > > > > I would argue that the best strategy is to have forced > > > > > separation at the root level, > > > > but I can appreciate that there are limits on the number of > > > > roots that ?CAs are allowed to submit. > > > > > > > > > > > > > > > Original Message > > > > > From: Steve Roylance > > > > > Sent: Wednesday, February 18, 2015 9:18 AM > > > > > To: Peter Kurrasch > > > > > Cc: Kathleen Wilson; > > > > > mozilla-dev-security-policy at lists.mozilla.org > > > > > Subject: RE: TurkTrust Root Renewal Request > > > > > > > > > > Hi Peter, > > > > > > > > > > In general this would be true if issuance of either or both > > > > > types of end entity > > > > certificate were directly from the same Root, however CA's, as > > > > best practice and from a product line perspective, segregate the > > > > usage of any end entity certificate types through an > > > > intermediate CA. In fact this is now mandated by the Baseline > > > > Requirements for SSL and forthcoming CodeSIgning requirements. > > > > Whilst any intermediate CA may or may not necessarily have EKUs > > > > which provide further protection, the additional hierarchical > > > > layer and key materials used offer the > > necessary > > > protection overall. > > > > > > > > > > The other reason is that Root Stores generally place a limit > > > > > on the number of > > > > Roots which can be entered so CA's need to be able to maximize > > > > their usage, especially where we are today with ongoing > > > > transitions in cryptography standards and key sizes. > > > > > > > > > > I hope that helps. > > > > > > > > > > Steve > > > > > > > > > >> -----Original Message----- > > > > >> From: dev-security-policy [mailto:dev-security-policy- > > > > >> bounces+steve.roylance=globalsign.com at lists.mozilla.org] On > > > > >> bounces+Behalf Of Peter > > > > >> Kurrasch > > > > >> Sent: 18 February 2015 14:31 > > > > >> To: Kathleen Wilson; > > > > >> mozilla-dev-security-policy at lists.mozilla.org > > > > >> Subject: Re: TurkTrust Root Renewal Request > > > > >> > > > > >> ?Allowing a single cert to be used for both websites and code > > > > >> signing is a dangerous proposition. What is the current > > > > >> thinking among the > > > > community? > > > > >> > > > > >> > > > > >> Original Message > > > > >> From: Kathleen Wilson > > > > >> Sent: Thursday, February 12, 2015 12:31 PM > > > > >> To: mozilla-dev-security-policy at lists.mozilla.org > > > > >> Subject: TurkTrust Root Renewal Request > > > > >> > > > > >> TurkTrust has applied to include the SHA-256 "T?RKTRUST > > > > >> Elektronik Sertifika Hizmet Sa?lay?c?s? H5" and "T?RKTRUST > > > > >> Elektronik Sertifika Hizmet Sa?lay?c?s? H6" root > > > > >> certificates; turn on the Websites trust bit for both roots, > > > > >> turn on the Code Signing trust bit for the H5 root, and > > > > >> enable > > > > EV treatment for the H6 root. > > > > >> TurkTrust's SHA-1 root certificates were included in NSS via > > > > >> Bugzilla Bug > > > > >> #380635 and Bug #433845. > > > > >> > > > > >> ? > > > > >> _______________________________________________ > > > > >> dev-security-policy mailing list > > > > >> dev-security-policy at lists.mozilla.org > > > > >> https://lists.mozilla.org/listinfo/dev-security-policy > > > > _______________________________________________ > > dev-security-policy mailing list > > dev-security-policy at lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-security-policy > > > > > _______________________________________________ > dev-security-policy mailing list > dev-security-policy at lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4954 bytes Desc: not available URL: From i-barreira at izenpe.net Wed Feb 25 16:30:56 2015 From: i-barreira at izenpe.net (=?UTF-8?B?IkJhcnJlaXJhIElnbGVzaWFzLCBJw7FpZ28i?=) Date: Wed, 25 Feb 2015 17:30:56 +0100 Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline RequirementstoRFC3647 Framework Message-ID: <14g8suajpk83brdupqug404t.1424881854376@email.android.com> Yes, i know. ?I've been working on it :-) My concern is when i had to update the EN and the time we can have to do it. OTOH, in ETSI we're also thinking on the same idea Enviado de Samsung Mobile -------- Mensaje original -------- De: Ben Wilson Fecha: Para: i-barreira at izenpe.net,kirk_hall at trendmicro.com,Dean_Coclin at symantec.com,public at cabforum.org Asunto: RE: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements toRFC3647 Framework I?igo, The Working Group did consider your previous comments during its deliberations.? We?re willing to help out in whatever way we can with transitioning the necessary cross-references in ETSI documents to the new section numbers.? Once this has been accomplished, though, I don?t? think we?ll be doing this kind of moving sections around again.? Ben ? From: i-barreira at izenpe.net [mailto:i-barreira at izenpe.net] Sent: Wednesday, February 25, 2015 12:55 AM To: kirk_hall at trendmicro.com; Dean_Coclin at symantec.com; Ben Wilson; public at cabforum.org Subject: RE: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC3647 Framework ? This is something that I complained time ago basically due to the timing needed to adopt the EN, which is not the same than the TS. BTW, ETSI also mandates that the CP/CPS shall be structured according to the RFC 3647 ? ? I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 ? ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. ? De: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] En nombre de kirk_hall at trendmicro.com Enviado el: martes, 24 de febrero de 2015 18:56 Para: Dean Coclin; Ben Wilson; CABFPub Asunto: Re: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC3647 Framework ? Fair point, but here is another consideration. ?Right now, all the WebTrust (and ETSI?) documents are laid out more or less in the same order as the current BRs and EVGL, and include references to the current numbering.? If all numbering is changed, they will have to amend the WebTrust (and ETSI?) internal references ? maybe not a big deal ? but the order of the WebTrust requirements will no longer correspond to the order of the BRs. ? From: Dean Coclin [mailto:Dean_Coclin at symantec.com] Sent: Tuesday, February 24, 2015 8:59 AM To: Kirk Hall (RD-US); Ben Wilson; CABFPub Subject: RE: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework ? Some of the beneficiaries are Browser root programs and relying parties. Having the BRs in this format makes it easier for Jody, Kathleen and others to review CPS? and compare to the sections in the BRs for compliance. ? ? Jeremy has already taken a pass at doing this and a draft has been circulated. ? Dean ? From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of kirk_hall at trendmicro.com Sent: Tuesday, February 24, 2015 11:52 AM To: Ben Wilson; CABFPub Subject: Re: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework ? Ben ? first of all, thanks for the hard work on this one. ? I?m trying to figure out the benefit of locking the Forum into the RFC 3647 framework for the purpose of listing BR requirements.? Is there really a benefit?? Does it add to understanding and make CA compliance any easier?? Or will it force us to put rules in odd places that actually make understanding a bit harder? ? I note the BR 8.2 already requires CAs to put their CPS into the format of RFC 2527 or 3647.? See the first two sections of BR 8.2 below.? That can facilitate comparison between the CPSs of different CAs, if anyone cares to do that.? But is there any corresponding benefit from restructuring the BRs to an RFC 3647 format?? What if a rule spans two or more different sections of the RFC 3647 format? ? I see that in your new organization of the BRs you have moved old BR 8.2.2 to a new Section 2.1 Repositories, not to new Section 2.2 Publication of Information.? How did you make that choice?? And is there an expectation that CAs will publish their CAA disclosure in new Sec. 2.2 of their CPS? ? I?m just afraid we will be handcuffing ourselves with these changes, and that there could be errors in internal cross-references.? It is also a lot of work for everyone to review a complete rewrite of the BRs. ? Can you give us a convincing argument of why this is worth doing?? Sorry I didn?t ask this question earlier, but I hadn?t really understood this was what the working group was doing ? I thought you were just looking for GAPS in the BRs as compared to the RFC 3647 where we could ADD new provisions to the BRs ? not a wholesale restructuring of the BRs. ? Thanks. ? BR 8.2.2 Disclosure The CA SHALL publicly disclose its Certificate Policy and/or Certification Practice Statement through an appropriate and readily accessible online means that is available on a 24x7 basis. The CA SHALL publicly disclose its CA business practices to the extent required by the CA?s selected audit scheme (see Section 17.1). The disclosures MUST include all the material required by RFC 2527 or RFC 3647, and MUST be structured in accordance with either RFC 2527 or RFC 3647. Effective as of 15 April 2015, section 4.2 of a CA's Certificate Policy and/or Certification Practice Statement (section 4.1 for CAs still conforming to RFC 2527) SHALL state whether the CA reviews CAA Records, and if so, the CA?s policy or practice on processing CAA Records for Fully Qualified Domain Names. The CA SHALL log all actions taken, if any, consistent with its processing practice. ? From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ben Wilson Sent: Tuesday, February 24, 2015 7:22 AM To: CABFPub Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework ? Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework The Certificate Policy Review Working Group was chartered by Ballot 128 to (i) consider existing and proposed standards, (ii) create a list of potential improvements based on the considered standards that improve the existing CAB Forum work product, (iii) evaluate the transition to a 3647 format based on the amount [of work involved]. One deliverable of the CP Review WG was to propose a ballot to improve CA infrastructure based on existing standards and documents and recommend whether to finish the 3647 conversion presented by Jeremy Rowley in January 2014. The CP Review WG has met and concluded that the best path forward for the Forum is to complete a conversion to the RFC 3647 for the Baseline Requirements with an initial step that merely moves existing content from the Baseline Requirements and the Network and Certificate System Security Requirements into the RFC 3647 format. Attached is an RFC-3647-formatted Certificate Policy for Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates. Comments embedded in the document contain either the source of the text (for content copied from the Baseline Requirements) or the current text (for provisions incorporated by reference from the Network and Certificate System Security Requirements ("NetSec"). It was decided that it was better to incorporate the NetSec requirements by reference rather than copying and pasting them in. In some limited instances the phrase "these Requirements" has been replaced with "this CP." However, "these Requirements" is mostly left in to preserve consistency with the current Baseline Requirements. Ben Wilson of DigiCert made the following motion, from and from have endorsed it. Motion Begins Be it resolved that the CA / Browser Forum adopts the attached CA/B Forum Certificate Policy v.1.2.5, effective immediately. Motion Ends The review period for this ballot shall commence at 2200 UTC on March 2015 and will close at 2200 UTC on March 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on March 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the ballot must indicate a clear ?yes? in the response. A vote against the ballot must indicate a clear ?no? in the response. A vote to abstain must indicate a clear ?abstain? in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/. In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and more than one half of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members? at least nine members must participate in the ballot, either by voting in favor, voting against, or by abstaining for the vote to be valid. ? ? TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. ? ? TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirk_hall at trendmicro.com Wed Feb 25 17:51:49 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Wed, 25 Feb 2015 17:51:49 +0000 Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC3647 Framework In-Reply-To: <265dc2dc2f67410bb12f97b420b7c4dc@EX2.corp.digicert.com> References: <763539E260C37C46A0D6B340B5434C3B0AE7EA23@AEX06.ejsarea.net> <265dc2dc2f67410bb12f97b420b7c4dc@EX2.corp.digicert.com> Message-ID: Ben, out of curiosity ? did the Working Group consider simply making cross reference tables correlating the current BRs (and EVGL) and the RFC 3647 CPS framework? So that if a browser wanted to see which BR sections were relevant to a CPS in RFC 3647 format (and vice versa), they could just consult the table? It seems that would have been a simpler approach, and would recognize that a lot of the BRs are not relevant to a CA?s CPS or CPS format. From: Ben Wilson [mailto:ben.wilson at digicert.com] Sent: Wednesday, February 25, 2015 8:16 AM To: i-barreira at izenpe.net; Kirk Hall (RD-US); Dean_Coclin at symantec.com; public at cabforum.org Subject: RE: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC3647 Framework I?igo, The Working Group did consider your previous comments during its deliberations. We?re willing to help out in whatever way we can with transitioning the necessary cross-references in ETSI documents to the new section numbers. Once this has been accomplished, though, I don?t? think we?ll be doing this kind of moving sections around again. Ben From: i-barreira at izenpe.net [mailto:i-barreira at izenpe.net] Sent: Wednesday, February 25, 2015 12:55 AM To: kirk_hall at trendmicro.com; Dean_Coclin at symantec.com; Ben Wilson; public at cabforum.org Subject: RE: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC3647 Framework This is something that I complained time ago basically due to the timing needed to adopt the EN, which is not the same than the TS. BTW, ETSI also mandates that the CP/CPS shall be structured according to the RFC 3647 I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 [Descripci?n: cid:image001.png at 01CE3152.B4804EB0] ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. De: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] En nombre de kirk_hall at trendmicro.com Enviado el: martes, 24 de febrero de 2015 18:56 Para: Dean Coclin; Ben Wilson; CABFPub Asunto: Re: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC3647 Framework Fair point, but here is another consideration. Right now, all the WebTrust (and ETSI?) documents are laid out more or less in the same order as the current BRs and EVGL, and include references to the current numbering. If all numbering is changed, they will have to amend the WebTrust (and ETSI?) internal references ? maybe not a big deal ? but the order of the WebTrust requirements will no longer correspond to the order of the BRs. From: Dean Coclin [mailto:Dean_Coclin at symantec.com] Sent: Tuesday, February 24, 2015 8:59 AM To: Kirk Hall (RD-US); Ben Wilson; CABFPub Subject: RE: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Some of the beneficiaries are Browser root programs and relying parties. Having the BRs in this format makes it easier for Jody, Kathleen and others to review CPS? and compare to the sections in the BRs for compliance. Jeremy has already taken a pass at doing this and a draft has been circulated. Dean From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of kirk_hall at trendmicro.com Sent: Tuesday, February 24, 2015 11:52 AM To: Ben Wilson; CABFPub Subject: Re: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Ben ? first of all, thanks for the hard work on this one. I?m trying to figure out the benefit of locking the Forum into the RFC 3647 framework for the purpose of listing BR requirements. Is there really a benefit? Does it add to understanding and make CA compliance any easier? Or will it force us to put rules in odd places that actually make understanding a bit harder? I note the BR 8.2 already requires CAs to put their CPS into the format of RFC 2527 or 3647. See the first two sections of BR 8.2 below. That can facilitate comparison between the CPSs of different CAs, if anyone cares to do that. But is there any corresponding benefit from restructuring the BRs to an RFC 3647 format? What if a rule spans two or more different sections of the RFC 3647 format? I see that in your new organization of the BRs you have moved old BR 8.2.2 to a new Section 2.1 Repositories, not to new Section 2.2 Publication of Information. How did you make that choice? And is there an expectation that CAs will publish their CAA disclosure in new Sec. 2.2 of their CPS? I?m just afraid we will be handcuffing ourselves with these changes, and that there could be errors in internal cross-references. It is also a lot of work for everyone to review a complete rewrite of the BRs. Can you give us a convincing argument of why this is worth doing? Sorry I didn?t ask this question earlier, but I hadn?t really understood this was what the working group was doing ? I thought you were just looking for GAPS in the BRs as compared to the RFC 3647 where we could ADD new provisions to the BRs ? not a wholesale restructuring of the BRs. Thanks. BR 8.2.2 Disclosure The CA SHALL publicly disclose its Certificate Policy and/or Certification Practice Statement through an appropriate and readily accessible online means that is available on a 24x7 basis. The CA SHALL publicly disclose its CA business practices to the extent required by the CA?s selected audit scheme (see Section 17.1). The disclosures MUST include all the material required by RFC 2527 or RFC 3647, and MUST be structured in accordance with either RFC 2527 or RFC 3647. Effective as of 15 April 2015, section 4.2 of a CA's Certificate Policy and/or Certification Practice Statement (section 4.1 for CAs still conforming to RFC 2527) SHALL state whether the CA reviews CAA Records, and if so, the CA?s policy or practice on processing CAA Records for Fully Qualified Domain Names. The CA SHALL log all actions taken, if any, consistent with its processing practice. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ben Wilson Sent: Tuesday, February 24, 2015 7:22 AM To: CABFPub Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework The Certificate Policy Review Working Group was chartered by Ballot 128 to (i) consider existing and proposed standards, (ii) create a list of potential improvements based on the considered standards that improve the existing CAB Forum work product, (iii) evaluate the transition to a 3647 format based on the amount [of work involved]. One deliverable of the CP Review WG was to propose a ballot to improve CA infrastructure based on existing standards and documents and recommend whether to finish the 3647 conversion presented by Jeremy Rowley in January 2014. The CP Review WG has met and concluded that the best path forward for the Forum is to complete a conversion to the RFC 3647 for the Baseline Requirements with an initial step that merely moves existing content from the Baseline Requirements and the Network and Certificate System Security Requirements into the RFC 3647 format. Attached is an RFC-3647-formatted Certificate Policy for Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates. Comments embedded in the document contain either the source of the text (for content copied from the Baseline Requirements) or the current text (for provisions incorporated by reference from the Network and Certificate System Security Requirements ("NetSec"). It was decided that it was better to incorporate the NetSec requirements by reference rather than copying and pasting them in. In some limited instances the phrase "these Requirements" has been replaced with "this CP." However, "these Requirements" is mostly left in to preserve consistency with the current Baseline Requirements. Ben Wilson of DigiCert made the following motion, from and from have endorsed it. Motion Begins Be it resolved that the CA / Browser Forum adopts the attached CA/B Forum Certificate Policy v.1.2.5, effective immediately. Motion Ends The review period for this ballot shall commence at 2200 UTC on March 2015 and will close at 2200 UTC on March 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on March 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the ballot must indicate a clear ?yes? in the response. A vote against the ballot must indicate a clear ?no? in the response. A vote to abstain must indicate a clear ?abstain? in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/. In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and more than one half of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members? at least nine members must participate in the ballot, either by voting in favor, voting against, or by abstaining for the vote to be valid. TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
-------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 19121 bytes Desc: image001.png URL: From dosheehy at deloitte.ca Wed Feb 25 18:07:13 2015 From: dosheehy at deloitte.ca (Sheehy, Don (CA - Toronto)) Date: Wed, 25 Feb 2015 18:07:13 +0000 Subject: [cabfpub] When did the WebTrust/ETSI BR audit requirement become mandatory? In-Reply-To: <54E7AF26.8000706@startcom.org> References: <54E7A2AE.2040501@startcom.org> <54E7AF26.8000706@startcom.org> Message-ID: If one remembers the discussion that we had at the face to face and others , one would remember that there are CAs that are NOT public and NOT part of the trusted root programs that do not require the additional baseline audit. Given that, a merger into one set of standards is unlikely in the near future ( unless we decide to create WebTrust Pubic and non-public versions ? but that is unlikely). So at present you need to meet WebTrust and WebTrust BR + WebTrust EV ( If applicable). If your reporting year starts after last June 30 you will also need to meet the Network Security requirements. Don Donald E. Sheehy, CPA, CA, CISA, CRISC, CIPP/C, CITP Partner | Enterprise Risk Deloitte From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Eddy Nigg Sent: Friday, February 20, 2015 5:03 PM To: kirk_hall at trendmicro.com; i-barreira; Peter Bowen; public at cabforum.org Subject: Re: [cabfpub] When did the WebTrust/ETSI BR audit requirement become mandatory? On 02/20/2015 11:45 PM, kirk_hall at trendmicro.com wrote: When you say ?why? ? do you mean ?is regular WebTrust still required?? (it is, along with BR WebTrust), or are you suggesting that regular WebTrust should no longer be a requirement, just BR WebTrust? I certainly would expect that this will become one (basic) audit eventually (and EV and others optional). -- Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. XMPP: startcom at startcom.org Blog: Join the Revolution! Twitter: Follow Me Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s), are confidential, and may be privileged. If you are not the intended recipient, you are hereby notified that any review, retransmission, conversion to hard copy, copying, circulation or other use of this message and any attachments is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, and delete this message and any attachments from your system. Thank You If you do not wish to receive future commercial electronic messages from Deloitte, forward this email to unsubscribe at deloitte.ca Avertissement de confidentialit?: Ce message, ainsi que toutes ses pi?ces jointes, est destin? exclusivement au(x) destinataire(s) pr?vu(s), est confidentiel et peut contenir des renseignements privil?gi?s. Si vous n??tes pas le destinataire pr?vu de ce message, nous vous avisons par la pr?sente que la modification, la retransmission, la conversion en format papier, la reproduction, la diffusion ou toute autre utilisation de ce message et de ses pi?ces jointes sont strictement interdites. Si vous n??tes pas le destinataire pr?vu, veuillez en aviser imm?diatement l?exp?diteur en r?pondant ? ce courriel et supprimez ce message et toutes ses pi?ces jointes de votre syst?me. Merci. Si vous ne voulez pas recevoir d?autres messages ?lectroniques commerciaux de Deloitte ? l?avenir, veuillez envoyer ce courriel ? l?adresse unsubscribe at deloitte.ca -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.wilson at digicert.com Wed Feb 25 18:18:37 2015 From: ben.wilson at digicert.com (Ben Wilson) Date: Wed, 25 Feb 2015 18:18:37 +0000 Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC3647 Framework In-Reply-To: References: <763539E260C37C46A0D6B340B5434C3B0AE7EA23@AEX06.ejsarea.net> <265dc2dc2f67410bb12f97b420b7c4dc@EX2.corp.digicert.com> Message-ID: <19c62260d34c43c1bd93a1231808ed2d@EX2.corp.digicert.com> Yes ? and those charts were distributed. From: kirk_hall at trendmicro.com [mailto:kirk_hall at trendmicro.com] Sent: Wednesday, February 25, 2015 10:52 AM To: Ben Wilson; i-barreira at izenpe.net; Dean_Coclin at symantec.com; public at cabforum.org Subject: RE: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC3647 Framework Ben, out of curiosity ? did the Working Group consider simply making cross reference tables correlating the current BRs (and EVGL) and the RFC 3647 CPS framework? So that if a browser wanted to see which BR sections were relevant to a CPS in RFC 3647 format (and vice versa), they could just consult the table? It seems that would have been a simpler approach, and would recognize that a lot of the BRs are not relevant to a CA?s CPS or CPS format. From: Ben Wilson [mailto:ben.wilson at digicert.com] Sent: Wednesday, February 25, 2015 8:16 AM To: i-barreira at izenpe.net ; Kirk Hall (RD-US); Dean_Coclin at symantec.com ; public at cabforum.org Subject: RE: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC3647 Framework I?igo, The Working Group did consider your previous comments during its deliberations. We?re willing to help out in whatever way we can with transitioning the necessary cross-references in ETSI documents to the new section numbers. Once this has been accomplished, though, I don?t? think we?ll be doing this kind of moving sections around again. Ben From: i-barreira at izenpe.net [mailto:i-barreira at izenpe.net] Sent: Wednesday, February 25, 2015 12:55 AM To: kirk_hall at trendmicro.com ; Dean_Coclin at symantec.com ; Ben Wilson; public at cabforum.org Subject: RE: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC3647 Framework This is something that I complained time ago basically due to the timing needed to adopt the EN, which is not the same than the TS. BTW, ETSI also mandates that the CP/CPS shall be structured according to the RFC 3647 I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. De: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] En nombre de kirk_hall at trendmicro.com Enviado el: martes, 24 de febrero de 2015 18:56 Para: Dean Coclin; Ben Wilson; CABFPub Asunto: Re: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC3647 Framework Fair point, but here is another consideration. Right now, all the WebTrust (and ETSI?) documents are laid out more or less in the same order as the current BRs and EVGL, and include references to the current numbering. If all numbering is changed, they will have to amend the WebTrust (and ETSI?) internal references ? maybe not a big deal ? but the order of the WebTrust requirements will no longer correspond to the order of the BRs. From: Dean Coclin [mailto:Dean_Coclin at symantec.com] Sent: Tuesday, February 24, 2015 8:59 AM To: Kirk Hall (RD-US); Ben Wilson; CABFPub Subject: RE: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Some of the beneficiaries are Browser root programs and relying parties. Having the BRs in this format makes it easier for Jody, Kathleen and others to review CPS? and compare to the sections in the BRs for compliance. Jeremy has already taken a pass at doing this and a draft has been circulated. Dean From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of kirk_hall at trendmicro.com Sent: Tuesday, February 24, 2015 11:52 AM To: Ben Wilson; CABFPub Subject: Re: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Ben ? first of all, thanks for the hard work on this one. I?m trying to figure out the benefit of locking the Forum into the RFC 3647 framework for the purpose of listing BR requirements. Is there really a benefit? Does it add to understanding and make CA compliance any easier? Or will it force us to put rules in odd places that actually make understanding a bit harder? I note the BR 8.2 already requires CAs to put their CPS into the format of RFC 2527 or 3647. See the first two sections of BR 8.2 below. That can facilitate comparison between the CPSs of different CAs, if anyone cares to do that. But is there any corresponding benefit from restructuring the BRs to an RFC 3647 format? What if a rule spans two or more different sections of the RFC 3647 format? I see that in your new organization of the BRs you have moved old BR 8.2.2 to a new Section 2.1 Repositories, not to new Section 2.2 Publication of Information. How did you make that choice? And is there an expectation that CAs will publish their CAA disclosure in new Sec. 2.2 of their CPS? I?m just afraid we will be handcuffing ourselves with these changes, and that there could be errors in internal cross-references. It is also a lot of work for everyone to review a complete rewrite of the BRs. Can you give us a convincing argument of why this is worth doing? Sorry I didn?t ask this question earlier, but I hadn?t really understood this was what the working group was doing ? I thought you were just looking for GAPS in the BRs as compared to the RFC 3647 where we could ADD new provisions to the BRs ? not a wholesale restructuring of the BRs. Thanks. BR 8.2.2 Disclosure The CA SHALL publicly disclose its Certificate Policy and/or Certification Practice Statement through an appropriate and readily accessible online means that is available on a 24x7 basis. The CA SHALL publicly disclose its CA business practices to the extent required by the CA?s selected audit scheme (see Section 17.1). The disclosures MUST include all the material required by RFC 2527 or RFC 3647, and MUST be structured in accordance with either RFC 2527 or RFC 3647. Effective as of 15 April 2015, section 4.2 of a CA's Certificate Policy and/or Certification Practice Statement (section 4.1 for CAs still conforming to RFC 2527) SHALL state whether the CA reviews CAA Records, and if so, the CA?s policy or practice on processing CAA Records for Fully Qualified Domain Names. The CA SHALL log all actions taken, if any, consistent with its processing practice. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ben Wilson Sent: Tuesday, February 24, 2015 7:22 AM To: CABFPub Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework The Certificate Policy Review Working Group was chartered by Ballot 128 to (i) consider existing and proposed standards, (ii) create a list of potential improvements based on the considered standards that improve the existing CAB Forum work product, (iii) evaluate the transition to a 3647 format based on the amount [of work involved]. One deliverable of the CP Review WG was to propose a ballot to improve CA infrastructure based on existing standards and documents and recommend whether to finish the 3647 conversion presented by Jeremy Rowley in January 2014. The CP Review WG has met and concluded that the best path forward for the Forum is to complete a conversion to the RFC 3647 for the Baseline Requirements with an initial step that merely moves existing content from the Baseline Requirements and the Network and Certificate System Security Requirements into the RFC 3647 format. Attached is an RFC-3647-formatted Certificate Policy for Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates. Comments embedded in the document contain either the source of the text (for content copied from the Baseline Requirements) or the current text (for provisions incorporated by reference from the Network and Certificate System Security Requirements ("NetSec"). It was decided that it was better to incorporate the NetSec requirements by reference rather than copying and pasting them in. In some limited instances the phrase "these Requirements" has been replaced with "this CP." However, "these Requirements" is mostly left in to preserve consistency with the current Baseline Requirements. Ben Wilson of DigiCert made the following motion, from and from have endorsed it. Motion Begins Be it resolved that the CA / Browser Forum adopts the attached CA/B Forum Certificate Policy v.1.2.5, effective immediately. Motion Ends The review period for this ballot shall commence at 2200 UTC on March 2015 and will close at 2200 UTC on March 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on March 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the ballot must indicate a clear ?yes? in the response. A vote against the ballot must indicate a clear ?no? in the response. A vote to abstain must indicate a clear ?abstain? in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/. In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and more than one half of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members? at least nine members must participate in the ballot, either by voting in favor, voting against, or by abstaining for the vote to be valid. TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 19121 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4954 bytes Desc: not available URL: From Dean_Coclin at symantec.com Wed Feb 25 23:41:10 2015 From: Dean_Coclin at symantec.com (Dean Coclin) Date: Wed, 25 Feb 2015 15:41:10 -0800 Subject: [cabfpub] DRAFT Minutes of CA/B Forum meeting Feb 19, 2015 Message-ID: <14D026C7F297AD44AC82578DD818CDD038EF4A9BCA@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> Attendees: Dean Coclin, Doug Beattie, Kirk Hall, Bruce Morton, Rick Andrews, Ben Wilson, Eddy Nigg, Volkan (TurkTrust), Robin Alden, Mads (BuyPass), Tim Shirley, Wayne Thayer, Connie Enke, Atilla Biller, Gerv Markham, Jeremy Rowley, Atsushi Inaba, Sisel (BuyPass), Kubra (TurkTrust), Davut (E-Tugra), Cecilia Kam. 1. Antitrust Statement was read. 2. Minutes of Feb 5th meeting were approved. Ben to post to website 3. Ballot Status: Ballots 143 and 144 were approved. Ben will update the website to reflect the new working group name. Ballot 144 requires changes to the EV Guidelines which Jeremy will amend and update. There were a large number of abstentions on ballot 144. Jeremy said that many people may have used that to help the ballot meet quorum and that they didn't have a strong interest in the ballot. 4. IPv6: Ryan put out a draft ballot on this topic. Dean sent out the results of a survey of CASC members on this topic which Gerv said was very useful. Gerv said it would be good for the Internet for the Forum to support IPv6 and that the ballot provides a generous amount of time to do this. Jeremy said some CAs use a CDN and that may not support IPv6. Wayne updated the group stating that GoDaddy can now support it. Rick stated that for the sake of a complete argument, why not let market forces control this? Let people choose a CA that supports it if they want. Gerv said that doesn't work because a user or third party doesn't have that choice. Rick said most browsers don't fail on OCSP failure so it's not blocking anything. 5. Membership Application of TrustCor Systems: The Forum received an application for membership from this entity. They have a WebTrust report from Princeton Audit Group which stated they are not actively issuing certificates yet. Dean sent the applicant a note asking for a site that uses one of their certs. He also sent a note to Don Sheehy about the auditor qualifications. Kirk asked if they have a BR audit which Dean will ask the applicant. Kirk suggested that if they don't fully qualify, they could be granted observer status. Wayne asked if we should update the membership rules to require a BR audit. Jeremy agreed that this should be updated and that when we do a bylaw update, this should be undertaken. Wayne also said that everyone on the Management list is also on the Questions list. 6. New Ballots: Operational Existence (145) and pre-ballot Domain Validation (146). Cecilia and Kirk said that the EV Working group proposed ballot 145 for Government entity purposes. Discussion period for 145 starts today. Ballot 146 is a proposal to eliminate the "any other method (7)" for domain validation. Jeremy said they are soliciting comments and should have a proposal ready by the face to face meeting. Kirk encouraged others to bring forward any other verification methods for domain validation. Jeremy said there is another ballot coming forward on using attorney opinion letters for legal existence. This should be out before the face to face meeting. 7. Working group publicity: To date, the working group mailing lists have not been public. The bylaws state (in one place) that minutes and agendas of working groups should be made public and (in another place) that the lists should be managed in the same fashion as the public list. Gerv said that some working groups weren't public because they were in existence before the bylaws. But we should make the archives publicly accessible. Wayne said we can publish the URL to subscribe to the list. Gerv said that when groups are re-chartered, we should create a new list to not violate anyone's expectation of privacy from the old list. Regarding the new Validation Working Group, Gerv suggested we re-subscribe all the old members to the new list and state that it would be made public. It has to be clear that active participation is limited to those that have signed the IPR. 8. EV WG update: Per #6 above. 9. Code Signing update: Public draft of BR issued. Some comments received which the working group will address before the face to face meeting. 10. Policy Review WG: A ballot will be proposed for the reconfiguration of the BRs to RFC 3647 format. 11. Info Sharing WG: Hasn't met in a while but needs to get back together soon. Members have had conflicts during the meeting time. 12. Any other business: Kirk said we have 32 members coming to the F2F meeting. Send agenda items to Dean. 13. Next meeting will be March 5th. Dean Coclin CA/B Forum Chair -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6130 bytes Desc: not available URL: From jeremy.rowley at digicert.com Thu Feb 26 00:28:51 2015 From: jeremy.rowley at digicert.com (Jeremy Rowley) Date: Thu, 26 Feb 2015 00:28:51 +0000 Subject: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc In-Reply-To: References: <763539E260C37C46A0D6B340B5434C3B0ACD81A9@AEX06.ejsarea.net> A <763539E260C37C46A0D6B340B5434C3B0ADAE0EB@AEX06.ejsarea.net> Message-ID: <2639008ebb224f54be8be02132375681@EX2.corp.digicert.com> Should this be added to the BRs instead of code signing? For auditor qualifications, we just incorporate the auditor qualifications by reference. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jody Cloutier Sent: Friday, February 13, 2015 1:28 PM To: i-barreira at izenpe.net; public at cabforum.org Subject: Re: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Thank you, Inigo, What seems to be happening is that organizations are applying the ETSI standard in cases in which either there is no National Standards Body, or where the national standards body does not certify the company. Building on the scenario below, Audit Co is not recognized by ISRAC, but Auditor Jones has a CISP certification, which I've already confirmed with ETSI is not sufficient. I think what would help here is to make the requirement much more specific: A Qualified Auditor is limited to an auditor that is employed by a company that is certified by a National Authority listed in either the Members or Associate Members link. This, much simplified language, seems to be what you are saying below, but the current language is such that Audit Co can argue that it can issue an ETSI audit because it's company is certified by another national authority that's not listed on the ETSI webpages anywhere. Jody From: i-barreira at izenpe.net [mailto:i-barreira at izenpe.net] Sent: Friday, February 13, 2015 12:16 AM To: Jody Cloutier; public at cabforum.org Subject: RE: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Dear Jody, I understand your concern because it?s not easy for you to manage all possible combinations regarding ETSI audits in different countries so will try to clarify your example. First of all, no AuditCo has to be member of ETSI, AuditCo can perform ETSI accredited audits without being member of ETSI, they only need to be accredited in their country as stated in Annex E requirements. So, For example, * Company A is a commercial CA that operates in Israel * Auditor Jones works for AuditCo, which is based in Israel * AuditCo is certified by some governmental agency as a qualified auditor IB--> AuditCo has to be accredited under its National Accreditation Body according to ISO 17021. In the case of Israel, to follow the example, in the associated members tab of the EA, you can find the Israeli accreditation body, called ISRAC. Then AuditCo should be listed there and meeting the requirements to perform ETSI audits according to the national scheme indicated by ISRAC * AuditCo is not an ETSI Member or Associate Member IB --> this is not necessary. No need to be an ETSI member to perform ETSI audits * Auditor Jones audits Company A using the ETSI 102042 standard, and Company A sends the auditor's attestation letter to Microsoft as evidence that Company A complied with the Program's requirements. IB--> this is perfectly valid if AuditCo is listed in ISRAC and is allowed to perform ETSI audits. Of course Auditor Jones has to be also accredited to perform these kind of audits, has to be "qualified", so it?s not only the company but also the auditor, but that?s an internal task of the AuditCo. Regarding of being member of not, this is voluntary, they can join ETSI or not and don?t think that solve the problem because joining ETSI does not mean that you?re "qualified" or "accredited" to perform an ETSI audit, it?s just indicate that you belong to a club for example. And of course, if company A needs an auditing company accredited in Israel and there?s none, they can look for in other countries. For example, in Spain there?s no accredited auditing bodies to perform ETSI audits listed in our NAB, called ENAC, so, we, Izenpe, had to look for another option. So, we contacted for the first 6 years with KPMG in the Netherlands, and the last 3, with TUV IT in Germany. And Izenpe has an accredited ETSI audits according to the, right now, German national scheme and we?re listed in Germany. We?ll debate this within ETSI ESI trying to find an easier solution. Regards I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 [Descripci?n: cid:image001.png at 01CE3152.B4804EB0] ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. De: Jody Cloutier [mailto:jodycl at microsoft.com] Enviado el: mi?rcoles, 11 de febrero de 2015 0:32 Para: Barreira Iglesias, I?igo; public at cabforum.org Asunto: RE: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Thank you, Inigo. I think the problem is that, under ETSI, it's difficult to discern what an "equivalent national scheme" is. This sets up the scenario in which an auditor is employed by an organization that is recognized somehow by the government, but is not affiliated with an ETSI member organization (http://www.european-accreditation.org/home ). Microsoft does not know whether or not this auditor is qualified or not. For example, * Company A is a commercial CA that operates in Israel * Auditor Jones works for AuditCo, which is based in Israel * AuditCo is certified by some governmental agency as a qualified auditor * AuditCo is not an ETSI Member or Associate Member * Auditor Jones audits Company A using the ETSI 102042 standard, and Company A sends the auditor's attestation letter to Microsoft as evidence that Company A complied with the Program's requirements. In this scenario, how does Microsoft know that Auditor Jones conducted a proper audit without expending significant resources to determine whether and according to what standard AuditCo and Auditor Jones was certified? Microsoft believes that it would be simpler if the requirements were that the Auditor must work for a company that is affiliated with an ETSI-approved member organization. If Company A needs an auditor and there is no qualified auditor in Israel, the company can use an auditor from a member organization via the cross-border conformity rules. Unless I am fundamentally misunderstanding the rules, the above is something that Microsoft is presently struggling with, and we'd like to try to make the rules easier to understand for potential partners and ourselves. Jody Cloutier Senior Security Program Manager Microsoft Trusted Root Certificate Program jody.cloutier at microsoft.com 425.443.8922 Operating Systems Group Global Risk and Compliance [https://brandtools.microsoft.com/Style%20Library/BT/Images/MicrosoftMasterLogo.png] From: i-barreira at izenpe.net [mailto:i-barreira at izenpe.net] Sent: Tuesday, February 10, 2015 3:09 AM To: Jody Cloutier; public at cabforum.org Subject: RE: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Hi Jody, Regarding your comment on ETSI audits, I have to say that the ETSI audits shall be performed by accredited auditors as mentioned in Annex E of the current ETSI TS 102 042. ETSI audits performed by not accredited auditors shall be considered invalid. Microsoft is accepting ETSI audits since the very beginning in its root program requirements indicating this requirement. ETSI is providing a list of accredited auditors as mere information because has to be maintained by every NAB (National Accreditation Body). It?s true that this has to be improved regarding the new regulation 910/2014 and the new ENs and will take some time, but at the moment, it?s clearly stated that the audits shall be performed by accredited auditors. Don?t hesitate in contacting me for any additional information or help. Sometimes I?ve received some emails from Tom or Kelvin asking for the qualification of some audits, so, as say, you can contact me regarding this issue. Regards I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 [Descripci?n: cid:image001.png at 01CE3152.B4804EB0] ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. De: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] En nombre de Jody Cloutier Enviado el: lunes, 09 de febrero de 2015 18:55 Para: CABFPub (public at cabforum.org) Asunto: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Microsoft comments on Section 17. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 19121 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 1181 bytes Desc: image002.png URL: From i-barreira at izenpe.net Thu Feb 26 07:53:58 2015 From: i-barreira at izenpe.net (i-barreira at izenpe.net) Date: Thu, 26 Feb 2015 08:53:58 +0100 Subject: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc In-Reply-To: <2639008ebb224f54be8be02132375681@EX2.corp.digicert.com> References: <763539E260C37C46A0D6B340B5434C3B0ACD81A9@AEX06.ejsarea.net> A <763539E260C37C46A0D6B340B5434C3B0ADAE0EB@AEX06.ejsarea.net> <2639008ebb224f54be8be02132375681@EX2.corp.digicert.com> Message-ID: <763539E260C37C46A0D6B340B5434C3B0AE7ECC9@AEX06.ejsarea.net> I think the auditors qualification should be added to the BRs as a general matter valid for all documents produced by the CABF for all type of audits. So, all audits should be conducted in the same way. I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. De: Jeremy Rowley [mailto:jeremy.rowley at digicert.com] Enviado el: jueves, 26 de febrero de 2015 1:29 Para: Jody Cloutier; Barreira Iglesias, I?igo; public at cabforum.org Asunto: RE: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Should this be added to the BRs instead of code signing? For auditor qualifications, we just incorporate the auditor qualifications by reference. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jody Cloutier Sent: Friday, February 13, 2015 1:28 PM To: i-barreira at izenpe.net; public at cabforum.org Subject: Re: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Thank you, Inigo, What seems to be happening is that organizations are applying the ETSI standard in cases in which either there is no National Standards Body, or where the national standards body does not certify the company. Building on the scenario below, Audit Co is not recognized by ISRAC, but Auditor Jones has a CISP certification, which I've already confirmed with ETSI is not sufficient. I think what would help here is to make the requirement much more specific: A Qualified Auditor is limited to an auditor that is employed by a company that is certified by a National Authority listed in either the Members or Associate Members link. This, much simplified language, seems to be what you are saying below, but the current language is such that Audit Co can argue that it can issue an ETSI audit because it's company is certified by another national authority that's not listed on the ETSI webpages anywhere. Jody From: i-barreira at izenpe.net [mailto:i-barreira at izenpe.net] Sent: Friday, February 13, 2015 12:16 AM To: Jody Cloutier; public at cabforum.org Subject: RE: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Dear Jody, I understand your concern because it?s not easy for you to manage all possible combinations regarding ETSI audits in different countries so will try to clarify your example. First of all, no AuditCo has to be member of ETSI, AuditCo can perform ETSI accredited audits without being member of ETSI, they only need to be accredited in their country as stated in Annex E requirements. So, For example, ? Company A is a commercial CA that operates in Israel ? Auditor Jones works for AuditCo, which is based in Israel ? AuditCo is certified by some governmental agency as a qualified auditor IB? AuditCo has to be accredited under its National Accreditation Body according to ISO 17021. In the case of Israel, to follow the example, in the associated members tab of the EA, you can find the Israeli accreditation body, called ISRAC. Then AuditCo should be listed there and meeting the requirements to perform ETSI audits according to the national scheme indicated by ISRAC ? AuditCo is not an ETSI Member or Associate Member IB ? this is not necessary. No need to be an ETSI member to perform ETSI audits ? Auditor Jones audits Company A using the ETSI 102042 standard, and Company A sends the auditor's attestation letter to Microsoft as evidence that Company A complied with the Program's requirements. IB? this is perfectly valid if AuditCo is listed in ISRAC and is allowed to perform ETSI audits. Of course Auditor Jones has to be also accredited to perform these kind of audits, has to be "qualified", so it?s not only the company but also the auditor, but that?s an internal task of the AuditCo. Regarding of being member of not, this is voluntary, they can join ETSI or not and don?t think that solve the problem because joining ETSI does not mean that you?re "qualified" or "accredited" to perform an ETSI audit, it?s just indicate that you belong to a club for example. And of course, if company A needs an auditing company accredited in Israel and there?s none, they can look for in other countries. For example, in Spain there?s no accredited auditing bodies to perform ETSI audits listed in our NAB, called ENAC, so, we, Izenpe, had to look for another option. So, we contacted for the first 6 years with KPMG in the Netherlands, and the last 3, with TUV IT in Germany. And Izenpe has an accredited ETSI audits according to the, right now, German national scheme and we?re listed in Germany. We?ll debate this within ETSI ESI trying to find an easier solution. Regards I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. De: Jody Cloutier [mailto:jodycl at microsoft.com] Enviado el: mi?rcoles, 11 de febrero de 2015 0:32 Para: Barreira Iglesias, I?igo; public at cabforum.org Asunto: RE: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Thank you, Inigo. I think the problem is that, under ETSI, it's difficult to discern what an "equivalent national scheme" is. This sets up the scenario in which an auditor is employed by an organization that is recognized somehow by the government, but is not affiliated with an ETSI member organization (http://www.european-accreditation.org/home ). Microsoft does not know whether or not this auditor is qualified or not. For example, ? Company A is a commercial CA that operates in Israel ? Auditor Jones works for AuditCo, which is based in Israel ? AuditCo is certified by some governmental agency as a qualified auditor ? AuditCo is not an ETSI Member or Associate Member ? Auditor Jones audits Company A using the ETSI 102042 standard, and Company A sends the auditor's attestation letter to Microsoft as evidence that Company A complied with the Program's requirements. In this scenario, how does Microsoft know that Auditor Jones conducted a proper audit without expending significant resources to determine whether and according to what standard AuditCo and Auditor Jones was certified? Microsoft believes that it would be simpler if the requirements were that the Auditor must work for a company that is affiliated with an ETSI-approved member organization. If Company A needs an auditor and there is no qualified auditor in Israel, the company can use an auditor from a member organization via the cross-border conformity rules. Unless I am fundamentally misunderstanding the rules, the above is something that Microsoft is presently struggling with, and we'd like to try to make the rules easier to understand for potential partners and ourselves. Jody Cloutier Senior Security Program Manager Microsoft Trusted Root Certificate Program jody.cloutier at microsoft.com 425.443.8922 Operating Systems Group Global Risk and Compliance From: i-barreira at izenpe.net [mailto:i-barreira at izenpe.net] Sent: Tuesday, February 10, 2015 3:09 AM To: Jody Cloutier; public at cabforum.org Subject: RE: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Hi Jody, Regarding your comment on ETSI audits, I have to say that the ETSI audits shall be performed by accredited auditors as mentioned in Annex E of the current ETSI TS 102 042. ETSI audits performed by not accredited auditors shall be considered invalid. Microsoft is accepting ETSI audits since the very beginning in its root program requirements indicating this requirement. ETSI is providing a list of accredited auditors as mere information because has to be maintained by every NAB (National Accreditation Body). It?s true that this has to be improved regarding the new regulation 910/2014 and the new ENs and will take some time, but at the moment, it?s clearly stated that the audits shall be performed by accredited auditors. Don?t hesitate in contacting me for any additional information or help. Sometimes I?ve received some emails from Tom or Kelvin asking for the qualification of some audits, so, as say, you can contact me regarding this issue. Regards I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. De: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] En nombre de Jody Cloutier Enviado el: lunes, 09 de febrero de 2015 18:55 Para: CABFPub (public at cabforum.org) Asunto: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Microsoft comments on Section 17. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 19121 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 1181 bytes Desc: image002.png URL: From mcaughron at apple.com Thu Feb 26 22:15:37 2015 From: mcaughron at apple.com (Mat Caughron) Date: Thu, 26 Feb 2015 14:15:37 -0800 Subject: [cabfpub] Updated Certificate Transparency + Extended Validation plan In-Reply-To: References: Message-ID: <2C97673F-8638-4592-8B0C-C7398D2221A7@apple.com> Greetings: It has been one year, has this CT plan been updated at all? Sincerely, Mat Caughron ? Product Security > On Feb 4, 2014, at 9:08 AM, Ben Laurie wrote: > > Enclosed, our revised plan. > > Comments welcome. > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4112 bytes Desc: not available URL: From rob.stradling at comodo.com Thu Feb 26 22:24:25 2015 From: rob.stradling at comodo.com (Rob Stradling) Date: Thu, 26 Feb 2015 17:24:25 -0500 Subject: [cabfpub] Updated Certificate Transparency + Extended Validationplan In-Reply-To: <2C97673F-8638-4592-8B0C-C7398D2221A7@apple.com> References: <2C97673F-8638-4592-8B0C-C7398D2221A7@apple.com> Message-ID: <54EF9D19.9070105@comodo.com> On 26/02/15 17:15, Mat Caughron wrote: > Greetings: > > It has been one year, has this CT plan been updated at all? Hi Mat. Google's EV/CT Plan has been updated a couple of times since then. See here: http://www.certificate-transparency.org/ev-ct-plan > Sincerely, > > > Mat Caughron > ? Product Security > > > >> On Feb 4, 2014, at 9:08 AM, Ben Laurie wrote: >> >> Enclosed, our revised plan. >> >> Comments welcome. >> _______________________________________________ >> Public mailing list >> Public at cabforum.org >> https://cabforum.org/mailman/listinfo/public > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From mcaughron at apple.com Thu Feb 26 22:39:22 2015 From: mcaughron at apple.com (Mat Caughron) Date: Thu, 26 Feb 2015 14:39:22 -0800 Subject: [cabfpub] Updated Certificate Transparency + Extended Validationplan In-Reply-To: <54EF9D19.9070105@comodo.com> References: <2C97673F-8638-4592-8B0C-C7398D2221A7@apple.com> <54EF9D19.9070105@comodo.com> Message-ID: <0281DDB3-432A-4ABA-82B6-D757D92E6A4A@apple.com> Hello Rob, So presumably, the survey if conducted now would indicate a few more CA's on board than indicated here? http://www.certificate-transparency.org/feb-2014-survey-responses Mat Caughron ? Product Security mcaughron at appe.com > On Feb 26, 2015, at 2:24 PM, Rob Stradling wrote: > > On 26/02/15 17:15, Mat Caughron wrote: >> Greetings: >> >> It has been one year, has this CT plan been updated at all? > > Hi Mat. > > Google's EV/CT Plan has been updated a couple of times since then. See here: > http://www.certificate-transparency.org/ev-ct-plan > >> Sincerely, >> >> >> Mat Caughron >> ? Product Security >> >> >> >>> On Feb 4, 2014, at 9:08 AM, Ben Laurie wrote: >>> >>> Enclosed, our revised plan. >>> >>> Comments welcome. >>> _______________________________________________ >>> Public mailing list >>> Public at cabforum.org >>> https://cabforum.org/mailman/listinfo/public >> > > -- > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4112 bytes Desc: not available URL: From rob.stradling at comodo.com Fri Feb 27 04:18:18 2015 From: rob.stradling at comodo.com (Rob Stradling) Date: Thu, 26 Feb 2015 23:18:18 -0500 Subject: [cabfpub] Updated Certificate Transparency + ExtendedValidationplan In-Reply-To: <0281DDB3-432A-4ABA-82B6-D757D92E6A4A@apple.com> References: <2C97673F-8638-4592-8B0C-C7398D2221A7@apple.com> <54EF9D19.9070105@comodo.com> <0281DDB3-432A-4ABA-82B6-D757D92E6A4A@apple.com> Message-ID: <54EFF00A.5030805@comodo.com> Good question, Mat. I've just generated a report (see attached) that shows, per issuing CA, the number of certs with embedded SCTs that have been logged in the currently existing CT logs so far. That is one measurement of which CAs are "on board", but it's not the full story. On 26/02/15 17:39, Mat Caughron wrote: > Hello Rob, > > So presumably, the survey if conducted now would indicate a few more > CA's on board than indicated here? > http://www.certificate-transparency.org/feb-2014-survey-responses > > > > Mat Caughron > ? Product Security > mcaughron at appe.com > > > >> On Feb 26, 2015, at 2:24 PM, Rob Stradling > > wrote: >> >> On 26/02/15 17:15, Mat Caughron wrote: >>> Greetings: >>> >>> It has been one year, has this CT plan been updated at all? >> >> Hi Mat. >> >> Google's EV/CT Plan has been updated a couple of times since then. >> See here: >> http://www.certificate-transparency.org/ev-ct-plan >> >>> Sincerely, >>> >>> >>> Mat Caughron >>> ? Product Security >>> >>> >>> >>>> On Feb 4, 2014, at 9:08 AM, Ben Laurie wrote: >>>> >>>> Enclosed, our revised plan. >>>> >>>> Comments welcome. >>>> _______________________________________________ >>>> Public mailing list >>>> Public at cabforum.org >>>> https://cabforum.org/mailman/listinfo/public >>> >> >> -- >> Rob Stradling >> Senior Research & Development Scientist >> COMODO - Creating Trust Online > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. -------------- next part -------------- A non-text attachment was scrubbed... Name: certs_with_embedded_scts_per_ca.csv Type: text/csv Size: 6218 bytes Desc: not available URL: From i-barreira at izenpe.net Fri Feb 27 07:40:15 2015 From: i-barreira at izenpe.net (i-barreira at izenpe.net) Date: Fri, 27 Feb 2015 08:40:15 +0100 Subject: [cabfpub] Updated Certificate Transparency + ExtendedValidationplan In-Reply-To: <54EFF00A.5030805@comodo.com> References: <2C97673F-8638-4592-8B0C-C7398D2221A7@apple.com> <54EF9D19.9070105@comodo.com> <0281DDB3-432A-4ABA-82B6-D757D92E6A4A@apple.com> <54EFF00A.5030805@comodo.com> Message-ID: <763539E260C37C46A0D6B340B5434C3B0AE7EF28@AEX06.ejsarea.net> And for example, Izepe indicated that were not interested in running a log server, and we?re running one :-) I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. -----Mensaje original----- De: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] En nombre de Rob Stradling Enviado el: viernes, 27 de febrero de 2015 5:18 Para: Mat Caughron CC: therightkey at ietf.org; certificate-transparency at googlegroups.com; CABFPub Asunto: Re: [cabfpub] Updated Certificate Transparency + ExtendedValidationplan Good question, Mat. I've just generated a report (see attached) that shows, per issuing CA, the number of certs with embedded SCTs that have been logged in the currently existing CT logs so far. That is one measurement of which CAs are "on board", but it's not the full story. On 26/02/15 17:39, Mat Caughron wrote: > Hello Rob, > > So presumably, the survey if conducted now would indicate a few more > CA's on board than indicated here? > http://www.certificate-transparency.org/feb-2014-survey-responses > > > > Mat Caughron > ? Product Security > mcaughron at appe.com > > > >> On Feb 26, 2015, at 2:24 PM, Rob Stradling > > wrote: >> >> On 26/02/15 17:15, Mat Caughron wrote: >>> Greetings: >>> >>> It has been one year, has this CT plan been updated at all? >> >> Hi Mat. >> >> Google's EV/CT Plan has been updated a couple of times since then. >> See here: >> http://www.certificate-transparency.org/ev-ct-plan >> >>> Sincerely, >>> >>> >>> Mat Caughron >>> ? Product Security >>> >>> >>> >>>> On Feb 4, 2014, at 9:08 AM, Ben Laurie wrote: >>>> >>>> Enclosed, our revised plan. >>>> >>>> Comments welcome. >>>> _______________________________________ >>>> ________ >>>> Public mailing list >>>> Public at cabforum.org >>>> https://cabforum.org/mailman/listinfo/public >>> >> >> -- >> Rob Stradling >> Senior Research & Development Scientist COMODO - Creating Trust >> Online > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. From bruce.morton at entrust.com Fri Feb 27 14:25:46 2015 From: bruce.morton at entrust.com (Bruce Morton) Date: Fri, 27 Feb 2015 14:25:46 +0000 Subject: [cabfpub] Ballot 145 - Operational Existence for Government Entities In-Reply-To: References: Message-ID: <452C99D20750E74083DBA441FF932385E41A749D@SOTTEXCH10.corp.ad.entrust.com> Entrust votes Yes. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Thursday, February 19, 2015 10:44 AM To: CABFPub Subject: [cabfpub] Ballot 145 - Operational Existence for Government Entities Ballot 145 - Operational Existence for Government Entities ________________________________ Reason ________________________________ Because government entities aren't operating as businesses, they are often not listed with a QIIS, especially immediately after the entity is created by either statute or order. The legal existence of these entities is verifiable through a QGIS, but this source in many countries (especially Arabic and African countries) does not always list a date of creation of these entities. Operational existence exists to ensure organizations aren't fly-by-night scams/phishing entities. With government entities, these same risks are not present as they are created directly by government action. Jeremy Rowley of DigiCert made the following motion, which was endorsed by Rich Smith of Comodo and Cecilia Kam of Symantec. ________________________________ Motion begins ________________________________ Effective immediately, section 11.6.1 is modified as follows: 11.6.1 Verification Requirements. The CA MUST verify that the Applicant has the ability to engage in business by verifying the Applicant's, or Affiliate/Parent/Subsidiary Company's, operational existence. The CA MAY rely on its verification of a Government Entity's legal existence under Section 11.2 as verification of a Government Entity's operational existence. ________________________________ Motion Ends ________________________________ The review period for this ballot shall commence at 2200 UTC on 19 Feb 2015, and will close at 2200 UTC on 26 Feb 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on 5 Mar 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirk_hall at trendmicro.com Fri Feb 27 16:05:00 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Fri, 27 Feb 2015 16:05:00 +0000 Subject: [cabfpub] Ballot 145 - Operational Existence for Government Entities In-Reply-To: <452C99D20750E74083DBA441FF932385E41A749D@SOTTEXCH10.corp.ad.entrust.com> References: <452C99D20750E74083DBA441FF932385E41A749D@SOTTEXCH10.corp.ad.entrust.com> Message-ID: Trend Micro votes yes From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Thursday, February 19, 2015 10:44 AM To: CABFPub Subject: [cabfpub] Ballot 145 - Operational Existence for Government Entities Ballot 145 - Operational Existence for Government Entities ________________________________ Reason ________________________________ Because government entities aren't operating as businesses, they are often not listed with a QIIS, especially immediately after the entity is created by either statute or order. The legal existence of these entities is verifiable through a QGIS, but this source in many countries (especially Arabic and African countries) does not always list a date of creation of these entities. Operational existence exists to ensure organizations aren't fly-by-night scams/phishing entities. With government entities, these same risks are not present as they are created directly by government action. Jeremy Rowley of DigiCert made the following motion, which was endorsed by Rich Smith of Comodo and Cecilia Kam of Symantec. ________________________________ Motion begins ________________________________ Effective immediately, section 11.6.1 is modified as follows: 11.6.1 Verification Requirements. The CA MUST verify that the Applicant has the ability to engage in business by verifying the Applicant's, or Affiliate/Parent/Subsidiary Company's, operational existence. The CA MAY rely on its verification of a Government Entity's legal existence under Section 11.2 as verification of a Government Entity's operational existence. ________________________________ Motion Ends ________________________________ The review period for this ballot shall commence at 2200 UTC on 19 Feb 2015, and will close at 2200 UTC on 26 Feb 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on 5 Mar 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
-------------- next part -------------- An HTML attachment was scrubbed... URL: From richard at wosign.com Fri Feb 27 16:13:34 2015 From: richard at wosign.com (Richard Wang) Date: Fri, 27 Feb 2015 16:13:34 +0000 Subject: [cabfpub] Ballot 145 - Operational Existence for Government Entities In-Reply-To: References: <452C99D20750E74083DBA441FF932385E41A749D@SOTTEXCH10.corp.ad.entrust.com> Message-ID: <43831CBB-7B89-4F6A-9EA8-714DD58A067E@wosign.com> > WoSign votes yes > > From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley > Sent: Thursday, February 19, 2015 10:44 AM > To: CABFPub > Subject: [cabfpub] Ballot 145 - Operational Existence for Government Entities > > Ballot 145 - Operational Existence for Government Entities > > Reason > > Because government entities aren?t operating as businesses, they are often not listed with a QIIS, especially immediately after the entity is created by either statute or order. The legal existence of these entities is verifiable through a QGIS, but this source in many countries (especially Arabic and African countries) does not always list a date of creation of these entities. Operational existence exists to ensure organizations aren?t fly-by-night scams/phishing entities. With government entities, these same risks are not present as they are created directly by government action. > > Jeremy Rowley of DigiCert made the following motion, which was endorsed by Rich Smith of Comodo and Cecilia Kam of Symantec. > > Motion begins > > Effective immediately, section 11.6.1 is modified as follows: > > 11.6.1 Verification Requirements. > > The CA MUST verify that the Applicant has the ability to engage in business by verifying the Applicant's, or Affiliate/Parent/Subsidiary Company's, operational existence. The CA MAY rely on its verification of a Government Entity?s legal existence under Section 11.2 as verification of a Government Entity?s operational existence. > > Motion Ends > > The review period for this ballot shall commence at 2200 UTC on 19 Feb 2015, and will close at 2200 UTC on 26 Feb 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on 5 Mar 2015. Votes must be cast by posting an on-list reply to this thread. > > A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ > > In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members? at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. > > > TREND MICRO EMAIL NOTICE > The information contained in this email and any attachments is confidential > and may be subject to copyright or other intellectual property protection. > If you are not the intended recipient, you are not authorized to use or > disclose this information, and we request that you notify us by reply mail or > telephone and delete the original message from your mail system. > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 7152 bytes Desc: not available URL: From Dean_Coclin at symantec.com Fri Feb 27 18:32:39 2015 From: Dean_Coclin at symantec.com (Dean Coclin) Date: Fri, 27 Feb 2015 10:32:39 -0800 Subject: [cabfpub] Ballot 145 - Operational Existence for Government Entities In-Reply-To: References: Message-ID: <14D026C7F297AD44AC82578DD818CDD038EF614DE0@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> Symantec votes YES. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Thursday, February 19, 2015 10:44 AM To: CABFPub Subject: [cabfpub] Ballot 145 - Operational Existence for Government Entities Ballot 145 - Operational Existence for Government Entities _____ Reason _____ Because government entities aren't operating as businesses, they are often not listed with a QIIS, especially immediately after the entity is created by either statute or order. The legal existence of these entities is verifiable through a QGIS, but this source in many countries (especially Arabic and African countries) does not always list a date of creation of these entities. Operational existence exists to ensure organizations aren't fly-by-night scams/phishing entities. With government entities, these same risks are not present as they are created directly by government action. Jeremy Rowley of DigiCert made the following motion, which was endorsed by Rich Smith of Comodo and Cecilia Kam of Symantec. _____ Motion begins _____ Effective immediately, section 11.6.1 is modified as follows: 11.6.1 Verification Requirements. The CA MUST verify that the Applicant has the ability to engage in business by verifying the Applicant's, or Affiliate/Parent/Subsidiary Company's, operational existence. The CA MAY rely on its verification of a Government Entity's legal existence under Section 11.2 as verification of a Government Entity's operational existence. _____ Motion Ends _____ The review period for this ballot shall commence at 2200 UTC on 19 Feb 2015, and will close at 2200 UTC on 26 Feb 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on 5 Mar 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6130 bytes Desc: not available URL: From S.Davidson at quovadisglobal.com Fri Feb 27 18:42:27 2015 From: S.Davidson at quovadisglobal.com (Stephen Davidson) Date: Fri, 27 Feb 2015 18:42:27 +0000 Subject: [cabfpub] Ballot 145 - Operational Existence for Government Entities In-Reply-To: <452C99D20750E74083DBA441FF932385E41A749D@SOTTEXCH10.corp.ad.entrust.com> References: <452C99D20750E74083DBA441FF932385E41A749D@SOTTEXCH10.corp.ad.entrust.com> Message-ID: QuoVadis votes yes. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Thursday, February 19, 2015 10:44 AM To: CABFPub Subject: [cabfpub] Ballot 145 - Operational Existence for Government Entities Ballot 145 - Operational Existence for Government Entities _____ Reason _____ Because government entities aren't operating as businesses, they are often not listed with a QIIS, especially immediately after the entity is created by either statute or order. The legal existence of these entities is verifiable through a QGIS, but this source in many countries (especially Arabic and African countries) does not always list a date of creation of these entities. Operational existence exists to ensure organizations aren't fly-by-night scams/phishing entities. With government entities, these same risks are not present as they are created directly by government action. Jeremy Rowley of DigiCert made the following motion, which was endorsed by Rich Smith of Comodo and Cecilia Kam of Symantec. _____ Motion begins _____ Effective immediately, section 11.6.1 is modified as follows: 11.6.1 Verification Requirements. The CA MUST verify that the Applicant has the ability to engage in business by verifying the Applicant's, or Affiliate/Parent/Subsidiary Company's, operational existence. The CA MAY rely on its verification of a Government Entity's legal existence under Section 11.2 as verification of a Government Entity's operational existence. _____ Motion Ends _____ The review period for this ballot shall commence at 2200 UTC on 19 Feb 2015, and will close at 2200 UTC on 26 Feb 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on 5 Mar 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5529 bytes Desc: not available URL: From jeremy.rowley at digicert.com Fri Feb 27 18:44:33 2015 From: jeremy.rowley at digicert.com (Jeremy Rowley) Date: Fri, 27 Feb 2015 18:44:33 +0000 Subject: [cabfpub] Ballot 145 - Operational Existence for Government Entities In-Reply-To: <14D026C7F297AD44AC82578DD818CDD038EF614DE0@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> References: <14D026C7F297AD44AC82578DD818CDD038EF614DE0@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> Message-ID: <5e3148ac833b49f9a4a0363fa6fddbc5@EX2.corp.digicert.com> DigiCert votes YES From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Dean Coclin Sent: Friday, February 27, 2015 11:33 AM To: CABFPub Subject: Re: [cabfpub] Ballot 145 - Operational Existence for Government Entities Symantec votes YES. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Thursday, February 19, 2015 10:44 AM To: CABFPub Subject: [cabfpub] Ballot 145 - Operational Existence for Government Entities Ballot 145 - Operational Existence for Government Entities ________________________________ Reason ________________________________ Because government entities aren't operating as businesses, they are often not listed with a QIIS, especially immediately after the entity is created by either statute or order. The legal existence of these entities is verifiable through a QGIS, but this source in many countries (especially Arabic and African countries) does not always list a date of creation of these entities. Operational existence exists to ensure organizations aren't fly-by-night scams/phishing entities. With government entities, these same risks are not present as they are created directly by government action. Jeremy Rowley of DigiCert made the following motion, which was endorsed by Rich Smith of Comodo and Cecilia Kam of Symantec. ________________________________ Motion begins ________________________________ Effective immediately, section 11.6.1 is modified as follows: 11.6.1 Verification Requirements. The CA MUST verify that the Applicant has the ability to engage in business by verifying the Applicant's, or Affiliate/Parent/Subsidiary Company's, operational existence. The CA MAY rely on its verification of a Government Entity's legal existence under Section 11.2 as verification of a Government Entity's operational existence. ________________________________ Motion Ends ________________________________ The review period for this ballot shall commence at 2200 UTC on 19 Feb 2015, and will close at 2200 UTC on 26 Feb 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on 5 Mar 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jodycl at microsoft.com Fri Feb 27 18:48:05 2015 From: jodycl at microsoft.com (Jody Cloutier) Date: Fri, 27 Feb 2015 18:48:05 +0000 Subject: [cabfpub] Ballot 145 - Operational Existence for Government Entities In-Reply-To: <5e3148ac833b49f9a4a0363fa6fddbc5@EX2.corp.digicert.com> References: <14D026C7F297AD44AC82578DD818CDD038EF614DE0@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> <5e3148ac833b49f9a4a0363fa6fddbc5@EX2.corp.digicert.com> Message-ID: Microsoft votes YES From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Friday, February 27, 2015 10:45 AM To: Dean Coclin; CABFPub Subject: Re: [cabfpub] Ballot 145 - Operational Existence for Government Entities DigiCert votes YES From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Dean Coclin Sent: Friday, February 27, 2015 11:33 AM To: CABFPub Subject: Re: [cabfpub] Ballot 145 - Operational Existence for Government Entities Symantec votes YES. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Thursday, February 19, 2015 10:44 AM To: CABFPub Subject: [cabfpub] Ballot 145 - Operational Existence for Government Entities Ballot 145 - Operational Existence for Government Entities ________________________________ Reason ________________________________ Because government entities aren't operating as businesses, they are often not listed with a QIIS, especially immediately after the entity is created by either statute or order. The legal existence of these entities is verifiable through a QGIS, but this source in many countries (especially Arabic and African countries) does not always list a date of creation of these entities. Operational existence exists to ensure organizations aren't fly-by-night scams/phishing entities. With government entities, these same risks are not present as they are created directly by government action. Jeremy Rowley of DigiCert made the following motion, which was endorsed by Rich Smith of Comodo and Cecilia Kam of Symantec. ________________________________ Motion begins ________________________________ Effective immediately, section 11.6.1 is modified as follows: 11.6.1 Verification Requirements. The CA MUST verify that the Applicant has the ability to engage in business by verifying the Applicant's, or Affiliate/Parent/Subsidiary Company's, operational existence. The CA MAY rely on its verification of a Government Entity's legal existence under Section 11.2 as verification of a Government Entity's operational existence. ________________________________ Motion Ends ________________________________ The review period for this ballot shall commence at 2200 UTC on 19 Feb 2015, and will close at 2200 UTC on 26 Feb 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on 5 Mar 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: From enric.castillo at anf.es Fri Feb 27 19:56:02 2015 From: enric.castillo at anf.es (Enric Castillo) Date: Fri, 27 Feb 2015 14:56:02 -0500 Subject: [cabfpub] Ballot 145 - Operational Existence for Government Entities In-Reply-To: References: Message-ID: <54F0CBD2.8010102@anf.es> ANF AC votes yes. ANF Autoridad de Certificaci?n *Enric Castillo* Director T?cnico +34 626818285 Gran Via de Les Corts Catalanes 996, Barcelona +593 0 998554992 12 de Octubre y Cordero, World Trade Center, Torre A, 1102, Quito ANF Autoridad de Certificaci?n www.anf.es *Aviso* Este mensaje se dirige exclusivamente a su destinatario y puede contener informaci?n privilegiada o confidencial y/o datos de car?cter personal, cuya difusi?n est? regulada por la Ley Org?nica de Protecci?n de Datos y la Ley de Servicios de la Sociedad de la Informaci?n. Si usted no es el destinatario indicado (o el responsable de la entrega al mismo), no debe copiar o entregar este mensaje a terceros bajo ning?n concepto. Si ha recibido este mensaje por error o lo ha conseguido por otros medios, le rogamos que nos lo comunique inmediatamente por esta misma v?a y proceda a su eliminaci?n irreversible. Las opiniones, conclusiones y dem?s informaciones incluidas en este mensaje que no est?n relacionadas con asuntos profesionales de ANF Autoridad de Certificaci?n no est?n respaldadas por la empresa. El 19/02/2015 a las 10:43, Jeremy Rowley escribi?: > > Ballot 145 - Operational Existence for Government Entities > > ------------------------------------------------------------------------ > > Reason > > ------------------------------------------------------------------------ > > Because government entities aren?t operating as businesses, they are > often not listed with a QIIS, especially immediately after the entity > is created by either statute or order. The legal existence of these > entities is verifiable through a QGIS, but this source in many > countries (especially Arabic and African countries) does not always > list a date of creation of these entities. Operational existence > exists to ensure organizations aren?t fly-by-night scams/phishing > entities. With government entities, these same risks are not present > as they are created directly by government action. > > Jeremy Rowley of DigiCert > made the following motion, which was endorsed by Rich Smith of Comodo > and Cecilia Kam of Symantec. > > ------------------------------------------------------------------------ > > Motion begins > > ------------------------------------------------------------------------ > > Effective immediately, section 11.6.1 is modified as follows: > > 11.6.1 Verification Requirements. > > The CA MUST verify that the Applicant has the ability to engage in > business by verifying the Applicant's, or Affiliate/Parent/Subsidiary > Company's, operational existence._The CA MAY rely on its verification > of a Government Entity?s legal existence under Section 11.2 as > verification of a Government Entity?s operational existence. _ > > ------------------------------------------------------------------------ > > Motion Ends > > ------------------------------------------------------------------------ > > The review period for this ballot shall commence at 2200 UTC on 19 Feb > 2015, and will close at 2200 UTC on 26 Feb 2015. Unless the motion is > withdrawn during the review period, the voting period will start > immediately thereafter and will close at 2200 UTC on 5 Mar 2015. Votes > must be cast by posting an on-list reply to this thread. > > A vote in favor of the motion must indicate a clear 'yes' in the > response. A vote against must indicate a clear 'no' in the response. A > vote to abstain must indicate a clear 'abstain' in the response. > Unclear responses will not be counted. The latest vote received from > any representative of a voting member before the close of the voting > period will be counted. Voting members are listed here: > https://cabforum.org/members/ > > In order for the motion to be adopted, two thirds or more of the votes > cast by members in the CA category and greater than 50% of the votes > cast by members in the browser category must be in favor. Quorum is > currently nine (9) members? at least nine members must participate in > the ballot, either by voting in favor, voting against, or abstaining. > > > > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo-anf.png Type: image/png Size: 4746 bytes Desc: not available URL: From eddy_nigg at startcom.org Fri Feb 27 20:32:28 2015 From: eddy_nigg at startcom.org (Eddy Nigg) Date: Fri, 27 Feb 2015 22:32:28 +0200 Subject: [cabfpub] Ballot 145 - Operational Existence for Government Entities In-Reply-To: References: Message-ID: <54F0D45C.9050501@startcom.org> If you need more yes votes, here another one: StartCom votes YES On 02/19/2015 05:43 PM, Jeremy Rowley wrote: > > Ballot 145 - Operational Existence for Government Entities > > ------------------------------------------------------------------------ > > Reason > > ------------------------------------------------------------------------ > > Because government entities aren't operating as businesses, they are > often not listed with a QIIS, especially immediately after the entity > is created by either statute or order. The legal existence of these > entities is verifiable through a QGIS, but this source in many > countries (especially Arabic and African countries) does not always > list a date of creation of these entities. Operational existence > exists to ensure organizations aren't fly-by-night scams/phishing > entities. With government entities, these same risks are not present > as they are created directly by government action. > > Jeremy Rowley of DigiCert > made the following motion, which was endorsed by Rich Smith of Comodo > and Cecilia Kam of Symantec. > > ------------------------------------------------------------------------ > > Motion begins > > ------------------------------------------------------------------------ > > Effective immediately, section 11.6.1 is modified as follows: > > 11.6.1 Verification Requirements. > > The CA MUST verify that the Applicant has the ability to engage in > business by verifying the Applicant's, or Affiliate/Parent/Subsidiary > Company's, operational existence._The CA MAY rely on its verification > of a Government Entity's legal existence under Section 11.2 as > verification of a Government Entity's operational existence. _ > > ------------------------------------------------------------------------ > > Motion Ends > > ------------------------------------------------------------------------ > > The review period for this ballot shall commence at 2200 UTC on 19 Feb > 2015, and will close at 2200 UTC on 26 Feb 2015. Unless the motion is > withdrawn during the review period, the voting period will start > immediately thereafter and will close at 2200 UTC on 5 Mar 2015. Votes > must be cast by posting an on-list reply to this thread. > > A vote in favor of the motion must indicate a clear 'yes' in the > response. A vote against must indicate a clear 'no' in the response. A > vote to abstain must indicate a clear 'abstain' in the response. > Unclear responses will not be counted. The latest vote received from > any representative of a voting member before the close of the voting > period will be counted. Voting members are listed here: > https://cabforum.org/members/ > > In order for the motion to be adopted, two thirds or more of the votes > cast by members in the CA category and greater than 50% of the votes > cast by members in the browser category must be in favor. Quorum is > currently nine (9) members-- at least nine members must participate in > the ballot, either by voting in favor, voting against, or abstaining. > > > > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public -- Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. XMPP: startcom at startcom.org Blog: Join the Revolution! Twitter: Follow Me -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4313 bytes Desc: S/MIME Cryptographic Signature URL: From rob.stradling at comodo.com Fri Feb 27 23:28:06 2015 From: rob.stradling at comodo.com (Rob Stradling) Date: Fri, 27 Feb 2015 18:28:06 -0500 Subject: [cabfpub] Updated Certificate Transparency + ExtendedValidationplan In-Reply-To: <54EFF00A.5030805@comodo.com> References: <2C97673F-8638-4592-8B0C-C7398D2221A7@apple.com> <54EF9D19.9070105@comodo.com> <0281DDB3-432A-4ABA-82B6-D757D92E6A4A@apple.com> <54EFF00A.5030805@comodo.com> Message-ID: <54F0FD86.3010608@comodo.com> Mat, BTW, do Apple have any plans to support CT in Safari? On 26/02/15 23:18, Rob Stradling wrote: > Good question, Mat. > > I've just generated a report (see attached) that shows, per issuing CA, > the number of certs with embedded SCTs that have been logged in the > currently existing CT logs so far. > > That is one measurement of which CAs are "on board", but it's not the > full story. > > On 26/02/15 17:39, Mat Caughron wrote: >> Hello Rob, >> >> So presumably, the survey if conducted now would indicate a few more >> CA's on board than indicated here? >> http://www.certificate-transparency.org/feb-2014-survey-responses >> >> >> >> Mat Caughron >> ? Product Security >> mcaughron at appe.com >> >> >> >>> On Feb 26, 2015, at 2:24 PM, Rob Stradling >> > wrote: >>> >>> On 26/02/15 17:15, Mat Caughron wrote: >>>> Greetings: >>>> >>>> It has been one year, has this CT plan been updated at all? >>> >>> Hi Mat. >>> >>> Google's EV/CT Plan has been updated a couple of times since then. >>> See here: >>> http://www.certificate-transparency.org/ev-ct-plan >>> >>>> Sincerely, >>>> >>>> >>>> Mat Caughron >>>> ? Product Security >>>> >>>> >>>> >>>>> On Feb 4, 2014, at 9:08 AM, Ben Laurie wrote: >>>>> >>>>> Enclosed, our revised plan. >>>>> >>>>> Comments welcome. >>>>> _______________________________________________ >>>>> >>>>> Public mailing list >>>>> Public at cabforum.org >>>>> https://cabforum.org/mailman/listinfo/public >>>> >>> >>> -- >>> Rob Stradling >>> Senior Research & Development Scientist >>> COMODO - Creating Trust Online >> > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. From kirk_hall at trendmicro.com Sun Feb 1 20:05:21 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Sun, 1 Feb 2015 20:05:21 +0000 Subject: [cabfpub] Ballot 145 - Formalization of Validation Working Group In-Reply-To: <54CA80B3.3050503@comodo.com> References: <54CA80B3.3050503@comodo.com> Message-ID: Trend Micro will also endorse. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Rich Smith Sent: Thursday, January 29, 2015 10:49 AM To: public at cabforum.org; jeremy.rowley at digicert.com Subject: Re: [cabfpub] Ballot 145 - Formalization of Validation Working Group I'll endorse. Rich On 1/29/2015 11:56 AM, Jeremy Rowley wrote: This is the ballot to formalize the validation working group and modify its scope to include validation and the inclusion of information in certificates. I'm looking for two endorsers Ballot 145 - Formalization of Validation Working Group Reason In order to address validation issues and inconsistencies in both the SSL Baseline Requirements and the EV Guidelines, the CAB Forum has held an informal working group previously referred to as the Extended Validation Working Group now known as the Validation Working Group, would like to modify its scope to include validation in the Baseline Requirements as well as the EV Guidelines. - Motion begins - The CA-Browser Forum formally establishes the Validation Working Group as an official working group of the CAB Forum, replacing the previous informal EV working group. The scope of this working group is to address issues arising under adopted CAB Forum standards related to the validation of certificate information and the inclusion of information in certificates. Scope: The Validation Working Group will consider all matters relating to the validation and inclusion of information in certificates under adopted CAB Forum guidelines. Deliverables: The Working Group shall produce one or more documents offering options to the Forum for validation within the scope defined above. -- Motion Ends -- The review period for this ballot shall commence at 2200 UTC on , and will close at 2200 UTC on . Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on . Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. _______________________________________________ Public mailing list Public at cabforum.org https://cabforum.org/mailman/listinfo/public 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
-------------- next part -------------- An HTML attachment was scrubbed... URL: From jeremy.rowley at digicert.com Wed Feb 4 20:51:56 2015 From: jeremy.rowley at digicert.com (Jeremy Rowley) Date: Wed, 4 Feb 2015 20:51:56 +0000 Subject: [cabfpub] Ballot .onion ballot Message-ID: The following is the finalized onion ballot. I made two changes since we spoke in the last meeting. The first is based on Tom Ritter's feedback. He mentioned that there might be several onion names for a single entity so adding an identifier in the data structure that links the onionURI to the nonce would be helpful. I've included it below. I also realized that without a change to the BRs, CAs could still issue .onion names under the BRs as an internal name OR under the EV Guidelines. Since the goal is to lock down .onion issuance, I added a restriction that all .onion names would need to be revoked by May 1 if the ballot passes. I assume everyone is still willing to endorse? --- Applicants want a CA-signed .onion address for several reasons, including: - Powerful web platform features are restricted to secure origins, which are currently not available to onion names (in part, because of the lack of IANA registration). Permitting EV certs for onion names will help provide a secure origin for the service, moving onion towards use of powerful web platform features. - Currently, access to .onion names over https from a standard browser results in the standard existing 'Invalid Certificate' warning. Training users to click through security warnings lowers the value of these warnings and will cause users to miss important security information. Removing these warnings for the user, through use of a digital certificate, will help users recognize and avoid real MITM attacks. - The public needs attribution of ownership of the .onion address to differentiate onion services, including potential phishing services. Because onion names are not easily recognizable strings, providing the public with additional information about the operator has significant security improvements, especially in regions where use of the incorrect name could have lethal consequences. The following motion has been proposed by Jeremy Rowley of DigiCert and endorsed by Ryan Sleevi of Google and Wayne Thayer of GoDaddy. --------------------- Motion Starts --------------------- Amend Section 9.2.1 of the Baseline Requirements v. 1.2.3 as follows: 9.2.1 Subject Alternative Name Extension Certificate Field: extensions:subjectAltName Required/Optional: Required Contents: This 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. The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate. Wildcard FQDNs are permitted. As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name, the CA SHALL notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016. Also as of the Effective Date, the CA SHALL NOT issue a certificate with an Expiry Date later than 1 November 2015 with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name. Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Name. Effective May 1, 2015, each CA SHALL revoke all unexpired Certificates with an Internal Name using onion as the left-most label in an entry in the subjectAltName Extension or commonName field unless such Certificate was issued in accordance with Appendix F of the EV Guidelines. Amend the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2 as follows: Amend Section 9.2.2 and 11.7.1 as follows: 9.2.2. Subject Alternative Name Extension Certificate field: subjectAltName:dNSName Required/Optional: Required Contents: This extension MUST contain one or more host Domain Name(s) owned or controlled by the Subject and to be associated with the Subject's server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). Wildcard certificates are not allowed for EV Certificates except as permitted under Appendix F. 11.7 Verification of Applicant's Domain Name 11.7.1. Verification Requirements (1) For each Fully-Qualified Domain Name listed in a Certificate, other than a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant (or the Applicant's Parent Company, Subsidiary Company, or Affiliate, collectively referred to as "Applicant" for the purposes of this section) either is the Domain Name Registrant or has control over the FQDN using a procedure specified in Section 11.1.1 of the Baseline Requirements, except that a CA MAY NOT verify a domain using the procedure described 11.1.1(7). For a Certificate issued to a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant's control over the .onion Domain Name in accordance with Appendix F. (2) Mixed Character Set Domain Names: EV Certificates MAY include Domain Names containing mixed character sets only in compliance with the rules set forth by the domain registrar. The CA MUST visually compare any Domain Names with mixed character sets with known high risk domains. If a similarity is found, then the EV Certificate Request MUST be flagged as High Risk. The CA must perform reasonably appropriate additional authentication and verification to be certain beyond reasonable doubt that the Applicant and the target in question are the same organization. Add a new Appendix F: Appendix F - Issuance of Certificates for .onion Domain Names A CA may issue an EV Certificate with .onion in the right-most label of the Domain Name provided that issuance complies with the requirements set forth in this Appendix: 1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) The CAB Forum has created an extension of the TBSCertificate for use in conveying hashes of keys related to .onion addresses. The Tor Service Descriptor Hash extension has the following format: cabf-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 } TorServiceDescriptorSyntax ::= SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash TorServiceDescriptorHash:: = SEQUENCE { onionURI UTF8String algorithm AlgorithmIdentifier subjectPublicKeyHash BIT STRING } Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 6234) performed over the DER-encoding of an ASN.1 SubjectPublicKey of the .onion service and SubjectPublicKeyHash is the hash output. 2. The CA MUST verify the Applicant's control over the .onion Domain Name using one of the following: a. The CA MAY verify the Applicant's control over the .onion service by posting a specific value at a well-known URL under RFC5785. b. The CA MAY verify the Applicant's control over the .onion service by having the Applicant provide a Certificate Request signed using the .onion public key if the Attributes section of the certificationRequestInfo contains: (i) A caSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy, 2) is generated by the CA, and 3) delivered to the Applicant through a Verified Method of Communication and (ii) An applicantSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy and 2) is generated by the Applicant. The signing nonce attributes have the following format: caSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-caSigningNonce } } cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } applicantSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-applicantSigningNonce } } cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 } 4. Each Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name MUST conform to the requirements of these Guidelines, including the content requirements in Section 9 and Appendix B of the Baseline Requirements, except that the CA MAY include a wildcard character in the Subject Alternative Name Extension and Subject Common Name Field as the leftmost character in the .onion Domain Name provided inclusion of the wildcard character complies with Section 11.1.3 of the Baseline Requirements. 5. CAs MUST NOT issue a Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name with a validity period longer than 15 months. Despite Section 9.2.1 of the Baseline Requirements deprecating the use of Internal Names, a CA MAY issue a Certificate containing an .onion name with an expiration date later than 1 November 2015 after (and only if) .onion is officially recognized by the IESG as a reserved TLD. 6. On or before February 15, 2015, each CA MUST revoke all Certificates issued with the Subject Alternative Name extension or Common Name field that includes a Domain Name where .onion is in the right-most label of the Domain Name unless the Certificate was issued in compliance with this Appendix F. ---- Motion Ends ----- The review period for this ballot shall commence at 2200 UTC on Thursday, 4 February 2015, and will close at 2200 UTC on Thursday, 11 February 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on Monday, 18 February 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeremy.rowley at digicert.com Wed Feb 4 21:05:19 2015 From: jeremy.rowley at digicert.com (Jeremy Rowley) Date: Wed, 4 Feb 2015 21:05:19 +0000 Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group Message-ID: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> Ballot 143 - Formalization of validation working group ---- Reason ---- In order to address validation issues and inconsistencies in both the SSL Baseline Requirements and the EV Guidelines, the CAB Forum has held an informal working group previously referred to as the Extended Validation Working Group now known as the Validation Working Group, would like to modify its scope to include validation in the Baseline Requirements as well as the EV Guidelines. Jeremy Rowley of DigiCert made the following motion, which was endorsed by Rich Smith of Comodo and Kirk Hall of TrendMicro ---- Motion begins ---- The CA-Browser Forum formally establishes the Validation Working Group as an official working group of the CAB Forum, replacing the previous informal EV working group. The scope of this working group is to address issues arising under adopted CAB Forum standards related to the validation of certificate information and the inclusion of information in certificates. Scope: The Validation Working Group will consider all matters relating to the validation and inclusion of information in certificates under adopted CAB Forum guidelines. Deliverables: The Working Group shall produce one or more documents offering options to the Forum for validation within the scope defined above. ---- Motion Ends ---- The review period for this ballot shall commence at 2200 UTC on 5 Feb 2015, and will close at 2200 UTC on 11 Feb 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on 18 Feb 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Dean_Coclin at symantec.com Wed Feb 4 21:16:11 2015 From: Dean_Coclin at symantec.com (Dean Coclin) Date: Wed, 4 Feb 2015 13:16:11 -0800 Subject: [cabfpub] Draft Agenda for CA/B Forum call February 5, 2015 Message-ID: <14D026C7F297AD44AC82578DD818CDD038EEF0B789@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> We have an open 10 min slot below if anyone has a topic they'd like to discuss. Antitrust Statement: As you know, this meeting includes companies that compete against one another. This meeting is intended to discuss technical standards related to the provision of existing and new types of digital certificates without restricting competition in developing and marketing such certificates. This meeting is not intended to share competitively-sensitive information among competitors, and therefore all participants agree not to discuss or exchange information related to: (a) Pricing policies, pricing formulas, prices or other terms of sale; (b) Costs, cost structures, profit margins, (c) Pending or planned service offerings, (d) Customers, business, or marketing plans; or (e) The allocation of customers, territories, or products in any way. Note: Please announce yourself when you dial in. This helps in documenting attendance when recording is played back later. Here is the proposed agenda: Time Start(UTC) Stop Slot Description Notes / Presenters (Thur) 5 Feb 2015 0:01 16:00 16:01 1 Read Antitrust Statement Dean 0:02 16:01 16:03 2 Roll Call Dean 0:01 16:03 16:04 3 Review Agenda Dean 0:01 16:04 16:05 4 Approve Minutes of 22 Jan 2015 Distributed by Kirk on Jan 23rd 0:20 16:05 16:25 5 Ballot Updates: EV Working Group change, .Onion Ballot, Other EV Ballots? Jeremy, Kirk 0:05 16:25 16:30 6 Vivaldi 0:07 16:30 16:37 7 Any more discussion on IPv6? Ryan 0:10 16:37 16:47 8 Open Slot 0:05 16:45 16:50 9 EV Working Group Status Update Jeremy 0:02 16:50 16:52 10 Code Signing Working Group Status Update Dean/Jeremy -Public draft 0:02 16:52 16:54 11 Policy Review Working Group Status Update Ben/Dean-Boston meeting Jan 27th postponed due to blizzard 0:02 16:54 16:56 12 *New* Information Sharing Working Group Update Ben 0:03 16:56 16:59 13 Any Other Business - Cupertino Meeting-March 10-12: 26 attendees signed up so far 0:00 17:00 17:00 14 Next phone call - February 19, 2015 0:00 17:00 17:00 15 Adjourn -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6130 bytes Desc: not available URL: From jeremy.rowley at digicert.com Wed Feb 4 21:19:45 2015 From: jeremy.rowley at digicert.com (Jeremy Rowley) Date: Wed, 4 Feb 2015 21:19:45 +0000 Subject: [cabfpub] Ballot .onion ballot In-Reply-To: References: Message-ID: <445290cba41444119f8c958eebbcc76a@EX2.corp.digicert.com> One correction. It should have read "right-most" not "left-most". (Fixed below) The following is the finalized onion ballot. I made two changes since we spoke in the last meeting. The first is based on Tom Ritter's feedback. He mentioned that there might be several onion names for a single entity so adding an identifier in the data structure that links the onionURI to the nonce would be helpful. I've included it below. I also realized that without a change to the BRs, CAs could still issue .onion names under the BRs as an internal name OR under the EV Guidelines. Since the goal is to lock down .onion issuance, I added a restriction that all .onion names would need to be revoked by May 1 if the ballot passes. I assume everyone is still willing to endorse? --- Applicants want a CA-signed .onion address for several reasons, including: - Powerful web platform features are restricted to secure origins, which are currently not available to onion names (in part, because of the lack of IANA registration). Permitting EV certs for onion names will help provide a secure origin for the service, moving onion towards use of powerful web platform features. - Currently, access to .onion names over https from a standard browser results in the standard existing 'Invalid Certificate' warning. Training users to click through security warnings lowers the value of these warnings and will cause users to miss important security information. Removing these warnings for the user, through use of a digital certificate, will help users recognize and avoid real MITM attacks. - The public needs attribution of ownership of the .onion address to differentiate onion services, including potential phishing services. Because onion names are not easily recognizable strings, providing the public with additional information about the operator has significant security improvements, especially in regions where use of the incorrect name could have lethal consequences. The following motion has been proposed by Jeremy Rowley of DigiCert and endorsed by Ryan Sleevi of Google and Wayne Thayer of GoDaddy. --------------------- Motion Starts --------------------- Amend Section 9.2.1 of the Baseline Requirements v. 1.2.3 as follows: 9.2.1 Subject Alternative Name Extension Certificate Field: extensions:subjectAltName Required/Optional: Required Contents: This 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. The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate. Wildcard FQDNs are permitted. As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name, the CA SHALL notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016. Also as of the Effective Date, the CA SHALL NOT issue a certificate with an Expiry Date later than 1 November 2015 with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name. Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Name. Effective May 1, 2015, each CA SHALL revoke all unexpired Certificates with an Internal Name using onion as the right-most label in an entry in the subjectAltName Extension or commonName field unless such Certificate was issued in accordance with Appendix F of the EV Guidelines. Amend the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2 as follows: Amend Section 9.2.2 and 11.7.1 as follows: 9.2.2. Subject Alternative Name Extension Certificate field: subjectAltName:dNSName Required/Optional: Required Contents: This extension MUST contain one or more host Domain Name(s) owned or controlled by the Subject and to be associated with the Subject's server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). Wildcard certificates are not allowed for EV Certificates except as permitted under Appendix F. 11.7 Verification of Applicant's Domain Name 11.7.1. Verification Requirements (1) For each Fully-Qualified Domain Name listed in a Certificate, other than a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant (or the Applicant's Parent Company, Subsidiary Company, or Affiliate, collectively referred to as "Applicant" for the purposes of this section) either is the Domain Name Registrant or has control over the FQDN using a procedure specified in Section 11.1.1 of the Baseline Requirements, except that a CA MAY NOT verify a domain using the procedure described 11.1.1(7). For a Certificate issued to a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant's control over the .onion Domain Name in accordance with Appendix F. (2) Mixed Character Set Domain Names: EV Certificates MAY include Domain Names containing mixed character sets only in compliance with the rules set forth by the domain registrar. The CA MUST visually compare any Domain Names with mixed character sets with known high risk domains. If a similarity is found, then the EV Certificate Request MUST be flagged as High Risk. The CA must perform reasonably appropriate additional authentication and verification to be certain beyond reasonable doubt that the Applicant and the target in question are the same organization. Add a new Appendix F: Appendix F - Issuance of Certificates for .onion Domain Names A CA may issue an EV Certificate with .onion in the right-most label of the Domain Name provided that issuance complies with the requirements set forth in this Appendix: 1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) The CAB Forum has created an extension of the TBSCertificate for use in conveying hashes of keys related to .onion addresses. The Tor Service Descriptor Hash extension has the following format: cabf-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 } TorServiceDescriptorSyntax ::= SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash TorServiceDescriptorHash:: = SEQUENCE { onionURI UTF8String algorithm AlgorithmIdentifier subjectPublicKeyHash BIT STRING } Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 6234) performed over the DER-encoding of an ASN.1 SubjectPublicKey of the .onion service and SubjectPublicKeyHash is the hash output. 2. The CA MUST verify the Applicant's control over the .onion Domain Name using one of the following: a. The CA MAY verify the Applicant's control over the .onion service by posting a specific value at a well-known URL under RFC5785. b. The CA MAY verify the Applicant's control over the .onion service by having the Applicant provide a Certificate Request signed using the .onion public key if the Attributes section of the certificationRequestInfo contains: (i) A caSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy, 2) is generated by the CA, and 3) delivered to the Applicant through a Verified Method of Communication and (ii) An applicantSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy and 2) is generated by the Applicant. The signing nonce attributes have the following format: caSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-caSigningNonce } } cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } applicantSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-applicantSigningNonce } } cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 } 4. Each Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name MUST conform to the requirements of these Guidelines, including the content requirements in Section 9 and Appendix B of the Baseline Requirements, except that the CA MAY include a wildcard character in the Subject Alternative Name Extension and Subject Common Name Field as the right-most character in the .onion Domain Name provided inclusion of the wildcard character complies with Section 11.1.3 of the Baseline Requirements. 5. CAs MUST NOT issue a Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name with a validity period longer than 15 months. Despite Section 9.2.1 of the Baseline Requirements deprecating the use of Internal Names, a CA MAY issue a Certificate containing an .onion name with an expiration date later than 1 November 2015 after (and only if) .onion is officially recognized by the IESG as a reserved TLD. 6. On or before February 15, 2015, each CA MUST revoke all Certificates issued with the Subject Alternative Name extension or Common Name field that includes a Domain Name where .onion is in the right-most label of the Domain Name unless the Certificate was issued in compliance with this Appendix F. ---- Motion Ends ----- The review period for this ballot shall commence at 2200 UTC on Thursday, 4 February 2015, and will close at 2200 UTC on Thursday, 11 February 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on Monday, 18 February 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sleevi at google.com Wed Feb 4 22:08:10 2015 From: sleevi at google.com (Ryan Sleevi) Date: Wed, 4 Feb 2015 14:08:10 -0800 Subject: [cabfpub] Ballot .onion ballot In-Reply-To: References: Message-ID: On Wed, Feb 4, 2015 at 12:51 PM, Jeremy Rowley wrote: > I assume everyone is still willing to endorse? Thanks for continuing to work on this. Indeed, willing to. However, note your added revocation clause is duplicated in point 6 (with the earlier Feb 15 date). I'm guessing you just forgot you already had this clause ;) For those considering: This restricts the existing set of capabilities to issue .onion from "Whatever you want" (under internal name rules) to "Under these rules", but does nothing to prolong past the internal names sunset (.onion is still an internal name unless IANA delegates it, and a separate ballot will be needed IF IANA decides to never delegate and reserve as a special-purpose domain) From jeremy.rowley at digicert.com Wed Feb 4 22:10:26 2015 From: jeremy.rowley at digicert.com (Jeremy Rowley) Date: Wed, 4 Feb 2015 22:10:26 +0000 Subject: [cabfpub] Ballot .onion ballot In-Reply-To: References: Message-ID: Thanks - I had it in EV, but that won't effect certs issued under the BRs. I just need to update the dates so they match :) And thanks for the clarification. That's indeed the purpose. If IANA chooses not the reserve the name, we'll need to have a separate discussion on how (and whether) to proceed. -----Original Message----- From: Ryan Sleevi [mailto:sleevi at google.com] Sent: Wednesday, February 4, 2015 3:08 PM To: Jeremy Rowley Cc: CABFPub Subject: Re: [cabfpub] Ballot .onion ballot On Wed, Feb 4, 2015 at 12:51 PM, Jeremy Rowley wrote: > I assume everyone is still willing to endorse? Thanks for continuing to work on this. Indeed, willing to. However, note your added revocation clause is duplicated in point 6 (with the earlier Feb 15 date). I'm guessing you just forgot you already had this clause ;) For those considering: This restricts the existing set of capabilities to issue .onion from "Whatever you want" (under internal name rules) to "Under these rules", but does nothing to prolong past the internal names sunset (.onion is still an internal name unless IANA delegates it, and a separate ballot will be needed IF IANA decides to never delegate and reserve as a special-purpose domain) From wthayer at godaddy.com Thu Feb 5 04:00:39 2015 From: wthayer at godaddy.com (Wayne Thayer) Date: Thu, 5 Feb 2015 04:00:39 +0000 Subject: [cabfpub] Ballot .onion ballot In-Reply-To: References: Message-ID: <8144CFC7-F7F4-4FB4-9CF1-716BB32E4BDC@godaddy.com> Yes, I?ll still endorse. On 2/4/15, 3:10 PM, "Jeremy Rowley" wrote: >I assume everyone is still willing to endorse? From adriano.santoni at staff.aruba.it Thu Feb 5 07:24:51 2015 From: adriano.santoni at staff.aruba.it (Adriano Santoni) Date: Thu, 05 Feb 2015 08:24:51 +0100 Subject: [cabfpub] Draft Agenda for CA/B Forum call February 5, 2015 In-Reply-To: <14D026C7F297AD44AC82578DD818CDD038EEF0B789@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> References: <14D026C7F297AD44AC82578DD818CDD038EEF0B789@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> Message-ID: <54D31AC3.4000009@staff.aruba.it> An HTML attachment was scrubbed... URL: From atsushi.inaba at globalsign.com Thu Feb 5 07:36:05 2015 From: atsushi.inaba at globalsign.com (Atsushi Inaba) Date: Thu, 5 Feb 2015 07:36:05 +0000 Subject: [cabfpub] Draft Agenda for CA/B Forum call February 5, 2015 In-Reply-To: <54D31AC3.4000009@staff.aruba.it> References: <14D026C7F297AD44AC82578DD818CDD038EEF0B789@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> <54D31AC3.4000009@staff.aruba.it> Message-ID: Hello, I suppose that Vivaldi means the browser released recently. Please forgive me if I'm wrong.... Kind regards, Atsushi Inaba From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Adriano Santoni Sent: Thursday, February 5, 2015 4:25 PM To: public at cabforum.org Subject: Re: [cabfpub] Draft Agenda for CA/B Forum call February 5, 2015 Hi all, what is "Vivaldi" ? Adriano Il 04/02/2015 22:16, Dean Coclin ha scritto: We have an open 10 min slot below if anyone has a topic they'd like to discuss. Antitrust Statement: As you know, this meeting includes companies that compete against one another. This meeting is intended to discuss technical standards related to the provision of existing and new types of digital certificates without restricting competition in developing and marketing such certificates. This meeting is not intended to share competitively-sensitive information among competitors, and therefore all participants agree not to discuss or exchange information related to: (a) Pricing policies, pricing formulas, prices or other terms of sale; (b) Costs, cost structures, profit margins, (c) Pending or planned service offerings, (d) Customers, business, or marketing plans; or (e) The allocation of customers, territories, or products in any way. Note: Please announce yourself when you dial in. This helps in documenting attendance when recording is played back later. Here is the proposed agenda: Time Start(UTC) Stop Slot Description Notes / Presenters (Thur) 5 Feb 2015 0:01 16:00 16:01 1 Read Antitrust Statement Dean 0:02 16:01 16:03 2 Roll Call Dean 0:01 16:03 16:04 3 Review Agenda Dean 0:01 16:04 16:05 4 Approve Minutes of 22 Jan 2015 Distributed by Kirk on Jan 23rd 0:20 16:05 16:25 5 Ballot Updates: EV Working Group change, .Onion Ballot, Other EV Ballots? Jeremy, Kirk 0:05 16:25 16:30 6 Vivaldi 0:07 16:30 16:37 7 Any more discussion on IPv6? Ryan 0:10 16:37 16:47 8 Open Slot 0:05 16:45 16:50 9 EV Working Group Status Update Jeremy 0:02 16:50 16:52 10 Code Signing Working Group Status Update Dean/Jeremy -Public draft 0:02 16:52 16:54 11 Policy Review Working Group Status Update Ben/Dean-Boston meeting Jan 27th postponed due to blizzard 0:02 16:54 16:56 12 *New* Information Sharing Working Group Update Ben 0:03 16:56 16:59 13 Any Other Business - Cupertino Meeting-March 10-12: 26 attendees signed up so far 0:00 17:00 17:00 14 Next phone call - February 19, 2015 0:00 17:00 17:00 15 Adjourn _______________________________________________ Public mailing list Public at cabforum.org https://cabforum.org/mailman/listinfo/public -- Adriano Santoni -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4315 bytes Desc: not available URL: From adriano.santoni at staff.aruba.it Thu Feb 5 07:45:57 2015 From: adriano.santoni at staff.aruba.it (Adriano Santoni) Date: Thu, 05 Feb 2015 08:45:57 +0100 Subject: [cabfpub] Draft Agenda for CA/B Forum call February 5, 2015 In-Reply-To: References: <14D026C7F297AD44AC82578DD818CDD038EEF0B789@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> <54D31AC3.4000009@staff.aruba.it> Message-ID: <54D31FB5.4070106@staff.aruba.it> An HTML attachment was scrubbed... URL: From erwann.abalea at opentrust.com Thu Feb 5 10:05:01 2015 From: erwann.abalea at opentrust.com (Erwann Abalea) Date: Thu, 05 Feb 2015 11:05:01 +0100 Subject: [cabfpub] Ballot .onion ballot In-Reply-To: <445290cba41444119f8c958eebbcc76a@EX2.corp.digicert.com> References: <445290cba41444119f8c958eebbcc76a@EX2.corp.digicert.com> Message-ID: <54D3404D.90808@opentrust.com> Bonjour, Le 04/02/2015 22:19, Jeremy Rowley a ?crit : [...] > Amend the Guidelines for the Issuance and Management of Extended > Validation Certificates v1.5.2 as follows: > > Amend Section 9.2.2 and 11.7.1 as follows: > > 9.2.2. Subject Alternative Name Extension Certificate field: > subjectAltName:dNSName > > Required/Optional: Required > > Contents: This extension MUST contain one or more host Domain Name(s) > owned or controlled by the Subject and to be associated with the > Subject's server. Such server MAY be owned and operated by the Subject > or another entity (e.g., a hosting service). Wildcard certificates are > not allowed for EV Certificates_except as permitted under Appendix F_. > So an EV certificate can't be a wildcard one, except under some new conditions, applicable only to .onion names. Not a small change. [...] > Add a new Appendix F: > > Appendix F -- Issuance of Certificates for .onion Domain Names > [...] > 4. Each Certificate that includes a Domain Name where .onion is in the > right-most label of the Domain Name MUST conform to the requirements > of these Guidelines, including the content requirements in Section 9 > and Appendix B of the Baseline Requirements, except that the CA MAY > include a wildcard character in the Subject Alternative Name Extension > and Subject Common Name Field as the right-most character in the > .onion Domain Name provided inclusion of the wildcard character > complies with Section 11.1.3 of the Baseline Requirements. > What does that mean? is *.onion accepted? is *.onion accepted? -- Erwann ABALEA -------------- next part -------------- An HTML attachment was scrubbed... URL: From gerv at mozilla.org Thu Feb 5 10:25:35 2015 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 05 Feb 2015 10:25:35 +0000 Subject: [cabfpub] Ballot .onion ballot In-Reply-To: <54D3404D.90808@opentrust.com> References: <445290cba41444119f8c958eebbcc76a@EX2.corp.digicert.com> <54D3404D.90808@opentrust.com> Message-ID: <54D3451F.4090201@mozilla.org> On 05/02/15 10:05, Erwann Abalea wrote: > What does that mean? > is *.onion accepted? > is *.onion accepted? You are right; this should say "left-most label" not "right-most character". Gerv From erwann.abalea at opentrust.com Thu Feb 5 14:13:59 2015 From: erwann.abalea at opentrust.com (Erwann Abalea) Date: Thu, 05 Feb 2015 15:13:59 +0100 Subject: [cabfpub] Ballot .onion ballot In-Reply-To: <54D3451F.4090201@mozilla.org> References: <445290cba41444119f8c958eebbcc76a@EX2.corp.digicert.com> <54D3404D.90808@opentrust.com> <54D3451F.4090201@mozilla.org> Message-ID: <54D37AA7.8040101@opentrust.com> Le 05/02/2015 11:25, Gervase Markham a ?crit : > On 05/02/15 10:05, Erwann Abalea wrote: >> What does that mean? >> is *.onion accepted? >> is *.onion accepted? > You are right; this should say "left-most label" not "right-most character". Even with this typo corrected, what is the rationale behind allowing wildcard EV certificates for .onion domains while rejecting wildcards for all other EV certs? Why should "*.facebookcorewwwi.onion" be allowed and "*.facebook.com" refused? -- Erwann ABALEA From gerv at mozilla.org Thu Feb 5 14:26:39 2015 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 05 Feb 2015 14:26:39 +0000 Subject: [cabfpub] Ballot .onion ballot In-Reply-To: <54D37AA7.8040101@opentrust.com> References: <445290cba41444119f8c958eebbcc76a@EX2.corp.digicert.com> <54D3404D.90808@opentrust.com> <54D3451F.4090201@mozilla.org> <54D37AA7.8040101@opentrust.com> Message-ID: <54D37D9F.1070907@mozilla.org> On 05/02/15 14:13, Erwann Abalea wrote: > Even with this typo corrected, what is the rationale behind allowing > wildcard EV certificates for .onion domains while rejecting wildcards > for all other EV certs? > > Why should "*.facebookcorewwwi.onion" be allowed and "*.facebook.com" > refused? I'm not the person who argued for a restriction on *.facebook.com EV, but the idea of no wildcard for EV, as I understand it, is that you then get e.g. EV "*.blogspot.com" and the actual person controlling fred.blogspot.com is not named in the EV cert fred.blogspot.com is using, thereby defeating the point of EV as being about identity. With .onion, there is a single private key (the one whose public fingerprint is facebookcorewwwi, in the case of Facebook) and so the idea of different mutually-untrusting entities owning and controlling different parts of the subdomain space doesn't really make much sense. So the above risk is not present. Gerv From jeremy.rowley at digicert.com Thu Feb 5 14:53:27 2015 From: jeremy.rowley at digicert.com (Jeremy Rowley) Date: Thu, 5 Feb 2015 14:53:27 +0000 Subject: [cabfpub] Ballot .onion ballot In-Reply-To: <54D3451F.4090201@mozilla.org> References: <445290cba41444119f8c958eebbcc76a@EX2.corp.digicert.com> <54D3404D.90808@opentrust.com> <54D3451F.4090201@mozilla.org> Message-ID: <2eebcc99c215491d9c19124f51c21f45@EX2.corp.digicert.com> Right - I changed both unintentionally. I'll make this correction and the correction Ryan Sleevi pointed out right after today's call. -----Original Message----- From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Gervase Markham Sent: Thursday, February 5, 2015 3:26 AM To: Erwann Abalea; public at cabforum.org Subject: Re: [cabfpub] Ballot .onion ballot On 05/02/15 10:05, Erwann Abalea wrote: > What does that mean? > is *.onion accepted? > is *.onion accepted? You are right; this should say "left-most label" not "right-most character". Gerv _______________________________________________ Public mailing list Public at cabforum.org https://cabforum.org/mailman/listinfo/public From gerv at mozilla.org Thu Feb 5 15:29:04 2015 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 05 Feb 2015 15:29:04 +0000 Subject: [cabfpub] Not coming to Switzerland in June :-( Message-ID: <54D38C40.90005@mozilla.org> Dear CAB Forum members, Unfortunately, Mozilla has scheduled a get-together the same week as the CAB Forum meeting in Switzerland at the end of June, so I will not be able to make it, or to dial in, and it's unlikely that any other Mozilla representative would be able to either. I don't want to have delusions of my own importance, but it has been noted before that it's important to have browser participation in face-to-face meetings. I also note that our friends at Google and Opera have not been attending in person recently, with their last attendances being: Opera: Meeting 30 (Sep 2013) Google: Meeting 28 (Feb 2013) Hence, I thought I'd note our planned absence so that if Microsoft were not planning to send anyone (and neither were Google or Opera), we could at least discuss whether the CAs in the group would prefer to meet alone, or would prefer to investigate an alternative week (by arrangement with our gracious hosts). Ryan? Jody? Sigbjorn? Gerv From douglas.beattie at globalsign.com Thu Feb 5 16:34:25 2015 From: douglas.beattie at globalsign.com (Doug Beattie) Date: Thu, 5 Feb 2015 16:34:25 +0000 Subject: [cabfpub] Preballot for IPv6 Support In-Reply-To: References: <548F4FAD.8070207@startcom.org> <65e414a19c364c0995474791821af203@EX2.corp.digicert.com> Message-ID: Ryan, GlobalSign, both GlobalSign proper and our CDN provider, support IPv4 and IPv6 for OCSP and CRLs today. Doug From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ryan Sleevi Sent: Wednesday, December 17, 2014 12:50 AM To: Jeremy Rowley Cc: CABFPub Subject: Re: [cabfpub] Preballot for IPv6 Support For the sake of the Forum and those questioning the value of this, I'd like to point out that this is not just theoretical for clients. Consider this message -http://seclists.org/nanog/2014/Dec/114 - to NANOG from one of the largest USP ISPs, Time Warner Cable about the trouble that they're having making a client that "Does PKI right" and the challenges they face (Robert's bio from the ARIN Advisory Council to fill in the value for $DAYJOB - https://www.arin.net/about_us/ac.html#rseastrom ) The lack of IPv6 universally penalizes a client that chooses to support revocation checking, because now in addition to supporting IPv6 on the server, server operators have to be aware of their CA's infrastructure support for IPv6. What's worse, if you look at the incentives, this penalizes the client. From the user's perspective, the choice to implement revocation checking is the fault of the device manufacturer/deployer (Time Warner), rather than an issue with the remote server. The remote server is unlikely to be told by end users that their site doesn't work when using Time Warner devices - instead, Time Warner will be told that the server doesn't work with them. These sorts of penalties have already been reported by browsers that have lead to questioning the revocation strategies, but this is yet another ecosystem affected. On Tue, Dec 16, 2014 at 8:29 PM, Jeremy Rowley > wrote: The proposal is more likely to force CAs into using their own infrastructure to provide revocation information than forcing CDNs and hosting providers to use IPv6, slowing OCSP response times. However, nothing wrong with gathering the information and looking at which CDNs and providers we need to get on board with the proposal. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ryan Sleevi Sent: Monday, December 15, 2014 2:59 PM To: Eddy Nigg Cc: CABFPub Subject: Re: [cabfpub] Preballot for IPv6 Support On Mon, Dec 15, 2014 at 1:16 PM, Eddy Nigg > wrote: On 12/15/2014 11:02 PM, Ryan Sleevi wrote: As discussed on our call last week, I'd like to put together a ballot requiring that CAs support IPv6 for their external (relying party facing) infrastructure. Funny that you want to start with that part first - most of the time that's the part CAs have the least control over it and depend on third parties. I'm not sure I follow this. CAs aren't required to delegate their infrastructure out to third-parties. If they chose to, then they have to pick third-parties who are capable of meeting the Baseline Requirements (e.g. the current 24/7 uptime requirements or the 10 second availability). If a new requirement comes down, the question is how long will it take for the CAs to either get their infrastructure updated, get their third parties to update, or transition to new third parties. That's fundamentally the question I'm asking. This is surely NOT a problem that's impossible. If CAs are telling third parties that they need IPv6 support, then eventually there will be IPv6 support. As both servers and clients transition to IPv6-only networks, the goal is to ensure that services RPs need are accessible. Hardly 5 % as of today - and I assume they all (must) support IPv4 in any case since the vast majority doesn't support IPv6. That's an assumption that is, in part, caused by the unavailability of some services over IPv4. This is a collective action problem, as the CA industry is quite familiar with, so I don't understand why "we don't support it today" is necessarily an argument for why "we shouldn't support it tomorrow". Before proposing dates/timelines, it'd be helpful to understand where the CA's current infrastructure and plans are, so that we can reach a happy medium. I believe this is premature by any standard. Of course CAs may and probably want to support IPv6 as soon as there is a real demand for it. It's also not overly difficult - but the real problem is the third party service providers involved including CDNs and ISPs which must provide IPv6 support first before the CA can. I fail to see how this is premature. It's exactly the same conversation that had to happen with SHA-1 - CAs weren't moving to support it, so eventually timelines had to be set. This is a classic collective action problem, and it's simply a question of what is a reasonable timeframe for CAs to move, and why. You've indicated "CDNs and ISPs must provide IPv6 support first". A number of them do. A number of them don't. The entire point of a preballot is to get a sense of what those numbers are, and for CAs that have contracts with those that do not support IPv6, how long would it take a reasonable CA to support it? You've indicated it's not overly difficult, so is it a matter of 3 months? 6 months? 10 years? That's the set of information that's useful to discuss, rather than assume it will happen. Consider "Real demand for it" being at least one browser with a non-trivial user base requesting it. But besides that I'm a bit curious why Google would have even the slightest interest in revocation checking services and how they are accessed considering that its products don't check revocation in first place :-) 1) This isn't just about revocation checking. As I noted in the preballot, it's also about authorityInfoAccess for intermediates. 2) As I explained in the preballot, this also applies to servers' ability to fetch fresh OCSP responses. I appreciate the feedback, Eddy, but your response seems mostly reactionary, without having read the proposal or justifications provided therein. It'd be helpful to know what concrete concerns you'd have and what it would take to address them. Regardless, I don't think it's a good state in the present form that, for counter-example, a CA could provide an OCSP responder or AIA caIssuers solely available over IPv6, when as you note, there's a non-trivial majority of clients with IPv4-only stacks. So consider this proposal as a way to close that ambiguity as well. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sleevi at google.com Thu Feb 5 16:42:54 2015 From: sleevi at google.com (Ryan Sleevi) Date: Thu, 5 Feb 2015 08:42:54 -0800 Subject: [cabfpub] Not coming to Switzerland in June :-( In-Reply-To: <54D38C40.90005@mozilla.org> References: <54D38C40.90005@mozilla.org> Message-ID: On Thu, Feb 5, 2015 at 7:29 AM, Gervase Markham wrote: > Dear CAB Forum members, > > Unfortunately, Mozilla has scheduled a get-together the same week as the > CAB Forum meeting in Switzerland at the end of June, so I will not be > able to make it, or to dial in, and it's unlikely that any other Mozilla > representative would be able to either. > > I don't want to have delusions of my own importance, but it has been > noted before that it's important to have browser participation in > face-to-face meetings. I also note that our friends at Google and Opera > have not been attending in person recently, with their last attendances > being: > > Opera: Meeting 30 (Sep 2013) > Google: Meeting 28 (Feb 2013) > > Hence, I thought I'd note our planned absence so that if Microsoft were > not planning to send anyone (and neither were Google or Opera), we could > at least discuss whether the CAs in the group would prefer to meet > alone, or would prefer to investigate an alternative week (by > arrangement with our gracious hosts). > > Ryan? Jody? Sigbjorn? > > Gerv Hi Gerv, Looks like you made a typo; we hosted the February 2014 F2F here in Mountain View, and, while unable to attend the Beijing F2F in September, I remotely dialed in for all of the non-WG-specific meetings (which we don't participate in anyways). It's unclear at this time with regards to the Switzerland F2F, but do you have alternate dates or times that might work better for you, so as to inform the discussion? From gerv at mozilla.org Thu Feb 5 16:46:20 2015 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 05 Feb 2015 16:46:20 +0000 Subject: [cabfpub] Not coming to Switzerland in June :-( In-Reply-To: References: <54D38C40.90005@mozilla.org> Message-ID: <54D39E5C.6030505@mozilla.org> On 05/02/15 16:42, Ryan Sleevi wrote: > Looks like you made a typo; we hosted the February 2014 F2F here in > Mountain View, Ah! I was fooled because https://www.cabforum.org/wiki/Meeting%2031 lists no Google people. > It's unclear at this time with regards to the Switzerland F2F, but do > you have alternate dates or times that might work better for you, so > as to inform the discussion? As noted on the call, both the week before and the week after could be made to work for me. Although ideally I'd not be away two weeks on the trot, so a further week either side would actually be a bit better. Gerv From Dean_Coclin at symantec.com Thu Feb 5 17:11:58 2015 From: Dean_Coclin at symantec.com (Dean Coclin) Date: Thu, 5 Feb 2015 09:11:58 -0800 Subject: [cabfpub] Code Signing Baseline Requirements - Final Draft for public exposure Message-ID: <14D026C7F297AD44AC82578DD818CDD038EEF0BA61@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> The Code Signing Working Group of the CA/Browser Forum announces the final draft of the Code Signing Baseline Requirements. This version takes into account comments received in the first round of public review as well as comments from WebTrust auditors. Additional changes/corrections were incorporated by the working group over the past 3 months. This version is being sent out to the public mailing list and will be posted on the CA/B Forum website for final comments until March 6th, 2015. Comments should be sent to: questions at cabforum.org. If there are no further comments, the group plans to propose a ballot to the CA/B Forum in mid-March to approve the Baseline Requirements. The team wishes to thank the following companies/organizations for participating in the working group: CACert Comodo Digicert Entrust ETSI Federal PKI Firmprofessional Globalsign Intarsys Izenpe Microsoft OTA Alliance Startcom Symantec SwissSign Travelport Trend Micro WebTrust WoSign >From the beginning, we have endeavored to keep the document formation process open and inclusive and we hope everyone feels that this contribution is significant to the improvement of Internet security. Dean Coclin CA/B Forum Chair -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Baseline requirements for codesigning - Feb 4 2015.doc Type: application/msword Size: 295424 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Baseline requirements for codesigning - Feb 4 2015 (3).pdf Type: application/pdf Size: 801597 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6130 bytes Desc: not available URL: From Dean_Coclin at symantec.com Thu Feb 5 17:38:57 2015 From: Dean_Coclin at symantec.com (Dean Coclin) Date: Thu, 5 Feb 2015 09:38:57 -0800 Subject: [cabfpub] Not coming to Switzerland in June :-( In-Reply-To: <54D39E5C.6030505@mozilla.org> References: <54D38C40.90005@mozilla.org> <54D39E5C.6030505@mozilla.org> Message-ID: <14D026C7F297AD44AC82578DD818CDD038EEF0BA8C@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> Clearly that list is incorrect (especially since Google hosted the meeting but probably felt they didn't need to sign up for their own venue). But luckily they are present in the Minutes. OK, Kirk and I will discuss this along with the host and put out some suggestions. Dean -----Original Message----- From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Gervase Markham Sent: Thursday, February 05, 2015 11:46 AM To: Ryan Sleevi Cc: CABFPub Subject: Re: [cabfpub] Not coming to Switzerland in June :-( On 05/02/15 16:42, Ryan Sleevi wrote: > Looks like you made a typo; we hosted the February 2014 F2F here in > Mountain View, Ah! I was fooled because https://www.cabforum.org/wiki/Meeting%2031 lists no Google people. > It's unclear at this time with regards to the Switzerland F2F, but do > you have alternate dates or times that might work better for you, so > as to inform the discussion? As noted on the call, both the week before and the week after could be made to work for me. Although ideally I'd not be away two weeks on the trot, so a further week either side would actually be a bit better. Gerv _______________________________________________ Public mailing list Public at cabforum.org https://cabforum.org/mailman/listinfo/public -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6130 bytes Desc: not available URL: From i-barreira at izenpe.net Thu Feb 5 17:44:16 2015 From: i-barreira at izenpe.net (i-barreira at izenpe.net) Date: Thu, 05 Feb 2015 18:44:16 +0100 Subject: [cabfpub] Not coming to Switzerland in June :-( In-Reply-To: A <14D026C7F297AD44AC82578DD818CDD038EEF0BA8C@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> References: <54D38C40.90005@mozilla.org> <54D39E5C.6030505@mozilla.org> A <14D026C7F297AD44AC82578DD818CDD038EEF0BA8C@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> Message-ID: <763539E260C37C46A0D6B340B5434C3B0ACD7C48@AEX06.ejsarea.net> We haven?t heard of the other browsers yet. We can check if we have had some F2F meetings without browsers. Don?t see a major impact since they can dialing in as Ryan did last time, or read the minutes at the end I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. -----Mensaje original----- De: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] En nombre de Dean Coclin Enviado el: jueves, 05 de febrero de 2015 18:39 Para: Gervase Markham; Ryan Sleevi CC: CABFPub Asunto: Re: [cabfpub] Not coming to Switzerland in June :-( Clearly that list is incorrect (especially since Google hosted the meeting but probably felt they didn't need to sign up for their own venue). But luckily they are present in the Minutes. OK, Kirk and I will discuss this along with the host and put out some suggestions. Dean -----Original Message----- From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Gervase Markham Sent: Thursday, February 05, 2015 11:46 AM To: Ryan Sleevi Cc: CABFPub Subject: Re: [cabfpub] Not coming to Switzerland in June :-( On 05/02/15 16:42, Ryan Sleevi wrote: > Looks like you made a typo; we hosted the February 2014 F2F here in > Mountain View, Ah! I was fooled because https://www.cabforum.org/wiki/Meeting%2031 lists no Google people. > It's unclear at this time with regards to the Switzerland F2F, but do > you have alternate dates or times that might work better for you, so > as to inform the discussion? As noted on the call, both the week before and the week after could be made to work for me. Although ideally I'd not be away two weeks on the trot, so a further week either side would actually be a bit better. Gerv _______________________________________________ Public mailing list Public at cabforum.org https://cabforum.org/mailman/listinfo/public From eddy_nigg at startcom.org Thu Feb 5 17:44:49 2015 From: eddy_nigg at startcom.org (Eddy Nigg) Date: Thu, 05 Feb 2015 19:44:49 +0200 Subject: [cabfpub] Ballot .onion ballot In-Reply-To: <54D37D9F.1070907@mozilla.org> References: <445290cba41444119f8c958eebbcc76a@EX2.corp.digicert.com> <54D3404D.90808@opentrust.com> <54D3451F.4090201@mozilla.org> <54D37AA7.8040101@opentrust.com> <54D37D9F.1070907@mozilla.org> Message-ID: <54D3AC11.6050607@startcom.org> On 02/05/2015 04:26 PM, Gervase Markham wrote: > I'm not the person who argued for a restriction on *.facebook.com EV I too might be wrong on this, but according to my memory I recall that you were the person arguing against it when we discussed it last time when we created the BR. :-) IIRC Wayne from Godaddy argued (correctly) that if wild cards should be restricted it would make most sense to have it supported by EV since it's the strongest verification standard currently. EV allows to include domain names of third parties (in my opinion incorrectly), so adding wild cards doesn't change that in any way really. We would be in favor for such a move and believe that wild cards have nothing lost in the non-verified (e.g. DV) settings due to their potential abuse. If at all, wild cards should be permitted with EV and prohibited for DV (if you want anything else than EV). -- Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. XMPP: startcom at startcom.org Blog: Join the Revolution! Twitter: Follow Me -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4313 bytes Desc: S/MIME Cryptographic Signature URL: From sleevi at google.com Thu Feb 5 18:10:33 2015 From: sleevi at google.com (Ryan Sleevi) Date: Thu, 5 Feb 2015 10:10:33 -0800 Subject: [cabfpub] Ballot .onion ballot In-Reply-To: <54D3AC11.6050607@startcom.org> References: <445290cba41444119f8c958eebbcc76a@EX2.corp.digicert.com> <54D3404D.90808@opentrust.com> <54D3451F.4090201@mozilla.org> <54D37AA7.8040101@opentrust.com> <54D37D9F.1070907@mozilla.org> <54D3AC11.6050607@startcom.org> Message-ID: On Thu, Feb 5, 2015 at 9:44 AM, Eddy Nigg wrote: > > On 02/05/2015 04:26 PM, Gervase Markham wrote: > > I'm not the person who argued for a restriction on *.facebook.com EV > > > I too might be wrong on this, but according to my memory I recall that you > were the person arguing against it when we discussed it last time when we > created the BR. :-) > > IIRC Wayne from Godaddy argued (correctly) that if wild cards should be > restricted it would make most sense to have it supported by EV since it's > the strongest verification standard currently. EV allows to include domain > names of third parties (in my opinion incorrectly), so adding wild cards > doesn't change that in any way really. > > We would be in favor for such a move and believe that wild cards have > nothing lost in the non-verified (e.g. DV) settings due to their potential > abuse. If at all, wild cards should be permitted with EV and prohibited for > DV (if you want anything else than EV). > At the risk of derailing the conversation, we'd be opposed to such a proposal (and have said so in the past) To the topic at hand - as it relates specifically to .onion names: The case for wildcards: - The use of origins (RFC 6454 for those unfamiliar with the core concept of web security) provides an effective means to separate privileges and reduce the risks of compromise (in the web sense; this means issues such as XSS) and the privileges granted - The use of separable origins can be beneficial-to-critical to high performance web pages (... unless/until the site is using HTTP/2), due to items such as connection pooling, request prioritization, etc The case against wildcards: - The primary argument against wildcards (for EV) is derived from Section 11.12.1 of EVG 1.5.2. EVG 1.5.2 requires all names be treated as High Risk (as defined in the BRs 1.2.3), which requires that the CA perform some degree of secondary checks (such as names listed on Miller Smiles or Safe Browsing). A wildcard cert allows an entity to request a potentially confusing name (bankofamericacom.facebook.com) that may phish the user. - The secondary argument against wildcards is derived from Section 11.7.1 p2 of EVG 1.5.2, the prohibition against mixed script. A wildcard allows a certificate holder to find any valid construction of IDNA/script at that subordinate domain that may exploit some confusible. Now, I don't feel that the case against is at all strong or relevant. It's long been public record that we don't view certificates as an effective means against phishing, for a wide variety of reasons, and so phishing-level arguments are, to us, particularly specious. The argument against mixed script is also questionable, in as much as it's possible with DV, and it's an issue that browsers (and their rules regarding presentation of punycode vs native scripts) are already handling. For !browser clients, it might be relevant, but I would argue that the EVGs are not exactly relevant to the !browser case. To the broader question about whether wildcards should be prevented or allowed in the EVGs, I suspect this will be the same tension and misaligned interests as the insurance discussion. CAs may perceive one set of value propositions, browsers another. The lack of wildcard support allows for greater price controls, which on a purely business level is a boon, but on a practical security level, would be unfortunate if CAs place profit over security. However, if this does represent some set of concern for CAs (although I would argue unwarranted, for the reasons explained above), then I suspect it can be removed. It just means anyone wanting to use hidden services for accessibility (e.g. as Facebook is doing) will need to invest sizably more, or work out an appropriate cost structure with the CA that allows for bulk purchase, neither of which do much to change the security landscape any. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jodycl at microsoft.com Mon Feb 9 17:54:31 2015 From: jodycl at microsoft.com (Jody Cloutier) Date: Mon, 9 Feb 2015 17:54:31 +0000 Subject: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Message-ID: Microsoft comments on Section 17. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Baseline requirements for codesigning - Feb 4 2015.doc Type: application/msword Size: 310272 bytes Desc: Baseline requirements for codesigning - Feb 4 2015.doc URL: From benedikt at cacert.org Mon Feb 9 23:05:11 2015 From: benedikt at cacert.org (Benedikt Heintel) Date: Tue, 10 Feb 2015 00:05:11 +0100 Subject: [cabfpub] Audit over CA/B BR and WebTrust needed? Message-ID: <54D93D27.6020807@cacert.org> Dear group, Planning the next steps forward, getting our root certificates in the trust stores, we wonder what are the minimum requirements certification wise. Do we need CA/B Baseline Requirements and WebTrust Certification? Is it necessary to go for CA/B BR and ETSI TS 102 042? Is CA/B BR enough? Best Regards Benedikt -- Benedikt Heintel - benedikt at cacert.org CAcert Assurer for People & Organizations CAcert internal Auditor CAcert.org - Secure Together http://www.cacert.org -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3870 bytes Desc: S/MIME Cryptographic Signature URL: From sleevi at google.com Mon Feb 9 23:11:07 2015 From: sleevi at google.com (Ryan Sleevi) Date: Mon, 9 Feb 2015 15:11:07 -0800 Subject: [cabfpub] Audit over CA/B BR and WebTrust needed? In-Reply-To: <54D93D27.6020807@cacert.org> References: <54D93D27.6020807@cacert.org> Message-ID: On Feb 9, 2015 3:05 PM, "Benedikt Heintel" wrote: > > Dear group, > > Planning the next steps forward, getting our root certificates in the > trust stores, we wonder what are the minimum requirements certification > wise. > > Do we need CA/B Baseline Requirements and WebTrust Certification? > Is it necessary to go for CA/B BR and ETSI TS 102 042? Is CA/B BR enough? > > Best Regards > Benedikt > -- > Benedikt Heintel - benedikt at cacert.org > CAcert Assurer for People & Organizations > CAcert internal Auditor > > CAcert.org - Secure Together > http://www.cacert.org > > > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public > That's nominally a question for each root to answer as to what their individual acceptance policies are. To be enabled for the SSL trust bits in Mozilla, for example, you must complete an appropriate audit scheme that incorporates the CA/B Forum Baseline Requirements, as well as comply with the Mozilla Root Inclusion policy. The acceptable audit schemes are listed in https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ For WebTrust, this means Principles and Criteria for CAs 2.0 _and_ SSL BR audit 1.1. -------------- next part -------------- An HTML attachment was scrubbed... URL: From i-barreira at izenpe.net Tue Feb 10 09:17:33 2015 From: i-barreira at izenpe.net (i-barreira at izenpe.net) Date: Tue, 10 Feb 2015 10:17:33 +0100 Subject: [cabfpub] Audit over CA/B BR and WebTrust needed? In-Reply-To: References: <54D93D27.6020807@cacert.org> Message-ID: <763539E260C37C46A0D6B340B5434C3B0ACD8128@AEX06.ejsarea.net> If you have access to the wiki there you can find the different requirements of the browsers plus the information from ETSI and Webtrust. I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. De: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] En nombre de Ryan Sleevi Enviado el: martes, 10 de febrero de 2015 0:11 Para: Benedikt Heintel CC: CABFPub Asunto: Re: [cabfpub] Audit over CA/B BR and WebTrust needed? On Feb 9, 2015 3:05 PM, "Benedikt Heintel" wrote: > > Dear group, > > Planning the next steps forward, getting our root certificates in the > trust stores, we wonder what are the minimum requirements certification > wise. > > Do we need CA/B Baseline Requirements and WebTrust Certification? > Is it necessary to go for CA/B BR and ETSI TS 102 042? Is CA/B BR enough? > > Best Regards > Benedikt > -- > Benedikt Heintel - benedikt at cacert.org > CAcert Assurer for People & Organizations > CAcert internal Auditor > > CAcert.org - Secure Together > http://www.cacert.org > > > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public > That's nominally a question for each root to answer as to what their individual acceptance policies are. To be enabled for the SSL trust bits in Mozilla, for example, you must complete an appropriate audit scheme that incorporates the CA/B Forum Baseline Requirements, as well as comply with the Mozilla Root Inclusion policy. The acceptable audit schemes are listed in https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ For WebTrust, this means Principles and Criteria for CAs 2.0 _and_ SSL BR audit 1.1. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 19121 bytes Desc: image001.png URL: From i-barreira at izenpe.net Tue Feb 10 11:09:24 2015 From: i-barreira at izenpe.net (i-barreira at izenpe.net) Date: Tue, 10 Feb 2015 12:09:24 +0100 Subject: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Message-ID: <763539E260C37C46A0D6B340B5434C3B0ACD81A9@AEX06.ejsarea.net> Hi Jody, Regarding your comment on ETSI audits, I have to say that the ETSI audits shall be performed by accredited auditors as mentioned in Annex E of the current ETSI TS 102 042. ETSI audits performed by not accredited auditors shall be considered invalid. Microsoft is accepting ETSI audits since the very beginning in its root program requirements indicating this requirement. ETSI is providing a list of accredited auditors as mere information because has to be maintained by every NAB (National Accreditation Body). It?s true that this has to be improved regarding the new regulation 910/2014 and the new ENs and will take some time, but at the moment, it?s clearly stated that the audits shall be performed by accredited auditors. Don?t hesitate in contacting me for any additional information or help. Sometimes I?ve received some emails from Tom or Kelvin asking for the qualification of some audits, so, as say, you can contact me regarding this issue. Regards I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. De: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] En nombre de Jody Cloutier Enviado el: lunes, 09 de febrero de 2015 18:55 Para: CABFPub (public at cabforum.org) Asunto: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Microsoft comments on Section 17. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 19121 bytes Desc: image001.png URL: From ben.wilson at digicert.com Tue Feb 10 14:20:29 2015 From: ben.wilson at digicert.com (Ben Wilson) Date: Tue, 10 Feb 2015 14:20:29 +0000 Subject: [cabfpub] Audit over CA/B BR and WebTrust needed? In-Reply-To: <763539E260C37C46A0D6B340B5434C3B0ACD8128@AEX06.ejsarea.net> References: <54D93D27.6020807@cacert.org> <763539E260C37C46A0D6B340B5434C3B0ACD8128@AEX06.ejsarea.net> Message-ID: <5e42a240cc6d404ba88cda81558d7f4e@EX2.corp.digicert.com> I tried to port that all over from the wiki to the public web site. You can find information here - https://cabforum.org/browser-os-info/ and here - https://cabforum.org/audit-criteria/. Going forward, if our website isn?t clear, then we need update the information so that it is. Any member representative interested in improving our web pages should contact me. Thanks, Ben From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of i-barreira at izenpe.net Sent: Tuesday, February 10, 2015 2:18 AM To: sleevi at google.com; benedikt at cacert.org Cc: public at cabforum.org Subject: Re: [cabfpub] Audit over CA/B BR and WebTrust needed? If you have access to the wiki there you can find the different requirements of the browsers plus the information from ETSI and Webtrust. I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. De: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] En nombre de Ryan Sleevi Enviado el: martes, 10 de febrero de 2015 0:11 Para: Benedikt Heintel CC: CABFPub Asunto: Re: [cabfpub] Audit over CA/B BR and WebTrust needed? On Feb 9, 2015 3:05 PM, "Benedikt Heintel" > wrote: > > Dear group, > > Planning the next steps forward, getting our root certificates in the > trust stores, we wonder what are the minimum requirements certification > wise. > > Do we need CA/B Baseline Requirements and WebTrust Certification? > Is it necessary to go for CA/B BR and ETSI TS 102 042? Is CA/B BR enough? > > Best Regards > Benedikt > -- > Benedikt Heintel - benedikt at cacert.org > CAcert Assurer for People & Organizations > CAcert internal Auditor > > CAcert.org - Secure Together > http://www.cacert.org > > > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public > That's nominally a question for each root to answer as to what their individual acceptance policies are. To be enabled for the SSL trust bits in Mozilla, for example, you must complete an appropriate audit scheme that incorporates the CA/B Forum Baseline Requirements, as well as comply with the Mozilla Root Inclusion policy. The acceptable audit schemes are listed in https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ For WebTrust, this means Principles and Criteria for CAs 2.0 _and_ SSL BR audit 1.1. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 19121 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4954 bytes Desc: not available URL: From jeremy.rowley at digicert.com Tue Feb 10 18:38:52 2015 From: jeremy.rowley at digicert.com (Jeremy Rowley) Date: Tue, 10 Feb 2015 18:38:52 +0000 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names Message-ID: Here's the ballot with the two typos fixed: Applicants want a CA-signed .onion address for several reasons, including: - Powerful web platform features are restricted to secure origins, which are currently not available to onion names (in part, because of the lack of IANA registration). Permitting EV certs for onion names will help provide a secure origin for the service, moving onion towards use of powerful web platform features. - Currently, access to .onion names over https from a standard browser results in the standard existing 'Invalid Certificate' warning. Training users to click through security warnings lowers the value of these warnings and will cause users to miss important security information. Removing these warnings for the user, through use of a digital certificate, will help users recognize and avoid real MITM attacks. - The public needs attribution of ownership of the .onion address to differentiate onion services, including potential phishing services. Because onion names are not easily recognizable strings, providing the public with additional information about the operator has significant security improvements, especially in regions where use of the incorrect name could have lethal consequences. The following motion has been proposed by Jeremy Rowley of DigiCert and endorsed by Ryan Sleevi of Google and Wayne Thayer of GoDaddy. --------------------- Motion Starts --------------------- 1) Amend Section 9.2.1 of the Baseline Requirements v. 1.2.3 as follows: 9.2.1 Subject Alternative Name Extension Certificate Field: extensions:subjectAltName Required/Optional: Required Contents: This 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. The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate. Wildcard FQDNs are permitted. As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name, the CA SHALL notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016. Also as of the Effective Date, the CA SHALL NOT issue a certificate with an Expiry Date later than 1 November 2015 with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name. Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Name. Effective May 1, 2015, each CA SHALL revoke all unexpired Certificates with an Internal Name using onion as the right-most label in an entry in the subjectAltName Extension or commonName field unless such Certificate was issued in accordance with Appendix F of the EV Guidelines. 2) Amend Section 9.2.2 and 11.7.1 of the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2 as follows: 9.2.2. Subject Alternative Name Extension Certificate field: subjectAltName:dNSName Required/Optional: Required Contents: This extension MUST contain one or more host Domain Name(s) owned or controlled by the Subject and to be associated with the Subject's server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). Wildcard certificates are not allowed for EV Certificates except as permitted under Appendix F. 11.7 Verification of Applicant's Domain Name 11.7.1. Verification Requirements (1) For each Fully-Qualified Domain Name listed in a Certificate, other than a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant (or the Applicant's Parent Company, Subsidiary Company, or Affiliate, collectively referred to as "Applicant" for the purposes of this section) either is the Domain Name Registrant or has control over the FQDN using a procedure specified in Section 11.1.1 of the Baseline Requirements, except that a CA MAY NOT verify a domain using the procedure described 11.1.1(7). For a Certificate issued to a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant's control over the .onion Domain Name in accordance with Appendix F. (2) Mixed Character Set Domain Names: EV Certificates MAY include Domain Names containing mixed character sets only in compliance with the rules set forth by the domain registrar. The CA MUST visually compare any Domain Names with mixed character sets with known high risk domains. If a similarity is found, then the EV Certificate Request MUST be flagged as High Risk. The CA must perform reasonably appropriate additional authentication and verification to be certain beyond reasonable doubt that the Applicant and the target in question are the same organization. 3) Add a new Appendix F to the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2: Appendix F - Issuance of Certificates for .onion Domain Names A CA may issue an EV Certificate with .onion in the right-most label of the Domain Name provided that issuance complies with the requirements set forth in this Appendix: 1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) The CAB Forum has created an extension of the TBSCertificate for use in conveying hashes of keys related to .onion addresses. The Tor Service Descriptor Hash extension has the following format: cabf-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 } TorServiceDescriptorSyntax ::= SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash TorServiceDescriptorHash:: = SEQUENCE { onionURI UTF8String algorithm AlgorithmIdentifier subjectPublicKeyHash BIT STRING } Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 6234) performed over the DER-encoding of an ASN.1 SubjectPublicKey of the .onion service and SubjectPublicKeyHash is the hash output. 2. The CA MUST verify the Applicant's control over the .onion Domain Name using one of the following: a. The CA MAY verify the Applicant's control over the .onion service by posting a specific value at a well-known URL under RFC5785. b. The CA MAY verify the Applicant's control over the .onion service by having the Applicant provide a Certificate Request signed using the .onion public key if the Attributes section of the certificationRequestInfo contains: (i) A caSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy, 2) is generated by the CA, and 3) delivered to the Applicant through a Verified Method of Communication and (ii) An applicantSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy and 2) is generated by the Applicant. The signing nonce attributes have the following format: caSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-caSigningNonce } } cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } applicantSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-applicantSigningNonce } } cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 } 4. Each Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name MUST conform to the requirements of these Guidelines, including the content requirements in Section 9 and Appendix B of the Baseline Requirements, except that the CA MAY include a wildcard character in the Subject Alternative Name Extension and Subject Common Name Field as the left-most character in the .onion Domain Name provided inclusion of the wildcard character complies with Section 11.1.3 of the Baseline Requirements. 5. CAs MUST NOT issue a Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name with a validity period longer than 15 months. Despite Section 9.2.1 of the Baseline Requirements deprecating the use of Internal Names, a CA MAY issue a Certificate containing an .onion name with an expiration date later than 1 November 2015 after (and only if) .onion is officially recognized by the IESG as a reserved TLD. 6. On or before May 1, 2015, each CA MUST revoke all Certificates issued with the Subject Alternative Name extension or Common Name field that includes a Domain Name where .onion is in the right-most label of the Domain Name unless the Certificate was issued in compliance with this Appendix F. ---- Motion Ends ----- The review period for this ballot shall commence at 2200 UTC on Thursday, 4 February 2015, and will close at 2200 UTC on Thursday, 11 February 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on Monday, 18 February 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.wilson at digicert.com Tue Feb 10 21:02:17 2015 From: ben.wilson at digicert.com (Ben Wilson) Date: Tue, 10 Feb 2015 21:02:17 +0000 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names In-Reply-To: References: Message-ID: <5c04557077cf4564979bc37e501297de@EX2.corp.digicert.com> I'll post this to the public page with a correction stating that the review period ends and the voting period of the ballot begins to run from Wednesday, 11 Feb., to Wednesday, 18 Feb. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Tuesday, February 10, 2015 11:39 AM To: public at cabforum.org Subject: [cabfpub] Ballot 144 - Validation rules for .onion names Here's the ballot with the two typos fixed: Applicants want a CA-signed .onion address for several reasons, including: - Powerful web platform features are restricted to secure origins, which are currently not available to onion names (in part, because of the lack of IANA registration). Permitting EV certs for onion names will help provide a secure origin for the service, moving onion towards use of powerful web platform features. - Currently, access to .onion names over https from a standard browser results in the standard existing 'Invalid Certificate' warning. Training users to click through security warnings lowers the value of these warnings and will cause users to miss important security information. Removing these warnings for the user, through use of a digital certificate, will help users recognize and avoid real MITM attacks. - The public needs attribution of ownership of the .onion address to differentiate onion services, including potential phishing services. Because onion names are not easily recognizable strings, providing the public with additional information about the operator has significant security improvements, especially in regions where use of the incorrect name could have lethal consequences. The following motion has been proposed by Jeremy Rowley of DigiCert and endorsed by Ryan Sleevi of Google and Wayne Thayer of GoDaddy. --------------------- Motion Starts --------------------- 1) Amend Section 9.2.1 of the Baseline Requirements v. 1.2.3 as follows: 9.2.1 Subject Alternative Name Extension Certificate Field: extensions:subjectAltName Required/Optional: Required Contents: This 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. The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate. Wildcard FQDNs are permitted. As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name, the CA SHALL notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016. Also as of the Effective Date, the CA SHALL NOT issue a certificate with an Expiry Date later than 1 November 2015 with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name. Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Name. Effective May 1, 2015, each CA SHALL revoke all unexpired Certificates with an Internal Name using onion as the right-most label in an entry in the subjectAltName Extension or commonName field unless such Certificate was issued in accordance with Appendix F of the EV Guidelines. 2) Amend Section 9.2.2 and 11.7.1 of the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2 as follows: 9.2.2. Subject Alternative Name Extension Certificate field: subjectAltName:dNSName Required/Optional: Required Contents: This extension MUST contain one or more host Domain Name(s) owned or controlled by the Subject and to be associated with the Subject's server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). Wildcard certificates are not allowed for EV Certificates except as permitted under Appendix F. 11.7 Verification of Applicant's Domain Name 11.7.1. Verification Requirements (1) For each Fully-Qualified Domain Name listed in a Certificate, other than a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant (or the Applicant's Parent Company, Subsidiary Company, or Affiliate, collectively referred to as "Applicant" for the purposes of this section) either is the Domain Name Registrant or has control over the FQDN using a procedure specified in Section 11.1.1 of the Baseline Requirements, except that a CA MAY NOT verify a domain using the procedure described 11.1.1(7). For a Certificate issued to a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant's control over the .onion Domain Name in accordance with Appendix F. (2) Mixed Character Set Domain Names: EV Certificates MAY include Domain Names containing mixed character sets only in compliance with the rules set forth by the domain registrar. The CA MUST visually compare any Domain Names with mixed character sets with known high risk domains. If a similarity is found, then the EV Certificate Request MUST be flagged as High Risk. The CA must perform reasonably appropriate additional authentication and verification to be certain beyond reasonable doubt that the Applicant and the target in question are the same organization. 3) Add a new Appendix F to the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2: Appendix F - Issuance of Certificates for .onion Domain Names A CA may issue an EV Certificate with .onion in the right-most label of the Domain Name provided that issuance complies with the requirements set forth in this Appendix: 1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) The CAB Forum has created an extension of the TBSCertificate for use in conveying hashes of keys related to .onion addresses. The Tor Service Descriptor Hash extension has the following format: cabf-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 } TorServiceDescriptorSyntax ::= SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash TorServiceDescriptorHash:: = SEQUENCE { onionURI UTF8String algorithm AlgorithmIdentifier subjectPublicKeyHash BIT STRING } Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 6234) performed over the DER-encoding of an ASN.1 SubjectPublicKey of the .onion service and SubjectPublicKeyHash is the hash output. 2. The CA MUST verify the Applicant's control over the .onion Domain Name using one of the following: a. The CA MAY verify the Applicant's control over the .onion service by posting a specific value at a well-known URL under RFC5785. b. The CA MAY verify the Applicant's control over the .onion service by having the Applicant provide a Certificate Request signed using the .onion public key if the Attributes section of the certificationRequestInfo contains: (i) A caSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy, 2) is generated by the CA, and 3) delivered to the Applicant through a Verified Method of Communication and (ii) An applicantSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy and 2) is generated by the Applicant. The signing nonce attributes have the following format: caSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-caSigningNonce } } cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } applicantSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-applicantSigningNonce } } cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 } 4. Each Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name MUST conform to the requirements of these Guidelines, including the content requirements in Section 9 and Appendix B of the Baseline Requirements, except that the CA MAY include a wildcard character in the Subject Alternative Name Extension and Subject Common Name Field as the left-most character in the .onion Domain Name provided inclusion of the wildcard character complies with Section 11.1.3 of the Baseline Requirements. 5. CAs MUST NOT issue a Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name with a validity period longer than 15 months. Despite Section 9.2.1 of the Baseline Requirements deprecating the use of Internal Names, a CA MAY issue a Certificate containing an .onion name with an expiration date later than 1 November 2015 after (and only if) .onion is officially recognized by the IESG as a reserved TLD. 6. On or before May 1, 2015, each CA MUST revoke all Certificates issued with the Subject Alternative Name extension or Common Name field that includes a Domain Name where .onion is in the right-most label of the Domain Name unless the Certificate was issued in compliance with this Appendix F. ---- Motion Ends ----- The review period for this ballot shall commence at 2200 UTC on Thursday, 4 February 2015, and will close at 2200 UTC on Thursday, 11 February 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on Monday, 18 February 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4954 bytes Desc: not available URL: From jodycl at microsoft.com Tue Feb 10 23:32:19 2015 From: jodycl at microsoft.com (Jody Cloutier) Date: Tue, 10 Feb 2015 23:32:19 +0000 Subject: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc In-Reply-To: <763539E260C37C46A0D6B340B5434C3B0ACD81A9@AEX06.ejsarea.net> References: <763539E260C37C46A0D6B340B5434C3B0ACD81A9@AEX06.ejsarea.net> Message-ID: Thank you, Inigo. I think the problem is that, under ETSI, it's difficult to discern what an "equivalent national scheme" is. This sets up the scenario in which an auditor is employed by an organization that is recognized somehow by the government, but is not affiliated with an ETSI member organization (http://www.european-accreditation.org/home ). Microsoft does not know whether or not this auditor is qualified or not. For example, ? Company A is a commercial CA that operates in Israel ? Auditor Jones works for AuditCo, which is based in Israel ? AuditCo is certified by some governmental agency as a qualified auditor ? AuditCo is not an ETSI Member or Associate Member ? Auditor Jones audits Company A using the ETSI 102042 standard, and Company A sends the auditor's attestation letter to Microsoft as evidence that Company A complied with the Program's requirements. In this scenario, how does Microsoft know that Auditor Jones conducted a proper audit without expending significant resources to determine whether and according to what standard AuditCo and Auditor Jones was certified? Microsoft believes that it would be simpler if the requirements were that the Auditor must work for a company that is affiliated with an ETSI-approved member organization. If Company A needs an auditor and there is no qualified auditor in Israel, the company can use an auditor from a member organization via the cross-border conformity rules. Unless I am fundamentally misunderstanding the rules, the above is something that Microsoft is presently struggling with, and we'd like to try to make the rules easier to understand for potential partners and ourselves. Jody Cloutier Senior Security Program Manager Microsoft Trusted Root Certificate Program jody.cloutier at microsoft.com 425.443.8922 Operating Systems Group Global Risk and Compliance [https://brandtools.microsoft.com/Style%20Library/BT/Images/MicrosoftMasterLogo.png] From: i-barreira at izenpe.net [mailto:i-barreira at izenpe.net] Sent: Tuesday, February 10, 2015 3:09 AM To: Jody Cloutier; public at cabforum.org Subject: RE: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Hi Jody, Regarding your comment on ETSI audits, I have to say that the ETSI audits shall be performed by accredited auditors as mentioned in Annex E of the current ETSI TS 102 042. ETSI audits performed by not accredited auditors shall be considered invalid. Microsoft is accepting ETSI audits since the very beginning in its root program requirements indicating this requirement. ETSI is providing a list of accredited auditors as mere information because has to be maintained by every NAB (National Accreditation Body). It?s true that this has to be improved regarding the new regulation 910/2014 and the new ENs and will take some time, but at the moment, it?s clearly stated that the audits shall be performed by accredited auditors. Don?t hesitate in contacting me for any additional information or help. Sometimes I?ve received some emails from Tom or Kelvin asking for the qualification of some audits, so, as say, you can contact me regarding this issue. Regards I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 [Descripci?n: cid:image001.png at 01CE3152.B4804EB0] ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. De: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] En nombre de Jody Cloutier Enviado el: lunes, 09 de febrero de 2015 18:55 Para: CABFPub (public at cabforum.org) Asunto: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Microsoft comments on Section 17. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 19121 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 1181 bytes Desc: image002.png URL: From haavardm at opera.com Wed Feb 11 14:32:07 2015 From: haavardm at opera.com (haavardm at work) Date: Wed, 11 Feb 2015 15:32:07 +0100 Subject: [cabfpub] Not coming to Switzerland in June :-( In-Reply-To: <54D38C40.90005@mozilla.org> References: <54D38C40.90005@mozilla.org> Message-ID: Hi Gerv, Depending on a few internal factors, we are considering sending one representative to the Switzerland meeting. If so, either me or Sigbj?rn will attend. Cheers, H?vard On Thu, Feb 5, 2015 at 4:29 PM, Gervase Markham wrote: > Dear CAB Forum members, > > Unfortunately, Mozilla has scheduled a get-together the same week as the > CAB Forum meeting in Switzerland at the end of June, so I will not be > able to make it, or to dial in, and it's unlikely that any other Mozilla > representative would be able to either. > > I don't want to have delusions of my own importance, but it has been > noted before that it's important to have browser participation in > face-to-face meetings. I also note that our friends at Google and Opera > have not been attending in person recently, with their last attendances > being: > > Opera: Meeting 30 (Sep 2013) > Google: Meeting 28 (Feb 2013) > > Hence, I thought I'd note our planned absence so that if Microsoft were > not planning to send anyone (and neither were Google or Opera), we could > at least discuss whether the CAs in the group would prefer to meet > alone, or would prefer to investigate an alternative week (by > arrangement with our gracious hosts). > > Ryan? Jody? Sigbjorn? > > Gerv > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.wilson at digicert.com Wed Feb 11 21:21:37 2015 From: ben.wilson at digicert.com (Ben Wilson) Date: Wed, 11 Feb 2015 21:21:37 +0000 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names In-Reply-To: <5c04557077cf4564979bc37e501297de@EX2.corp.digicert.com> References: <5c04557077cf4564979bc37e501297de@EX2.corp.digicert.com> Message-ID: <3ff9a59417eb41ff98aed77794f075e2@EX2.corp.digicert.com> I've posted the ballot here - https://cabforum.org/2015/02/11/ballot-144-validation-rules-dot-onion-names/ Voting begins in 40 minutes and lasts for 7 days. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ben Wilson Sent: Tuesday, February 10, 2015 2:02 PM To: public at cabforum.org Subject: Re: [cabfpub] Ballot 144 - Validation rules for .onion names I'll post this to the public page with a correction stating that the review period ends and the voting period of the ballot begins to run from Wednesday, 11 Feb., to Wednesday, 18 Feb. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Tuesday, February 10, 2015 11:39 AM To: public at cabforum.org Subject: [cabfpub] Ballot 144 - Validation rules for .onion names Here's the ballot with the two typos fixed: Applicants want a CA-signed .onion address for several reasons, including: - Powerful web platform features are restricted to secure origins, which are currently not available to onion names (in part, because of the lack of IANA registration). Permitting EV certs for onion names will help provide a secure origin for the service, moving onion towards use of powerful web platform features. - Currently, access to .onion names over https from a standard browser results in the standard existing 'Invalid Certificate' warning. Training users to click through security warnings lowers the value of these warnings and will cause users to miss important security information. Removing these warnings for the user, through use of a digital certificate, will help users recognize and avoid real MITM attacks. - The public needs attribution of ownership of the .onion address to differentiate onion services, including potential phishing services. Because onion names are not easily recognizable strings, providing the public with additional information about the operator has significant security improvements, especially in regions where use of the incorrect name could have lethal consequences. The following motion has been proposed by Jeremy Rowley of DigiCert and endorsed by Ryan Sleevi of Google and Wayne Thayer of GoDaddy. --------------------- Motion Starts --------------------- 1) Amend Section 9.2.1 of the Baseline Requirements v. 1.2.3 as follows: 9.2.1 Subject Alternative Name Extension Certificate Field: extensions:subjectAltName Required/Optional: Required Contents: This 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. The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate. Wildcard FQDNs are permitted. As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name, the CA SHALL notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016. Also as of the Effective Date, the CA SHALL NOT issue a certificate with an Expiry Date later than 1 November 2015 with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name. Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Name. Effective May 1, 2015, each CA SHALL revoke all unexpired Certificates with an Internal Name using onion as the right-most label in an entry in the subjectAltName Extension or commonName field unless such Certificate was issued in accordance with Appendix F of the EV Guidelines. 2) Amend Section 9.2.2 and 11.7.1 of the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2 as follows: 9.2.2. Subject Alternative Name Extension Certificate field: subjectAltName:dNSName Required/Optional: Required Contents: This extension MUST contain one or more host Domain Name(s) owned or controlled by the Subject and to be associated with the Subject's server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). Wildcard certificates are not allowed for EV Certificates except as permitted under Appendix F. 11.7 Verification of Applicant's Domain Name 11.7.1. Verification Requirements (1) For each Fully-Qualified Domain Name listed in a Certificate, other than a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant (or the Applicant's Parent Company, Subsidiary Company, or Affiliate, collectively referred to as "Applicant" for the purposes of this section) either is the Domain Name Registrant or has control over the FQDN using a procedure specified in Section 11.1.1 of the Baseline Requirements, except that a CA MAY NOT verify a domain using the procedure described 11.1.1(7). For a Certificate issued to a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant's control over the .onion Domain Name in accordance with Appendix F. (2) Mixed Character Set Domain Names: EV Certificates MAY include Domain Names containing mixed character sets only in compliance with the rules set forth by the domain registrar. The CA MUST visually compare any Domain Names with mixed character sets with known high risk domains. If a similarity is found, then the EV Certificate Request MUST be flagged as High Risk. The CA must perform reasonably appropriate additional authentication and verification to be certain beyond reasonable doubt that the Applicant and the target in question are the same organization. 3) Add a new Appendix F to the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2: Appendix F - Issuance of Certificates for .onion Domain Names A CA may issue an EV Certificate with .onion in the right-most label of the Domain Name provided that issuance complies with the requirements set forth in this Appendix: 1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) The CAB Forum has created an extension of the TBSCertificate for use in conveying hashes of keys related to .onion addresses. The Tor Service Descriptor Hash extension has the following format: cabf-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 } TorServiceDescriptorSyntax ::= SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash TorServiceDescriptorHash:: = SEQUENCE { onionURI UTF8String algorithm AlgorithmIdentifier subjectPublicKeyHash BIT STRING } Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 6234) performed over the DER-encoding of an ASN.1 SubjectPublicKey of the .onion service and SubjectPublicKeyHash is the hash output. 2. The CA MUST verify the Applicant's control over the .onion Domain Name using one of the following: a. The CA MAY verify the Applicant's control over the .onion service by posting a specific value at a well-known URL under RFC5785. b. The CA MAY verify the Applicant's control over the .onion service by having the Applicant provide a Certificate Request signed using the .onion public key if the Attributes section of the certificationRequestInfo contains: (i) A caSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy, 2) is generated by the CA, and 3) delivered to the Applicant through a Verified Method of Communication and (ii) An applicantSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy and 2) is generated by the Applicant. The signing nonce attributes have the following format: caSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-caSigningNonce } } cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } applicantSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-applicantSigningNonce } } cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 } 4. Each Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name MUST conform to the requirements of these Guidelines, including the content requirements in Section 9 and Appendix B of the Baseline Requirements, except that the CA MAY include a wildcard character in the Subject Alternative Name Extension and Subject Common Name Field as the left-most character in the .onion Domain Name provided inclusion of the wildcard character complies with Section 11.1.3 of the Baseline Requirements. 5. CAs MUST NOT issue a Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name with a validity period longer than 15 months. Despite Section 9.2.1 of the Baseline Requirements deprecating the use of Internal Names, a CA MAY issue a Certificate containing an .onion name with an expiration date later than 1 November 2015 after (and only if) .onion is officially recognized by the IESG as a reserved TLD. 6. On or before May 1, 2015, each CA MUST revoke all Certificates issued with the Subject Alternative Name extension or Common Name field that includes a Domain Name where .onion is in the right-most label of the Domain Name unless the Certificate was issued in compliance with this Appendix F. ---- Motion Ends ----- The review period for this ballot shall commence at 2200 UTC on Thursday, 4 February 2015, and will close at 2200 UTC on Thursday, 11 February 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on Monday, 18 February 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4954 bytes Desc: not available URL: From arno.fiedler at nimbus-berlin.com Thu Feb 12 08:44:33 2015 From: arno.fiedler at nimbus-berlin.com (Arno Fiedler) Date: Thu, 12 Feb 2015 09:44:33 +0100 Subject: [cabfpub] CA-Day in Berlin on 09.06.15 In-Reply-To: References: <54D93D27.6020807@cacert.org> Message-ID: <54DC67F1.7030209@nimbus-berlin.com> Hello, please save the date: TSP Compliance Info-Day "eIDAS and Trust Service Provider Conformity Assessment" Organizer: T?VIT, Bundesdruckerei, Date: Tuesday, 09.06.2015 from 10:00 AM to 05:00 PM Venue: T?VIT at Microsoft Berlin, Unter den Linden Best regards Arno Fiedler -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: arno_fiedler.vcf Type: text/x-vcard Size: 302 bytes Desc: not available URL: From kirk_hall at trendmicro.com Thu Feb 12 20:43:36 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Thu, 12 Feb 2015 20:43:36 +0000 Subject: [cabfpub] Ballot 144 -.onion domains Message-ID: Jeremy and Ben - sorry we didn't ask these questions last week, but I was travelling and didn't realize the comment period had begun. (1) We are concerned that under Ballot 144 there could be two .onion certs with the SAME domain but identifying two DIFFERENT subjects. For example, Evil Corp. and Angel Corp. could each submit a request for a .onion cert and get the same domain: [same 16 digit hash of their public keys].onion if their public keys hash to the same value. One cert would say O=Evil Corp. the other would say O=Angel Corp., so that a .onion domain would not be uniquely identified with one subject. While unlikely, it could happen. How does Tor resolve this if the same .onion domain is assigned to multiple, different subjects? If someone types in [16 digit hash].onion and that could lead to multiple Tor locations, how does Tor decide where to direct the user? (2) Does this also create an opportunity for a hacker? For example, one of the .onion domains in the SANs field of the Facebook cert you created is *.xx.fbcdn23dssr3jqnq.onion - could a hacker create a public key that would hash to the same value in order to get a cert with the same .onion domain and imitate the Facebook cert? (This is maybe the more serious case.) (3) Another concern is there is no central registry to identify the owner of a .onion domain (of course, there could be multiple owners of the domain under the scenario above). If there is no Subject info in the O field, etc., with no registry there is no real way to contact the domain (or cert owner). Any information you can provide on these point will be very helpful. 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
-------------- next part -------------- An HTML attachment was scrubbed... URL: From kirk_hall at trendmicro.com Thu Feb 12 20:45:45 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Thu, 12 Feb 2015 20:45:45 +0000 Subject: [cabfpub] Ballot 144 -.onion domains Message-ID: Here are screen shots of the Facebook.com cert, if anyone hasn't seen it. The .onion domains are in the second shot in the SANs field. [cid:image001.png at 01D046C1.D1682440] [cid:image002.png at 01D046C1.D1682440] From: Kirk Hall (RD-US) Sent: Thursday, February 12, 2015 12:44 PM To: Jeremy Rowley (jeremy.rowley at digicert.com); Ben Wilson (Ben.Wilson at digicert.com) Cc: CABFPub (public at cabforum.org) Subject: Ballot 144 -.onion domains Jeremy and Ben - sorry we didn't ask these questions last week, but I was travelling and didn't realize the comment period had begun. (1) We are concerned that under Ballot 144 there could be two .onion certs with the SAME domain but identifying two DIFFERENT subjects. For example, Evil Corp. and Angel Corp. could each submit a request for a .onion cert and get the same domain: [same 16 digit hash of their public keys].onion if their public keys hash to the same value. One cert would say O=Evil Corp. the other would say O=Angel Corp., so that a .onion domain would not be uniquely identified with one subject. While unlikely, it could happen. How does Tor resolve this if the same .onion domain is assigned to multiple, different subjects? If someone types in [16 digit hash].onion and that could lead to multiple Tor locations, how does Tor decide where to direct the user? (2) Does this also create an opportunity for a hacker? For example, one of the .onion domains in the SANs field of the Facebook cert you created is *.xx.fbcdn23dssr3jqnq.onion - could a hacker create a public key that would hash to the same value in order to get a cert with the same .onion domain and imitate the Facebook cert? (This is maybe the more serious case.) (3) Another concern is there is no central registry to identify the owner of a .onion domain (of course, there could be multiple owners of the domain under the scenario above). If there is no Subject info in the O field, etc., with no registry there is no real way to contact the domain (or cert owner). Any information you can provide on these point will be very helpful. 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
-------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 49635 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 51544 bytes Desc: image002.png URL: From sleevi at google.com Thu Feb 12 21:01:58 2015 From: sleevi at google.com (Ryan Sleevi) Date: Thu, 12 Feb 2015 13:01:58 -0800 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: References: Message-ID: On Feb 12, 2015 12:43 PM, "kirk_hall at trendmicro.com" < kirk_hall at trendmicro.com> wrote: > > Jeremy and Ben ? sorry we didn?t ask these questions last week, but I was travelling and didn?t realize the comment period had begun. > > > > (1) We are concerned that under Ballot 144 there could be two .onion certs with the SAME domain but identifying two DIFFERENT subjects. > > > > For example, Evil Corp. and Angel Corp. could each submit a request for a .onion cert and get the same domain: [same 16 digit hash of their public keys].onion if their public keys hash to the same value. One cert would say O=Evil Corp. the other would say O=Angel Corp., so that a .onion domain would not be uniquely identified with one subject. While unlikely, it could happen. > > > > How does Tor resolve this if the same .onion domain is assigned to multiple, different subjects? If someone types in [16 digit hash].onion and that could lead to multiple Tor locations, how does Tor decide where to direct the user? > > Hi Kirk, While not Jeremy, this is actually why I suggested that the full public key be included within the issued certificate itself, so as to highlight any hash collision attempts on the onion private key (e.g. by funkily encoding key parameters or by using key confusion). On a practical level, it's far out there from the realm of being feasible, but it's enough of an issue that I felt important that this should be included in the issued cert, so that sites could use, for example, certificate transparency to monitor for such things. On the TOR side, the protocol is being revved to deal with this, but it is described more at https://trac.torproject.org/projects/tor/wiki/doc/HiddenServiceNames So from the issuance side, the mitigations are including the full public key as well as requiring the EV validation, rather than DV. > > (2) Does this also create an opportunity for a hacker? For example, one of the .onion domains in the SANs field of the Facebook cert you created is *.xx.fbcdn23dssr3jqnq.onion ? could a hacker create a public key that would hash to the same value in order to get a cert with the same .onion domain and imitate the Facebook cert? (This is maybe the more serious case.) > Isn't this a restatement of 1? Or at least, the answers there would still apply. > (3) Another concern is there is no central registry to identify the owner of a .onion domain (of course, there could be multiple owners of the domain under the scenario above). If there is no Subject info in the O field, etc., with no registry there is no real way to contact the domain (or cert owner). > I'm not entirely sure I follow? Note during the discussion phase also included discussion about requiring one or more DNS names from the IANA zone as well, which seems like it would mitigate this concern. > > > Any information you can provide on these point will be very helpful. > I think it is important when considering these that, as of today, any CA can issue any name under .onion under the "Internal Names" exception. This proposal merely restricts it from being "any rules you want" to "more stringent verification required" It still treats .onion as an internal name, in as much as they still sunset and must be revoked. If this ballot fails, every CA will still be able to issue .onion names to any party they wish, including parties who have no relationship whatsoever to the onion HS. That is, if this fails, there is no requirement for attackers to execute a hash collision or factor a private key - they just need to find a CA willing to issue under the "Internal Names" rule (which, as you know, is typically validated at a level less than EV, such as OV). That's why I think this ballot is good - it doesn't prolong or extend risk, it actually _restricts_ issuance in this space until internal names are sunset, at which point, no more of these certs will be issued, no matter the rules. In practice, I expect discussion and standardization to continue, and we may see DigiCert issue a ballot in half a year that looks to extend such issuance, but that's not this ballot, thankfully, so we don't have to solve all of these issues right away. > > > > > TREND MICRO EMAIL NOTICE > The information contained in this email and any attachments is confidential > and may be subject to copyright or other intellectual property protection. > If you are not the intended recipient, you are not authorized to use or > disclose this information, and we request that you notify us by reply mail or > telephone and delete the original message from your mail system. > > > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gerv at mozilla.org Thu Feb 12 21:41:01 2015 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 12 Feb 2015 21:41:01 +0000 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: References: Message-ID: <54DD1DED.4090105@mozilla.org> On 12/02/15 20:43, kirk_hall at trendmicro.com wrote: > For example, Evil Corp. and Angel Corp. could each submit a request for > a .onion cert and get the same domain: _[same 16 digit hash of their > public keys].onion_ if their public keys hash to the same value. One > cert would say O=Evil Corp. the other would say O=Angel Corp., so that a > .onion domain would not be uniquely identified with one subject. While > unlikely, it could happen. Have you been able to put a figure on the likelihood of this occurrence? I think I could calculate it, but I'm interested in what figure you came up with that led to your concern. > (2) Does this also create an opportunity for a hacker? For example, > one of the .onion domains in the SANs field of the Facebook cert you > created is _*.xx.fbcdn23dssr3jqnq.onion_ ? could a hacker create a > public key that would hash to the same value in order to get a cert with > the same .onion domain and imitate the Facebook cert? (This is maybe > the more serious case.) Being able to create some text which hashes to a specific, defined value that you are targetting would be what's called a Preimage attack: http://en.wikipedia.org/wiki/Preimage_attack SHA-1 has no known preimage attacks. Tor .onion names use 80 bits of the SHA-1 hash, which is not the full hash, so it's possible that they might be slightly easier to attack. While there are no known attacks, my understanding is that the Tor people are looking at moving to SHA-256 as a precautionary measure. > (3) Another concern is there is no central registry to identify the > owner of a .onion domain (of course, there could be multiple owners of > the domain under the scenario above). If there is no Subject info in > the O field, etc., with no registry there is no real way to contact the > domain (or cert owner). .onion certs are going to be EV, right? So they would have Subject info in the O field. Gerv From Dean_Coclin at symantec.com Thu Feb 12 22:04:09 2015 From: Dean_Coclin at symantec.com (Dean Coclin) Date: Thu, 12 Feb 2015 14:04:09 -0800 Subject: [cabfpub] Voting period: Ballots 143 and 144 Message-ID: <14D026C7F297AD44AC82578DD818CDD038EF1E9E65@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> Just a reminder that the voting period is underway for Ballots 143 (Validation Working Group) and 144 (.onion) and closes on February 18th. Dean -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6130 bytes Desc: not available URL: From kirk_hall at trendmicro.com Thu Feb 12 22:18:35 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Thu, 12 Feb 2015 22:18:35 +0000 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: <54DD1DED.4090105@mozilla.org> References: <54DD1DED.4090105@mozilla.org> Message-ID: Responding both the Ryan and Gerv. Ryan -- you are correct that concerns (1) and (2) are related -- (1) relates to accidental clashes that give different customers the same domain. Gerv -- you are right, the change is extremely small -- but giving the same domain to different customers is something not allowed today, so it would be quite a change to allow it. This link has some information on the subject, but I really don?t understand the explanation of why clashes aren?t a concern. https://trac.torproject.org/projects/tor/wiki/doc/HiddenServiceNames On (2) ? this concern is of an intentional clash created by a hacker for evil purpose ? a much more serious issue. I notice that in Facebook?s existing .onion cert, they managed to get the following .onion domain: *.m.facebookcorewwwi.onion See screen shot below or attached. I?m sure that didn?t happen randomly, so there must have been some very serious computing that happened to get that particular 16 digit ?random? hash of a Facebook public key, facebookcorewwwi. If Facebook can reverse engineer to get that .onion domain, couldn?t a hacker (or googlegoogle.onion, for another example) do the same and get a duplicate cert with the same domain? [cid:image001.png at 01D046CE.C86B58F0] -----Original Message----- From: Gervase Markham [mailto:gerv at mozilla.org] Sent: Thursday, February 12, 2015 1:41 PM To: Kirk Hall (RD-US); Jeremy Rowley (jeremy.rowley at digicert.com); Ben Wilson (Ben.Wilson at digicert.com) Cc: CABFPub (public at cabforum.org) Subject: Re: [cabfpub] Ballot 144 -.onion domains On 12/02/15 20:43, kirk_hall at trendmicro.com wrote: > For example, Evil Corp. and Angel Corp. could each submit a request > for a .onion cert and get the same domain: _[same 16 digit hash of > their public keys].onion_ if their public keys hash to the same value. > One cert would say O=Evil Corp. the other would say O=Angel Corp., so > that a .onion domain would not be uniquely identified with one > subject. While unlikely, it could happen. Have you been able to put a figure on the likelihood of this occurrence? I think I could calculate it, but I'm interested in what figure you came up with that led to your concern. > (2) Does this also create an opportunity for a hacker? For example, > one of the .onion domains in the SANs field of the Facebook cert you > created is _*.xx.fbcdn23dssr3jqnq.onion_ ? could a hacker create a > public key that would hash to the same value in order to get a cert > with the same .onion domain and imitate the Facebook cert? (This is > maybe the more serious case.) Being able to create some text which hashes to a specific, defined value that you are targetting would be what's called a Preimage attack: http://en.wikipedia.org/wiki/Preimage_attack SHA-1 has no known preimage attacks. Tor .onion names use 80 bits of the SHA-1 hash, which is not the full hash, so it's possible that they might be slightly easier to attack. While there are no known attacks, my understanding is that the Tor people are looking at moving to SHA-256 as a precautionary measure. > (3) Another concern is there is no central registry to identify the > owner of a .onion domain (of course, there could be multiple owners of > the domain under the scenario above). If there is no Subject info in > the O field, etc., with no registry there is no real way to contact > the domain (or cert owner). .onion certs are going to be EV, right? So they would have Subject info in the O field. Gerv 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
-------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 51544 bytes Desc: image001.png URL: From gerv at mozilla.org Thu Feb 12 22:26:38 2015 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 12 Feb 2015 22:26:38 +0000 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: References: <54DD1DED.4090105@mozilla.org> Message-ID: <54DD289E.8040304@mozilla.org> Hi Kirk, On 12/02/15 22:18, kirk_hall at trendmicro.com wrote: > Ryan -- you are correct that concerns (1) and (2) are related -- (1) > relates to accidental clashes that give different customers the same > domain. Gerv -- you are right, the change is extremely small -- but > giving the same domain to different customers is something not allowed > today, so it would be quite a change to allow it. How unlikely would it need to be for you not to use the word "allow"? At the moment, it's possible for two different customers to generate the same public/private key pair, and so they would be able to impersonate each other. But, assuming there's no flaws in the RNG, it is pretty unlikely. Would you say that the CAB Forum "allows" this? > This link has some information on the subject, but I really don?t > understand the explanation of why clashes aren?t a concern. > > https://trac.torproject.org/projects/tor/wiki/doc/HiddenServiceNames Yes, I'm not sure I understand that either. Ryan? > On (2) ? this concern is of an intentional clash created by a hacker for > evil purpose ? a much more serious issue. I notice that in Facebook?s > existing .onion cert, they managed to get the following .onion domain: > > *.m.facebookcorewwwi.onion > > I?m sure that didn?t happen randomly, so there must have been some very > serious computing that happened to get that particular 16 digit ?random? > hash of a Facebook public key, _facebookcorewwwi_. Yes, it did. Facebook are on record as saying that they threw a lot of computing power at the problem, and then reviewed all the options generated which started with "facebook" and picked the one they liked best. The engineer said something like: "I feel we were very lucky in generating a good name." I rather wish they hadn't, actually, because it confuses people into thinking it's possible to just pick a good name and use it, which it isn't. > If Facebook can > reverse engineer to get that .onion domain, couldn?t a hacker (or > googlegoogle.onion, for another example) do the same and get a duplicate > cert with the same domain? No. What Facebook did was generate a lot of hashes starting "facebook", reviewed them, picked the one they liked best and then invented a "reason" for why it's that one: "Facebook's Core WWW Infrastructure". However, generating a second one which exactly matched the name Facebook picked is a much harder process. Gerv From kirk_hall at trendmicro.com Thu Feb 12 22:26:40 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Thu, 12 Feb 2015 22:26:40 +0000 Subject: [cabfpub] Ballot 143 - Formalization of validation working group Message-ID: Trend Micro votes yes. Kirk R. Hall Operations Director, Trust Services Trend Micro +1.503.753.3088 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
-------------- next part -------------- An HTML attachment was scrubbed... URL: From THollebeek at trustwave.com Thu Feb 12 22:33:23 2015 From: THollebeek at trustwave.com (Tim Hollebeek) Date: Thu, 12 Feb 2015 22:33:23 +0000 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: References: <54DD1DED.4090105@mozilla.org> Message-ID: The 40-bit attack only applies in a scenario like the following: 1. I generate 2^40 RSA key pairs. I now (probably) have two RSA key pairs with the same 80-bit URL. 2. I convince someone to use one of the two as their hidden service name I now have a second RSA key pair that can masquerade as the first. But that?s not horribly useful to me, as I also have the first key pair as well! I can convince them to use the key I generated (#2), without having to first generate a collision, and achieve the same result. There is an actual issue (the pre-image attack), where I just generate key pairs until I do collide, but: 1. That?s 2^80 / #hiddenservices key pairs. That?s a lot. 2. I have no control over which hidden service I accidentally collide with. If hidden services become widely used and there are lots of them, this conceivably becomes an issues sometime in the future, which is why I expressed concern about it on the management call. It really is time for the Tor folks to fix this before it becomes a problem. But the existing state of the .onion world is so bad, that allowing EV certificates and HTTPS for Tor is a significant improvement. The size and potential weakness of the onion hashes merit continuing attention, and perhaps a timeline to phase them out, but they?re not a practical attack today. -Tim From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of kirk_hall at trendmicro.com Sent: Thursday, February 12, 2015 5:19 PM To: Gervase Markham; Jeremy Rowley (jeremy.rowley at digicert.com); Ben Wilson (Ben.Wilson at digicert.com) Cc: CABFPub (public at cabforum.org) Subject: Re: [cabfpub] Ballot 144 -.onion domains Responding both the Ryan and Gerv. Ryan -- you are correct that concerns (1) and (2) are related -- (1) relates to accidental clashes that give different customers the same domain. Gerv -- you are right, the change is extremely small -- but giving the same domain to different customers is something not allowed today, so it would be quite a change to allow it. This link has some information on the subject, but I really don?t understand the explanation of why clashes aren?t a concern. https://trac.torproject.org/projects/tor/wiki/doc/HiddenServiceNames On (2) ? this concern is of an intentional clash created by a hacker for evil purpose ? a much more serious issue. I notice that in Facebook?s existing .onion cert, they managed to get the following .onion domain: *.m.facebookcorewwwi.onion See screen shot below or attached. I?m sure that didn?t happen randomly, so there must have been some very serious computing that happened to get that particular 16 digit ?random? hash of a Facebook public key, facebookcorewwwi. If Facebook can reverse engineer to get that .onion domain, couldn?t a hacker (or googlegoogle.onion, for another example) do the same and get a duplicate cert with the same domain? [cid:image001.png at 01D046E8.B2667340] -----Original Message----- From: Gervase Markham [mailto:gerv at mozilla.org] Sent: Thursday, February 12, 2015 1:41 PM To: Kirk Hall (RD-US); Jeremy Rowley (jeremy.rowley at digicert.com); Ben Wilson (Ben.Wilson at digicert.com) Cc: CABFPub (public at cabforum.org) Subject: Re: [cabfpub] Ballot 144 -.onion domains On 12/02/15 20:43, kirk_hall at trendmicro.com wrote: > For example, Evil Corp. and Angel Corp. could each submit a request > for a .onion cert and get the same domain: _[same 16 digit hash of > their public keys].onion_ if their public keys hash to the same value. > One cert would say O=Evil Corp. the other would say O=Angel Corp., so > that a .onion domain would not be uniquely identified with one > subject. While unlikely, it could happen. Have you been able to put a figure on the likelihood of this occurrence? I think I could calculate it, but I'm interested in what figure you came up with that led to your concern. > (2) Does this also create an opportunity for a hacker? For example, > one of the .onion domains in the SANs field of the Facebook cert you > created is _*.xx.fbcdn23dssr3jqnq.onion_ ? could a hacker create a > public key that would hash to the same value in order to get a cert > with the same .onion domain and imitate the Facebook cert? (This is > maybe the more serious case.) Being able to create some text which hashes to a specific, defined value that you are targetting would be what's called a Preimage attack: http://en.wikipedia.org/wiki/Preimage_attack SHA-1 has no known preimage attacks. Tor .onion names use 80 bits of the SHA-1 hash, which is not the full hash, so it's possible that they might be slightly easier to attack. While there are no known attacks, my understanding is that the Tor people are looking at moving to SHA-256 as a precautionary measure. > (3) Another concern is there is no central registry to identify the > owner of a .onion domain (of course, there could be multiple owners of > the domain under the scenario above). If there is no Subject info in > the O field, etc., with no registry there is no real way to contact > the domain (or cert owner). .onion certs are going to be EV, right? So they would have Subject info in the O field. Gerv TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. ________________________________ This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 51544 bytes Desc: image001.png URL: From jeremy.rowley at digicert.com Fri Feb 13 00:58:58 2015 From: jeremy.rowley at digicert.com (Jeremy Rowley) Date: Fri, 13 Feb 2015 00:58:58 +0000 Subject: [cabfpub] Ballot 143 - Formalization of validation working group In-Reply-To: References: Message-ID: <608ba22f4b5d42ec9926ed95d6548299@EX2.corp.digicert.com> DigiCert votes yes From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of kirk_hall at trendmicro.com Sent: Thursday, February 12, 2015 3:27 PM To: CABFPub (public at cabforum.org) Subject: [cabfpub] Ballot 143 - Formalization of validation working group Trend Micro votes yes. Kirk R. Hall Operations Director, Trust Services Trend Micro +1.503.753.3088 TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeremy.rowley at digicert.com Fri Feb 13 01:14:01 2015 From: jeremy.rowley at digicert.com (Jeremy Rowley) Date: Fri, 13 Feb 2015 01:14:01 +0000 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: References: Message-ID: <50b4fdabaa7a4c7e9d1c3b962071f9af@EX2.corp.digicert.com> One caveat is that another ballot is not required if the IESG officially recognizes .onion a reserved name. From: Ryan Sleevi [mailto:sleevi at google.com] Sent: Thursday, February 12, 2015 2:02 PM To: kirk_hall at trendmicro.com Cc: Jeremy Rowley; CABFPub; Ben Wilson Subject: Re: [cabfpub] Ballot 144 -.onion domains On Feb 12, 2015 12:43 PM, "kirk_hall at trendmicro.com" > wrote: > > Jeremy and Ben ? sorry we didn?t ask these questions last week, but I was travelling and didn?t realize the comment period had begun. > > > > (1) We are concerned that under Ballot 144 there could be two .onion certs with the SAME domain but identifying two DIFFERENT subjects. > > > > For example, Evil Corp. and Angel Corp. could each submit a request for a .onion cert and get the same domain: [same 16 digit hash of their public keys].onion if their public keys hash to the same value. One cert would say O=Evil Corp. the other would say O=Angel Corp., so that a .onion domain would not be uniquely identified with one subject. While unlikely, it could happen. > > > > How does Tor resolve this if the same .onion domain is assigned to multiple, different subjects? If someone types in [16 digit hash].onion and that could lead to multiple Tor locations, how does Tor decide where to direct the user? > > Hi Kirk, While not Jeremy, this is actually why I suggested that the full public key be included within the issued certificate itself, so as to highlight any hash collision attempts on the onion private key (e.g. by funkily encoding key parameters or by using key confusion). On a practical level, it's far out there from the realm of being feasible, but it's enough of an issue that I felt important that this should be included in the issued cert, so that sites could use, for example, certificate transparency to monitor for such things. On the TOR side, the protocol is being revved to deal with this, but it is described more at https://trac.torproject.org/projects/tor/wiki/doc/HiddenServiceNames So from the issuance side, the mitigations are including the full public key as well as requiring the EV validation, rather than DV. > > (2) Does this also create an opportunity for a hacker? For example, one of the .onion domains in the SANs field of the Facebook cert you created is *.xx.fbcdn23dssr3jqnq.onion ? could a hacker create a public key that would hash to the same value in order to get a cert with the same .onion domain and imitate the Facebook cert? (This is maybe the more serious case.) > Isn't this a restatement of 1? Or at least, the answers there would still apply. > (3) Another concern is there is no central registry to identify the owner of a .onion domain (of course, there could be multiple owners of the domain under the scenario above). If there is no Subject info in the O field, etc., with no registry there is no real way to contact the domain (or cert owner). > I'm not entirely sure I follow? Note during the discussion phase also included discussion about requiring one or more DNS names from the IANA zone as well, which seems like it would mitigate this concern. > > > Any information you can provide on these point will be very helpful. > I think it is important when considering these that, as of today, any CA can issue any name under .onion under the "Internal Names" exception. This proposal merely restricts it from being "any rules you want" to "more stringent verification required" It still treats .onion as an internal name, in as much as they still sunset and must be revoked. If this ballot fails, every CA will still be able to issue .onion names to any party they wish, including parties who have no relationship whatsoever to the onion HS. That is, if this fails, there is no requirement for attackers to execute a hash collision or factor a private key - they just need to find a CA willing to issue under the "Internal Names" rule (which, as you know, is typically validated at a level less than EV, such as OV). That's why I think this ballot is good - it doesn't prolong or extend risk, it actually _restricts_ issuance in this space until internal names are sunset, at which point, no more of these certs will be issued, no matter the rules. In practice, I expect discussion and standardization to continue, and we may see DigiCert issue a ballot in half a year that looks to extend such issuance, but that's not this ballot, thankfully, so we don't have to solve all of these issues right away. > > > > > TREND MICRO EMAIL NOTICE > The information contained in this email and any attachments is confidential > and may be subject to copyright or other intellectual property protection. > If you are not the intended recipient, you are not authorized to use or > disclose this information, and we request that you notify us by reply mail or > telephone and delete the original message from your mail system. > > > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sleevi at google.com Fri Feb 13 01:18:06 2015 From: sleevi at google.com (Ryan Sleevi) Date: Thu, 12 Feb 2015 17:18:06 -0800 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: <50b4fdabaa7a4c7e9d1c3b962071f9af@EX2.corp.digicert.com> References: <50b4fdabaa7a4c7e9d1c3b962071f9af@EX2.corp.digicert.com> Message-ID: On Thu, Feb 12, 2015 at 5:14 PM, Jeremy Rowley wrote: > One caveat is that another ballot is not required if the IESG officially > recognizes .onion a reserved name. Yes it does. Per BR 1.2.3 Internal Name: A string of characters (not an IP address) in a Common Name or Subject Alternative Name field of a Certificate that cannot be verified as globally unique within the public DNS at the time of certificate issuance because it does not end with a Top Level Domain registered in IANA?s Root Zone Database. An IESG reservation would not result in it being added to the IANA Root Zone Database. You can see this is already the case for RFC 6761 names not being present in the Root Zone Database at [1] [1] https://www.iana.org/domains/root/files From jeremy.rowley at digicert.com Fri Feb 13 01:43:22 2015 From: jeremy.rowley at digicert.com (Jeremy Rowley) Date: Fri, 13 Feb 2015 01:43:22 +0000 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: References: <50b4fdabaa7a4c7e9d1c3b962071f9af@EX2.corp.digicert.com> Message-ID: <258fee1ba76546188b462cc2c6ba0327@EX2.corp.digicert.com> #5 in the ballot: 5. CAs MUST NOT issue a Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name with a validity period longer than 15 months. Despite Section 9.2.1 of the Baseline Requirements deprecating the use of Internal Names, a CA MAY issue a Certificate containing an .onion name with an expiration date later than 1 November 2015 after (and only if) .onion is officially recognized by the IESG as a reserved TLD. -----Original Message----- From: Ryan Sleevi [mailto:sleevi at google.com] Sent: Thursday, February 12, 2015 6:18 PM To: Jeremy Rowley Cc: kirk_hall at trendmicro.com; CABFPub; Ben Wilson Subject: Re: [cabfpub] Ballot 144 -.onion domains On Thu, Feb 12, 2015 at 5:14 PM, Jeremy Rowley wrote: > One caveat is that another ballot is not required if the IESG > officially recognizes .onion a reserved name. Yes it does. Per BR 1.2.3 Internal Name: A string of characters (not an IP address) in a Common Name or Subject Alternative Name field of a Certificate that cannot be verified as globally unique within the public DNS at the time of certificate issuance because it does not end with a Top Level Domain registered in IANA?s Root Zone Database. An IESG reservation would not result in it being added to the IANA Root Zone Database. You can see this is already the case for RFC 6761 names not being present in the Root Zone Database at [1] [1] https://www.iana.org/domains/root/files From jeremy.rowley at digicert.com Fri Feb 13 02:26:21 2015 From: jeremy.rowley at digicert.com (Jeremy Rowley) Date: Fri, 13 Feb 2015 02:26:21 +0000 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names In-Reply-To: References: Message-ID: <95e76d821df3405eb58dcb116081b82b@EX2.corp.digicert.com> DigiCert votes "Yes" From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Tuesday, February 10, 2015 11:39 AM To: public at cabforum.org Subject: [cabfpub] Ballot 144 - Validation rules for .onion names Here's the ballot with the two typos fixed: Applicants want a CA-signed .onion address for several reasons, including: - Powerful web platform features are restricted to secure origins, which are currently not available to onion names (in part, because of the lack of IANA registration). Permitting EV certs for onion names will help provide a secure origin for the service, moving onion towards use of powerful web platform features. - Currently, access to .onion names over https from a standard browser results in the standard existing 'Invalid Certificate' warning. Training users to click through security warnings lowers the value of these warnings and will cause users to miss important security information. Removing these warnings for the user, through use of a digital certificate, will help users recognize and avoid real MITM attacks. - The public needs attribution of ownership of the .onion address to differentiate onion services, including potential phishing services. Because onion names are not easily recognizable strings, providing the public with additional information about the operator has significant security improvements, especially in regions where use of the incorrect name could have lethal consequences. The following motion has been proposed by Jeremy Rowley of DigiCert and endorsed by Ryan Sleevi of Google and Wayne Thayer of GoDaddy. --------------------- Motion Starts --------------------- 1) Amend Section 9.2.1 of the Baseline Requirements v. 1.2.3 as follows: 9.2.1 Subject Alternative Name Extension Certificate Field: extensions:subjectAltName Required/Optional: Required Contents: This 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. The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate. Wildcard FQDNs are permitted. As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name, the CA SHALL notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016. Also as of the Effective Date, the CA SHALL NOT issue a certificate with an Expiry Date later than 1 November 2015 with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name. Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Name. Effective May 1, 2015, each CA SHALL revoke all unexpired Certificates with an Internal Name using onion as the right-most label in an entry in the subjectAltName Extension or commonName field unless such Certificate was issued in accordance with Appendix F of the EV Guidelines. 2) Amend Section 9.2.2 and 11.7.1 of the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2 as follows: 9.2.2. Subject Alternative Name Extension Certificate field: subjectAltName:dNSName Required/Optional: Required Contents: This extension MUST contain one or more host Domain Name(s) owned or controlled by the Subject and to be associated with the Subject's server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). Wildcard certificates are not allowed for EV Certificates except as permitted under Appendix F. 11.7 Verification of Applicant's Domain Name 11.7.1. Verification Requirements (1) For each Fully-Qualified Domain Name listed in a Certificate, other than a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant (or the Applicant's Parent Company, Subsidiary Company, or Affiliate, collectively referred to as "Applicant" for the purposes of this section) either is the Domain Name Registrant or has control over the FQDN using a procedure specified in Section 11.1.1 of the Baseline Requirements, except that a CA MAY NOT verify a domain using the procedure described 11.1.1(7). For a Certificate issued to a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant's control over the .onion Domain Name in accordance with Appendix F. (2) Mixed Character Set Domain Names: EV Certificates MAY include Domain Names containing mixed character sets only in compliance with the rules set forth by the domain registrar. The CA MUST visually compare any Domain Names with mixed character sets with known high risk domains. If a similarity is found, then the EV Certificate Request MUST be flagged as High Risk. The CA must perform reasonably appropriate additional authentication and verification to be certain beyond reasonable doubt that the Applicant and the target in question are the same organization. 3) Add a new Appendix F to the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2: Appendix F - Issuance of Certificates for .onion Domain Names A CA may issue an EV Certificate with .onion in the right-most label of the Domain Name provided that issuance complies with the requirements set forth in this Appendix: 1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) The CAB Forum has created an extension of the TBSCertificate for use in conveying hashes of keys related to .onion addresses. The Tor Service Descriptor Hash extension has the following format: cabf-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 } TorServiceDescriptorSyntax ::= SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash TorServiceDescriptorHash:: = SEQUENCE { onionURI UTF8String algorithm AlgorithmIdentifier subjectPublicKeyHash BIT STRING } Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 6234) performed over the DER-encoding of an ASN.1 SubjectPublicKey of the .onion service and SubjectPublicKeyHash is the hash output. 2. The CA MUST verify the Applicant's control over the .onion Domain Name using one of the following: a. The CA MAY verify the Applicant's control over the .onion service by posting a specific value at a well-known URL under RFC5785. b. The CA MAY verify the Applicant's control over the .onion service by having the Applicant provide a Certificate Request signed using the .onion public key if the Attributes section of the certificationRequestInfo contains: (i) A caSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy, 2) is generated by the CA, and 3) delivered to the Applicant through a Verified Method of Communication and (ii) An applicantSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy and 2) is generated by the Applicant. The signing nonce attributes have the following format: caSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-caSigningNonce } } cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } applicantSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-applicantSigningNonce } } cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 } 4. Each Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name MUST conform to the requirements of these Guidelines, including the content requirements in Section 9 and Appendix B of the Baseline Requirements, except that the CA MAY include a wildcard character in the Subject Alternative Name Extension and Subject Common Name Field as the left-most character in the .onion Domain Name provided inclusion of the wildcard character complies with Section 11.1.3 of the Baseline Requirements. 5. CAs MUST NOT issue a Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name with a validity period longer than 15 months. Despite Section 9.2.1 of the Baseline Requirements deprecating the use of Internal Names, a CA MAY issue a Certificate containing an .onion name with an expiration date later than 1 November 2015 after (and only if) .onion is officially recognized by the IESG as a reserved TLD. 6. On or before May 1, 2015, each CA MUST revoke all Certificates issued with the Subject Alternative Name extension or Common Name field that includes a Domain Name where .onion is in the right-most label of the Domain Name unless the Certificate was issued in compliance with this Appendix F. ---- Motion Ends ----- The review period for this ballot shall commence at 2200 UTC on Thursday, 4 February 2015, and will close at 2200 UTC on Thursday, 11 February 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on Monday, 18 February 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirk_hall at trendmicro.com Fri Feb 13 02:33:12 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Fri, 13 Feb 2015 02:33:12 +0000 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: <54DD289E.8040304@mozilla.org> References: <54DD1DED.4090105@mozilla.org> <54DD289E.8040304@mozilla.org> Message-ID: Gerv, you made an interesting point below in response to my message: [Kirk] If Facebook can reverse engineer to get that .onion domain, couldn?t a hacker (or googlegoogle.onion, for another example) do the same and get a duplicate cert with the same domain? [Gerv] No. What Facebook did was generate a lot of hashes starting "facebook", reviewed them, picked the one they liked best and then invented a "reason" for why it's that one: "Facebook's Core WWW Infrastructure". However, generating a second one which exactly matched the name Facebook picked is a much harder process. Fair enough. But if Facebook can engineer *multiple* public keys that hash so the first 8 characters of ALL of them are ?facebook?, I?m guessing its not that hard and a hacker could do the same thing (or get the first 5 as yahoo, the first 6 as google, or the first 8 as microsoft). After that, the rest of the characters could be random or meaningful, but the potential harm (trickery in the domain name) is already done. Under the ballot, CAs have no obligation to scan or verify a *meaningful* .onion domain and look for phishing or fraud attempts. I was under the impression that .onion domain names were ALWAYS 12 random characters (which avoids fraud); now I see that people who want a specific .onion name can arguably game the system to get a meaningful name that they want (and it might not even be their own name ? gervmarkham1 for example). Under BR 9.2.4g, CAs are not permitted to issue certs with unverified names in the OU field: The CA SHALL implement a process that prevents an OU attribute from including a name, DBA, tradename, trademark, address, location, or other text that refers to a specific natural person or Legal Entity unless the CA has verified this information in accordance with Section 11.2 and the Certificate also contains subject:organizationName, subject:localityName, and subject:countryName attributes, also verified in accordance with Section 11.2. Of course, the OU field is not very important because it?s almost never visible to users. In contrast, a .onion domain name will be displayed to Tor users, and could cause confusion. Should we require CAs to follow the rules of BR 9.2.4g so that .onion domains that include meaningful names are verified? Or better yet, not allow .onion domains to be meaningful (require them to be random only)? 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
-------------- next part -------------- An HTML attachment was scrubbed... URL: From sleevi at google.com Fri Feb 13 02:43:57 2015 From: sleevi at google.com (Ryan Sleevi) Date: Thu, 12 Feb 2015 18:43:57 -0800 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: References: <54DD1DED.4090105@mozilla.org> <54DD289E.8040304@mozilla.org> Message-ID: On Thu, Feb 12, 2015 at 6:33 PM, kirk_hall at trendmicro.com < kirk_hall at trendmicro.com> wrote: > > In contrast, a .onion domain name will be displayed to Tor users, and > could cause confusion. Should we require CAs to follow the rules of BR > 9.2.4g so that .onion domains that include meaningful names are verified? > Or better yet, not allow .onion domains to be meaningful (require them to > be random only)? > How do you define meaningful? How do you define random? In quantifiable ways that can either be audited or inspected by third-parties (e.g. via Certificate Transparency) facebookcorewwwi is a random name. That it has symbolic meaning in English is something that happens with any random system, given sufficient time. Would these concerns go away if Item #5 was removed from the ballot (the automatic extension if IESG reserves)? While I think this discussion is useful to a degree, I do have some concerns: - Under the current provisions, anyone can issue for .onion, so this is by no means worse in any quantifiable way - Under the current provisions, using a .onion with HTTP is objectively less secure than using a .onion name with HTTPS - A .onion name is based upon an RSA-1024 bit key, which is the only security protection in play here. - A .onion name is denied access to privacy-and-security enhancing technologies (due to browsers restricting access to features not delivered over secure transports) - The concerns regarding 'spoofability' of a .onion name exist independent of any discussion in the Forum. That is, it is, at it's core, a TOR protocol "issue" (I'm not sure I would call it that, but for sake of discussion...) - Anyone using .onion names can create facebookwwwcore1.onion, given sufficient time and energy - DNS spoofing exists entirely in the Baseline Requirements (CAs are only required to document their procedures regarding high risk requests. They are not prohibited from issuing such phishy names, per 11.5 of the BR 1.2.3) - DNS spoofing exists entirely in the EV Guidelines (CAs are only required to inspect mixed-script domains, per 11.7.1 p2 of the EVG 1.5.2) Nothing prohibits facebookcorewwwi.com and facebookcorewww1.com from purchasing certificates, EV or DV, provided they demonstrate control over that namespace. Why would or should .onion be any different? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeremy.rowley at digicert.com Fri Feb 13 02:44:39 2015 From: jeremy.rowley at digicert.com (Jeremy Rowley) Date: Fri, 13 Feb 2015 02:44:39 +0000 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: References: <54DD1DED.4090105@mozilla.org> <54DD289E.8040304@mozilla.org> Message-ID: Actually, this illustrates exactly why EV is being used for these. Someone might be able to generate a name that looks similar to the facebook onion name. Without EV, you couldn?t convey which is the actual onion service run by facebook, making it easier to conduct phishing attacks. All onion names are meaningful in that they tie the service to a particular key. With EV, you have a way to tie the key directly to an existing organization. From: kirk_hall at trendmicro.com [mailto:kirk_hall at trendmicro.com] Sent: Thursday, February 12, 2015 7:33 PM To: Gervase Markham; Jeremy Rowley; Ben Wilson Cc: CABFPub (public at cabforum.org) Subject: RE: [cabfpub] Ballot 144 -.onion domains Gerv, you made an interesting point below in response to my message: [Kirk] If Facebook can reverse engineer to get that .onion domain, couldn?t a hacker (or googlegoogle.onion, for another example) do the same and get a duplicate cert with the same domain? [Gerv] No. What Facebook did was generate a lot of hashes starting "facebook", reviewed them, picked the one they liked best and then invented a "reason" for why it's that one: "Facebook's Core WWW Infrastructure". However, generating a second one which exactly matched the name Facebook picked is a much harder process. Fair enough. But if Facebook can engineer *multiple* public keys that hash so the first 8 characters of ALL of them are ?facebook?, I?m guessing its not that hard and a hacker could do the same thing (or get the first 5 as yahoo, the first 6 as google, or the first 8 as microsoft). After that, the rest of the characters could be random or meaningful, but the potential harm (trickery in the domain name) is already done. Under the ballot, CAs have no obligation to scan or verify a *meaningful* .onion domain and look for phishing or fraud attempts. I was under the impression that .onion domain names were ALWAYS 12 random characters (which avoids fraud); now I see that people who want a specific .onion name can arguably game the system to get a meaningful name that they want (and it might not even be their own name ? gervmarkham1 for example). Under BR 9.2.4g, CAs are not permitted to issue certs with unverified names in the OU field: The CA SHALL implement a process that prevents an OU attribute from including a name, DBA, tradename, trademark, address, location, or other text that refers to a specific natural person or Legal Entity unless the CA has verified this information in accordance with Section 11.2 and the Certificate also contains subject:organizationName, subject:localityName, and subject:countryName attributes, also verified in accordance with Section 11.2. Of course, the OU field is not very important because it?s almost never visible to users. In contrast, a .onion domain name will be displayed to Tor users, and could cause confusion. Should we require CAs to follow the rules of BR 9.2.4g so that .onion domains that include meaningful names are verified? Or better yet, not allow .onion domains to be meaningful (require them to be random only)? TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeremy.rowley at digicert.com Fri Feb 13 02:55:02 2015 From: jeremy.rowley at digicert.com (Jeremy Rowley) Date: Fri, 13 Feb 2015 02:55:02 +0000 Subject: [cabfpub] Domain Validation Revision Message-ID: Attached is a draft proposal from the EV working group about revising the domain validation in the BRs. The intent is 1) to eliminate the "any other option" (as it made domain validation essentially meaningless, 2) tighten up the domain validation language, and 3) permit attorney/accountants to draft the domain authorization document. Note that revising this section will automatically revise domain validation in EV. Also note that this is a draft from the working group and not yet a proposed ballot. Jeremy -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Domain Validation Revision Proposal.docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Size: 20594 bytes Desc: Domain Validation Revision Proposal.docx URL: From sleevi at google.com Fri Feb 13 03:08:50 2015 From: sleevi at google.com (Ryan Sleevi) Date: Thu, 12 Feb 2015 19:08:50 -0800 Subject: [cabfpub] Domain Validation Revision In-Reply-To: References: Message-ID: Jeremy, I'm excited to see momentum towards removing the the "Any other option" language, so I'm glad to hear the EV working group is tackling this. In line with "tightening up" the requirements, it would be nice to see Section 7 tightened to go from "Making a change on any file on a web server" to being a specific path (e.g. a .well-known URI) Incidentally, due to other discussions, I'm curious how 2 and 3 tangibly differ (given that the Registrar will provide WHOIS information). Even if they are kept separate, does it make sense to add "through a Reliable Method of Communication" to Section 3, as you have with 1/2? Regarding the language "agreed-upon", this does seem to give significant leeway for CAs to be lax in ways that attackers may exploit. Consistent with your "tightening up" goal, should Items 6 and 7 be explicit that the CA must dictate what change to make? Otherwise, I am concerned that the attacker can "propose" a change (using a portion of the system that they control) and then be issued a certificate. As I've mentioned in the past, it would be nice to see an explicit whitelist for these two methods, consistent with the whitelist for email addresses in Section 4. Put differently, I can see 7 being a little fuzzy-on-the-edges, even though it does approach a more restrictive subset. It would be great to explicitly specify record types that may be used to perform this demonstration (e.g. a TXT record with some CA-dictated value, making a change to a CNAME/A/AAAA in some meaningful way, etc) 8 concerns me for a couple reasons, even though it's moving in the right direction. - You require HTTPS, but that seems overkill, when you only need to perform a TLS handshake. That is, consider a mail server configured for SMTP-S - it seems that would be a viable configuration - It would seem that anyone that can get a port forwarded on a particular address can now get a certificate on that address. For things like STUN-TCP services, this seems quite bad! - The definition of "test certificate" is, from experience, a bit of a handwave that varies from CA to CA. It would be nice to put some explicit technical profile in place here (e.g. a critical poison extension, a requirement that EKUs are present but not serverAuth/clientAuth, issued from a CA independent of the issuing CA's 'trusted' hierarchy) that would prevent relying parties from believing the test certificate is "real" These are just some initial reactions from the proposal; more may come in time. On Thu, Feb 12, 2015 at 6:55 PM, Jeremy Rowley wrote: > Attached is a draft proposal from the EV working group about revising the > domain validation in the BRs. The intent is 1) to eliminate the ?any other > option? (as it made domain validation essentially meaningless, 2) tighten up > the domain validation language, and 3) permit attorney/accountants to draft > the domain authorization document. > > > > Note that revising this section will automatically revise domain validation > in EV. Also note that this is a draft from the working group and not yet a > proposed ballot. > > > > Jeremy > > > > > > > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public > From jeremy.rowley at digicert.com Fri Feb 13 03:37:18 2015 From: jeremy.rowley at digicert.com (Jeremy Rowley) Date: Fri, 13 Feb 2015 03:37:18 +0000 Subject: [cabfpub] Domain Validation Revision In-Reply-To: References: Message-ID: <64bba0d4f05e48fe9673b25b87dd400d@EX2.corp.digicert.com> Thanks Ryan, In line with "tightening up" the requirements, it would be nice to see Section 7 tightened to go from "Making a change on any file on a web server" to being a specific path (e.g. a .well-known URI) [JR] We discussed this, but I can't remember what the objection was. I'll bring it back to the working group unless someone else chimes in. Incidentally, due to other discussions, I'm curious how 2 and 3 tangibly differ (given that the Registrar will provide WHOIS information). Even if they are kept separate, does it make sense to add "through a Reliable Method of Communication" to Section 3, as you have with 1/2? [JR] For 2 sometimes we call up the registrar to get info on how to contact the registrant (such as when the domain is private). However, we could probably combine them to a single bullet point and apply reliable method of communication to both. Regarding the language "agreed-upon", this does seem to give significant leeway for CAs to be lax in ways that attackers may exploit. Consistent with your "tightening up" goal, should Items 6 and 7 be explicit that the CA must dictate what change to make? Otherwise, I am concerned that the attacker can "propose" a change (using a portion of the system that they control) and then be issued a certificate. As I've mentioned in the past, it would be nice to see an explicit whitelist for these two methods, consistent with the whitelist for email addresses in Section 4. [JR] Agreed. By posting this to the mailing list, we're hoping that CAs will indicate exactly what they want covered so we can narrow the scope of these two sections. I probably should have mentioned that in the original email... Put differently, I can see 7 being a little fuzzy-on-the-edges, even though it does approach a more restrictive subset. It would be great to explicitly specify record types that may be used to perform this demonstration (e.g. a TXT record with some CA-dictated value, making a change to a CNAME/A/AAAA in some meaningful way, etc) [JR] I'll have the working group come up with an initial list. If anyone has specific ways they verify though DNS, please email it to me for consideration. 8 concerns me for a couple reasons, even though it's moving in the right direction. - You require HTTPS, but that seems overkill, when you only need to perform a TLS handshake. That is, consider a mail server configured for SMTP-S - it seems that would be a viable configuration - It would seem that anyone that can get a port forwarded on a particular address can now get a certificate on that address. For things like STUN-TCP services, this seems quite bad! - The definition of "test certificate" is, from experience, a bit of a handwave that varies from CA to CA. It would be nice to put some explicit technical profile in place here (e.g. a critical poison extension, a requirement that EKUs are present but not serverAuth/clientAuth, issued from a CA independent of the issuing CA's 'trusted' hierarchy) that would prevent relying parties from believing the test certificate is "real" [JR] This was added by GlobalSign so I'll let them comment. These are just some initial reactions from the proposal; more may come in time. On Thu, Feb 12, 2015 at 6:55 PM, Jeremy Rowley wrote: > Attached is a draft proposal from the EV working group about revising > the domain validation in the BRs. The intent is 1) to eliminate the > ?any other option? (as it made domain validation essentially > meaningless, 2) tighten up the domain validation language, and 3) > permit attorney/accountants to draft the domain authorization document. > > > > Note that revising this section will automatically revise domain > validation in EV. Also note that this is a draft from the working > group and not yet a proposed ballot. > > > > Jeremy > > > > > > > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public > From kirk_hall at trendmicro.com Fri Feb 13 06:22:59 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Fri, 13 Feb 2015 06:22:59 +0000 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: References: <54DD1DED.4090105@mozilla.org> <54DD289E.8040304@mozilla.org> Message-ID: BR 11.5 High Risk Requests The CA SHALL develop, maintain, and implement documented procedures that identify and require additional verification activity for High Risk Certificate Requests prior to the Certificate?s approval, as reasonably necessary to ensure that such requests are properly verified under these Requirements. High Risk Certificate Request: A Request that the CA flags for additional scrutiny by reference to internal criteria and databases maintained by the CA, which may include names at higher risk for phishing or other fraudulent usage, names contained in previously rejected certificate requests or revoked Certificates, names listed on the Miller Smiles phishing list or the Google Safe Browsing list, or names that the CA identifies using its own risk-mitigation criteria. We won?t issue certs for microsoft.example.com, googleserver.example.com, etc., even though our customer owns example.com. I think the same concerns would apply to .onion certs, for the same reason. From: Ryan Sleevi [mailto:sleevi at google.com] Sent: Thursday, February 12, 2015 6:44 PM To: Kirk Hall (RD-US) Cc: Gervase Markham; Jeremy Rowley (jeremy.rowley at digicert.com); Ben Wilson (Ben.Wilson at digicert.com); CABFPub (public at cabforum.org) Subject: Re: [cabfpub] Ballot 144 -.onion domains On Thu, Feb 12, 2015 at 6:33 PM, kirk_hall at trendmicro.com > wrote: In contrast, a .onion domain name will be displayed to Tor users, and could cause confusion. Should we require CAs to follow the rules of BR 9.2.4g so that .onion domains that include meaningful names are verified? Or better yet, not allow .onion domains to be meaningful (require them to be random only)? How do you define meaningful? How do you define random? In quantifiable ways that can either be audited or inspected by third-parties (e.g. via Certificate Transparency) facebookcorewwwi is a random name. That it has symbolic meaning in English is something that happens with any random system, given sufficient time. Would these concerns go away if Item #5 was removed from the ballot (the automatic extension if IESG reserves)? While I think this discussion is useful to a degree, I do have some concerns: - Under the current provisions, anyone can issue for .onion, so this is by no means worse in any quantifiable way - Under the current provisions, using a .onion with HTTP is objectively less secure than using a .onion name with HTTPS - A .onion name is based upon an RSA-1024 bit key, which is the only security protection in play here. - A .onion name is denied access to privacy-and-security enhancing technologies (due to browsers restricting access to features not delivered over secure transports) - The concerns regarding 'spoofability' of a .onion name exist independent of any discussion in the Forum. That is, it is, at it's core, a TOR protocol "issue" (I'm not sure I would call it that, but for sake of discussion...) - Anyone using .onion names can create facebookwwwcore1.onion, given sufficient time and energy - DNS spoofing exists entirely in the Baseline Requirements (CAs are only required to document their procedures regarding high risk requests. They are not prohibited from issuing such phishy names, per 11.5 of the BR 1.2.3) - DNS spoofing exists entirely in the EV Guidelines (CAs are only required to inspect mixed-script domains, per 11.7.1 p2 of the EVG 1.5.2) Nothing prohibits facebookcorewwwi.com and facebookcorewww1.com from purchasing certificates, EV or DV, provided they demonstrate control over that namespace. Why would or should .onion be any different? 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
-------------- next part -------------- An HTML attachment was scrubbed... URL: From sleevi at google.com Fri Feb 13 07:18:08 2015 From: sleevi at google.com (Ryan Sleevi) Date: Thu, 12 Feb 2015 23:18:08 -0800 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: References: <54DD1DED.4090105@mozilla.org> <54DD289E.8040304@mozilla.org> Message-ID: Right, I'm aware you, as an individual CA, may not, but the BRs 1) Don't place any requirements beyond documenting and having a procedure for those flagged High Risk. The procedures may simply be "We require a phone call and a pinky promise to be good" 2) Don't place any requirements on the criteria for a request being flagged as High Risk, other than all EV certs are automatically high risk. Thus while you won't issue for microsoft.example.com or googleserver.example.com (and, to be fair, TrendMicro certainly will issue certs for those names, since it seems you will sell *.example.com), another CA may, and without violating any requirements. This is true whether the CA is issuing for DV or EV. I'm not trying to be stubborn here, but again, it is worth reiterating that nothing in the BRs or EVGs requires that a CA treat a request for facebook1.com any different than facebook2.com, or fbcdn.com any different than fcbdn.com, beyond the ambiguous and underspecified "addition verification activity", and if and only if the CA deems it high risk (which they may not). They do not prohibit a CA from issuing these certs, so I see no reason why .onion should be any different, especially since certificates are not an anti-phishing tool. My goal in arguing for these certs is I believe they are a great tool to increase online privacy and security, and, from a validation and verification space, are not weaker than the existing DV and EV practices. Indeed, in very real ways, this proposal is actually stronger than some of the verification practices CAs currently use (e.g. it requires a cryptographic key binding the name, rather than the insecure and unauthenticated reliance on DNS) I am concerned that the questions on criteria from my previous mail were somewhat ignored. I definitely think that if there are opportunities to improve this ballot, we should take them. However, your previous comment regarding "randomness" doesn't really establish actionable, auditable, objective criteria, and proposes to require more than the BRs require or CAs practice. I'm not sure how we can reasonably satisfy your concerns because of this, nor whether the absence of a solution for a problem the BRs don't address means you will vote to leave .onion unvalidated and unregulated, and, as a consequence, untrusted by some UAs (notably, Chrome). On Feb 12, 2015 10:23 PM, "kirk_hall at trendmicro.com" < kirk_hall at trendmicro.com> wrote: > *BR 11.5 High Risk Requests* > > The CA SHALL develop, maintain, and implement documented procedures that > identify and require additional verification activity for High Risk > Certificate Requests prior to the Certificate?s approval, as reasonably > necessary to ensure that such requests are properly verified under these > Requirements. > > > > *High Risk Certificate Request: *A Request that the CA flags for > additional scrutiny by reference to internal criteria and databases > maintained by the CA, which may include names at higher risk for phishing > or other fraudulent usage, names contained in previously rejected > certificate requests or revoked Certificates, names listed on the Miller > Smiles phishing list or the Google Safe Browsing list, or names that the CA > identifies using its own risk-mitigation criteria. > > > > We won?t issue certs for microsoft.example.com, googleserver.example.com, > etc., even though our customer owns example.com. I think the same > concerns would apply to .onion certs, for the same reason. > > > > *From:* Ryan Sleevi [mailto:sleevi at google.com] > *Sent:* Thursday, February 12, 2015 6:44 PM > *To:* Kirk Hall (RD-US) > *Cc:* Gervase Markham; Jeremy Rowley (jeremy.rowley at digicert.com); Ben > Wilson (Ben.Wilson at digicert.com); CABFPub (public at cabforum.org) > *Subject:* Re: [cabfpub] Ballot 144 -.onion domains > > > > > > > > On Thu, Feb 12, 2015 at 6:33 PM, kirk_hall at trendmicro.com < > kirk_hall at trendmicro.com> wrote: > > In contrast, a .onion domain name will be displayed to Tor users, and > could cause confusion. Should we require CAs to follow the rules of BR > 9.2.4g so that .onion domains that include meaningful names are verified? > Or better yet, not allow .onion domains to be meaningful (require them to > be random only)? > > > > How do you define meaningful? How do you define random? In quantifiable > ways that can either be audited or inspected by third-parties (e.g. via > Certificate Transparency) > > > > facebookcorewwwi is a random name. That it has symbolic meaning in English > is something that happens with any random system, given sufficient time. > > > > Would these concerns go away if Item #5 was removed from the ballot (the > automatic extension if IESG reserves)? > > > > While I think this discussion is useful to a degree, I do have some > concerns: > > > > - Under the current provisions, anyone can issue for .onion, so this is by > no means worse in any quantifiable way > > > > - Under the current provisions, using a .onion with HTTP is objectively > less secure than using a .onion name with HTTPS > > - A .onion name is based upon an RSA-1024 bit key, which is the only > security protection in play here. > > - A .onion name is denied access to privacy-and-security enhancing > technologies (due to browsers restricting access to features not delivered > over secure transports) > > > > - The concerns regarding 'spoofability' of a .onion name exist independent > of any discussion in the Forum. That is, it is, at it's core, a TOR > protocol "issue" (I'm not sure I would call it that, but for sake of > discussion...) > > - Anyone using .onion names can create facebookwwwcore1.onion, given > sufficient time and energy > > - DNS spoofing exists entirely in the Baseline Requirements (CAs are > only required to document their procedures regarding high risk requests. > They are not prohibited from issuing such phishy names, per 11.5 of the BR > 1.2.3) > > - DNS spoofing exists entirely in the EV Guidelines (CAs are only > required to inspect mixed-script domains, per 11.7.1 p2 of the EVG 1.5.2) > > > > Nothing prohibits facebookcorewwwi.com and facebookcorewww1.com from > purchasing certificates, EV or DV, provided they demonstrate control over > that namespace. Why would or should .onion be any different? > > > TREND MICRO EMAIL NOTICE > The information contained in this email and any attachments is confidential > and may be subject to copyright or other intellectual property protection. > If you are not the intended recipient, you are not authorized to use or > disclose this information, and we request that you notify us by reply mail or > telephone and delete the original message from your mail system. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From i-barreira at izenpe.net Fri Feb 13 08:05:11 2015 From: i-barreira at izenpe.net (i-barreira at izenpe.net) Date: Fri, 13 Feb 2015 09:05:11 +0100 Subject: [cabfpub] ballots 143 and 144 Message-ID: <763539E260C37C46A0D6B340B5434C3B0ADAE0DE@AEX06.ejsarea.net> Izenpe votes as follow 143: yes 144: abstains I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 19121 bytes Desc: image001.png URL: From i-barreira at izenpe.net Fri Feb 13 08:16:20 2015 From: i-barreira at izenpe.net (i-barreira at izenpe.net) Date: Fri, 13 Feb 2015 09:16:20 +0100 Subject: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc In-Reply-To: A References: <763539E260C37C46A0D6B340B5434C3B0ACD81A9@AEX06.ejsarea.net> A Message-ID: <763539E260C37C46A0D6B340B5434C3B0ADAE0EB@AEX06.ejsarea.net> Dear Jody, I understand your concern because it?s not easy for you to manage all possible combinations regarding ETSI audits in different countries so will try to clarify your example. First of all, no AuditCo has to be member of ETSI, AuditCo can perform ETSI accredited audits without being member of ETSI, they only need to be accredited in their country as stated in Annex E requirements. So, For example, ? Company A is a commercial CA that operates in Israel ? Auditor Jones works for AuditCo, which is based in Israel ? AuditCo is certified by some governmental agency as a qualified auditor IB? AuditCo has to be accredited under its National Accreditation Body according to ISO 17021. In the case of Israel, to follow the example, in the associated members tab of the EA, you can find the Israeli accreditation body, called ISRAC. Then AuditCo should be listed there and meeting the requirements to perform ETSI audits according to the national scheme indicated by ISRAC ? AuditCo is not an ETSI Member or Associate Member IB ? this is not necessary. No need to be an ETSI member to perform ETSI audits ? Auditor Jones audits Company A using the ETSI 102042 standard, and Company A sends the auditor's attestation letter to Microsoft as evidence that Company A complied with the Program's requirements. IB? this is perfectly valid if AuditCo is listed in ISRAC and is allowed to perform ETSI audits. Of course Auditor Jones has to be also accredited to perform these kind of audits, has to be "qualified", so it?s not only the company but also the auditor, but that?s an internal task of the AuditCo. Regarding of being member of not, this is voluntary, they can join ETSI or not and don?t think that solve the problem because joining ETSI does not mean that you?re "qualified" or "accredited" to perform an ETSI audit, it?s just indicate that you belong to a club for example. And of course, if company A needs an auditing company accredited in Israel and there?s none, they can look for in other countries. For example, in Spain there?s no accredited auditing bodies to perform ETSI audits listed in our NAB, called ENAC, so, we, Izenpe, had to look for another option. So, we contacted for the first 6 years with KPMG in the Netherlands, and the last 3, with TUV IT in Germany. And Izenpe has an accredited ETSI audits according to the, right now, German national scheme and we?re listed in Germany. We?ll debate this within ETSI ESI trying to find an easier solution. Regards I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. De: Jody Cloutier [mailto:jodycl at microsoft.com] Enviado el: mi?rcoles, 11 de febrero de 2015 0:32 Para: Barreira Iglesias, I?igo; public at cabforum.org Asunto: RE: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Thank you, Inigo. I think the problem is that, under ETSI, it's difficult to discern what an "equivalent national scheme" is. This sets up the scenario in which an auditor is employed by an organization that is recognized somehow by the government, but is not affiliated with an ETSI member organization (http://www.european-accreditation.org/home ). Microsoft does not know whether or not this auditor is qualified or not. For example, ? Company A is a commercial CA that operates in Israel ? Auditor Jones works for AuditCo, which is based in Israel ? AuditCo is certified by some governmental agency as a qualified auditor ? AuditCo is not an ETSI Member or Associate Member ? Auditor Jones audits Company A using the ETSI 102042 standard, and Company A sends the auditor's attestation letter to Microsoft as evidence that Company A complied with the Program's requirements. In this scenario, how does Microsoft know that Auditor Jones conducted a proper audit without expending significant resources to determine whether and according to what standard AuditCo and Auditor Jones was certified? Microsoft believes that it would be simpler if the requirements were that the Auditor must work for a company that is affiliated with an ETSI-approved member organization. If Company A needs an auditor and there is no qualified auditor in Israel, the company can use an auditor from a member organization via the cross-border conformity rules. Unless I am fundamentally misunderstanding the rules, the above is something that Microsoft is presently struggling with, and we'd like to try to make the rules easier to understand for potential partners and ourselves. Jody Cloutier Senior Security Program Manager Microsoft Trusted Root Certificate Program jody.cloutier at microsoft.com 425.443.8922 Operating Systems Group Global Risk and Compliance From: i-barreira at izenpe.net [mailto:i-barreira at izenpe.net] Sent: Tuesday, February 10, 2015 3:09 AM To: Jody Cloutier; public at cabforum.org Subject: RE: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Hi Jody, Regarding your comment on ETSI audits, I have to say that the ETSI audits shall be performed by accredited auditors as mentioned in Annex E of the current ETSI TS 102 042. ETSI audits performed by not accredited auditors shall be considered invalid. Microsoft is accepting ETSI audits since the very beginning in its root program requirements indicating this requirement. ETSI is providing a list of accredited auditors as mere information because has to be maintained by every NAB (National Accreditation Body). It?s true that this has to be improved regarding the new regulation 910/2014 and the new ENs and will take some time, but at the moment, it?s clearly stated that the audits shall be performed by accredited auditors. Don?t hesitate in contacting me for any additional information or help. Sometimes I?ve received some emails from Tom or Kelvin asking for the qualification of some audits, so, as say, you can contact me regarding this issue. Regards I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. De: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] En nombre de Jody Cloutier Enviado el: lunes, 09 de febrero de 2015 18:55 Para: CABFPub (public at cabforum.org) Asunto: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Microsoft comments on Section 17. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 19121 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 1181 bytes Desc: image002.png URL: From adriano.santoni at staff.aruba.it Fri Feb 13 09:23:47 2015 From: adriano.santoni at staff.aruba.it (Adriano Santoni) Date: Fri, 13 Feb 2015 10:23:47 +0100 Subject: [cabfpub] Ballots 143 and 144 In-Reply-To: <763539E260C37C46A0D6B340B5434C3B0ADAE0DE@AEX06.ejsarea.net> References: <763539E260C37C46A0D6B340B5434C3B0ADAE0DE@AEX06.ejsarea.net> Message-ID: <54DDC2A3.2000200@staff.aruba.it> An HTML attachment was scrubbed... URL: From gerv at mozilla.org Fri Feb 13 09:53:18 2015 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 13 Feb 2015 09:53:18 +0000 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: References: <54DD1DED.4090105@mozilla.org> <54DD289E.8040304@mozilla.org> Message-ID: <54DDC98E.8020907@mozilla.org> Hi Kirk, On 13/02/15 02:33, kirk_hall at trendmicro.com wrote: > Fair enough. But if Facebook can engineer **multiple** public keys that > hash so the first 8 characters of ALL of them are ?facebook?, I?m > guessing its not that hard and a hacker could do the same thing (or get > the first 5 as yahoo, the first 6 as google, or the first 8 as > microsoft). After that, the rest of the characters could be random or > meaningful, but the potential harm (trickery in the domain name) is > already done. .onion names represent 80 bits of data (half of the 160 bits of a SHA-1 hash) and are 16 characters, so each character represents 5 bits. This means that to fix the first character would require generating about 32 (2 ^ 5) keys. Not many. But to fix the first two characters would require 32 ^ 2 = 1024 keys. Each additional character you want to fix makes the job 32 times harder. Therefore, getting even one key where the first 8 hash characters are "facebook" requires approx. 1 x 10^12 keys to be generated (that's 100,000,000,000). Facebook has a lot of computing power, so they could do this. This is not out of the reach of others, but would be expensive. I'm not sure a phisher would consider this the most cost-effective method of phishing. > Under the ballot, CAs have no obligation to scan or verify a > **meaningful** .onion domain and look for phishing or fraud attempts. Do they have such an obligation for normal domain names? If so, why does that obligation not extend to .onion names? > I > was under the impression that .onion domain names were ALWAYS 12 random > characters (which avoids fraud); now I see that people who want a > specific .onion name can arguably game the system to get a meaningful > name that they want (and it might not even be their own name ? > gervmarkham1 for example). The longer the required "meaningful" portion is, the harder it is to find a name beginning with it. As I said, each extra character you want makes it 32 times harder. So getting an 8-character prefix ("facebook") requires approx. 1 x 10^12 keys to be generated. Getting an 11 character prefix ("gervmarkham") requires 3.6 x 10^16 - i.e. it's 32,678 times harder. 11 characters would have been out of the reach of even Facebook. > In contrast, a .onion domain name will be displayed to Tor users, and > could cause confusion. Should we require CAs to follow the rules of BR > 9.2.4g so that .onion domains that include meaningful names are > verified? Or better yet, not allow .onion domains to be meaningful > (require them to be random only)? I think the idea of requiring "randomness" would not be any better. Let's say we required Facebook to be: 5jdgiu3sn4j2lkqq.onion. It would be equally as easy for someone to generate a key matching the first 8 letters of this as it is for someone to generate one matching the word "facebook". So for the same effort as above, I could generate: 5jdgiu3sya3mldpz.onion I'm not convinced that a user is going to recognise the difference between those two better than the difference between two strings starting "facebook". This is fundamentally why the proposal is that onion names be EV only - because looking at the domain name is not a good way of determining the owner, whether it's random or mnemonic. Gerv From gerv at mozilla.org Fri Feb 13 10:05:17 2015 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 13 Feb 2015 10:05:17 +0000 Subject: [cabfpub] Domain Validation Revision In-Reply-To: References: Message-ID: <54DDCC5D.50305@mozilla.org> On 13/02/15 02:55, Jeremy Rowley wrote: > Attached is a draft proposal from the EV working group about revising > the domain validation in the BRs. The intent is 1) to eliminate the > ?any other option? (as it made domain validation essentially > meaningless, I don't agree that the "any other option" makes domain validation essentially meaningless. The current text is as follows: "Using any other method of confirmation, provided that the CA maintains documented evidence that the method of confirmation establishes that the Applicant is the Domain Name Registrant or has control over the FQDN to at least the same level of assurance as those methods previously described." This basically means that CAs can innovate in the way they do domain control as long as the level of assurance remains the same, and it makes the CA responsible for confirming that this is so. (And if a CA was using this clause, I would expect the auditor auditing them to the BRs to review their documentation and make an assessment as to whether the level of assurance was equivalent.) Given that this is an area of CA operations where there are patents on some methods of doing things, open-endedness is IMO important to make sure that the BRs are not used as a device to force CAs to acquire patent licenses due to limited options. I have no objection to listing more methods that the CAB Forum explicitly finds to be acceptable, but I think removing the flexibility is a backwards step. > 3) permit > attorney/accountants to draft the domain authorization document. If I understand this correctly, then I am opposed. I don't see why a lawyer or an accountant is an appropriate authority on the subject of who controls a domain. Domain control can only be properly validated either by the registrar who issued the domain, the registrant listed in WHOIS, or some practical demonstration of control. No-one else's opinion matters. Gerv From bruce.morton at entrust.com Fri Feb 13 13:17:57 2015 From: bruce.morton at entrust.com (Bruce Morton) Date: Fri, 13 Feb 2015 13:17:57 +0000 Subject: [cabfpub] Domain Validation Revision In-Reply-To: References: Message-ID: <452C99D20750E74083DBA441FF932385E4162A8B@SOTTEXCH10.corp.ad.entrust.com> Some comments: Item 1 would originally allow confirmation of the domain name registrant using a WHOIS review. Now this must be done using a Reliable Method of Communications which does not appear to be compatible. Items 2, 3 and 4 now state "Confirming authorization of the Certificate's issuance". The purpose of section 11.1.1 is to confirm "the Applicant either is the Domain Name Registrant or has control." I don't think we need the new language about certificate's issuance. Thanks, Bruce. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Thursday, February 12, 2015 9:55 PM To: CABFPub (public at cabforum.org) Subject: [cabfpub] Domain Validation Revision Attached is a draft proposal from the EV working group about revising the domain validation in the BRs. The intent is 1) to eliminate the "any other option" (as it made domain validation essentially meaningless, 2) tighten up the domain validation language, and 3) permit attorney/accountants to draft the domain authorization document. Note that revising this section will automatically revise domain validation in EV. Also note that this is a draft from the working group and not yet a proposed ballot. Jeremy -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruce.morton at entrust.com Fri Feb 13 13:46:05 2015 From: bruce.morton at entrust.com (Bruce Morton) Date: Fri, 13 Feb 2015 13:46:05 +0000 Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group In-Reply-To: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> References: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> Message-ID: <452C99D20750E74083DBA441FF932385E4162C54@SOTTEXCH10.corp.ad.entrust.com> Entrust votes Yes. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Wednesday, February 04, 2015 4:05 PM To: CABFPub Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group Ballot 143 - Formalization of validation working group ---- Reason ---- In order to address validation issues and inconsistencies in both the SSL Baseline Requirements and the EV Guidelines, the CAB Forum has held an informal working group previously referred to as the Extended Validation Working Group now known as the Validation Working Group, would like to modify its scope to include validation in the Baseline Requirements as well as the EV Guidelines. Jeremy Rowley of DigiCert made the following motion, which was endorsed by Rich Smith of Comodo and Kirk Hall of TrendMicro ---- Motion begins ---- The CA-Browser Forum formally establishes the Validation Working Group as an official working group of the CAB Forum, replacing the previous informal EV working group. The scope of this working group is to address issues arising under adopted CAB Forum standards related to the validation of certificate information and the inclusion of information in certificates. Scope: The Validation Working Group will consider all matters relating to the validation and inclusion of information in certificates under adopted CAB Forum guidelines. Deliverables: The Working Group shall produce one or more documents offering options to the Forum for validation within the scope defined above. ---- Motion Ends ---- The review period for this ballot shall commence at 2200 UTC on 5 Feb 2015, and will close at 2200 UTC on 11 Feb 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on 18 Feb 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: From volkan.nergiz at turktrust.com.tr Fri Feb 13 15:18:42 2015 From: volkan.nergiz at turktrust.com.tr (Volkan Nergiz) Date: Fri, 13 Feb 2015 17:18:42 +0200 Subject: [cabfpub] Ballots 143 and 144 Message-ID: <00db01d047a0$59e3dfb0$0dab9f10$@turktrust.com.tr> T?RKTRUST votes YES for Ballot 143 and ABSTAIN for Ballot 144. Volkan NERG?Z Quality Management System Specialist TURKTRUST Information Security Services Inc. Address: Hollanda Caddesi 696. Sokak No: 7 Y?ld?z, ?ankaya 06550 - ANKARA Phone: (312) 439 10 00 - 226 Fax: (312) 439 10 01 E-Mail: volkan.nergiz at turktrust.com.tr Web: www.turktrust.com.tr -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 1906 bytes Desc: not available URL: From kirk_hall at trendmicro.com Fri Feb 13 16:28:29 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Fri, 13 Feb 2015 16:28:29 +0000 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: <54DDC98E.8020907@mozilla.org> References: <54DD1DED.4090105@mozilla.org> <54DD289E.8040304@mozilla.org> <54DDC98E.8020907@mozilla.org> Message-ID: Thanks, Gerv ? but if it wasn?t too hard for Facebook to generate multiple ?facebook? .onion domains (presumably using automated methods), I?m not convinced it would be hard for hackers. And I?m still troubled that the .onion plan allows multiple customers to obtain the same .onion domain (meaning there could be multiple certs for the same .onion domain that belong to different subjects). I have to circle back to ?Why are we doing this?? ? Tor users want to visit websites anonymously. [That sounds like something CAs should support if possible] ? Website owners do *not* want anonymity ? in fact, just the opposite. They want EV certs with their identity information included that will work for Tor users. ? For some reason, regular TLD certs (like .com certs) won?t work after Tor users go through the Tor blender. [Does anyone know why that is the case?] ? But for some reason, Internal Name .onion certs *do* work for Tor users after they go through the Tor blender. [Does anyone know why this is so?] ? Tor does not want to apply for .onion as a TLD, and does not want to be the registrar for .onion [Why not? That would solve everything by making .onion a TLD, so all the current CA rules could apply. And remember, website users are not looking for anonymity in their certs ? they want EV certs with their identity displayed prominently in the browsers.] ? The Tor process for assigning .onion domains does not require domains to be unique. Why won?t regular TLD certs work in Tor? Why do .onion Internal Name certs work in Tor? Could Tor fix this discrepancy so we don?t have to continue allowing Internal Name certs for the .onion case? If two or more website owners receive the same .onion domain (either by accident, or by design of some of the website owners who choose what their .onion domain will be, like Facebook did), how does Tor resolve this clash? Where does it send users? I really don?t understand why we have to create an exception to the rules to accommodate this case. -----Original Message----- From: Gervase Markham [mailto:gerv at mozilla.org] Sent: Friday, February 13, 2015 1:53 AM To: Kirk Hall (RD-US); Jeremy Rowley (jeremy.rowley at digicert.com); Ben Wilson (Ben.Wilson at digicert.com) Cc: CABFPub (public at cabforum.org) Subject: Re: [cabfpub] Ballot 144 -.onion domains Hi Kirk, On 13/02/15 02:33, kirk_hall at trendmicro.com wrote: > Fair enough. But if Facebook can engineer **multiple** public keys > that hash so the first 8 characters of ALL of them are ?facebook?, I?m > guessing its not that hard and a hacker could do the same thing (or > get the first 5 as yahoo, the first 6 as google, or the first 8 as > microsoft). After that, the rest of the characters could be random or > meaningful, but the potential harm (trickery in the domain name) is > already done. .onion names represent 80 bits of data (half of the 160 bits of a SHA-1 hash) and are 16 characters, so each character represents 5 bits. This means that to fix the first character would require generating about 32 (2 ^ 5) keys. Not many. But to fix the first two characters would require 32 ^ 2 = 1024 keys. Each additional character you want to fix makes the job 32 times harder. Therefore, getting even one key where the first 8 hash characters are "facebook" requires approx. 1 x 10^12 keys to be generated (that's 100,000,000,000). Facebook has a lot of computing power, so they could do this. This is not out of the reach of others, but would be expensive. I'm not sure a phisher would consider this the most cost-effective method of phishing. > Under the ballot, CAs have no obligation to scan or verify a > **meaningful** .onion domain and look for phishing or fraud attempts. Do they have such an obligation for normal domain names? If so, why does that obligation not extend to .onion names? > I > was under the impression that .onion domain names were ALWAYS 12 > random characters (which avoids fraud); now I see that people who want > a specific .onion name can arguably game the system to get a > meaningful name that they want (and it might not even be their own > name ? > gervmarkham1 for example). The longer the required "meaningful" portion is, the harder it is to find a name beginning with it. As I said, each extra character you want makes it 32 times harder. So getting an 8-character prefix ("facebook") requires approx. 1 x 10^12 keys to be generated. Getting an 11 character prefix ("gervmarkham") requires 3.6 x 10^16 - i.e. it's 32,678 times harder. 11 characters would have been out of the reach of even Facebook. > In contrast, a .onion domain name will be displayed to Tor users, and > could cause confusion. Should we require CAs to follow the rules of > BR 9.2.4g so that .onion domains that include meaningful names are > verified? Or better yet, not allow .onion domains to be meaningful > (require them to be random only)? I think the idea of requiring "randomness" would not be any better. Let's say we required Facebook to be: 5jdgiu3sn4j2lkqq.onion. It would be equally as easy for someone to generate a key matching the first 8 letters of this as it is for someone to generate one matching the word "facebook". So for the same effort as above, I could generate: 5jdgiu3sya3mldpz.onion I'm not convinced that a user is going to recognise the difference between those two better than the difference between two strings starting "facebook". This is fundamentally why the proposal is that onion names be EV only - because looking at the domain name is not a good way of determining the owner, whether it's random or mnemonic. Gerv 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
-------------- next part -------------- An HTML attachment was scrubbed... URL: From gerv at mozilla.org Fri Feb 13 16:45:16 2015 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 13 Feb 2015 16:45:16 +0000 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: References: <54DD1DED.4090105@mozilla.org> <54DD289E.8040304@mozilla.org> <54DDC98E.8020907@mozilla.org> Message-ID: <54DE2A1C.9050601@mozilla.org> On 13/02/15 16:28, kirk_hall at trendmicro.com wrote: > Thanks, Gerv ? but if it wasn?t too hard for Facebook to generate > multiple ?facebook? .onion domains (presumably using automated methods), > I?m not convinced it would be hard for hackers. I will again try and convince you that the laws of probability mean it would be extremely, extremely hard -> impossible. > And I?m still troubled > that the .onion plan allows multiple customers to obtain the same .onion > domain (meaning there could be multiple certs for the same .onion domain > that belong to different subjects). I don't think that's true, for any useful meaning of the term "allow". There is a level of "vanishingly unlikely" which we can equate to "impossible". If I wanted to get a cert for facebookcorewwwi.onion, I would need to generate approximately 2^80 certificates to have a reasonable chance of finding one with the right hash. 2^80 is: 120,892,581,961,463,000,000,000. That's approximately a million times the number of grains of sand in the world. Making some estimates, it would require Amazon to run all of their 2 million AWS machines generating only keypairs for a thousand years. So it's possible that if I just start generating certs, I might get one which matches, but it's vanishingly unlikely for any reasonable scenario, even if I have lots and lots of computers and lots and lots of money. > ? For some reason, regular TLD certs (like .com > certs) won?t work after Tor users go through the Tor blender. [Does > anyone know why that is the case?] Because unless CAs issue for .onion, the domain name in any certificate the site is able to obtain doesn't match the domain name they are using. > ? But for some reason, Internal Name .onion certs > **do** work for Tor users after they go through the Tor blender. [Does > anyone know why this is so?] Because the domain names match. > ? Tor does not want to apply for .onion as a TLD, and > does not want to be the registrar for .onion [Why not? That would solve > everything by making .onion a TLD, so all the current CA rules could > apply. It is not meaningful to have a "registrar" for a namespace where everyone picks their own name, at random, by generating a keypair. > ? The Tor process for assigning .onion domains does > not require domains to be unique. The laws of chance, as noted above, means that a collision is highly, highly, highly unlikely. > If two or more website owners receive the same .onion domain (either by > accident, or by design of some of the website owners who choose what > their .onion domain will be, like Facebook did), As noted in previous emails, it would require gargantuan computing power to obtain a cert which matched an existing cert. Gerv From tom at ritter.vg Fri Feb 13 16:52:43 2015 From: tom at ritter.vg (Tom Ritter) Date: Fri, 13 Feb 2015 10:52:43 -0600 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: References: <54DD1DED.4090105@mozilla.org> <54DD289E.8040304@mozilla.org> <54DDC98E.8020907@mozilla.org> Message-ID: Damn, Gerv replied before I could. I'll add a couple notes: On 13 February 2015 at 10:28, kirk_hall at trendmicro.com < kirk_hall at trendmicro.com> wrote: > * Tor does not want to apply for .onion as a TLD, and > does not want to be the registrar for .onion [Why not? That would solve > everything by making .onion a TLD, so all the current CA rules could > apply. And remember, website users are not looking for anonymity in their > certs - they want EV certs with their identity displayed prominently in the > browsers.] > Tor will consider applying for .onion the next time the TLD rigamarole comes up. I don't believe you can just shoot off an application at this point, the process is closed until it is opened again, and no announcements on when that will be. (I could be wrong there, but that's my belief.) As Gerv said, it's strange and difficult to try and register for a generic term that you don't intend to actually process registrations for, that would not be publicly accessible. There was a big debate a few years ago I don't know the status of, but how would people feel if I wanted to register for [looks around the room, sees a picture frame] .frames and then never use it? Anyway, besides all that, the application fee is $180K and that doesn't include the cost in terms of manpower (internal and external) to apply. If anyone is willing to sponsor the costs of doing so for a non-profit, Tor will be happy to chat. > * The Tor process for assigning .onion domains does > not require domains to be unique. > Technically, no. The math makes it diminishingly small, but just on the verge of attackable. It's weak. We know. We're working on fixing it. I would say; however, that while the Tor process for assigning .onion does not require domains to be unique - the CA issuance process can. These are going to be in Certificate Transparency logs, you can go look. -tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom at ritter.vg Fri Feb 13 16:55:20 2015 From: tom at ritter.vg (Tom Ritter) Date: Fri, 13 Feb 2015 10:55:20 -0600 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names In-Reply-To: <95e76d821df3405eb58dcb116081b82b@EX2.corp.digicert.com> References: <95e76d821df3405eb58dcb116081b82b@EX2.corp.digicert.com> Message-ID: I'll voice my support for this. =) -tom On 12 February 2015 at 20:26, Jeremy Rowley wrote: > DigiCert votes "Yes" > > > > From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On > Behalf Of Jeremy Rowley > Sent: Tuesday, February 10, 2015 11:39 AM > To: public at cabforum.org > Subject: [cabfpub] Ballot 144 - Validation rules for .onion names > > > > Here's the ballot with the two typos fixed: > > > > Applicants want a CA-signed .onion address for several reasons, including: > > - Powerful web platform features are restricted to secure > origins, which are currently not available to onion names (in part, because > of the lack of IANA registration). Permitting EV certs for onion names will > help provide a secure origin for the service, moving onion towards use of > powerful web platform features. > > - Currently, access to .onion names over https from a standard > browser results in the standard existing 'Invalid Certificate' warning. > Training users to click through security warnings lowers the value of these > warnings and will cause users to miss important security information. > Removing these warnings for the user, through use of a digital certificate, > will help users recognize and avoid real MITM attacks. > > - The public needs attribution of ownership of the .onion > address to differentiate onion services, including potential phishing > services. Because onion names are not easily recognizable strings, providing > the public with additional information about the operator has significant > security improvements, especially in regions where use of the incorrect name > could have lethal consequences. > > > > The following motion has been proposed by Jeremy Rowley of DigiCert and > endorsed by Ryan Sleevi of Google and Wayne Thayer of GoDaddy. > > > > --------------------- > > Motion Starts > > --------------------- > > > > 1) Amend Section 9.2.1 of the Baseline Requirements v. 1.2.3 as follows: > > 9.2.1 Subject Alternative Name Extension > > Certificate Field: extensions:subjectAltName > > Required/Optional: Required > > Contents: This 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. The CA MUST confirm that the > Applicant controls the Fully-Qualified Domain Name or IP address or has been > granted the right to use it by the Domain Name Registrant or IP address > assignee, as appropriate. > > > > Wildcard FQDNs are permitted. As of the Effective Date of these > Requirements, prior to the issuance of a Certificate with a > subjectAlternativeName extension or Subject commonName field containing a > Reserved IP Address or Internal Name, the CA SHALL notify the Applicant that > the use of such Certificates has been deprecated by the CA / Browser Forum > and that the practice will be eliminated by October 2016. Also as of the > Effective Date, the CA SHALL NOT issue a certificate with an Expiry Date > later than 1 November 2015 with a subjectAlternativeName extension or > Subject commonName field containing a Reserved IP Address or Internal Name. > Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose > subjectAlternativeName extension or Subject commonName field contains a > Reserved IP Address or Internal Name. Effective May 1, 2015, each CA SHALL > revoke all unexpired Certificates with an Internal Name using onion as the > right-most label in an entry in the subjectAltName Extension or commonName > field unless such Certificate was issued in accordance with Appendix F of > the EV Guidelines. > > > > 2) Amend Section 9.2.2 and 11.7.1 of the Guidelines for the Issuance and > Management of Extended Validation Certificates v1.5.2 as follows: > > > > 9.2.2. Subject Alternative Name Extension Certificate field: > subjectAltName:dNSName > > Required/Optional: Required > > Contents: This extension MUST contain one or more host Domain Name(s) owned > or controlled by the Subject and to be associated with the Subject's server. > Such server MAY be owned and operated by the Subject or another entity > (e.g., a hosting service). Wildcard certificates are not allowed for EV > Certificates except as permitted under Appendix F. > > > > 11.7 Verification of Applicant's Domain Name > > > > 11.7.1. Verification Requirements > > > > (1) For each Fully-Qualified Domain Name listed in a Certificate, other than > a Domain Name with .onion in the right-most label of the Domain Name, the CA > SHALL confirm that, as of the date the Certificate was issued, the Applicant > (or the Applicant's Parent Company, Subsidiary Company, or Affiliate, > collectively referred to as "Applicant" for the purposes of this section) > either is the Domain Name Registrant or has control over the FQDN using a > procedure specified in Section 11.1.1 of the Baseline Requirements, except > that a CA MAY NOT verify a domain using the procedure described 11.1.1(7). > For a Certificate issued to a Domain Name with .onion in the right-most > label of the Domain Name, the CA SHALL confirm that, as of the date the > Certificate was issued, the Applicant's control over the .onion Domain Name > in accordance with Appendix F. > > > > (2) Mixed Character Set Domain Names: EV Certificates MAY include Domain > Names containing mixed character sets only in compliance with the rules set > forth by the domain registrar. The CA MUST visually compare any Domain Names > with mixed character sets with known high risk domains. If a similarity is > found, then the EV Certificate Request MUST be flagged as High Risk. The CA > must perform reasonably appropriate additional authentication and > verification to be certain beyond reasonable doubt that the Applicant and > the target in question are the same organization. > > > > 3) Add a new Appendix F to the Guidelines for the Issuance and Management of > Extended Validation Certificates v1.5.2: > > > > Appendix F - Issuance of Certificates for .onion Domain Names > > > > A CA may issue an EV Certificate with .onion in the right-most label of the > Domain Name provided that issuance complies with the requirements set forth > in this Appendix: > > 1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) > > The CAB Forum has created an extension of the TBSCertificate for use in > conveying hashes of keys related to .onion addresses. The Tor Service > Descriptor Hash extension has the following format: > > > > cabf-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 } > > > > TorServiceDescriptorSyntax ::= > > SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash > > > > TorServiceDescriptorHash:: = SEQUENCE { > > onionURI UTF8String > > algorithm AlgorithmIdentifier > > subjectPublicKeyHash BIT STRING } > > > > Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 6234) > performed over the DER-encoding of an ASN.1 SubjectPublicKey of the .onion > service and SubjectPublicKeyHash is the hash output. > > > > 2. The CA MUST verify the Applicant's control over the .onion Domain > Name using one of the following: > > > > a. The CA MAY verify the Applicant's control over the .onion service by > posting a specific value at a well-known URL under RFC5785. > > > > b. The CA MAY verify the Applicant's control over the .onion service by > having the Applicant provide a Certificate Request signed using the .onion > public key if the Attributes section of the certificationRequestInfo > contains: > > > > (i) A caSigningNonce attribute that 1) contains a single value > with at least 64-bits of entropy, 2) is generated by the CA, and 3) > delivered to the Applicant through a Verified Method of Communication and > > (ii) An applicantSigningNonce attribute that 1) contains a single > value with at least 64-bits of entropy and 2) is generated by the Applicant. > > > > The signing nonce attributes have the following format: > > > > caSigningNonce ATTRIBUTE ::= { > > WITH SYNTAX OCTET STRING > > EQUALITY MATCHING RULE octetStringMatch > > SINGLE VALUE TRUE > > ID { > cabf-caSigningNonce } > > } > > > > cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } > > > > applicantSigningNonce ATTRIBUTE ::= { > > WITH SYNTAX OCTET STRING > > EQUALITY MATCHING RULE octetStringMatch > > SINGLE VALUE TRUE > > ID { > cabf-applicantSigningNonce } > > } > > > > cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 } > > > > 4. Each Certificate that includes a Domain Name where .onion is in the > right-most label of the Domain Name MUST conform to the requirements of > these Guidelines, including the content requirements in Section 9 and > Appendix B of the Baseline Requirements, except that the CA MAY include a > wildcard character in the Subject Alternative Name Extension and Subject > Common Name Field as the left-most character in the .onion Domain Name > provided inclusion of the wildcard character complies with Section 11.1.3 of > the Baseline Requirements. > > > > 5. CAs MUST NOT issue a Certificate that includes a Domain Name where > .onion is in the right-most label of the Domain Name with a validity period > longer than 15 months. Despite Section 9.2.1 of the Baseline Requirements > deprecating the use of Internal Names, a CA MAY issue a Certificate > containing an .onion name with an expiration date later than 1 November 2015 > after (and only if) .onion is officially recognized by the IESG as a > reserved TLD. > > > > 6. On or before May 1, 2015, each CA MUST revoke all Certificates issued > with the Subject Alternative Name extension or Common Name field that > includes a Domain Name where .onion is in the right-most label of the Domain > Name unless the Certificate was issued in compliance with this Appendix F. > > > > ---- > > Motion Ends > > ----- > > The review period for this ballot shall commence at 2200 UTC on Thursday, 4 > February 2015, and will close at 2200 UTC on Thursday, 11 February 2015. > Unless the motion is withdrawn during the review period, the voting period > will start immediately thereafter and will close at 2200 UTC on Monday, 18 > February 2015. Votes must be cast by posting an on-list reply to this > thread. > > A vote in favor of the motion must indicate a clear 'yes' in the response. A > vote against must indicate a clear 'no' in the response. A vote to abstain > must indicate a clear 'abstain' in the response. Unclear responses will not > be counted. The latest vote received from any representative of a voting > member before the close of the voting period will be counted. Voting members > are listed here: https://cabforum.org/members/ > > In order for the motion to be adopted, two thirds or more of the votes cast > by members in the CA category and greater than 50% of the votes cast by > members in the browser category must be in favor. Quorum is currently nine > (9) members- at least nine members must participate in the ballot, either by > voting in favor, voting against, or abstaining. > > > > > > > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public > From gerv at mozilla.org Fri Feb 13 17:08:41 2015 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 13 Feb 2015 17:08:41 +0000 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: References: <54DD1DED.4090105@mozilla.org> <54DD289E.8040304@mozilla.org> <54DDC98E.8020907@mozilla.org> Message-ID: <54DE2F99.9010004@mozilla.org> On 13/02/15 16:52, Tom Ritter wrote: > Tor will consider applying for .onion the next time the TLD rigamarole > comes up. I personally think the RFC reservation is a better, quicker and cheaper route than an ICANN application. > Technically, no. The math makes it diminishingly small, but just on the > verge of attackable. ...by an extremely well-resourced adversary? Was my maths in my email to Kirk correct? If so, that seems currently beyond attackable to me. But perhaps I missed something. Gerv From tom at ritter.vg Fri Feb 13 17:12:06 2015 From: tom at ritter.vg (Tom Ritter) Date: Fri, 13 Feb 2015 11:12:06 -0600 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: <54DE2F99.9010004@mozilla.org> References: <54DD1DED.4090105@mozilla.org> <54DD289E.8040304@mozilla.org> <54DDC98E.8020907@mozilla.org> <54DE2F99.9010004@mozilla.org> Message-ID: On 13 February 2015 at 11:08, Gervase Markham wrote: > On 13/02/15 16:52, Tom Ritter wrote: >> Tor will consider applying for .onion the next time the TLD rigamarole >> comes up. > > I personally think the RFC reservation is a better, quicker and cheaper > route than an ICANN application. > >> Technically, no. The math makes it diminishingly small, but just on the >> verge of attackable. > > ...by an extremely well-resourced adversary? Was my maths in my email to > Kirk correct? If so, that seems currently beyond attackable to me. But > perhaps I missed something. No, I think it is correct. And yes, a well-resourced adversary. I think I've seen estimates that the bitcoin network as a whole turns over 2^80 in some reasonable amount of time; government agencies; a very large botnet; someone at Google gets bored ;) -tom From gerv at mozilla.org Fri Feb 13 17:18:13 2015 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 13 Feb 2015 17:18:13 +0000 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: References: <54DD1DED.4090105@mozilla.org> <54DD289E.8040304@mozilla.org> <54DDC98E.8020907@mozilla.org> <54DE2F99.9010004@mozilla.org> Message-ID: <54DE31D5.5030306@mozilla.org> On 13/02/15 17:12, Tom Ritter wrote: > No, I think it is correct. And yes, a well-resourced adversary. I > think I've seen estimates that the bitcoin network as a whole turns > over 2^80 in some reasonable amount of time; government agencies; a > very large botnet; someone at Google gets bored ;) 2^80 CPU cycles, hashes, or keypair generations? I estimated keypair generation at 1000 cycles, but it could be more expensive than that. Gerv From TShirley at trustwave.com Fri Feb 13 17:24:54 2015 From: TShirley at trustwave.com (Tim Shirley) Date: Fri, 13 Feb 2015 17:24:54 +0000 Subject: [cabfpub] Domain Validation Revision In-Reply-To: References: Message-ID: <252D51A38EFF0D4B991378E55299BFD15F7AE1AF@SKYMB1.trustwave.com> While we're in this section, do we want to consider removing the "registrant" address from item 3 as one of the WHOIS options? I only mention it because Mozilla lists only the technical and administrative fields as acceptable options at https://wiki.mozilla.org/CA:Problematic_Practices#Email_Address_Prefixes_for_DV_Certs. Or was that simply an oversight on Mozilla's part? I realize specific browser programs can and do make their requirements more stringent than the Baseline Requirements, and that this is not even a requirement from Mozilla as of yet. But that page says discussion is underway to make it mandatory, and if indeed Mozilla does not consider the registrant field to be acceptable for validating domain control, then it might reduce potential confusion to include the same restriction here. Regards, Tim From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Thursday, February 12, 2015 9:55 PM To: CABFPub (public at cabforum.org) Subject: [cabfpub] Domain Validation Revision Attached is a draft proposal from the EV working group about revising the domain validation in the BRs. The intent is 1) to eliminate the "any other option" (as it made domain validation essentially meaningless, 2) tighten up the domain validation language, and 3) permit attorney/accountants to draft the domain authorization document. Note that revising this section will automatically revise domain validation in EV. Also note that this is a draft from the working group and not yet a proposed ballot. Jeremy ________________________________ This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom at ritter.vg Fri Feb 13 17:39:35 2015 From: tom at ritter.vg (Tom Ritter) Date: Fri, 13 Feb 2015 11:39:35 -0600 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: <54DE31D5.5030306@mozilla.org> References: <54DD1DED.4090105@mozilla.org> <54DD289E.8040304@mozilla.org> <54DDC98E.8020907@mozilla.org> <54DE2F99.9010004@mozilla.org> <54DE31D5.5030306@mozilla.org> Message-ID: On 13 February 2015 at 11:18, Gervase Markham wrote: > On 13/02/15 17:12, Tom Ritter wrote: >> No, I think it is correct. And yes, a well-resourced adversary. I >> think I've seen estimates that the bitcoin network as a whole turns >> over 2^80 in some reasonable amount of time; government agencies; a >> very large botnet; someone at Google gets bored ;) > > 2^80 CPU cycles, hashes, or keypair generations? I estimated keypair > generation at 1000 cycles, but it could be more expensive than that. Alright, let me do some handwaving and back-of-the-envelope calculations. Bitcoin network appears to be at about 300,000 Trillion hashes/second, and a hash is ~64 cycles, we'll use a key gen as 1000 cycles so a keypair is 15 times as difficult. (pow(2,80) * 15) / (300000 * pow(2,40)) / 3600 / 24 / 365.25 = 1.7412731006160165 years In another expression, the bitcoin network is at 4048030.71 petaflops, which was more than the top 500 public supercomputers in the world combined. Except that's not accurate because it was in 2013 when bitcoin was even smaller. [0] So if you controlled the entire bitcoin network (HAH!), and my back of the envelope handwaving is roughly correct, you could collide a .onion address in about a year, year and a half. If you were Google, and you had the _best_ super computer in the world, it would take you (4048030.71 * 1000) / 54902.4 = ~73,731 times longer[1]. So I came out to be a little more than Gerv (1,000 years vs my 73,000) but either way we're not talking something trivial. Like I said - this is much weaker than we want for our cryptosystems. But it's not so weak that it's practically exploitable today or in the next couple years. If we're still using it in 2 years I'll be very disappointed. And unlike the internet, it is actually much easier to upgrade the whole Tor network in a relative short timespan (6 months-year). -tom [0] http://www.forbes.com/sites/reuvencohen/2013/11/28/global-bitcoin-computing-power-now-256-times-faster-than-top-500-supercomputers-combined/ [1]http://www.top500.org/lists/2014/11/ From kirk_hall at trendmicro.com Fri Feb 13 17:51:28 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Fri, 13 Feb 2015 17:51:28 +0000 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: References: <54DD1DED.4090105@mozilla.org> <54DD289E.8040304@mozilla.org> <54DDC98E.8020907@mozilla.org> <54DE2F99.9010004@mozilla.org> <54DE31D5.5030306@mozilla.org> Message-ID: Terrific calculations, Tom -- but I'm wondering how hard it was for Facebook to get their multiple .onion domains that included "facebook". Yes, I'm concerned about the possibility of an exact clash, but I'm also concerned about the ability of a hacker to get a .onion domain that includes names commonly sought by hackers. Perhaps Tor limit final .onion domains to random letters and numbers using the same pattern scanning methods that CAs use. -----Original Message----- From: Tom Ritter [mailto:tom at ritter.vg] Sent: Friday, February 13, 2015 9:40 AM To: Gervase Markham Cc: Kirk Hall (RD-US); Jeremy Rowley (jeremy.rowley at digicert.com); Ben Wilson (Ben.Wilson at digicert.com); CABFPub (public at cabforum.org) Subject: Re: [cabfpub] Ballot 144 -.onion domains On 13 February 2015 at 11:18, Gervase Markham wrote: > On 13/02/15 17:12, Tom Ritter wrote: >> No, I think it is correct. And yes, a well-resourced adversary. I >> think I've seen estimates that the bitcoin network as a whole turns >> over 2^80 in some reasonable amount of time; government agencies; a >> very large botnet; someone at Google gets bored ;) > > 2^80 CPU cycles, hashes, or keypair generations? I estimated keypair > generation at 1000 cycles, but it could be more expensive than that. Alright, let me do some handwaving and back-of-the-envelope calculations. Bitcoin network appears to be at about 300,000 Trillion hashes/second, and a hash is ~64 cycles, we'll use a key gen as 1000 cycles so a keypair is 15 times as difficult. (pow(2,80) * 15) / (300000 * pow(2,40)) / 3600 / 24 / 365.25 = 1.7412731006160165 years In another expression, the bitcoin network is at 4048030.71 petaflops, which was more than the top 500 public supercomputers in the world combined. Except that's not accurate because it was in 2013 when bitcoin was even smaller. [0] So if you controlled the entire bitcoin network (HAH!), and my back of the envelope handwaving is roughly correct, you could collide a .onion address in about a year, year and a half. If you were Google, and you had the _best_ super computer in the world, it would take you (4048030.71 * 1000) / 54902.4 = ~73,731 times longer[1]. So I came out to be a little more than Gerv (1,000 years vs my 73,000) but either way we're not talking something trivial. Like I said - this is much weaker than we want for our cryptosystems. But it's not so weak that it's practically exploitable today or in the next couple years. If we're still using it in 2 years I'll be very disappointed. And unlike the internet, it is actually much easier to upgrade the whole Tor network in a relative short timespan (6 months-year). -tom [0] http://www.forbes.com/sites/reuvencohen/2013/11/28/global-bitcoin-computing-power-now-256-times-faster-than-top-500-supercomputers-combined/ [1]http://www.top500.org/lists/2014/11/ 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
From gerv at mozilla.org Fri Feb 13 17:58:00 2015 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 13 Feb 2015 17:58:00 +0000 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: References: <54DD1DED.4090105@mozilla.org> <54DD289E.8040304@mozilla.org> <54DDC98E.8020907@mozilla.org> <54DE2F99.9010004@mozilla.org> <54DE31D5.5030306@mozilla.org> Message-ID: <54DE3B28.5030109@mozilla.org> On 13/02/15 17:51, kirk_hall at trendmicro.com wrote: > Terrific calculations, Tom -- but I'm wondering how hard it was for > Facebook to get their multiple .onion domains that included > "facebook". > > Yes, I'm concerned about the possibility of an exact clash, but I'm > also concerned about the ability of a hacker to get a .onion domain > that includes names commonly sought by hackers. Insofar as this issue is in scope for the CAB Forum, why can't we solve it using exactly the same mechanisms we use to solve it for non-onion domain names? Gerv From wthayer at godaddy.com Fri Feb 13 18:03:12 2015 From: wthayer at godaddy.com (Wayne Thayer) Date: Fri, 13 Feb 2015 18:03:12 +0000 Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group In-Reply-To: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> References: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> Message-ID: GoDaddy votes Yes. Thanks, Wayne From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Wednesday, February 04, 2015 2:05 PM To: CABFPub Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group Ballot 143 - Formalization of validation working group ---- Reason ---- In order to address validation issues and inconsistencies in both the SSL Baseline Requirements and the EV Guidelines, the CAB Forum has held an informal working group previously referred to as the Extended Validation Working Group now known as the Validation Working Group, would like to modify its scope to include validation in the Baseline Requirements as well as the EV Guidelines. Jeremy Rowley of DigiCert made the following motion, which was endorsed by Rich Smith of Comodo and Kirk Hall of TrendMicro ---- Motion begins ---- The CA-Browser Forum formally establishes the Validation Working Group as an official working group of the CAB Forum, replacing the previous informal EV working group. The scope of this working group is to address issues arising under adopted CAB Forum standards related to the validation of certificate information and the inclusion of information in certificates. Scope: The Validation Working Group will consider all matters relating to the validation and inclusion of information in certificates under adopted CAB Forum guidelines. Deliverables: The Working Group shall produce one or more documents offering options to the Forum for validation within the scope defined above. ---- Motion Ends ---- The review period for this ballot shall commence at 2200 UTC on 5 Feb 2015, and will close at 2200 UTC on 11 Feb 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on 18 Feb 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: From douglas.beattie at globalsign.com Fri Feb 13 18:45:52 2015 From: douglas.beattie at globalsign.com (Doug Beattie) Date: Fri, 13 Feb 2015 18:45:52 +0000 Subject: [cabfpub] Domain Validation Revision In-Reply-To: References: Message-ID: > -----Original Message----- > From: public-bounces at cabforum.org [mailto:public- > bounces at cabforum.org] On Behalf Of Ryan Sleevi > Sent: Thursday, February 12, 2015 10:09 PM > To: Jeremy Rowley > Cc: CABFPub (public at cabforum.org) > Subject: Re: [cabfpub] Domain Validation Revision > > > 8 concerns me for a couple reasons, even though it's moving in the right > direction. > - You require HTTPS, but that seems overkill, when you only need to perform > a TLS handshake. That is, consider a mail server configured for SMTP-S - it > seems that would be a viable configuration Sure, we can change this to be just TLS handshake. > - It would seem that anyone that can get a port forwarded on a particular > address can now get a certificate on that address. For things like STUN-TCP > services, this seems quite bad! We might want to align this with the final approach regarding making a change on the web server at a well-known URI and/or list a small number of approved ports. We'll need to circle back on this later when the other updates are closer to consensus. > - The definition of "test certificate" is, from experience, a bit of a handwave > that varies from CA to CA. It would be nice to put some explicit technical > profile in place here (e.g. a critical poison extension, a requirement that EKUs > are present but not serverAuth/clientAuth, issued from a CA independent of > the issuing CA's 'trusted' hierarchy) that would prevent relying parties from > believing the test certificate is "real" Sure, we can define what we mean by a "test" certificate to cover these. Proposed new wording for item 8): Having the Applicant demonstrate practical control over the FQDN by the Applicant requesting and then installing a Test TLS Certificate issued by the CA on the FQDN which is accessed via a TLS handshake by the CA New Definition in section 4: Test TLS Certificate: A certificate which contains a poison extension, does not have serverAuth/clientAuth, is issued under a root not in browser public key stores, or similar such methods which would render a cert unusable for TLS server use. From kirk_hall at trendmicro.com Fri Feb 13 19:25:06 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Fri, 13 Feb 2015 19:25:06 +0000 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: <54DE3B28.5030109@mozilla.org> References: <54DD1DED.4090105@mozilla.org> <54DD289E.8040304@mozilla.org> <54DDC98E.8020907@mozilla.org> <54DE2F99.9010004@mozilla.org> <54DE31D5.5030306@mozilla.org> <54DE3B28.5030109@mozilla.org> Message-ID: Maybe you're right on that point, Gerv. One other question: Does Tor do revocation checking for .onion certs? I'm guessing not for privacy reasons... I know some browsers have given up some revocation checking (a mistake in my opinion), but if we know an application never checks for revocation as a matter of policy, that would concern me. There would be no way to remove a bad cert (used for fraud or abuse, or misissued to the wrong party) from the Tor system, even if the CA revokes it. -----Original Message----- From: Gervase Markham [mailto:gerv at mozilla.org] Sent: Friday, February 13, 2015 9:58 AM To: Kirk Hall (RD-US); Tom Ritter Cc: Jeremy Rowley (jeremy.rowley at digicert.com); Ben Wilson (Ben.Wilson at digicert.com); CABFPub (public at cabforum.org) Subject: Re: [cabfpub] Ballot 144 -.onion domains On 13/02/15 17:51, kirk_hall at trendmicro.com wrote: > Terrific calculations, Tom -- but I'm wondering how hard it was for > Facebook to get their multiple .onion domains that included > "facebook". > > Yes, I'm concerned about the possibility of an exact clash, but I'm > also concerned about the ability of a hacker to get a .onion domain > that includes names commonly sought by hackers. Insofar as this issue is in scope for the CAB Forum, why can't we solve it using exactly the same mechanisms we use to solve it for non-onion domain names? Gerv 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
From tom at ritter.vg Fri Feb 13 19:38:28 2015 From: tom at ritter.vg (Tom Ritter) Date: Fri, 13 Feb 2015 13:38:28 -0600 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: References: <54DD1DED.4090105@mozilla.org> <54DD289E.8040304@mozilla.org> <54DDC98E.8020907@mozilla.org> <54DE2F99.9010004@mozilla.org> <54DE31D5.5030306@mozilla.org> <54DE3B28.5030109@mozilla.org> Message-ID: On 13 February 2015 at 13:25, kirk_hall at trendmicro.com wrote: > Maybe you're right on that point, Gerv. > > One other question: Does Tor do revocation checking for .onion certs? I'm guessing not for privacy reasons... I know some browsers have given up some revocation checking (a mistake in my opinion), but if we know an application never checks for revocation as a matter of policy, that would concern me. There would be no way to remove a bad cert (used for fraud or abuse, or misissued to the wrong party) from the Tor system, even if the CA revokes it. I do not believe that Tor Browser edits Firefox's configuration for revocation. I expected to see something here: https://gitweb.torproject.org/tor-browser.git/tree/browser/app/profile/000-tor-browser.js?h=tor-browser-31.4.0esr-4.5-1 - but the absence and other bug reports I've seen make me believe it's left as the default. -tom From kirk_hall at trendmicro.com Fri Feb 13 19:42:46 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Fri, 13 Feb 2015 19:42:46 +0000 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: References: <54DD1DED.4090105@mozilla.org> <54DD289E.8040304@mozilla.org> <54DDC98E.8020907@mozilla.org> <54DE2F99.9010004@mozilla.org> <54DE31D5.5030306@mozilla.org> <54DE3B28.5030109@mozilla.org> Message-ID: I'm over my ski tips, but... wouldn't revocation checking (by the user's client) potentially reveal which websites the Tor user is viewing? -----Original Message----- From: Tom Ritter [mailto:tom at ritter.vg] Sent: Friday, February 13, 2015 11:38 AM To: Kirk Hall (RD-US) Cc: Gervase Markham; Jeremy Rowley (jeremy.rowley at digicert.com); Ben Wilson (Ben.Wilson at digicert.com); CABFPub (public at cabforum.org) Subject: Re: [cabfpub] Ballot 144 -.onion domains On 13 February 2015 at 13:25, kirk_hall at trendmicro.com wrote: > Maybe you're right on that point, Gerv. > > One other question: Does Tor do revocation checking for .onion certs? I'm guessing not for privacy reasons... I know some browsers have given up some revocation checking (a mistake in my opinion), but if we know an application never checks for revocation as a matter of policy, that would concern me. There would be no way to remove a bad cert (used for fraud or abuse, or misissued to the wrong party) from the Tor system, even if the CA revokes it. I do not believe that Tor Browser edits Firefox's configuration for revocation. I expected to see something here: https://gitweb.torproject.org/tor-browser.git/tree/browser/app/profile/000-tor-browser.js?h=tor-browser-31.4.0esr-4.5-1 - but the absence and other bug reports I've seen make me believe it's left as the default. -tom 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
From tom at ritter.vg Fri Feb 13 19:51:41 2015 From: tom at ritter.vg (Tom Ritter) Date: Fri, 13 Feb 2015 13:51:41 -0600 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: References: <54DD1DED.4090105@mozilla.org> <54DD289E.8040304@mozilla.org> <54DDC98E.8020907@mozilla.org> <54DE2F99.9010004@mozilla.org> <54DE31D5.5030306@mozilla.org> <54DE3B28.5030109@mozilla.org> Message-ID: On Feb 13, 2015 1:42 PM, "kirk_hall at trendmicro.com" < kirk_hall at trendmicro.com> wrote: > > I'm over my ski tips, but... wouldn't revocation checking (by the user's client) potentially reveal which websites the Tor user is viewing? To the CA? Yes. But you're not going to learn anything other than that a Tor user visited the site at that time. The exit IP is a Tor IP, and TorBrowser is designed to present a uniform presentation to prevent fingerprinting. I think they may even use a different circuit so the IP wouldn't even match the IP the website sees, but I'm not certain. -tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From douglas.beattie at globalsign.com Fri Feb 13 20:27:42 2015 From: douglas.beattie at globalsign.com (Doug Beattie) Date: Fri, 13 Feb 2015 20:27:42 +0000 Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group In-Reply-To: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> References: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> Message-ID: GlobalSign votes YES Doug From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Wednesday, February 4, 2015 4:05 PM To: CABFPub Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group Ballot 143 - Formalization of validation working group ---- Reason ---- In order to address validation issues and inconsistencies in both the SSL Baseline Requirements and the EV Guidelines, the CAB Forum has held an informal working group previously referred to as the Extended Validation Working Group now known as the Validation Working Group, would like to modify its scope to include validation in the Baseline Requirements as well as the EV Guidelines. Jeremy Rowley of DigiCert made the following motion, which was endorsed by Rich Smith of Comodo and Kirk Hall of TrendMicro ---- Motion begins ---- The CA-Browser Forum formally establishes the Validation Working Group as an official working group of the CAB Forum, replacing the previous informal EV working group. The scope of this working group is to address issues arising under adopted CAB Forum standards related to the validation of certificate information and the inclusion of information in certificates. Scope: The Validation Working Group will consider all matters relating to the validation and inclusion of information in certificates under adopted CAB Forum guidelines. Deliverables: The Working Group shall produce one or more documents offering options to the Forum for validation within the scope defined above. ---- Motion Ends ---- The review period for this ballot shall commence at 2200 UTC on 5 Feb 2015, and will close at 2200 UTC on 11 Feb 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on 18 Feb 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jodycl at microsoft.com Fri Feb 13 20:28:14 2015 From: jodycl at microsoft.com (Jody Cloutier) Date: Fri, 13 Feb 2015 20:28:14 +0000 Subject: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc In-Reply-To: <763539E260C37C46A0D6B340B5434C3B0ADAE0EB@AEX06.ejsarea.net> References: <763539E260C37C46A0D6B340B5434C3B0ACD81A9@AEX06.ejsarea.net> A <763539E260C37C46A0D6B340B5434C3B0ADAE0EB@AEX06.ejsarea.net> Message-ID: Thank you, Inigo, What seems to be happening is that organizations are applying the ETSI standard in cases in which either there is no National Standards Body, or where the national standards body does not certify the company. Building on the scenario below, Audit Co is not recognized by ISRAC, but Auditor Jones has a CISP certification, which I've already confirmed with ETSI is not sufficient. I think what would help here is to make the requirement much more specific: A Qualified Auditor is limited to an auditor that is employed by a company that is certified by a National Authority listed in either the Members or Associate Members link. This, much simplified language, seems to be what you are saying below, but the current language is such that Audit Co can argue that it can issue an ETSI audit because it's company is certified by another national authority that's not listed on the ETSI webpages anywhere. Jody From: i-barreira at izenpe.net [mailto:i-barreira at izenpe.net] Sent: Friday, February 13, 2015 12:16 AM To: Jody Cloutier; public at cabforum.org Subject: RE: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Dear Jody, I understand your concern because it?s not easy for you to manage all possible combinations regarding ETSI audits in different countries so will try to clarify your example. First of all, no AuditCo has to be member of ETSI, AuditCo can perform ETSI accredited audits without being member of ETSI, they only need to be accredited in their country as stated in Annex E requirements. So, For example, * Company A is a commercial CA that operates in Israel * Auditor Jones works for AuditCo, which is based in Israel * AuditCo is certified by some governmental agency as a qualified auditor IB--> AuditCo has to be accredited under its National Accreditation Body according to ISO 17021. In the case of Israel, to follow the example, in the associated members tab of the EA, you can find the Israeli accreditation body, called ISRAC. Then AuditCo should be listed there and meeting the requirements to perform ETSI audits according to the national scheme indicated by ISRAC * AuditCo is not an ETSI Member or Associate Member IB --> this is not necessary. No need to be an ETSI member to perform ETSI audits * Auditor Jones audits Company A using the ETSI 102042 standard, and Company A sends the auditor's attestation letter to Microsoft as evidence that Company A complied with the Program's requirements. IB--> this is perfectly valid if AuditCo is listed in ISRAC and is allowed to perform ETSI audits. Of course Auditor Jones has to be also accredited to perform these kind of audits, has to be "qualified", so it?s not only the company but also the auditor, but that?s an internal task of the AuditCo. Regarding of being member of not, this is voluntary, they can join ETSI or not and don?t think that solve the problem because joining ETSI does not mean that you?re "qualified" or "accredited" to perform an ETSI audit, it?s just indicate that you belong to a club for example. And of course, if company A needs an auditing company accredited in Israel and there?s none, they can look for in other countries. For example, in Spain there?s no accredited auditing bodies to perform ETSI audits listed in our NAB, called ENAC, so, we, Izenpe, had to look for another option. So, we contacted for the first 6 years with KPMG in the Netherlands, and the last 3, with TUV IT in Germany. And Izenpe has an accredited ETSI audits according to the, right now, German national scheme and we?re listed in Germany. We?ll debate this within ETSI ESI trying to find an easier solution. Regards I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 [Descripci?n: cid:image001.png at 01CE3152.B4804EB0] ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. De: Jody Cloutier [mailto:jodycl at microsoft.com] Enviado el: mi?rcoles, 11 de febrero de 2015 0:32 Para: Barreira Iglesias, I?igo; public at cabforum.org Asunto: RE: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Thank you, Inigo. I think the problem is that, under ETSI, it's difficult to discern what an "equivalent national scheme" is. This sets up the scenario in which an auditor is employed by an organization that is recognized somehow by the government, but is not affiliated with an ETSI member organization (http://www.european-accreditation.org/home ). Microsoft does not know whether or not this auditor is qualified or not. For example, * Company A is a commercial CA that operates in Israel * Auditor Jones works for AuditCo, which is based in Israel * AuditCo is certified by some governmental agency as a qualified auditor * AuditCo is not an ETSI Member or Associate Member * Auditor Jones audits Company A using the ETSI 102042 standard, and Company A sends the auditor's attestation letter to Microsoft as evidence that Company A complied with the Program's requirements. In this scenario, how does Microsoft know that Auditor Jones conducted a proper audit without expending significant resources to determine whether and according to what standard AuditCo and Auditor Jones was certified? Microsoft believes that it would be simpler if the requirements were that the Auditor must work for a company that is affiliated with an ETSI-approved member organization. If Company A needs an auditor and there is no qualified auditor in Israel, the company can use an auditor from a member organization via the cross-border conformity rules. Unless I am fundamentally misunderstanding the rules, the above is something that Microsoft is presently struggling with, and we'd like to try to make the rules easier to understand for potential partners and ourselves. Jody Cloutier Senior Security Program Manager Microsoft Trusted Root Certificate Program jody.cloutier at microsoft.com 425.443.8922 Operating Systems Group Global Risk and Compliance [https://brandtools.microsoft.com/Style%20Library/BT/Images/MicrosoftMasterLogo.png] From: i-barreira at izenpe.net [mailto:i-barreira at izenpe.net] Sent: Tuesday, February 10, 2015 3:09 AM To: Jody Cloutier; public at cabforum.org Subject: RE: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Hi Jody, Regarding your comment on ETSI audits, I have to say that the ETSI audits shall be performed by accredited auditors as mentioned in Annex E of the current ETSI TS 102 042. ETSI audits performed by not accredited auditors shall be considered invalid. Microsoft is accepting ETSI audits since the very beginning in its root program requirements indicating this requirement. ETSI is providing a list of accredited auditors as mere information because has to be maintained by every NAB (National Accreditation Body). It?s true that this has to be improved regarding the new regulation 910/2014 and the new ENs and will take some time, but at the moment, it?s clearly stated that the audits shall be performed by accredited auditors. Don?t hesitate in contacting me for any additional information or help. Sometimes I?ve received some emails from Tom or Kelvin asking for the qualification of some audits, so, as say, you can contact me regarding this issue. Regards I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 [Descripci?n: cid:image001.png at 01CE3152.B4804EB0] ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. De: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] En nombre de Jody Cloutier Enviado el: lunes, 09 de febrero de 2015 18:55 Para: CABFPub (public at cabforum.org) Asunto: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Microsoft comments on Section 17. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 19121 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 1181 bytes Desc: image002.png URL: From jodycl at microsoft.com Fri Feb 13 20:29:41 2015 From: jodycl at microsoft.com (Jody Cloutier) Date: Fri, 13 Feb 2015 20:29:41 +0000 Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group In-Reply-To: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> References: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> Message-ID: Microsoft votes yes., From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Wednesday, February 4, 2015 1:05 PM To: CABFPub Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group Ballot 143 - Formalization of validation working group ---- Reason ---- In order to address validation issues and inconsistencies in both the SSL Baseline Requirements and the EV Guidelines, the CAB Forum has held an informal working group previously referred to as the Extended Validation Working Group now known as the Validation Working Group, would like to modify its scope to include validation in the Baseline Requirements as well as the EV Guidelines. Jeremy Rowley of DigiCert made the following motion, which was endorsed by Rich Smith of Comodo and Kirk Hall of TrendMicro ---- Motion begins ---- The CA-Browser Forum formally establishes the Validation Working Group as an official working group of the CAB Forum, replacing the previous informal EV working group. The scope of this working group is to address issues arising under adopted CAB Forum standards related to the validation of certificate information and the inclusion of information in certificates. Scope: The Validation Working Group will consider all matters relating to the validation and inclusion of information in certificates under adopted CAB Forum guidelines. Deliverables: The Working Group shall produce one or more documents offering options to the Forum for validation within the scope defined above. ---- Motion Ends ---- The review period for this ballot shall commence at 2200 UTC on 5 Feb 2015, and will close at 2200 UTC on 11 Feb 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on 18 Feb 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.wilson at digicert.com Fri Feb 13 20:38:57 2015 From: ben.wilson at digicert.com (Ben Wilson) Date: Fri, 13 Feb 2015 20:38:57 +0000 Subject: [cabfpub] [cabfquest] Domain Validation Revision In-Reply-To: <54DE3BBE.9000203@eff.org> References: <54DE3BBE.9000203@eff.org> Message-ID: Forwarding from questions list. From: questions-bounces at cabforum.org [mailto:questions-bounces at cabforum.org] On Behalf Of Jacob Hoffman-Andrews Sent: Friday, February 13, 2015 11:01 AM To: questions at cabforum.org Subject: Re: [cabfquest] [cabfpub] Domain Validation Revision Following up from a thread on cabfpub: On 02/12/2015 07:08 PM, Ryan Sleevi wrote: 8 concerns me for a couple reasons, even though it's moving in the right direction. - You require HTTPS, but that seems overkill, when you only need to perform a TLS handshake. That is, consider a mail server configured for SMTP-S - it seems that would be a viable configuration Agreed. As a concrete example, the ACME spec under discussion at IETF proposes a challenge type called "Domain Validation with Server Name Indication," or DVSNI for short: http://www.ietf.org/id/draft-barnes-acme-01.txt. We believe that DVSNI allows us to offer a higher level of assurance than item (6), "making an agreed-upon change to information found on an online Web page," since some sites allow arbitrary file upload, either by intent or by accident. We're planning to use it for the Let's Encrypt CA for that reason, so we'd like to make sure that item (8) allows for DVSNI. For example, here is a version of item (8) that we think would work: Having the Applicant demonstrate practical control over the FQDN by providing a TLS service on a host found in DNS for the FQDN. The CA SHALL initiate a TLS connection with that host and verify that the response contains unique, unguessable information proposed by the CA, in a well-specified format. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4954 bytes Desc: not available URL: From md at ssc.lt Fri Feb 13 21:00:24 2015 From: md at ssc.lt (Moudrick M. Dadashov) Date: Fri, 13 Feb 2015 23:00:24 +0200 Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group In-Reply-To: <452C99D20750E74083DBA441FF932385E4162C54@SOTTEXCH10.corp.ad.entrust.com> References: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> <452C99D20750E74083DBA441FF932385E4162C54@SOTTEXCH10.corp.ad.entrust.com> Message-ID: <54DE65E8.20202@ssc.lt> SSC votes: "Yes". Thanks, M.D. On 2/13/2015 3:46 PM, Bruce Morton wrote: > > Entrust votes Yes. > > *From:* public-bounces at cabforum.org > [mailto:public-bounces at cabforum.org] *On Behalf Of *Jeremy Rowley > *Sent:* Wednesday, February 04, 2015 4:05 PM > *To:* CABFPub > *Subject:* [cabfpub] Ballot 143 - Formalization of Validation Working > Group > > Ballot 143 - Formalization of validation working group > > ---- > > Reason > > ---- > > In order to address validation issues and inconsistencies in both the > SSL Baseline Requirements and the EV Guidelines, the CAB Forum has > held an informal working group previously referred to as the Extended > Validation Working Group now known as the Validation Working Group, > would like to modify its scope to include validation in the Baseline > Requirements as well as the EV Guidelines. > > Jeremy Rowley of DigiCert made the following motion, which was > endorsed by Rich Smith of Comodo and Kirk Hall of TrendMicro > > ---- > > Motion begins > > ---- > > The CA-Browser Forum formally establishes the Validation Working Group > as an official working group of the CAB Forum, replacing the previous > informal EV working group. The scope of this working group is to > address issues arising under adopted CAB Forum standards related to > the validation of certificate information and the inclusion of > information in certificates. > > Scope: The Validation Working Group will consider all matters relating > to the validation and inclusion of information in certificates under > adopted CAB Forum guidelines. > > Deliverables: The Working Group shall produce one or more documents > offering options to the Forum for validation within the scope defined > above. > > ---- > > Motion Ends > > ---- > > The review period for this ballot shall commence at 2200 UTC on 5 Feb > 2015, and will close at 2200 UTC on 11 Feb 2015. Unless the motion is > withdrawn during the review period, the voting period will start > immediately thereafter and will close at 2200 UTC on 18 Feb 2015. > Votes must be cast by posting an on-list reply to this thread. > > A vote in favor of the motion must indicate a clear 'yes' in the > response. A vote against must indicate a clear 'no' in the response. A > vote to abstain must indicate a clear 'abstain' in the response. > Unclear responses will not be counted. The latest vote received from > any representative of a voting member before the close of the voting > period will be counted. Voting members are listed here: > https://cabforum.org/members/ > > In order for the motion to be adopted, two thirds or more of the votes > cast by members in the CA category and greater than 50% of the votes > cast by members in the browser category must be in favor. Quorum is > currently nine (9) members? at least nine members must participate in > the ballot, either by voting in favor, voting against, or abstaining. > > > > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3653 bytes Desc: S/MIME Cryptographic Signature URL: From eddy_nigg at startcom.org Fri Feb 13 21:10:53 2015 From: eddy_nigg at startcom.org (Eddy Nigg) Date: Fri, 13 Feb 2015 23:10:53 +0200 Subject: [cabfpub] Ballot 143 In-Reply-To: <68a8241d150c4bc6bd624e08988e44fa@EX2.corp.digicert.com> References: <68a8241d150c4bc6bd624e08988e44fa@EX2.corp.digicert.com> Message-ID: <54DE685D.2000500@startcom.org> There appears to be a mistake with ballot number 143 which was previously assigned to "Remove the operational existence requirement for Government Entities" and later "Formalization of validation working group". Jeremy I believe both were initiated by you? -- Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. XMPP: startcom at startcom.org Blog: Join the Revolution! Twitter: Follow Me -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4313 bytes Desc: S/MIME Cryptographic Signature URL: From Dean_Coclin at symantec.com Fri Feb 13 21:31:20 2015 From: Dean_Coclin at symantec.com (Dean Coclin) Date: Fri, 13 Feb 2015 13:31:20 -0800 Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group In-Reply-To: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> References: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> Message-ID: <14D026C7F297AD44AC82578DD818CDD038EF1EA29E@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> Symantec votes YES. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Wednesday, February 04, 2015 4:05 PM To: CABFPub Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group Ballot 143 - Formalization of validation working group ---- Reason ---- In order to address validation issues and inconsistencies in both the SSL Baseline Requirements and the EV Guidelines, the CAB Forum has held an informal working group previously referred to as the Extended Validation Working Group now known as the Validation Working Group, would like to modify its scope to include validation in the Baseline Requirements as well as the EV Guidelines. Jeremy Rowley of DigiCert made the following motion, which was endorsed by Rich Smith of Comodo and Kirk Hall of TrendMicro ---- Motion begins ---- The CA-Browser Forum formally establishes the Validation Working Group as an official working group of the CAB Forum, replacing the previous informal EV working group. The scope of this working group is to address issues arising under adopted CAB Forum standards related to the validation of certificate information and the inclusion of information in certificates. Scope: The Validation Working Group will consider all matters relating to the validation and inclusion of information in certificates under adopted CAB Forum guidelines. Deliverables: The Working Group shall produce one or more documents offering options to the Forum for validation within the scope defined above. ---- Motion Ends ---- The review period for this ballot shall commence at 2200 UTC on 5 Feb 2015, and will close at 2200 UTC on 11 Feb 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on 18 Feb 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6130 bytes Desc: not available URL: From eddy_nigg at startcom.org Fri Feb 13 21:47:34 2015 From: eddy_nigg at startcom.org (Eddy Nigg) Date: Fri, 13 Feb 2015 23:47:34 +0200 Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group In-Reply-To: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> References: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> Message-ID: <54DE70F6.1070706@startcom.org> On 02/04/2015 11:05 PM, Jeremy Rowley wrote: > > Ballot 143 - Formalization of validation working group > StartCom votes YES to this ballot. -- Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. XMPP: startcom at startcom.org Blog: Join the Revolution! Twitter: Follow Me -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4313 bytes Desc: S/MIME Cryptographic Signature URL: From Dean_Coclin at symantec.com Fri Feb 13 22:33:48 2015 From: Dean_Coclin at symantec.com (Dean Coclin) Date: Fri, 13 Feb 2015 14:33:48 -0800 Subject: [cabfpub] IPv6 support References: <14D026C7F297AD44AC82578DD818CDD038EEF0BA5B@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C01141460BD37468D1@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <14D026C7F297AD44AC82578DD818CDD038EEF0BFAD@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> Message-ID: <14D026C7F297AD44AC82578DD818CDD038EF1EA316@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> Ryan, As discussed on the last CA/B call, I was asked to poll the CASC members on their support of IPv6. The results are below. You'll probably realize after reading this that there isn't much actionable material here as many members are "scoping" or "waiting for info" without any concrete response dates. We'll keep this tally going and update as we get more info. Globalsign: Yes, can support Symantec: We don't support this today. We've received very little demand for it from customers, but we're in the process of scoping out the effort. Comodo: Yes, for CRL and OCSP Trend Micro: Yes GoDaddy: Waiting for info from network team Entrust: Yes for CRL and OCSP. Trustwave: We don't support this today. Just started scoping the effort. Not many requests for this Digicert: We currently do not support it. Our connectivity providers support it, and it could be done with CRLs and OCSP, but we'd need to look for any gotchas before pulling the trigger. We've only had a couple of customers ask whether we support it. Thanks, Dean -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6130 bytes Desc: not available URL: From kirk_hall at trendmicro.com Fri Feb 13 22:52:38 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Fri, 13 Feb 2015 22:52:38 +0000 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names Message-ID: Trend Micro abstains Kirk R. Hall Operations Director, Trust Services Trend Micro +1.503.753.3088 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
-------------- next part -------------- An HTML attachment was scrubbed... URL: From eddy_nigg at startcom.org Fri Feb 13 22:58:11 2015 From: eddy_nigg at startcom.org (Eddy Nigg) Date: Sat, 14 Feb 2015 00:58:11 +0200 Subject: [cabfpub] IPv6 support In-Reply-To: <14D026C7F297AD44AC82578DD818CDD038EF1EA316@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> References: <14D026C7F297AD44AC82578DD818CDD038EEF0BA5B@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C01141460BD37468D1@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <14D026C7F297AD44AC82578DD818CDD038EEF0BFAD@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> <14D026C7F297AD44AC82578DD818CDD038EF1EA316@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> Message-ID: <54DE8183.1060204@startcom.org> On 02/14/2015 12:33 AM, Dean Coclin wrote: > You'll probably realize after reading this that there isn't much > actionable material here as many members are "scoping" or "waiting for > info" without any concrete response dates. We'll keep this tally > going and update as we get more info. > > Globalsign: Yes, can support > > Symantec: We don't support this today. We've received very little > demand for it from customers, but we're in the process of scoping out > the effort. > > Comodo:Yes, for CRL and OCSP > > TrendMicro:Yes > GoDaddy: Waiting for info from network team > > Entrust:Yes for CRL and OCSP. > > Trustwave:We don't support this today. Just started scoping the > effort. Not many requests for this > > Digicert:We currently do not support it. Our connectivity providers > support it, and it could be done with CRLs and OCSP, but we'd need to > look for any gotchas before pulling the trigger. We've only had a > couple of customers ask whether we support it. > To add StartCom to the list, we could support it for almost everything, but we have some historical CRL distribution points that can't support IPv6 for now. It seems that OCSP would work, but CRLs not 100%. Same as with Digicert, demand for IPv6 has been so low that we haven't invested into it so far. -- Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. XMPP: startcom at startcom.org Blog: Join the Revolution! Twitter: Follow Me -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4313 bytes Desc: S/MIME Cryptographic Signature URL: From wthayer at godaddy.com Sat Feb 14 00:02:09 2015 From: wthayer at godaddy.com (Wayne Thayer) Date: Sat, 14 Feb 2015 00:02:09 +0000 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names In-Reply-To: References: Message-ID: GoDaddy votes Yes. Thanks, Wayne From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Tuesday, February 10, 2015 11:39 AM To: public at cabforum.org Subject: [cabfpub] Ballot 144 - Validation rules for .onion names Here's the ballot with the two typos fixed: Applicants want a CA-signed .onion address for several reasons, including: - Powerful web platform features are restricted to secure origins, which are currently not available to onion names (in part, because of the lack of IANA registration). Permitting EV certs for onion names will help provide a secure origin for the service, moving onion towards use of powerful web platform features. - Currently, access to .onion names over https from a standard browser results in the standard existing 'Invalid Certificate' warning. Training users to click through security warnings lowers the value of these warnings and will cause users to miss important security information. Removing these warnings for the user, through use of a digital certificate, will help users recognize and avoid real MITM attacks. - The public needs attribution of ownership of the .onion address to differentiate onion services, including potential phishing services. Because onion names are not easily recognizable strings, providing the public with additional information about the operator has significant security improvements, especially in regions where use of the incorrect name could have lethal consequences. The following motion has been proposed by Jeremy Rowley of DigiCert and endorsed by Ryan Sleevi of Google and Wayne Thayer of GoDaddy. --------------------- Motion Starts --------------------- 1) Amend Section 9.2.1 of the Baseline Requirements v. 1.2.3 as follows: 9.2.1 Subject Alternative Name Extension Certificate Field: extensions:subjectAltName Required/Optional: Required Contents: This 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. The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate. Wildcard FQDNs are permitted. As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name, the CA SHALL notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016. Also as of the Effective Date, the CA SHALL NOT issue a certificate with an Expiry Date later than 1 November 2015 with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name. Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Name. Effective May 1, 2015, each CA SHALL revoke all unexpired Certificates with an Internal Name using onion as the right-most label in an entry in the subjectAltName Extension or commonName field unless such Certificate was issued in accordance with Appendix F of the EV Guidelines. 2) Amend Section 9.2.2 and 11.7.1 of the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2 as follows: 9.2.2. Subject Alternative Name Extension Certificate field: subjectAltName:dNSName Required/Optional: Required Contents: This extension MUST contain one or more host Domain Name(s) owned or controlled by the Subject and to be associated with the Subject's server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). Wildcard certificates are not allowed for EV Certificates except as permitted under Appendix F. 11.7 Verification of Applicant's Domain Name 11.7.1. Verification Requirements (1) For each Fully-Qualified Domain Name listed in a Certificate, other than a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant (or the Applicant's Parent Company, Subsidiary Company, or Affiliate, collectively referred to as "Applicant" for the purposes of this section) either is the Domain Name Registrant or has control over the FQDN using a procedure specified in Section 11.1.1 of the Baseline Requirements, except that a CA MAY NOT verify a domain using the procedure described 11.1.1(7). For a Certificate issued to a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant's control over the .onion Domain Name in accordance with Appendix F. (2) Mixed Character Set Domain Names: EV Certificates MAY include Domain Names containing mixed character sets only in compliance with the rules set forth by the domain registrar. The CA MUST visually compare any Domain Names with mixed character sets with known high risk domains. If a similarity is found, then the EV Certificate Request MUST be flagged as High Risk. The CA must perform reasonably appropriate additional authentication and verification to be certain beyond reasonable doubt that the Applicant and the target in question are the same organization. 3) Add a new Appendix F to the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2: Appendix F - Issuance of Certificates for .onion Domain Names A CA may issue an EV Certificate with .onion in the right-most label of the Domain Name provided that issuance complies with the requirements set forth in this Appendix: 1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) The CAB Forum has created an extension of the TBSCertificate for use in conveying hashes of keys related to .onion addresses. The Tor Service Descriptor Hash extension has the following format: cabf-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 } TorServiceDescriptorSyntax ::= SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash TorServiceDescriptorHash:: = SEQUENCE { onionURI UTF8String algorithm AlgorithmIdentifier subjectPublicKeyHash BIT STRING } Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 6234) performed over the DER-encoding of an ASN.1 SubjectPublicKey of the .onion service and SubjectPublicKeyHash is the hash output. 2. The CA MUST verify the Applicant's control over the .onion Domain Name using one of the following: a. The CA MAY verify the Applicant's control over the .onion service by posting a specific value at a well-known URL under RFC5785. b. The CA MAY verify the Applicant's control over the .onion service by having the Applicant provide a Certificate Request signed using the .onion public key if the Attributes section of the certificationRequestInfo contains: (i) A caSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy, 2) is generated by the CA, and 3) delivered to the Applicant through a Verified Method of Communication and (ii) An applicantSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy and 2) is generated by the Applicant. The signing nonce attributes have the following format: caSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-caSigningNonce } } cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } applicantSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-applicantSigningNonce } } cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 } 4. Each Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name MUST conform to the requirements of these Guidelines, including the content requirements in Section 9 and Appendix B of the Baseline Requirements, except that the CA MAY include a wildcard character in the Subject Alternative Name Extension and Subject Common Name Field as the left-most character in the .onion Domain Name provided inclusion of the wildcard character complies with Section 11.1.3 of the Baseline Requirements. 5. CAs MUST NOT issue a Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name with a validity period longer than 15 months. Despite Section 9.2.1 of the Baseline Requirements deprecating the use of Internal Names, a CA MAY issue a Certificate containing an .onion name with an expiration date later than 1 November 2015 after (and only if) .onion is officially recognized by the IESG as a reserved TLD. 6. On or before May 1, 2015, each CA MUST revoke all Certificates issued with the Subject Alternative Name extension or Common Name field that includes a Domain Name where .onion is in the right-most label of the Domain Name unless the Certificate was issued in compliance with this Appendix F. ---- Motion Ends ----- The review period for this ballot shall commence at 2200 UTC on Thursday, 4 February 2015, and will close at 2200 UTC on Thursday, 11 February 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on Monday, 18 February 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Patrick.Tronnier at oati.net Sat Feb 14 03:53:43 2015 From: Patrick.Tronnier at oati.net (Patrick Tronnier) Date: Sat, 14 Feb 2015 03:53:43 +0000 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names In-Reply-To: <5c04557077cf4564979bc37e501297de@EX2.corp.digicert.com> References: , <5c04557077cf4564979bc37e501297de@EX2.corp.digicert.com> Message-ID: <4F1C24C0-B730-495E-AE84-098FC341323E@oati.net> OATI abstains. Thanks, With kind regards, Patrick Tronnier Principal Security Architect & Sr. Director of Quality Assurance Phone: 763.201.2000 Fax: 763.201.5333 Direct Line: 763.201.2052 Open Access Technology International, Inc. 3660 Technology Drive NE, Minneapolis, MN 55418 CONFIDENTIAL INFORMATION: This email and any attachment(s) contain confidential and/or proprietary information of Open Access Technology International, Inc. Do not copy or distribute without the prior written consent of OATI. If you are not a named recipient to the message, please notify the sender immediately and do not retain the message in any form, printed or electronic. On Feb 10, 2015, at 3:03 PM, Ben Wilson > wrote: I?ll post this to the public page with a correction stating that the review period ends and the voting period of the ballot begins to run from Wednesday, 11 Feb., to Wednesday, 18 Feb. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Tuesday, February 10, 2015 11:39 AM To: public at cabforum.org Subject: [cabfpub] Ballot 144 - Validation rules for .onion names Here?s the ballot with the two typos fixed: Applicants want a CA-signed .onion address for several reasons, including: - Powerful web platform features are restricted to secure origins, which are currently not available to onion names (in part, because of the lack of IANA registration). Permitting EV certs for onion names will help provide a secure origin for the service, moving onion towards use of powerful web platform features. - Currently, access to .onion names over https from a standard browser results in the standard existing 'Invalid Certificate' warning. Training users to click through security warnings lowers the value of these warnings and will cause users to miss important security information. Removing these warnings for the user, through use of a digital certificate, will help users recognize and avoid real MITM attacks. - The public needs attribution of ownership of the .onion address to differentiate onion services, including potential phishing services. Because onion names are not easily recognizable strings, providing the public with additional information about the operator has significant security improvements, especially in regions where use of the incorrect name could have lethal consequences. The following motion has been proposed by Jeremy Rowley of DigiCert and endorsed by Ryan Sleevi of Google and Wayne Thayer of GoDaddy. --------------------- Motion Starts --------------------- 1) Amend Section 9.2.1 of the Baseline Requirements v. 1.2.3 as follows: 9.2.1 Subject Alternative Name Extension Certificate Field: extensions:subjectAltName Required/Optional: Required Contents: This 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. The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate. Wildcard FQDNs are permitted. As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name, the CA SHALL notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016. Also as of the Effective Date, the CA SHALL NOT issue a certificate with an Expiry Date later than 1 November 2015 with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name. Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Name. Effective May 1, 2015, each CA SHALL revoke all unexpired Certificates with an Internal Name using onion as the right-most label in an entry in the subjectAltName Extension or commonName field unless such Certificate was issued in accordance with Appendix F of the EV Guidelines. 2) Amend Section 9.2.2 and 11.7.1 of the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2 as follows: 9.2.2. Subject Alternative Name Extension Certificate field: subjectAltName:dNSName Required/Optional: Required Contents: This extension MUST contain one or more host Domain Name(s) owned or controlled by the Subject and to be associated with the Subject?s server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). Wildcard certificates are not allowed for EV Certificates except as permitted under Appendix F. 11.7 Verification of Applicant?s Domain Name 11.7.1. Verification Requirements (1) For each Fully-Qualified Domain Name listed in a Certificate, other than a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant (or the Applicant?s Parent Company, Subsidiary Company, or Affiliate, collectively referred to as ?Applicant? for the purposes of this section) either is the Domain Name Registrant or has control over the FQDN using a procedure specified in Section 11.1.1 of the Baseline Requirements, except that a CA MAY NOT verify a domain using the procedure described 11.1.1(7). For a Certificate issued to a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant?s control over the .onion Domain Name in accordance with Appendix F. (2) Mixed Character Set Domain Names: EV Certificates MAY include Domain Names containing mixed character sets only in compliance with the rules set forth by the domain registrar. The CA MUST visually compare any Domain Names with mixed character sets with known high risk domains. If a similarity is found, then the EV Certificate Request MUST be flagged as High Risk. The CA must perform reasonably appropriate additional authentication and verification to be certain beyond reasonable doubt that the Applicant and the target in question are the same organization. 3) Add a new Appendix F to the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2: Appendix F ? Issuance of Certificates for .onion Domain Names A CA may issue an EV Certificate with .onion in the right-most label of the Domain Name provided that issuance complies with the requirements set forth in this Appendix: 1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) The CAB Forum has created an extension of the TBSCertificate for use in conveying hashes of keys related to .onion addresses. The Tor Service Descriptor Hash extension has the following format: cabf-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 } TorServiceDescriptorSyntax ::= SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash TorServiceDescriptorHash:: = SEQUENCE { onionURI UTF8String algorithm AlgorithmIdentifier subjectPublicKeyHash BIT STRING } Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 6234) performed over the DER-encoding of an ASN.1 SubjectPublicKey of the .onion service and SubjectPublicKeyHash is the hash output. 2. The CA MUST verify the Applicant?s control over the .onion Domain Name using one of the following: a. The CA MAY verify the Applicant?s control over the .onion service by posting a specific value at a well-known URL under RFC5785. b. The CA MAY verify the Applicant?s control over the .onion service by having the Applicant provide a Certificate Request signed using the .onion public key if the Attributes section of the certificationRequestInfo contains: (i) A caSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy, 2) is generated by the CA, and 3) delivered to the Applicant through a Verified Method of Communication and (ii) An applicantSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy and 2) is generated by the Applicant. The signing nonce attributes have the following format: caSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-caSigningNonce } } cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } applicantSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-applicantSigningNonce } } cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 } 4. Each Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name MUST conform to the requirements of these Guidelines, including the content requirements in Section 9 and Appendix B of the Baseline Requirements, except that the CA MAY include a wildcard character in the Subject Alternative Name Extension and Subject Common Name Field as the left-most character in the .onion Domain Name provided inclusion of the wildcard character complies with Section 11.1.3 of the Baseline Requirements. 5. CAs MUST NOT issue a Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name with a validity period longer than 15 months. Despite Section 9.2.1 of the Baseline Requirements deprecating the use of Internal Names, a CA MAY issue a Certificate containing an .onion name with an expiration date later than 1 November 2015 after (and only if) .onion is officially recognized by the IESG as a reserved TLD. 6. On or before May 1, 2015, each CA MUST revoke all Certificates issued with the Subject Alternative Name extension or Common Name field that includes a Domain Name where .onion is in the right-most label of the Domain Name unless the Certificate was issued in compliance with this Appendix F. ---- Motion Ends ----- The review period for this ballot shall commence at 2200 UTC on Thursday, 4 February 2015, and will close at 2200 UTC on Thursday, 11 February 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on Monday, 18 February 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members? at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. _______________________________________________ Public mailing list Public at cabforum.org https://cabforum.org/mailman/listinfo/public From richard at wosign.com Sat Feb 14 03:52:38 2015 From: richard at wosign.com (Richard Wang) Date: Sat, 14 Feb 2015 03:52:38 +0000 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names In-Reply-To: References: Message-ID: <84AFFBBCB7046F44B89AAD7AC09C4A06153353E5@ex2.corp.wosign.com> WoSign vote ?abstains? Best Regards, Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5075 bytes Desc: not available URL: From richard at wosign.com Sat Feb 14 03:53:37 2015 From: richard at wosign.com (Richard Wang) Date: Sat, 14 Feb 2015 03:53:37 +0000 Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group In-Reply-To: <54DE70F6.1070706@startcom.org> References: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> <54DE70F6.1070706@startcom.org> Message-ID: <84AFFBBCB7046F44B89AAD7AC09C4A0615335403@ex2.corp.wosign.com> WoSign votes YES Best Regards, Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5075 bytes Desc: not available URL: From eddy_nigg at startcom.org Sun Feb 15 18:01:57 2015 From: eddy_nigg at startcom.org (Eddy Nigg) Date: Sun, 15 Feb 2015 20:01:57 +0200 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names In-Reply-To: References: Message-ID: <54E0DF15.6060006@startcom.org> StartCom abstains as well for now. On 02/14/2015 12:52 AM, kirk_hall at trendmicro.com wrote: > > Trend Micro abstains > > */Kirk R. Hall/* > > Operations Director, Trust Services > > Trend Micro > > +1.503.753.3088 > -- Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. XMPP: startcom at startcom.org Blog: Join the Revolution! Twitter: Follow Me -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4313 bytes Desc: S/MIME Cryptographic Signature URL: From Dean_Coclin at symantec.com Sun Feb 15 20:50:13 2015 From: Dean_Coclin at symantec.com (Dean Coclin) Date: Sun, 15 Feb 2015 12:50:13 -0800 Subject: [cabfpub] Minutes of recent CA/B Forum meetings Message-ID: <14D026C7F297AD44AC82578DD818CDD038EF1EA3EE@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> It occurred to me that I may not have sent to the public list the minutes from recent meetings. They can be found here: https://cabforum.org/2015/01/22/2015-01-22-minutes/ https://cabforum.org/2015/01/08/2015-01-08-minutes/ All previous meeting minutes are located here: https://cabforum.org/category/proceedings/minutes/ Dean Coclin CA/B Forum Chair -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6130 bytes Desc: not available URL: From Dean_Coclin at symantec.com Sun Feb 15 21:39:31 2015 From: Dean_Coclin at symantec.com (Dean Coclin) Date: Sun, 15 Feb 2015 13:39:31 -0800 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names In-Reply-To: References: Message-ID: <14D026C7F297AD44AC82578DD818CDD038EF1EA3F7@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> Symantec votes YES From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Tuesday, February 10, 2015 1:39 PM To: public at cabforum.org Subject: [cabfpub] Ballot 144 - Validation rules for .onion names Here's the ballot with the two typos fixed: Applicants want a CA-signed .onion address for several reasons, including: - Powerful web platform features are restricted to secure origins, which are currently not available to onion names (in part, because of the lack of IANA registration). Permitting EV certs for onion names will help provide a secure origin for the service, moving onion towards use of powerful web platform features. - Currently, access to .onion names over https from a standard browser results in the standard existing 'Invalid Certificate' warning. Training users to click through security warnings lowers the value of these warnings and will cause users to miss important security information. Removing these warnings for the user, through use of a digital certificate, will help users recognize and avoid real MITM attacks. - The public needs attribution of ownership of the .onion address to differentiate onion services, including potential phishing services. Because onion names are not easily recognizable strings, providing the public with additional information about the operator has significant security improvements, especially in regions where use of the incorrect name could have lethal consequences. The following motion has been proposed by Jeremy Rowley of DigiCert and endorsed by Ryan Sleevi of Google and Wayne Thayer of GoDaddy. --------------------- Motion Starts --------------------- 1) Amend Section 9.2.1 of the Baseline Requirements v. 1.2.3 as follows: 9.2.1 Subject Alternative Name Extension Certificate Field: extensions:subjectAltName Required/Optional: Required Contents: This 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. The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate. Wildcard FQDNs are permitted. As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name, the CA SHALL notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016. Also as of the Effective Date, the CA SHALL NOT issue a certificate with an Expiry Date later than 1 November 2015 with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name. Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Name. Effective May 1, 2015, each CA SHALL revoke all unexpired Certificates with an Internal Name using onion as the right-most label in an entry in the subjectAltName Extension or commonName field unless such Certificate was issued in accordance with Appendix F of the EV Guidelines. 2) Amend Section 9.2.2 and 11.7.1 of the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2 as follows: 9.2.2. Subject Alternative Name Extension Certificate field: subjectAltName:dNSName Required/Optional: Required Contents: This extension MUST contain one or more host Domain Name(s) owned or controlled by the Subject and to be associated with the Subject's server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). Wildcard certificates are not allowed for EV Certificates except as permitted under Appendix F. 11.7 Verification of Applicant's Domain Name 11.7.1. Verification Requirements (1) For each Fully-Qualified Domain Name listed in a Certificate, other than a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant (or the Applicant's Parent Company, Subsidiary Company, or Affiliate, collectively referred to as "Applicant" for the purposes of this section) either is the Domain Name Registrant or has control over the FQDN using a procedure specified in Section 11.1.1 of the Baseline Requirements, except that a CA MAY NOT verify a domain using the procedure described 11.1.1(7). For a Certificate issued to a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant's control over the .onion Domain Name in accordance with Appendix F. (2) Mixed Character Set Domain Names: EV Certificates MAY include Domain Names containing mixed character sets only in compliance with the rules set forth by the domain registrar. The CA MUST visually compare any Domain Names with mixed character sets with known high risk domains. If a similarity is found, then the EV Certificate Request MUST be flagged as High Risk. The CA must perform reasonably appropriate additional authentication and verification to be certain beyond reasonable doubt that the Applicant and the target in question are the same organization. 3) Add a new Appendix F to the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2: Appendix F - Issuance of Certificates for .onion Domain Names A CA may issue an EV Certificate with .onion in the right-most label of the Domain Name provided that issuance complies with the requirements set forth in this Appendix: 1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) The CAB Forum has created an extension of the TBSCertificate for use in conveying hashes of keys related to .onion addresses. The Tor Service Descriptor Hash extension has the following format: cabf-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 } TorServiceDescriptorSyntax ::= SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash TorServiceDescriptorHash:: = SEQUENCE { onionURI UTF8String algorithm AlgorithmIdentifier subjectPublicKeyHash BIT STRING } Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 6234) performed over the DER-encoding of an ASN.1 SubjectPublicKey of the .onion service and SubjectPublicKeyHash is the hash output. 2. The CA MUST verify the Applicant's control over the .onion Domain Name using one of the following: a. The CA MAY verify the Applicant's control over the .onion service by posting a specific value at a well-known URL under RFC5785. b. The CA MAY verify the Applicant's control over the .onion service by having the Applicant provide a Certificate Request signed using the .onion public key if the Attributes section of the certificationRequestInfo contains: (i) A caSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy, 2) is generated by the CA, and 3) delivered to the Applicant through a Verified Method of Communication and (ii) An applicantSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy and 2) is generated by the Applicant. The signing nonce attributes have the following format: caSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-caSigningNonce } } cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } applicantSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-applicantSigningNonce } } cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 } 4. Each Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name MUST conform to the requirements of these Guidelines, including the content requirements in Section 9 and Appendix B of the Baseline Requirements, except that the CA MAY include a wildcard character in the Subject Alternative Name Extension and Subject Common Name Field as the left-most character in the .onion Domain Name provided inclusion of the wildcard character complies with Section 11.1.3 of the Baseline Requirements. 5. CAs MUST NOT issue a Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name with a validity period longer than 15 months. Despite Section 9.2.1 of the Baseline Requirements deprecating the use of Internal Names, a CA MAY issue a Certificate containing an .onion name with an expiration date later than 1 November 2015 after (and only if) .onion is officially recognized by the IESG as a reserved TLD. 6. On or before May 1, 2015, each CA MUST revoke all Certificates issued with the Subject Alternative Name extension or Common Name field that includes a Domain Name where .onion is in the right-most label of the Domain Name unless the Certificate was issued in compliance with this Appendix F. ---- Motion Ends ----- The review period for this ballot shall commence at 2200 UTC on Thursday, 4 February 2015, and will close at 2200 UTC on Thursday, 11 February 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on Monday, 18 February 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6130 bytes Desc: not available URL: From sleevi at google.com Mon Feb 16 00:44:08 2015 From: sleevi at google.com (Ryan Sleevi) Date: Sun, 15 Feb 2015 16:44:08 -0800 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names In-Reply-To: <14D026C7F297AD44AC82578DD818CDD038EF1EA3F7@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> References: <14D026C7F297AD44AC82578DD818CDD038EF1EA3F7@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> Message-ID: Google votes YES. On Sun, Feb 15, 2015 at 1:39 PM, Dean Coclin wrote: > Symantec votes YES > > > > From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On > Behalf Of Jeremy Rowley > Sent: Tuesday, February 10, 2015 1:39 PM > To: public at cabforum.org > Subject: [cabfpub] Ballot 144 - Validation rules for .onion names > > > > Here?s the ballot with the two typos fixed: > > > > Applicants want a CA-signed .onion address for several reasons, including: > > - Powerful web platform features are restricted to secure > origins, which are currently not available to onion names (in part, because > of the lack of IANA registration). Permitting EV certs for onion names will > help provide a secure origin for the service, moving onion towards use of > powerful web platform features. > > - Currently, access to .onion names over https from a standard > browser results in the standard existing 'Invalid Certificate' warning. > Training users to click through security warnings lowers the value of these > warnings and will cause users to miss important security information. > Removing these warnings for the user, through use of a digital certificate, > will help users recognize and avoid real MITM attacks. > > - The public needs attribution of ownership of the .onion > address to differentiate onion services, including potential phishing > services. Because onion names are not easily recognizable strings, providing > the public with additional information about the operator has significant > security improvements, especially in regions where use of the incorrect name > could have lethal consequences. > > > > The following motion has been proposed by Jeremy Rowley of DigiCert and > endorsed by Ryan Sleevi of Google and Wayne Thayer of GoDaddy. > > > > --------------------- > > Motion Starts > > --------------------- > > > > 1) Amend Section 9.2.1 of the Baseline Requirements v. 1.2.3 as follows: > > 9.2.1 Subject Alternative Name Extension > > Certificate Field: extensions:subjectAltName > > Required/Optional: Required > > Contents: This 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. The CA MUST confirm that the > Applicant controls the Fully-Qualified Domain Name or IP address or has been > granted the right to use it by the Domain Name Registrant or IP address > assignee, as appropriate. > > > > Wildcard FQDNs are permitted. As of the Effective Date of these > Requirements, prior to the issuance of a Certificate with a > subjectAlternativeName extension or Subject commonName field containing a > Reserved IP Address or Internal Name, the CA SHALL notify the Applicant that > the use of such Certificates has been deprecated by the CA / Browser Forum > and that the practice will be eliminated by October 2016. Also as of the > Effective Date, the CA SHALL NOT issue a certificate with an Expiry Date > later than 1 November 2015 with a subjectAlternativeName extension or > Subject commonName field containing a Reserved IP Address or Internal Name. > Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose > subjectAlternativeName extension or Subject commonName field contains a > Reserved IP Address or Internal Name. Effective May 1, 2015, each CA SHALL > revoke all unexpired Certificates with an Internal Name using onion as the > right-most label in an entry in the subjectAltName Extension or commonName > field unless such Certificate was issued in accordance with Appendix F of > the EV Guidelines. > > > > 2) Amend Section 9.2.2 and 11.7.1 of the Guidelines for the Issuance and > Management of Extended Validation Certificates v1.5.2 as follows: > > > > 9.2.2. Subject Alternative Name Extension Certificate field: > subjectAltName:dNSName > > Required/Optional: Required > > Contents: This extension MUST contain one or more host Domain Name(s) owned > or controlled by the Subject and to be associated with the Subject?s server. > Such server MAY be owned and operated by the Subject or another entity > (e.g., a hosting service). Wildcard certificates are not allowed for EV > Certificates except as permitted under Appendix F. > > > > 11.7 Verification of Applicant?s Domain Name > > > > 11.7.1. Verification Requirements > > > > (1) For each Fully-Qualified Domain Name listed in a Certificate, other than > a Domain Name with .onion in the right-most label of the Domain Name, the CA > SHALL confirm that, as of the date the Certificate was issued, the Applicant > (or the Applicant?s Parent Company, Subsidiary Company, or Affiliate, > collectively referred to as ?Applicant? for the purposes of this section) > either is the Domain Name Registrant or has control over the FQDN using a > procedure specified in Section 11.1.1 of the Baseline Requirements, except > that a CA MAY NOT verify a domain using the procedure described 11.1.1(7). > For a Certificate issued to a Domain Name with .onion in the right-most > label of the Domain Name, the CA SHALL confirm that, as of the date the > Certificate was issued, the Applicant?s control over the .onion Domain Name > in accordance with Appendix F. > > > > (2) Mixed Character Set Domain Names: EV Certificates MAY include Domain > Names containing mixed character sets only in compliance with the rules set > forth by the domain registrar. The CA MUST visually compare any Domain Names > with mixed character sets with known high risk domains. If a similarity is > found, then the EV Certificate Request MUST be flagged as High Risk. The CA > must perform reasonably appropriate additional authentication and > verification to be certain beyond reasonable doubt that the Applicant and > the target in question are the same organization. > > > > 3) Add a new Appendix F to the Guidelines for the Issuance and Management of > Extended Validation Certificates v1.5.2: > > > > Appendix F ? Issuance of Certificates for .onion Domain Names > > > > A CA may issue an EV Certificate with .onion in the right-most label of the > Domain Name provided that issuance complies with the requirements set forth > in this Appendix: > > 1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) > > The CAB Forum has created an extension of the TBSCertificate for use in > conveying hashes of keys related to .onion addresses. The Tor Service > Descriptor Hash extension has the following format: > > > > cabf-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 } > > > > TorServiceDescriptorSyntax ::= > > SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash > > > > TorServiceDescriptorHash:: = SEQUENCE { > > onionURI UTF8String > > algorithm AlgorithmIdentifier > > subjectPublicKeyHash BIT STRING } > > > > Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 6234) > performed over the DER-encoding of an ASN.1 SubjectPublicKey of the .onion > service and SubjectPublicKeyHash is the hash output. > > > > 2. The CA MUST verify the Applicant?s control over the .onion Domain > Name using one of the following: > > > > a. The CA MAY verify the Applicant?s control over the .onion service by > posting a specific value at a well-known URL under RFC5785. > > > > b. The CA MAY verify the Applicant?s control over the .onion service by > having the Applicant provide a Certificate Request signed using the .onion > public key if the Attributes section of the certificationRequestInfo > contains: > > > > (i) A caSigningNonce attribute that 1) contains a single value > with at least 64-bits of entropy, 2) is generated by the CA, and 3) > delivered to the Applicant through a Verified Method of Communication and > > (ii) An applicantSigningNonce attribute that 1) contains a single > value with at least 64-bits of entropy and 2) is generated by the Applicant. > > > > The signing nonce attributes have the following format: > > > > caSigningNonce ATTRIBUTE ::= { > > WITH SYNTAX OCTET STRING > > EQUALITY MATCHING RULE octetStringMatch > > SINGLE VALUE TRUE > > ID { > cabf-caSigningNonce } > > } > > > > cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } > > > > applicantSigningNonce ATTRIBUTE ::= { > > WITH SYNTAX OCTET STRING > > EQUALITY MATCHING RULE octetStringMatch > > SINGLE VALUE TRUE > > ID { > cabf-applicantSigningNonce } > > } > > > > cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 } > > > > 4. Each Certificate that includes a Domain Name where .onion is in the > right-most label of the Domain Name MUST conform to the requirements of > these Guidelines, including the content requirements in Section 9 and > Appendix B of the Baseline Requirements, except that the CA MAY include a > wildcard character in the Subject Alternative Name Extension and Subject > Common Name Field as the left-most character in the .onion Domain Name > provided inclusion of the wildcard character complies with Section 11.1.3 of > the Baseline Requirements. > > > > 5. CAs MUST NOT issue a Certificate that includes a Domain Name where > .onion is in the right-most label of the Domain Name with a validity period > longer than 15 months. Despite Section 9.2.1 of the Baseline Requirements > deprecating the use of Internal Names, a CA MAY issue a Certificate > containing an .onion name with an expiration date later than 1 November 2015 > after (and only if) .onion is officially recognized by the IESG as a > reserved TLD. > > > > 6. On or before May 1, 2015, each CA MUST revoke all Certificates issued > with the Subject Alternative Name extension or Common Name field that > includes a Domain Name where .onion is in the right-most label of the Domain > Name unless the Certificate was issued in compliance with this Appendix F. > > > > ---- > > Motion Ends > > ----- > > The review period for this ballot shall commence at 2200 UTC on Thursday, 4 > February 2015, and will close at 2200 UTC on Thursday, 11 February 2015. > Unless the motion is withdrawn during the review period, the voting period > will start immediately thereafter and will close at 2200 UTC on Monday, 18 > February 2015. Votes must be cast by posting an on-list reply to this > thread. > > A vote in favor of the motion must indicate a clear 'yes' in the response. A > vote against must indicate a clear 'no' in the response. A vote to abstain > must indicate a clear 'abstain' in the response. Unclear responses will not > be counted. The latest vote received from any representative of a voting > member before the close of the voting period will be counted. Voting members > are listed here: https://cabforum.org/members/ > > In order for the motion to be adopted, two thirds or more of the votes cast > by members in the CA category and greater than 50% of the votes cast by > members in the browser category must be in favor. Quorum is currently nine > (9) members? at least nine members must participate in the ballot, either by > voting in favor, voting against, or abstaining. > > > > > > > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public > From sleevi at google.com Mon Feb 16 00:49:52 2015 From: sleevi at google.com (Ryan Sleevi) Date: Sun, 15 Feb 2015 16:49:52 -0800 Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group In-Reply-To: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> References: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> Message-ID: Jeremy, To confirm, will this newly-formalized WG be operated consistent with Section 5.3 of our Bylaws? Specifically: "With the approval of the Chair, Working Groups may establish separate list-servs, wikis, and web pages for their communications, but all such separate list-servs must be managed in the same fashion as the Public Mail List." The existing EV WG does not operate according to the above, so I'm wanting to know how this newly formalized group will be handled if the motion succeeds. Cheers, From jeremy.rowley at digicert.com Mon Feb 16 01:09:18 2015 From: jeremy.rowley at digicert.com (Jeremy Rowley) Date: Mon, 16 Feb 2015 01:09:18 +0000 Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group In-Reply-To: References: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> Message-ID: <4560f1b512db41a98c4ddb3198adad2d@EX2.corp.digicert.com> Yes - that is the plan. -----Original Message----- From: Ryan Sleevi [mailto:sleevi at google.com] Sent: Sunday, February 15, 2015 5:50 PM To: Jeremy Rowley Cc: CABFPub Subject: Re: [cabfpub] Ballot 143 - Formalization of Validation Working Group Jeremy, To confirm, will this newly-formalized WG be operated consistent with Section 5.3 of our Bylaws? Specifically: "With the approval of the Chair, Working Groups may establish separate list-servs, wikis, and web pages for their communications, but all such separate list-servs must be managed in the same fashion as the Public Mail List." The existing EV WG does not operate according to the above, so I'm wanting to know how this newly formalized group will be handled if the motion succeeds. Cheers, From sleevi at google.com Mon Feb 16 01:10:33 2015 From: sleevi at google.com (Ryan Sleevi) Date: Sun, 15 Feb 2015 17:10:33 -0800 Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group In-Reply-To: <4560f1b512db41a98c4ddb3198adad2d@EX2.corp.digicert.com> References: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> <4560f1b512db41a98c4ddb3198adad2d@EX2.corp.digicert.com> Message-ID: In that case, Google votes YES. On Sun, Feb 15, 2015 at 5:09 PM, Jeremy Rowley wrote: > Yes - that is the plan. > > -----Original Message----- > From: Ryan Sleevi [mailto:sleevi at google.com] > Sent: Sunday, February 15, 2015 5:50 PM > To: Jeremy Rowley > Cc: CABFPub > Subject: Re: [cabfpub] Ballot 143 - Formalization of Validation Working Group > > Jeremy, > > To confirm, will this newly-formalized WG be operated consistent with Section 5.3 of our Bylaws? Specifically: > > "With the approval of the Chair, Working Groups may establish separate list-servs, wikis, and web pages for their communications, but all such separate list-servs must be managed in the same fashion as the Public Mail List." > > The existing EV WG does not operate according to the above, so I'm wanting to know how this newly formalized group will be handled if the motion succeeds. > > Cheers, From i-barreira at izenpe.net Mon Feb 16 09:50:51 2015 From: i-barreira at izenpe.net (i-barreira at izenpe.net) Date: Mon, 16 Feb 2015 10:50:51 +0100 Subject: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc In-Reply-To: A References: <763539E260C37C46A0D6B340B5434C3B0ACD81A9@AEX06.ejsarea.net> A <763539E260C37C46A0D6B340B5434C3B0ADAE0EB@AEX06.ejsarea.net> A Message-ID: <763539E260C37C46A0D6B340B5434C3B0ADAE39F@AEX06.ejsarea.net> Jody, The auditor can be certified, can have a CISA, ISO27001 lead auditor, CISSP, etc. but does not entitled him to perform an ETSI audit. Of course is good to have, but is the auditing body that is allowed to perform an ETSI audit. And in their internal reqs they request their auditors to have those certifications or others. That has to be defined by the National Accreditation Body on the requirements to fulfill by the auditing body, in this case AuditCo. If AuditCo meets the requirements, then it can be incorporated in the list of its NAB and therefore perform ETSI audits if ETSI is one of the admitted ones (otherwise you can?t be on the list, of course). Once AuditCo is accredited in its NAB according to whatever national scheme able to performing ETSI audits, then you can hire them even if you?re not, as a CA, belonging to that country. Again, if we take Izenpe as a CA that wants to have an ETSI accredited audit (of course I can have ETSI audit but not accredited) then I have to look for Auditing bodies accredited in their countries (in Spain we don?t have), then I found that in Germany, TUV IT is accredited in its NAB according to the ISO standards requested and able to perform ETSI audits. And yes, it?s not easy, not for me as a CA and not for you as a RP. As said, we?re working on improving the language (the requisites are not so easy as it depends on every country). Hopefully I can provide some inputs for the F2F I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. De: Jody Cloutier [mailto:jodycl at microsoft.com] Enviado el: viernes, 13 de febrero de 2015 21:28 Para: Barreira Iglesias, I?igo; public at cabforum.org Asunto: RE: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Thank you, Inigo, What seems to be happening is that organizations are applying the ETSI standard in cases in which either there is no National Standards Body, or where the national standards body does not certify the company. Building on the scenario below, Audit Co is not recognized by ISRAC, but Auditor Jones has a CISP certification, which I've already confirmed with ETSI is not sufficient. I think what would help here is to make the requirement much more specific: A Qualified Auditor is limited to an auditor that is employed by a company that is certified by a National Authority listed in either the Members or Associate Members link. This, much simplified language, seems to be what you are saying below, but the current language is such that Audit Co can argue that it can issue an ETSI audit because it's company is certified by another national authority that's not listed on the ETSI webpages anywhere. Jody From: i-barreira at izenpe.net [mailto:i-barreira at izenpe.net] Sent: Friday, February 13, 2015 12:16 AM To: Jody Cloutier; public at cabforum.org Subject: RE: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Dear Jody, I understand your concern because it?s not easy for you to manage all possible combinations regarding ETSI audits in different countries so will try to clarify your example. First of all, no AuditCo has to be member of ETSI, AuditCo can perform ETSI accredited audits without being member of ETSI, they only need to be accredited in their country as stated in Annex E requirements. So, For example, ? Company A is a commercial CA that operates in Israel ? Auditor Jones works for AuditCo, which is based in Israel ? AuditCo is certified by some governmental agency as a qualified auditor IB? AuditCo has to be accredited under its National Accreditation Body according to ISO 17021. In the case of Israel, to follow the example, in the associated members tab of the EA, you can find the Israeli accreditation body, called ISRAC. Then AuditCo should be listed there and meeting the requirements to perform ETSI audits according to the national scheme indicated by ISRAC ? AuditCo is not an ETSI Member or Associate Member IB ? this is not necessary. No need to be an ETSI member to perform ETSI audits ? Auditor Jones audits Company A using the ETSI 102042 standard, and Company A sends the auditor's attestation letter to Microsoft as evidence that Company A complied with the Program's requirements. IB? this is perfectly valid if AuditCo is listed in ISRAC and is allowed to perform ETSI audits. Of course Auditor Jones has to be also accredited to perform these kind of audits, has to be "qualified", so it?s not only the company but also the auditor, but that?s an internal task of the AuditCo. Regarding of being member of not, this is voluntary, they can join ETSI or not and don?t think that solve the problem because joining ETSI does not mean that you?re "qualified" or "accredited" to perform an ETSI audit, it?s just indicate that you belong to a club for example. And of course, if company A needs an auditing company accredited in Israel and there?s none, they can look for in other countries. For example, in Spain there?s no accredited auditing bodies to perform ETSI audits listed in our NAB, called ENAC, so, we, Izenpe, had to look for another option. So, we contacted for the first 6 years with KPMG in the Netherlands, and the last 3, with TUV IT in Germany. And Izenpe has an accredited ETSI audits according to the, right now, German national scheme and we?re listed in Germany. We?ll debate this within ETSI ESI trying to find an easier solution. Regards I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. De: Jody Cloutier [mailto:jodycl at microsoft.com] Enviado el: mi?rcoles, 11 de febrero de 2015 0:32 Para: Barreira Iglesias, I?igo; public at cabforum.org Asunto: RE: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Thank you, Inigo. I think the problem is that, under ETSI, it's difficult to discern what an "equivalent national scheme" is. This sets up the scenario in which an auditor is employed by an organization that is recognized somehow by the government, but is not affiliated with an ETSI member organization (http://www.european-accreditation.org/home ). Microsoft does not know whether or not this auditor is qualified or not. For example, ? Company A is a commercial CA that operates in Israel ? Auditor Jones works for AuditCo, which is based in Israel ? AuditCo is certified by some governmental agency as a qualified auditor ? AuditCo is not an ETSI Member or Associate Member ? Auditor Jones audits Company A using the ETSI 102042 standard, and Company A sends the auditor's attestation letter to Microsoft as evidence that Company A complied with the Program's requirements. In this scenario, how does Microsoft know that Auditor Jones conducted a proper audit without expending significant resources to determine whether and according to what standard AuditCo and Auditor Jones was certified? Microsoft believes that it would be simpler if the requirements were that the Auditor must work for a company that is affiliated with an ETSI-approved member organization. If Company A needs an auditor and there is no qualified auditor in Israel, the company can use an auditor from a member organization via the cross-border conformity rules. Unless I am fundamentally misunderstanding the rules, the above is something that Microsoft is presently struggling with, and we'd like to try to make the rules easier to understand for potential partners and ourselves. Jody Cloutier Senior Security Program Manager Microsoft Trusted Root Certificate Program jody.cloutier at microsoft.com 425.443.8922 Operating Systems Group Global Risk and Compliance From: i-barreira at izenpe.net [mailto:i-barreira at izenpe.net] Sent: Tuesday, February 10, 2015 3:09 AM To: Jody Cloutier; public at cabforum.org Subject: RE: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Hi Jody, Regarding your comment on ETSI audits, I have to say that the ETSI audits shall be performed by accredited auditors as mentioned in Annex E of the current ETSI TS 102 042. ETSI audits performed by not accredited auditors shall be considered invalid. Microsoft is accepting ETSI audits since the very beginning in its root program requirements indicating this requirement. ETSI is providing a list of accredited auditors as mere information because has to be maintained by every NAB (National Accreditation Body). It?s true that this has to be improved regarding the new regulation 910/2014 and the new ENs and will take some time, but at the moment, it?s clearly stated that the audits shall be performed by accredited auditors. Don?t hesitate in contacting me for any additional information or help. Sometimes I?ve received some emails from Tom or Kelvin asking for the qualification of some audits, so, as say, you can contact me regarding this issue. Regards I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. De: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] En nombre de Jody Cloutier Enviado el: lunes, 09 de febrero de 2015 18:55 Para: CABFPub (public at cabforum.org) Asunto: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Microsoft comments on Section 17. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 19121 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 1181 bytes Desc: image002.png URL: From gerv at mozilla.org Mon Feb 16 11:02:35 2015 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 16 Feb 2015 11:02:35 +0000 Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group In-Reply-To: References: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> <4560f1b512db41a98c4ddb3198adad2d@EX2.corp.digicert.com> Message-ID: <54E1CE4B.8030800@mozilla.org> On 16/02/15 01:10, Ryan Sleevi wrote: > In that case, Google votes YES. Mozilla votes YES. Gerv From gerv at mozilla.org Mon Feb 16 11:02:56 2015 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 16 Feb 2015 11:02:56 +0000 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names In-Reply-To: References: Message-ID: <54E1CE60.9020304@mozilla.org> Mozilla votes YES. Gerv From Peter.Miskovic at disig.sk Mon Feb 16 16:32:27 2015 From: Peter.Miskovic at disig.sk (Miskovic Peter) Date: Mon, 16 Feb 2015 16:32:27 +0000 Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group In-Reply-To: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> References: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> Message-ID: <3bb806d9da2b4517bc1e0e0726d3cce2@DISIGEX.disig.local> Ballot 143 - Formalization of Validation Working Group: Disig votes "YES". Regards, Peter Miskovic From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Wednesday, February 04, 2015 10:05 PM To: CABFPub Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group Ballot 143 - Formalization of validation working group ---- Reason ---- In order to address validation issues and inconsistencies in both the SSL Baseline Requirements and the EV Guidelines, the CAB Forum has held an informal working group previously referred to as the Extended Validation Working Group now known as the Validation Working Group, would like to modify its scope to include validation in the Baseline Requirements as well as the EV Guidelines. Jeremy Rowley of DigiCert made the following motion, which was endorsed by Rich Smith of Comodo and Kirk Hall of TrendMicro ---- Motion begins ---- The CA-Browser Forum formally establishes the Validation Working Group as an official working group of the CAB Forum, replacing the previous informal EV working group. The scope of this working group is to address issues arising under adopted CAB Forum standards related to the validation of certificate information and the inclusion of information in certificates. Scope: The Validation Working Group will consider all matters relating to the validation and inclusion of information in certificates under adopted CAB Forum guidelines. Deliverables: The Working Group shall produce one or more documents offering options to the Forum for validation within the scope defined above. ---- Motion Ends ---- The review period for this ballot shall commence at 2200 UTC on 5 Feb 2015, and will close at 2200 UTC on 11 Feb 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on 18 Feb 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Peter.Miskovic at disig.sk Mon Feb 16 16:34:12 2015 From: Peter.Miskovic at disig.sk (Miskovic Peter) Date: Mon, 16 Feb 2015 16:34:12 +0000 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names In-Reply-To: References: Message-ID: <593c466c7fc34b4da114746b576d4396@DISIGEX.disig.local> Ballot 144 - Validation rules for .onion names: Disig abstains. Regards, Peter Miskovic From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Tuesday, February 10, 2015 7:39 PM To: public at cabforum.org Subject: [cabfpub] Ballot 144 - Validation rules for .onion names Here's the ballot with the two typos fixed: Applicants want a CA-signed .onion address for several reasons, including: - Powerful web platform features are restricted to secure origins, which are currently not available to onion names (in part, because of the lack of IANA registration). Permitting EV certs for onion names will help provide a secure origin for the service, moving onion towards use of powerful web platform features. - Currently, access to .onion names over https from a standard browser results in the standard existing 'Invalid Certificate' warning. Training users to click through security warnings lowers the value of these warnings and will cause users to miss important security information. Removing these warnings for the user, through use of a digital certificate, will help users recognize and avoid real MITM attacks. - The public needs attribution of ownership of the .onion address to differentiate onion services, including potential phishing services. Because onion names are not easily recognizable strings, providing the public with additional information about the operator has significant security improvements, especially in regions where use of the incorrect name could have lethal consequences. The following motion has been proposed by Jeremy Rowley of DigiCert and endorsed by Ryan Sleevi of Google and Wayne Thayer of GoDaddy. --------------------- Motion Starts --------------------- 1) Amend Section 9.2.1 of the Baseline Requirements v. 1.2.3 as follows: 9.2.1 Subject Alternative Name Extension Certificate Field: extensions:subjectAltName Required/Optional: Required Contents: This 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. The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate. Wildcard FQDNs are permitted. As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name, the CA SHALL notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016. Also as of the Effective Date, the CA SHALL NOT issue a certificate with an Expiry Date later than 1 November 2015 with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name. Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Name. Effective May 1, 2015, each CA SHALL revoke all unexpired Certificates with an Internal Name using onion as the right-most label in an entry in the subjectAltName Extension or commonName field unless such Certificate was issued in accordance with Appendix F of the EV Guidelines. 2) Amend Section 9.2.2 and 11.7.1 of the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2 as follows: 9.2.2. Subject Alternative Name Extension Certificate field: subjectAltName:dNSName Required/Optional: Required Contents: This extension MUST contain one or more host Domain Name(s) owned or controlled by the Subject and to be associated with the Subject's server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). Wildcard certificates are not allowed for EV Certificates except as permitted under Appendix F. 11.7 Verification of Applicant's Domain Name 11.7.1. Verification Requirements (1) For each Fully-Qualified Domain Name listed in a Certificate, other than a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant (or the Applicant's Parent Company, Subsidiary Company, or Affiliate, collectively referred to as "Applicant" for the purposes of this section) either is the Domain Name Registrant or has control over the FQDN using a procedure specified in Section 11.1.1 of the Baseline Requirements, except that a CA MAY NOT verify a domain using the procedure described 11.1.1(7). For a Certificate issued to a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant's control over the .onion Domain Name in accordance with Appendix F. (2) Mixed Character Set Domain Names: EV Certificates MAY include Domain Names containing mixed character sets only in compliance with the rules set forth by the domain registrar. The CA MUST visually compare any Domain Names with mixed character sets with known high risk domains. If a similarity is found, then the EV Certificate Request MUST be flagged as High Risk. The CA must perform reasonably appropriate additional authentication and verification to be certain beyond reasonable doubt that the Applicant and the target in question are the same organization. 3) Add a new Appendix F to the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2: Appendix F - Issuance of Certificates for .onion Domain Names A CA may issue an EV Certificate with .onion in the right-most label of the Domain Name provided that issuance complies with the requirements set forth in this Appendix: 1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) The CAB Forum has created an extension of the TBSCertificate for use in conveying hashes of keys related to .onion addresses. The Tor Service Descriptor Hash extension has the following format: cabf-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 } TorServiceDescriptorSyntax ::= SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash TorServiceDescriptorHash:: = SEQUENCE { onionURI UTF8String algorithm AlgorithmIdentifier subjectPublicKeyHash BIT STRING } Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 6234) performed over the DER-encoding of an ASN.1 SubjectPublicKey of the .onion service and SubjectPublicKeyHash is the hash output. 2. The CA MUST verify the Applicant's control over the .onion Domain Name using one of the following: a. The CA MAY verify the Applicant's control over the .onion service by posting a specific value at a well-known URL under RFC5785. b. The CA MAY verify the Applicant's control over the .onion service by having the Applicant provide a Certificate Request signed using the .onion public key if the Attributes section of the certificationRequestInfo contains: (i) A caSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy, 2) is generated by the CA, and 3) delivered to the Applicant through a Verified Method of Communication and (ii) An applicantSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy and 2) is generated by the Applicant. The signing nonce attributes have the following format: caSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-caSigningNonce } } cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } applicantSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-applicantSigningNonce } } cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 } 4. Each Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name MUST conform to the requirements of these Guidelines, including the content requirements in Section 9 and Appendix B of the Baseline Requirements, except that the CA MAY include a wildcard character in the Subject Alternative Name Extension and Subject Common Name Field as the left-most character in the .onion Domain Name provided inclusion of the wildcard character complies with Section 11.1.3 of the Baseline Requirements. 5. CAs MUST NOT issue a Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name with a validity period longer than 15 months. Despite Section 9.2.1 of the Baseline Requirements deprecating the use of Internal Names, a CA MAY issue a Certificate containing an .onion name with an expiration date later than 1 November 2015 after (and only if) .onion is officially recognized by the IESG as a reserved TLD. 6. On or before May 1, 2015, each CA MUST revoke all Certificates issued with the Subject Alternative Name extension or Common Name field that includes a Domain Name where .onion is in the right-most label of the Domain Name unless the Certificate was issued in compliance with this Appendix F. ---- Motion Ends ----- The review period for this ballot shall commence at 2200 UTC on Thursday, 4 February 2015, and will close at 2200 UTC on Thursday, 11 February 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on Monday, 18 February 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.wilson at digicert.com Mon Feb 16 16:56:37 2015 From: ben.wilson at digicert.com (Ben Wilson) Date: Mon, 16 Feb 2015 16:56:37 +0000 Subject: [cabfpub] Ballot 143 In-Reply-To: <54DE685D.2000500@startcom.org> References: <68a8241d150c4bc6bd624e08988e44fa@EX2.corp.digicert.com> <54DE685D.2000500@startcom.org> Message-ID: Eddy, I think that because the ballot on the validation working group was going to move forward faster than the one on operational existence, Jeremy inadvertently swapped ballot numbers 143 and 145. Let the record so reflect the currently used numbering. Ben From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Eddy Nigg Sent: Friday, February 13, 2015 2:11 PM To: CABFPub Subject: [cabfpub] Ballot 143 There appears to be a mistake with ballot number 143 which was previously assigned to "Remove the operational existence requirement for Government Entities" and later "Formalization of validation working group". Jeremy I believe both were initiated by you? -- Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. XMPP: startcom at startcom.org Blog: Join the Revolution! Twitter: Follow Me -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4954 bytes Desc: not available URL: From eddy_nigg at startcom.org Mon Feb 16 16:58:29 2015 From: eddy_nigg at startcom.org (Eddy Nigg) Date: Mon, 16 Feb 2015 18:58:29 +0200 Subject: [cabfpub] Ballot 143 In-Reply-To: References: <68a8241d150c4bc6bd624e08988e44fa@EX2.corp.digicert.com> <54DE685D.2000500@startcom.org> Message-ID: <54E221B5.4050607@startcom.org> On 02/16/2015 06:56 PM, Ben Wilson wrote: > > Eddy, > > I think that because the ballot on the validation working group was > going to move forward faster than the one on operational existence, > Jeremy inadvertently swapped ballot numbers 143 and 145. Let the > record so reflect the currently used numbering. > OK - so /Remove the operational existence requirement for Government Entities/ will become 145 now. -- Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. XMPP: startcom at startcom.org Blog: Join the Revolution! Twitter: Follow Me -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4313 bytes Desc: S/MIME Cryptographic Signature URL: From ben.wilson at digicert.com Mon Feb 16 16:59:30 2015 From: ben.wilson at digicert.com (Ben Wilson) Date: Mon, 16 Feb 2015 16:59:30 +0000 Subject: [cabfpub] UK's Companies House Liable for Misinformation Message-ID: FYI ? FWIW from Tom Smedinghoff From: Federated ID Management Task Force [mailto:BL-FIDM at MAIL.AMERICANBAR.ORG] On Behalf Of Smedinghoff, Tom Sent: Monday, February 16, 2015 8:49 AM To: BL-FIDM at MAIL.AMERICANBAR.ORG Subject: [ABA-IDM-TASK-FORCE] Liability of IdP? With respect to the issue of identity system participant liability, and the discussion regarding legislative approaches to the issue, a list participant alerted me to a recent UK decision that might be of interest. See Companies House liable for company's collapse and Government in ?9 million payout after single letter blunder causes business to collapse . In that case, Companies House (the UK government's official registrar of companies, and an executive agency of the UK Department of Business, Innovation and Skills) had provided (apparently negligently) false information to credit reference agencies indicating that a business was in liquidation. The result was that all of its suppliers canceled their orders within three weeks, and the 100-year old company was forced to shut down. The UK High Court held Companies House liable for the resulting damages, finding that it owed a duty of care to the business, and that there was a special relationship with the business because ?it is foreseeable that if a company is wrongly said on the register to be in liquidation, it will suffer serious harm.? Since the case involves identity attribute-like information, it appears to raise numerous issues of relevance for the current discussion, including the liability of identity providers and attribute providers, the nature of the duty they might owe to persons and businesses they identify, and the potential liability of a government agency. It will be interesting to see whether similar reasoning is applied to identity credentials asserting incorrect information. Tom Thomas J. Smedinghoff Locke Lord LLP 225 W. Wacker Drive, Suite 3000 Chicago, Illinois 60606 312-201-2021 Direct 312-545-1333 Mobile Tom.Smedinghoff at lockelord.com www.lockelord.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4954 bytes Desc: not available URL: From douglas.beattie at globalsign.com Mon Feb 16 17:41:28 2015 From: douglas.beattie at globalsign.com (Doug Beattie) Date: Mon, 16 Feb 2015 17:41:28 +0000 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names In-Reply-To: <593c466c7fc34b4da114746b576d4396@DISIGEX.disig.local> References: <593c466c7fc34b4da114746b576d4396@DISIGEX.disig.local> Message-ID: GlobalSign abstains. Doug From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Tuesday, February 10, 2015 7:39 PM To: public at cabforum.org Subject: [cabfpub] Ballot 144 - Validation rules for .onion names Here's the ballot with the two typos fixed: Applicants want a CA-signed .onion address for several reasons, including: - Powerful web platform features are restricted to secure origins, which are currently not available to onion names (in part, because of the lack of IANA registration). Permitting EV certs for onion names will help provide a secure origin for the service, moving onion towards use of powerful web platform features. - Currently, access to .onion names over https from a standard browser results in the standard existing 'Invalid Certificate' warning. Training users to click through security warnings lowers the value of these warnings and will cause users to miss important security information. Removing these warnings for the user, through use of a digital certificate, will help users recognize and avoid real MITM attacks. - The public needs attribution of ownership of the .onion address to differentiate onion services, including potential phishing services. Because onion names are not easily recognizable strings, providing the public with additional information about the operator has significant security improvements, especially in regions where use of the incorrect name could have lethal consequences. The following motion has been proposed by Jeremy Rowley of DigiCert and endorsed by Ryan Sleevi of Google and Wayne Thayer of GoDaddy. --------------------- Motion Starts --------------------- 1) Amend Section 9.2.1 of the Baseline Requirements v. 1.2.3 as follows: 9.2.1 Subject Alternative Name Extension Certificate Field: extensions:subjectAltName Required/Optional: Required Contents: This 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. The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate. Wildcard FQDNs are permitted. As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name, the CA SHALL notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016. Also as of the Effective Date, the CA SHALL NOT issue a certificate with an Expiry Date later than 1 November 2015 with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name. Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Name. Effective May 1, 2015, each CA SHALL revoke all unexpired Certificates with an Internal Name using onion as the right-most label in an entry in the subjectAltName Extension or commonName field unless such Certificate was issued in accordance with Appendix F of the EV Guidelines. 2) Amend Section 9.2.2 and 11.7.1 of the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2 as follows: 9.2.2. Subject Alternative Name Extension Certificate field: subjectAltName:dNSName Required/Optional: Required Contents: This extension MUST contain one or more host Domain Name(s) owned or controlled by the Subject and to be associated with the Subject's server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). Wildcard certificates are not allowed for EV Certificates except as permitted under Appendix F. 11.7 Verification of Applicant's Domain Name 11.7.1. Verification Requirements (1) For each Fully-Qualified Domain Name listed in a Certificate, other than a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant (or the Applicant's Parent Company, Subsidiary Company, or Affiliate, collectively referred to as "Applicant" for the purposes of this section) either is the Domain Name Registrant or has control over the FQDN using a procedure specified in Section 11.1.1 of the Baseline Requirements, except that a CA MAY NOT verify a domain using the procedure described 11.1.1(7). For a Certificate issued to a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant's control over the .onion Domain Name in accordance with Appendix F. (2) Mixed Character Set Domain Names: EV Certificates MAY include Domain Names containing mixed character sets only in compliance with the rules set forth by the domain registrar. The CA MUST visually compare any Domain Names with mixed character sets with known high risk domains. If a similarity is found, then the EV Certificate Request MUST be flagged as High Risk. The CA must perform reasonably appropriate additional authentication and verification to be certain beyond reasonable doubt that the Applicant and the target in question are the same organization. 3) Add a new Appendix F to the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2: Appendix F - Issuance of Certificates for .onion Domain Names A CA may issue an EV Certificate with .onion in the right-most label of the Domain Name provided that issuance complies with the requirements set forth in this Appendix: 1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) The CAB Forum has created an extension of the TBSCertificate for use in conveying hashes of keys related to .onion addresses. The Tor Service Descriptor Hash extension has the following format: cabf-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 } TorServiceDescriptorSyntax ::= SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash TorServiceDescriptorHash:: = SEQUENCE { onionURI UTF8String algorithm AlgorithmIdentifier subjectPublicKeyHash BIT STRING } Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 6234) performed over the DER-encoding of an ASN.1 SubjectPublicKey of the .onion service and SubjectPublicKeyHash is the hash output. 2. The CA MUST verify the Applicant's control over the .onion Domain Name using one of the following: a. The CA MAY verify the Applicant's control over the .onion service by posting a specific value at a well-known URL under RFC5785. b. The CA MAY verify the Applicant's control over the .onion service by having the Applicant provide a Certificate Request signed using the .onion public key if the Attributes section of the certificationRequestInfo contains: (i) A caSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy, 2) is generated by the CA, and 3) delivered to the Applicant through a Verified Method of Communication and (ii) An applicantSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy and 2) is generated by the Applicant. The signing nonce attributes have the following format: caSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-caSigningNonce } } cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } applicantSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-applicantSigningNonce } } cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 } 4. Each Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name MUST conform to the requirements of these Guidelines, including the content requirements in Section 9 and Appendix B of the Baseline Requirements, except that the CA MAY include a wildcard character in the Subject Alternative Name Extension and Subject Common Name Field as the left-most character in the .onion Domain Name provided inclusion of the wildcard character complies with Section 11.1.3 of the Baseline Requirements. 5. CAs MUST NOT issue a Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name with a validity period longer than 15 months. Despite Section 9.2.1 of the Baseline Requirements deprecating the use of Internal Names, a CA MAY issue a Certificate containing an .onion name with an expiration date later than 1 November 2015 after (and only if) .onion is officially recognized by the IESG as a reserved TLD. 6. On or before May 1, 2015, each CA MUST revoke all Certificates issued with the Subject Alternative Name extension or Common Name field that includes a Domain Name where .onion is in the right-most label of the Domain Name unless the Certificate was issued in compliance with this Appendix F. ---- Motion Ends ----- The review period for this ballot shall commence at 2200 UTC on Thursday, 4 February 2015, and will close at 2200 UTC on Thursday, 11 February 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on Monday, 18 February 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: From douglas.beattie at globalsign.com Mon Feb 16 18:31:46 2015 From: douglas.beattie at globalsign.com (Doug Beattie) Date: Mon, 16 Feb 2015 18:31:46 +0000 Subject: [cabfpub] [cabfquest] Domain Validation Revision In-Reply-To: References: <54DE3BBE.9000203@eff.org> Message-ID: This suggestion for item 8 works for GlobalSign so you can replace our recommendation with the one below. Doug From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ben Wilson Sent: Friday, February 13, 2015 3:39 PM To: CABFPub Subject: Re: [cabfpub] [cabfquest] Domain Validation Revision Forwarding from questions list. From: questions-bounces at cabforum.org [mailto:questions-bounces at cabforum.org] On Behalf Of Jacob Hoffman-Andrews Sent: Friday, February 13, 2015 11:01 AM To: questions at cabforum.org Subject: Re: [cabfquest] [cabfpub] Domain Validation Revision Following up from a thread on cabfpub: On 02/12/2015 07:08 PM, Ryan Sleevi wrote: 8 concerns me for a couple reasons, even though it's moving in the right direction. - You require HTTPS, but that seems overkill, when you only need to perform a TLS handshake. That is, consider a mail server configured for SMTP-S - it seems that would be a viable configuration Agreed. As a concrete example, the ACME spec under discussion at IETF proposes a challenge type called "Domain Validation with Server Name Indication," or DVSNI for short: http://www.ietf.org/id/draft-barnes-acme-01.txt. We believe that DVSNI allows us to offer a higher level of assurance than item (6), "making an agreed-upon change to information found on an online Web page," since some sites allow arbitrary file upload, either by intent or by accident. We're planning to use it for the Let's Encrypt CA for that reason, so we'd like to make sure that item (8) allows for DVSNI. For example, here is a version of item (8) that we think would work: Having the Applicant demonstrate practical control over the FQDN by providing a TLS service on a host found in DNS for the FQDN. The CA SHALL initiate a TLS connection with that host and verify that the response contains unique, unguessable information proposed by the CA, in a well-specified format. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirk_hall at trendmicro.com Mon Feb 16 21:57:33 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Mon, 16 Feb 2015 21:57:33 +0000 Subject: [cabfpub] Domain Validation Revision In-Reply-To: <54DDCC5D.50305@mozilla.org> References: <54DDCC5D.50305@mozilla.org> Message-ID: Gerv -- we always allowed attorney letters in the past. For DV/OV, it was an "any other method" means of domain confirmation. For EV, it was explicitly allowed under the EVGL (and there are still references to it in the template Attorney Letter attached to the EVGL), but by mistake we deleted the reference when we changed EVGL 11.7 simply to a cross reference to BR 11.1.1 ? we accidentally dropped the old reference to using attorney-accountant letters for EV domain confirmation (I can give you a version number reference to the old EVGL if you want to confirm). So the proposal just corrects that mistake and adds back in a method we have always permitted for domain confirmation. This is useful when the Domain Name Registrant has licensed the domain to the Customer, or when the parent-sub relationship is not reported correctly, etc. -----Original Message----- From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Gervase Markham Sent: Friday, February 13, 2015 2:05 AM To: Jeremy Rowley; CABFPub (public at cabforum.org) Subject: Re: [cabfpub] Domain Validation Revision > 3) permit > attorney/accountants to draft the domain authorization document. If I understand this correctly, then I am opposed. I don't see why a lawyer or an accountant is an appropriate authority on the subject of who controls a domain. Domain control can only be properly validated either by the registrar who issued the domain, the registrant listed in WHOIS, or some practical demonstration of control. No-one else's opinion matters. Gerv _______________________________________________ Public mailing list Public at cabforum.org https://cabforum.org/mailman/listinfo/public 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
-------------- next part -------------- An HTML attachment was scrubbed... URL: From enric.castillo at anf.es Mon Feb 16 18:40:23 2015 From: enric.castillo at anf.es (Enric Castillo) Date: Mon, 16 Feb 2015 19:40:23 +0100 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names In-Reply-To: References: Message-ID: <54E23997.5080604@anf.es> ANF AC abstains ballot 144. ANF Autoridad de Certificaci?n *Enric Castillo* Director T?cnico +34 626818285 Gran Via de Les Corts Catalanes 996, Barcelona +593 0 998554992 12 de Octubre y Cordero, World Trade Center, Torre A, 1102, Quito ANF Autoridad de Certificaci?n www.anf.es *Aviso* Este mensaje se dirige exclusivamente a su destinatario y puede contener informaci?n privilegiada o confidencial y/o datos de car?cter personal, cuya difusi?n est? regulada por la Ley Org?nica de Protecci?n de Datos y la Ley de Servicios de la Sociedad de la Informaci?n. Si usted no es el destinatario indicado (o el responsable de la entrega al mismo), no debe copiar o entregar este mensaje a terceros bajo ning?n concepto. Si ha recibido este mensaje por error o lo ha conseguido por otros medios, le rogamos que nos lo comunique inmediatamente por esta misma v?a y proceda a su eliminaci?n irreversible. Las opiniones, conclusiones y dem?s informaciones incluidas en este mensaje que no est?n relacionadas con asuntos profesionales de ANF Autoridad de Certificaci?n no est?n respaldadas por la empresa. El 10/02/2015 a las 19:38, Jeremy Rowley escribi?: > > *Here?s the ballot with the two typos fixed:* > > Applicants want a CA-signed .onion address for several reasons, including: > > - Powerful web platform features are restricted to secure origins, > which are currently not available to onion names (in part, because of > the lack of IANA registration). Permitting EV certs for onion names > will help provide a secure origin for the service, moving onion > towards use of powerful web platform features. > > - Currently, access to .onion names over https from a standard browser > results in the standard existing 'Invalid Certificate' warning. > Training users to click through security warnings lowers the value of > these warnings and will cause users to miss important security > information. Removing these warnings for the user, through use of a > digital certificate, will help users recognize and avoid real MITM > attacks. > > - The public needs attribution of ownership of the .onion address to > differentiate onion services, including potential phishing services. > Because onion names are not easily recognizable strings, providing the > public with additional information about the operator has significant > security improvements, especially in regions where use of the > incorrect name could have lethal consequences. > > The following motion has been proposed by Jeremy Rowley of DigiCert > and endorsed by Ryan Sleevi of Google and Wayne Thayer of GoDaddy. > > --------------------- > > Motion Starts > > --------------------- > > 1) Amend Section 9.2.1 of the Baseline Requirements v. 1.2.3 as follows: > > 9.2.1 Subject Alternative Name Extension > > Certificate Field: extensions:subjectAltName > > Required/Optional: Required > > Contents: This 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. The CA MUST > confirm that the Applicant controls the Fully-Qualified Domain Name or > IP address or has been granted the right to use it by the Domain Name > Registrant or IP address assignee, as appropriate. > > Wildcard FQDNs are permitted. As of the Effective Date of these > Requirements, prior to the issuance of a Certificate with a > subjectAlternativeName extension or Subject commonName field > containing a Reserved IP Address or Internal Name, the CA SHALL notify > the Applicant that the use of such Certificates has been deprecated by > the CA / Browser Forum and that the practice will be eliminated by > October 2016. Also as of the Effective Date, the CA SHALL NOT issue a > certificate with an Expiry Date later than 1 November 2015 with a > subjectAlternativeName extension or Subject commonName field > containing a Reserved IP Address or Internal Name. Effective 1 October > 2016, CAs SHALL revoke all unexpired Certificates whose > subjectAlternativeName extension or Subject commonName field contains > a Reserved IP Address or Internal Name. _Effective May 1, 2015, each > CA SHALL revoke all unexpired Certificates with an Internal Name using > onion as the right-most label in an entry in the subjectAltName > Extension or commonName field unless such Certificate was issued in > accordance with Appendix F of the EV Guidelines._ > > 2) Amend Section 9.2.2 and 11.7.1 of the Guidelines for the Issuance > and Management of Extended Validation Certificates v1.5.2 as follows: > > 9.2.2. Subject Alternative Name Extension Certificate field: > subjectAltName:dNSName > > Required/Optional: Required > > Contents: This extension MUST contain one or more host Domain Name(s) > owned or controlled by the Subject and to be associated with the > Subject?s server. Such server MAY be owned and operated by the Subject > or another entity (e.g., a hosting service). Wildcard certificates are > not allowed for EV Certificates_except as permitted under Appendix F_. > > 11.7 Verification of Applicant?s Domain Name > > 11.7.1. Verification Requirements > > (1) For each Fully-Qualified Domain Name listed in a Certificate, > other than a Domain Name with .onion in the right-most label of the > Domain Name, the CA SHALL confirm that, as of the date the Certificate > was issued, the Applicant (or the Applicant?s Parent Company, > Subsidiary Company, or Affiliate, collectively referred to as > ?Applicant? for the purposes of this section) either is the Domain > Name Registrant or has control over the FQDN using a procedure > specified in Section 11.1.1 of the Baseline Requirements, except that > a CA MAY NOT verify a domain using the procedure described 11.1.1(7). > _For a Certificate issued to a Domain Name with .onion in the > right-most label of the Domain Name, the CA SHALL confirm that, as of > the date the Certificate was issued, the Applicant?s control over the > .onion Domain Name in accordance with Appendix F._ > > (2) Mixed Character Set Domain Names: EV Certificates MAY include > Domain Names containing mixed character sets only in compliance with > the rules set forth by the domain registrar. The CA MUST visually > compare any Domain Names with mixed character sets with known high > risk domains. If a similarity is found, then the EV Certificate > Request MUST be flagged as High Risk. The CA must perform reasonably > appropriate additional authentication and verification to be certain > beyond reasonable doubt that the Applicant and the target in question > are the same organization. > > 3) Add a new Appendix F to the Guidelines for the Issuance and > Management of Extended Validation Certificates v1.5.2: > > Appendix F ? Issuance of Certificates for .onion Domain Names > > A CA may issue an EV Certificate with .onion in the right-most label > of the Domain Name provided that issuance complies with the > requirements set forth in this Appendix: > > 1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) > > The CAB Forum has created an extension of the TBSCertificate for use > in conveying hashes of keys related to .onion addresses. The Tor > Service Descriptor Hash extension has the following format: > > cabf-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 } > > TorServiceDescriptorSyntax ::= > > SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash > > TorServiceDescriptorHash:: = SEQUENCE { > > onionURI UTF8String > > algorithm AlgorithmIdentifier > > subjectPublicKeyHash BIT STRING } > > Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC > 6234) performed over the DER-encoding of an ASN.1 SubjectPublicKey of > the .onion service and SubjectPublicKeyHash is the hash output. > > 2. The CA MUST verify the Applicant?s control over the .onion Domain > Name using one of the following: > > a. The CA MAY verify the Applicant?s control over the .onion service > by posting a specific value at a well-known URL under RFC5785. > > b. The CA MAY verify the Applicant?s control over the .onion service > by having the Applicant provide a Certificate Request signed using the > .onion public key if the Attributes section of the > certificationRequestInfo contains: > > (i) A caSigningNonce attribute that 1) contains a single value with at > least 64-bits of entropy, 2) is generated by the CA, and 3) delivered > to the Applicant through a Verified Method of Communication and > > (ii) An applicantSigningNonce attribute that 1) contains a single > value with at least 64-bits of entropy and 2) is generated by the > Applicant. > > The signing nonce attributes have the following format: > > caSigningNonce ATTRIBUTE ::= { > > WITH SYNTAX OCTET STRING > > EQUALITY MATCHING RULE octetStringMatch > > SINGLE VALUE TRUE > > ID { cabf-caSigningNonce } > > } > > cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } > > applicantSigningNonce ATTRIBUTE ::= { > > WITH SYNTAX OCTET STRING > > EQUALITY MATCHING RULE octetStringMatch > > SINGLE VALUE TRUE > > ID { cabf-applicantSigningNonce } > > } > > cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 } > > 4. Each Certificate that includes a Domain Name where .onion is in the > right-most label of the Domain Name MUST conform to the requirements > of these Guidelines, including the content requirements in Section 9 > and Appendix B of the Baseline Requirements, except that the CA MAY > include a wildcard character in the Subject Alternative Name Extension > and Subject Common Name Field as the left-most character in the .onion > Domain Name provided inclusion of the wildcard character complies with > Section 11.1.3 of the Baseline Requirements. > > 5. CAs MUST NOT issue a Certificate that includes a Domain Name where > .onion is in the right-most label of the Domain Name with a validity > period longer than 15 months. Despite Section 9.2.1 of the Baseline > Requirements deprecating the use of Internal Names, a CA MAY issue a > Certificate containing an .onion name with an expiration date later > than 1 November 2015 after (and only if) .onion is officially > recognized by the IESG as a reserved TLD. > > 6. On or before May 1, 2015, each CA MUST revoke all Certificates > issued with the Subject Alternative Name extension or Common Name > field that includes a Domain Name where .onion is in the right-most > label of the Domain Name unless the Certificate was issued in > compliance with this Appendix F. > > ---- > > Motion Ends > > ----- > > The review period for this ballot shall commence at 2200 UTC on > Thursday, 4 February 2015, and will close at 2200 UTC on Thursday, 11 > February 2015. Unless the motion is withdrawn during the review > period, the voting period will start immediately thereafter and will > close at 2200 UTC on Monday, 18 February 2015. Votes must be cast by > posting an on-list reply to this thread. > > A vote in favor of the motion must indicate a clear 'yes' in the > response. A vote against must indicate a clear 'no' in the response. A > vote to abstain must indicate a clear 'abstain' in the response. > Unclear responses will not be counted. The latest vote received from > any representative of a voting member before the close of the voting > period will be counted. Voting members are listed here: > https://cabforum.org/members/ > > In order for the motion to be adopted, two thirds or more of the votes > cast by members in the CA category and greater than 50% of the votes > cast by members in the browser category must be in favor. Quorum is > currently nine (9) members? at least nine members must participate in > the ballot, either by voting in favor, voting against, or abstaining. > > > > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo-anf.png Type: image/png Size: 4746 bytes Desc: not available URL: From enric.castillo at anf.es Mon Feb 16 18:41:22 2015 From: enric.castillo at anf.es (Enric Castillo) Date: Mon, 16 Feb 2015 19:41:22 +0100 Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group In-Reply-To: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> References: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> Message-ID: <54E239D2.1090001@anf.es> ANF AC votes yes. ANF Autoridad de Certificaci?n *Enric Castillo* Director T?cnico +34 626818285 Gran Via de Les Corts Catalanes 996, Barcelona +593 0 998554992 12 de Octubre y Cordero, World Trade Center, Torre A, 1102, Quito ANF Autoridad de Certificaci?n www.anf.es *Aviso* Este mensaje se dirige exclusivamente a su destinatario y puede contener informaci?n privilegiada o confidencial y/o datos de car?cter personal, cuya difusi?n est? regulada por la Ley Org?nica de Protecci?n de Datos y la Ley de Servicios de la Sociedad de la Informaci?n. Si usted no es el destinatario indicado (o el responsable de la entrega al mismo), no debe copiar o entregar este mensaje a terceros bajo ning?n concepto. Si ha recibido este mensaje por error o lo ha conseguido por otros medios, le rogamos que nos lo comunique inmediatamente por esta misma v?a y proceda a su eliminaci?n irreversible. Las opiniones, conclusiones y dem?s informaciones incluidas en este mensaje que no est?n relacionadas con asuntos profesionales de ANF Autoridad de Certificaci?n no est?n respaldadas por la empresa. El 04/02/2015 a las 22:05, Jeremy Rowley escribi?: > > Ballot 143 - Formalization of validation working group > > ---- > > Reason > > ---- > > In order to address validation issues and inconsistencies in both the > SSL Baseline Requirements and the EV Guidelines, the CAB Forum has > held an informal working group previously referred to as the Extended > Validation Working Group now known as the Validation Working Group, > would like to modify its scope to include validation in the Baseline > Requirements as well as the EV Guidelines. > > Jeremy Rowley of DigiCert made the following motion, which was > endorsed by Rich Smith of Comodo and Kirk Hall of TrendMicro > > ---- > > Motion begins > > ---- > > The CA-Browser Forum formally establishes the Validation Working Group > as an official working group of the CAB Forum, replacing the previous > informal EV working group. The scope of this working group is to > address issues arising under adopted CAB Forum standards related to > the validation of certificate information and the inclusion of > information in certificates. > > Scope: The Validation Working Group will consider all matters relating > to the validation and inclusion of information in certificates under > adopted CAB Forum guidelines. > > Deliverables: The Working Group shall produce one or more documents > offering options to the Forum for validation within the scope defined > above. > > ---- > > Motion Ends > > ---- > > The review period for this ballot shall commence at 2200 UTC on 5 Feb > 2015, and will close at 2200 UTC on 11 Feb 2015. Unless the motion is > withdrawn during the review period, the voting period will start > immediately thereafter and will close at 2200 UTC on 18 Feb 2015. > Votes must be cast by posting an on-list reply to this thread. > > A vote in favor of the motion must indicate a clear 'yes' in the > response. A vote against must indicate a clear 'no' in the response. A > vote to abstain must indicate a clear 'abstain' in the response. > Unclear responses will not be counted. The latest vote received from > any representative of a voting member before the close of the voting > period will be counted. Voting members are listed here: > https://cabforum.org/members/ > > In order for the motion to be adopted, two thirds or more of the votes > cast by members in the CA category and greater than 50% of the votes > cast by members in the browser category must be in favor. Quorum is > currently nine (9) members? at least nine members must participate in > the ballot, either by voting in favor, voting against, or abstaining. > > > > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo-anf.png Type: image/png Size: 4746 bytes Desc: not available URL: From enric.castillo at anf.es Mon Feb 16 18:59:56 2015 From: enric.castillo at anf.es (Enric Castillo) Date: Mon, 16 Feb 2015 19:59:56 +0100 Subject: [cabfpub] IPv6 support In-Reply-To: <54DE8183.1060204@startcom.org> References: <14D026C7F297AD44AC82578DD818CDD038EEF0BA5B@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C01141460BD37468D1@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <14D026C7F297AD44AC82578DD818CDD038EEF0BFAD@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> <14D026C7F297AD44AC82578DD818CDD038EF1EA316@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> <54DE8183.1060204@startcom.org> Message-ID: <54E23E2C.70903@anf.es> We don't support IPv6 now for CRL and OCSP because the demand is so low by the moment. Talking with the infraestructure team, our changes are easy to implement and become fully compilance with IPv6. ANF Autoridad de Certificaci?n *Enric Castillo* Director T?cnico +34 626818285 Gran Via de Les Corts Catalanes 996, Barcelona +593 0 998554992 12 de Octubre y Cordero, World Trade Center, Torre A, 1102, Quito ANF Autoridad de Certificaci?n www.anf.es *Aviso* Este mensaje se dirige exclusivamente a su destinatario y puede contener informaci?n privilegiada o confidencial y/o datos de car?cter personal, cuya difusi?n est? regulada por la Ley Org?nica de Protecci?n de Datos y la Ley de Servicios de la Sociedad de la Informaci?n. Si usted no es el destinatario indicado (o el responsable de la entrega al mismo), no debe copiar o entregar este mensaje a terceros bajo ning?n concepto. Si ha recibido este mensaje por error o lo ha conseguido por otros medios, le rogamos que nos lo comunique inmediatamente por esta misma v?a y proceda a su eliminaci?n irreversible. Las opiniones, conclusiones y dem?s informaciones incluidas en este mensaje que no est?n relacionadas con asuntos profesionales de ANF Autoridad de Certificaci?n no est?n respaldadas por la empresa. El 13/02/2015 a las 23:58, Eddy Nigg escribi?: > > On 02/14/2015 12:33 AM, Dean Coclin wrote: >> You?ll probably realize after reading this that there isn?t much >> actionable material here as many members are ?scoping? or ?waiting >> for info? without any concrete response dates. We?ll keep this tally >> going and update as we get more info. >> >> Globalsign: Yes, can support >> >> Symantec: We don?t support this today. We?ve received very little >> demand for it from customers, but we?re in the process of scoping out >> the effort. >> >> Comodo:Yes, for CRL and OCSP >> >> TrendMicro:Yes >> GoDaddy: Waiting for info from network team >> >> Entrust:Yes for CRL and OCSP. >> >> Trustwave:We don?t support this today. Just started scoping the >> effort. Not many requests for this >> >> Digicert:We currently do not support it. Our connectivity providers >> support it, and it could be done with CRLs and OCSP, but we?d need to >> look for any gotchas before pulling the trigger. We?ve only had a >> couple of customers ask whether we support it. >> > > To add StartCom to the list, we could support it for almost > everything, but we have some historical CRL distribution points that > can't support IPv6 for now. It seems that OCSP would work, but CRLs > not 100%. > > Same as with Digicert, demand for IPv6 has been so low that we haven't > invested into it so far. > > -- > Regards > Signer: Eddy Nigg, COO/CTO > StartCom Ltd. > XMPP: startcom at startcom.org > Blog: Join the Revolution! > Twitter: Follow Me > > > > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo-anf.png Type: image/png Size: 4746 bytes Desc: not available URL: From realsky at cht.com.tw Tue Feb 17 10:02:09 2015 From: realsky at cht.com.tw (=?UTF-8?B?6Zmz56uL576k?=) Date: Tue, 17 Feb 2015 18:02:09 +0800 Subject: [cabfpub] Ballot 143 - Formalization of validation working group In-Reply-To: References: Message-ID: <00d701d04a98$cb5e6570$621b3050$@cht.com.tw> Chunghwa Telecom Co., Ltd. votes YES as Sincerely Yours, Li-Chun CHEN Engineer CISSP, CISA, CISM, PMP, Information & Communication Security Dept. Data Communication Business Group Chunghwa Telecom Co. Ltd. realsky at cht.com.tw +886-2-2344-4820#4025 From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of kirk_hall at trendmicro.com Sent: Friday, February 13, 2015 6:27 AM To: CABFPub (public at cabforum.org) Subject: [cabfpub] Ballot 143 - Formalization of validation working group Trend Micro votes yes. Kirk R. Hall Operations Director, Trust Services Trend Micro +1.503.753.3088 TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. 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: From gerv at mozilla.org Tue Feb 17 11:12:35 2015 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 17 Feb 2015 11:12:35 +0000 Subject: [cabfpub] Domain Validation Revision In-Reply-To: References: <54DDCC5D.50305@mozilla.org> Message-ID: <54E32223.1070200@mozilla.org> On 16/02/15 21:57, kirk_hall at trendmicro.com wrote: > Gerv -- we always allowed attorney letters in the past. > > For DV/OV, it was an "any other method" means of domain confirmation. Who has used this method? Perhaps they could explain how they feel that this provides the "same level of assurance"? What expertise does an attorney have in determining actual domain control? > For EV, it was explicitly allowed under the EVGL (and there are still > references to it in the template Attorney Letter attached to the EVGL), > but /_by mistake_/ we deleted the reference when we changed EVGL 11.7 > simply to a cross reference to BR 11.1.1 ? we accidentally dropped the > old reference to using attorney-accountant letters for EV domain > confirmation (I can give you a version number reference to the old EVGL > if you want to confirm). That would be useful, please. > This is useful when the Domain Name Registrant has licensed the domain > to the Customer, or when the parent-sub relationship is not reported > correctly, etc. If they've licensed the domain to the customer, then surely the customer can demonstrate control in any of the normal ways? If they can't, then they don't actually have control of it, do they? Gerv From bruce.morton at entrust.com Tue Feb 17 12:27:36 2015 From: bruce.morton at entrust.com (Bruce Morton) Date: Tue, 17 Feb 2015 12:27:36 +0000 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names In-Reply-To: References: Message-ID: <452C99D20750E74083DBA441FF932385E4167C98@SOTTEXCH10.corp.ad.entrust.com> Entrust abstains. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Tuesday, February 10, 2015 1:39 PM To: public at cabforum.org Subject: [cabfpub] Ballot 144 - Validation rules for .onion names Here's the ballot with the two typos fixed: Applicants want a CA-signed .onion address for several reasons, including: - Powerful web platform features are restricted to secure origins, which are currently not available to onion names (in part, because of the lack of IANA registration). Permitting EV certs for onion names will help provide a secure origin for the service, moving onion towards use of powerful web platform features. - Currently, access to .onion names over https from a standard browser results in the standard existing 'Invalid Certificate' warning. Training users to click through security warnings lowers the value of these warnings and will cause users to miss important security information. Removing these warnings for the user, through use of a digital certificate, will help users recognize and avoid real MITM attacks. - The public needs attribution of ownership of the .onion address to differentiate onion services, including potential phishing services. Because onion names are not easily recognizable strings, providing the public with additional information about the operator has significant security improvements, especially in regions where use of the incorrect name could have lethal consequences. The following motion has been proposed by Jeremy Rowley of DigiCert and endorsed by Ryan Sleevi of Google and Wayne Thayer of GoDaddy. --------------------- Motion Starts --------------------- 1) Amend Section 9.2.1 of the Baseline Requirements v. 1.2.3 as follows: 9.2.1 Subject Alternative Name Extension Certificate Field: extensions:subjectAltName Required/Optional: Required Contents: This 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. The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate. Wildcard FQDNs are permitted. As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name, the CA SHALL notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016. Also as of the Effective Date, the CA SHALL NOT issue a certificate with an Expiry Date later than 1 November 2015 with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name. Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Name. Effective May 1, 2015, each CA SHALL revoke all unexpired Certificates with an Internal Name using onion as the right-most label in an entry in the subjectAltName Extension or commonName field unless such Certificate was issued in accordance with Appendix F of the EV Guidelines. 2) Amend Section 9.2.2 and 11.7.1 of the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2 as follows: 9.2.2. Subject Alternative Name Extension Certificate field: subjectAltName:dNSName Required/Optional: Required Contents: This extension MUST contain one or more host Domain Name(s) owned or controlled by the Subject and to be associated with the Subject's server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). Wildcard certificates are not allowed for EV Certificates except as permitted under Appendix F. 11.7 Verification of Applicant's Domain Name 11.7.1. Verification Requirements (1) For each Fully-Qualified Domain Name listed in a Certificate, other than a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant (or the Applicant's Parent Company, Subsidiary Company, or Affiliate, collectively referred to as "Applicant" for the purposes of this section) either is the Domain Name Registrant or has control over the FQDN using a procedure specified in Section 11.1.1 of the Baseline Requirements, except that a CA MAY NOT verify a domain using the procedure described 11.1.1(7). For a Certificate issued to a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant's control over the .onion Domain Name in accordance with Appendix F. (2) Mixed Character Set Domain Names: EV Certificates MAY include Domain Names containing mixed character sets only in compliance with the rules set forth by the domain registrar. The CA MUST visually compare any Domain Names with mixed character sets with known high risk domains. If a similarity is found, then the EV Certificate Request MUST be flagged as High Risk. The CA must perform reasonably appropriate additional authentication and verification to be certain beyond reasonable doubt that the Applicant and the target in question are the same organization. 3) Add a new Appendix F to the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2: Appendix F - Issuance of Certificates for .onion Domain Names A CA may issue an EV Certificate with .onion in the right-most label of the Domain Name provided that issuance complies with the requirements set forth in this Appendix: 1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) The CAB Forum has created an extension of the TBSCertificate for use in conveying hashes of keys related to .onion addresses. The Tor Service Descriptor Hash extension has the following format: cabf-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 } TorServiceDescriptorSyntax ::= SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash TorServiceDescriptorHash:: = SEQUENCE { onionURI UTF8String algorithm AlgorithmIdentifier subjectPublicKeyHash BIT STRING } Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 6234) performed over the DER-encoding of an ASN.1 SubjectPublicKey of the .onion service and SubjectPublicKeyHash is the hash output. 2. The CA MUST verify the Applicant's control over the .onion Domain Name using one of the following: a. The CA MAY verify the Applicant's control over the .onion service by posting a specific value at a well-known URL under RFC5785. b. The CA MAY verify the Applicant's control over the .onion service by having the Applicant provide a Certificate Request signed using the .onion public key if the Attributes section of the certificationRequestInfo contains: (i) A caSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy, 2) is generated by the CA, and 3) delivered to the Applicant through a Verified Method of Communication and (ii) An applicantSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy and 2) is generated by the Applicant. The signing nonce attributes have the following format: caSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-caSigningNonce } } cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } applicantSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-applicantSigningNonce } } cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 } 4. Each Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name MUST conform to the requirements of these Guidelines, including the content requirements in Section 9 and Appendix B of the Baseline Requirements, except that the CA MAY include a wildcard character in the Subject Alternative Name Extension and Subject Common Name Field as the left-most character in the .onion Domain Name provided inclusion of the wildcard character complies with Section 11.1.3 of the Baseline Requirements. 5. CAs MUST NOT issue a Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name with a validity period longer than 15 months. Despite Section 9.2.1 of the Baseline Requirements deprecating the use of Internal Names, a CA MAY issue a Certificate containing an .onion name with an expiration date later than 1 November 2015 after (and only if) .onion is officially recognized by the IESG as a reserved TLD. 6. On or before May 1, 2015, each CA MUST revoke all Certificates issued with the Subject Alternative Name extension or Common Name field that includes a Domain Name where .onion is in the right-most label of the Domain Name unless the Certificate was issued in compliance with this Appendix F. ---- Motion Ends ----- The review period for this ballot shall commence at 2200 UTC on Thursday, 4 February 2015, and will close at 2200 UTC on Thursday, 11 February 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on Monday, 18 February 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: From haavardm at opera.com Tue Feb 17 13:05:54 2015 From: haavardm at opera.com (haavardm at work) Date: Tue, 17 Feb 2015 14:05:54 +0100 Subject: [cabfpub] Ballot 143 - Formalization of validation working group In-Reply-To: References: Message-ID: Opera votes YES. H?vard On Thu, Feb 12, 2015 at 11:26 PM, kirk_hall at trendmicro.com < kirk_hall at trendmicro.com> wrote: > Trend Micro votes yes. > > > > *Kirk R. Hall* > > Operations Director, Trust Services > > Trend Micro > > +1.503.753.3088 > > > > TREND MICRO EMAIL NOTICE > The information contained in this email and any attachments is confidential > and may be subject to copyright or other intellectual property protection. > If you are not the intended recipient, you are not authorized to use or > disclose this information, and we request that you notify us by reply mail or > telephone and delete the original message from your mail system. > > > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From haavardm at opera.com Tue Feb 17 13:08:14 2015 From: haavardm at opera.com (haavardm at work) Date: Tue, 17 Feb 2015 14:08:14 +0100 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names Message-ID: Opera votes YES On Tue, Feb 10, 2015 at 7:38 PM, Jeremy Rowley wrote: > *Here?s the ballot with the two typos fixed:* > > > > Applicants want a CA-signed .onion address for several reasons, including: > > - Powerful web platform features are restricted to secure > origins, which are currently not available to onion names (in part, because > of the lack of IANA registration). Permitting EV certs for onion names > will help provide a secure origin for the service, moving onion towards use > of powerful web platform features. > > - Currently, access to .onion names over https from a > standard browser results in the standard existing 'Invalid Certificate' > warning. Training users to click through security warnings lowers the > value of these warnings and will cause users to miss important security > information. Removing these warnings for the user, through use of a > digital certificate, will help users recognize and avoid real MITM attacks. > > - The public needs attribution of ownership of the .onion > address to differentiate onion services, including potential phishing > services. Because onion names are not easily recognizable strings, > providing the public with additional information about the operator has > significant security improvements, especially in regions where use of the > incorrect name could have lethal consequences. > > > > The following motion has been proposed by Jeremy Rowley of DigiCert and > endorsed by Ryan Sleevi of Google and Wayne Thayer of GoDaddy. > > > > --------------------- > > Motion Starts > > --------------------- > > > > 1) Amend Section 9.2.1 of the Baseline Requirements v. 1.2.3 as follows: > > 9.2.1 Subject Alternative Name Extension > > Certificate Field: extensions:subjectAltName > > Required/Optional: Required > > Contents: This 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. The CA MUST confirm that > the Applicant controls the Fully-Qualified Domain Name or IP address or has > been granted the right to use it by the Domain Name Registrant or IP > address assignee, as appropriate. > > > > Wildcard FQDNs are permitted. As of the Effective Date of these > Requirements, prior to the issuance of a Certificate with a > subjectAlternativeName extension or Subject commonName field containing a > Reserved IP Address or Internal Name, the CA SHALL notify the Applicant > that the use of such Certificates has been deprecated by the CA / Browser > Forum and that the practice will be eliminated by October 2016. Also as of > the Effective Date, the CA SHALL NOT issue a certificate with an Expiry > Date later than 1 November 2015 with a subjectAlternativeName extension or > Subject commonName field containing a Reserved IP Address or Internal Name. > Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose > subjectAlternativeName extension or Subject commonName field contains a > Reserved IP Address or Internal Name. *Effective May 1, 2015, each CA > SHALL revoke all unexpired Certificates with an Internal Name using onion > as the right-most label in an entry in the subjectAltName Extension or > commonName field unless such Certificate was issued in accordance with > Appendix F of the EV Guidelines.* > > > > 2) Amend Section 9.2.2 and 11.7.1 of the Guidelines for the Issuance and > Management of Extended Validation Certificates v1.5.2 as follows: > > > > 9.2.2. Subject Alternative Name Extension Certificate field: > subjectAltName:dNSName > > Required/Optional: Required > > Contents: This extension MUST contain one or more host Domain Name(s) > owned or controlled by the Subject and to be associated with the Subject?s > server. Such server MAY be owned and operated by the Subject or another > entity (e.g., a hosting service). Wildcard certificates are not allowed for > EV Certificates* except as permitted under Appendix F*. > > > > 11.7 Verification of Applicant?s Domain Name > > > > 11.7.1. Verification Requirements > > > > (1) For each Fully-Qualified Domain Name listed in a Certificate, other > than a Domain Name with .onion in the right-most label of the Domain Name, > the CA SHALL confirm that, as of the date the Certificate was issued, the > Applicant (or the Applicant?s Parent Company, Subsidiary Company, or > Affiliate, collectively referred to as ?Applicant? for the purposes of this > section) either is the Domain Name Registrant or has control over the FQDN > using a procedure specified in Section 11.1.1 of the Baseline Requirements, > except that a CA MAY NOT verify a domain using the procedure described > 11.1.1(7). *For a Certificate issued to a Domain Name with .onion in the > right-most label of the Domain Name, the CA SHALL confirm that, as of the > date the Certificate was issued, the Applicant?s control over the .onion > Domain Name in accordance with Appendix F.* > > > > (2) Mixed Character Set Domain Names: EV Certificates MAY include Domain > Names containing mixed character sets only in compliance with the rules set > forth by the domain registrar. The CA MUST visually compare any Domain > Names with mixed character sets with known high risk domains. If a > similarity is found, then the EV Certificate Request MUST be flagged as > High Risk. The CA must perform reasonably appropriate additional > authentication and verification to be certain beyond reasonable doubt that > the Applicant and the target in question are the same organization. > > > > 3) Add a new Appendix F to the Guidelines for the Issuance and Management > of Extended Validation Certificates v1.5.2: > > > > Appendix F ? Issuance of Certificates for .onion Domain Names > > > > A CA may issue an EV Certificate with .onion in the right-most label of > the Domain Name provided that issuance complies with the requirements set > forth in this Appendix: > > 1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) > > The CAB Forum has created an extension of the TBSCertificate for use in > conveying hashes of keys related to .onion addresses. The Tor Service > Descriptor Hash extension has the following format: > > > > cabf-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 } > > > > TorServiceDescriptorSyntax ::= > > SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash > > > > TorServiceDescriptorHash:: = SEQUENCE { > > onionURI UTF8String > > algorithm AlgorithmIdentifier > > subjectPublicKeyHash BIT STRING } > > > > Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 6234) > performed over the DER-encoding of an ASN.1 SubjectPublicKey of the .onion > service and SubjectPublicKeyHash is the hash output. > > > > 2. The CA MUST verify the Applicant?s control over the .onion Domain > Name using one of the following: > > > > a. The CA MAY verify the Applicant?s control over the .onion service > by posting a specific value at a well-known URL under RFC5785. > > > > b. The CA MAY verify the Applicant?s control over the .onion service > by having the Applicant provide a Certificate Request signed using the > .onion public key if the Attributes section of the certificationRequestInfo > contains: > > > > (i) A caSigningNonce attribute that 1) contains a single value > with at least 64-bits of entropy, 2) is generated by the CA, and 3) > delivered to the Applicant through a Verified Method of Communication and > > (ii) An applicantSigningNonce attribute that 1) contains a > single value with at least 64-bits of entropy and 2) is generated by the > Applicant. > > > > The signing nonce attributes have the following format: > > > > caSigningNonce ATTRIBUTE ::= { > > WITH SYNTAX OCTET STRING > > EQUALITY MATCHING RULE octetStringMatch > > SINGLE VALUE TRUE > > ID { > cabf-caSigningNonce } > > } > > > > cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } > > > > applicantSigningNonce ATTRIBUTE ::= { > > WITH SYNTAX OCTET STRING > > EQUALITY MATCHING RULE octetStringMatch > > SINGLE VALUE TRUE > > ID { > cabf-applicantSigningNonce } > > } > > > > cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 } > > > > 4. Each Certificate that includes a Domain Name where .onion is in > the right-most label of the Domain Name MUST conform to the requirements of > these Guidelines, including the content requirements in Section 9 and > Appendix B of the Baseline Requirements, except that the CA MAY include a > wildcard character in the Subject Alternative Name Extension and Subject > Common Name Field as the left-most character in the .onion Domain Name > provided inclusion of the wildcard character complies with Section 11.1.3 > of the Baseline Requirements. > > > > 5. CAs MUST NOT issue a Certificate that includes a Domain Name where > .onion is in the right-most label of the Domain Name with a validity period > longer than 15 months. Despite Section 9.2.1 of the Baseline Requirements > deprecating the use of Internal Names, a CA MAY issue a Certificate > containing an .onion name with an expiration date later than 1 November > 2015 after (and only if) .onion is officially recognized by the IESG as a > reserved TLD. > > > > 6. On or before May 1, 2015, each CA MUST revoke all Certificates > issued with the Subject Alternative Name extension or Common Name field > that includes a Domain Name where .onion is in the right-most label of the > Domain Name unless the Certificate was issued in compliance with this > Appendix F. > > > > ---- > > Motion Ends > > ----- > > The review period for this ballot shall commence at 2200 UTC on Thursday, > 4 February 2015, and will close at 2200 UTC on Thursday, 11 February 2015. > Unless the motion is withdrawn during the review period, the voting period > will start immediately thereafter and will close at 2200 UTC on Monday, 18 > February 2015. Votes must be cast by posting an on-list reply to this > thread. > > A vote in favor of the motion must indicate a clear 'yes' in the response. > A vote against must indicate a clear 'no' in the response. A vote to > abstain must indicate a clear 'abstain' in the response. Unclear responses > will not be counted. The latest vote received from any representative of a > voting member before the close of the voting period will be counted. Voting > members are listed here: https://cabforum.org/members/ > > In order for the motion to be adopted, two thirds or more of the votes > cast by members in the CA category and greater than 50% of the votes cast > by members in the browser category must be in favor. Quorum is currently > nine (9) members? at least nine members must participate in the ballot, > either by voting in favor, voting against, or abstaining. > > > > > > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From md at ssc.lt Tue Feb 17 13:20:22 2015 From: md at ssc.lt (Moudrick M. Dadashov) Date: Tue, 17 Feb 2015 15:20:22 +0200 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names In-Reply-To: References: Message-ID: <54E34016.1010101@ssc.lt> SSC votes: "Yes". Thanks, M.D On 2/17/2015 3:08 PM, haavardm at work wrote: > Opera votes YES > > > On Tue, Feb 10, 2015 at 7:38 PM, Jeremy Rowley > > wrote: > > *Here?s the ballot with the two typos fixed:* > > Applicants want a CA-signed .onion address for several reasons, > including: > > - Powerful web platform features are restricted to secure origins, > which are currently not available to onion names (in part, because > of the lack of IANA registration). Permitting EV certs for onion > names will help provide a secure origin for the service, moving > onion towards use of powerful web platform features. > > - Currently, access to .onion names over https from a standard > browser results in the standard existing 'Invalid Certificate' > warning. Training users to click through security warnings lowers > the value of these warnings and will cause users to miss important > security information. Removing these warnings for the user, > through use of a digital certificate, will help users recognize > and avoid real MITM attacks. > > - The public needs attribution of ownership of the .onion address > to differentiate onion services, including potential phishing > services. Because onion names are not easily recognizable strings, > providing the public with additional information about the > operator has significant security improvements, especially in > regions where use of the incorrect name could have lethal > consequences. > > The following motion has been proposed by Jeremy Rowley of > DigiCert and endorsed by Ryan Sleevi of Google and Wayne Thayer of > GoDaddy. > > --------------------- > > Motion Starts > > --------------------- > > 1) Amend Section 9.2.1 of the Baseline Requirements v. 1.2.3 as > follows: > > 9.2.1 Subject Alternative Name Extension > > Certificate Field: extensions:subjectAltName > > Required/Optional: Required > > Contents: This 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. > The CA MUST confirm that the Applicant controls the > Fully-Qualified Domain Name or IP address or has been granted the > right to use it by the Domain Name Registrant or IP address > assignee, as appropriate. > > Wildcard FQDNs are permitted. As of the Effective Date of these > Requirements, prior to the issuance of a Certificate with a > subjectAlternativeName extension or Subject commonName field > containing a Reserved IP Address or Internal Name, the CA SHALL > notify the Applicant that the use of such Certificates has been > deprecated by the CA / Browser Forum and that the practice will be > eliminated by October 2016. Also as of the Effective Date, the CA > SHALL NOT issue a certificate with an Expiry Date later than 1 > November 2015 with a subjectAlternativeName extension or Subject > commonName field containing a Reserved IP Address or Internal > Name. Effective 1 October 2016, CAs SHALL revoke all unexpired > Certificates whose subjectAlternativeName extension or Subject > commonName field contains a Reserved IP Address or Internal Name. > _Effective May 1, 2015, each CA SHALL revoke all unexpired > Certificates with an Internal Name using onion as the right-most > label in an entry in the subjectAltName Extension or commonName > field unless such Certificate was issued in accordance with > Appendix F of the EV Guidelines._ > > 2) Amend Section 9.2.2 and 11.7.1 of the Guidelines for the > Issuance and Management of Extended Validation Certificates v1.5.2 > as follows: > > 9.2.2. Subject Alternative Name Extension Certificate field: > subjectAltName:dNSName > > Required/Optional: Required > > Contents: This extension MUST contain one or more host Domain > Name(s) owned or controlled by the Subject and to be associated > with the Subject?s server. Such server MAY be owned and operated > by the Subject or another entity (e.g., a hosting service). > Wildcard certificates are not allowed for EV Certificates_except > as permitted under Appendix F_. > > 11.7 Verification of Applicant?s Domain Name > > 11.7.1. Verification Requirements > > (1) For each Fully-Qualified Domain Name listed in a Certificate, > other than a Domain Name with .onion in the right-most label of > the Domain Name, the CA SHALL confirm that, as of the date the > Certificate was issued, the Applicant (or the Applicant?s Parent > Company, Subsidiary Company, or Affiliate, collectively referred > to as ?Applicant? for the purposes of this section) either is the > Domain Name Registrant or has control over the FQDN using a > procedure specified in Section 11.1.1 of the Baseline > Requirements, except that a CA MAY NOT verify a domain using the > procedure described 11.1.1(7). _For a Certificate issued to a > Domain Name with .onion in the right-most label of the Domain > Name, the CA SHALL confirm that, as of the date the Certificate > was issued, the Applicant?s control over the .onion Domain Name in > accordance with Appendix F._ > > (2) Mixed Character Set Domain Names: EV Certificates MAY include > Domain Names containing mixed character sets only in compliance > with the rules set forth by the domain registrar. The CA MUST > visually compare any Domain Names with mixed character sets with > known high risk domains. If a similarity is found, then the EV > Certificate Request MUST be flagged as High Risk. The CA must > perform reasonably appropriate additional authentication and > verification to be certain beyond reasonable doubt that the > Applicant and the target in question are the same organization. > > 3) Add a new Appendix F to the Guidelines for the Issuance and > Management of Extended Validation Certificates v1.5.2: > > Appendix F ? Issuance of Certificates for .onion Domain Names > > A CA may issue an EV Certificate with .onion in the right-most > label of the Domain Name provided that issuance complies with the > requirements set forth in this Appendix: > > 1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) > > The CAB Forum has created an extension of the TBSCertificate for > use in conveying hashes of keys related to .onion addresses. The > Tor Service Descriptor Hash extension has the following format: > > cabf-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 } > > TorServiceDescriptorSyntax ::= > > SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash > > TorServiceDescriptorHash:: = SEQUENCE { > > onionURI UTF8String > > algorithm AlgorithmIdentifier > > subjectPublicKeyHash BIT STRING } > > Where the AlgorithmIdentifier is a hashing algorithm (defined in > RFC 6234) performed over the DER-encoding of an ASN.1 > SubjectPublicKey of the .onion service and SubjectPublicKeyHash is > the hash output. > > 2. The CA MUST verify the Applicant?s control over the .onion > Domain Name using one of the following: > > a. The CA MAY verify the Applicant?s control over the .onion > service by posting a specific value at a well-known URL under > RFC5785. > > b. The CA MAY verify the Applicant?s control over the .onion > service by having the Applicant provide a Certificate Request > signed using the .onion public key if the Attributes section of > the certificationRequestInfo contains: > > (i) A caSigningNonce attribute that 1) contains a single value > with at least 64-bits of entropy, 2) is generated by the CA, and > 3) delivered to the Applicant through a Verified Method of > Communication and > > (ii) An applicantSigningNonce attribute that 1) contains a single > value with at least 64-bits of entropy and 2) is generated by the > Applicant. > > The signing nonce attributes have the following format: > > caSigningNonce ATTRIBUTE ::= { > > WITH SYNTAX OCTET STRING > > EQUALITY MATCHING RULE octetStringMatch > > SINGLE VALUE TRUE > > ID { cabf-caSigningNonce } > > } > > cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } > > applicantSigningNonce ATTRIBUTE ::= { > > WITH SYNTAX OCTET STRING > > EQUALITY MATCHING RULE octetStringMatch > > SINGLE VALUE TRUE > > ID { cabf-applicantSigningNonce } > > } > > cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 } > > 4. Each Certificate that includes a Domain Name where .onion is in > the right-most label of the Domain Name MUST conform to the > requirements of these Guidelines, including the content > requirements in Section 9 and Appendix B of the Baseline > Requirements, except that the CA MAY include a wildcard character > in the Subject Alternative Name Extension and Subject Common Name > Field as the left-most character in the .onion Domain Name > provided inclusion of the wildcard character complies with Section > 11.1.3 of the Baseline Requirements. > > 5. CAs MUST NOT issue a Certificate that includes a Domain Name > where .onion is in the right-most label of the Domain Name with a > validity period longer than 15 months. Despite Section 9.2.1 of > the Baseline Requirements deprecating the use of Internal Names, a > CA MAY issue a Certificate containing an .onion name with an > expiration date later than 1 November 2015 after (and only if) > .onion is officially recognized by the IESG as a reserved TLD. > > 6. On or before May 1, 2015, each CA MUST revoke all Certificates > issued with the Subject Alternative Name extension or Common Name > field that includes a Domain Name where .onion is in the > right-most label of the Domain Name unless the Certificate was > issued in compliance with this Appendix F. > > ---- > > Motion Ends > > ----- > > The review period for this ballot shall commence at 2200 UTC on > Thursday, 4 February 2015, and will close at 2200 UTC on Thursday, > 11 February 2015. Unless the motion is withdrawn during the review > period, the voting period will start immediately thereafter and > will close at 2200 UTC on Monday, 18 February 2015. Votes must be > cast by posting an on-list reply to this thread. > > A vote in favor of the motion must indicate a clear 'yes' in the > response. A vote against must indicate a clear 'no' in the > response. A vote to abstain must indicate a clear 'abstain' in the > response. Unclear responses will not be counted. The latest vote > received from any representative of a voting member before the > close of the voting period will be counted. Voting members are > listed here: https://cabforum.org/members/ > > In order for the motion to be adopted, two thirds or more of the > votes cast by members in the CA category and greater than 50% of > the votes cast by members in the browser category must be in > favor. Quorum is currently nine (9) members? at least nine members > must participate in the ballot, either by voting in favor, voting > against, or abstaining. > > > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public > > > > > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3653 bytes Desc: S/MIME Cryptographic Signature URL: From realsky at cht.com.tw Tue Feb 17 13:56:23 2015 From: realsky at cht.com.tw (=?big5?B?s6+l37hz?=) Date: Tue, 17 Feb 2015 21:56:23 +0800 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names In-Reply-To: References: Message-ID: <004001d04ab9$842e5ae0$8c8b10a0$@cht.com.tw> Chunghwa Telecom Co., Ltd. vote ?No? not because we object supporting .onion names but because we think that a method suggested in the Appendix F for verifying the Applicant?s control over the .onion Domain Name has security problem. In the Appendix F, the method 2.b says 'The CA MAY verify the Applicant 's control over the .onion service by having the Applicant provide a Certificate Request signed using the .onion public key ?'. What we concerns is that if the .onion private key used to sign the PKCS#10 SSL Certificate Request is not the same one as the SSL server 's private key, it will cause security problem. For security reason, PKCS#10 Certificate Request need to be signed by the private key corresponding to the public key contained in the CertificationRequestInfo. Please refer to Note 2 of section 3 of RFC 2986 (the PKCS#10 standard), where it explains the security concern. Note 2 of section 3 of RFC 2986 is extracted as below: Note 2 - The signature on the certification request prevents an entity from requesting a certificate with another party's public key. Such an attack would give the entity the minor ability to pretend to be the originator of any message signed by the other party. This attack is significant only if the entity does not know the message being signed and the signed part of the message does not identify the signer. The entity would still not be able to decrypt messages intended for the other party, of course. Sincerely Yours, Li-Chun CHEN Engineer CISSP, CISA, CISM, PMP, Information & Communication Security Dept. Data Communication Business Group Chunghwa Telecom Co. Ltd. realsky at cht.com.tw +886-2-2344-4820#4025 From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Wednesday, February 11, 2015 2:39 AM To: public at cabforum.org Subject: [cabfpub] Ballot 144 - Validation rules for .onion names Here?s the ballot with the two typos fixed: Applicants want a CA-signed .onion address for several reasons, including: - Powerful web platform features are restricted to secure origins, which are currently not available to onion names (in part, because of the lack of IANA registration). Permitting EV certs for onion names will help provide a secure origin for the service, moving onion towards use of powerful web platform features. - Currently, access to .onion names over https from a standard browser results in the standard existing 'Invalid Certificate' warning. Training users to click through security warnings lowers the value of these warnings and will cause users to miss important security information. Removing these warnings for the user, through use of a digital certificate, will help users recognize and avoid real MITM attacks. - The public needs attribution of ownership of the .onion address to differentiate onion services, including potential phishing services. Because onion names are not easily recognizable strings, providing the public with additional information about the operator has significant security improvements, especially in regions where use of the incorrect name could have lethal consequences. The following motion has been proposed by Jeremy Rowley of DigiCert and endorsed by Ryan Sleevi of Google and Wayne Thayer of GoDaddy. --------------------- Motion Starts --------------------- 1) Amend Section 9.2.1 of the Baseline Requirements v. 1.2.3 as follows: 9.2.1 Subject Alternative Name Extension Certificate Field: extensions:subjectAltName Required/Optional: Required Contents: This 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. The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate. Wildcard FQDNs are permitted. As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name, the CA SHALL notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016. Also as of the Effective Date, the CA SHALL NOT issue a certificate with an Expiry Date later than 1 November 2015 with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name. Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Name. Effective May 1, 2015, each CA SHALL revoke all unexpired Certificates with an Internal Name using onion as the right-most label in an entry in the subjectAltName Extension or commonName field unless such Certificate was issued in accordance with Appendix F of the EV Guidelines. 2) Amend Section 9.2.2 and 11.7.1 of the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2 as follows: 9.2.2. Subject Alternative Name Extension Certificate field: subjectAltName: dNSName Required/Optional: Required Contents: This extension MUST contain one or more host Domain Name(s) owned or controlled by the Subject and to be associated with the Subject?s server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). Wildcard certificates are not allowed for EV Certificates except as permitted under Appendix F. 11.7 Verification of Applicant?s Domain Name 11.7.1. Verification Requirements (1) For each Fully-Qualified Domain Name listed in a Certificate, other than a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant (or the Applicant?s Parent Company, Subsidiary Company, or Affiliate, collectively referred to as ?Applicant? for the purposes of this section) either is the Domain Name Registrant or has control over the FQDN using a procedure specified in Section 11.1.1 of the Baseline Requirements, except that a CA MAY NOT verify a domain using the procedure described 11.1.1(7). For a Certificate issued to a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant?s control over the .onion Domain Name in accordance with Appendix F. (2) Mixed Character Set Domain Names: EV Certificates MAY include Domain Names containing mixed character sets only in compliance with the rules set forth by the domain registrar. The CA MUST visually compare any Domain Names with mixed character sets with known high risk domains. If a similarity is found, then the EV Certificate Request MUST be flagged as High Risk. The CA must perform reasonably appropriate additional authentication and verification to be certain beyond reasonable doubt that the Applicant and the target in question are the same organization. 3) Add a new Appendix F to the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2: Appendix F ? Issuance of Certificates for .onion Domain Names A CA may issue an EV Certificate with .onion in the right-most label of the Domain Name provided that issuance complies with the requirements set forth in this Appendix: 1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) The CAB Forum has created an extension of the TBSCertificate for use in conveying hashes of keys related to .onion addresses. The Tor Service Descriptor Hash extension has the following format: cabf-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 } TorServiceDescriptorSyntax ::= SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash TorServiceDescriptorHash:: = SEQUENCE { onionURI UTF8String algorithm AlgorithmIdentifier subjectPublicKeyHash BIT STRING } Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 6234) performed over the DER-encoding of an ASN.1 SubjectPublicKey of the .onion service and SubjectPublicKeyHash is the hash output. 2. The CA MUST verify the Applicant?s control over the .onion Domain Name using one of the following: a. The CA MAY verify the Applicant?s control over the .onion service by posting a specific value at a well-known URL under RFC5785. b. The CA MAY verify the Applicant?s control over the .onion service by having the Applicant provide a Certificate Request signed using the .onion public key if the Attributes section of the certificationRequestInfo contains: (i) A caSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy, 2) is generated by the CA, and 3) delivered to the Applicant through a Verified Method of Communication and (ii) An applicantSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy and 2) is generated by the Applicant. The signing nonce attributes have the following format: caSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-caSigningNonce } } cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } applicantSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-applicantSigningNonce } } cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 } 4. Each Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name MUST conform to the requirements of these Guidelines, including the content requirements in Section 9 and Appendix B of the Baseline Requirements, except that the CA MAY include a wildcard character in the Subject Alternative Name Extension and Subject Common Name Field as the left-most character in the .onion Domain Name provided inclusion of the wildcard character complies with Section 11.1.3 of the Baseline Requirements. 5. CAs MUST NOT issue a Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name with a validity period longer than 15 months. Despite Section 9.2.1 of the Baseline Requirements deprecating the use of Internal Names, a CA MAY issue a Certificate containing an .onion name with an expiration date later than 1 November 2015 after (and only if) .onion is officially recognized by the IESG as a reserved TLD. 6. On or before May 1, 2015, each CA MUST revoke all Certificates issued with the Subject Alternative Name extension or Common Name field that includes a Domain Name where .onion is in the right-most label of the Domain Name unless the Certificate was issued in compliance with this Appendix F. ---- Motion Ends ----- The review period for this ballot shall commence at 2200 UTC on Thursday, 4 February 2015, and will close at 2200 UTC on Thursday, 11 February 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on Monday, 18 February 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members? at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6450 bytes Desc: not available URL: From robert.vande.rijt at logius.nl Tue Feb 17 14:00:11 2015 From: robert.vande.rijt at logius.nl (Rijt, R.A. van de (Robert) - Logius) Date: Tue, 17 Feb 2015 14:00:11 +0000 Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group In-Reply-To: References: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> Message-ID: Logius PKIoverheid votes yes. Regards, Robert From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Wednesday, February 4, 2015 4:05 PM To: CABFPub Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group Ballot 143 - Formalization of validation working group ---- Reason ---- In order to address validation issues and inconsistencies in both the SSL Baseline Requirements and the EV Guidelines, the CAB Forum has held an informal working group previously referred to as the Extended Validation Working Group now known as the Validation Working Group, would like to modify its scope to include validation in the Baseline Requirements as well as the EV Guidelines. Jeremy Rowley of DigiCert made the following motion, which was endorsed by Rich Smith of Comodo and Kirk Hall of TrendMicro ---- Motion begins ---- The CA-Browser Forum formally establishes the Validation Working Group as an official working group of the CAB Forum, replacing the previous informal EV working group. The scope of this working group is to address issues arising under adopted CAB Forum standards related to the validation of certificate information and the inclusion of information in certificates. Scope: The Validation Working Group will consider all matters relating to the validation and inclusion of information in certificates under adopted CAB Forum guidelines. Deliverables: The Working Group shall produce one or more documents offering options to the Forum for validation within the scope defined above. ---- Motion Ends ---- The review period for this ballot shall commence at 2200 UTC on 5 Feb 2015, and will close at 2200 UTC on 11 Feb 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on 18 Feb 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. ________________________________ Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten. This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages. . -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom at ritter.vg Tue Feb 17 15:13:30 2015 From: tom at ritter.vg (Tom Ritter) Date: Tue, 17 Feb 2015 09:13:30 -0600 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names In-Reply-To: <004001d04ab9$842e5ae0$8c8b10a0$@cht.com.tw> References: <004001d04ab9$842e5ae0$8c8b10a0$@cht.com.tw> Message-ID: On 17 February 2015 at 07:56, ??? wrote: > > > Chunghwa Telecom Co., Ltd. vote ?No? not because we object supporting > .onion names but because we think that a method suggested in the Appendix F > for verifying the Applicant?s control over the .onion Domain Name has > security problem. In the Appendix F, the method 2.b says 'The CA MAY verify > the Applicant 's control over the .onion service by having the Applicant > provide a Certificate Request signed using the .onion public key ?'. What we > concerns is that if the .onion private key used to sign the PKCS#10 SSL > Certificate Request is not the same one as the SSL server 's private key, it > will cause security problem. For security reason, PKCS#10 Certificate > Request need to be signed by the private key corresponding to the public key > contained in the CertificationRequestInfo. Please refer to Note 2 of section > 3 of RFC 2986 (the PKCS#10 standard), where it explains the security > concern. Note 2 of section 3 of RFC 2986 is extracted as below: Hi Li-Chun CHEN, It was always my understanding that this CSR (signed by the onion key) was in ADDITION to the CSR signed with the SSL private key, not in place of. I guess the text does not bear this out clearly, apologies. Otherwise, yes I agree that would be a problem. (The applicant could get a certificate for a .onion address they control but a SSL private key they do not. Doesn't really introduce a security vulnerability for anyone but themselves, but clearly not correct issuance.) -tom From erwann.abalea at opentrust.com Tue Feb 17 16:38:05 2015 From: erwann.abalea at opentrust.com (Erwann Abalea) Date: Tue, 17 Feb 2015 17:38:05 +0100 Subject: [cabfpub] Ballot 144 -.onion domains In-Reply-To: References: <54DD1DED.4090105@mozilla.org> <54DD289E.8040304@mozilla.org> <54DDC98E.8020907@mozilla.org> Message-ID: <54E36E6D.8070106@opentrust.com> Bonjour, Coming back on this email, as it seems it hasn't been fully answered. Le 13/02/2015 17:28, kirk_hall at trendmicro.com a ?crit : > > [...] > > I have to circle back to ?Why are we doing this?? > > ?Tor users want to visit websites anonymously. [That sounds like > something CAs should support if possible] > > ?Website owners do **not** want anonymity ? in fact, just the > opposite. They want EV certs with their identity information included > that will work for Tor users. > > ?For some reason, regular TLD certs (like .com certs) won?t work after > Tor users go through the Tor blender. [Does anyone know why that is > the case?] > A TorBrowser user can connect to https://www.facebook.com, it will have the nice padlock icon, and all the packets will go through the Tor mesh network. A "{elinks,chrome,IE,whatever}+tor+socks5-in-between" user can do the same action with the same guarantees. > ?But for some reason, Internal Name .onion certs **do** work for Tor > users after they go through the Tor blender. [Does anyone know why > this is so?] > > ?Tor does not want to apply for .onion as a TLD, and does not want to > be the registrar for .onion [Why not? That would solve everything by > making .onion a TLD, so all the current CA rules could apply. And > remember, website users are not looking for anonymity in their certs ? > they want EV certs with their identity displayed prominently in the > browsers.] > > ?The Tor process for assigning .onion domains does not require domains > to be unique. > IIUC, asking Tor to connect to some identified server creates a circuit, involving at least 3 nodes (entry, relay+, exit) to provide some anonymity. Asking Tor to connect to a .onion address involves requesting the nearest catalog of hidden services to get the Tor node hosting this hidden service, and the circuit will never go through an exit node, providing confidentiality. This confidentiality is already offered by TLS. -- Erwann ABALEA -------------- next part -------------- An HTML attachment was scrubbed... URL: From robin at comodo.com Tue Feb 17 17:04:09 2015 From: robin at comodo.com (Robin Alden) Date: Tue, 17 Feb 2015 17:04:09 -0000 Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group In-Reply-To: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> References: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> Message-ID: <0a4901d04ad3$bef7f360$3ce7da20$@comodo.com> Comodo votes 'Yes'. Regards Robin Alden Comodo From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: 04 February 2015 21:05 To: CABFPub Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group Ballot 143 - Formalization of validation working group ---- Reason ---- In order to address validation issues and inconsistencies in both the SSL Baseline Requirements and the EV Guidelines, the CAB Forum has held an informal working group previously referred to as the Extended Validation Working Group now known as the Validation Working Group, would like to modify its scope to include validation in the Baseline Requirements as well as the EV Guidelines. Jeremy Rowley of DigiCert made the following motion, which was endorsed by Rich Smith of Comodo and Kirk Hall of TrendMicro ---- Motion begins ---- The CA-Browser Forum formally establishes the Validation Working Group as an official working group of the CAB Forum, replacing the previous informal EV working group. The scope of this working group is to address issues arising under adopted CAB Forum standards related to the validation of certificate information and the inclusion of information in certificates. Scope: The Validation Working Group will consider all matters relating to the validation and inclusion of information in certificates under adopted CAB Forum guidelines. Deliverables: The Working Group shall produce one or more documents offering options to the Forum for validation within the scope defined above. ---- Motion Ends ---- The review period for this ballot shall commence at 2200 UTC on 5 Feb 2015, and will close at 2200 UTC on 11 Feb 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on 18 Feb 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5156 bytes Desc: not available URL: From JRandall at trustwave.com Tue Feb 17 17:10:59 2015 From: JRandall at trustwave.com (John Randall) Date: Tue, 17 Feb 2015 17:10:59 +0000 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names Message-ID: Trustwave ABSTAINS Cheers- John From: Miskovic Peter > Date: Monday, February 16, 2015 at 8:34 AM To: "public at cabforum.org" > Subject: Re: [cabfpub] Ballot 144 - Validation rules for .onion names Ballot 144 - Validation rules for .onion names: Disig abstains. Regards, Peter Miskovic From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Tuesday, February 10, 2015 7:39 PM To: public at cabforum.org Subject: [cabfpub] Ballot 144 - Validation rules for .onion names Here?s the ballot with the two typos fixed: Applicants want a CA-signed .onion address for several reasons, including: - Powerful web platform features are restricted to secure origins, which are currently not available to onion names (in part, because of the lack of IANA registration). Permitting EV certs for onion names will help provide a secure origin for the service, moving onion towards use of powerful web platform features. - Currently, access to .onion names over https from a standard browser results in the standard existing 'Invalid Certificate' warning. Training users to click through security warnings lowers the value of these warnings and will cause users to miss important security information. Removing these warnings for the user, through use of a digital certificate, will help users recognize and avoid real MITM attacks. - The public needs attribution of ownership of the .onion address to differentiate onion services, including potential phishing services. Because onion names are not easily recognizable strings, providing the public with additional information about the operator has significant security improvements, especially in regions where use of the incorrect name could have lethal consequences. The following motion has been proposed by Jeremy Rowley of DigiCert and endorsed by Ryan Sleevi of Google and Wayne Thayer of GoDaddy. --------------------- Motion Starts --------------------- 1) Amend Section 9.2.1 of the Baseline Requirements v. 1.2.3 as follows: 9.2.1 Subject Alternative Name Extension Certificate Field: extensions:subjectAltName Required/Optional: Required Contents: This 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. The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate. Wildcard FQDNs are permitted. As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name, the CA SHALL notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016. Also as of the Effective Date, the CA SHALL NOT issue a certificate with an Expiry Date later than 1 November 2015 with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name. Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Name. Effective May 1, 2015, each CA SHALL revoke all unexpired Certificates with an Internal Name using onion as the right-most label in an entry in the subjectAltName Extension or commonName field unless such Certificate was issued in accordance with Appendix F of the EV Guidelines. 2) Amend Section 9.2.2 and 11.7.1 of the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2 as follows: 9.2.2. Subject Alternative Name Extension Certificate field: subjectAltName:dNSName Required/Optional: Required Contents: This extension MUST contain one or more host Domain Name(s) owned or controlled by the Subject and to be associated with the Subject?s server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). Wildcard certificates are not allowed for EV Certificates except as permitted under Appendix F. 11.7 Verification of Applicant?s Domain Name 11.7.1. Verification Requirements (1) For each Fully-Qualified Domain Name listed in a Certificate, other than a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant (or the Applicant?s Parent Company, Subsidiary Company, or Affiliate, collectively referred to as ?Applicant? for the purposes of this section) either is the Domain Name Registrant or has control over the FQDN using a procedure specified in Section 11.1.1 of the Baseline Requirements, except that a CA MAY NOT verify a domain using the procedure described 11.1.1(7). For a Certificate issued to a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant?s control over the .onion Domain Name in accordance with Appendix F. (2) Mixed Character Set Domain Names: EV Certificates MAY include Domain Names containing mixed character sets only in compliance with the rules set forth by the domain registrar. The CA MUST visually compare any Domain Names with mixed character sets with known high risk domains. If a similarity is found, then the EV Certificate Request MUST be flagged as High Risk. The CA must perform reasonably appropriate additional authentication and verification to be certain beyond reasonable doubt that the Applicant and the target in question are the same organization. 3) Add a new Appendix F to the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2: Appendix F ? Issuance of Certificates for .onion Domain Names A CA may issue an EV Certificate with .onion in the right-most label of the Domain Name provided that issuance complies with the requirements set forth in this Appendix: 1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) The CAB Forum has created an extension of the TBSCertificate for use in conveying hashes of keys related to .onion addresses. The Tor Service Descriptor Hash extension has the following format: cabf-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 } TorServiceDescriptorSyntax ::= SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash TorServiceDescriptorHash:: = SEQUENCE { onionURI UTF8String algorithm AlgorithmIdentifier subjectPublicKeyHash BIT STRING } Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 6234) performed over the DER-encoding of an ASN.1 SubjectPublicKey of the .onion service and SubjectPublicKeyHash is the hash output. 2. The CA MUST verify the Applicant?s control over the .onion Domain Name using one of the following: a. The CA MAY verify the Applicant?s control over the .onion service by posting a specific value at a well-known URL under RFC5785. b. The CA MAY verify the Applicant?s control over the .onion service by having the Applicant provide a Certificate Request signed using the .onion public key if the Attributes section of the certificationRequestInfo contains: (i) A caSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy, 2) is generated by the CA, and 3) delivered to the Applicant through a Verified Method of Communication and (ii) An applicantSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy and 2) is generated by the Applicant. The signing nonce attributes have the following format: caSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-caSigningNonce } } cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } applicantSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-applicantSigningNonce } } cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 } 4. Each Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name MUST conform to the requirements of these Guidelines, including the content requirements in Section 9 and Appendix B of the Baseline Requirements, except that the CA MAY include a wildcard character in the Subject Alternative Name Extension and Subject Common Name Field as the left-most character in the .onion Domain Name provided inclusion of the wildcard character complies with Section 11.1.3 of the Baseline Requirements. 5. CAs MUST NOT issue a Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name with a validity period longer than 15 months. Despite Section 9.2.1 of the Baseline Requirements deprecating the use of Internal Names, a CA MAY issue a Certificate containing an .onion name with an expiration date later than 1 November 2015 after (and only if) .onion is officially recognized by the IESG as a reserved TLD. 6. On or before May 1, 2015, each CA MUST revoke all Certificates issued with the Subject Alternative Name extension or Common Name field that includes a Domain Name where .onion is in the right-most label of the Domain Name unless the Certificate was issued in compliance with this Appendix F. ---- Motion Ends ----- The review period for this ballot shall commence at 2200 UTC on Thursday, 4 February 2015, and will close at 2200 UTC on Thursday, 11 February 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on Monday, 18 February 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members? at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. ________________________________ This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. -------------- next part -------------- An HTML attachment was scrubbed... URL: From S.Davidson at quovadisglobal.com Tue Feb 17 17:24:13 2015 From: S.Davidson at quovadisglobal.com (Stephen Davidson) Date: Tue, 17 Feb 2015 17:24:13 +0000 Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group In-Reply-To: References: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> Message-ID: QuoVadis votes yes. Best, Stephen From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Wednesday, February 4, 2015 4:05 PM To: CABFPub Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group Ballot 143 - Formalization of validation working group ---- Reason ---- In order to address validation issues and inconsistencies in both the SSL Baseline Requirements and the EV Guidelines, the CAB Forum has held an informal working group previously referred to as the Extended Validation Working Group now known as the Validation Working Group, would like to modify its scope to include validation in the Baseline Requirements as well as the EV Guidelines. Jeremy Rowley of DigiCert made the following motion, which was endorsed by Rich Smith of Comodo and Kirk Hall of TrendMicro ---- Motion begins ---- The CA-Browser Forum formally establishes the Validation Working Group as an official working group of the CAB Forum, replacing the previous informal EV working group. The scope of this working group is to address issues arising under adopted CAB Forum standards related to the validation of certificate information and the inclusion of information in certificates. Scope: The Validation Working Group will consider all matters relating to the validation and inclusion of information in certificates under adopted CAB Forum guidelines. Deliverables: The Working Group shall produce one or more documents offering options to the Forum for validation within the scope defined above. ---- Motion Ends ---- The review period for this ballot shall commence at 2200 UTC on 5 Feb 2015, and will close at 2200 UTC on 11 Feb 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on 18 Feb 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. _____ Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten. This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages. . -------------- next part -------------- An HTML attachment was scrubbed... URL: From robin at comodo.com Tue Feb 17 17:39:45 2015 From: robin at comodo.com (Robin Alden) Date: Tue, 17 Feb 2015 17:39:45 -0000 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names In-Reply-To: References: Message-ID: <0afe01d04ad8$b86d3320$29479960$@comodo.com> Comodo abstains. Regards Robin Alden Comodo From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: 10 February 2015 18:39 To: public at cabforum.org Subject: [cabfpub] Ballot 144 - Validation rules for .onion names Here's the ballot with the two typos fixed: Applicants want a CA-signed .onion address for several reasons, including: - Powerful web platform features are restricted to secure origins, which are currently not available to onion names (in part, because of the lack of IANA registration). Permitting EV certs for onion names will help provide a secure origin for the service, moving onion towards use of powerful web platform features. - Currently, access to .onion names over https from a standard browser results in the standard existing 'Invalid Certificate' warning. Training users to click through security warnings lowers the value of these warnings and will cause users to miss important security information. Removing these warnings for the user, through use of a digital certificate, will help users recognize and avoid real MITM attacks. - The public needs attribution of ownership of the .onion address to differentiate onion services, including potential phishing services. Because onion names are not easily recognizable strings, providing the public with additional information about the operator has significant security improvements, especially in regions where use of the incorrect name could have lethal consequences. The following motion has been proposed by Jeremy Rowley of DigiCert and endorsed by Ryan Sleevi of Google and Wayne Thayer of GoDaddy. --------------------- Motion Starts --------------------- 1) Amend Section 9.2.1 of the Baseline Requirements v. 1.2.3 as follows: 9.2.1 Subject Alternative Name Extension Certificate Field: extensions:subjectAltName Required/Optional: Required Contents: This 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. The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate. Wildcard FQDNs are permitted. As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name, the CA SHALL notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016. Also as of the Effective Date, the CA SHALL NOT issue a certificate with an Expiry Date later than 1 November 2015 with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name. Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Name. Effective May 1, 2015, each CA SHALL revoke all unexpired Certificates with an Internal Name using onion as the right-most label in an entry in the subjectAltName Extension or commonName field unless such Certificate was issued in accordance with Appendix F of the EV Guidelines. 2) Amend Section 9.2.2 and 11.7.1 of the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2 as follows: 9.2.2. Subject Alternative Name Extension Certificate field: subjectAltName:dNSName Required/Optional: Required Contents: This extension MUST contain one or more host Domain Name(s) owned or controlled by the Subject and to be associated with the Subject's server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). Wildcard certificates are not allowed for EV Certificates except as permitted under Appendix F. 11.7 Verification of Applicant's Domain Name 11.7.1. Verification Requirements (1) For each Fully-Qualified Domain Name listed in a Certificate, other than a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant (or the Applicant's Parent Company, Subsidiary Company, or Affiliate, collectively referred to as "Applicant" for the purposes of this section) either is the Domain Name Registrant or has control over the FQDN using a procedure specified in Section 11.1.1 of the Baseline Requirements, except that a CA MAY NOT verify a domain using the procedure described 11.1.1(7). For a Certificate issued to a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant's control over the .onion Domain Name in accordance with Appendix F. (2) Mixed Character Set Domain Names: EV Certificates MAY include Domain Names containing mixed character sets only in compliance with the rules set forth by the domain registrar. The CA MUST visually compare any Domain Names with mixed character sets with known high risk domains. If a similarity is found, then the EV Certificate Request MUST be flagged as High Risk. The CA must perform reasonably appropriate additional authentication and verification to be certain beyond reasonable doubt that the Applicant and the target in question are the same organization. 3) Add a new Appendix F to the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2: Appendix F - Issuance of Certificates for .onion Domain Names A CA may issue an EV Certificate with .onion in the right-most label of the Domain Name provided that issuance complies with the requirements set forth in this Appendix: 1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) The CAB Forum has created an extension of the TBSCertificate for use in conveying hashes of keys related to .onion addresses. The Tor Service Descriptor Hash extension has the following format: cabf-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 } TorServiceDescriptorSyntax ::= SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash TorServiceDescriptorHash:: = SEQUENCE { onionURI UTF8String algorithm AlgorithmIdentifier subjectPublicKeyHash BIT STRING } Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 6234) performed over the DER-encoding of an ASN.1 SubjectPublicKey of the .onion service and SubjectPublicKeyHash is the hash output. 2. The CA MUST verify the Applicant's control over the .onion Domain Name using one of the following: a. The CA MAY verify the Applicant's control over the .onion service by posting a specific value at a well-known URL under RFC5785. b. The CA MAY verify the Applicant's control over the .onion service by having the Applicant provide a Certificate Request signed using the .onion public key if the Attributes section of the certificationRequestInfo contains: (i) A caSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy, 2) is generated by the CA, and 3) delivered to the Applicant through a Verified Method of Communication and (ii) An applicantSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy and 2) is generated by the Applicant. The signing nonce attributes have the following format: caSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-caSigningNonce } } cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } applicantSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-applicantSigningNonce } } cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 } 4. Each Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name MUST conform to the requirements of these Guidelines, including the content requirements in Section 9 and Appendix B of the Baseline Requirements, except that the CA MAY include a wildcard character in the Subject Alternative Name Extension and Subject Common Name Field as the left-most character in the .onion Domain Name provided inclusion of the wildcard character complies with Section 11.1.3 of the Baseline Requirements. 5. CAs MUST NOT issue a Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name with a validity period longer than 15 months. Despite Section 9.2.1 of the Baseline Requirements deprecating the use of Internal Names, a CA MAY issue a Certificate containing an .onion name with an expiration date later than 1 November 2015 after (and only if) .onion is officially recognized by the IESG as a reserved TLD. 6. On or before May 1, 2015, each CA MUST revoke all Certificates issued with the Subject Alternative Name extension or Common Name field that includes a Domain Name where .onion is in the right-most label of the Domain Name unless the Certificate was issued in compliance with this Appendix F. ---- Motion Ends ----- The review period for this ballot shall commence at 2200 UTC on Thursday, 4 February 2015, and will close at 2200 UTC on Thursday, 11 February 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on Monday, 18 February 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5156 bytes Desc: not available URL: From dtokgoz at e-tugra.com.tr Wed Feb 18 09:10:27 2015 From: dtokgoz at e-tugra.com.tr (=?iso-8859-9?Q?Davut_Tokg=F6z?=) Date: Wed, 18 Feb 2015 11:10:27 +0200 Subject: [cabfpub] Ballots 143 and 144 In-Reply-To: <54DDC2A3.2000200@staff.aruba.it> References: <763539E260C37C46A0D6B340B5434C3B0ADAE0DE@AEX06.ejsarea.net> <54DDC2A3.2000200@staff.aruba.it> Message-ID: <019301d04b5a$bce15c10$36a41430$@e-tugra.com.tr> E-tugra votes yes for ballot 143 and abstains for ballot 144 Davut Tokg?z -------------- next part -------------- An HTML attachment was scrubbed... URL: From Dean_Coclin at symantec.com Wed Feb 18 15:40:40 2015 From: Dean_Coclin at symantec.com (Dean Coclin) Date: Wed, 18 Feb 2015 07:40:40 -0800 Subject: [cabfpub] Voting Reminder Message-ID: <14D026C7F297AD44AC82578DD818CDD038EF1EAA5C@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> Reminder: Voting closes later today on ballots 143 and 144. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6130 bytes Desc: not available URL: From Mads.Henriksveen at buypass.no Wed Feb 18 15:40:50 2015 From: Mads.Henriksveen at buypass.no (Mads Egil Henriksveen) Date: Wed, 18 Feb 2015 15:40:50 +0000 Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group In-Reply-To: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> References: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> Message-ID: Buypass votes YES Regards Mads From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: 4. februar 2015 22:05 To: CABFPub Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group Ballot 143 - Formalization of validation working group ---- Reason ---- In order to address validation issues and inconsistencies in both the SSL Baseline Requirements and the EV Guidelines, the CAB Forum has held an informal working group previously referred to as the Extended Validation Working Group now known as the Validation Working Group, would like to modify its scope to include validation in the Baseline Requirements as well as the EV Guidelines. Jeremy Rowley of DigiCert made the following motion, which was endorsed by Rich Smith of Comodo and Kirk Hall of TrendMicro ---- Motion begins ---- The CA-Browser Forum formally establishes the Validation Working Group as an official working group of the CAB Forum, replacing the previous informal EV working group. The scope of this working group is to address issues arising under adopted CAB Forum standards related to the validation of certificate information and the inclusion of information in certificates. Scope: The Validation Working Group will consider all matters relating to the validation and inclusion of information in certificates under adopted CAB Forum guidelines. Deliverables: The Working Group shall produce one or more documents offering options to the Forum for validation within the scope defined above. ---- Motion Ends ---- The review period for this ballot shall commence at 2200 UTC on 5 Feb 2015, and will close at 2200 UTC on 11 Feb 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on 18 Feb 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Dean_Coclin at symantec.com Wed Feb 18 15:51:09 2015 From: Dean_Coclin at symantec.com (Dean Coclin) Date: Wed, 18 Feb 2015 07:51:09 -0800 Subject: [cabfpub] Agenda for CA/B Forum call February 18, 2015 Message-ID: <14D026C7F297AD44AC82578DD818CDD038EF1EAA6F@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> Antitrust Statement: As you know, this meeting includes companies that compete against one another. This meeting is intended to discuss technical standards related to the provision of existing and new types of digital certificates without restricting competition in developing and marketing such certificates. This meeting is not intended to share competitively-sensitive information among competitors, and therefore all participants agree not to discuss or exchange information related to: (a) Pricing policies, pricing formulas, prices or other terms of sale; (b) Costs, cost structures, profit margins, (c) Pending or planned service offerings, (d) Customers, business, or marketing plans; or (e) The allocation of customers, territories, or products in any way. Note: Please announce yourself when you dial in. This helps in documenting attendance when recording is played back later. Here is the proposed agenda: Time Start(UTC) Stop Slot Description Notes / Presenters (Thur) 19 Feb 2015 0:01 16:00 16:01 1 Read Antitrust Statement Dean 0:02 16:01 16:03 2 Roll Call Dean 0:01 16:03 16:04 3 Review Agenda Dean 0:01 16:04 16:05 4 Approve Minutes of 5 Feb 2015 Latest version distributed by Dean on Feb 15th 0:20 16:05 16:25 5 Results of Ballots 143 and 144. Use of Abstention vote. Dean 0:05 16:25 16:30 6 IPv6: additional updates? Ryan S. 0:10 16:30 16:40 7 New Ballots: Operational existence and domain validation Jeremy 0:10 16:40 16:45 8 Working Groups-public discussion? 0:05 16:45 16:50 9 EV Working Group Status Update Jeremy 0:02 16:50 16:52 10 Code Signing Working Group Status Update Dean/Jeremy -Public draft 0:02 16:52 16:54 11 Policy Review Working Group Status Update Proposed ballot status 0:02 16:54 16:56 12 *New* Information Sharing Working Group Update Ben 0:03 16:56 16:59 13 Any Other Business - Cupertino Meeting-March 10-12: 32 attendees signed up so far 0:00 17:00 17:00 14 Next phone call - March 5, 2015 Should we skip the next call since F2F is the week after? 0:00 17:00 17:00 15 Adjourn -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6130 bytes Desc: not available URL: From erwann.abalea at opentrust.com Wed Feb 18 16:14:25 2015 From: erwann.abalea at opentrust.com (Erwann Abalea) Date: Wed, 18 Feb 2015 17:14:25 +0100 Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group In-Reply-To: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> References: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> Message-ID: <54E4BA61.2000100@opentrust.com> OpenTrust votes Yes. -- Erwann ABALEA Le 04/02/2015 22:05, Jeremy Rowley a ?crit : > > Ballot 143 - Formalization of validation working group > > ---- > > Reason > > ---- > > In order to address validation issues and inconsistencies in both the > SSL Baseline Requirements and the EV Guidelines, the CAB Forum has > held an informal working group previously referred to as the Extended > Validation Working Group now known as the Validation Working Group, > would like to modify its scope to include validation in the Baseline > Requirements as well as the EV Guidelines. > > Jeremy Rowley of DigiCert made the following motion, which was > endorsed by Rich Smith of Comodo and Kirk Hall of TrendMicro > > ---- > > Motion begins > > ---- > > The CA-Browser Forum formally establishes the Validation Working Group > as an official working group of the CAB Forum, replacing the previous > informal EV working group. The scope of this working group is to > address issues arising under adopted CAB Forum standards related to > the validation of certificate information and the inclusion of > information in certificates. > > Scope: The Validation Working Group will consider all matters relating > to the validation and inclusion of information in certificates under > adopted CAB Forum guidelines. > > Deliverables: The Working Group shall produce one or more documents > offering options to the Forum for validation within the scope defined > above. > > ---- > > Motion Ends > > ---- > > The review period for this ballot shall commence at 2200 UTC on 5 Feb > 2015, and will close at 2200 UTC on 11 Feb 2015. Unless the motion is > withdrawn during the review period, the voting period will start > immediately thereafter and will close at 2200 UTC on 18 Feb 2015. > Votes must be cast by posting an on-list reply to this thread. > > A vote in favor of the motion must indicate a clear 'yes' in the > response. A vote against must indicate a clear 'no' in the response. A > vote to abstain must indicate a clear 'abstain' in the response. > Unclear responses will not be counted. The latest vote received from > any representative of a voting member before the close of the voting > period will be counted. Voting members are listed here: > https://cabforum.org/members/ > > In order for the motion to be adopted, two thirds or more of the votes > cast by members in the CA category and greater than 50% of the votes > cast by members in the browser category must be in favor. Quorum is > currently nine (9) members? at least nine members must participate in > the ballot, either by voting in favor, voting against, or abstaining. > > > > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public -------------- next part -------------- An HTML attachment was scrubbed... URL: From JAmaral at trustwave.com Wed Feb 18 16:24:20 2015 From: JAmaral at trustwave.com (John Amaral) Date: Wed, 18 Feb 2015 16:24:20 +0000 Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group In-Reply-To: References: <5d8b535053124446bd98977d91b7a497@EX2.corp.digicert.com> Message-ID: <99A44CD64687DD4EB6D44264DBED7525507C0DBD@SKYMB2.trustwave.com> Trustwave votes YES Regards, John John Amaral SVP, Product Management t: +1 781.419.6344 m: +1 978.760.0144 Trustwave | SMART SECURITY ON DEMAND www.trustwave.com Subject: [cabfpub] Ballot 143 - Formalization of Validation Working Group Ballot 143 - Formalization of validation working group ---- Reason ---- In order to address validation issues and inconsistencies in both the SSL Baseline Requirements and the EV Guidelines, the CAB Forum has held an informal working group previously referred to as the Extended Validation Working Group now known as the Validation Working Group, would like to modify its scope to include validation in the Baseline Requirements as well as the EV Guidelines. Jeremy Rowley of DigiCert made the following motion, which was endorsed by Rich Smith of Comodo and Kirk Hall of TrendMicro ---- Motion begins ---- The CA-Browser Forum formally establishes the Validation Working Group as an official working group of the CAB Forum, replacing the previous informal EV working group. The scope of this working group is to address issues arising under adopted CAB Forum standards related to the validation of certificate information and the inclusion of information in certificates. Scope: The Validation Working Group will consider all matters relating to the validation and inclusion of information in certificates under adopted CAB Forum guidelines. Deliverables: The Working Group shall produce one or more documents offering options to the Forum for validation within the scope defined above. ---- Motion Ends ---- The review period for this ballot shall commence at 2200 UTC on 5 Feb 2015, and will close at 2200 UTC on 11 Feb 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on 18 Feb 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. ________________________________ This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Mads.Henriksveen at buypass.no Wed Feb 18 16:35:00 2015 From: Mads.Henriksveen at buypass.no (Mads Egil Henriksveen) Date: Wed, 18 Feb 2015 16:35:00 +0000 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names In-Reply-To: References: Message-ID: <55329794072a4622ad3ef4c589d95f70@Buyp-gvk-ex01.intra.buypass.no> Buypass votes YES. Regards Mads From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: 10. februar 2015 19:39 To: public at cabforum.org Subject: [cabfpub] Ballot 144 - Validation rules for .onion names Here's the ballot with the two typos fixed: Applicants want a CA-signed .onion address for several reasons, including: - Powerful web platform features are restricted to secure origins, which are currently not available to onion names (in part, because of the lack of IANA registration). Permitting EV certs for onion names will help provide a secure origin for the service, moving onion towards use of powerful web platform features. - Currently, access to .onion names over https from a standard browser results in the standard existing 'Invalid Certificate' warning. Training users to click through security warnings lowers the value of these warnings and will cause users to miss important security information. Removing these warnings for the user, through use of a digital certificate, will help users recognize and avoid real MITM attacks. - The public needs attribution of ownership of the .onion address to differentiate onion services, including potential phishing services. Because onion names are not easily recognizable strings, providing the public with additional information about the operator has significant security improvements, especially in regions where use of the incorrect name could have lethal consequences. The following motion has been proposed by Jeremy Rowley of DigiCert and endorsed by Ryan Sleevi of Google and Wayne Thayer of GoDaddy. --------------------- Motion Starts --------------------- 1) Amend Section 9.2.1 of the Baseline Requirements v. 1.2.3 as follows: 9.2.1 Subject Alternative Name Extension Certificate Field: extensions:subjectAltName Required/Optional: Required Contents: This 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. The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate. Wildcard FQDNs are permitted. As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name, the CA SHALL notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016. Also as of the Effective Date, the CA SHALL NOT issue a certificate with an Expiry Date later than 1 November 2015 with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name. Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Name. Effective May 1, 2015, each CA SHALL revoke all unexpired Certificates with an Internal Name using onion as the right-most label in an entry in the subjectAltName Extension or commonName field unless such Certificate was issued in accordance with Appendix F of the EV Guidelines. 2) Amend Section 9.2.2 and 11.7.1 of the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2 as follows: 9.2.2. Subject Alternative Name Extension Certificate field: subjectAltName:dNSName Required/Optional: Required Contents: This extension MUST contain one or more host Domain Name(s) owned or controlled by the Subject and to be associated with the Subject's server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). Wildcard certificates are not allowed for EV Certificates except as permitted under Appendix F. 11.7 Verification of Applicant's Domain Name 11.7.1. Verification Requirements (1) For each Fully-Qualified Domain Name listed in a Certificate, other than a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant (or the Applicant's Parent Company, Subsidiary Company, or Affiliate, collectively referred to as "Applicant" for the purposes of this section) either is the Domain Name Registrant or has control over the FQDN using a procedure specified in Section 11.1.1 of the Baseline Requirements, except that a CA MAY NOT verify a domain using the procedure described 11.1.1(7). For a Certificate issued to a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant's control over the .onion Domain Name in accordance with Appendix F. (2) Mixed Character Set Domain Names: EV Certificates MAY include Domain Names containing mixed character sets only in compliance with the rules set forth by the domain registrar. The CA MUST visually compare any Domain Names with mixed character sets with known high risk domains. If a similarity is found, then the EV Certificate Request MUST be flagged as High Risk. The CA must perform reasonably appropriate additional authentication and verification to be certain beyond reasonable doubt that the Applicant and the target in question are the same organization. 3) Add a new Appendix F to the Guidelines for the Issuance and Management of Extended Validation Certificates v1.5.2: Appendix F - Issuance of Certificates for .onion Domain Names A CA may issue an EV Certificate with .onion in the right-most label of the Domain Name provided that issuance complies with the requirements set forth in this Appendix: 1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) The CAB Forum has created an extension of the TBSCertificate for use in conveying hashes of keys related to .onion addresses. The Tor Service Descriptor Hash extension has the following format: cabf-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 } TorServiceDescriptorSyntax ::= SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash TorServiceDescriptorHash:: = SEQUENCE { onionURI UTF8String algorithm AlgorithmIdentifier subjectPublicKeyHash BIT STRING } Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 6234) performed over the DER-encoding of an ASN.1 SubjectPublicKey of the .onion service and SubjectPublicKeyHash is the hash output. 2. The CA MUST verify the Applicant's control over the .onion Domain Name using one of the following: a. The CA MAY verify the Applicant's control over the .onion service by posting a specific value at a well-known URL under RFC5785. b. The CA MAY verify the Applicant's control over the .onion service by having the Applicant provide a Certificate Request signed using the .onion public key if the Attributes section of the certificationRequestInfo contains: (i) A caSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy, 2) is generated by the CA, and 3) delivered to the Applicant through a Verified Method of Communication and (ii) An applicantSigningNonce attribute that 1) contains a single value with at least 64-bits of entropy and 2) is generated by the Applicant. The signing nonce attributes have the following format: caSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-caSigningNonce } } cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } applicantSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { cabf-applicantSigningNonce } } cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 } 4. Each Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name MUST conform to the requirements of these Guidelines, including the content requirements in Section 9 and Appendix B of the Baseline Requirements, except that the CA MAY include a wildcard character in the Subject Alternative Name Extension and Subject Common Name Field as the left-most character in the .onion Domain Name provided inclusion of the wildcard character complies with Section 11.1.3 of the Baseline Requirements. 5. CAs MUST NOT issue a Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name with a validity period longer than 15 months. Despite Section 9.2.1 of the Baseline Requirements deprecating the use of Internal Names, a CA MAY issue a Certificate containing an .onion name with an expiration date later than 1 November 2015 after (and only if) .onion is officially recognized by the IESG as a reserved TLD. 6. On or before May 1, 2015, each CA MUST revoke all Certificates issued with the Subject Alternative Name extension or Common Name field that includes a Domain Name where .onion is in the right-most label of the Domain Name unless the Certificate was issued in compliance with this Appendix F. ---- Motion Ends ----- The review period for this ballot shall commence at 2200 UTC on Thursday, 4 February 2015, and will close at 2200 UTC on Thursday, 11 February 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on Monday, 18 February 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: From erwann.abalea at opentrust.com Wed Feb 18 19:07:44 2015 From: erwann.abalea at opentrust.com (Erwann Abalea) Date: Wed, 18 Feb 2015 20:07:44 +0100 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names In-Reply-To: References: Message-ID: <54E4E300.3050303@opentrust.com> OpenTrust votes NO. I've got nothing against Tor, I use it and operate a relay node, and I appreciate its value. However: * there's no constraint on service descriptor key sizes, and right now the keys are 1024bits RSA by default. The service descriptor key is what gives the hidden service its name (facebookcorewwwi.onion, for example), so it can't be changed without changing the hidden service name, and the service descriptor key size can't easily be changed (it's a manual and undocumented process, and I'm not sure a larger key will be accepted by Tor clients). The vast majority of onion keys are also RSA1024 ones. For example, the service descriptor key for the "facebookcorewwwi" service is also a 1024bits one. Whoever gets the private key can impersonate the hidden service. CABForum members must not certify public keys smaller than 2048 bits since 2013-12-31, let's not reintroduce them now. * the hidden service name that will be certified is generated using a truncated SHA1. Cryptographically, that's not a security problem so far because it uses the second preimage resistance of SHA1, and SHA1 has no real weakness regarding second preimage. It's a 2^80 work effort for an attacker to generate a key having the same hidden service name as an existing one. CABForum members have already agreed to avoid SHA1, with a deprecation plan, even for intermediate CA certificates, where we also rely on the second preimage resistance property of the hash function (with a 2^160 effort for an attacker because it's not truncated). Let's be consistent and avoid SHA1 all along. * the final goal of this ballot is to allow a Tor user to access a non hidden service using a hidden service name. Such a user can *already* access to the public facing classical version of this service, using its public name. A Tor user can already access https://www.whatever.com with its browser and the browser will be happy and get the green bar if the certificate is an EV one. I may fail to see the expected benefit, but that's it, I don't see it. -- Erwann ABALEA Le 10/02/2015 19:38, Jeremy Rowley a ?crit : > > *Here?s the ballot with the two typos fixed:* > > Applicants want a CA-signed .onion address for several reasons, including: > > - Powerful web platform features are restricted to secure origins, > which are currently not available to onion names (in part, because of > the lack of IANA registration). Permitting EV certs for onion names > will help provide a secure origin for the service, moving onion > towards use of powerful web platform features. > > - Currently, access to .onion names over https from a standard browser > results in the standard existing 'Invalid Certificate' warning. > Training users to click through security warnings lowers the value of > these warnings and will cause users to miss important security > information. Removing these warnings for the user, through use of a > digital certificate, will help users recognize and avoid real MITM > attacks. > > - The public needs attribution of ownership of the .onion address to > differentiate onion services, including potential phishing services. > Because onion names are not easily recognizable strings, providing the > public with additional information about the operator has significant > security improvements, especially in regions where use of the > incorrect name could have lethal consequences. > > The following motion has been proposed by Jeremy Rowley of DigiCert > and endorsed by Ryan Sleevi of Google and Wayne Thayer of GoDaddy. > > --------------------- > > Motion Starts > > --------------------- > > 1) Amend Section 9.2.1 of the Baseline Requirements v. 1.2.3 as follows: > > 9.2.1 Subject Alternative Name Extension > > Certificate Field: extensions:subjectAltName > > Required/Optional: Required > > Contents: This 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. The CA MUST > confirm that the Applicant controls the Fully-Qualified Domain Name or > IP address or has been granted the right to use it by the Domain Name > Registrant or IP address assignee, as appropriate. > > Wildcard FQDNs are permitted. As of the Effective Date of these > Requirements, prior to the issuance of a Certificate with a > subjectAlternativeName extension or Subject commonName field > containing a Reserved IP Address or Internal Name, the CA SHALL notify > the Applicant that the use of such Certificates has been deprecated by > the CA / Browser Forum and that the practice will be eliminated by > October 2016. Also as of the Effective Date, the CA SHALL NOT issue a > certificate with an Expiry Date later than 1 November 2015 with a > subjectAlternativeName extension or Subject commonName field > containing a Reserved IP Address or Internal Name. Effective 1 October > 2016, CAs SHALL revoke all unexpired Certificates whose > subjectAlternativeName extension or Subject commonName field contains > a Reserved IP Address or Internal Name. _Effective May 1, 2015, each > CA SHALL revoke all unexpired Certificates with an Internal Name using > onion as the right-most label in an entry in the subjectAltName > Extension or commonName field unless such Certificate was issued in > accordance with Appendix F of the EV Guidelines._ > > 2) Amend Section 9.2.2 and 11.7.1 of the Guidelines for the Issuance > and Management of Extended Validation Certificates v1.5.2 as follows: > > 9.2.2. Subject Alternative Name Extension Certificate field: > subjectAltName:dNSName > > Required/Optional: Required > > Contents: This extension MUST contain one or more host Domain Name(s) > owned or controlled by the Subject and to be associated with the > Subject?s server. Such server MAY be owned and operated by the Subject > or another entity (e.g., a hosting service). Wildcard certificates are > not allowed for EV Certificates_except as permitted under Appendix F_. > > 11.7 Verification of Applicant?s Domain Name > > 11.7.1. Verification Requirements > > (1) For each Fully-Qualified Domain Name listed in a Certificate, > other than a Domain Name with .onion in the right-most label of the > Domain Name, the CA SHALL confirm that, as of the date the Certificate > was issued, the Applicant (or the Applicant?s Parent Company, > Subsidiary Company, or Affiliate, collectively referred to as > ?Applicant? for the purposes of this section) either is the Domain > Name Registrant or has control over the FQDN using a procedure > specified in Section 11.1.1 of the Baseline Requirements, except that > a CA MAY NOT verify a domain using the procedure described 11.1.1(7). > _For a Certificate issued to a Domain Name with .onion in the > right-most label of the Domain Name, the CA SHALL confirm that, as of > the date the Certificate was issued, the Applicant?s control over the > .onion Domain Name in accordance with Appendix F._ > > (2) Mixed Character Set Domain Names: EV Certificates MAY include > Domain Names containing mixed character sets only in compliance with > the rules set forth by the domain registrar. The CA MUST visually > compare any Domain Names with mixed character sets with known high > risk domains. If a similarity is found, then the EV Certificate > Request MUST be flagged as High Risk. The CA must perform reasonably > appropriate additional authentication and verification to be certain > beyond reasonable doubt that the Applicant and the target in question > are the same organization. > > 3) Add a new Appendix F to the Guidelines for the Issuance and > Management of Extended Validation Certificates v1.5.2: > > Appendix F ? Issuance of Certificates for .onion Domain Names > > A CA may issue an EV Certificate with .onion in the right-most label > of the Domain Name provided that issuance complies with the > requirements set forth in this Appendix: > > 1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) > > The CAB Forum has created an extension of the TBSCertificate for use > in conveying hashes of keys related to .onion addresses. The Tor > Service Descriptor Hash extension has the following format: > > cabf-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 } > > TorServiceDescriptorSyntax ::= > > SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash > > TorServiceDescriptorHash:: = SEQUENCE { > > onionURI UTF8String > > algorithm AlgorithmIdentifier > > subjectPublicKeyHash BIT STRING } > > Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC > 6234) performed over the DER-encoding of an ASN.1 SubjectPublicKey of > the .onion service and SubjectPublicKeyHash is the hash output. > > 2. The CA MUST verify the Applicant?s control over the .onion Domain > Name using one of the following: > > a. The CA MAY verify the Applicant?s control over the .onion service > by posting a specific value at a well-known URL under RFC5785. > > b. The CA MAY verify the Applicant?s control over the .onion service > by having the Applicant provide a Certificate Request signed using the > .onion public key if the Attributes section of the > certificationRequestInfo contains: > > (i) A caSigningNonce attribute that 1) contains a single value with at > least 64-bits of entropy, 2) is generated by the CA, and 3) delivered > to the Applicant through a Verified Method of Communication and > > (ii) An applicantSigningNonce attribute that 1) contains a single > value with at least 64-bits of entropy and 2) is generated by the > Applicant. > > The signing nonce attributes have the following format: > > caSigningNonce ATTRIBUTE ::= { > > WITH SYNTAX OCTET STRING > > EQUALITY MATCHING RULE octetStringMatch > > SINGLE VALUE TRUE > > ID { cabf-caSigningNonce } > > } > > cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } > > applicantSigningNonce ATTRIBUTE ::= { > > WITH SYNTAX OCTET STRING > > EQUALITY MATCHING RULE octetStringMatch > > SINGLE VALUE TRUE > > ID { cabf-applicantSigningNonce } > > } > > cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 } > > 4. Each Certificate that includes a Domain Name where .onion is in the > right-most label of the Domain Name MUST conform to the requirements > of these Guidelines, including the content requirements in Section 9 > and Appendix B of the Baseline Requirements, except that the CA MAY > include a wildcard character in the Subject Alternative Name Extension > and Subject Common Name Field as the left-most character in the .onion > Domain Name provided inclusion of the wildcard character complies with > Section 11.1.3 of the Baseline Requirements. > > 5. CAs MUST NOT issue a Certificate that includes a Domain Name where > .onion is in the right-most label of the Domain Name with a validity > period longer than 15 months. Despite Section 9.2.1 of the Baseline > Requirements deprecating the use of Internal Names, a CA MAY issue a > Certificate containing an .onion name with an expiration date later > than 1 November 2015 after (and only if) .onion is officially > recognized by the IESG as a reserved TLD. > > 6. On or before May 1, 2015, each CA MUST revoke all Certificates > issued with the Subject Alternative Name extension or Common Name > field that includes a Domain Name where .onion is in the right-most > label of the Domain Name unless the Certificate was issued in > compliance with this Appendix F. > > ---- > > Motion Ends > > ----- > > The review period for this ballot shall commence at 2200 UTC on > Thursday, 4 February 2015, and will close at 2200 UTC on Thursday, 11 > February 2015. Unless the motion is withdrawn during the review > period, the voting period will start immediately thereafter and will > close at 2200 UTC on Monday, 18 February 2015. Votes must be cast by > posting an on-list reply to this thread. > > A vote in favor of the motion must indicate a clear 'yes' in the > response. A vote against must indicate a clear 'no' in the response. A > vote to abstain must indicate a clear 'abstain' in the response. > Unclear responses will not be counted. The latest vote received from > any representative of a voting member before the close of the voting > period will be counted. Voting members are listed here: > https://cabforum.org/members/ > > In order for the motion to be adopted, two thirds or more of the votes > cast by members in the CA category and greater than 50% of the votes > cast by members in the browser category must be in favor. Quorum is > currently nine (9) members? at least nine members must participate in > the ballot, either by voting in favor, voting against, or abstaining. > > > > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public -------------- next part -------------- An HTML attachment was scrubbed... URL: From sleevi at google.com Wed Feb 18 22:00:41 2015 From: sleevi at google.com (Ryan Sleevi) Date: Wed, 18 Feb 2015 14:00:41 -0800 Subject: [cabfpub] Preballot for IPv6 Support In-Reply-To: References: Message-ID: In advance of tomorrow's call, I'd like to bring forward this pre-ballot again ---MOTION BEGINS--- Update Section 13.2.1 of the Baseline Requirements as follows: From: "The CA SHALL make revocation information for Subordinate Certificates and Subscriber Certificates available in accordance with Appendix B." To: "The CA SHALL make revocation information for Subordinate Certificates and Subscriber Certificates available in accordance with Appendix B. Effective March 1, 2016, the CA SHALL make this information available via both IPv4 and IPv6. For each DNS host included in accordance with Appendix B, lookups to the authoritative resolver MUST return valid A records if A records are requested and valid AAAA records if AAAA records are requested." Update Appendix B, Section 2(b) of the Baseline Requirements as follows: From: "This extension MUST be present and MUST NOT be marked critical. It MUST contain the HTTP URL of the CA?s CRL service." To: "This extension MUST be present and MUST NOT be marked critical. It MUST contain the HTTP URL of the CA?s CRL service. See Section 13.2.1 for details." ---MOTION ENDS--- The key changes from the previous pre-ballot are the wording changes suggested by Brian Smith, and attaching a concrete date - 1 year from now. From gerv at mozilla.org Thu Feb 19 10:11:59 2015 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 19 Feb 2015 10:11:59 +0000 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names In-Reply-To: <54E4E300.3050303@opentrust.com> References: <54E4E300.3050303@opentrust.com> Message-ID: <54E5B6EF.3000009@mozilla.org> Hi Erwann, On 18/02/15 19:07, Erwann Abalea wrote: > OpenTrust votes NO. >From reading your objections: does this mean you would be in favour after the Tor folk move to longer hashes and SHA-256? > * the final goal of this ballot is to allow a Tor user to access a non > hidden service using a hidden service name. Such a user can > *already* access to the public facing classical version of this > service, using its public name. Yes; however, people in the middle can both tell that the user is accessing the site, and can block their access. Gerv From Dean_Coclin at symantec.com Thu Feb 19 15:39:36 2015 From: Dean_Coclin at symantec.com (Dean Coclin) Date: Thu, 19 Feb 2015 07:39:36 -0800 Subject: [cabfpub] Ballot 143, 144 results Message-ID: <14D026C7F297AD44AC82578DD818CDD038EF343757@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> On Ballot 143, Formation of Validation Working Group, I counted 22 Yes votes, 0 No votes , 0 Abstentions from the CAs and 4 Yes votes from the browsers. Therefore, the ballot passes. On Ballot 144, Issuance to .Onion domains, I counted 6 Yes votes, 2 No votes and 13 Abstentions from the CAs and 3 Yes votes from the browsers. Therefore, the ballot passes. Detailed results are on the wiki ballot tracker. The Chair directs that the name of the working group be updated to the Validation Working Group and requests that Ben Wilson update the wiki and website to reflect this. The group's new charter should reflect the ballot results. Further, I ask that Jeremy update the EV Guidelines to adjust for Ballot 144 as appropriate (per the ballot). Thank you, Dean Coclin -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6130 bytes Desc: not available URL: From jeremy.rowley at digicert.com Thu Feb 19 15:43:43 2015 From: jeremy.rowley at digicert.com (Jeremy Rowley) Date: Thu, 19 Feb 2015 15:43:43 +0000 Subject: [cabfpub] Ballot 145 - Operational Existence for Government Entities Message-ID: Ballot 145 - Operational Existence for Government Entities ________________________________ Reason ________________________________ Because government entities aren't operating as businesses, they are often not listed with a QIIS, especially immediately after the entity is created by either statute or order. The legal existence of these entities is verifiable through a QGIS, but this source in many countries (especially Arabic and African countries) does not always list a date of creation of these entities. Operational existence exists to ensure organizations aren't fly-by-night scams/phishing entities. With government entities, these same risks are not present as they are created directly by government action. Jeremy Rowley of DigiCert made the following motion, which was endorsed by Rich Smith of Comodo and Cecilia Kam of Symantec. ________________________________ Motion begins ________________________________ Effective immediately, section 11.6.1 is modified as follows: 11.6.1 Verification Requirements. The CA MUST verify that the Applicant has the ability to engage in business by verifying the Applicant's, or Affiliate/Parent/Subsidiary Company's, operational existence. The CA MAY rely on its verification of a Government Entity's legal existence under Section 11.2 as verification of a Government Entity's operational existence. ________________________________ Motion Ends ________________________________ The review period for this ballot shall commence at 2200 UTC on 19 Feb 2015, and will close at 2200 UTC on 26 Feb 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on 5 Mar 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wthayer at godaddy.com Thu Feb 19 16:54:28 2015 From: wthayer at godaddy.com (Wayne Thayer) Date: Thu, 19 Feb 2015 16:54:28 +0000 Subject: [cabfpub] Preballot for IPv6 Support In-Reply-To: References: Message-ID: Ryan, We didn't find any blockers that prevent GoDaddy from enabling support for IPv6. Like other CAs, we also don't see any demand for it today, but I agree that this is a collective action problem and CAs need to remove certificate validation from the list of problems that are blocking other parties from moving to IPv6. GoDaddy supports this ballot and I would be happy to endorse. Thanks, Wayne -----Original Message----- From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ryan Sleevi Sent: Wednesday, February 18, 2015 3:01 PM To: CABFPub Subject: Re: [cabfpub] Preballot for IPv6 Support In advance of tomorrow's call, I'd like to bring forward this pre-ballot again ---MOTION BEGINS--- Update Section 13.2.1 of the Baseline Requirements as follows: From: "The CA SHALL make revocation information for Subordinate Certificates and Subscriber Certificates available in accordance with Appendix B." To: "The CA SHALL make revocation information for Subordinate Certificates and Subscriber Certificates available in accordance with Appendix B. Effective March 1, 2016, the CA SHALL make this information available via both IPv4 and IPv6. For each DNS host included in accordance with Appendix B, lookups to the authoritative resolver MUST return valid A records if A records are requested and valid AAAA records if AAAA records are requested." Update Appendix B, Section 2(b) of the Baseline Requirements as follows: From: "This extension MUST be present and MUST NOT be marked critical. It MUST contain the HTTP URL of the CA?s CRL service." To: "This extension MUST be present and MUST NOT be marked critical. It MUST contain the HTTP URL of the CA?s CRL service. See Section 13.2.1 for details." ---MOTION ENDS--- The key changes from the previous pre-ballot are the wording changes suggested by Brian Smith, and attaching a concrete date - 1 year from now. _______________________________________________ Public mailing list Public at cabforum.org https://cabforum.org/mailman/listinfo/public From kirk_hall at trendmicro.com Thu Feb 19 16:59:51 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Thu, 19 Feb 2015 16:59:51 +0000 Subject: [cabfpub] When did the WebTrust/ETSI BR audit requirement become mandatory? Message-ID: On our Forum call today, we asked when a WebTrust/ETSI BR audit requirement become mandatory for CAs. Ballot 62 (Nov. 2011) adopted the BRs effective July 1, 2012. However, there were no audit criteria in place for some time. I did some quick research, and the answer is not clear as to when the audit criteria came into effect. The WebTrust draft audit requirements were completed by early 2013, and I see comments that Mozilla adopted the BR audit as a program requirement at the Mountain View meeting in Feb. 2013. Here is the current Mozilla requirement at Sec. 11: https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ As I recall, the initial Mozilla BR audit requirement was not clear as to exact effective date (what operational period must be covered by a CA's initial BR audit). I vaguely recall Mozilla clarifying the rule at our Feb. 2013 meeting at Mountain View that all CA operations occurring on or after Feb. 15, 2013 must be covered by a BR audit - so some CAs did partial-year initial BR audits to align their BR audits with their other audits. Based on all this, I would say all CAs should have full year BR audits in place by now. We can change our Bylaw on membership at Bylaw 2.1 to reflect this. Kirk R. Hall Operations Director, Trust Services Trend Micro +1.503.753.3088 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
-------------- next part -------------- An HTML attachment was scrubbed... URL: From gerv at mozilla.org Thu Feb 19 17:33:27 2015 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 19 Feb 2015 17:33:27 +0000 Subject: [cabfpub] When did the WebTrust/ETSI BR audit requirement become mandatory? In-Reply-To: References: Message-ID: <54E61E67.6090409@mozilla.org> On 19/02/15 16:59, kirk_hall at trendmicro.com wrote: > Based on all this, I would say all CAs should have full year BR audits > in place by now. We can change our Bylaw on membership at Bylaw 2.1 to > reflect this. I agree with the former, but let me challenge for a moment whether it directly implies the goodness of the latter. Why do we have membership criteria at all? I would say that it's solely to prevent people or organizations signing up as members who are not actually doing things the forum concerns itself with. Therefore, our membership criteria should be as wide as possible consistent with that goal. We currently require a WebTrust or ETSI scheme audit. I think it's unlikely that an organization will seek and pay for such a thing unless they are actually a CA. So I would say our membership criteria are already rigorous enough. To put it another way: Mozilla's root program requirements are not the same thing as CAB Forum membership criteria. I suspect that a new CA won't get very far in practice without a BR audit, but the CAB Forum should not be judging the business model viability of potential members as a condition of membership. That seems a dangerous road to me. Gerv From kirk_hall at trendmicro.com Thu Feb 19 18:28:44 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Thu, 19 Feb 2015 18:28:44 +0000 Subject: [cabfpub] When did the WebTrust/ETSI BR audit requirement become mandatory? In-Reply-To: <54E61E67.6090409@mozilla.org> References: <54E61E67.6090409@mozilla.org> Message-ID: I partially agree, but I would put it this way: CA membership requirements are intended to make sure an applicant is a "real" CA. Today, both Mozilla and Microsoft require a CA to have a Baseline Requirements audit for its roots to be included in the trusted root store. Here is the Microsoft link: http://social.technet.microsoft.com/wiki/contents/articles/26675.windows-root-certificate-program-audit-requirements-for-cas.aspx Plus, the CA-Browser Forum itself requires all CAs to follow the BRs for their certs to be considered trustworthy (except that the Forum has no enforcement power ? that is left to the browsers through their root program requirements): These Baseline Requirements describe an integrated set of technologies, protocols, identity-proofing, lifecycle management, and auditing requirements that are necessary (but not sufficient) for the issuance and management of Publicly-Trusted Certificates; Certificates that are trusted by virtue of the fact that their corresponding Root Certificate is distributed in widely-available application software. The Requirements are not mandatory for Certification Authorities unless and until they become adopted and enforced by relying?party Application Software Suppliers. *** 1. Scope The Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates describe a subset of the requirements that a Certification Authority must meet in order to issue Publicly Trusted Certificates. Except where explicitly stated otherwise, these requirements apply only to relevant events that occur on or after the Effective Date. *** These Requirements are applicable to all Certification Authorities within a chain of trust. They are to be flowed down from the Root Certification Authority through successive Subordinate Certification Authorities. 2. Purpose The primary goal of these Requirements is to enable efficient and secure electronic communication, while addressing user concerns about the trustworthiness of Certificates. The Requirements also serve to inform users and help them to make informed decisions when relying on Certificates. No CA is required to join the Forum to operate ? the CAs only need to satisfy the browsers. But I can?t think of any reason why a CA would choose NOT to follow the BRs and get a BR audit if it wants to be considered a ?real? CA. And I don?t think the Forum would want to accept any new CA member that said ?I choose not to follow the BRs, and I choose not to get a BR audit? ? why would we want such a CA as a member? So it seems reasonable to update our bylaws to require a BR audit for membership. -----Original Message----- From: Gervase Markham [mailto:gerv at mozilla.org] Sent: Thursday, February 19, 2015 9:33 AM To: Kirk Hall (RD-US); CABFPub (public at cabforum.org) Subject: Re: [cabfpub] When did the WebTrust/ETSI BR audit requirement become mandatory? On 19/02/15 16:59, kirk_hall at trendmicro.com wrote: > Based on all this, I would say all CAs should have full year BR audits > in place by now. We can change our Bylaw on membership at Bylaw 2.1 > to reflect this. I agree with the former, but let me challenge for a moment whether it directly implies the goodness of the latter. Why do we have membership criteria at all? I would say that it's solely to prevent people or organizations signing up as members who are not actually doing things the forum concerns itself with. Therefore, our membership criteria should be as wide as possible consistent with that goal. We currently require a WebTrust or ETSI scheme audit. I think it's unlikely that an organization will seek and pay for such a thing unless they are actually a CA. So I would say our membership criteria are already rigorous enough. To put it another way: Mozilla's root program requirements are not the same thing as CAB Forum membership criteria. I suspect that a new CA won't get very far in practice without a BR audit, but the CAB Forum should not be judging the business model viability of potential members as a condition of membership. That seems a dangerous road to me. Gerv 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
-------------- next part -------------- An HTML attachment was scrubbed... URL: From erwann.abalea at opentrust.com Thu Feb 19 18:44:47 2015 From: erwann.abalea at opentrust.com (Erwann Abalea) Date: Thu, 19 Feb 2015 19:44:47 +0100 Subject: [cabfpub] Ballot 144 - Validation rules for .onion names In-Reply-To: <54E5B6EF.3000009@mozilla.org> References: <54E4E300.3050303@opentrust.com> <54E5B6EF.3000009@mozilla.org> Message-ID: <54E62F1F.9000109@opentrust.com> Bonjour Gerv, Le 19/02/2015 11:11, Gervase Markham a ?crit : > Hi Erwann, > > On 18/02/15 19:07, Erwann Abalea wrote: >> OpenTrust votes NO. > From reading your objections: does this mean you would be in favour > after the Tor folk move to longer hashes and SHA-256? Longer hashes may not be necessary, we lived with a 2^80 theoretical effort (collision resistance of a perfect hash function) for a while, and recently deprecated SHA1. But what was really deprecated? SHA1 in itself because it's old, despite its 2^160 resistance for intermediate certificates and CRLs? The idea of a 2^80 collision resistance? The latest estimated 2^61 collision resistance of SHA1? There was a reason to deprecate SHA1, there are consequences (we all heard of them and decided to drop legacy software, for good), there's a design behind our choices (or there should be). How does this truncated SHA1 fit this design? The other technical objection is that Tor is *full* of keys, and the vast majority of them are 1024 bits RSA keys. Some keys are ECC Curve25519 ones, but I don't know if they're used for signature or key exchange purpose. There are keys used to generate names, keys used to encrypt data exchanged between cells, keys used to sign distributed data, keys used to sign descriptor informations published by services, keys used to setup rendez-vous tokens to access hidden services, and maybe others. Keys smaller than 2048 bits are Evil(tm). It's written in stone, we track public 1024bits certificates and sue the CAs who produced them, we don't like DNSSEC partly because it's also full of 1024 bits keys. That's good, I'm fine with it. I'm not opposed to embrace Tor or any other similar security thing in CABForum's definition of a TLS certificate, but I'd like to be sure that we all know what is being introduced, the security consequences and guarantees of what we're doing. I really like Tor. But understanding Tor is hard, and I wouldn't be surprised if a non negligible number of the "abstain" votes was caused by this complexity. >> * the final goal of this ballot is to allow a Tor user to access a non >> hidden service using a hidden service name. Such a user can >> *already* access to the public facing classical version of this >> service, using its public name. > Yes; however, people in the middle can both tell that the user is > accessing the site, and can block their access. Tor is supposedly targeted for this situation. The exit node knows that someone wants to access the site and block it, the entry node knows that this specific user wants to access something and block it, but not both. In theory. From my understanding, accessing a Tor hidden service involves a longer path (3 nodes between the user and a rendezvous point, 3 nodes from this rendezvous point and the service), provides end-to-end encryption, and self-authentication. That's good. Does it solve the anonymity problem? Yes, for a hidden service. How does it work for a mixed hidden/non-hidden service? -- Erwann ABALEA From philliph at comodo.com Thu Feb 19 18:53:26 2015 From: philliph at comodo.com (Phillip Hallam-Baker) Date: Thu, 19 Feb 2015 13:53:26 -0500 Subject: [cabfpub] Lenovo installation of malicious root. Message-ID: <9CB5BBD9-58FA-4DC2-90E0-70F01911A4AC@comodo.com> I am sure many of you have seen this. If not you will, I have had a dozen people ping me about it in the past hour. https://www.eff.org/deeplinks/2015/02/further-evidence-lenovo-breaking-https-security-its-laptops Someone has to draw the line here or the politicians will do it for us. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Rick_Andrews at symantec.com Thu Feb 19 19:25:46 2015 From: Rick_Andrews at symantec.com (Rick Andrews) Date: Thu, 19 Feb 2015 11:25:46 -0800 Subject: [cabfpub] Preballot for IPv6 Support In-Reply-To: References: Message-ID: <544B0DD62A64C1448B2DA253C01141460BD3E573A0@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> Ryan, It seems to me we need to add one more detail: it must be possible to make the lookups to the authoritative resolver (DNS) over IPv4 and IPv6. A client running on an IPv6-only network will first make a DNS call to get the AAAA record for the CA's OCSP or CRL service. So the CA needs to make sure that those DNS lookups can be served via IPv6. -Rick -----Original Message----- From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Wayne Thayer Sent: Thursday, February 19, 2015 8:54 AM To: CABFPub Subject: Re: [cabfpub] Preballot for IPv6 Support Ryan, We didn't find any blockers that prevent GoDaddy from enabling support for IPv6. Like other CAs, we also don't see any demand for it today, but I agree that this is a collective action problem and CAs need to remove certificate validation from the list of problems that are blocking other parties from moving to IPv6. GoDaddy supports this ballot and I would be happy to endorse. Thanks, Wayne -----Original Message----- From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ryan Sleevi Sent: Wednesday, February 18, 2015 3:01 PM To: CABFPub Subject: Re: [cabfpub] Preballot for IPv6 Support In advance of tomorrow's call, I'd like to bring forward this pre-ballot again ---MOTION BEGINS--- Update Section 13.2.1 of the Baseline Requirements as follows: From: "The CA SHALL make revocation information for Subordinate Certificates and Subscriber Certificates available in accordance with Appendix B." To: "The CA SHALL make revocation information for Subordinate Certificates and Subscriber Certificates available in accordance with Appendix B. Effective March 1, 2016, the CA SHALL make this information available via both IPv4 and IPv6. For each DNS host included in accordance with Appendix B, lookups to the authoritative resolver MUST return valid A records if A records are requested and valid AAAA records if AAAA records are requested." Update Appendix B, Section 2(b) of the Baseline Requirements as follows: From: "This extension MUST be present and MUST NOT be marked critical. It MUST contain the HTTP URL of the CA?s CRL service." To: "This extension MUST be present and MUST NOT be marked critical. It MUST contain the HTTP URL of the CA?s CRL service. See Section 13.2.1 for details." ---MOTION ENDS--- The key changes from the previous pre-ballot are the wording changes suggested by Brian Smith, and attaching a concrete date - 1 year from now. _______________________________________________ Public mailing list Public at cabforum.org https://cabforum.org/mailman/listinfo/public _______________________________________________ Public mailing list Public at cabforum.org https://cabforum.org/mailman/listinfo/public From sleevi at google.com Thu Feb 19 20:11:27 2015 From: sleevi at google.com (Ryan Sleevi) Date: Thu, 19 Feb 2015 12:11:27 -0800 Subject: [cabfpub] Preballot for IPv6 Support In-Reply-To: <544B0DD62A64C1448B2DA253C01141460BD3E573A0@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> References: <544B0DD62A64C1448B2DA253C01141460BD3E573A0@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> Message-ID: Good point. What good is server a AAAA record from a DNS server that doesn't listen on IPv6 On Thu, Feb 19, 2015 at 11:25 AM, Rick Andrews wrote: > Ryan, > > It seems to me we need to add one more detail: it must be possible to make the lookups to the authoritative resolver (DNS) over IPv4 and IPv6. A client running on an IPv6-only network will first make a DNS call to get the AAAA record for the CA's OCSP or CRL service. So the CA needs to make sure that those DNS lookups can be served via IPv6. > > -Rick > > -----Original Message----- > From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Wayne Thayer > Sent: Thursday, February 19, 2015 8:54 AM > To: CABFPub > Subject: Re: [cabfpub] Preballot for IPv6 Support > > Ryan, > > We didn't find any blockers that prevent GoDaddy from enabling support for IPv6. Like other CAs, we also don't see any demand for it today, but I agree that this is a collective action problem and CAs need to remove certificate validation from the list of problems that are blocking other parties from moving to IPv6. GoDaddy supports this ballot and I would be happy to endorse. > > Thanks, > > Wayne > > -----Original Message----- > From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ryan Sleevi > Sent: Wednesday, February 18, 2015 3:01 PM > To: CABFPub > Subject: Re: [cabfpub] Preballot for IPv6 Support > > In advance of tomorrow's call, I'd like to bring forward this pre-ballot again > > ---MOTION BEGINS--- > > Update Section 13.2.1 of the Baseline Requirements as follows: > > From: > "The CA SHALL make revocation information for Subordinate Certificates and Subscriber Certificates available in accordance with Appendix B." > > To: > > "The CA SHALL make revocation information for Subordinate Certificates and Subscriber Certificates available in accordance with Appendix B. > > Effective March 1, 2016, the CA SHALL make this information available via both IPv4 and IPv6. For each DNS host included in accordance with Appendix B, lookups to the authoritative resolver MUST return valid A records if A records are requested and valid AAAA records if AAAA records are requested." > > Update Appendix B, Section 2(b) of the Baseline Requirements as follows: > > From: > "This extension MUST be present and MUST NOT be marked critical. It MUST contain the HTTP URL of the CA?s CRL service." > > To: > "This extension MUST be present and MUST NOT be marked critical. It MUST contain the HTTP URL of the CA?s CRL service. See Section 13.2.1 for details." > > ---MOTION ENDS--- > > The key changes from the previous pre-ballot are the wording changes suggested by Brian Smith, and attaching a concrete date - 1 year from now. > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public From geoffk at apple.com Thu Feb 19 20:50:56 2015 From: geoffk at apple.com (Geoff Keating) Date: Thu, 19 Feb 2015 12:50:56 -0800 Subject: [cabfpub] Preballot for IPv6 Support In-Reply-To: References: <544B0DD62A64C1448B2DA253C01141460BD3E573A0@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> Message-ID: <6F77FE02-17AB-48F7-BFFB-59634699FA28@apple.com> > On 19 Feb 2015, at 12:11 pm, Ryan Sleevi wrote: > > Good point. What good is server a AAAA record from a DNS server that > doesn't listen on IPv6 An IPv6-only client can use a recursive DNS server which has both IPv6 and IPv4 addresses, for example Google Public DNS or Comcast's DNS servers, so this isn't as high a priority as OCSP (but still an important step). -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4103 bytes Desc: not available URL: From philliph at comodo.com Thu Feb 19 23:41:07 2015 From: philliph at comodo.com (Phillip Hallam-Baker) Date: Thu, 19 Feb 2015 18:41:07 -0500 Subject: [cabfpub] Preballot for IPv6 Support In-Reply-To: References: <544B0DD62A64C1448B2DA253C01141460BD3E573A0@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> Message-ID: <17B2AFA3-EAF1-4439-8CA3-49ECF5AD2200@comodo.com> Actually it would work fine since an IPv6 client would not talk to the authoritative directly anyway, it would go through a recursive that is probably dual stack unless you are playing the DNS64 game. > On Feb 19, 2015, at 3:11 PM, Ryan Sleevi wrote: > > Good point. What good is server a AAAA record from a DNS server that > doesn't listen on IPv6 > > On Thu, Feb 19, 2015 at 11:25 AM, Rick Andrews > wrote: >> Ryan, >> >> It seems to me we need to add one more detail: it must be possible to make the lookups to the authoritative resolver (DNS) over IPv4 and IPv6. A client running on an IPv6-only network will first make a DNS call to get the AAAA record for the CA's OCSP or CRL service. So the CA needs to make sure that those DNS lookups can be served via IPv6. >> >> -Rick >> >> -----Original Message----- >> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Wayne Thayer >> Sent: Thursday, February 19, 2015 8:54 AM >> To: CABFPub >> Subject: Re: [cabfpub] Preballot for IPv6 Support >> >> Ryan, >> >> We didn't find any blockers that prevent GoDaddy from enabling support for IPv6. Like other CAs, we also don't see any demand for it today, but I agree that this is a collective action problem and CAs need to remove certificate validation from the list of problems that are blocking other parties from moving to IPv6. GoDaddy supports this ballot and I would be happy to endorse. >> >> Thanks, >> >> Wayne >> >> -----Original Message----- >> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ryan Sleevi >> Sent: Wednesday, February 18, 2015 3:01 PM >> To: CABFPub >> Subject: Re: [cabfpub] Preballot for IPv6 Support >> >> In advance of tomorrow's call, I'd like to bring forward this pre-ballot again >> >> ---MOTION BEGINS--- >> >> Update Section 13.2.1 of the Baseline Requirements as follows: >> >> From: >> "The CA SHALL make revocation information for Subordinate Certificates and Subscriber Certificates available in accordance with Appendix B." >> >> To: >> >> "The CA SHALL make revocation information for Subordinate Certificates and Subscriber Certificates available in accordance with Appendix B. >> >> Effective March 1, 2016, the CA SHALL make this information available via both IPv4 and IPv6. For each DNS host included in accordance with Appendix B, lookups to the authoritative resolver MUST return valid A records if A records are requested and valid AAAA records if AAAA records are requested." >> >> Update Appendix B, Section 2(b) of the Baseline Requirements as follows: >> >> From: >> "This extension MUST be present and MUST NOT be marked critical. It MUST contain the HTTP URL of the CA?s CRL service." >> >> To: >> "This extension MUST be present and MUST NOT be marked critical. It MUST contain the HTTP URL of the CA?s CRL service. See Section 13.2.1 for details." >> >> ---MOTION ENDS--- >> >> The key changes from the previous pre-ballot are the wording changes suggested by Brian Smith, and attaching a concrete date - 1 year from now. >> _______________________________________________ >> Public mailing list >> Public at cabforum.org >> https://cabforum.org/mailman/listinfo/public >> _______________________________________________ >> Public mailing list >> Public at cabforum.org >> https://cabforum.org/mailman/listinfo/public >> _______________________________________________ >> Public mailing list >> Public at cabforum.org >> https://cabforum.org/mailman/listinfo/public > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public From sleevi at google.com Thu Feb 19 23:42:55 2015 From: sleevi at google.com (Ryan Sleevi) Date: Thu, 19 Feb 2015 15:42:55 -0800 Subject: [cabfpub] Preballot for IPv6 Support In-Reply-To: <17B2AFA3-EAF1-4439-8CA3-49ECF5AD2200@comodo.com> References: <544B0DD62A64C1448B2DA253C01141460BD3E573A0@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <17B2AFA3-EAF1-4439-8CA3-49ECF5AD2200@comodo.com> Message-ID: On Thu, Feb 19, 2015 at 3:41 PM, Phillip Hallam-Baker wrote: > Actually it would work fine since an IPv6 client would not talk to the authoritative directly anyway, it would go through a recursive that is probably dual stack unless you are playing the DNS64 game. In theory, yes. In practice, no. I know what the RFCs say. I also know that RFCs are invitations for users to go buckwild and do their own thing :) Rather than worry about the many weird and wild ways in which users, enterprises, and network operators configure things, I think being explicit here on the expectations of infrastructure is the best solution for all. From i-barreira at izenpe.net Fri Feb 20 07:33:17 2015 From: i-barreira at izenpe.net (i-barreira at izenpe.net) Date: Fri, 20 Feb 2015 08:33:17 +0100 Subject: [cabfpub] When did the WebTrust/ETSI BR audit requirement becomemandatory? Message-ID: <763539E260C37C46A0D6B340B5434C3B0ADAED2D@AEX06.ejsarea.net> Kirk, From the ETSI side, you know that the CAs that want to be ETSI audited according to the BRs can do it according to the TS 102 042 v 2.4.1 which is effective since February 2013. OTOH mandating the CAs to be certified against ETSI, up to the regulation, that was on a voluntary basis. The regulation was approved last year and it mandates the certification (not decided yet which ones) for those service providers that want to issue qualified services and become a Qualified TSP by July 2016 with a year to send the conformity assessment to the supervisory body. So, the answer is that by July 2016 (having a year to do so) all TSPs that issue qualified certificates and are ?under? the regulation shall be certified, probably against ETSI standards like the new ENs. I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. De: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] En nombre de kirk_hall at trendmicro.com Enviado el: jueves, 19 de febrero de 2015 18:00 Para: CABFPub (public at cabforum.org) Asunto: [cabfpub] When did the WebTrust/ETSI BR audit requirement becomemandatory? On our Forum call today, we asked when a WebTrust/ETSI BR audit requirement become mandatory for CAs. Ballot 62 (Nov. 2011) adopted the BRs effective July 1, 2012. However, there were no audit criteria in place for some time. I did some quick research, and the answer is not clear as to when the audit criteria came into effect. The WebTrust draft audit requirements were completed by early 2013, and I see comments that Mozilla adopted the BR audit as a program requirement at the Mountain View meeting in Feb. 2013. Here is the current Mozilla requirement at Sec. 11: https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ As I recall, the initial Mozilla BR audit requirement was not clear as to exact effective date (what operational period must be covered by a CA?s initial BR audit). I vaguely recall Mozilla clarifying the rule at our Feb. 2013 meeting at Mountain View that all CA operations occurring on or after Feb. 15, 2013 must be covered by a BR audit ? so some CAs did partial-year initial BR audits to align their BR audits with their other audits. Based on all this, I would say all CAs should have full year BR audits in place by now. We can change our Bylaw on membership at Bylaw 2.1 to reflect this. Kirk R. Hall Operations Director, Trust Services Trend Micro +1.503.753.3088 TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 19121 bytes Desc: image001.png URL: From rob.stradling at comodo.com Fri Feb 20 09:37:04 2015 From: rob.stradling at comodo.com (Rob Stradling) Date: Fri, 20 Feb 2015 09:37:04 +0000 Subject: [cabfpub] Preballot for IPv6 Support In-Reply-To: References: Message-ID: <54E70040.2050203@comodo.com> On 19/02/15 16:54, Wayne Thayer wrote: > Like other CAs, we also don't see any demand for it today, but I agree that this is a collective action problem and CAs need to remove certificate validation from the list of problems that are blocking other parties from moving to IPv6. GoDaddy supports this ballot and I would be happy to endorse. +1 Ryan, I would also be happy to endorse this ballot on behalf of Comodo. > Thanks, > > Wayne > > -----Original Message----- > From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ryan Sleevi > Sent: Wednesday, February 18, 2015 3:01 PM > To: CABFPub > Subject: Re: [cabfpub] Preballot for IPv6 Support > > In advance of tomorrow's call, I'd like to bring forward this pre-ballot again > > ---MOTION BEGINS--- > > Update Section 13.2.1 of the Baseline Requirements as follows: > > From: > "The CA SHALL make revocation information for Subordinate Certificates and Subscriber Certificates available in accordance with Appendix B." > > To: > > "The CA SHALL make revocation information for Subordinate Certificates and Subscriber Certificates available in accordance with Appendix B. > > Effective March 1, 2016, the CA SHALL make this information available via both IPv4 and IPv6. For each DNS host included in accordance with Appendix B, lookups to the authoritative resolver MUST return valid A records if A records are requested and valid AAAA records if AAAA records are requested." > > Update Appendix B, Section 2(b) of the Baseline Requirements as follows: > > From: > "This extension MUST be present and MUST NOT be marked critical. It MUST contain the HTTP URL of the CA?s CRL service." > > To: > "This extension MUST be present and MUST NOT be marked critical. It MUST contain the HTTP URL of the CA?s CRL service. See Section 13.2.1 for details." > > ---MOTION ENDS--- > > The key changes from the previous pre-ballot are the wording changes suggested by Brian Smith, and attaching a concrete date - 1 year from now. > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. From i-barreira at izenpe.net Fri Feb 20 09:54:51 2015 From: i-barreira at izenpe.net (i-barreira at izenpe.net) Date: Fri, 20 Feb 2015 10:54:51 +0100 Subject: [cabfpub] issues with DNSSEC Message-ID: <763539E260C37C46A0D6B340B5434C3B0AE7E2B1@AEX06.ejsarea.net> Hi, It affects BIND with DNSSEC validation https://kb.isc.org/article/AA-01235/74/CVE-2015-1349%3A-A-Problem-with-Trust-Anchor-Management-Can-Cause-named-to-Crash.html Regards I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 19121 bytes Desc: image001.png URL: From kirk_hall at trendmicro.com Fri Feb 20 16:51:39 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Fri, 20 Feb 2015 16:51:39 +0000 Subject: [cabfpub] When did the WebTrust/ETSI BR audit requirement become mandatory? In-Reply-To: References: Message-ID: Sorry, I should have clarified. Any CA can get a point in time or ?readiness? BR audit at any time, even just before starting operations. Plus any CA can get a 60 day or 90 day performance BR audit once they start operations ? in fact, that is the recommended method (i.e., don?t wait a whole year). In general, a CA can?t start selling certs to anyone until the CA has its roots in the browsers. And the browsers won?t add the roots until they see (at least) a WebTrust and a BR readiness audit ? so there really is no blocking effect on the membership rules from requiring the audits. A CA can?t be in operation (can?t be in the browsers) until that happens. Plus ? when my new CA, AffirmTrust (acquired by Trend Micro) applied to the Forum, we had our audits but no customers yet (because at that time, the Mozilla root review process was very slow). The Forum accepted us, but only on an observer basis, not member, until we started issuing certs to customers. From: Peter Bowen [mailto:pzbowen at gmail.com] Sent: Thursday, February 19, 2015 7:14 PM To: Kirk Hall (RD-US); CABFPub (public at cabforum.org) Cc: questions at cabforum.org Subject: Re: [cabfpub] When did the WebTrust/ETSI BR audit requirement become mandatory? (copying questions@ for visibility) On Thu, Feb 19, 2015 at 8:59 AM, kirk_hall at trendmicro.com > wrote: Based on all this, I would say all CAs should have full year BR audits in place by now. We can change our Bylaw on membership at Bylaw 2.1 to reflect this. Have you considered that it is possible a new CA might want to become a member before their first anniversary of operation? If you require a full year BR audit for membership, you are effectively excluding new CAs, as they presumably will start with a point in time then a partial year audit (given the requirement to get a period of time audit started within 90 days of issuing the first certificate). 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
-------------- next part -------------- An HTML attachment was scrubbed... URL: From i-barreira at izenpe.net Fri Feb 20 18:53:44 2015 From: i-barreira at izenpe.net (=?utf-8?B?IkJhcnJlaXJhIElnbGVzaWFzLCBJw7FpZ28i?=) Date: Fri, 20 Feb 2015 19:53:44 +0100 Subject: [cabfpub] When did the WebTrust/ETSI BR audit requirement become mandatory? Message-ID: Kirk, any CA can sell certs without having any audit. It's up to the customers. It's their decission. You can add the CA manually Enviado de Samsung Mobile -------- Mensaje original -------- De: kirk_hall at trendmicro.com Fecha: Para: Peter Bowen ,"CABFPub (public at cabforum.org)" Cc: questions at cabforum.org Asunto: Re: [cabfpub] When did the WebTrust/ETSI BR audit requirement become mandatory? Sorry, I should have clarified. ? Any CA can get a point in time or ?readiness? BR audit at any time, even just before starting operations. ? Plus any CA can get a 60 day or 90 day performance BR audit once they start operations ? in fact, that is the recommended method (i.e., don?t wait a whole year). ? In general, a CA can?t start selling certs to anyone until the CA has its roots in the browsers.? And the browsers won?t add the roots until they see (at least) a WebTrust and a BR readiness audit ? so there really is no blocking effect on the membership rules from requiring the audits. ?A CA can?t be in operation (can?t be in the browsers) until that happens. ? Plus ? when my new CA, AffirmTrust (acquired by Trend Micro) applied to the Forum, we had our audits but no customers yet (because at that time, the Mozilla root review process was very slow).? The Forum accepted us, but only on an observer basis, not member, until we started issuing certs to customers. ? From: Peter Bowen [mailto:pzbowen at gmail.com] Sent: Thursday, February 19, 2015 7:14 PM To: Kirk Hall (RD-US); CABFPub (public at cabforum.org) Cc: questions at cabforum.org Subject: Re: [cabfpub] When did the WebTrust/ETSI BR audit requirement become mandatory? ? (copying questions@ for visibility) ? On Thu, Feb 19, 2015 at 8:59 AM, kirk_hall at trendmicro.com wrote: Based on all this, I would say all CAs should have full year BR audits in place by now.? We can change our Bylaw on membership at Bylaw 2.1 to reflect this. ? Have you considered that it is possible a new CA might want to become a member before their first anniversary of operation?? If you require a full year BR audit for membership, you are effectively excluding new CAs, as they presumably will start with a point in time then a partial year audit (given the requirement to get a period of time audit started within 90 days of issuing the first certificate). TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirk_hall at trendmicro.com Fri Feb 20 19:01:55 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Fri, 20 Feb 2015 19:01:55 +0000 Subject: [cabfpub] When did the WebTrust/ETSI BR audit requirement become mandatory? In-Reply-To: References: Message-ID: That?s true ? but every person visiting the site would have to do the same thing. So as a practical matter, no commercial CA will proceed in selling certs generally without its roots being in the main browser root stores, which requires completed WebTrust/ETSI audits to be delivered to the browsers. And I don?t think the Forum needs to have ?private? CA members. From: "Barreira Iglesias, I?igo" [mailto:i-barreira at izenpe.net] Sent: Friday, February 20, 2015 10:54 AM To: Kirk Hall (RD-US); Peter Bowen; public at cabforum.org Cc: questions at cabforum.org Subject: Re: [cabfpub] When did the WebTrust/ETSI BR audit requirement become mandatory? Kirk, any CA can sell certs without having any audit. It's up to the customers. It's their decission. You can add the CA manually Enviado de Samsung Mobile -------- Mensaje original -------- De: kirk_hall at trendmicro.com Fecha: Para: Peter Bowen ,"CABFPub (public at cabforum.org)" Cc: questions at cabforum.org Asunto: Re: [cabfpub] When did the WebTrust/ETSI BR audit requirement become mandatory? Sorry, I should have clarified. Any CA can get a point in time or ?readiness? BR audit at any time, even just before starting operations. Plus any CA can get a 60 day or 90 day performance BR audit once they start operations ? in fact, that is the recommended method (i.e., don?t wait a whole year). In general, a CA can?t start selling certs to anyone until the CA has its roots in the browsers. And the browsers won?t add the roots until they see (at least) a WebTrust and a BR readiness audit ? so there really is no blocking effect on the membership rules from requiring the audits. A CA can?t be in operation (can?t be in the browsers) until that happens. Plus ? when my new CA, AffirmTrust (acquired by Trend Micro) applied to the Forum, we had our audits but no customers yet (because at that time, the Mozilla root review process was very slow). The Forum accepted us, but only on an observer basis, not member, until we started issuing certs to customers. From: Peter Bowen [mailto:pzbowen at gmail.com] Sent: Thursday, February 19, 2015 7:14 PM To: Kirk Hall (RD-US); CABFPub (public at cabforum.org) Cc: questions at cabforum.org Subject: Re: [cabfpub] When did the WebTrust/ETSI BR audit requirement become mandatory? (copying questions@ for visibility) On Thu, Feb 19, 2015 at 8:59 AM, kirk_hall at trendmicro.com > wrote: Based on all this, I would say all CAs should have full year BR audits in place by now. We can change our Bylaw on membership at Bylaw 2.1 to reflect this. Have you considered that it is possible a new CA might want to become a member before their first anniversary of operation? If you require a full year BR audit for membership, you are effectively excluding new CAs, as they presumably will start with a point in time then a partial year audit (given the requirement to get a period of time audit started within 90 days of issuing the first certificate). TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
-------------- next part -------------- An HTML attachment was scrubbed... URL: From eddy_nigg at startcom.org Fri Feb 20 21:10:06 2015 From: eddy_nigg at startcom.org (Eddy Nigg) Date: Fri, 20 Feb 2015 23:10:06 +0200 Subject: [cabfpub] When did the WebTrust/ETSI BR audit requirement become mandatory? In-Reply-To: References: Message-ID: <54E7A2AE.2040501@startcom.org> On 02/20/2015 09:01 PM, kirk_hall at trendmicro.com wrote: > > That's true -- but every person visiting the site would have to do the > same thing. So as a practical matter, no commercial CA will proceed > in selling certs generally without its roots being in the main browser > root stores, which requires completed WebTrust/ETSI audits to be > delivered to the browsers. And I don't think the Forum needs to have > "private" CA members. > The forum requires a CA to be supported by at least one major browser. But it can be a browser that isn't Mozilla - on the other hand why should WebTrust perform any other audits today than BR? -- Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. XMPP: startcom at startcom.org Blog: Join the Revolution! Twitter: Follow Me -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4313 bytes Desc: S/MIME Cryptographic Signature URL: From kirk_hall at trendmicro.com Fri Feb 20 21:45:15 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Fri, 20 Feb 2015 21:45:15 +0000 Subject: [cabfpub] When did the WebTrust/ETSI BR audit requirement become mandatory? In-Reply-To: <54E7A2AE.2040501@startcom.org> References: <54E7A2AE.2040501@startcom.org> Message-ID: When you say "why" - do you mean "is regular WebTrust still required?" (it is, along with BR WebTrust), or are you suggesting that regular WebTrust should no longer be a requirement, just BR WebTrust? In an earlier string, this was asked and I recall Don Sheehy noted that the two audit regimes are somewhat overlapping in certain areas, but otherwise cover different issues and are both still needed. From: Eddy Nigg [mailto:eddy_nigg at startcom.org] Sent: Friday, February 20, 2015 1:10 PM To: Kirk Hall (RD-US); i-barreira; Peter Bowen; public at cabforum.org Subject: Re: [cabfpub] When did the WebTrust/ETSI BR audit requirement become mandatory? On 02/20/2015 09:01 PM, kirk_hall at trendmicro.com wrote: That's true - but every person visiting the site would have to do the same thing. So as a practical matter, no commercial CA will proceed in selling certs generally without its roots being in the main browser root stores, which requires completed WebTrust/ETSI audits to be delivered to the browsers. And I don't think the Forum needs to have "private" CA members. The forum requires a CA to be supported by at least one major browser. But it can be a browser that isn't Mozilla - on the other hand why should WebTrust perform any other audits today than BR? -- Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. XMPP: startcom at startcom.org Blog: Join the Revolution! Twitter: Follow Me 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
-------------- next part -------------- An HTML attachment was scrubbed... URL: From eddy_nigg at startcom.org Fri Feb 20 22:03:18 2015 From: eddy_nigg at startcom.org (Eddy Nigg) Date: Sat, 21 Feb 2015 00:03:18 +0200 Subject: [cabfpub] When did the WebTrust/ETSI BR audit requirement become mandatory? In-Reply-To: References: <54E7A2AE.2040501@startcom.org> Message-ID: <54E7AF26.8000706@startcom.org> On 02/20/2015 11:45 PM, kirk_hall at trendmicro.com wrote: > > When you say ?why? ? do you mean ?is regular WebTrust still required?? > (it is, along with BR WebTrust), or are you suggesting that regular > WebTrust should no longer be a requirement, just BR WebTrust? > I certainly would expect that this will become one (basic) audit eventually (and EV and others optional). -- Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. XMPP: startcom at startcom.org Blog: Join the Revolution! Twitter: Follow Me -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4313 bytes Desc: S/MIME Cryptographic Signature URL: From gerv at mozilla.org Mon Feb 23 14:10:10 2015 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 23 Feb 2015 14:10:10 +0000 Subject: [cabfpub] When did the WebTrust/ETSI BR audit requirement become mandatory? In-Reply-To: References: <54E61E67.6090409@mozilla.org> Message-ID: <54EB34C2.3040600@mozilla.org> On 19/02/15 18:28, kirk_hall at trendmicro.com wrote: > The > Requirements are not mandatory for Certification Authorities unless and > until they become adopted and enforced by relying?party Application > Software Suppliers. *** This sentence seems to me to say precisely what I am saying. Making a BR audit a condition of membership is moving towards making the BRs mandatory for CAs for a reason _other_ than "they are enforced by relying party Application Software Suppliers". Which would be contrary to this sentence. > No CA is required to join the Forum to operate ? the CAs only need to > satisfy the browsers. But I can?t think of any reason why a CA would > choose NOT to follow the BRs and get a BR audit if it wants to be > considered a ?real? CA. Well, perhaps there is some aspect of the BRs that they disagree with, or cannot follow for legal reasons, and wish to join in order to get things changed? I am also troubled by the general principle of "if you want a voice in getting these requirements changed, you have to abide by them first". The CAB Forum does not control the WebTrust audit criteria so this problem is not apparent when we use that as a membership filter. > And I don?t think the Forum would want to accept any new CA member that > said ?I choose not to follow the BRs, and I choose not to get a BR > audit? ? why would we want such a CA as a member? The CA/Browser Forum is not a gentleman's club; we don't get to blackball people because we don't like the way they do things. The CAB Forum also does not assess the suitability or trustworthiness of CAs for any particular role or task. Unless we think that the current criteria for CA membership are so loose that people are applying for membership who are not "real CAs", then there is no need to change the criteria. Gerv From bruce.morton at entrust.com Mon Feb 23 18:41:50 2015 From: bruce.morton at entrust.com (Bruce Morton) Date: Mon, 23 Feb 2015 18:41:50 +0000 Subject: [cabfpub] Lenovo installation of malicious root. In-Reply-To: <9CB5BBD9-58FA-4DC2-90E0-70F01911A4AC@comodo.com> References: <9CB5BBD9-58FA-4DC2-90E0-70F01911A4AC@comodo.com> Message-ID: <452C99D20750E74083DBA441FF932385E419DB78@SOTTEXCH10.corp.ad.entrust.com> Have we just come across an issue with operating systems/browsers and private roots? I suppose an attacker can install proxy software with their private root and examine all secured traffic. We don't need Lenovo to install this software, this could easily be done by any corner-store computer shop. Should private roots get the same trust indication as public trust roots? Public key pinning didn't even catch this issue as the private root seems to be trusted more than the public trust roots are. Thanks, Bruce. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Phillip Hallam-Baker Sent: Thursday, February 19, 2015 1:53 PM To: CABFPub Subject: [cabfpub] Lenovo installation of malicious root. I am sure many of you have seen this. If not you will, I have had a dozen people ping me about it in the past hour. https://www.eff.org/deeplinks/2015/02/further-evidence-lenovo-breaking-https-security-its-laptops Someone has to draw the line here or the politicians will do it for us. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sleevi at google.com Mon Feb 23 19:05:25 2015 From: sleevi at google.com (Ryan Sleevi) Date: Mon, 23 Feb 2015 11:05:25 -0800 Subject: [cabfpub] Lenovo installation of malicious root. In-Reply-To: <452C99D20750E74083DBA441FF932385E419DB78@SOTTEXCH10.corp.ad.entrust.com> References: <9CB5BBD9-58FA-4DC2-90E0-70F01911A4AC@comodo.com> <452C99D20750E74083DBA441FF932385E419DB78@SOTTEXCH10.corp.ad.entrust.com> Message-ID: On Mon, Feb 23, 2015 at 10:41 AM, Bruce Morton wrote: > Have we just come across an issue with operating systems/browsers and > private roots? > Yes > > > I suppose an attacker can install proxy software with their private root and > examine all secured traffic. We don?t need Lenovo to install this software, > this could easily be done by any corner-store computer shop. > Correct > > > Should private roots get the same trust indication as public trust roots? > Yes. > > > Public key pinning didn?t even catch this issue as the private root seems to > be trusted more than the public trust roots are. Correct, because public key pinning is not designed to catch such issues, as it cannot catch such issues. http://www.chromium.org/Home/chromium-security/security-faq#TOC-How-does-key-pinning-interact-with-local-proxies-and-filters- > > > > Thanks, Bruce. > From palmer at google.com Mon Feb 23 19:37:30 2015 From: palmer at google.com (Chris Palmer) Date: Mon, 23 Feb 2015 11:37:30 -0800 Subject: [cabfpub] Lenovo installation of malicious root. In-Reply-To: References: <9CB5BBD9-58FA-4DC2-90E0-70F01911A4AC@comodo.com> <452C99D20750E74083DBA441FF932385E419DB78@SOTTEXCH10.corp.ad.entrust.com> Message-ID: Also, Comodo might want to tell us what is going on here: http://news.softpedia.com/news/Comodo-s-PrivDog-Breaks-HTTPS-Security-Possibly-Worse-than-Superfish-473968.shtml On Feb 23, 2015 11:05, "Ryan Sleevi" wrote: > On Mon, Feb 23, 2015 at 10:41 AM, Bruce Morton > wrote: > > Have we just come across an issue with operating systems/browsers and > > private roots? > > > > Yes > > > > > > > I suppose an attacker can install proxy software with their private root > and > > examine all secured traffic. We don?t need Lenovo to install this > software, > > this could easily be done by any corner-store computer shop. > > > > Correct > > > > > > > Should private roots get the same trust indication as public trust roots? > > > > Yes. > > > > > > > Public key pinning didn?t even catch this issue as the private root > seems to > > be trusted more than the public trust roots are. > > Correct, because public key pinning is not designed to catch such > issues, as it cannot catch such issues. > > > http://www.chromium.org/Home/chromium-security/security-faq#TOC-How-does-key-pinning-interact-with-local-proxies-and-filters- > > > > > > > > > Thanks, Bruce. > > > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.wilson at digicert.com Mon Feb 23 21:39:59 2015 From: ben.wilson at digicert.com (Ben Wilson) Date: Mon, 23 Feb 2015 21:39:59 +0000 Subject: [cabfpub] Version 1.5.3 redlined with Ballot 144 Changes Message-ID: All, Attached please find a Word version of the EV Guidelines redlined with changes from Ballot 144. Previous versions of the EV Guidelines in Word would cause some people's computers to crash while they were editing the EV Guidelines. Could a few of your take a look at this document and confirm that it is stable? Hopefully this version has eliminated that problem. Thanks, Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: EV V1_5_3-redlined.doc Type: application/msword Size: 351744 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4954 bytes Desc: not available URL: From Rick_Andrews at symantec.com Mon Feb 23 21:50:50 2015 From: Rick_Andrews at symantec.com (Rick Andrews) Date: Mon, 23 Feb 2015 13:50:50 -0800 Subject: [cabfpub] Version 1.5.3 redlined with Ballot 144 Changes In-Reply-To: References: Message-ID: <544B0DD62A64C1448B2DA253C01141460BD3FDC905@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> Ben, I got through the document without problems. I see two nits: "For a Certificate issued to a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant's control over the .onion Domain Name in accordance with Appendix F." That's not grammatically correct. Maybe say "the Applicant has control"? Appendix F: Number 1 isn't properly indented. -Rick From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ben Wilson Sent: Monday, February 23, 2015 1:40 PM To: CABFPub Subject: [cabfpub] Version 1.5.3 redlined with Ballot 144 Changes All, Attached please find a Word version of the EV Guidelines redlined with changes from Ballot 144. Previous versions of the EV Guidelines in Word would cause some people's computers to crash while they were editing the EV Guidelines. Could a few of your take a look at this document and confirm that it is stable? Hopefully this version has eliminated that problem. Thanks, Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.wilson at digicert.com Mon Feb 23 21:51:19 2015 From: ben.wilson at digicert.com (Ben Wilson) Date: Mon, 23 Feb 2015 21:51:19 +0000 Subject: [cabfpub] Version 1.2.4 of Baseline Requirements redlined with Ballot 144 Changes Message-ID: All, Similar to my request concerning version of the EV Guidelines just circulated, please confirm that this document (v. 1.2.4 of Baseline Requirements) is in order. Thanks, Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: BRv1.2.4-redlined.doc Type: application/msword Size: 514560 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4954 bytes Desc: not available URL: From ben.wilson at digicert.com Tue Feb 24 01:35:22 2015 From: ben.wilson at digicert.com (Ben Wilson) Date: Tue, 24 Feb 2015 01:35:22 +0000 Subject: [cabfpub] Version 1.2.4 of Baseline Requirements redlined with Ballot 144 Changes In-Reply-To: References: Message-ID: All, Peter Bowen reminded me that we need to update section 16.5 of the BRs - see https://bugzilla.cabforum.org/show_bug.cgi?id=10. I suppose that when I introduce a ballot to reformat the BRs to RFC 3647, that will take care of it. Ben From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ben Wilson Sent: Monday, February 23, 2015 2:51 PM To: CABFPub Subject: [cabfpub] Version 1.2.4 of Baseline Requirements redlined with Ballot 144 Changes All, Similar to my request concerning version of the EV Guidelines just circulated, please confirm that this document (v. 1.2.4 of Baseline Requirements) is in order. Thanks, Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4954 bytes Desc: not available URL: From robin at comodo.com Tue Feb 24 04:21:47 2015 From: robin at comodo.com (Robin Alden) Date: Mon, 23 Feb 2015 23:21:47 -0500 Subject: [cabfpub] Lenovo installation of malicious root. In-Reply-To: References: <9CB5BBD9-58FA-4DC2-90E0-70F01911A4AC@comodo.com> <452C99D20750E74083DBA441FF932385E419DB78@SOTTEXCH10.corp.ad.entrust.com> Message-ID: <00a901d04fe9$68eed040$3acc70c0$@comodo.com> Hi Chris, PrivDog is not a Comodo Group product. Comodo ships a version of PrivDog with Comodo Internet Security (CIS) and with Comodo browsers, but that is an earlier release which does not exhibit the identified behaviour. The PrivDog versions being downloaded and evaluated by security researchers is a newer stand-alone version that has never been distributed by Comodo. The issue is only present in PrivDog versions 3.0.96.0 and 3.0.97.0 and is apparently due to a bug in a third party library that PrivDog bought in. The PrivDog team has released an advisory with more information, available here: http://privdog.com/advisory.html I see that Hanno has updated his page somewhat, too, to remove the claim that it is Comodo distributing this flawed version of PrivDog. https://blog.hboeck.de/archives/865-Adware-Privdog-worse-than-Superfish.html c.f. http://web.archive.org/web/20150223010209/https://blog.hboeck.de/archives/865-Comodo-ships-Adware-Privdog-worse-than-Superfish.html Regards Robin Alden Comodo CA Ltd. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Chris Palmer Sent: 23 February 2015 14:38 To: Ryan Sleevi Cc: public at cabforum.org Subject: Re: [cabfpub] Lenovo installation of malicious root. Also, Comodo might want to tell us what is going on here: http://news.softpedia.com/news/Comodo-s-PrivDog-Breaks-HTTPS-Security-Possibly-Worse-than-Superfish-473968.shtml On Feb 23, 2015 11:05, "Ryan Sleevi" wrote: On Mon, Feb 23, 2015 at 10:41 AM, Bruce Morton wrote: > Have we just come across an issue with operating systems/browsers and > private roots? > Yes > > > I suppose an attacker can install proxy software with their private root and > examine all secured traffic. We don?t need Lenovo to install this software, > this could easily be done by any corner-store computer shop. > Correct > > > Should private roots get the same trust indication as public trust roots? > Yes. > > > Public key pinning didn?t even catch this issue as the private root seems to > be trusted more than the public trust roots are. Correct, because public key pinning is not designed to catch such issues, as it cannot catch such issues. http://www.chromium.org/Home/chromium-security/security-faq#TOC-How-does-key-pinning-interact-with-local-proxies-and-filters- > > > > Thanks, Bruce. > _______________________________________________ Public mailing list Public at cabforum.org https://cabforum.org/mailman/listinfo/public -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5776 bytes Desc: not available URL: From kirk_hall at trendmicro.com Tue Feb 24 06:17:19 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Tue, 24 Feb 2015 06:17:19 +0000 Subject: [cabfpub] When did the WebTrust/ETSI BR audit requirement become mandatory? In-Reply-To: <54EC12E1.7030407@certizen.com> References: <54E61E67.6090409@mozilla.org> <54EB34C2.3040600@mozilla.org> <54EC12E1.7030407@certizen.com> Message-ID: There is no fee. -----Original Message----- From: Man Ho (Certizen) [mailto:manho at certizen.com] Sent: Monday, February 23, 2015 9:58 PM To: Gervase Markham; Kirk Hall (RD-US); CABFPub (public at cabforum.org) Subject: Re: [cabfpub] When did the WebTrust/ETSI BR audit requirement become mandatory? On 2/23/2015 10:10 PM, Gervase Markham wrote: > Well, perhaps there is some aspect of the BRs that they disagree with, > or cannot follow for legal reasons, and wish to join in order to get > things changed? > > I am also troubled by the general principle of "if you want a voice in > getting these requirements changed, you have to abide by them first". > The CAB Forum does not control the WebTrust audit criteria so this > problem is not apparent when we use that as a membership filter. +1 BTW, is there any membership fee for joining the CAB/Forum? -- Man Ho 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
From robin at comodo.com Tue Feb 24 12:46:29 2015 From: robin at comodo.com (Robin Alden) Date: Tue, 24 Feb 2015 07:46:29 -0500 Subject: [cabfpub] Lenovo installation of malicious root. In-Reply-To: <00a901d04fe9$68eed040$3acc70c0$@comodo.com> References: <9CB5BBD9-58FA-4DC2-90E0-70F01911A4AC@comodo.com> <452C99D20750E74083DBA441FF932385E419DB78@SOTTEXCH10.corp.ad.entrust.com> <00a901d04fe9$68eed040$3acc70c0$@comodo.com> Message-ID: <019c01d0502f$eb4fb9a0$c1ef2ce0$@comodo.com> That archive.org link I gave is dead. I?ve put a screen grab of the old page here: https://app.ccloud.com/#share/1783 &6ac37df3dbd2a650399cb25639157cbe017bc9b9 for comparison with https://blog.hboeck.de/archives/865-Adware-Privdog-worse-than-Superfish.html Regards Robin From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Robin Alden Sent: 23 February 2015 23:22 To: 'Chris Palmer'; 'Ryan Sleevi' Cc: public at cabforum.org Subject: Re: [cabfpub] Lenovo installation of malicious root. Hi Chris, PrivDog is not a Comodo Group product. Comodo ships a version of PrivDog with Comodo Internet Security (CIS) and with Comodo browsers, but that is an earlier release which does not exhibit the identified behaviour. The PrivDog versions being downloaded and evaluated by security researchers is a newer stand-alone version that has never been distributed by Comodo. The issue is only present in PrivDog versions 3.0.96.0 and 3.0.97.0 and is apparently due to a bug in a third party library that PrivDog bought in. The PrivDog team has released an advisory with more information, available here: http://privdog.com/advisory.html I see that Hanno has updated his page somewhat, too, to remove the claim that it is Comodo distributing this flawed version of PrivDog. https://blog.hboeck.de/archives/865-Adware-Privdog-worse-than-Superfish.html c.f. http://web.archive.org/web/20150223010209/https://blog.hboeck.de/archives/865-Comodo-ships-Adware-Privdog-worse-than-Superfish.html Regards Robin Alden Comodo CA Ltd. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Chris Palmer Sent: 23 February 2015 14:38 To: Ryan Sleevi Cc: public at cabforum.org Subject: Re: [cabfpub] Lenovo installation of malicious root. Also, Comodo might want to tell us what is going on here: http://news.softpedia.com/news/Comodo-s-PrivDog-Breaks-HTTPS-Security-Possibly-Worse-than-Superfish-473968.shtml -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.wilson at digicert.com Tue Feb 24 15:21:44 2015 From: ben.wilson at digicert.com (Ben Wilson) Date: Tue, 24 Feb 2015 15:21:44 +0000 Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Message-ID: <4214ab2ac59143c3a726ad7419792a45@EX2.corp.digicert.com> Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework The Certificate Policy Review Working Group was chartered by Ballot 128 to (i) consider existing and proposed standards, (ii) create a list of potential improvements based on the considered standards that improve the existing CAB Forum work product, (iii) evaluate the transition to a 3647 format based on the amount [of work involved]. One deliverable of the CP Review WG was to propose a ballot to improve CA infrastructure based on existing standards and documents and recommend whether to finish the 3647 conversion presented by Jeremy Rowley in January 2014. The CP Review WG has met and concluded that the best path forward for the Forum is to complete a conversion to the RFC 3647 for the Baseline Requirements with an initial step that merely moves existing content from the Baseline Requirements and the Network and Certificate System Security Requirements into the RFC 3647 format. Attached is an RFC-3647-formatted Certificate Policy for Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates. Comments embedded in the document contain either the source of the text (for content copied from the Baseline Requirements) or the current text (for provisions incorporated by reference from the Network and Certificate System Security Requirements ("NetSec"). It was decided that it was better to incorporate the NetSec requirements by reference rather than copying and pasting them in. In some limited instances the phrase "these Requirements" has been replaced with "this CP." However, "these Requirements" is mostly left in to preserve consistency with the current Baseline Requirements. Ben Wilson of DigiCert made the following motion, from and from have endorsed it. Motion Begins Be it resolved that the CA / Browser Forum adopts the attached CA/B Forum Certificate Policy v.1.2.5, effective immediately. Motion Ends The review period for this ballot shall commence at 2200 UTC on March 2015 and will close at 2200 UTC on March 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on March 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the ballot must indicate a clear 'yes' in the response. A vote against the ballot must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/. In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and more than one half of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or by abstaining for the vote to be valid. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: CAB Forum BR 3647 CP Draft.doc Type: application/msword Size: 601600 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4954 bytes Desc: not available URL: From THollebeek at trustwave.com Tue Feb 24 15:49:07 2015 From: THollebeek at trustwave.com (Tim Hollebeek) Date: Tue, 24 Feb 2015 15:49:07 +0000 Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework In-Reply-To: <4214ab2ac59143c3a726ad7419792a45@EX2.corp.digicert.com> References: <4214ab2ac59143c3a726ad7419792a45@EX2.corp.digicert.com> Message-ID: I'll endorse. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ben Wilson Sent: Tuesday, February 24, 2015 10:22 AM To: CABFPub Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework The Certificate Policy Review Working Group was chartered by Ballot 128 to (i) consider existing and proposed standards, (ii) create a list of potential improvements based on the considered standards that improve the existing CAB Forum work product, (iii) evaluate the transition to a 3647 format based on the amount [of work involved]. One deliverable of the CP Review WG was to propose a ballot to improve CA infrastructure based on existing standards and documents and recommend whether to finish the 3647 conversion presented by Jeremy Rowley in January 2014. The CP Review WG has met and concluded that the best path forward for the Forum is to complete a conversion to the RFC 3647 for the Baseline Requirements with an initial step that merely moves existing content from the Baseline Requirements and the Network and Certificate System Security Requirements into the RFC 3647 format. Attached is an RFC-3647-formatted Certificate Policy for Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates. Comments embedded in the document contain either the source of the text (for content copied from the Baseline Requirements) or the current text (for provisions incorporated by reference from the Network and Certificate System Security Requirements ("NetSec"). It was decided that it was better to incorporate the NetSec requirements by reference rather than copying and pasting them in. In some limited instances the phrase "these Requirements" has been replaced with "this CP." However, "these Requirements" is mostly left in to preserve consistency with the current Baseline Requirements. Ben Wilson of DigiCert made the following motion, from and from have endorsed it. Motion Begins Be it resolved that the CA / Browser Forum adopts the attached CA/B Forum Certificate Policy v.1.2.5, effective immediately. Motion Ends The review period for this ballot shall commence at 2200 UTC on March 2015 and will close at 2200 UTC on March 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on March 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the ballot must indicate a clear 'yes' in the response. A vote against the ballot must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/. In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and more than one half of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or by abstaining for the vote to be valid. ________________________________ This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirk_hall at trendmicro.com Tue Feb 24 16:51:48 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Tue, 24 Feb 2015 16:51:48 +0000 Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework In-Reply-To: <4214ab2ac59143c3a726ad7419792a45@EX2.corp.digicert.com> References: <4214ab2ac59143c3a726ad7419792a45@EX2.corp.digicert.com> Message-ID: Ben - first of all, thanks for the hard work on this one. I'm trying to figure out the benefit of locking the Forum into the RFC 3647 framework for the purpose of listing BR requirements. Is there really a benefit? Does it add to understanding and make CA compliance any easier? Or will it force us to put rules in odd places that actually make understanding a bit harder? I note the BR 8.2 already requires CAs to put their CPS into the format of RFC 2527 or 3647. See the first two sections of BR 8.2 below. That can facilitate comparison between the CPSs of different CAs, if anyone cares to do that. But is there any corresponding benefit from restructuring the BRs to an RFC 3647 format? What if a rule spans two or more different sections of the RFC 3647 format? I see that in your new organization of the BRs you have moved old BR 8.2.2 to a new Section 2.1 Repositories, not to new Section 2.2 Publication of Information. How did you make that choice? And is there an expectation that CAs will publish their CAA disclosure in new Sec. 2.2 of their CPS? I'm just afraid we will be handcuffing ourselves with these changes, and that there could be errors in internal cross-references. It is also a lot of work for everyone to review a complete rewrite of the BRs. Can you give us a convincing argument of why this is worth doing? Sorry I didn't ask this question earlier, but I hadn't really understood this was what the working group was doing - I thought you were just looking for GAPS in the BRs as compared to the RFC 3647 where we could ADD new provisions to the BRs - not a wholesale restructuring of the BRs. Thanks. BR 8.2.2 Disclosure The CA SHALL publicly disclose its Certificate Policy and/or Certification Practice Statement through an appropriate and readily accessible online means that is available on a 24x7 basis. The CA SHALL publicly disclose its CA business practices to the extent required by the CA's selected audit scheme (see Section 17.1). The disclosures MUST include all the material required by RFC 2527 or RFC 3647, and MUST be structured in accordance with either RFC 2527 or RFC 3647. Effective as of 15 April 2015, section 4.2 of a CA's Certificate Policy and/or Certification Practice Statement (section 4.1 for CAs still conforming to RFC 2527) SHALL state whether the CA reviews CAA Records, and if so, the CA's policy or practice on processing CAA Records for Fully Qualified Domain Names. The CA SHALL log all actions taken, if any, consistent with its processing practice. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ben Wilson Sent: Tuesday, February 24, 2015 7:22 AM To: CABFPub Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework The Certificate Policy Review Working Group was chartered by Ballot 128 to (i) consider existing and proposed standards, (ii) create a list of potential improvements based on the considered standards that improve the existing CAB Forum work product, (iii) evaluate the transition to a 3647 format based on the amount [of work involved]. One deliverable of the CP Review WG was to propose a ballot to improve CA infrastructure based on existing standards and documents and recommend whether to finish the 3647 conversion presented by Jeremy Rowley in January 2014. The CP Review WG has met and concluded that the best path forward for the Forum is to complete a conversion to the RFC 3647 for the Baseline Requirements with an initial step that merely moves existing content from the Baseline Requirements and the Network and Certificate System Security Requirements into the RFC 3647 format. Attached is an RFC-3647-formatted Certificate Policy for Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates. Comments embedded in the document contain either the source of the text (for content copied from the Baseline Requirements) or the current text (for provisions incorporated by reference from the Network and Certificate System Security Requirements ("NetSec"). It was decided that it was better to incorporate the NetSec requirements by reference rather than copying and pasting them in. In some limited instances the phrase "these Requirements" has been replaced with "this CP." However, "these Requirements" is mostly left in to preserve consistency with the current Baseline Requirements. Ben Wilson of DigiCert made the following motion, from and from have endorsed it. Motion Begins Be it resolved that the CA / Browser Forum adopts the attached CA/B Forum Certificate Policy v.1.2.5, effective immediately. Motion Ends The review period for this ballot shall commence at 2200 UTC on March 2015 and will close at 2200 UTC on March 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on March 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the ballot must indicate a clear 'yes' in the response. A vote against the ballot must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/. In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and more than one half of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or by abstaining for the vote to be valid. 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
-------------- next part -------------- An HTML attachment was scrubbed... URL: From Dean_Coclin at symantec.com Tue Feb 24 16:59:05 2015 From: Dean_Coclin at symantec.com (Dean Coclin) Date: Tue, 24 Feb 2015 08:59:05 -0800 Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework In-Reply-To: References: <4214ab2ac59143c3a726ad7419792a45@EX2.corp.digicert.com> Message-ID: <14D026C7F297AD44AC82578DD818CDD038EF4A93E9@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> Some of the beneficiaries are Browser root programs and relying parties. Having the BRs in this format makes it easier for Jody, Kathleen and others to review CPS? and compare to the sections in the BRs for compliance. Jeremy has already taken a pass at doing this and a draft has been circulated. Dean From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of kirk_hall at trendmicro.com Sent: Tuesday, February 24, 2015 11:52 AM To: Ben Wilson; CABFPub Subject: Re: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Ben ? first of all, thanks for the hard work on this one. I?m trying to figure out the benefit of locking the Forum into the RFC 3647 framework for the purpose of listing BR requirements. Is there really a benefit? Does it add to understanding and make CA compliance any easier? Or will it force us to put rules in odd places that actually make understanding a bit harder? I note the BR 8.2 already requires CAs to put their CPS into the format of RFC 2527 or 3647. See the first two sections of BR 8.2 below. That can facilitate comparison between the CPSs of different CAs, if anyone cares to do that. But is there any corresponding benefit from restructuring the BRs to an RFC 3647 format? What if a rule spans two or more different sections of the RFC 3647 format? I see that in your new organization of the BRs you have moved old BR 8.2.2 to a new Section 2.1 Repositories, not to new Section 2.2 Publication of Information. How did you make that choice? And is there an expectation that CAs will publish their CAA disclosure in new Sec. 2.2 of their CPS? I?m just afraid we will be handcuffing ourselves with these changes, and that there could be errors in internal cross-references. It is also a lot of work for everyone to review a complete rewrite of the BRs. Can you give us a convincing argument of why this is worth doing? Sorry I didn?t ask this question earlier, but I hadn?t really understood this was what the working group was doing ? I thought you were just looking for GAPS in the BRs as compared to the RFC 3647 where we could ADD new provisions to the BRs ? not a wholesale restructuring of the BRs. Thanks. BR 8.2.2 Disclosure The CA SHALL publicly disclose its Certificate Policy and/or Certification Practice Statement through an appropriate and readily accessible online means that is available on a 24x7 basis. The CA SHALL publicly disclose its CA business practices to the extent required by the CA?s selected audit scheme (see Section 17.1). The disclosures MUST include all the material required by RFC 2527 or RFC 3647, and MUST be structured in accordance with either RFC 2527 or RFC 3647. Effective as of 15 April 2015, section 4.2 of a CA's Certificate Policy and/or Certification Practice Statement (section 4.1 for CAs still conforming to RFC 2527) SHALL state whether the CA reviews CAA Records, and if so, the CA?s policy or practice on processing CAA Records for Fully Qualified Domain Names. The CA SHALL log all actions taken, if any, consistent with its processing practice. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ben Wilson Sent: Tuesday, February 24, 2015 7:22 AM To: CABFPub Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework The Certificate Policy Review Working Group was chartered by Ballot 128 to (i) consider existing and proposed standards, (ii) create a list of potential improvements based on the considered standards that improve the existing CAB Forum work product, (iii) evaluate the transition to a 3647 format based on the amount [of work involved]. One deliverable of the CP Review WG was to propose a ballot to improve CA infrastructure based on existing standards and documents and recommend whether to finish the 3647 conversion presented by Jeremy Rowley in January 2014. The CP Review WG has met and concluded that the best path forward for the Forum is to complete a conversion to the RFC 3647 for the Baseline Requirements with an initial step that merely moves existing content from the Baseline Requirements and the Network and Certificate System Security Requirements into the RFC 3647 format. Attached is an RFC-3647-formatted Certificate Policy for Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates. Comments embedded in the document contain either the source of the text (for content copied from the Baseline Requirements) or the current text (for provisions incorporated by reference from the Network and Certificate System Security Requirements ("NetSec"). It was decided that it was better to incorporate the NetSec requirements by reference rather than copying and pasting them in. In some limited instances the phrase "these Requirements" has been replaced with "this CP." However, "these Requirements" is mostly left in to preserve consistency with the current Baseline Requirements. Ben Wilson of DigiCert made the following motion, from and from have endorsed it. Motion Begins Be it resolved that the CA / Browser Forum adopts the attached CA/B Forum Certificate Policy v.1.2.5, effective immediately. Motion Ends The review period for this ballot shall commence at 2200 UTC on March 2015 and will close at 2200 UTC on March 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on March 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the ballot must indicate a clear ?yes? in the response. A vote against the ballot must indicate a clear ?no? in the response. A vote to abstain must indicate a clear ?abstain? in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/. In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and more than one half of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members? at least nine members must participate in the ballot, either by voting in favor, voting against, or by abstaining for the vote to be valid. TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6130 bytes Desc: not available URL: From jodycl at microsoft.com Tue Feb 24 17:24:03 2015 From: jodycl at microsoft.com (Jody Cloutier) Date: Tue, 24 Feb 2015 17:24:03 +0000 Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework In-Reply-To: References: <4214ab2ac59143c3a726ad7419792a45@EX2.corp.digicert.com> Message-ID: I'll endorse. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Tim Hollebeek Sent: Tuesday, February 24, 2015 7:49 AM To: Ben Wilson; CABFPub Subject: Re: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework I'll endorse. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ben Wilson Sent: Tuesday, February 24, 2015 10:22 AM To: CABFPub Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework The Certificate Policy Review Working Group was chartered by Ballot 128 to (i) consider existing and proposed standards, (ii) create a list of potential improvements based on the considered standards that improve the existing CAB Forum work product, (iii) evaluate the transition to a 3647 format based on the amount [of work involved]. One deliverable of the CP Review WG was to propose a ballot to improve CA infrastructure based on existing standards and documents and recommend whether to finish the 3647 conversion presented by Jeremy Rowley in January 2014. The CP Review WG has met and concluded that the best path forward for the Forum is to complete a conversion to the RFC 3647 for the Baseline Requirements with an initial step that merely moves existing content from the Baseline Requirements and the Network and Certificate System Security Requirements into the RFC 3647 format. Attached is an RFC-3647-formatted Certificate Policy for Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates. Comments embedded in the document contain either the source of the text (for content copied from the Baseline Requirements) or the current text (for provisions incorporated by reference from the Network and Certificate System Security Requirements ("NetSec"). It was decided that it was better to incorporate the NetSec requirements by reference rather than copying and pasting them in. In some limited instances the phrase "these Requirements" has been replaced with "this CP." However, "these Requirements" is mostly left in to preserve consistency with the current Baseline Requirements. Ben Wilson of DigiCert made the following motion, from and from have endorsed it. Motion Begins Be it resolved that the CA / Browser Forum adopts the attached CA/B Forum Certificate Policy v.1.2.5, effective immediately. Motion Ends The review period for this ballot shall commence at 2200 UTC on March 2015 and will close at 2200 UTC on March 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on March 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the ballot must indicate a clear 'yes' in the response. A vote against the ballot must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/. In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and more than one half of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or by abstaining for the vote to be valid. ________________________________ This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirk_hall at trendmicro.com Tue Feb 24 17:56:12 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Tue, 24 Feb 2015 17:56:12 +0000 Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework In-Reply-To: <14D026C7F297AD44AC82578DD818CDD038EF4A93E9@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> References: <4214ab2ac59143c3a726ad7419792a45@EX2.corp.digicert.com> <14D026C7F297AD44AC82578DD818CDD038EF4A93E9@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> Message-ID: Fair point, but here is another consideration. Right now, all the WebTrust (and ETSI?) documents are laid out more or less in the same order as the current BRs and EVGL, and include references to the current numbering. If all numbering is changed, they will have to amend the WebTrust (and ETSI?) internal references ? maybe not a big deal ? but the order of the WebTrust requirements will no longer correspond to the order of the BRs. From: Dean Coclin [mailto:Dean_Coclin at symantec.com] Sent: Tuesday, February 24, 2015 8:59 AM To: Kirk Hall (RD-US); Ben Wilson; CABFPub Subject: RE: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Some of the beneficiaries are Browser root programs and relying parties. Having the BRs in this format makes it easier for Jody, Kathleen and others to review CPS? and compare to the sections in the BRs for compliance. Jeremy has already taken a pass at doing this and a draft has been circulated. Dean From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of kirk_hall at trendmicro.com Sent: Tuesday, February 24, 2015 11:52 AM To: Ben Wilson; CABFPub Subject: Re: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Ben ? first of all, thanks for the hard work on this one. I?m trying to figure out the benefit of locking the Forum into the RFC 3647 framework for the purpose of listing BR requirements. Is there really a benefit? Does it add to understanding and make CA compliance any easier? Or will it force us to put rules in odd places that actually make understanding a bit harder? I note the BR 8.2 already requires CAs to put their CPS into the format of RFC 2527 or 3647. See the first two sections of BR 8.2 below. That can facilitate comparison between the CPSs of different CAs, if anyone cares to do that. But is there any corresponding benefit from restructuring the BRs to an RFC 3647 format? What if a rule spans two or more different sections of the RFC 3647 format? I see that in your new organization of the BRs you have moved old BR 8.2.2 to a new Section 2.1 Repositories, not to new Section 2.2 Publication of Information. How did you make that choice? And is there an expectation that CAs will publish their CAA disclosure in new Sec. 2.2 of their CPS? I?m just afraid we will be handcuffing ourselves with these changes, and that there could be errors in internal cross-references. It is also a lot of work for everyone to review a complete rewrite of the BRs. Can you give us a convincing argument of why this is worth doing? Sorry I didn?t ask this question earlier, but I hadn?t really understood this was what the working group was doing ? I thought you were just looking for GAPS in the BRs as compared to the RFC 3647 where we could ADD new provisions to the BRs ? not a wholesale restructuring of the BRs. Thanks. BR 8.2.2 Disclosure The CA SHALL publicly disclose its Certificate Policy and/or Certification Practice Statement through an appropriate and readily accessible online means that is available on a 24x7 basis. The CA SHALL publicly disclose its CA business practices to the extent required by the CA?s selected audit scheme (see Section 17.1). The disclosures MUST include all the material required by RFC 2527 or RFC 3647, and MUST be structured in accordance with either RFC 2527 or RFC 3647. Effective as of 15 April 2015, section 4.2 of a CA's Certificate Policy and/or Certification Practice Statement (section 4.1 for CAs still conforming to RFC 2527) SHALL state whether the CA reviews CAA Records, and if so, the CA?s policy or practice on processing CAA Records for Fully Qualified Domain Names. The CA SHALL log all actions taken, if any, consistent with its processing practice. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ben Wilson Sent: Tuesday, February 24, 2015 7:22 AM To: CABFPub Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework The Certificate Policy Review Working Group was chartered by Ballot 128 to (i) consider existing and proposed standards, (ii) create a list of potential improvements based on the considered standards that improve the existing CAB Forum work product, (iii) evaluate the transition to a 3647 format based on the amount [of work involved]. One deliverable of the CP Review WG was to propose a ballot to improve CA infrastructure based on existing standards and documents and recommend whether to finish the 3647 conversion presented by Jeremy Rowley in January 2014. The CP Review WG has met and concluded that the best path forward for the Forum is to complete a conversion to the RFC 3647 for the Baseline Requirements with an initial step that merely moves existing content from the Baseline Requirements and the Network and Certificate System Security Requirements into the RFC 3647 format. Attached is an RFC-3647-formatted Certificate Policy for Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates. Comments embedded in the document contain either the source of the text (for content copied from the Baseline Requirements) or the current text (for provisions incorporated by reference from the Network and Certificate System Security Requirements ("NetSec"). It was decided that it was better to incorporate the NetSec requirements by reference rather than copying and pasting them in. In some limited instances the phrase "these Requirements" has been replaced with "this CP." However, "these Requirements" is mostly left in to preserve consistency with the current Baseline Requirements. Ben Wilson of DigiCert made the following motion, from and from have endorsed it. Motion Begins Be it resolved that the CA / Browser Forum adopts the attached CA/B Forum Certificate Policy v.1.2.5, effective immediately. Motion Ends The review period for this ballot shall commence at 2200 UTC on March 2015 and will close at 2200 UTC on March 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on March 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the ballot must indicate a clear ?yes? in the response. A vote against the ballot must indicate a clear ?no? in the response. A vote to abstain must indicate a clear ?abstain? in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/. In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and more than one half of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members? at least nine members must participate in the ballot, either by voting in favor, voting against, or by abstaining for the vote to be valid. TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
-------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.wilson at digicert.com Tue Feb 24 18:02:21 2015 From: ben.wilson at digicert.com (Ben Wilson) Date: Tue, 24 Feb 2015 18:02:21 +0000 Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework In-Reply-To: References: <4214ab2ac59143c3a726ad7419792a45@EX2.corp.digicert.com> Message-ID: <2f0cf1bb3e3c488ebf5e700d9629aa91@EX2.corp.digicert.com> That is how the original from Jeremy was introduced with his email dated November 7, 2013, but I assume that it can be moved to section 2.2. From: kirk_hall at trendmicro.com [mailto:kirk_hall at trendmicro.com] Sent: Tuesday, February 24, 2015 9:52 AM To: Ben Wilson; CABFPub Subject: RE: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Ben ? first of all, thanks for the hard work on this one. I?m trying to figure out the benefit of locking the Forum into the RFC 3647 framework for the purpose of listing BR requirements. Is there really a benefit? Does it add to understanding and make CA compliance any easier? Or will it force us to put rules in odd places that actually make understanding a bit harder? I note the BR 8.2 already requires CAs to put their CPS into the format of RFC 2527 or 3647. See the first two sections of BR 8.2 below. That can facilitate comparison between the CPSs of different CAs, if anyone cares to do that. But is there any corresponding benefit from restructuring the BRs to an RFC 3647 format? What if a rule spans two or more different sections of the RFC 3647 format? I see that in your new organization of the BRs you have moved old BR 8.2.2 to a new Section 2.1 Repositories, not to new Section 2.2 Publication of Information. How did you make that choice? And is there an expectation that CAs will publish their CAA disclosure in new Sec. 2.2 of their CPS? I?m just afraid we will be handcuffing ourselves with these changes, and that there could be errors in internal cross-references. It is also a lot of work for everyone to review a complete rewrite of the BRs. Can you give us a convincing argument of why this is worth doing? Sorry I didn?t ask this question earlier, but I hadn?t really understood this was what the working group was doing ? I thought you were just looking for GAPS in the BRs as compared to the RFC 3647 where we could ADD new provisions to the BRs ? not a wholesale restructuring of the BRs. Thanks. BR 8.2.2 Disclosure The CA SHALL publicly disclose its Certificate Policy and/or Certification Practice Statement through an appropriate and readily accessible online means that is available on a 24x7 basis. The CA SHALL publicly disclose its CA business practices to the extent required by the CA?s selected audit scheme (see Section 17.1). The disclosures MUST include all the material required by RFC 2527 or RFC 3647, and MUST be structured in accordance with either RFC 2527 or RFC 3647. Effective as of 15 April 2015, section 4.2 of a CA's Certificate Policy and/or Certification Practice Statement (section 4.1 for CAs still conforming to RFC 2527) SHALL state whether the CA reviews CAA Records, and if so, the CA?s policy or practice on processing CAA Records for Fully Qualified Domain Names. The CA SHALL log all actions taken, if any, consistent with its processing practice. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ben Wilson Sent: Tuesday, February 24, 2015 7:22 AM To: CABFPub Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework The Certificate Policy Review Working Group was chartered by Ballot 128 to (i) consider existing and proposed standards, (ii) create a list of potential improvements based on the considered standards that improve the existing CAB Forum work product, (iii) evaluate the transition to a 3647 format based on the amount [of work involved]. One deliverable of the CP Review WG was to propose a ballot to improve CA infrastructure based on existing standards and documents and recommend whether to finish the 3647 conversion presented by Jeremy Rowley in January 2014. The CP Review WG has met and concluded that the best path forward for the Forum is to complete a conversion to the RFC 3647 for the Baseline Requirements with an initial step that merely moves existing content from the Baseline Requirements and the Network and Certificate System Security Requirements into the RFC 3647 format. Attached is an RFC-3647-formatted Certificate Policy for Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates. Comments embedded in the document contain either the source of the text (for content copied from the Baseline Requirements) or the current text (for provisions incorporated by reference from the Network and Certificate System Security Requirements ("NetSec"). It was decided that it was better to incorporate the NetSec requirements by reference rather than copying and pasting them in. In some limited instances the phrase "these Requirements" has been replaced with "this CP." However, "these Requirements" is mostly left in to preserve consistency with the current Baseline Requirements. Ben Wilson of DigiCert made the following motion, from and from have endorsed it. Motion Begins Be it resolved that the CA / Browser Forum adopts the attached CA/B Forum Certificate Policy v.1.2.5, effective immediately. Motion Ends The review period for this ballot shall commence at 2200 UTC on March 2015 and will close at 2200 UTC on March 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on March 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the ballot must indicate a clear ?yes? in the response. A vote against the ballot must indicate a clear ?no? in the response. A vote to abstain must indicate a clear ?abstain? in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/. In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and more than one half of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members? at least nine members must participate in the ballot, either by voting in favor, voting against, or by abstaining for the vote to be valid. TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4954 bytes Desc: not available URL: From kirk_hall at trendmicro.com Tue Feb 24 18:13:43 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Tue, 24 Feb 2015 18:13:43 +0000 Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework In-Reply-To: <2f0cf1bb3e3c488ebf5e700d9629aa91@EX2.corp.digicert.com> References: <4214ab2ac59143c3a726ad7419792a45@EX2.corp.digicert.com> <2f0cf1bb3e3c488ebf5e700d9629aa91@EX2.corp.digicert.com> Message-ID: Ben ? I was not arguing for any specific change. I was just raising the question of whether trying to fit the BRs into RFC 3647 created its own problems ? like where does a BR section go, and what should be done about a BR section that touches multiple sections of RFC 3647 (do you split up the current BR section, or just choose one place in the RFC 3647 format to put all the BR sections?). One other consideration ? there are many parts of the BRs (and EVGLs) that are not included in or relevant to a CA?s CPS ? they are either requirements, technical standards, or prohibitions, but they don?t have to be declared or included in a CPS. So in that sense, putting the BRs into RFC 3647 does not aid in review or comparison of CPSs across CAs, at least as to those sections? From: Ben Wilson [mailto:ben.wilson at digicert.com] Sent: Tuesday, February 24, 2015 10:02 AM To: Kirk Hall (RD-US); CABFPub Subject: RE: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework That is how the original from Jeremy was introduced with his email dated November 7, 2013, but I assume that it can be moved to section 2.2. From: kirk_hall at trendmicro.com [mailto:kirk_hall at trendmicro.com] Sent: Tuesday, February 24, 2015 9:52 AM To: Ben Wilson; CABFPub Subject: RE: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Ben ? first of all, thanks for the hard work on this one. I?m trying to figure out the benefit of locking the Forum into the RFC 3647 framework for the purpose of listing BR requirements. Is there really a benefit? Does it add to understanding and make CA compliance any easier? Or will it force us to put rules in odd places that actually make understanding a bit harder? I note the BR 8.2 already requires CAs to put their CPS into the format of RFC 2527 or 3647. See the first two sections of BR 8.2 below. That can facilitate comparison between the CPSs of different CAs, if anyone cares to do that. But is there any corresponding benefit from restructuring the BRs to an RFC 3647 format? What if a rule spans two or more different sections of the RFC 3647 format? I see that in your new organization of the BRs you have moved old BR 8.2.2 to a new Section 2.1 Repositories, not to new Section 2.2 Publication of Information. How did you make that choice? And is there an expectation that CAs will publish their CAA disclosure in new Sec. 2.2 of their CPS? I?m just afraid we will be handcuffing ourselves with these changes, and that there could be errors in internal cross-references. It is also a lot of work for everyone to review a complete rewrite of the BRs. Can you give us a convincing argument of why this is worth doing? Sorry I didn?t ask this question earlier, but I hadn?t really understood this was what the working group was doing ? I thought you were just looking for GAPS in the BRs as compared to the RFC 3647 where we could ADD new provisions to the BRs ? not a wholesale restructuring of the BRs. Thanks. BR 8.2.2 Disclosure The CA SHALL publicly disclose its Certificate Policy and/or Certification Practice Statement through an appropriate and readily accessible online means that is available on a 24x7 basis. The CA SHALL publicly disclose its CA business practices to the extent required by the CA?s selected audit scheme (see Section 17.1). The disclosures MUST include all the material required by RFC 2527 or RFC 3647, and MUST be structured in accordance with either RFC 2527 or RFC 3647. Effective as of 15 April 2015, section 4.2 of a CA's Certificate Policy and/or Certification Practice Statement (section 4.1 for CAs still conforming to RFC 2527) SHALL state whether the CA reviews CAA Records, and if so, the CA?s policy or practice on processing CAA Records for Fully Qualified Domain Names. The CA SHALL log all actions taken, if any, consistent with its processing practice. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ben Wilson Sent: Tuesday, February 24, 2015 7:22 AM To: CABFPub Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework The Certificate Policy Review Working Group was chartered by Ballot 128 to (i) consider existing and proposed standards, (ii) create a list of potential improvements based on the considered standards that improve the existing CAB Forum work product, (iii) evaluate the transition to a 3647 format based on the amount [of work involved]. One deliverable of the CP Review WG was to propose a ballot to improve CA infrastructure based on existing standards and documents and recommend whether to finish the 3647 conversion presented by Jeremy Rowley in January 2014. The CP Review WG has met and concluded that the best path forward for the Forum is to complete a conversion to the RFC 3647 for the Baseline Requirements with an initial step that merely moves existing content from the Baseline Requirements and the Network and Certificate System Security Requirements into the RFC 3647 format. Attached is an RFC-3647-formatted Certificate Policy for Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates. Comments embedded in the document contain either the source of the text (for content copied from the Baseline Requirements) or the current text (for provisions incorporated by reference from the Network and Certificate System Security Requirements ("NetSec"). It was decided that it was better to incorporate the NetSec requirements by reference rather than copying and pasting them in. In some limited instances the phrase "these Requirements" has been replaced with "this CP." However, "these Requirements" is mostly left in to preserve consistency with the current Baseline Requirements. Ben Wilson of DigiCert made the following motion, from and from have endorsed it. Motion Begins Be it resolved that the CA / Browser Forum adopts the attached CA/B Forum Certificate Policy v.1.2.5, effective immediately. Motion Ends The review period for this ballot shall commence at 2200 UTC on March 2015 and will close at 2200 UTC on March 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on March 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the ballot must indicate a clear ?yes? in the response. A vote against the ballot must indicate a clear ?no? in the response. A vote to abstain must indicate a clear ?abstain? in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/. In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and more than one half of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members? at least nine members must participate in the ballot, either by voting in favor, voting against, or by abstaining for the vote to be valid. TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
-------------- next part -------------- An HTML attachment was scrubbed... URL: From eddy_nigg at startcom.org Tue Feb 24 18:30:45 2015 From: eddy_nigg at startcom.org (Eddy Nigg) Date: Tue, 24 Feb 2015 20:30:45 +0200 Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework In-Reply-To: References: <4214ab2ac59143c3a726ad7419792a45@EX2.corp.digicert.com> <2f0cf1bb3e3c488ebf5e700d9629aa91@EX2.corp.digicert.com> Message-ID: <54ECC355.6030702@startcom.org> On 02/24/2015 08:13 PM, kirk_hall at trendmicro.com wrote: > One other consideration -- there are many parts of the BRs (and EVGLs) > that are not included in or relevant to a CA's CPS -- they are either > requirements, technical standards, or prohibitions, but they don't > have to be declared or included in a CPS. So in that sense, putting > the BRs into RFC 3647 does not aid in review or comparison of CPSs > across CAs, at least as to those sections... How about the BR in addition to a RFC 3647 structure document stating the relevant BR requirements? Meaning, two documents. -- Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. XMPP: startcom at startcom.org Blog: Join the Revolution! Twitter: Follow Me -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4313 bytes Desc: S/MIME Cryptographic Signature URL: From eddy_nigg at startcom.org Tue Feb 24 18:30:54 2015 From: eddy_nigg at startcom.org (Eddy Nigg) Date: Tue, 24 Feb 2015 20:30:54 +0200 Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework In-Reply-To: References: <4214ab2ac59143c3a726ad7419792a45@EX2.corp.digicert.com> <2f0cf1bb3e3c488ebf5e700d9629aa91@EX2.corp.digicert.com> Message-ID: <54ECC35E.8090405@startcom.org> On 02/24/2015 08:13 PM, kirk_hall at trendmicro.com wrote: > One other consideration -- there are many parts of the BRs (and EVGLs) > that are not included in or relevant to a CA's CPS -- they are either > requirements, technical standards, or prohibitions, but they don't > have to be declared or included in a CPS. So in that sense, putting > the BRs into RFC 3647 does not aid in review or comparison of CPSs > across CAs, at least as to those sections... How about the BR in addition to a RFC 3647 structured document stating the relevant BR requirements? Meaning, two documents. -- Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. XMPP: startcom at startcom.org Blog: Join the Revolution! Twitter: Follow Me -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4313 bytes Desc: S/MIME Cryptographic Signature URL: From ben.wilson at digicert.com Tue Feb 24 19:27:11 2015 From: ben.wilson at digicert.com (Ben Wilson) Date: Tue, 24 Feb 2015 19:27:11 +0000 Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework In-Reply-To: References: <4214ab2ac59143c3a726ad7419792a45@EX2.corp.digicert.com> <2f0cf1bb3e3c488ebf5e700d9629aa91@EX2.corp.digicert.com> Message-ID: <1c377341c18846f8b77a396438e97cf5@EX2.corp.digicert.com> Most of your comment is moot, because the work has already been done. That is why I focused on your comment about whether a particular section belongs in one section or another and responded that it could be moved. I suppose then that you are looking at the document and seeing lots of other items that belong somewhere else? I think Jeremy and I and the CP Review Working Group will be happy to accommodate such requests, but the stage we?re at now does not involve splitting sections up too much, although there are a couple of places where we?ve already done that without much trouble, such as in section 5.3.4. From: kirk_hall at trendmicro.com [mailto:kirk_hall at trendmicro.com] Sent: Tuesday, February 24, 2015 11:14 AM To: Ben Wilson; CABFPub Subject: RE: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Ben ? I was not arguing for any specific change. I was just raising the question of whether trying to fit the BRs into RFC 3647 created its own problems ? like where does a BR section go, and what should be done about a BR section that touches multiple sections of RFC 3647 (do you split up the current BR section, or just choose one place in the RFC 3647 format to put all the BR sections?). One other consideration ? there are many parts of the BRs (and EVGLs) that are not included in or relevant to a CA?s CPS ? they are either requirements, technical standards, or prohibitions, but they don?t have to be declared or included in a CPS. So in that sense, putting the BRs into RFC 3647 does not aid in review or comparison of CPSs across CAs, at least as to those sections? From: Ben Wilson [mailto:ben.wilson at digicert.com] Sent: Tuesday, February 24, 2015 10:02 AM To: Kirk Hall (RD-US); CABFPub Subject: RE: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework That is how the original from Jeremy was introduced with his email dated November 7, 2013, but I assume that it can be moved to section 2.2. From: kirk_hall at trendmicro.com [mailto:kirk_hall at trendmicro.com] Sent: Tuesday, February 24, 2015 9:52 AM To: Ben Wilson; CABFPub Subject: RE: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Ben ? first of all, thanks for the hard work on this one. I?m trying to figure out the benefit of locking the Forum into the RFC 3647 framework for the purpose of listing BR requirements. Is there really a benefit? Does it add to understanding and make CA compliance any easier? Or will it force us to put rules in odd places that actually make understanding a bit harder? I note the BR 8.2 already requires CAs to put their CPS into the format of RFC 2527 or 3647. See the first two sections of BR 8.2 below. That can facilitate comparison between the CPSs of different CAs, if anyone cares to do that. But is there any corresponding benefit from restructuring the BRs to an RFC 3647 format? What if a rule spans two or more different sections of the RFC 3647 format? I see that in your new organization of the BRs you have moved old BR 8.2.2 to a new Section 2.1 Repositories, not to new Section 2.2 Publication of Information. How did you make that choice? And is there an expectation that CAs will publish their CAA disclosure in new Sec. 2.2 of their CPS? I?m just afraid we will be handcuffing ourselves with these changes, and that there could be errors in internal cross-references. It is also a lot of work for everyone to review a complete rewrite of the BRs. Can you give us a convincing argument of why this is worth doing? Sorry I didn?t ask this question earlier, but I hadn?t really understood this was what the working group was doing ? I thought you were just looking for GAPS in the BRs as compared to the RFC 3647 where we could ADD new provisions to the BRs ? not a wholesale restructuring of the BRs. Thanks. BR 8.2.2 Disclosure The CA SHALL publicly disclose its Certificate Policy and/or Certification Practice Statement through an appropriate and readily accessible online means that is available on a 24x7 basis. The CA SHALL publicly disclose its CA business practices to the extent required by the CA?s selected audit scheme (see Section 17.1). The disclosures MUST include all the material required by RFC 2527 or RFC 3647, and MUST be structured in accordance with either RFC 2527 or RFC 3647. Effective as of 15 April 2015, section 4.2 of a CA's Certificate Policy and/or Certification Practice Statement (section 4.1 for CAs still conforming to RFC 2527) SHALL state whether the CA reviews CAA Records, and if so, the CA?s policy or practice on processing CAA Records for Fully Qualified Domain Names. The CA SHALL log all actions taken, if any, consistent with its processing practice. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ben Wilson Sent: Tuesday, February 24, 2015 7:22 AM To: CABFPub Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework The Certificate Policy Review Working Group was chartered by Ballot 128 to (i) consider existing and proposed standards, (ii) create a list of potential improvements based on the considered standards that improve the existing CAB Forum work product, (iii) evaluate the transition to a 3647 format based on the amount [of work involved]. One deliverable of the CP Review WG was to propose a ballot to improve CA infrastructure based on existing standards and documents and recommend whether to finish the 3647 conversion presented by Jeremy Rowley in January 2014. The CP Review WG has met and concluded that the best path forward for the Forum is to complete a conversion to the RFC 3647 for the Baseline Requirements with an initial step that merely moves existing content from the Baseline Requirements and the Network and Certificate System Security Requirements into the RFC 3647 format. Attached is an RFC-3647-formatted Certificate Policy for Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates. Comments embedded in the document contain either the source of the text (for content copied from the Baseline Requirements) or the current text (for provisions incorporated by reference from the Network and Certificate System Security Requirements ("NetSec"). It was decided that it was better to incorporate the NetSec requirements by reference rather than copying and pasting them in. In some limited instances the phrase "these Requirements" has been replaced with "this CP." However, "these Requirements" is mostly left in to preserve consistency with the current Baseline Requirements. Ben Wilson of DigiCert made the following motion, from and from have endorsed it. Motion Begins Be it resolved that the CA / Browser Forum adopts the attached CA/B Forum Certificate Policy v.1.2.5, effective immediately. Motion Ends The review period for this ballot shall commence at 2200 UTC on March 2015 and will close at 2200 UTC on March 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on March 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the ballot must indicate a clear ?yes? in the response. A vote against the ballot must indicate a clear ?no? in the response. A vote to abstain must indicate a clear ?abstain? in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/. In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and more than one half of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members? at least nine members must participate in the ballot, either by voting in favor, voting against, or by abstaining for the vote to be valid. TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4954 bytes Desc: not available URL: From i-barreira at izenpe.net Wed Feb 25 07:54:41 2015 From: i-barreira at izenpe.net (i-barreira at izenpe.net) Date: Wed, 25 Feb 2015 08:54:41 +0100 Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC3647 Framework Message-ID: <763539E260C37C46A0D6B340B5434C3B0AE7EA23@AEX06.ejsarea.net> This is something that I complained time ago basically due to the timing needed to adopt the EN, which is not the same than the TS. BTW, ETSI also mandates that the CP/CPS shall be structured according to the RFC 3647 I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. De: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] En nombre de kirk_hall at trendmicro.com Enviado el: martes, 24 de febrero de 2015 18:56 Para: Dean Coclin; Ben Wilson; CABFPub Asunto: Re: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC3647 Framework Fair point, but here is another consideration. Right now, all the WebTrust (and ETSI?) documents are laid out more or less in the same order as the current BRs and EVGL, and include references to the current numbering. If all numbering is changed, they will have to amend the WebTrust (and ETSI?) internal references ? maybe not a big deal ? but the order of the WebTrust requirements will no longer correspond to the order of the BRs. From: Dean Coclin [mailto:Dean_Coclin at symantec.com] Sent: Tuesday, February 24, 2015 8:59 AM To: Kirk Hall (RD-US); Ben Wilson; CABFPub Subject: RE: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Some of the beneficiaries are Browser root programs and relying parties. Having the BRs in this format makes it easier for Jody, Kathleen and others to review CPS? and compare to the sections in the BRs for compliance. Jeremy has already taken a pass at doing this and a draft has been circulated. Dean From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of kirk_hall at trendmicro.com Sent: Tuesday, February 24, 2015 11:52 AM To: Ben Wilson; CABFPub Subject: Re: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Ben ? first of all, thanks for the hard work on this one. I?m trying to figure out the benefit of locking the Forum into the RFC 3647 framework for the purpose of listing BR requirements. Is there really a benefit? Does it add to understanding and make CA compliance any easier? Or will it force us to put rules in odd places that actually make understanding a bit harder? I note the BR 8.2 already requires CAs to put their CPS into the format of RFC 2527 or 3647. See the first two sections of BR 8.2 below. That can facilitate comparison between the CPSs of different CAs, if anyone cares to do that. But is there any corresponding benefit from restructuring the BRs to an RFC 3647 format? What if a rule spans two or more different sections of the RFC 3647 format? I see that in your new organization of the BRs you have moved old BR 8.2.2 to a new Section 2.1 Repositories, not to new Section 2.2 Publication of Information. How did you make that choice? And is there an expectation that CAs will publish their CAA disclosure in new Sec. 2.2 of their CPS? I?m just afraid we will be handcuffing ourselves with these changes, and that there could be errors in internal cross-references. It is also a lot of work for everyone to review a complete rewrite of the BRs. Can you give us a convincing argument of why this is worth doing? Sorry I didn?t ask this question earlier, but I hadn?t really understood this was what the working group was doing ? I thought you were just looking for GAPS in the BRs as compared to the RFC 3647 where we could ADD new provisions to the BRs ? not a wholesale restructuring of the BRs. Thanks. BR 8.2.2 Disclosure The CA SHALL publicly disclose its Certificate Policy and/or Certification Practice Statement through an appropriate and readily accessible online means that is available on a 24x7 basis. The CA SHALL publicly disclose its CA business practices to the extent required by the CA?s selected audit scheme (see Section 17.1). The disclosures MUST include all the material required by RFC 2527 or RFC 3647, and MUST be structured in accordance with either RFC 2527 or RFC 3647. Effective as of 15 April 2015, section 4.2 of a CA's Certificate Policy and/or Certification Practice Statement (section 4.1 for CAs still conforming to RFC 2527) SHALL state whether the CA reviews CAA Records, and if so, the CA?s policy or practice on processing CAA Records for Fully Qualified Domain Names. The CA SHALL log all actions taken, if any, consistent with its processing practice. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ben Wilson Sent: Tuesday, February 24, 2015 7:22 AM To: CABFPub Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework The Certificate Policy Review Working Group was chartered by Ballot 128 to (i) consider existing and proposed standards, (ii) create a list of potential improvements based on the considered standards that improve the existing CAB Forum work product, (iii) evaluate the transition to a 3647 format based on the amount [of work involved]. One deliverable of the CP Review WG was to propose a ballot to improve CA infrastructure based on existing standards and documents and recommend whether to finish the 3647 conversion presented by Jeremy Rowley in January 2014. The CP Review WG has met and concluded that the best path forward for the Forum is to complete a conversion to the RFC 3647 for the Baseline Requirements with an initial step that merely moves existing content from the Baseline Requirements and the Network and Certificate System Security Requirements into the RFC 3647 format. Attached is an RFC-3647-formatted Certificate Policy for Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates. Comments embedded in the document contain either the source of the text (for content copied from the Baseline Requirements) or the current text (for provisions incorporated by reference from the Network and Certificate System Security Requirements ("NetSec"). It was decided that it was better to incorporate the NetSec requirements by reference rather than copying and pasting them in. In some limited instances the phrase "these Requirements" has been replaced with "this CP." However, "these Requirements" is mostly left in to preserve consistency with the current Baseline Requirements. Ben Wilson of DigiCert made the following motion, from and from have endorsed it. Motion Begins Be it resolved that the CA / Browser Forum adopts the attached CA/B Forum Certificate Policy v.1.2.5, effective immediately. Motion Ends The review period for this ballot shall commence at 2200 UTC on March 2015 and will close at 2200 UTC on March 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on March 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the ballot must indicate a clear ?yes? in the response. A vote against the ballot must indicate a clear ?no? in the response. A vote to abstain must indicate a clear ?abstain? in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ . In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and more than one half of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members? at least nine members must participate in the ballot, either by voting in favor, voting against, or by abstaining for the vote to be valid. TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 19121 bytes Desc: image001.png URL: From ben.wilson at digicert.com Wed Feb 25 16:16:01 2015 From: ben.wilson at digicert.com (Ben Wilson) Date: Wed, 25 Feb 2015 16:16:01 +0000 Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC3647 Framework In-Reply-To: <763539E260C37C46A0D6B340B5434C3B0AE7EA23@AEX06.ejsarea.net> References: <763539E260C37C46A0D6B340B5434C3B0AE7EA23@AEX06.ejsarea.net> Message-ID: <265dc2dc2f67410bb12f97b420b7c4dc@EX2.corp.digicert.com> I?igo, The Working Group did consider your previous comments during its deliberations. We?re willing to help out in whatever way we can with transitioning the necessary cross-references in ETSI documents to the new section numbers. Once this has been accomplished, though, I don?t? think we?ll be doing this kind of moving sections around again. Ben From: i-barreira at izenpe.net [mailto:i-barreira at izenpe.net] Sent: Wednesday, February 25, 2015 12:55 AM To: kirk_hall at trendmicro.com; Dean_Coclin at symantec.com; Ben Wilson; public at cabforum.org Subject: RE: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC3647 Framework This is something that I complained time ago basically due to the timing needed to adopt the EN, which is not the same than the TS. BTW, ETSI also mandates that the CP/CPS shall be structured according to the RFC 3647 I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. De: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] En nombre de kirk_hall at trendmicro.com Enviado el: martes, 24 de febrero de 2015 18:56 Para: Dean Coclin; Ben Wilson; CABFPub Asunto: Re: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC3647 Framework Fair point, but here is another consideration. Right now, all the WebTrust (and ETSI?) documents are laid out more or less in the same order as the current BRs and EVGL, and include references to the current numbering. If all numbering is changed, they will have to amend the WebTrust (and ETSI?) internal references ? maybe not a big deal ? but the order of the WebTrust requirements will no longer correspond to the order of the BRs. From: Dean Coclin [mailto:Dean_Coclin at symantec.com] Sent: Tuesday, February 24, 2015 8:59 AM To: Kirk Hall (RD-US); Ben Wilson; CABFPub Subject: RE: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Some of the beneficiaries are Browser root programs and relying parties. Having the BRs in this format makes it easier for Jody, Kathleen and others to review CPS? and compare to the sections in the BRs for compliance. Jeremy has already taken a pass at doing this and a draft has been circulated. Dean From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of kirk_hall at trendmicro.com Sent: Tuesday, February 24, 2015 11:52 AM To: Ben Wilson; CABFPub Subject: Re: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Ben ? first of all, thanks for the hard work on this one. I?m trying to figure out the benefit of locking the Forum into the RFC 3647 framework for the purpose of listing BR requirements. Is there really a benefit? Does it add to understanding and make CA compliance any easier? Or will it force us to put rules in odd places that actually make understanding a bit harder? I note the BR 8.2 already requires CAs to put their CPS into the format of RFC 2527 or 3647. See the first two sections of BR 8.2 below. That can facilitate comparison between the CPSs of different CAs, if anyone cares to do that. But is there any corresponding benefit from restructuring the BRs to an RFC 3647 format? What if a rule spans two or more different sections of the RFC 3647 format? I see that in your new organization of the BRs you have moved old BR 8.2.2 to a new Section 2.1 Repositories, not to new Section 2.2 Publication of Information. How did you make that choice? And is there an expectation that CAs will publish their CAA disclosure in new Sec. 2.2 of their CPS? I?m just afraid we will be handcuffing ourselves with these changes, and that there could be errors in internal cross-references. It is also a lot of work for everyone to review a complete rewrite of the BRs. Can you give us a convincing argument of why this is worth doing? Sorry I didn?t ask this question earlier, but I hadn?t really understood this was what the working group was doing ? I thought you were just looking for GAPS in the BRs as compared to the RFC 3647 where we could ADD new provisions to the BRs ? not a wholesale restructuring of the BRs. Thanks. BR 8.2.2 Disclosure The CA SHALL publicly disclose its Certificate Policy and/or Certification Practice Statement through an appropriate and readily accessible online means that is available on a 24x7 basis. The CA SHALL publicly disclose its CA business practices to the extent required by the CA?s selected audit scheme (see Section 17.1). The disclosures MUST include all the material required by RFC 2527 or RFC 3647, and MUST be structured in accordance with either RFC 2527 or RFC 3647. Effective as of 15 April 2015, section 4.2 of a CA's Certificate Policy and/or Certification Practice Statement (section 4.1 for CAs still conforming to RFC 2527) SHALL state whether the CA reviews CAA Records, and if so, the CA?s policy or practice on processing CAA Records for Fully Qualified Domain Names. The CA SHALL log all actions taken, if any, consistent with its processing practice. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ben Wilson Sent: Tuesday, February 24, 2015 7:22 AM To: CABFPub Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework The Certificate Policy Review Working Group was chartered by Ballot 128 to (i) consider existing and proposed standards, (ii) create a list of potential improvements based on the considered standards that improve the existing CAB Forum work product, (iii) evaluate the transition to a 3647 format based on the amount [of work involved]. One deliverable of the CP Review WG was to propose a ballot to improve CA infrastructure based on existing standards and documents and recommend whether to finish the 3647 conversion presented by Jeremy Rowley in January 2014. The CP Review WG has met and concluded that the best path forward for the Forum is to complete a conversion to the RFC 3647 for the Baseline Requirements with an initial step that merely moves existing content from the Baseline Requirements and the Network and Certificate System Security Requirements into the RFC 3647 format. Attached is an RFC-3647-formatted Certificate Policy for Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates. Comments embedded in the document contain either the source of the text (for content copied from the Baseline Requirements) or the current text (for provisions incorporated by reference from the Network and Certificate System Security Requirements ("NetSec"). It was decided that it was better to incorporate the NetSec requirements by reference rather than copying and pasting them in. In some limited instances the phrase "these Requirements" has been replaced with "this CP." However, "these Requirements" is mostly left in to preserve consistency with the current Baseline Requirements. Ben Wilson of DigiCert made the following motion, from and from have endorsed it. Motion Begins Be it resolved that the CA / Browser Forum adopts the attached CA/B Forum Certificate Policy v.1.2.5, effective immediately. Motion Ends The review period for this ballot shall commence at 2200 UTC on March 2015 and will close at 2200 UTC on March 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on March 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the ballot must indicate a clear ?yes? in the response. A vote against the ballot must indicate a clear ?no? in the response. A vote to abstain must indicate a clear ?abstain? in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/. In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and more than one half of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members? at least nine members must participate in the ballot, either by voting in favor, voting against, or by abstaining for the vote to be valid. TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 19121 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4954 bytes Desc: not available URL: From ben.wilson at digicert.com Wed Feb 25 16:25:52 2015 From: ben.wilson at digicert.com (Ben Wilson) Date: Wed, 25 Feb 2015 16:25:52 +0000 Subject: [cabfpub] TurkTrust Root Renewal Request In-Reply-To: References: <20150218143046.4087891.82163.380@gmail.com> <20150218220100.4087891.76539.386@gmail.com> <20150219134909.4087891.28047.389@gmail.com> <20150225135154.4087891.14518.423@gmail.com> Message-ID: <3254c639926841ba86a367c16ee4ce51@EX2.corp.digicert.com> One practice that the CA/B Forum should consider is to forward select comments on proposed guidelines from the questions list over to the public list, but because of the IPR Policy concerns that it creates, the practice should include mitigations for third parties (not bound to the IPR Policy) injecting protected IP into the Forum's workstream. However, because I think the risk of that is small, I think it should be allowed as long as CABF members police themselves. -----Original Message----- From: dev-security-policy [mailto:dev-security-policy-bounces+ben=digicert.com at lists.mozilla.org] On Behalf Of Steve Roylance Sent: Wednesday, February 25, 2015 9:10 AM To: Peter Bowen Cc: fhw843 at gmail.com; mozilla-dev-security-policy at lists.mozilla.org; Kathleen Wilson Subject: RE: TurkTrust Root Renewal Request Thanks Peter. Yes my bad.. https://cabforum.org/current-work/code-signing-working-group/ has the questions e-mail at the bottom of the page. Steve > -----Original Message----- > From: dev-security-policy [mailto:dev-security-policy- > bounces+steve.roylance=globalsign.com at lists.mozilla.org] On Behalf Of > bounces+Peter > Bowen > Sent: 26 February 2015 00:00 > To: Steve Roylance > Cc: fhw843 at gmail.com; mozilla-dev-security-policy at lists.mozilla.org; > Kathleen Wilson > Subject: RE: TurkTrust Root Renewal Request > > Steve, > > Unless Peter is a member of the forum, the public list is a black > hole, as only members can post. The alternative, the questions list, > is not publicly readable, so is also a bad choice for open discussion. > > Therefore, while this thread is not the appropriate place, this forum > is probably the best place. > > Thanks, > Peter > On Feb 25, 2015 7:04 AM, "Steve Roylance" > > wrote: > > > Hi Peter. > > > > To better answer the issues you've raised, I'd suggest sending this > > topic to the public list in the CABforum. I'm not in the codesiging working > > group so I'm unable to help directly with answers to your points. I've > > not forwarded this mail as I'd rather that come directly from you. > > Details > > here:- https://cabforum.org/mailman/listinfo/public > > > > Not dodging the bullet, just highlighting a better target ;-) > > > > Steve > > > > > > > -----Original Message----- > > > From: Peter Kurrasch [mailto:fhw843 at gmail.com] > > > Sent: 25 February 2015 21:52 > > > To: Steve Roylance > > > Cc: Kathleen Wilson; mozilla-dev-security-policy at lists.mozilla.org > > > Subject: Re: TurkTrust Root Renewal Request > > > > > > Thanks for putting that together, Steve. Reading through the doc > > > it > > appears that > > > some of my concerns are addressed but I do have a few questions yet: > > > > > > 1) I saw that tucked away in section 10.3.2 item #3 is "key reuse" > > > but > > all it says is > > > "you have to promise not to do it". Is there any solid enforcement > > > for > > this, above > > > and beyond the "we found out about it" clause in section 13.1.5 > > > item > > > #4 > > or #6? > > > > > > 2) Is there a particular reason to not mention the prohibition on > > > key > > reuse in > > > section 9.5? > > > > > > 3) All of the EKU sections in Appendix B have a loophole for > > > companies > > that have > > > some sort of platform specific need to include other CA values, > > > but I > > don't know > > > what those use cases look like. From my standpoint it's more > > > secure for > > everyone > > > to have hard and fast rules for rigorous enforcement of security > > policies. As > > > written, such rigor goes out the window. Do you know of any good > > examples why > > > the loophole is necessary? > > > > > > > > > Bringing this discussion back to TurkTrust's request: > > > > > > 4) When might CABF approve the requirements and when might cert > > > issuers > > be > > > expected to comply? > > > > > > 5) What is reasonable to ask of TurkTrust to spell out in CP/CPS > > documents in > > > conjunction with this current request? I think it's reasonable to > > > ask > > for them to just > > > say what policies they plan to enforce. If they have no plans to > > > impose > > limits on > > > EKU's then just say it--give me a chance as an end user to make an > > informed > > > decision when I come across certs chained to their root. > > > > > > ? > > > > > > -------- Original Message -------- > > > From: Steve Roylance > > > Sent: Saturday, February 21, 2015 2:59 PM ? > > > > > > Hi Peter. > > > > > > I double checked, and everything looks good for the future (Please > > > see > > the > > > attached proposed Code Signing Requirements which has been > > > publically released by the CABForum) > > > > > > Specifically see Appendix B section F which covers MUST > > > requirements for > > CAs > > > and as such alleviates your concerns in that 'Server Auth' is not > > allowed to coexist > > > with code signing so it's not necessary to segregate by Root CA as > > > it's > > going to be > > > mandatory to segregate by issuing CA.. > > > > > > F. extkeyUsage (EKU) > > > The id-kp-codeSigning [RFC5280] value MUST be present. > > > The following EKUs MAY be present: documentSigning and emailProtection. > > > The value anyExtendedKeyUsage (2.5.29.37.0) MUST NOT be present. > > > Other values SHOULD NOT be present. If any other value is present, > > > the CA MUST have a business agreement with a Platform vendor > > > requiring that EKU > > in > > > order to issue a Platform-specific code signing certificate with > > > that > > EKU. > > > This extension SHOULD be marked non-critical. > > > The CA MUST set all other fields and extensions in accordance to > > > RFC > > 5280. > > > > > > Steve > > > > > > > -----Original Message----- > > > > From: Peter Kurrasch [mailto:fhw843 at gmail.com] > > > > Sent: 19 February 2015 13:49 > > > > To: Steve Roylance > > > > Cc: Kathleen Wilson; > > > > mozilla-dev-security-policy at lists.mozilla.org > > > > Subject: Re: TurkTrust Root Renewal Request > > > > > > > > My preference is to have key separation explicitly addressed by > > > > Mozilla and CABForum. From strictly a security perspective > > > > sharing keys is an all risk, no reward ?proposition. The only > > > > advantage I can see is in terms of convenience in different ways. > > > > > > > > I offer the following options for consideration: > > > > > > > > Bare minimum: for any ?root cert which intends to be used for > > > > both SSL and code, the CA shall provide a statement in the > > > > CP/CPS regarding any plans they have to limit end/leaf certs > > > > from having both EKU's. If it's just a policy thing or if an > > > > intermediate will provide a > > technical enforcement > > > mechanism, just write it down. > > > > If there is no plan/policy, just state that too. > > > > > > > > Minimum: enact a policy to disallow both EKU's from being used > > > > in a single end- entity cert. > > > > > > > > Better: separate intermediates are utilized for SSL and code. > > > > > > > > Ideal: separate roots for both SSL and code. > > > > > > > > The reason I favor something more than just policy statements > > > > are because people can make mistakes and should that happen it > > > > would be good to have the technical backstop. > > > > > > > > > > > > Kathleen--Would you feel comfortable asking TurkTrust to provide > > > > a statement clarifying their plans or intentions ?regarding these EKU's? > > > > > > > > Original Message > > > > From: Steve Roylance > > > > Sent: Wednesday, February 18, 2015 4:36 PM > > > > To: Peter Kurrasch > > > > Cc: Kathleen Wilson; > > > > mozilla-dev-security-policy at lists.mozilla.org > > > > Subject: Re: TurkTrust Root Renewal Request > > > > > > > > > > > > > On 18 Feb 2015, at 22:01, Peter Kurrasch wrote: > > > > > > > > > > ?Thanks for the update, Steve. Is there a requirement (current > > > > > or > > > > > forthcoming) for > > > > the CA to document how such segregation will be performed--or > > > > that there even is a plan to perform it? I didn't see any such > > > > language in the CP or CPS provided by TurkTrust so I don't know > > > > what they plan to > > do. > > > > > > > > > > > > > I don't know of any formal plans by CABForum to stipulate segregation. > > > > AFAIK it just happens naturally. Maybe if people feel strongly > > > > that can be looked at through enforced EKU usage in > > > > intermediates, however that sort of change would take far longer > > > > to enact due to the validity of intermediates being approx 10 > > > > years and the fact it's another > > slight against > > > RFC5280. > > > > > > > > > The risk I have in mind is when a server gets compromised thus > > > > > exposing the private keys. If the keys can be used to sign > > > > > objects I can then ?turn around and use them to sign malware and so forth. > > > > > What could be just a minor breach then becomes a bigger problem. > > > > > (I think we should assume that server compromises are a "regular" > > > > > occurrence even though we might not know how many or how often > > > > > or how serious they are.) > > > > > > > > > > > > > Here we are are all OK, as you are taking about end > > > > entities/leaf certificates and they always have the relevant EKU > > > > added by the CA so I don't see this as an issue. > > > > > > > > > I would argue that the best strategy is to have forced > > > > > separation at the root level, > > > > but I can appreciate that there are limits on the number of > > > > roots that ?CAs are allowed to submit. > > > > > > > > > > > > > > > Original Message > > > > > From: Steve Roylance > > > > > Sent: Wednesday, February 18, 2015 9:18 AM > > > > > To: Peter Kurrasch > > > > > Cc: Kathleen Wilson; > > > > > mozilla-dev-security-policy at lists.mozilla.org > > > > > Subject: RE: TurkTrust Root Renewal Request > > > > > > > > > > Hi Peter, > > > > > > > > > > In general this would be true if issuance of either or both > > > > > types of end entity > > > > certificate were directly from the same Root, however CA's, as > > > > best practice and from a product line perspective, segregate the > > > > usage of any end entity certificate types through an > > > > intermediate CA. In fact this is now mandated by the Baseline > > > > Requirements for SSL and forthcoming CodeSIgning requirements. > > > > Whilst any intermediate CA may or may not necessarily have EKUs > > > > which provide further protection, the additional hierarchical > > > > layer and key materials used offer the > > necessary > > > protection overall. > > > > > > > > > > The other reason is that Root Stores generally place a limit > > > > > on the number of > > > > Roots which can be entered so CA's need to be able to maximize > > > > their usage, especially where we are today with ongoing > > > > transitions in cryptography standards and key sizes. > > > > > > > > > > I hope that helps. > > > > > > > > > > Steve > > > > > > > > > >> -----Original Message----- > > > > >> From: dev-security-policy [mailto:dev-security-policy- > > > > >> bounces+steve.roylance=globalsign.com at lists.mozilla.org] On > > > > >> bounces+Behalf Of Peter > > > > >> Kurrasch > > > > >> Sent: 18 February 2015 14:31 > > > > >> To: Kathleen Wilson; > > > > >> mozilla-dev-security-policy at lists.mozilla.org > > > > >> Subject: Re: TurkTrust Root Renewal Request > > > > >> > > > > >> ?Allowing a single cert to be used for both websites and code > > > > >> signing is a dangerous proposition. What is the current > > > > >> thinking among the > > > > community? > > > > >> > > > > >> > > > > >> Original Message > > > > >> From: Kathleen Wilson > > > > >> Sent: Thursday, February 12, 2015 12:31 PM > > > > >> To: mozilla-dev-security-policy at lists.mozilla.org > > > > >> Subject: TurkTrust Root Renewal Request > > > > >> > > > > >> TurkTrust has applied to include the SHA-256 "T?RKTRUST > > > > >> Elektronik Sertifika Hizmet Sa?lay?c?s? H5" and "T?RKTRUST > > > > >> Elektronik Sertifika Hizmet Sa?lay?c?s? H6" root > > > > >> certificates; turn on the Websites trust bit for both roots, > > > > >> turn on the Code Signing trust bit for the H5 root, and > > > > >> enable > > > > EV treatment for the H6 root. > > > > >> TurkTrust's SHA-1 root certificates were included in NSS via > > > > >> Bugzilla Bug > > > > >> #380635 and Bug #433845. > > > > >> > > > > >> ? > > > > >> _______________________________________________ > > > > >> dev-security-policy mailing list > > > > >> dev-security-policy at lists.mozilla.org > > > > >> https://lists.mozilla.org/listinfo/dev-security-policy > > > > _______________________________________________ > > dev-security-policy mailing list > > dev-security-policy at lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-security-policy > > > > > _______________________________________________ > dev-security-policy mailing list > dev-security-policy at lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4954 bytes Desc: not available URL: From i-barreira at izenpe.net Wed Feb 25 16:30:56 2015 From: i-barreira at izenpe.net (=?UTF-8?B?IkJhcnJlaXJhIElnbGVzaWFzLCBJw7FpZ28i?=) Date: Wed, 25 Feb 2015 17:30:56 +0100 Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline RequirementstoRFC3647 Framework Message-ID: <14g8suajpk83brdupqug404t.1424881854376@email.android.com> Yes, i know. ?I've been working on it :-) My concern is when i had to update the EN and the time we can have to do it. OTOH, in ETSI we're also thinking on the same idea Enviado de Samsung Mobile -------- Mensaje original -------- De: Ben Wilson Fecha: Para: i-barreira at izenpe.net,kirk_hall at trendmicro.com,Dean_Coclin at symantec.com,public at cabforum.org Asunto: RE: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements toRFC3647 Framework I?igo, The Working Group did consider your previous comments during its deliberations.? We?re willing to help out in whatever way we can with transitioning the necessary cross-references in ETSI documents to the new section numbers.? Once this has been accomplished, though, I don?t? think we?ll be doing this kind of moving sections around again.? Ben ? From: i-barreira at izenpe.net [mailto:i-barreira at izenpe.net] Sent: Wednesday, February 25, 2015 12:55 AM To: kirk_hall at trendmicro.com; Dean_Coclin at symantec.com; Ben Wilson; public at cabforum.org Subject: RE: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC3647 Framework ? This is something that I complained time ago basically due to the timing needed to adopt the EN, which is not the same than the TS. BTW, ETSI also mandates that the CP/CPS shall be structured according to the RFC 3647 ? ? I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 ? ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. ? De: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] En nombre de kirk_hall at trendmicro.com Enviado el: martes, 24 de febrero de 2015 18:56 Para: Dean Coclin; Ben Wilson; CABFPub Asunto: Re: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC3647 Framework ? Fair point, but here is another consideration. ?Right now, all the WebTrust (and ETSI?) documents are laid out more or less in the same order as the current BRs and EVGL, and include references to the current numbering.? If all numbering is changed, they will have to amend the WebTrust (and ETSI?) internal references ? maybe not a big deal ? but the order of the WebTrust requirements will no longer correspond to the order of the BRs. ? From: Dean Coclin [mailto:Dean_Coclin at symantec.com] Sent: Tuesday, February 24, 2015 8:59 AM To: Kirk Hall (RD-US); Ben Wilson; CABFPub Subject: RE: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework ? Some of the beneficiaries are Browser root programs and relying parties. Having the BRs in this format makes it easier for Jody, Kathleen and others to review CPS? and compare to the sections in the BRs for compliance. ? ? Jeremy has already taken a pass at doing this and a draft has been circulated. ? Dean ? From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of kirk_hall at trendmicro.com Sent: Tuesday, February 24, 2015 11:52 AM To: Ben Wilson; CABFPub Subject: Re: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework ? Ben ? first of all, thanks for the hard work on this one. ? I?m trying to figure out the benefit of locking the Forum into the RFC 3647 framework for the purpose of listing BR requirements.? Is there really a benefit?? Does it add to understanding and make CA compliance any easier?? Or will it force us to put rules in odd places that actually make understanding a bit harder? ? I note the BR 8.2 already requires CAs to put their CPS into the format of RFC 2527 or 3647.? See the first two sections of BR 8.2 below.? That can facilitate comparison between the CPSs of different CAs, if anyone cares to do that.? But is there any corresponding benefit from restructuring the BRs to an RFC 3647 format?? What if a rule spans two or more different sections of the RFC 3647 format? ? I see that in your new organization of the BRs you have moved old BR 8.2.2 to a new Section 2.1 Repositories, not to new Section 2.2 Publication of Information.? How did you make that choice?? And is there an expectation that CAs will publish their CAA disclosure in new Sec. 2.2 of their CPS? ? I?m just afraid we will be handcuffing ourselves with these changes, and that there could be errors in internal cross-references.? It is also a lot of work for everyone to review a complete rewrite of the BRs. ? Can you give us a convincing argument of why this is worth doing?? Sorry I didn?t ask this question earlier, but I hadn?t really understood this was what the working group was doing ? I thought you were just looking for GAPS in the BRs as compared to the RFC 3647 where we could ADD new provisions to the BRs ? not a wholesale restructuring of the BRs. ? Thanks. ? BR 8.2.2 Disclosure The CA SHALL publicly disclose its Certificate Policy and/or Certification Practice Statement through an appropriate and readily accessible online means that is available on a 24x7 basis. The CA SHALL publicly disclose its CA business practices to the extent required by the CA?s selected audit scheme (see Section 17.1). The disclosures MUST include all the material required by RFC 2527 or RFC 3647, and MUST be structured in accordance with either RFC 2527 or RFC 3647. Effective as of 15 April 2015, section 4.2 of a CA's Certificate Policy and/or Certification Practice Statement (section 4.1 for CAs still conforming to RFC 2527) SHALL state whether the CA reviews CAA Records, and if so, the CA?s policy or practice on processing CAA Records for Fully Qualified Domain Names. The CA SHALL log all actions taken, if any, consistent with its processing practice. ? From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ben Wilson Sent: Tuesday, February 24, 2015 7:22 AM To: CABFPub Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework ? Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework The Certificate Policy Review Working Group was chartered by Ballot 128 to (i) consider existing and proposed standards, (ii) create a list of potential improvements based on the considered standards that improve the existing CAB Forum work product, (iii) evaluate the transition to a 3647 format based on the amount [of work involved]. One deliverable of the CP Review WG was to propose a ballot to improve CA infrastructure based on existing standards and documents and recommend whether to finish the 3647 conversion presented by Jeremy Rowley in January 2014. The CP Review WG has met and concluded that the best path forward for the Forum is to complete a conversion to the RFC 3647 for the Baseline Requirements with an initial step that merely moves existing content from the Baseline Requirements and the Network and Certificate System Security Requirements into the RFC 3647 format. Attached is an RFC-3647-formatted Certificate Policy for Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates. Comments embedded in the document contain either the source of the text (for content copied from the Baseline Requirements) or the current text (for provisions incorporated by reference from the Network and Certificate System Security Requirements ("NetSec"). It was decided that it was better to incorporate the NetSec requirements by reference rather than copying and pasting them in. In some limited instances the phrase "these Requirements" has been replaced with "this CP." However, "these Requirements" is mostly left in to preserve consistency with the current Baseline Requirements. Ben Wilson of DigiCert made the following motion, from and from have endorsed it. Motion Begins Be it resolved that the CA / Browser Forum adopts the attached CA/B Forum Certificate Policy v.1.2.5, effective immediately. Motion Ends The review period for this ballot shall commence at 2200 UTC on March 2015 and will close at 2200 UTC on March 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on March 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the ballot must indicate a clear ?yes? in the response. A vote against the ballot must indicate a clear ?no? in the response. A vote to abstain must indicate a clear ?abstain? in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/. In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and more than one half of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members? at least nine members must participate in the ballot, either by voting in favor, voting against, or by abstaining for the vote to be valid. ? ? TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. ? ? TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirk_hall at trendmicro.com Wed Feb 25 17:51:49 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Wed, 25 Feb 2015 17:51:49 +0000 Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC3647 Framework In-Reply-To: <265dc2dc2f67410bb12f97b420b7c4dc@EX2.corp.digicert.com> References: <763539E260C37C46A0D6B340B5434C3B0AE7EA23@AEX06.ejsarea.net> <265dc2dc2f67410bb12f97b420b7c4dc@EX2.corp.digicert.com> Message-ID: Ben, out of curiosity ? did the Working Group consider simply making cross reference tables correlating the current BRs (and EVGL) and the RFC 3647 CPS framework? So that if a browser wanted to see which BR sections were relevant to a CPS in RFC 3647 format (and vice versa), they could just consult the table? It seems that would have been a simpler approach, and would recognize that a lot of the BRs are not relevant to a CA?s CPS or CPS format. From: Ben Wilson [mailto:ben.wilson at digicert.com] Sent: Wednesday, February 25, 2015 8:16 AM To: i-barreira at izenpe.net; Kirk Hall (RD-US); Dean_Coclin at symantec.com; public at cabforum.org Subject: RE: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC3647 Framework I?igo, The Working Group did consider your previous comments during its deliberations. We?re willing to help out in whatever way we can with transitioning the necessary cross-references in ETSI documents to the new section numbers. Once this has been accomplished, though, I don?t? think we?ll be doing this kind of moving sections around again. Ben From: i-barreira at izenpe.net [mailto:i-barreira at izenpe.net] Sent: Wednesday, February 25, 2015 12:55 AM To: kirk_hall at trendmicro.com; Dean_Coclin at symantec.com; Ben Wilson; public at cabforum.org Subject: RE: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC3647 Framework This is something that I complained time ago basically due to the timing needed to adopt the EN, which is not the same than the TS. BTW, ETSI also mandates that the CP/CPS shall be structured according to the RFC 3647 I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 [Descripci?n: cid:image001.png at 01CE3152.B4804EB0] ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. De: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] En nombre de kirk_hall at trendmicro.com Enviado el: martes, 24 de febrero de 2015 18:56 Para: Dean Coclin; Ben Wilson; CABFPub Asunto: Re: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC3647 Framework Fair point, but here is another consideration. Right now, all the WebTrust (and ETSI?) documents are laid out more or less in the same order as the current BRs and EVGL, and include references to the current numbering. If all numbering is changed, they will have to amend the WebTrust (and ETSI?) internal references ? maybe not a big deal ? but the order of the WebTrust requirements will no longer correspond to the order of the BRs. From: Dean Coclin [mailto:Dean_Coclin at symantec.com] Sent: Tuesday, February 24, 2015 8:59 AM To: Kirk Hall (RD-US); Ben Wilson; CABFPub Subject: RE: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Some of the beneficiaries are Browser root programs and relying parties. Having the BRs in this format makes it easier for Jody, Kathleen and others to review CPS? and compare to the sections in the BRs for compliance. Jeremy has already taken a pass at doing this and a draft has been circulated. Dean From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of kirk_hall at trendmicro.com Sent: Tuesday, February 24, 2015 11:52 AM To: Ben Wilson; CABFPub Subject: Re: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Ben ? first of all, thanks for the hard work on this one. I?m trying to figure out the benefit of locking the Forum into the RFC 3647 framework for the purpose of listing BR requirements. Is there really a benefit? Does it add to understanding and make CA compliance any easier? Or will it force us to put rules in odd places that actually make understanding a bit harder? I note the BR 8.2 already requires CAs to put their CPS into the format of RFC 2527 or 3647. See the first two sections of BR 8.2 below. That can facilitate comparison between the CPSs of different CAs, if anyone cares to do that. But is there any corresponding benefit from restructuring the BRs to an RFC 3647 format? What if a rule spans two or more different sections of the RFC 3647 format? I see that in your new organization of the BRs you have moved old BR 8.2.2 to a new Section 2.1 Repositories, not to new Section 2.2 Publication of Information. How did you make that choice? And is there an expectation that CAs will publish their CAA disclosure in new Sec. 2.2 of their CPS? I?m just afraid we will be handcuffing ourselves with these changes, and that there could be errors in internal cross-references. It is also a lot of work for everyone to review a complete rewrite of the BRs. Can you give us a convincing argument of why this is worth doing? Sorry I didn?t ask this question earlier, but I hadn?t really understood this was what the working group was doing ? I thought you were just looking for GAPS in the BRs as compared to the RFC 3647 where we could ADD new provisions to the BRs ? not a wholesale restructuring of the BRs. Thanks. BR 8.2.2 Disclosure The CA SHALL publicly disclose its Certificate Policy and/or Certification Practice Statement through an appropriate and readily accessible online means that is available on a 24x7 basis. The CA SHALL publicly disclose its CA business practices to the extent required by the CA?s selected audit scheme (see Section 17.1). The disclosures MUST include all the material required by RFC 2527 or RFC 3647, and MUST be structured in accordance with either RFC 2527 or RFC 3647. Effective as of 15 April 2015, section 4.2 of a CA's Certificate Policy and/or Certification Practice Statement (section 4.1 for CAs still conforming to RFC 2527) SHALL state whether the CA reviews CAA Records, and if so, the CA?s policy or practice on processing CAA Records for Fully Qualified Domain Names. The CA SHALL log all actions taken, if any, consistent with its processing practice. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ben Wilson Sent: Tuesday, February 24, 2015 7:22 AM To: CABFPub Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework The Certificate Policy Review Working Group was chartered by Ballot 128 to (i) consider existing and proposed standards, (ii) create a list of potential improvements based on the considered standards that improve the existing CAB Forum work product, (iii) evaluate the transition to a 3647 format based on the amount [of work involved]. One deliverable of the CP Review WG was to propose a ballot to improve CA infrastructure based on existing standards and documents and recommend whether to finish the 3647 conversion presented by Jeremy Rowley in January 2014. The CP Review WG has met and concluded that the best path forward for the Forum is to complete a conversion to the RFC 3647 for the Baseline Requirements with an initial step that merely moves existing content from the Baseline Requirements and the Network and Certificate System Security Requirements into the RFC 3647 format. Attached is an RFC-3647-formatted Certificate Policy for Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates. Comments embedded in the document contain either the source of the text (for content copied from the Baseline Requirements) or the current text (for provisions incorporated by reference from the Network and Certificate System Security Requirements ("NetSec"). It was decided that it was better to incorporate the NetSec requirements by reference rather than copying and pasting them in. In some limited instances the phrase "these Requirements" has been replaced with "this CP." However, "these Requirements" is mostly left in to preserve consistency with the current Baseline Requirements. Ben Wilson of DigiCert made the following motion, from and from have endorsed it. Motion Begins Be it resolved that the CA / Browser Forum adopts the attached CA/B Forum Certificate Policy v.1.2.5, effective immediately. Motion Ends The review period for this ballot shall commence at 2200 UTC on March 2015 and will close at 2200 UTC on March 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on March 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the ballot must indicate a clear ?yes? in the response. A vote against the ballot must indicate a clear ?no? in the response. A vote to abstain must indicate a clear ?abstain? in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/. In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and more than one half of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members? at least nine members must participate in the ballot, either by voting in favor, voting against, or by abstaining for the vote to be valid. TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
-------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 19121 bytes Desc: image001.png URL: From dosheehy at deloitte.ca Wed Feb 25 18:07:13 2015 From: dosheehy at deloitte.ca (Sheehy, Don (CA - Toronto)) Date: Wed, 25 Feb 2015 18:07:13 +0000 Subject: [cabfpub] When did the WebTrust/ETSI BR audit requirement become mandatory? In-Reply-To: <54E7AF26.8000706@startcom.org> References: <54E7A2AE.2040501@startcom.org> <54E7AF26.8000706@startcom.org> Message-ID: If one remembers the discussion that we had at the face to face and others , one would remember that there are CAs that are NOT public and NOT part of the trusted root programs that do not require the additional baseline audit. Given that, a merger into one set of standards is unlikely in the near future ( unless we decide to create WebTrust Pubic and non-public versions ? but that is unlikely). So at present you need to meet WebTrust and WebTrust BR + WebTrust EV ( If applicable). If your reporting year starts after last June 30 you will also need to meet the Network Security requirements. Don Donald E. Sheehy, CPA, CA, CISA, CRISC, CIPP/C, CITP Partner | Enterprise Risk Deloitte From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Eddy Nigg Sent: Friday, February 20, 2015 5:03 PM To: kirk_hall at trendmicro.com; i-barreira; Peter Bowen; public at cabforum.org Subject: Re: [cabfpub] When did the WebTrust/ETSI BR audit requirement become mandatory? On 02/20/2015 11:45 PM, kirk_hall at trendmicro.com wrote: When you say ?why? ? do you mean ?is regular WebTrust still required?? (it is, along with BR WebTrust), or are you suggesting that regular WebTrust should no longer be a requirement, just BR WebTrust? I certainly would expect that this will become one (basic) audit eventually (and EV and others optional). -- Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. XMPP: startcom at startcom.org Blog: Join the Revolution! Twitter: Follow Me Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s), are confidential, and may be privileged. If you are not the intended recipient, you are hereby notified that any review, retransmission, conversion to hard copy, copying, circulation or other use of this message and any attachments is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, and delete this message and any attachments from your system. Thank You If you do not wish to receive future commercial electronic messages from Deloitte, forward this email to unsubscribe at deloitte.ca Avertissement de confidentialit?: Ce message, ainsi que toutes ses pi?ces jointes, est destin? exclusivement au(x) destinataire(s) pr?vu(s), est confidentiel et peut contenir des renseignements privil?gi?s. Si vous n??tes pas le destinataire pr?vu de ce message, nous vous avisons par la pr?sente que la modification, la retransmission, la conversion en format papier, la reproduction, la diffusion ou toute autre utilisation de ce message et de ses pi?ces jointes sont strictement interdites. Si vous n??tes pas le destinataire pr?vu, veuillez en aviser imm?diatement l?exp?diteur en r?pondant ? ce courriel et supprimez ce message et toutes ses pi?ces jointes de votre syst?me. Merci. Si vous ne voulez pas recevoir d?autres messages ?lectroniques commerciaux de Deloitte ? l?avenir, veuillez envoyer ce courriel ? l?adresse unsubscribe at deloitte.ca -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.wilson at digicert.com Wed Feb 25 18:18:37 2015 From: ben.wilson at digicert.com (Ben Wilson) Date: Wed, 25 Feb 2015 18:18:37 +0000 Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC3647 Framework In-Reply-To: References: <763539E260C37C46A0D6B340B5434C3B0AE7EA23@AEX06.ejsarea.net> <265dc2dc2f67410bb12f97b420b7c4dc@EX2.corp.digicert.com> Message-ID: <19c62260d34c43c1bd93a1231808ed2d@EX2.corp.digicert.com> Yes ? and those charts were distributed. From: kirk_hall at trendmicro.com [mailto:kirk_hall at trendmicro.com] Sent: Wednesday, February 25, 2015 10:52 AM To: Ben Wilson; i-barreira at izenpe.net; Dean_Coclin at symantec.com; public at cabforum.org Subject: RE: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC3647 Framework Ben, out of curiosity ? did the Working Group consider simply making cross reference tables correlating the current BRs (and EVGL) and the RFC 3647 CPS framework? So that if a browser wanted to see which BR sections were relevant to a CPS in RFC 3647 format (and vice versa), they could just consult the table? It seems that would have been a simpler approach, and would recognize that a lot of the BRs are not relevant to a CA?s CPS or CPS format. From: Ben Wilson [mailto:ben.wilson at digicert.com] Sent: Wednesday, February 25, 2015 8:16 AM To: i-barreira at izenpe.net ; Kirk Hall (RD-US); Dean_Coclin at symantec.com ; public at cabforum.org Subject: RE: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC3647 Framework I?igo, The Working Group did consider your previous comments during its deliberations. We?re willing to help out in whatever way we can with transitioning the necessary cross-references in ETSI documents to the new section numbers. Once this has been accomplished, though, I don?t? think we?ll be doing this kind of moving sections around again. Ben From: i-barreira at izenpe.net [mailto:i-barreira at izenpe.net] Sent: Wednesday, February 25, 2015 12:55 AM To: kirk_hall at trendmicro.com ; Dean_Coclin at symantec.com ; Ben Wilson; public at cabforum.org Subject: RE: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC3647 Framework This is something that I complained time ago basically due to the timing needed to adopt the EN, which is not the same than the TS. BTW, ETSI also mandates that the CP/CPS shall be structured according to the RFC 3647 I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. De: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] En nombre de kirk_hall at trendmicro.com Enviado el: martes, 24 de febrero de 2015 18:56 Para: Dean Coclin; Ben Wilson; CABFPub Asunto: Re: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC3647 Framework Fair point, but here is another consideration. Right now, all the WebTrust (and ETSI?) documents are laid out more or less in the same order as the current BRs and EVGL, and include references to the current numbering. If all numbering is changed, they will have to amend the WebTrust (and ETSI?) internal references ? maybe not a big deal ? but the order of the WebTrust requirements will no longer correspond to the order of the BRs. From: Dean Coclin [mailto:Dean_Coclin at symantec.com] Sent: Tuesday, February 24, 2015 8:59 AM To: Kirk Hall (RD-US); Ben Wilson; CABFPub Subject: RE: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Some of the beneficiaries are Browser root programs and relying parties. Having the BRs in this format makes it easier for Jody, Kathleen and others to review CPS? and compare to the sections in the BRs for compliance. Jeremy has already taken a pass at doing this and a draft has been circulated. Dean From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of kirk_hall at trendmicro.com Sent: Tuesday, February 24, 2015 11:52 AM To: Ben Wilson; CABFPub Subject: Re: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Ben ? first of all, thanks for the hard work on this one. I?m trying to figure out the benefit of locking the Forum into the RFC 3647 framework for the purpose of listing BR requirements. Is there really a benefit? Does it add to understanding and make CA compliance any easier? Or will it force us to put rules in odd places that actually make understanding a bit harder? I note the BR 8.2 already requires CAs to put their CPS into the format of RFC 2527 or 3647. See the first two sections of BR 8.2 below. That can facilitate comparison between the CPSs of different CAs, if anyone cares to do that. But is there any corresponding benefit from restructuring the BRs to an RFC 3647 format? What if a rule spans two or more different sections of the RFC 3647 format? I see that in your new organization of the BRs you have moved old BR 8.2.2 to a new Section 2.1 Repositories, not to new Section 2.2 Publication of Information. How did you make that choice? And is there an expectation that CAs will publish their CAA disclosure in new Sec. 2.2 of their CPS? I?m just afraid we will be handcuffing ourselves with these changes, and that there could be errors in internal cross-references. It is also a lot of work for everyone to review a complete rewrite of the BRs. Can you give us a convincing argument of why this is worth doing? Sorry I didn?t ask this question earlier, but I hadn?t really understood this was what the working group was doing ? I thought you were just looking for GAPS in the BRs as compared to the RFC 3647 where we could ADD new provisions to the BRs ? not a wholesale restructuring of the BRs. Thanks. BR 8.2.2 Disclosure The CA SHALL publicly disclose its Certificate Policy and/or Certification Practice Statement through an appropriate and readily accessible online means that is available on a 24x7 basis. The CA SHALL publicly disclose its CA business practices to the extent required by the CA?s selected audit scheme (see Section 17.1). The disclosures MUST include all the material required by RFC 2527 or RFC 3647, and MUST be structured in accordance with either RFC 2527 or RFC 3647. Effective as of 15 April 2015, section 4.2 of a CA's Certificate Policy and/or Certification Practice Statement (section 4.1 for CAs still conforming to RFC 2527) SHALL state whether the CA reviews CAA Records, and if so, the CA?s policy or practice on processing CAA Records for Fully Qualified Domain Names. The CA SHALL log all actions taken, if any, consistent with its processing practice. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ben Wilson Sent: Tuesday, February 24, 2015 7:22 AM To: CABFPub Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework The Certificate Policy Review Working Group was chartered by Ballot 128 to (i) consider existing and proposed standards, (ii) create a list of potential improvements based on the considered standards that improve the existing CAB Forum work product, (iii) evaluate the transition to a 3647 format based on the amount [of work involved]. One deliverable of the CP Review WG was to propose a ballot to improve CA infrastructure based on existing standards and documents and recommend whether to finish the 3647 conversion presented by Jeremy Rowley in January 2014. The CP Review WG has met and concluded that the best path forward for the Forum is to complete a conversion to the RFC 3647 for the Baseline Requirements with an initial step that merely moves existing content from the Baseline Requirements and the Network and Certificate System Security Requirements into the RFC 3647 format. Attached is an RFC-3647-formatted Certificate Policy for Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates. Comments embedded in the document contain either the source of the text (for content copied from the Baseline Requirements) or the current text (for provisions incorporated by reference from the Network and Certificate System Security Requirements ("NetSec"). It was decided that it was better to incorporate the NetSec requirements by reference rather than copying and pasting them in. In some limited instances the phrase "these Requirements" has been replaced with "this CP." However, "these Requirements" is mostly left in to preserve consistency with the current Baseline Requirements. Ben Wilson of DigiCert made the following motion, from and from have endorsed it. Motion Begins Be it resolved that the CA / Browser Forum adopts the attached CA/B Forum Certificate Policy v.1.2.5, effective immediately. Motion Ends The review period for this ballot shall commence at 2200 UTC on March 2015 and will close at 2200 UTC on March 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on March 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the ballot must indicate a clear ?yes? in the response. A vote against the ballot must indicate a clear ?no? in the response. A vote to abstain must indicate a clear ?abstain? in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/. In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and more than one half of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members? at least nine members must participate in the ballot, either by voting in favor, voting against, or by abstaining for the vote to be valid. TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 19121 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4954 bytes Desc: not available URL: From Dean_Coclin at symantec.com Wed Feb 25 23:41:10 2015 From: Dean_Coclin at symantec.com (Dean Coclin) Date: Wed, 25 Feb 2015 15:41:10 -0800 Subject: [cabfpub] DRAFT Minutes of CA/B Forum meeting Feb 19, 2015 Message-ID: <14D026C7F297AD44AC82578DD818CDD038EF4A9BCA@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> Attendees: Dean Coclin, Doug Beattie, Kirk Hall, Bruce Morton, Rick Andrews, Ben Wilson, Eddy Nigg, Volkan (TurkTrust), Robin Alden, Mads (BuyPass), Tim Shirley, Wayne Thayer, Connie Enke, Atilla Biller, Gerv Markham, Jeremy Rowley, Atsushi Inaba, Sisel (BuyPass), Kubra (TurkTrust), Davut (E-Tugra), Cecilia Kam. 1. Antitrust Statement was read. 2. Minutes of Feb 5th meeting were approved. Ben to post to website 3. Ballot Status: Ballots 143 and 144 were approved. Ben will update the website to reflect the new working group name. Ballot 144 requires changes to the EV Guidelines which Jeremy will amend and update. There were a large number of abstentions on ballot 144. Jeremy said that many people may have used that to help the ballot meet quorum and that they didn't have a strong interest in the ballot. 4. IPv6: Ryan put out a draft ballot on this topic. Dean sent out the results of a survey of CASC members on this topic which Gerv said was very useful. Gerv said it would be good for the Internet for the Forum to support IPv6 and that the ballot provides a generous amount of time to do this. Jeremy said some CAs use a CDN and that may not support IPv6. Wayne updated the group stating that GoDaddy can now support it. Rick stated that for the sake of a complete argument, why not let market forces control this? Let people choose a CA that supports it if they want. Gerv said that doesn't work because a user or third party doesn't have that choice. Rick said most browsers don't fail on OCSP failure so it's not blocking anything. 5. Membership Application of TrustCor Systems: The Forum received an application for membership from this entity. They have a WebTrust report from Princeton Audit Group which stated they are not actively issuing certificates yet. Dean sent the applicant a note asking for a site that uses one of their certs. He also sent a note to Don Sheehy about the auditor qualifications. Kirk asked if they have a BR audit which Dean will ask the applicant. Kirk suggested that if they don't fully qualify, they could be granted observer status. Wayne asked if we should update the membership rules to require a BR audit. Jeremy agreed that this should be updated and that when we do a bylaw update, this should be undertaken. Wayne also said that everyone on the Management list is also on the Questions list. 6. New Ballots: Operational Existence (145) and pre-ballot Domain Validation (146). Cecilia and Kirk said that the EV Working group proposed ballot 145 for Government entity purposes. Discussion period for 145 starts today. Ballot 146 is a proposal to eliminate the "any other method (7)" for domain validation. Jeremy said they are soliciting comments and should have a proposal ready by the face to face meeting. Kirk encouraged others to bring forward any other verification methods for domain validation. Jeremy said there is another ballot coming forward on using attorney opinion letters for legal existence. This should be out before the face to face meeting. 7. Working group publicity: To date, the working group mailing lists have not been public. The bylaws state (in one place) that minutes and agendas of working groups should be made public and (in another place) that the lists should be managed in the same fashion as the public list. Gerv said that some working groups weren't public because they were in existence before the bylaws. But we should make the archives publicly accessible. Wayne said we can publish the URL to subscribe to the list. Gerv said that when groups are re-chartered, we should create a new list to not violate anyone's expectation of privacy from the old list. Regarding the new Validation Working Group, Gerv suggested we re-subscribe all the old members to the new list and state that it would be made public. It has to be clear that active participation is limited to those that have signed the IPR. 8. EV WG update: Per #6 above. 9. Code Signing update: Public draft of BR issued. Some comments received which the working group will address before the face to face meeting. 10. Policy Review WG: A ballot will be proposed for the reconfiguration of the BRs to RFC 3647 format. 11. Info Sharing WG: Hasn't met in a while but needs to get back together soon. Members have had conflicts during the meeting time. 12. Any other business: Kirk said we have 32 members coming to the F2F meeting. Send agenda items to Dean. 13. Next meeting will be March 5th. Dean Coclin CA/B Forum Chair -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6130 bytes Desc: not available URL: From jeremy.rowley at digicert.com Thu Feb 26 00:28:51 2015 From: jeremy.rowley at digicert.com (Jeremy Rowley) Date: Thu, 26 Feb 2015 00:28:51 +0000 Subject: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc In-Reply-To: References: <763539E260C37C46A0D6B340B5434C3B0ACD81A9@AEX06.ejsarea.net> A <763539E260C37C46A0D6B340B5434C3B0ADAE0EB@AEX06.ejsarea.net> Message-ID: <2639008ebb224f54be8be02132375681@EX2.corp.digicert.com> Should this be added to the BRs instead of code signing? For auditor qualifications, we just incorporate the auditor qualifications by reference. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jody Cloutier Sent: Friday, February 13, 2015 1:28 PM To: i-barreira at izenpe.net; public at cabforum.org Subject: Re: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Thank you, Inigo, What seems to be happening is that organizations are applying the ETSI standard in cases in which either there is no National Standards Body, or where the national standards body does not certify the company. Building on the scenario below, Audit Co is not recognized by ISRAC, but Auditor Jones has a CISP certification, which I've already confirmed with ETSI is not sufficient. I think what would help here is to make the requirement much more specific: A Qualified Auditor is limited to an auditor that is employed by a company that is certified by a National Authority listed in either the Members or Associate Members link. This, much simplified language, seems to be what you are saying below, but the current language is such that Audit Co can argue that it can issue an ETSI audit because it's company is certified by another national authority that's not listed on the ETSI webpages anywhere. Jody From: i-barreira at izenpe.net [mailto:i-barreira at izenpe.net] Sent: Friday, February 13, 2015 12:16 AM To: Jody Cloutier; public at cabforum.org Subject: RE: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Dear Jody, I understand your concern because it?s not easy for you to manage all possible combinations regarding ETSI audits in different countries so will try to clarify your example. First of all, no AuditCo has to be member of ETSI, AuditCo can perform ETSI accredited audits without being member of ETSI, they only need to be accredited in their country as stated in Annex E requirements. So, For example, * Company A is a commercial CA that operates in Israel * Auditor Jones works for AuditCo, which is based in Israel * AuditCo is certified by some governmental agency as a qualified auditor IB--> AuditCo has to be accredited under its National Accreditation Body according to ISO 17021. In the case of Israel, to follow the example, in the associated members tab of the EA, you can find the Israeli accreditation body, called ISRAC. Then AuditCo should be listed there and meeting the requirements to perform ETSI audits according to the national scheme indicated by ISRAC * AuditCo is not an ETSI Member or Associate Member IB --> this is not necessary. No need to be an ETSI member to perform ETSI audits * Auditor Jones audits Company A using the ETSI 102042 standard, and Company A sends the auditor's attestation letter to Microsoft as evidence that Company A complied with the Program's requirements. IB--> this is perfectly valid if AuditCo is listed in ISRAC and is allowed to perform ETSI audits. Of course Auditor Jones has to be also accredited to perform these kind of audits, has to be "qualified", so it?s not only the company but also the auditor, but that?s an internal task of the AuditCo. Regarding of being member of not, this is voluntary, they can join ETSI or not and don?t think that solve the problem because joining ETSI does not mean that you?re "qualified" or "accredited" to perform an ETSI audit, it?s just indicate that you belong to a club for example. And of course, if company A needs an auditing company accredited in Israel and there?s none, they can look for in other countries. For example, in Spain there?s no accredited auditing bodies to perform ETSI audits listed in our NAB, called ENAC, so, we, Izenpe, had to look for another option. So, we contacted for the first 6 years with KPMG in the Netherlands, and the last 3, with TUV IT in Germany. And Izenpe has an accredited ETSI audits according to the, right now, German national scheme and we?re listed in Germany. We?ll debate this within ETSI ESI trying to find an easier solution. Regards I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 [Descripci?n: cid:image001.png at 01CE3152.B4804EB0] ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. De: Jody Cloutier [mailto:jodycl at microsoft.com] Enviado el: mi?rcoles, 11 de febrero de 2015 0:32 Para: Barreira Iglesias, I?igo; public at cabforum.org Asunto: RE: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Thank you, Inigo. I think the problem is that, under ETSI, it's difficult to discern what an "equivalent national scheme" is. This sets up the scenario in which an auditor is employed by an organization that is recognized somehow by the government, but is not affiliated with an ETSI member organization (http://www.european-accreditation.org/home ). Microsoft does not know whether or not this auditor is qualified or not. For example, * Company A is a commercial CA that operates in Israel * Auditor Jones works for AuditCo, which is based in Israel * AuditCo is certified by some governmental agency as a qualified auditor * AuditCo is not an ETSI Member or Associate Member * Auditor Jones audits Company A using the ETSI 102042 standard, and Company A sends the auditor's attestation letter to Microsoft as evidence that Company A complied with the Program's requirements. In this scenario, how does Microsoft know that Auditor Jones conducted a proper audit without expending significant resources to determine whether and according to what standard AuditCo and Auditor Jones was certified? Microsoft believes that it would be simpler if the requirements were that the Auditor must work for a company that is affiliated with an ETSI-approved member organization. If Company A needs an auditor and there is no qualified auditor in Israel, the company can use an auditor from a member organization via the cross-border conformity rules. Unless I am fundamentally misunderstanding the rules, the above is something that Microsoft is presently struggling with, and we'd like to try to make the rules easier to understand for potential partners and ourselves. Jody Cloutier Senior Security Program Manager Microsoft Trusted Root Certificate Program jody.cloutier at microsoft.com 425.443.8922 Operating Systems Group Global Risk and Compliance [https://brandtools.microsoft.com/Style%20Library/BT/Images/MicrosoftMasterLogo.png] From: i-barreira at izenpe.net [mailto:i-barreira at izenpe.net] Sent: Tuesday, February 10, 2015 3:09 AM To: Jody Cloutier; public at cabforum.org Subject: RE: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Hi Jody, Regarding your comment on ETSI audits, I have to say that the ETSI audits shall be performed by accredited auditors as mentioned in Annex E of the current ETSI TS 102 042. ETSI audits performed by not accredited auditors shall be considered invalid. Microsoft is accepting ETSI audits since the very beginning in its root program requirements indicating this requirement. ETSI is providing a list of accredited auditors as mere information because has to be maintained by every NAB (National Accreditation Body). It?s true that this has to be improved regarding the new regulation 910/2014 and the new ENs and will take some time, but at the moment, it?s clearly stated that the audits shall be performed by accredited auditors. Don?t hesitate in contacting me for any additional information or help. Sometimes I?ve received some emails from Tom or Kelvin asking for the qualification of some audits, so, as say, you can contact me regarding this issue. Regards I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 [Descripci?n: cid:image001.png at 01CE3152.B4804EB0] ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. De: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] En nombre de Jody Cloutier Enviado el: lunes, 09 de febrero de 2015 18:55 Para: CABFPub (public at cabforum.org) Asunto: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Microsoft comments on Section 17. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 19121 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 1181 bytes Desc: image002.png URL: From i-barreira at izenpe.net Thu Feb 26 07:53:58 2015 From: i-barreira at izenpe.net (i-barreira at izenpe.net) Date: Thu, 26 Feb 2015 08:53:58 +0100 Subject: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc In-Reply-To: <2639008ebb224f54be8be02132375681@EX2.corp.digicert.com> References: <763539E260C37C46A0D6B340B5434C3B0ACD81A9@AEX06.ejsarea.net> A <763539E260C37C46A0D6B340B5434C3B0ADAE0EB@AEX06.ejsarea.net> <2639008ebb224f54be8be02132375681@EX2.corp.digicert.com> Message-ID: <763539E260C37C46A0D6B340B5434C3B0AE7ECC9@AEX06.ejsarea.net> I think the auditors qualification should be added to the BRs as a general matter valid for all documents produced by the CABF for all type of audits. So, all audits should be conducted in the same way. I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. De: Jeremy Rowley [mailto:jeremy.rowley at digicert.com] Enviado el: jueves, 26 de febrero de 2015 1:29 Para: Jody Cloutier; Barreira Iglesias, I?igo; public at cabforum.org Asunto: RE: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Should this be added to the BRs instead of code signing? For auditor qualifications, we just incorporate the auditor qualifications by reference. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jody Cloutier Sent: Friday, February 13, 2015 1:28 PM To: i-barreira at izenpe.net; public at cabforum.org Subject: Re: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Thank you, Inigo, What seems to be happening is that organizations are applying the ETSI standard in cases in which either there is no National Standards Body, or where the national standards body does not certify the company. Building on the scenario below, Audit Co is not recognized by ISRAC, but Auditor Jones has a CISP certification, which I've already confirmed with ETSI is not sufficient. I think what would help here is to make the requirement much more specific: A Qualified Auditor is limited to an auditor that is employed by a company that is certified by a National Authority listed in either the Members or Associate Members link. This, much simplified language, seems to be what you are saying below, but the current language is such that Audit Co can argue that it can issue an ETSI audit because it's company is certified by another national authority that's not listed on the ETSI webpages anywhere. Jody From: i-barreira at izenpe.net [mailto:i-barreira at izenpe.net] Sent: Friday, February 13, 2015 12:16 AM To: Jody Cloutier; public at cabforum.org Subject: RE: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Dear Jody, I understand your concern because it?s not easy for you to manage all possible combinations regarding ETSI audits in different countries so will try to clarify your example. First of all, no AuditCo has to be member of ETSI, AuditCo can perform ETSI accredited audits without being member of ETSI, they only need to be accredited in their country as stated in Annex E requirements. So, For example, ? Company A is a commercial CA that operates in Israel ? Auditor Jones works for AuditCo, which is based in Israel ? AuditCo is certified by some governmental agency as a qualified auditor IB? AuditCo has to be accredited under its National Accreditation Body according to ISO 17021. In the case of Israel, to follow the example, in the associated members tab of the EA, you can find the Israeli accreditation body, called ISRAC. Then AuditCo should be listed there and meeting the requirements to perform ETSI audits according to the national scheme indicated by ISRAC ? AuditCo is not an ETSI Member or Associate Member IB ? this is not necessary. No need to be an ETSI member to perform ETSI audits ? Auditor Jones audits Company A using the ETSI 102042 standard, and Company A sends the auditor's attestation letter to Microsoft as evidence that Company A complied with the Program's requirements. IB? this is perfectly valid if AuditCo is listed in ISRAC and is allowed to perform ETSI audits. Of course Auditor Jones has to be also accredited to perform these kind of audits, has to be "qualified", so it?s not only the company but also the auditor, but that?s an internal task of the AuditCo. Regarding of being member of not, this is voluntary, they can join ETSI or not and don?t think that solve the problem because joining ETSI does not mean that you?re "qualified" or "accredited" to perform an ETSI audit, it?s just indicate that you belong to a club for example. And of course, if company A needs an auditing company accredited in Israel and there?s none, they can look for in other countries. For example, in Spain there?s no accredited auditing bodies to perform ETSI audits listed in our NAB, called ENAC, so, we, Izenpe, had to look for another option. So, we contacted for the first 6 years with KPMG in the Netherlands, and the last 3, with TUV IT in Germany. And Izenpe has an accredited ETSI audits according to the, right now, German national scheme and we?re listed in Germany. We?ll debate this within ETSI ESI trying to find an easier solution. Regards I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. De: Jody Cloutier [mailto:jodycl at microsoft.com] Enviado el: mi?rcoles, 11 de febrero de 2015 0:32 Para: Barreira Iglesias, I?igo; public at cabforum.org Asunto: RE: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Thank you, Inigo. I think the problem is that, under ETSI, it's difficult to discern what an "equivalent national scheme" is. This sets up the scenario in which an auditor is employed by an organization that is recognized somehow by the government, but is not affiliated with an ETSI member organization (http://www.european-accreditation.org/home ). Microsoft does not know whether or not this auditor is qualified or not. For example, ? Company A is a commercial CA that operates in Israel ? Auditor Jones works for AuditCo, which is based in Israel ? AuditCo is certified by some governmental agency as a qualified auditor ? AuditCo is not an ETSI Member or Associate Member ? Auditor Jones audits Company A using the ETSI 102042 standard, and Company A sends the auditor's attestation letter to Microsoft as evidence that Company A complied with the Program's requirements. In this scenario, how does Microsoft know that Auditor Jones conducted a proper audit without expending significant resources to determine whether and according to what standard AuditCo and Auditor Jones was certified? Microsoft believes that it would be simpler if the requirements were that the Auditor must work for a company that is affiliated with an ETSI-approved member organization. If Company A needs an auditor and there is no qualified auditor in Israel, the company can use an auditor from a member organization via the cross-border conformity rules. Unless I am fundamentally misunderstanding the rules, the above is something that Microsoft is presently struggling with, and we'd like to try to make the rules easier to understand for potential partners and ourselves. Jody Cloutier Senior Security Program Manager Microsoft Trusted Root Certificate Program jody.cloutier at microsoft.com 425.443.8922 Operating Systems Group Global Risk and Compliance From: i-barreira at izenpe.net [mailto:i-barreira at izenpe.net] Sent: Tuesday, February 10, 2015 3:09 AM To: Jody Cloutier; public at cabforum.org Subject: RE: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Hi Jody, Regarding your comment on ETSI audits, I have to say that the ETSI audits shall be performed by accredited auditors as mentioned in Annex E of the current ETSI TS 102 042. ETSI audits performed by not accredited auditors shall be considered invalid. Microsoft is accepting ETSI audits since the very beginning in its root program requirements indicating this requirement. ETSI is providing a list of accredited auditors as mere information because has to be maintained by every NAB (National Accreditation Body). It?s true that this has to be improved regarding the new regulation 910/2014 and the new ENs and will take some time, but at the moment, it?s clearly stated that the audits shall be performed by accredited auditors. Don?t hesitate in contacting me for any additional information or help. Sometimes I?ve received some emails from Tom or Kelvin asking for the qualification of some audits, so, as say, you can contact me regarding this issue. Regards I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. De: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] En nombre de Jody Cloutier Enviado el: lunes, 09 de febrero de 2015 18:55 Para: CABFPub (public at cabforum.org) Asunto: [cabfpub] Baseline requirements for codesigning - Feb 4 2015.doc Microsoft comments on Section 17. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 19121 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 1181 bytes Desc: image002.png URL: From mcaughron at apple.com Thu Feb 26 22:15:37 2015 From: mcaughron at apple.com (Mat Caughron) Date: Thu, 26 Feb 2015 14:15:37 -0800 Subject: [cabfpub] Updated Certificate Transparency + Extended Validation plan In-Reply-To: References: Message-ID: <2C97673F-8638-4592-8B0C-C7398D2221A7@apple.com> Greetings: It has been one year, has this CT plan been updated at all? Sincerely, Mat Caughron ? Product Security > On Feb 4, 2014, at 9:08 AM, Ben Laurie wrote: > > Enclosed, our revised plan. > > Comments welcome. > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4112 bytes Desc: not available URL: From rob.stradling at comodo.com Thu Feb 26 22:24:25 2015 From: rob.stradling at comodo.com (Rob Stradling) Date: Thu, 26 Feb 2015 17:24:25 -0500 Subject: [cabfpub] Updated Certificate Transparency + Extended Validationplan In-Reply-To: <2C97673F-8638-4592-8B0C-C7398D2221A7@apple.com> References: <2C97673F-8638-4592-8B0C-C7398D2221A7@apple.com> Message-ID: <54EF9D19.9070105@comodo.com> On 26/02/15 17:15, Mat Caughron wrote: > Greetings: > > It has been one year, has this CT plan been updated at all? Hi Mat. Google's EV/CT Plan has been updated a couple of times since then. See here: http://www.certificate-transparency.org/ev-ct-plan > Sincerely, > > > Mat Caughron > ? Product Security > > > >> On Feb 4, 2014, at 9:08 AM, Ben Laurie wrote: >> >> Enclosed, our revised plan. >> >> Comments welcome. >> _______________________________________________ >> Public mailing list >> Public at cabforum.org >> https://cabforum.org/mailman/listinfo/public > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From mcaughron at apple.com Thu Feb 26 22:39:22 2015 From: mcaughron at apple.com (Mat Caughron) Date: Thu, 26 Feb 2015 14:39:22 -0800 Subject: [cabfpub] Updated Certificate Transparency + Extended Validationplan In-Reply-To: <54EF9D19.9070105@comodo.com> References: <2C97673F-8638-4592-8B0C-C7398D2221A7@apple.com> <54EF9D19.9070105@comodo.com> Message-ID: <0281DDB3-432A-4ABA-82B6-D757D92E6A4A@apple.com> Hello Rob, So presumably, the survey if conducted now would indicate a few more CA's on board than indicated here? http://www.certificate-transparency.org/feb-2014-survey-responses Mat Caughron ? Product Security mcaughron at appe.com > On Feb 26, 2015, at 2:24 PM, Rob Stradling wrote: > > On 26/02/15 17:15, Mat Caughron wrote: >> Greetings: >> >> It has been one year, has this CT plan been updated at all? > > Hi Mat. > > Google's EV/CT Plan has been updated a couple of times since then. See here: > http://www.certificate-transparency.org/ev-ct-plan > >> Sincerely, >> >> >> Mat Caughron >> ? Product Security >> >> >> >>> On Feb 4, 2014, at 9:08 AM, Ben Laurie wrote: >>> >>> Enclosed, our revised plan. >>> >>> Comments welcome. >>> _______________________________________________ >>> Public mailing list >>> Public at cabforum.org >>> https://cabforum.org/mailman/listinfo/public >> > > -- > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4112 bytes Desc: not available URL: From rob.stradling at comodo.com Fri Feb 27 04:18:18 2015 From: rob.stradling at comodo.com (Rob Stradling) Date: Thu, 26 Feb 2015 23:18:18 -0500 Subject: [cabfpub] Updated Certificate Transparency + ExtendedValidationplan In-Reply-To: <0281DDB3-432A-4ABA-82B6-D757D92E6A4A@apple.com> References: <2C97673F-8638-4592-8B0C-C7398D2221A7@apple.com> <54EF9D19.9070105@comodo.com> <0281DDB3-432A-4ABA-82B6-D757D92E6A4A@apple.com> Message-ID: <54EFF00A.5030805@comodo.com> Good question, Mat. I've just generated a report (see attached) that shows, per issuing CA, the number of certs with embedded SCTs that have been logged in the currently existing CT logs so far. That is one measurement of which CAs are "on board", but it's not the full story. On 26/02/15 17:39, Mat Caughron wrote: > Hello Rob, > > So presumably, the survey if conducted now would indicate a few more > CA's on board than indicated here? > http://www.certificate-transparency.org/feb-2014-survey-responses > > > > Mat Caughron > ? Product Security > mcaughron at appe.com > > > >> On Feb 26, 2015, at 2:24 PM, Rob Stradling > > wrote: >> >> On 26/02/15 17:15, Mat Caughron wrote: >>> Greetings: >>> >>> It has been one year, has this CT plan been updated at all? >> >> Hi Mat. >> >> Google's EV/CT Plan has been updated a couple of times since then. >> See here: >> http://www.certificate-transparency.org/ev-ct-plan >> >>> Sincerely, >>> >>> >>> Mat Caughron >>> ? Product Security >>> >>> >>> >>>> On Feb 4, 2014, at 9:08 AM, Ben Laurie wrote: >>>> >>>> Enclosed, our revised plan. >>>> >>>> Comments welcome. >>>> _______________________________________________ >>>> Public mailing list >>>> Public at cabforum.org >>>> https://cabforum.org/mailman/listinfo/public >>> >> >> -- >> Rob Stradling >> Senior Research & Development Scientist >> COMODO - Creating Trust Online > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. -------------- next part -------------- A non-text attachment was scrubbed... Name: certs_with_embedded_scts_per_ca.csv Type: text/csv Size: 6218 bytes Desc: not available URL: From i-barreira at izenpe.net Fri Feb 27 07:40:15 2015 From: i-barreira at izenpe.net (i-barreira at izenpe.net) Date: Fri, 27 Feb 2015 08:40:15 +0100 Subject: [cabfpub] Updated Certificate Transparency + ExtendedValidationplan In-Reply-To: <54EFF00A.5030805@comodo.com> References: <2C97673F-8638-4592-8B0C-C7398D2221A7@apple.com> <54EF9D19.9070105@comodo.com> <0281DDB3-432A-4ABA-82B6-D757D92E6A4A@apple.com> <54EFF00A.5030805@comodo.com> Message-ID: <763539E260C37C46A0D6B340B5434C3B0AE7EF28@AEX06.ejsarea.net> And for example, Izepe indicated that were not interested in running a log server, and we?re running one :-) I?igo Barreira Responsable del ?rea t?cnica i-barreira at izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. -----Mensaje original----- De: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] En nombre de Rob Stradling Enviado el: viernes, 27 de febrero de 2015 5:18 Para: Mat Caughron CC: therightkey at ietf.org; certificate-transparency at googlegroups.com; CABFPub Asunto: Re: [cabfpub] Updated Certificate Transparency + ExtendedValidationplan Good question, Mat. I've just generated a report (see attached) that shows, per issuing CA, the number of certs with embedded SCTs that have been logged in the currently existing CT logs so far. That is one measurement of which CAs are "on board", but it's not the full story. On 26/02/15 17:39, Mat Caughron wrote: > Hello Rob, > > So presumably, the survey if conducted now would indicate a few more > CA's on board than indicated here? > http://www.certificate-transparency.org/feb-2014-survey-responses > > > > Mat Caughron > ? Product Security > mcaughron at appe.com > > > >> On Feb 26, 2015, at 2:24 PM, Rob Stradling > > wrote: >> >> On 26/02/15 17:15, Mat Caughron wrote: >>> Greetings: >>> >>> It has been one year, has this CT plan been updated at all? >> >> Hi Mat. >> >> Google's EV/CT Plan has been updated a couple of times since then. >> See here: >> http://www.certificate-transparency.org/ev-ct-plan >> >>> Sincerely, >>> >>> >>> Mat Caughron >>> ? Product Security >>> >>> >>> >>>> On Feb 4, 2014, at 9:08 AM, Ben Laurie wrote: >>>> >>>> Enclosed, our revised plan. >>>> >>>> Comments welcome. >>>> _______________________________________ >>>> ________ >>>> Public mailing list >>>> Public at cabforum.org >>>> https://cabforum.org/mailman/listinfo/public >>> >> >> -- >> Rob Stradling >> Senior Research & Development Scientist COMODO - Creating Trust >> Online > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. From bruce.morton at entrust.com Fri Feb 27 14:25:46 2015 From: bruce.morton at entrust.com (Bruce Morton) Date: Fri, 27 Feb 2015 14:25:46 +0000 Subject: [cabfpub] Ballot 145 - Operational Existence for Government Entities In-Reply-To: References: Message-ID: <452C99D20750E74083DBA441FF932385E41A749D@SOTTEXCH10.corp.ad.entrust.com> Entrust votes Yes. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Thursday, February 19, 2015 10:44 AM To: CABFPub Subject: [cabfpub] Ballot 145 - Operational Existence for Government Entities Ballot 145 - Operational Existence for Government Entities ________________________________ Reason ________________________________ Because government entities aren't operating as businesses, they are often not listed with a QIIS, especially immediately after the entity is created by either statute or order. The legal existence of these entities is verifiable through a QGIS, but this source in many countries (especially Arabic and African countries) does not always list a date of creation of these entities. Operational existence exists to ensure organizations aren't fly-by-night scams/phishing entities. With government entities, these same risks are not present as they are created directly by government action. Jeremy Rowley of DigiCert made the following motion, which was endorsed by Rich Smith of Comodo and Cecilia Kam of Symantec. ________________________________ Motion begins ________________________________ Effective immediately, section 11.6.1 is modified as follows: 11.6.1 Verification Requirements. The CA MUST verify that the Applicant has the ability to engage in business by verifying the Applicant's, or Affiliate/Parent/Subsidiary Company's, operational existence. The CA MAY rely on its verification of a Government Entity's legal existence under Section 11.2 as verification of a Government Entity's operational existence. ________________________________ Motion Ends ________________________________ The review period for this ballot shall commence at 2200 UTC on 19 Feb 2015, and will close at 2200 UTC on 26 Feb 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on 5 Mar 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirk_hall at trendmicro.com Fri Feb 27 16:05:00 2015 From: kirk_hall at trendmicro.com (kirk_hall at trendmicro.com) Date: Fri, 27 Feb 2015 16:05:00 +0000 Subject: [cabfpub] Ballot 145 - Operational Existence for Government Entities In-Reply-To: <452C99D20750E74083DBA441FF932385E41A749D@SOTTEXCH10.corp.ad.entrust.com> References: <452C99D20750E74083DBA441FF932385E41A749D@SOTTEXCH10.corp.ad.entrust.com> Message-ID: Trend Micro votes yes From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Thursday, February 19, 2015 10:44 AM To: CABFPub Subject: [cabfpub] Ballot 145 - Operational Existence for Government Entities Ballot 145 - Operational Existence for Government Entities ________________________________ Reason ________________________________ Because government entities aren't operating as businesses, they are often not listed with a QIIS, especially immediately after the entity is created by either statute or order. The legal existence of these entities is verifiable through a QGIS, but this source in many countries (especially Arabic and African countries) does not always list a date of creation of these entities. Operational existence exists to ensure organizations aren't fly-by-night scams/phishing entities. With government entities, these same risks are not present as they are created directly by government action. Jeremy Rowley of DigiCert made the following motion, which was endorsed by Rich Smith of Comodo and Cecilia Kam of Symantec. ________________________________ Motion begins ________________________________ Effective immediately, section 11.6.1 is modified as follows: 11.6.1 Verification Requirements. The CA MUST verify that the Applicant has the ability to engage in business by verifying the Applicant's, or Affiliate/Parent/Subsidiary Company's, operational existence. The CA MAY rely on its verification of a Government Entity's legal existence under Section 11.2 as verification of a Government Entity's operational existence. ________________________________ Motion Ends ________________________________ The review period for this ballot shall commence at 2200 UTC on 19 Feb 2015, and will close at 2200 UTC on 26 Feb 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on 5 Mar 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
-------------- next part -------------- An HTML attachment was scrubbed... URL: From richard at wosign.com Fri Feb 27 16:13:34 2015 From: richard at wosign.com (Richard Wang) Date: Fri, 27 Feb 2015 16:13:34 +0000 Subject: [cabfpub] Ballot 145 - Operational Existence for Government Entities In-Reply-To: References: <452C99D20750E74083DBA441FF932385E41A749D@SOTTEXCH10.corp.ad.entrust.com> Message-ID: <43831CBB-7B89-4F6A-9EA8-714DD58A067E@wosign.com> > WoSign votes yes > > From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley > Sent: Thursday, February 19, 2015 10:44 AM > To: CABFPub > Subject: [cabfpub] Ballot 145 - Operational Existence for Government Entities > > Ballot 145 - Operational Existence for Government Entities > > Reason > > Because government entities aren?t operating as businesses, they are often not listed with a QIIS, especially immediately after the entity is created by either statute or order. The legal existence of these entities is verifiable through a QGIS, but this source in many countries (especially Arabic and African countries) does not always list a date of creation of these entities. Operational existence exists to ensure organizations aren?t fly-by-night scams/phishing entities. With government entities, these same risks are not present as they are created directly by government action. > > Jeremy Rowley of DigiCert made the following motion, which was endorsed by Rich Smith of Comodo and Cecilia Kam of Symantec. > > Motion begins > > Effective immediately, section 11.6.1 is modified as follows: > > 11.6.1 Verification Requirements. > > The CA MUST verify that the Applicant has the ability to engage in business by verifying the Applicant's, or Affiliate/Parent/Subsidiary Company's, operational existence. The CA MAY rely on its verification of a Government Entity?s legal existence under Section 11.2 as verification of a Government Entity?s operational existence. > > Motion Ends > > The review period for this ballot shall commence at 2200 UTC on 19 Feb 2015, and will close at 2200 UTC on 26 Feb 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on 5 Mar 2015. Votes must be cast by posting an on-list reply to this thread. > > A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ > > In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members? at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. > > > TREND MICRO EMAIL NOTICE > The information contained in this email and any attachments is confidential > and may be subject to copyright or other intellectual property protection. > If you are not the intended recipient, you are not authorized to use or > disclose this information, and we request that you notify us by reply mail or > telephone and delete the original message from your mail system. > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 7152 bytes Desc: not available URL: From Dean_Coclin at symantec.com Fri Feb 27 18:32:39 2015 From: Dean_Coclin at symantec.com (Dean Coclin) Date: Fri, 27 Feb 2015 10:32:39 -0800 Subject: [cabfpub] Ballot 145 - Operational Existence for Government Entities In-Reply-To: References: Message-ID: <14D026C7F297AD44AC82578DD818CDD038EF614DE0@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> Symantec votes YES. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Thursday, February 19, 2015 10:44 AM To: CABFPub Subject: [cabfpub] Ballot 145 - Operational Existence for Government Entities Ballot 145 - Operational Existence for Government Entities _____ Reason _____ Because government entities aren't operating as businesses, they are often not listed with a QIIS, especially immediately after the entity is created by either statute or order. The legal existence of these entities is verifiable through a QGIS, but this source in many countries (especially Arabic and African countries) does not always list a date of creation of these entities. Operational existence exists to ensure organizations aren't fly-by-night scams/phishing entities. With government entities, these same risks are not present as they are created directly by government action. Jeremy Rowley of DigiCert made the following motion, which was endorsed by Rich Smith of Comodo and Cecilia Kam of Symantec. _____ Motion begins _____ Effective immediately, section 11.6.1 is modified as follows: 11.6.1 Verification Requirements. The CA MUST verify that the Applicant has the ability to engage in business by verifying the Applicant's, or Affiliate/Parent/Subsidiary Company's, operational existence. The CA MAY rely on its verification of a Government Entity's legal existence under Section 11.2 as verification of a Government Entity's operational existence. _____ Motion Ends _____ The review period for this ballot shall commence at 2200 UTC on 19 Feb 2015, and will close at 2200 UTC on 26 Feb 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on 5 Mar 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6130 bytes Desc: not available URL: From S.Davidson at quovadisglobal.com Fri Feb 27 18:42:27 2015 From: S.Davidson at quovadisglobal.com (Stephen Davidson) Date: Fri, 27 Feb 2015 18:42:27 +0000 Subject: [cabfpub] Ballot 145 - Operational Existence for Government Entities In-Reply-To: <452C99D20750E74083DBA441FF932385E41A749D@SOTTEXCH10.corp.ad.entrust.com> References: <452C99D20750E74083DBA441FF932385E41A749D@SOTTEXCH10.corp.ad.entrust.com> Message-ID: QuoVadis votes yes. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Thursday, February 19, 2015 10:44 AM To: CABFPub Subject: [cabfpub] Ballot 145 - Operational Existence for Government Entities Ballot 145 - Operational Existence for Government Entities _____ Reason _____ Because government entities aren't operating as businesses, they are often not listed with a QIIS, especially immediately after the entity is created by either statute or order. The legal existence of these entities is verifiable through a QGIS, but this source in many countries (especially Arabic and African countries) does not always list a date of creation of these entities. Operational existence exists to ensure organizations aren't fly-by-night scams/phishing entities. With government entities, these same risks are not present as they are created directly by government action. Jeremy Rowley of DigiCert made the following motion, which was endorsed by Rich Smith of Comodo and Cecilia Kam of Symantec. _____ Motion begins _____ Effective immediately, section 11.6.1 is modified as follows: 11.6.1 Verification Requirements. The CA MUST verify that the Applicant has the ability to engage in business by verifying the Applicant's, or Affiliate/Parent/Subsidiary Company's, operational existence. The CA MAY rely on its verification of a Government Entity's legal existence under Section 11.2 as verification of a Government Entity's operational existence. _____ Motion Ends _____ The review period for this ballot shall commence at 2200 UTC on 19 Feb 2015, and will close at 2200 UTC on 26 Feb 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on 5 Mar 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5529 bytes Desc: not available URL: From jeremy.rowley at digicert.com Fri Feb 27 18:44:33 2015 From: jeremy.rowley at digicert.com (Jeremy Rowley) Date: Fri, 27 Feb 2015 18:44:33 +0000 Subject: [cabfpub] Ballot 145 - Operational Existence for Government Entities In-Reply-To: <14D026C7F297AD44AC82578DD818CDD038EF614DE0@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> References: <14D026C7F297AD44AC82578DD818CDD038EF614DE0@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> Message-ID: <5e3148ac833b49f9a4a0363fa6fddbc5@EX2.corp.digicert.com> DigiCert votes YES From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Dean Coclin Sent: Friday, February 27, 2015 11:33 AM To: CABFPub Subject: Re: [cabfpub] Ballot 145 - Operational Existence for Government Entities Symantec votes YES. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Thursday, February 19, 2015 10:44 AM To: CABFPub Subject: [cabfpub] Ballot 145 - Operational Existence for Government Entities Ballot 145 - Operational Existence for Government Entities ________________________________ Reason ________________________________ Because government entities aren't operating as businesses, they are often not listed with a QIIS, especially immediately after the entity is created by either statute or order. The legal existence of these entities is verifiable through a QGIS, but this source in many countries (especially Arabic and African countries) does not always list a date of creation of these entities. Operational existence exists to ensure organizations aren't fly-by-night scams/phishing entities. With government entities, these same risks are not present as they are created directly by government action. Jeremy Rowley of DigiCert made the following motion, which was endorsed by Rich Smith of Comodo and Cecilia Kam of Symantec. ________________________________ Motion begins ________________________________ Effective immediately, section 11.6.1 is modified as follows: 11.6.1 Verification Requirements. The CA MUST verify that the Applicant has the ability to engage in business by verifying the Applicant's, or Affiliate/Parent/Subsidiary Company's, operational existence. The CA MAY rely on its verification of a Government Entity's legal existence under Section 11.2 as verification of a Government Entity's operational existence. ________________________________ Motion Ends ________________________________ The review period for this ballot shall commence at 2200 UTC on 19 Feb 2015, and will close at 2200 UTC on 26 Feb 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on 5 Mar 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jodycl at microsoft.com Fri Feb 27 18:48:05 2015 From: jodycl at microsoft.com (Jody Cloutier) Date: Fri, 27 Feb 2015 18:48:05 +0000 Subject: [cabfpub] Ballot 145 - Operational Existence for Government Entities In-Reply-To: <5e3148ac833b49f9a4a0363fa6fddbc5@EX2.corp.digicert.com> References: <14D026C7F297AD44AC82578DD818CDD038EF614DE0@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> <5e3148ac833b49f9a4a0363fa6fddbc5@EX2.corp.digicert.com> Message-ID: Microsoft votes YES From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Friday, February 27, 2015 10:45 AM To: Dean Coclin; CABFPub Subject: Re: [cabfpub] Ballot 145 - Operational Existence for Government Entities DigiCert votes YES From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Dean Coclin Sent: Friday, February 27, 2015 11:33 AM To: CABFPub Subject: Re: [cabfpub] Ballot 145 - Operational Existence for Government Entities Symantec votes YES. From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley Sent: Thursday, February 19, 2015 10:44 AM To: CABFPub Subject: [cabfpub] Ballot 145 - Operational Existence for Government Entities Ballot 145 - Operational Existence for Government Entities ________________________________ Reason ________________________________ Because government entities aren't operating as businesses, they are often not listed with a QIIS, especially immediately after the entity is created by either statute or order. The legal existence of these entities is verifiable through a QGIS, but this source in many countries (especially Arabic and African countries) does not always list a date of creation of these entities. Operational existence exists to ensure organizations aren't fly-by-night scams/phishing entities. With government entities, these same risks are not present as they are created directly by government action. Jeremy Rowley of DigiCert made the following motion, which was endorsed by Rich Smith of Comodo and Cecilia Kam of Symantec. ________________________________ Motion begins ________________________________ Effective immediately, section 11.6.1 is modified as follows: 11.6.1 Verification Requirements. The CA MUST verify that the Applicant has the ability to engage in business by verifying the Applicant's, or Affiliate/Parent/Subsidiary Company's, operational existence. The CA MAY rely on its verification of a Government Entity's legal existence under Section 11.2 as verification of a Government Entity's operational existence. ________________________________ Motion Ends ________________________________ The review period for this ballot shall commence at 2200 UTC on 19 Feb 2015, and will close at 2200 UTC on 26 Feb 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on 5 Mar 2015. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members- at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining. -------------- next part -------------- An HTML attachment was scrubbed... URL: From enric.castillo at anf.es Fri Feb 27 19:56:02 2015 From: enric.castillo at anf.es (Enric Castillo) Date: Fri, 27 Feb 2015 14:56:02 -0500 Subject: [cabfpub] Ballot 145 - Operational Existence for Government Entities In-Reply-To: References: Message-ID: <54F0CBD2.8010102@anf.es> ANF AC votes yes. ANF Autoridad de Certificaci?n *Enric Castillo* Director T?cnico +34 626818285 Gran Via de Les Corts Catalanes 996, Barcelona +593 0 998554992 12 de Octubre y Cordero, World Trade Center, Torre A, 1102, Quito ANF Autoridad de Certificaci?n www.anf.es *Aviso* Este mensaje se dirige exclusivamente a su destinatario y puede contener informaci?n privilegiada o confidencial y/o datos de car?cter personal, cuya difusi?n est? regulada por la Ley Org?nica de Protecci?n de Datos y la Ley de Servicios de la Sociedad de la Informaci?n. Si usted no es el destinatario indicado (o el responsable de la entrega al mismo), no debe copiar o entregar este mensaje a terceros bajo ning?n concepto. Si ha recibido este mensaje por error o lo ha conseguido por otros medios, le rogamos que nos lo comunique inmediatamente por esta misma v?a y proceda a su eliminaci?n irreversible. Las opiniones, conclusiones y dem?s informaciones incluidas en este mensaje que no est?n relacionadas con asuntos profesionales de ANF Autoridad de Certificaci?n no est?n respaldadas por la empresa. El 19/02/2015 a las 10:43, Jeremy Rowley escribi?: > > Ballot 145 - Operational Existence for Government Entities > > ------------------------------------------------------------------------ > > Reason > > ------------------------------------------------------------------------ > > Because government entities aren?t operating as businesses, they are > often not listed with a QIIS, especially immediately after the entity > is created by either statute or order. The legal existence of these > entities is verifiable through a QGIS, but this source in many > countries (especially Arabic and African countries) does not always > list a date of creation of these entities. Operational existence > exists to ensure organizations aren?t fly-by-night scams/phishing > entities. With government entities, these same risks are not present > as they are created directly by government action. > > Jeremy Rowley of DigiCert > made the following motion, which was endorsed by Rich Smith of Comodo > and Cecilia Kam of Symantec. > > ------------------------------------------------------------------------ > > Motion begins > > ------------------------------------------------------------------------ > > Effective immediately, section 11.6.1 is modified as follows: > > 11.6.1 Verification Requirements. > > The CA MUST verify that the Applicant has the ability to engage in > business by verifying the Applicant's, or Affiliate/Parent/Subsidiary > Company's, operational existence._The CA MAY rely on its verification > of a Government Entity?s legal existence under Section 11.2 as > verification of a Government Entity?s operational existence. _ > > ------------------------------------------------------------------------ > > Motion Ends > > ------------------------------------------------------------------------ > > The review period for this ballot shall commence at 2200 UTC on 19 Feb > 2015, and will close at 2200 UTC on 26 Feb 2015. Unless the motion is > withdrawn during the review period, the voting period will start > immediately thereafter and will close at 2200 UTC on 5 Mar 2015. Votes > must be cast by posting an on-list reply to this thread. > > A vote in favor of the motion must indicate a clear 'yes' in the > response. A vote against must indicate a clear 'no' in the response. A > vote to abstain must indicate a clear 'abstain' in the response. > Unclear responses will not be counted. The latest vote received from > any representative of a voting member before the close of the voting > period will be counted. Voting members are listed here: > https://cabforum.org/members/ > > In order for the motion to be adopted, two thirds or more of the votes > cast by members in the CA category and greater than 50% of the votes > cast by members in the browser category must be in favor. Quorum is > currently nine (9) members? at least nine members must participate in > the ballot, either by voting in favor, voting against, or abstaining. > > > > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo-anf.png Type: image/png Size: 4746 bytes Desc: not available URL: From eddy_nigg at startcom.org Fri Feb 27 20:32:28 2015 From: eddy_nigg at startcom.org (Eddy Nigg) Date: Fri, 27 Feb 2015 22:32:28 +0200 Subject: [cabfpub] Ballot 145 - Operational Existence for Government Entities In-Reply-To: References: Message-ID: <54F0D45C.9050501@startcom.org> If you need more yes votes, here another one: StartCom votes YES On 02/19/2015 05:43 PM, Jeremy Rowley wrote: > > Ballot 145 - Operational Existence for Government Entities > > ------------------------------------------------------------------------ > > Reason > > ------------------------------------------------------------------------ > > Because government entities aren't operating as businesses, they are > often not listed with a QIIS, especially immediately after the entity > is created by either statute or order. The legal existence of these > entities is verifiable through a QGIS, but this source in many > countries (especially Arabic and African countries) does not always > list a date of creation of these entities. Operational existence > exists to ensure organizations aren't fly-by-night scams/phishing > entities. With government entities, these same risks are not present > as they are created directly by government action. > > Jeremy Rowley of DigiCert > made the following motion, which was endorsed by Rich Smith of Comodo > and Cecilia Kam of Symantec. > > ------------------------------------------------------------------------ > > Motion begins > > ------------------------------------------------------------------------ > > Effective immediately, section 11.6.1 is modified as follows: > > 11.6.1 Verification Requirements. > > The CA MUST verify that the Applicant has the ability to engage in > business by verifying the Applicant's, or Affiliate/Parent/Subsidiary > Company's, operational existence._The CA MAY rely on its verification > of a Government Entity's legal existence under Section 11.2 as > verification of a Government Entity's operational existence. _ > > ------------------------------------------------------------------------ > > Motion Ends > > ------------------------------------------------------------------------ > > The review period for this ballot shall commence at 2200 UTC on 19 Feb > 2015, and will close at 2200 UTC on 26 Feb 2015. Unless the motion is > withdrawn during the review period, the voting period will start > immediately thereafter and will close at 2200 UTC on 5 Mar 2015. Votes > must be cast by posting an on-list reply to this thread. > > A vote in favor of the motion must indicate a clear 'yes' in the > response. A vote against must indicate a clear 'no' in the response. A > vote to abstain must indicate a clear 'abstain' in the response. > Unclear responses will not be counted. The latest vote received from > any representative of a voting member before the close of the voting > period will be counted. Voting members are listed here: > https://cabforum.org/members/ > > In order for the motion to be adopted, two thirds or more of the votes > cast by members in the CA category and greater than 50% of the votes > cast by members in the browser category must be in favor. Quorum is > currently nine (9) members-- at least nine members must participate in > the ballot, either by voting in favor, voting against, or abstaining. > > > > _______________________________________________ > Public mailing list > Public at cabforum.org > https://cabforum.org/mailman/listinfo/public -- Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. XMPP: startcom at startcom.org Blog: Join the Revolution! Twitter: Follow Me -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4313 bytes Desc: S/MIME Cryptographic Signature URL: From rob.stradling at comodo.com Fri Feb 27 23:28:06 2015 From: rob.stradling at comodo.com (Rob Stradling) Date: Fri, 27 Feb 2015 18:28:06 -0500 Subject: [cabfpub] Updated Certificate Transparency + ExtendedValidationplan In-Reply-To: <54EFF00A.5030805@comodo.com> References: <2C97673F-8638-4592-8B0C-C7398D2221A7@apple.com> <54EF9D19.9070105@comodo.com> <0281DDB3-432A-4ABA-82B6-D757D92E6A4A@apple.com> <54EFF00A.5030805@comodo.com> Message-ID: <54F0FD86.3010608@comodo.com> Mat, BTW, do Apple have any plans to support CT in Safari? On 26/02/15 23:18, Rob Stradling wrote: > Good question, Mat. > > I've just generated a report (see attached) that shows, per issuing CA, > the number of certs with embedded SCTs that have been logged in the > currently existing CT logs so far. > > That is one measurement of which CAs are "on board", but it's not the > full story. > > On 26/02/15 17:39, Mat Caughron wrote: >> Hello Rob, >> >> So presumably, the survey if conducted now would indicate a few more >> CA's on board than indicated here? >> http://www.certificate-transparency.org/feb-2014-survey-responses >> >> >> >> Mat Caughron >> ? Product Security >> mcaughron at appe.com >> >> >> >>> On Feb 26, 2015, at 2:24 PM, Rob Stradling >> > wrote: >>> >>> On 26/02/15 17:15, Mat Caughron wrote: >>>> Greetings: >>>> >>>> It has been one year, has this CT plan been updated at all? >>> >>> Hi Mat. >>> >>> Google's EV/CT Plan has been updated a couple of times since then. >>> See here: >>> http://www.certificate-transparency.org/ev-ct-plan >>> >>>> Sincerely, >>>> >>>> >>>> Mat Caughron >>>> ? Product Security >>>> >>>> >>>> >>>>> On Feb 4, 2014, at 9:08 AM, Ben Laurie wrote: >>>>> >>>>> Enclosed, our revised plan. >>>>> >>>>> Comments welcome. >>>>> _______________________________________________ >>>>> >>>>> Public mailing list >>>>> Public at cabforum.org >>>>> https://cabforum.org/mailman/listinfo/public >>>> >>> >>> -- >>> Rob Stradling >>> Senior Research & Development Scientist >>> COMODO - Creating Trust Online >> > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software.