[cabfpub] For informal review: Updated Code of Conduct Ballot

[Virginia Fournier via Public]

Hello all,

Here’s an updated draft of the Code of Conduct, in response to the most recent 
round of comments.

The definitions of the words used in the Code of Conduct are going to vary 
depending on the situation.  We will all have to use common sense and our best 
professional judgement to interpret the terms and comply with them.  It would 
not be possible to come up with comprehensive definitions of, for example, 
“demeaning” or “inappropriate” that would cover every possible scenario.

Also, there’s no point in having a Code of Conduct if there aren’t consequences 
of violating it.  However, the Code is flexible enough so that the number and 
severity of violations can be taken into consideration when determining what 
consequences would be appropriate, if any.  For example, different consequences 
would be in order if someone makes daily death threats to someone on the public 
mailing list, than if someone accidentally calls someone a 

With that said, please see changes below, highlighted in red.  Also, some of 
the paragraphs have been reordered so they’re in a more logical order. 

===
DRAFT BALLOT
===

Ballot ###

Purpose of Ballot:  To add a Code of Conduct to the CAB Forum Bylaws.

The following motion has been proposed by [name] of [company] and endorsed by 
[name] of [company] and [name] of [company].

—MOTION BEGINS—

1.  A new Section 6.4 will be added to the Bylaws of the CAB Forum, and will 
read in its entirety as follows:

“Section 6.4

All Members shall abide by the CAB Forum Code of Conduct, which is attached to 
these Bylaws as Exhibit C.”

2.  A new Exhibit C will be added to the Bylaws, and will read in its entirety 
as follows:

“Exhibit C

CAB Forum Code of Conduct (the “Code")

The CAB Forum (the “Forum") is comprised of a global group of professionals 
with differences in language, skills, expertise, experience, and backgrounds.  
To maintain a professional and productive environment, it is necessary for 
Members of the Forum to follow the letter and spirit of this Code.  This Code 
applies to all official Forum activities, such as meetings, teleconferences, 
mailing lists, conferences, and other Forum functions.  The Forum is committed 
to maintaining a professional and respectful environment.

All Member representatives are expected to behave in a collegial and 
professional manner in accordance with this Code.  Members will familiarize 
their representatives with this Code and require them to comply with the letter 
and spirit of this Code.

I.  Conduct.  The Forum is committed to providing a friendly, safe, and 
welcoming environment for all, regardless of gender, gender identity and 
expression, sexual orientation, disability, personal appearance, body size, 
race, ethnicity, age, religion, nationality, or other similar characteristic.  
The Forum recognizes and appreciates that its participants have diverse 
languages, backgrounds, experience, and expertise, and expects that all 
participants will be treated with respect by all other participants.

(a)  In connection with official Forum activities, all Forum participants shall:
Be polite, kind, and courteous to other participants, refraining from insulting 
remarks on the perceived intelligence or ability of others.
Treat fellow Forum participants with respect, professionalism, courtesy, and 
reasonableness.  
Respect that people have differences of opinion, and that there is seldom 
unanimous agreement on a single “correct" answer.  Be willing to compromise and 
agree to disagree.  

(b)  Refrain from conduct such as:  
Threatening violence towards any person.  
Discriminating against anyone on the basis of personal characteristics or group 
membership.
Harassing or bullying anyone verbally, physically, or sexually.
Directly insulting or demeaning another person.  For purposes of this Code, 
“demeaning" means acting in a way that reduces another person's dignity, sense 
of self-worth or respect within the Forum. [Note: this definition is from the 
W3C Code of Ethics and Professional Conduct]
Touching another person in a physically inappropriate way. 
Deliberately intimidating or stalking another person (in-person, online, or by 
other means).
Inappropriately disrupting or impeding official Forum events, including 
meetings, talks, and presentations.  For purposes of this Code, "inappropriate 
disruption" would include aggressive, violent, and abusive conduct that 
prevents an official Forum event from proceeding.
Spamming, trolling, flaming, baiting, and other similar behavior 
inappropriately directed towards an individual.
Advocating for, or encouraging, any of the above behavior.

(c)  All Forum participants should promote the rules of this Code and take 
action to bring discussions back into compliance with the Code whenever 
violations are observed.

(d)  Forum participants should stick to ideological, conceptual discussions and 
avoid engaging in offensive or sensitive personal 

Re: [cabfpub] [EXT] Re: Ballot 199 - Require commonName in Root and Intermediate Certificates

[Geoff Keating via Public]

In this particular case, because issued certificates contain the subject name 
from the issuer, you could argue that issuance from a CA without a subject name 
is no longer allowed—7.1.4.1 says that the issuer name must match the subject 
name of the issuer (of course!), and that brings the issuer's name into scope 
at the time of issuance.  This is different from other properties of the 
issuer’s certificate, like the algorithm it is signed with or its expiry date, 
because those don’t propagate to the issued certificate.

Or not.  You can make arguments either way.

> On 4 May 2017, at 1:06 pm, Ryan Sleevi  wrote:
> 
> How so? The Ballot only applies to the profile of the issuance of 
> roots/sub-CAs, not from.
> 
> If it applied to from, the existing BRs would already rule out a number of 
> members' roots and intermediates :)
> 
> 
> On Thu, May 4, 2017 at 4:04 PM, Geoff Keating  > wrote:
> 
>> On 4 May 2017, at 12:30 pm, Ryan Sleevi via Public > > wrote:
>> 
>> Kirk raised that, but it does not seem to be a founded concern.
>> 
>> 1) That requirement applies to all certificates issued against the current 
>> BRs
>> 2) The BRs do not retroactively invalidate - or, especially in the case of 
>> Ballot 197 - approve - certificate issuance.
>> 
>> A CA has always and only been obligated to state compliance with the 
>> in-force BRs with respect to issuance and its activities.
> 
> In this context, saying the BRs apply to ‘all certificates issued’ might mean 
> that you could no longer issue a certificate against a root without a common 
> name, and so cannot renew any sub-CAs.
> 
>> On Thu, May 4, 2017 at 3:27 PM, Steve Medin via Public > > wrote:
>> Gerv, could we also request explicit forward-looking language? Kirk raised 
>> the concern about whether this applies to existing roots and intermediates. 
>> We have a root issued in 1997 that does not have a common name. Some 
>> interpretations have been discussed, but we would strongly prefer that this 
>> be written into this change for clear future interpretations.
>> 
>>  
>> 
>> If I may:
>> 
>>  
>> 
>> 7.1.4.3. Subject Information – Root Certificates and Subordinate CA 
>> Certificates
>> 
>> When issuing a Root Certificate or Subordinate CA Certificate, the CA 
>> represents that it followed the procedure set forth in its Certificate 
>> Policy and/or Certification Practice Statement to verify that, as of the 
>> Certificate’s issuance date, all of the Subject Information was accurate and 
>> included the content required by this section.
>> 
> 



smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] [EXT] Re: Ballot 199 - Require commonName in Root and Intermediate Certificates

[Ryan Sleevi via Public]

How so? The Ballot only applies to the profile of the issuance of
roots/sub-CAs, not from.

If it applied to from, the existing BRs would already rule out a number of
members' roots and intermediates :)


On Thu, May 4, 2017 at 4:04 PM, Geoff Keating  wrote:

>
> On 4 May 2017, at 12:30 pm, Ryan Sleevi via Public 
> wrote:
>
> Kirk raised that, but it does not seem to be a founded concern.
>
> 1) That requirement applies to all certificates issued against the current
> BRs
> 2) The BRs do not retroactively invalidate - or, especially in the case of
> Ballot 197 - approve - certificate issuance.
>
> A CA has always and only been obligated to state compliance with the
> in-force BRs with respect to issuance and its activities.
>
>
> In this context, saying the BRs apply to ‘all certificates issued’ might
> mean that you could no longer issue a certificate against a root without a
> common name, and so cannot renew any sub-CAs.
>
> On Thu, May 4, 2017 at 3:27 PM, Steve Medin via Public <
> public@cabforum.org> wrote:
>
>> Gerv, could we also request explicit forward-looking language? Kirk
>> raised the concern about whether this applies to existing roots and
>> intermediates. We have a root issued in 1997 that does not have a common
>> name. Some interpretations have been discussed, but we would strongly
>> prefer that this be written into this change for clear future
>> interpretations.
>>
>>
>>
>> If I may:
>>
>>
>>
>> 7.1.4.3. Subject Information – Root Certificates and Subordinate CA
>> Certificates
>>
>> When issuing a Root Certificate or Subordinate CA Certificate, the CA
>> represents that it followed the procedure set forth in its Certificate
>> Policy and/or Certification Practice Statement to verify that, as of the
>> Certificate’s issuance date, all of the Subject Information was accurate
>> and included the content required by this section.
>>
>
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] [EXT] Re: Ballot 199 - Require commonName in Root and Intermediate Certificates

[Geoff Keating via Public]

> On 4 May 2017, at 12:30 pm, Ryan Sleevi via Public  
> wrote:
> 
> Kirk raised that, but it does not seem to be a founded concern.
> 
> 1) That requirement applies to all certificates issued against the current BRs
> 2) The BRs do not retroactively invalidate - or, especially in the case of 
> Ballot 197 - approve - certificate issuance.
> 
> A CA has always and only been obligated to state compliance with the in-force 
> BRs with respect to issuance and its activities.

In this context, saying the BRs apply to ‘all certificates issued’ might mean 
that you could no longer issue a certificate against a root without a common 
name, and so cannot renew any sub-CAs.

> On Thu, May 4, 2017 at 3:27 PM, Steve Medin via Public  > wrote:
> Gerv, could we also request explicit forward-looking language? Kirk raised 
> the concern about whether this applies to existing roots and intermediates. 
> We have a root issued in 1997 that does not have a common name. Some 
> interpretations have been discussed, but we would strongly prefer that this 
> be written into this change for clear future interpretations.
> 
>  
> 
> If I may:
> 
>  
> 
> 7.1.4.3. Subject Information – Root Certificates and Subordinate CA 
> Certificates
> 
> When issuing a Root Certificate or Subordinate CA Certificate, the CA 
> represents that it followed the procedure set forth in its Certificate Policy 
> and/or Certification Practice Statement to verify that, as of the 
> Certificate’s issuance date, all of the Subject Information was accurate and 
> included the content required by this section.


smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] [EXT] Re: Ballot 199 - Require commonName in Root and Intermediate Certificates

[Jeremy Rowley via Public]

+1. I’d prefer not to explicitly state after-ballot applicability as doing so 
raises the question the question for all future ballots. If we were going to 
add language about applicability, the language should be in the scope section 
and broadly state that the BRs only apply to certificates issued after the 
effective date of the latest version. (Note, I am not proposing this)

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Ryan Sleevi via 
Public
Sent: Thursday, May 4, 2017 1:30 PM
To: CA/Browser Forum Public Discussion List 
Cc: Ryan Sleevi 
Subject: Re: [cabfpub] [EXT] Re: Ballot 199 - Require commonName in Root and 
Intermediate Certificates

 

Kirk raised that, but it does not seem to be a founded concern.

 

1) That requirement applies to all certificates issued against the current BRs

2) The BRs do not retroactively invalidate - or, especially in the case of 
Ballot 197 - approve - certificate issuance.

 

A CA has always and only been obligated to state compliance with the in-force 
BRs with respect to issuance and its activities.

 

On Thu, May 4, 2017 at 3:27 PM, Steve Medin via Public  > wrote:

Gerv, could we also request explicit forward-looking language? Kirk raised the 
concern about whether this applies to existing roots and intermediates. We have 
a root issued in 1997 that does not have a common name. Some interpretations 
have been discussed, but we would strongly prefer that this be written into 
this change for clear future interpretations.

 

If I may:

 

7.1.4.3. Subject Information – Root Certificates and Subordinate CA Certificates

When issuing a Root Certificate or Subordinate CA Certificate, the CA 
represents that it followed the procedure set forth in its Certificate Policy 
and/or Certification Practice Statement to verify that, as of the Certificate’s 
issuance date, all of the Subject Information was accurate and included the 
content required by this section.

 

 

 

From: Public [mailto:public-boun...@cabforum.org 
 ] On Behalf Of Ben Wilson via Public
Sent: Thursday, May 04, 2017 11:21 AM
To: CA/Browser Forum Public Discussion List  >
Cc: Ben Wilson  >
Subject: [EXT] Re: [cabfpub] Ballot 199 - Require commonName in Root and 
Intermediate Certificates

 

Two questions, Gerv.  

 

1 - Does this ballot rule out “vanity CAs” – CAs with customer names in the 
subject field, even though the key is held by the root CA?  (I can provide 
further clarification, and/or examples, if necessary.

2-  What is the full current wording of Ballot 199?

 

Thanks,

 

Ben 

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Gervase Markham 
via Public
Sent: Tuesday, April 25, 2017 9:03 AM
To: CABFPub  >
Cc: Gervase Markham  >
Subject: [cabfpub] Ballot 199 - Require commonName in Root and Intermediate 
Certificates

 

Ballot 199 - Require commonName in Root and Intermediate Certificates

Purpose of Ballot: Section 7.1.4.3 of the BRs, which deals with Subject 
Information for Subordinate CA Certificates, currently requires only that all 
information in a Subordinate CA Certificate is accurate; it does not say what 
information is required. Some of the necessary information is required 
elsewhere in the BRs, but it is not complete - commonName is missing. If 
commonName is omitted, DN clashes can more easily occur. So this motion 
centralises that information in the obvious place, and adds a commonName 
requirement.

The following motion has been proposed by Gervase Markham of Mozilla and 
endorsed by Patrick Tronnier of OATI and Ryan Sleevi of Google:

-- MOTION BEGINS --


Make the following changes to the Baseline Requirements: 

* Delete 7.1.2.1 (e), which currently defines the Subject Information required 
in a Root CA Certificate.
 
* Delete 7.1.2.2 (h), which currently defines the Subject Information required 
in a Subordinate CA Certificate.
 
* Rename section 7.1.4.2, currently titled "Subject Information", to "Subject 
Information - Subscriber Certificates".
 
* Rename section 7.1.4.3, currently titled "Subject Information - Subordinate 
CA Certificates" to "Subject Information - Root Certificates and Subordinate CA 
Certificates".
 
* Based on the style used in 7.1.4.2.2 and the content from the now-deleted 
7.1.2.1 (e) and 7.1.2.2 (h), add the following section 7.1.4.3.1:
 
7.1.4.3.1 Subject Distinguished Name Fields
 
Certificate Field: subject:commonName (OID 2.5.4.3)
Required/Optional: Required
Contents: This field MUST be present and the contents MUST be an identifier 
for the certificate such that the certificate's Name is unique across all 
certificates issued by the issuing certificate.
 
b. Certificate 

Re: [cabfpub] [EXT] Re: Ballot 199 - Require commonName in Root and Intermediate Certificates

[Ryan Sleevi via Public]

Kirk raised that, but it does not seem to be a founded concern.

1) That requirement applies to all certificates issued against the current
BRs
2) The BRs do not retroactively invalidate - or, especially in the case of
Ballot 197 - approve - certificate issuance.

A CA has always and only been obligated to state compliance with the
in-force BRs with respect to issuance and its activities.

On Thu, May 4, 2017 at 3:27 PM, Steve Medin via Public 
wrote:

> Gerv, could we also request explicit forward-looking language? Kirk raised
> the concern about whether this applies to existing roots and intermediates.
> We have a root issued in 1997 that does not have a common name. Some
> interpretations have been discussed, but we would strongly prefer that this
> be written into this change for clear future interpretations.
>
>
>
> If I may:
>
>
>
> 7.1.4.3. Subject Information – Root Certificates and Subordinate CA
> Certificates
>
> When issuing a Root Certificate or Subordinate CA Certificate, the CA
> represents that it followed the procedure set forth in its Certificate
> Policy and/or Certification Practice Statement to verify that, as of the
> Certificate’s issuance date, all of the Subject Information was accurate
> and included the content required by this section.
>
>
>
>
>
>
>
> *From:* Public [mailto:public-boun...@cabforum.org] *On Behalf Of *Ben
> Wilson via Public
> *Sent:* Thursday, May 04, 2017 11:21 AM
> *To:* CA/Browser Forum Public Discussion List 
> *Cc:* Ben Wilson 
> *Subject:* [EXT] Re: [cabfpub] Ballot 199 - Require commonName in Root
> and Intermediate Certificates
>
>
>
> Two questions, Gerv.
>
>
>
> 1 - Does this ballot rule out “vanity CAs” – CAs with customer names in
> the subject field, even though the key is held by the root CA?  (I can
> provide further clarification, and/or examples, if necessary.
>
> 2-  What is the full current wording of Ballot 199?
>
>
>
> Thanks,
>
>
>
> Ben
>
>
>
> *From:* Public [mailto:public-boun...@cabforum.org
> ] *On Behalf Of *Gervase Markham via Public
> *Sent:* Tuesday, April 25, 2017 9:03 AM
> *To:* CABFPub 
> *Cc:* Gervase Markham 
> *Subject:* [cabfpub] Ballot 199 - Require commonName in Root and
> Intermediate Certificates
>
>
>
> *Ballot 199 - Require commonName in Root and Intermediate Certificates*
>
> *Purpose of Ballot: *Section 7.1.4.3 of the BRs, which deals with Subject
> Information for Subordinate CA Certificates, currently requires only that
> all information in a Subordinate CA Certificate is accurate; it does not
> say what information is required. Some of the necessary information is
> required elsewhere in the BRs, but it is not complete - commonName is
> missing. If commonName is omitted, DN clashes can more easily occur. So
> this motion centralises that information in the obvious place, and adds a
> commonName requirement.
>
> The following motion has been proposed by Gervase Markham of Mozilla and
> endorsed by Patrick Tronnier of OATI and Ryan Sleevi of Google:
>
> -- MOTION BEGINS --
>
>
> Make the following changes to the Baseline Requirements:
>
> * Delete 7.1.2.1 (e), which currently defines the Subject Information 
> required in a Root CA Certificate.
>
>
>
> * Delete 7.1.2.2 (h), which currently defines the Subject Information 
> required in a Subordinate CA Certificate.
>
>
>
> * Rename section 7.1.4.2, currently titled "Subject Information", to "Subject 
> Information - Subscriber Certificates".
>
>
>
> * Rename section 7.1.4.3, currently titled "Subject Information - Subordinate 
> CA Certificates" to "Subject Information - Root Certificates and Subordinate 
> CA Certificates".
>
>
>
> * Based on the style used in 7.1.4.2.2 and the content from the now-deleted 
> 7.1.2.1 (e) and 7.1.2.2 (h), add the following section 7.1.4.3.1:
>
>
>
> 7.1.4.3.1 Subject Distinguished Name Fields
>
>
>
> Certificate Field: subject:commonName (OID 2.5.4.3)
>
> Required/Optional: Required
>
> Contents: This field MUST be present and the contents MUST be an identifier
>
> for the certificate such that the certificate's Name is unique across all
>
> certificates issued by the issuing certificate.
>
>
>
> b. Certificate Field: subject:organizationName (OID 2.5.4.10)
>
> Required/Optional: Required
>
> Contents: This field MUST be present and the contents MUST contain
>
> either the Subject CA’s name or DBA as verified under Section 3.2.2.2.
>
> The CA may include information in this field that differs slightly from
>
> the verified name, such as common variations or abbreviations,  provided
>
> that the CA documents the difference and any abbreviations used are
>
> locally accepted abbreviations; e.g., if the official record shows
>
> “Company Name Incorporated”, the CA MAY use “Company Name Inc.” or
>
> “Company Name”.
>
>
>
> c. Certificate Field: subject:countryName (OID: 2.5.4.6)
>
> Required/Optional: 

Re: [cabfpub] [EXT] Re: Ballot 199 - Require commonName in Root and Intermediate Certificates

[Steve Medin via Public]

Gerv, could we also request explicit forward-looking language? Kirk raised the 
concern about whether this applies to existing roots and intermediates. We have 
a root issued in 1997 that does not have a common name. Some interpretations 
have been discussed, but we would strongly prefer that this be written into 
this change for clear future interpretations.



If I may:



7.1.4.3. Subject Information – Root Certificates and Subordinate CA Certificates

When issuing a Root Certificate or Subordinate CA Certificate, the CA 
represents that it followed the procedure set forth in its Certificate Policy 
and/or Certification Practice Statement to verify that, as of the Certificate’s 
issuance date, all of the Subject Information was accurate and included the 
content required by this section.







From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Ben Wilson via 
Public
Sent: Thursday, May 04, 2017 11:21 AM
To: CA/Browser Forum Public Discussion List 
Cc: Ben Wilson 
Subject: [EXT] Re: [cabfpub] Ballot 199 - Require commonName in Root and 
Intermediate Certificates



Two questions, Gerv.



1 - Does this ballot rule out “vanity CAs” – CAs with customer names in the 
subject field, even though the key is held by the root CA?  (I can provide 
further clarification, and/or examples, if necessary.

2-  What is the full current wording of Ballot 199?



Thanks,



Ben



From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Gervase Markham 
via Public
Sent: Tuesday, April 25, 2017 9:03 AM
To: CABFPub >
Cc: Gervase Markham >
Subject: [cabfpub] Ballot 199 - Require commonName in Root and Intermediate 
Certificates



Ballot 199 - Require commonName in Root and Intermediate Certificates

Purpose of Ballot: Section 7.1.4.3 of the BRs, which deals with Subject 
Information for Subordinate CA Certificates, currently requires only that all 
information in a Subordinate CA Certificate is accurate; it does not say what 
information is required. Some of the necessary information is required 
elsewhere in the BRs, but it is not complete - commonName is missing. If 
commonName is omitted, DN clashes can more easily occur. So this motion 
centralises that information in the obvious place, and adds a commonName 
requirement.

The following motion has been proposed by Gervase Markham of Mozilla and 
endorsed by Patrick Tronnier of OATI and Ryan Sleevi of Google:

-- MOTION BEGINS --


Make the following changes to the Baseline Requirements:

* Delete 7.1.2.1 (e), which currently defines the Subject Information required 
in a Root CA Certificate.

* Delete 7.1.2.2 (h), which currently defines the Subject Information required 
in a Subordinate CA Certificate.

* Rename section 7.1.4.2, currently titled "Subject Information", to "Subject 
Information - Subscriber Certificates".

* Rename section 7.1.4.3, currently titled "Subject Information - Subordinate 
CA Certificates" to "Subject Information - Root Certificates and Subordinate CA 
Certificates".

* Based on the style used in 7.1.4.2.2 and the content from the now-deleted 
7.1.2.1 (e) and 7.1.2.2 (h), add the following section 7.1.4.3.1:

7.1.4.3.1 Subject Distinguished Name Fields

Certificate Field: subject:commonName (OID 2.5.4.3)
Required/Optional: Required
Contents: This field MUST be present and the contents MUST be an identifier
for the certificate such that the certificate's Name is unique across all
certificates issued by the issuing certificate.

b. Certificate Field: subject:organizationName (OID 2.5.4.10)
Required/Optional: Required
Contents: This field MUST be present and the contents MUST contain
either the Subject CA’s name or DBA as verified under Section 3.2.2.2.
The CA may include information in this field that differs slightly from
the verified name, such as common variations or abbreviations,  provided
that the CA documents the difference and any abbreviations used are
locally accepted abbreviations; e.g., if the official record shows
“Company Name Incorporated”, the CA MAY use “Company Name Inc.” or
“Company Name”.

c. Certificate Field: subject:countryName (OID: 2.5.4.6)
Required/Optional: Required
Contents: This field MUST contain the two‐letter ISO 3166‐1 country code
for the country in which the CA’s place of business is located.

-- MOTION ENDS --



The procedure for approval of this Final Maintenance Guideline ballot is as 
follows (exact start and end times may be adjusted to comply with applicable 
Bylaws and IPR Agreement):



BALLOT 199

Status: Final Maintenance Guideline

Start time (23:00 UTC)

End time (23:00 UTC)

Discussion (7 to 14 days)

25 Apr

2 May

Vote for approval (7 days)

2 May

9 May

If vote approves ballot: Review Period (Chair to send Review Notice) (30 days).

If Exclusion Notice(s) filed, ballot approval is rescinded and PAG to be 
created.

If no Exclusion Notices 

Re: [cabfpub] Ballot 198 - Onion Revisions v2

[Erwann Abalea via Public]

DocuSign France votes YES.

Cordialement,
Erwann Abalea

Le 4 mai 2017 à 02:28, Jeremy Rowley via Public 
> a écrit :

This ballot is now in voting.

Ballot 198 – .Onion Revisions

Appendix F of the EV Guidelines in unclear on what a CA does with the Tor 
Service Descriptor Hash extension. This ballot clarifies that inclusion of the 
extension in the TBSCertificate is required.

The following motion has been proposed by Jeremy Rowley of DigiCert and 
endorsed by Ryan Sleevi of Google and Erwann Abalea of DocuSign France to 
introduce new Final Maintenance Guidelines for the "Guidelines for the Issuance 
and Management of Extended Validation Certificates" (EV Guidelines).

-- MOTION BEGINS –

Revise Appendix F, Section 1 to read as follows:
Appendix F – Issuance of Certificates for .onion Domain Names
A CA may issue an EV Certificate containing the .onion 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 extension in of the TBSCertificate to convey hashes of keys 
related to .onion addresses.  The CA MUST include the Tor Service Descriptor 
Hash extension using the following format:
cabf-TorServiceDescriptorHash OBJECT IDENTIFIER ::= { 2.23.140.1.31 }
TorServiceDescriptorHash:: = SEQUENCE {
algorithmAlgorithmIdentifier
subjectPublicKeyHash   BIT STRING  }
Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 6234) 
performed over the raw Public Key of the .onion service and 
SubjectPublicKeyHash is the value of the hash output of the raw Public Key.

--Motion Ends--

The procedure for approval of this Final Maintenance Guideline ballot is as 
follows (exact start and end times may be adjusted to comply with applicable 
Bylaws and IPR Agreement):

BALLOT 198 Status: Final Maintenance Guideline

Start time (22:00 UTC)

End time (22:00 UTC)

Discussion (7 to 14 days)

April 24, 2017

May, 2017

Vote for approval (7 days)

May 1, 2017

May 8, 2017

If vote approves ballot: Review Period (Chair to send Review Notice) (30 days). 
If Exclusion Notice(s) filed, ballot approval is rescinded and PAG to be 
created. If no Exclusion Notices filed, ballot becomes effective at end of 
Review Period.

Upon filing of Review Notice by Chair

30 days after filing of Review Notice by Chair


From Bylaw 2.3: If the Draft Guideline Ballot is proposing a Final Maintenance 
Guideline, such ballot will include a redline or comparison showing the set of 
changes from the Final Guideline section(s) intended to become a Final 
Maintenance Guideline, and need not include a copy of the full set of 
guidelines. Such redline or comparison shall be made against the Final 
Guideline section(s) as they exist at the time a ballot is proposed, and need 
not take into consideration other ballots that may be proposed subsequently, 
except as provided in Bylaw Section 2.3(j).

Votes must be cast by posting an on-list reply to this thread on the Public 
list. 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 shown on CA/Browser Forum 
wiki. Under Bylaw 2.2(g), at least the required quorum number must participate 
in the ballot for the ballot to be valid, either by voting in favor, voting 
against, or abstaining.


___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Ballot 198 - Onion Revisions v2

[Bruce Morton via Public]

Entrust vote Yes.
Bruce.
From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Jeremy Rowley 
via Public
Sent: Wednesday, May 3, 2017 8:29 PM
To: CA/Browser Forum Public Discussion List 
Cc: Jeremy Rowley 
Subject: [EXTERNAL]Re: [cabfpub] Ballot 198 - Onion Revisions v2

This ballot is now in voting.

Ballot 198 - .Onion Revisions

Appendix F of the EV Guidelines in unclear on what a CA does with the Tor 
Service Descriptor Hash extension. This ballot clarifies that inclusion of the 
extension in the TBSCertificate is required.

The following motion has been proposed by Jeremy Rowley of DigiCert and 
endorsed by Ryan Sleevi of Google and Erwann Abalea of DocuSign France to 
introduce new Final Maintenance Guidelines for the "Guidelines for the Issuance 
and Management of Extended Validation Certificates" (EV Guidelines).

-- MOTION BEGINS -

Revise Appendix F, Section 1 to read as follows:
Appendix F - Issuance of Certificates for .onion Domain Names
A CA may issue an EV Certificate containing the .onion 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 extension in of the TBSCertificate to convey hashes of keys 
related to .onion addresses.  The CA MUST include the Tor Service Descriptor 
Hash extension using the following format:
cabf-TorServiceDescriptorHash OBJECT IDENTIFIER ::= { 2.23.140.1.31 }
TorServiceDescriptorHash:: = SEQUENCE {
algorithmAlgorithmIdentifier
subjectPublicKeyHash   BIT STRING  }
Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 6234) 
performed over the raw Public Key of the .onion service and 
SubjectPublicKeyHash is the value of the hash output of the raw Public Key.

--Motion Ends--

The procedure for approval of this Final Maintenance Guideline ballot is as 
follows (exact start and end times may be adjusted to comply with applicable 
Bylaws and IPR Agreement):

BALLOT 198 Status: Final Maintenance Guideline


Start time (22:00 UTC)


End time (22:00 UTC)


Discussion (7 to 14 days)


April 24, 2017


May, 2017


Vote for approval (7 days)


May 1, 2017


May 8, 2017


If vote approves ballot: Review Period (Chair to send Review Notice) (30 days). 
If Exclusion Notice(s) filed, ballot approval is rescinded and PAG to be 
created. If no Exclusion Notices filed, ballot becomes effective at end of 
Review Period.


Upon filing of Review Notice by Chair


30 days after filing of Review Notice by Chair


>From Bylaw 2.3: If the Draft Guideline Ballot is proposing a Final Maintenance 
>Guideline, such ballot will include a redline or comparison showing the set of 
>changes from the Final Guideline section(s) intended to become a Final 
>Maintenance Guideline, and need not include a copy of the full set of 
>guidelines. Such redline or comparison shall be made against the Final 
>Guideline section(s) as they exist at the time a ballot is proposed, and need 
>not take into consideration other ballots that may be proposed subsequently, 
>except as provided in Bylaw Section 2.3(j).

Votes must be cast by posting an on-list reply to this thread on the Public 
list. 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 shown on CA/Browser Forum 
wiki. Under Bylaw 2.2(g), at least the required quorum number must participate 
in the ballot for the ballot to be valid, either by voting in favor, voting 
against, or abstaining.


___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Ballot 199 - Require commonName in Root and Intermediate Certificates

[Ben Wilson via Public]

Two questions, Gerv.  

 

1 - Does this ballot rule out “vanity CAs” – CAs with customer names in the 
subject field, even though the key is held by the root CA?  (I can provide 
further clarification, and/or examples, if necessary.

2-  What is the full current wording of Ballot 199?

 

Thanks,

 

Ben 

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Gervase Markham 
via Public
Sent: Tuesday, April 25, 2017 9:03 AM
To: CABFPub 
Cc: Gervase Markham 
Subject: [cabfpub] Ballot 199 - Require commonName in Root and Intermediate 
Certificates

 

Ballot 199 - Require commonName in Root and Intermediate Certificates

Purpose of Ballot: Section 7.1.4.3 of the BRs, which deals with Subject 
Information for Subordinate CA Certificates, currently requires only that all 
information in a Subordinate CA Certificate is accurate; it does not say what 
information is required. Some of the necessary information is required 
elsewhere in the BRs, but it is not complete - commonName is missing. If 
commonName is omitted, DN clashes can more easily occur. So this motion 
centralises that information in the obvious place, and adds a commonName 
requirement.

The following motion has been proposed by Gervase Markham of Mozilla and 
endorsed by Patrick Tronnier of OATI and Ryan Sleevi of Google:



-- MOTION BEGINS --


Make the following changes to the Baseline Requirements: 

* Delete 7.1.2.1 (e), which currently defines the Subject Information required 
in a Root CA Certificate.
 
* Delete 7.1.2.2 (h), which currently defines the Subject Information required 
in a Subordinate CA Certificate.
 
* Rename section 7.1.4.2, currently titled "Subject Information", to "Subject 
Information - Subscriber Certificates".
 
* Rename section 7.1.4.3, currently titled "Subject Information - Subordinate 
CA Certificates" to "Subject Information - Root Certificates and Subordinate CA 
Certificates".
 
* Based on the style used in 7.1.4.2.2 and the content from the now-deleted 
7.1.2.1 (e) and 7.1.2.2 (h), add the following section 7.1.4.3.1:
 
7.1.4.3.1 Subject Distinguished Name Fields
 
Certificate Field: subject:commonName (OID 2.5.4.3)
Required/Optional: Required
Contents: This field MUST be present and the contents MUST be an identifier 
for the certificate such that the certificate's Name is unique across all 
certificates issued by the issuing certificate.
 
b. Certificate Field: subject:organizationName (OID 2.5.4.10)
Required/Optional: Required
Contents: This field MUST be present and the contents MUST contain
either the Subject CA’s name or DBA as verified under Section 3.2.2.2.
The CA may include information in this field that differs slightly from
the verified name, such as common variations or abbreviations,  provided
that the CA documents the difference and any abbreviations used are
locally accepted abbreviations; e.g., if the official record shows
“Company Name Incorporated”, the CA MAY use “Company Name Inc.” or
“Company Name”.
 
c. Certificate Field: subject:countryName (OID: 2.5.4.6)
Required/Optional: Required
Contents: This field MUST contain the two‐letter ISO 3166‐1 country code
for the country in which the CA’s place of business is located.

-- MOTION ENDS -- 

 

The procedure for approval of this Final Maintenance Guideline ballot is as 
follows (exact start and end times may be adjusted to comply with applicable 
Bylaws and IPR Agreement):

 


BALLOT 199

Status: Final Maintenance Guideline

Start time (23:00 UTC)

End time (23:00 UTC)


Discussion (7 to 14 days)

25 Apr

2 May


Vote for approval (7 days)

2 May

9 May


If vote approves ballot: Review Period (Chair to send Review Notice) (30 days). 
 

If Exclusion Notice(s) filed, ballot approval is rescinded and PAG to be 
created.

If no Exclusion Notices filed, ballot becomes effective at end of Review Period.

Upon filing of Review Notice by Chair

30 days after filing of Review Notice by Chair

 

>From Bylaw 2.3: If the Draft Guideline Ballot is proposing a Final Maintenance 
>Guideline, such ballot will include a redline or comparison showing the set of 
>changes from the Final Guideline section(s) intended to become a Final 
>Maintenance Guideline, and need not include a copy of the full set of 
>guidelines.  Such redline or comparison shall be made against the Final 
>Guideline section(s) as they exist at the time a ballot is proposed, and need 
>not take into consideration other ballots that may be proposed subsequently, 
>except as provided in Bylaw Section 2.3(j).

 

Votes must be cast by posting an on-list reply to this thread on the Public 
list.  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 

Re: [cabfpub] Ballot 198 - Onion Revisions v2

[Dimitris Zacharopoulos via Public]

HARICA votes "yes" to ballot 198.

Dimitris.

On 24/4/2017 8:29 μμ, Jeremy Rowley via Public wrote:


Apparently May comes after April, not March.

Ballot 198 – .Onion Revisions

Appendix F of the EV Guidelines in unclear on what a CA does with the 
Tor Service Descriptor Hash extension. This ballot clarifies that 
inclusion of the extension in the TBSCertificate is required.


The following motion has been proposed by Jeremy Rowley of DigiCert 
and endorsed by Ryan Sleevi of Google and Erwann Abalea of DocuSign 
France to introduce new Final Maintenance Guidelines for the 
"Guidelines for the Issuance and Management of Extended Validation 
Certificates" (EV Guidelines).


-- MOTION BEGINS –

Revise Appendix F, Section 1 to read as follows:

*Appendix F – Issuance of Certificates for .onion Domain Names*

A CA may issue an EV Certificate containing the .onion 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 extension in of the TBSCertificate to convey hashes of 
keys related to .onion addresses.  The CA MUST include the Tor Service 
Descriptor Hash extension using the following format:


cabf-TorServiceDescriptorHash OBJECT IDENTIFIER ::= { 2.23.140.1.31 }

TorServiceDescriptorHash:: = SEQUENCE {

algorithm  AlgorithmIdentifier

subjectPublicKeyHash BIT STRING  }

Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 
6234) performed over the raw Public Key of the .onion service and 
SubjectPublicKeyHash is the value of the hash output of the raw Public 
Key.


--Motion Ends--

The procedure for approval of this Final Maintenance Guideline ballot 
is as follows (exact start and end times may be adjusted to comply 
with applicable Bylaws and IPR Agreement):


BALLOT 198 Status: Final Maintenance Guideline



Start time (22:00 UTC)



End time (22:00 UTC)

Discussion (7 to 14 days)



April 24, 2017



May, 2017

Vote for approval (7 days)



May 1, 2017



May 8, 2017

If vote approves ballot: Review Period (Chair to send Review Notice) 
(30 days). If Exclusion Notice(s) filed, ballot approval is rescinded 
and PAG to be created. If no Exclusion Notices filed, ballot becomes 
effective at end of Review Period.




Upon filing of Review Notice by Chair



30 days after filing of Review Notice by Chair

From Bylaw 2.3: If the Draft Guideline Ballot is proposing a Final 
Maintenance Guideline, such ballot will include a redline or 
comparison showing the set of changes from the Final Guideline 
section(s) intended to become a Final Maintenance Guideline, and need 
not include a copy of the full set of guidelines. Such redline or 
comparison shall be made against the Final Guideline section(s) as 
they exist at the time a ballot is proposed, and need not take into 
consideration other ballots that may be proposed subsequently, except 
as provided in Bylaw Section 2.3(j).


Votes must be cast by posting an on-list reply to this thread on the 
Public list. 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 
shown on CA/Browser Forum wiki. Under Bylaw 2.2(g), at least the 
required quorum number must participate in the ballot for the ballot 
to be valid, either by voting in favor, voting against, or abstaining.


**



___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public


___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Ballot 198 - Onion Revisions v2

[Michael Markevich via Public]

Opera votes YES.

On 24 April 2017 at 19:29, Jeremy Rowley via Public 
wrote:

> Apparently May comes after April, not March.
>
> Ballot 198 – .Onion Revisions
>
> Appendix F of the EV Guidelines in unclear on what a CA does with the Tor
> Service Descriptor Hash extension. This ballot clarifies that inclusion of
> the extension in the TBSCertificate is required.
>
> The following motion has been proposed by Jeremy Rowley of DigiCert and
> endorsed by Ryan Sleevi of Google and Erwann Abalea of DocuSign France to
> introduce new Final Maintenance Guidelines for the "Guidelines for the
> Issuance and Management of Extended Validation Certificates" (EV
> Guidelines).
>
> -- MOTION BEGINS –
>
> Revise Appendix F, Section 1 to read as follows:
>
> *Appendix F – Issuance of Certificates for .onion Domain Names*
>
> A CA may issue an EV Certificate containing the .onion 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 extension in of the TBSCertificate to convey hashes of keys
> related to .onion addresses.  The CA MUST include the Tor Service
> Descriptor Hash extension using the following format:
>
> cabf-TorServiceDescriptorHash OBJECT IDENTIFIER ::= { 2.23.140.1.31 }
>
> TorServiceDescriptorHash:: = SEQUENCE {
>
> algorithmAlgorithmIdentifier
>
> subjectPublicKeyHash   BIT STRING  }
>
> Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 6234)
> performed over the raw Public Key of the .onion service and
> SubjectPublicKeyHash is the value of the hash output of the raw Public Key.
>
> --Motion Ends--
>
> The procedure for approval of this Final Maintenance Guideline ballot is
> as follows (exact start and end times may be adjusted to comply with
> applicable Bylaws and IPR Agreement):
>
> BALLOT 198 Status: Final Maintenance Guideline
>
> Start time (22:00 UTC)
>
> End time (22:00 UTC)
>
> Discussion (7 to 14 days)
>
> April 24, 2017
>
> May, 2017
>
> Vote for approval (7 days)
>
> May 1, 2017
>
> May 8, 2017
>
> If vote approves ballot: Review Period (Chair to send Review Notice) (30
> days). If Exclusion Notice(s) filed, ballot approval is rescinded and PAG
> to be created. If no Exclusion Notices filed, ballot becomes effective at
> end of Review Period.
>
> Upon filing of Review Notice by Chair
>
> 30 days after filing of Review Notice by Chair
>
> From Bylaw 2.3: If the Draft Guideline Ballot is proposing a Final
> Maintenance Guideline, such ballot will include a redline or comparison
> showing the set of changes from the Final Guideline section(s) intended to
> become a Final Maintenance Guideline, and need not include a copy of the
> full set of guidelines. Such redline or comparison shall be made against
> the Final Guideline section(s) as they exist at the time a ballot is
> proposed, and need not take into consideration other ballots that may be
> proposed subsequently, except as provided in Bylaw Section 2.3(j).
>
> Votes must be cast by posting an on-list reply to this thread on the
> Public list. 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 shown on
> CA/Browser Forum wiki. Under Bylaw 2.2(g), at least the required quorum
> number must participate in the ballot for the ballot to be valid, either by
> voting in favor, voting against, or abstaining.
>
>
>
>
>
> ___
> Public mailing list
> Public@cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>


-- 
Michael Markevich
Head of Security and Privacy
Opera Software
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Ballot 198 - Onion Revisions v2

[N. Atilla Biler via Public]

TURKTRUST abstains.

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Jeremy Rowley
via Public
Sent: 4 Mayıs 2017 Perşembe 03:29
To: CA/Browser Forum Public Discussion List 
Cc: Jeremy Rowley 
Subject: Re: [cabfpub] Ballot 198 - Onion Revisions v2

 

This ballot is now in voting. 

Ballot 198 - .Onion Revisions

Appendix F of the EV Guidelines in unclear on what a CA does with the Tor
Service Descriptor Hash extension. This ballot clarifies that inclusion of
the extension in the TBSCertificate is required. 

The following motion has been proposed by Jeremy Rowley of DigiCert and
endorsed by Ryan Sleevi of Google and Erwann Abalea of DocuSign France to
introduce new Final Maintenance Guidelines for the "Guidelines for the
Issuance and Management of Extended Validation Certificates" (EV
Guidelines).

-- MOTION BEGINS -

Revise Appendix F, Section 1 to read as follows:

Appendix F - Issuance of Certificates for .onion Domain Names

A CA may issue an EV Certificate containing the .onion 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 extension in of the TBSCertificate to convey hashes of keys
related to .onion addresses.  The CA MUST include the Tor Service Descriptor
Hash extension using the following format:

cabf-TorServiceDescriptorHash OBJECT IDENTIFIER ::= { 2.23.140.1.31 }

TorServiceDescriptorHash:: = SEQUENCE { 

algorithmAlgorithmIdentifier

subjectPublicKeyHash   BIT STRING  }

Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 6234)
performed over the raw Public Key of the .onion service and
SubjectPublicKeyHash is the value of the hash output of the raw Public Key.

--Motion Ends--

The procedure for approval of this Final Maintenance Guideline ballot is as
follows (exact start and end times may be adjusted to comply with applicable
Bylaws and IPR Agreement):


BALLOT 198 Status: Final Maintenance Guideline

Start time (22:00 UTC)

End time (22:00 UTC)


Discussion (7 to 14 days)

April 24, 2017

May, 2017


Vote for approval (7 days)

May 1, 2017

May 8, 2017


If vote approves ballot: Review Period (Chair to send Review Notice) (30
days). If Exclusion Notice(s) filed, ballot approval is rescinded and PAG to
be created. If no Exclusion Notices filed, ballot becomes effective at end
of Review Period.

Upon filing of Review Notice by Chair

30 days after filing of Review Notice by Chair

>From Bylaw 2.3: If the Draft Guideline Ballot is proposing a Final
Maintenance Guideline, such ballot will include a redline or comparison
showing the set of changes from the Final Guideline section(s) intended to
become a Final Maintenance Guideline, and need not include a copy of the
full set of guidelines. Such redline or comparison shall be made against the
Final Guideline section(s) as they exist at the time a ballot is proposed,
and need not take into consideration other ballots that may be proposed
subsequently, except as provided in Bylaw Section 2.3(j).

Votes must be cast by posting an on-list reply to this thread on the Public
list. 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 shown on
CA/Browser Forum wiki. Under Bylaw 2.2(g), at least the required quorum
number must participate in the ballot for the ballot to be valid, either by
voting in favor, voting against, or abstaining. 

 

 

___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Ballot 198 - Onion Revisions v2

[García Jimeno , Oscar via Public]

Izenpe abstains
.eus gara !
horregatik orain nire helbide elektronikoa da:
por eso mi dirección de correo electrónico ahora es:  
o-gar...@izenpe.eus

Oscar García
CISSP, CISM

[Descripción: Descripción: firma_email_Izenpe_eus]



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 [mailto:public-boun...@cabforum.org] En nombre de Jeremy Rowley via 
Public
Enviado el: lunes, 24 de abril de 2017 19:29
Para: CA/Browser Forum Public Discussion List
CC: Jeremy Rowley
Asunto: [cabfpub] Ballot 198 - Onion Revisions v2

Apparently May comes after April, not March.

Ballot 198 – .Onion Revisions

Appendix F of the EV Guidelines in unclear on what a CA does with the Tor 
Service Descriptor Hash extension. This ballot clarifies that inclusion of the 
extension in the TBSCertificate is required.

The following motion has been proposed by Jeremy Rowley of DigiCert and 
endorsed by Ryan Sleevi of Google and Erwann Abalea of DocuSign France to 
introduce new Final Maintenance Guidelines for the "Guidelines for the Issuance 
and Management of Extended Validation Certificates" (EV Guidelines).

-- MOTION BEGINS –

Revise Appendix F, Section 1 to read as follows:
Appendix F – Issuance of Certificates for .onion Domain Names
A CA may issue an EV Certificate containing the .onion 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 extension in of the TBSCertificate to convey hashes of keys 
related to .onion addresses.  The CA MUST include the Tor Service Descriptor 
Hash extension using the following format:
cabf-TorServiceDescriptorHash OBJECT IDENTIFIER ::= { 2.23.140.1.31 }
TorServiceDescriptorHash:: = SEQUENCE {
algorithmAlgorithmIdentifier
subjectPublicKeyHash   BIT STRING  }
Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 6234) 
performed over the raw Public Key of the .onion service and 
SubjectPublicKeyHash is the value of the hash output of the raw Public Key.

--Motion Ends--

The procedure for approval of this Final Maintenance Guideline ballot is as 
follows (exact start and end times may be adjusted to comply with applicable 
Bylaws and IPR Agreement):

BALLOT 198 Status: Final Maintenance Guideline


Start time (22:00 UTC)


End time (22:00 UTC)


Discussion (7 to 14 days)


April 24, 2017


May, 2017


Vote for approval (7 days)


May 1, 2017


May 8, 2017


If vote approves ballot: Review Period (Chair to send Review Notice) (30 days). 
If Exclusion Notice(s) filed, ballot approval is rescinded and PAG to be 
created. If no Exclusion Notices filed, ballot becomes effective at end of 
Review Period.


Upon filing of Review Notice by Chair


30 days after filing of Review Notice by Chair


>From Bylaw 2.3: If the Draft Guideline Ballot is proposing a Final Maintenance 
>Guideline, such ballot will include a redline or comparison showing the set of 
>changes from the Final Guideline section(s) intended to become a Final 
>Maintenance Guideline, and need not include a copy of the full set of 
>guidelines. Such redline or comparison shall be made against the Final 
>Guideline section(s) as they exist at the time a ballot is proposed, and need 
>not take into consideration other ballots that may be proposed subsequently, 
>except as provided in Bylaw Section 2.3(j).

Votes must be cast by posting an on-list reply to this thread on the Public 
list. 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 shown on CA/Browser Forum 
wiki. Under Bylaw 2.2(g), at least the required quorum number must participate 
in the ballot for the ballot to be valid, either by voting in favor, voting 
against, or abstaining.


___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Ballot 198 - Onion Revisions v2

[Gervase Markham via Public]

On 04/05/17 01:28, Jeremy Rowley via Public wrote:
> Ballot 198 – .Onion Revisions

Mozilla votes YES.

Gerv
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public