[cabfpub] Voting has started on Ballot 191 - Clarify Place of Business Information

[Kirk Hall via Public]

The revised ballot is below.  Voting ends on May 23, 2017 at 22:00 UTC.

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Jeremy Rowley 
via Public
Sent: Thursday, May 11, 2017 9:51 AM
To: CA/Browser Forum Public Discussion List 
Cc: Jeremy Rowley 
Subject: [cabfpub] Ballot 191 - Clarify Place of Business Information

Updated:


Ballot 191 - Clarify Place of Business Information Field Inclusion

The current EV Guidelines are not clear on what address information is required 
in a certificate. This ballot clarifies the requirements and harmonizes the EV 
Guidelines and Baseline Requirements.

The following motion has been proposed by Bruce Morton of Entrust and endorsed 
by Jeremy Rowley of DigiCert and Robin Alden of Comodo:

--Motion Begins--

A. Modify Section 9.2.7 of the EV Guidelines as follows:

9.2.7. Subject Physical Address of Place of Business Field

Certificate fields:

Number and street: subject:streetAddress (OID: 2.5.4.9)

City or town: subject:localityName (OID: 2.5.4.7)

State or province (where applicable): subject:stateOrProvinceName (OID: 2.5.4.8)

Country: subject:countryName (OID: 2.5.4.6)

Postal code: subject:postalCode (OID: 2.5.4.17)

Required/Optional: --(City, State, and country - Required; Street and postal 
code - Optional)--__As stated in Section 7.1.4.2.2 d, e, f, g and h of the 
Baseline Requirements__

Contents: This field MUST contain the address of the physical location of the 
Subject's Place of Business.

--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 191 Status: Final Maintenance Guideline


Start time (22:00 UTC)


End time (22:00 UTC)


Discussion (7 to 14 days)


9 May 2017


16 May 2017


Vote for approval (7 days)


16 May 2017


23 May 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

[cabfpub] Ballot 200 - Amendment of Bylaws to add Code of Conduct

[Virginia Fournier via Public]

Ballot 200

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

The following motion has been proposed by Virginia Fournier of Apple and 
endorsed by Gervase Markham of Mozilla and Tarah Wheeler of Symantec.

—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)  In connection with official Forum activities, all Forum participants shall 
refrain from conduct such as:  
Threatening violence towards anyone.  
Discriminating against anyone on the basis of personal characteristics or group 
membership.
Harassing or bullying anyone verbally, physically, or sexually.
Launching barbs at others.  [Note:  a “barb” is an obviously or openly 
unpleasant or carping remark.]
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 occurring or 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 discussions, particularly if 
they're off-topic; such personal discussions can lead to unnecessary arguments, 
hurt feelings, and damaged trust. 

II.  Moderation.  These are the policies for upholding the Code.

(a) Resist the urge to be defensive.  Remember that it's your responsibility to 
clearly communicate your message to your fellow participants. Everyone wants to 
get along and we are all in the Forum first and foremost because we want to 
talk about standards and everything that involves. Other participants will be 
eager to assume good intent and forgive as long as you have earned their trust.

(b)  Participants should inform the Chair, Vice Chair, and/or a Working Group 
Chair immediately if they feel they have been, or are being, harassed or made 
uncomfortable by a Forum member. Intimidation, personal attacks, and 
retaliation of any kind will not be tolerated. 

(c)  Any Forum participant may report, in good faith, a perceived violation of 
the Code to the Forum Chair or Vice Chair, or to a Working Group Chair (each, a 
“Code Liaison”).  One or more Code Liaison(s) will work with the reported Forum 
participant to determine whether a violation of the Code has occurred and, if 
so, how to resolve it. 

Re: [cabfpub] Revised Notice of Review Period - Ballot 198 - .Onion Revisions

[Geoff Keating via Public]

The ‘ballot’ is the thing that includes the ‘redline or comparison’, bylaws 
section 2.3(a).  If it doesn’t have one of those, it’s not a ballot.  So the 
redline is definitely part of the ballot and if there’s some confusion it can 
be consulted to make it clear what change was voted on.

In addition, the redline has to be against a specific version of the 
guidelines.  If that wasn’t done properly, to the point where there’s a 
question as to what the ballot means or where votes might have been made based 
on the incorrect information, then I’d think the ballot would be invalid.

> On 16 May 2017, at 1:15 pm, Ryan Sleevi via Public  
> wrote:
> 
> Yup. I'm curious for Apple's and Amazon's feedback, since they've been most 
> active in bylaw discussions :)
> 
> We've got several paths to clear this up, hence my straw poll outlining 
> options I could think of that would allow us to do so (trying to do so w/in 2 
> weeks - e.g. prior to the IP Review period expiring)
> 
> On Tue, May 16, 2017 at 3:44 PM, Ben Wilson  > wrote:
> I think the end goal is to have a version 1.6.3 of the EV Guidelines with the 
> language indicated in the redlined version of Appendix F that I circulated a 
> short while ago.  So I’d prefer that we find there was no ambiguity and that 
> Kirk start the review period over with the correct language and we call that 
> good, but of course the cleanest route would be that Ballot 198 be declared 
> defective because of ambiguity and a new ballot be presented for a new vote.  
> Fortunately this issue only affects the EV Guidelines, which doesn’t have any 
> ballots in play, as far as I know. <>
>  
> 
> From: Ryan Sleevi [mailto:sle...@google.com ] 
> Sent: Tuesday, May 16, 2017 12:39 PM
> To: CA/Browser Forum Public Discussion List  >
> Cc: Ben Wilson >
> Subject: Re: [cabfpub] Revised Notice of Review Period - Ballot 198 - .Onion 
> Revisions
> 
>  
> 
> As Ben has highlighted, the result of 198 created a new set of issues.
> 
>  
> 
> Kirk's original message includes the full text of the ballot (MOTION BEGINS), 
> which, unfortunately, used text different from what was adopted in Ballot 144 
> (and part of the current EVGs) when Jeremy made his modifications.
> 
>  
> 
> In examining 198 - 
> https://cabforum.org/pipermail/public/2017-April/010706.html 
>  - it's clear 
> in Jeremy's redlined versions (which, mistakenly, I reviewed as truth), the 
> 'intent' was a small change. See 
> https://cabforum.org/pipermail/public/attachments/20170424/80683ba2/attachment-0001.pdf
>  
> 
>  
> 
> However, as Balloted, it requires a full replacement of the text adopted in 
> 144, in a way that's structurally incompatible with the ASN.1 encoding.
> 
>  
> 
> Worse, this is something that was discussed during the voting reform 
> discussions - both situations where redlines and text differ (as in this 
> case) and questions about redlining as 'source of truth'. We tried to address 
> it as best as possible, but also somewhat punted the issue as unlikely :)
> 
>  
> 
> I think it's worth highlighting this concern broadly, because we have several 
> possible interpretations:
> 
>  
> 
> 1) The MOTION BEGINS/MOTION ENDS is authoritative (e.g. as Kirk has 
> distributed)
> 
>   - In this case, we've now introduced a bug into the processing that is not 
> easily undone.
> 
>   - Supporting Argument: This is how we've always done things.
> 
>   - Solution Suggestion: Hold a ballot immediately to try to fix this before 
> the end of the IP review.
> 
> - Approach 1: Nullify the ballot? That is, to keep the version of the BRs 
> the same.
> 
> - Approach 2: Direct the Chair not to publish any new versions of the BRs 
> (thus triggering compliance for CAs) until the matter is resolved
> 
> - Approach 3: Introduce a new ballot with a new OID for the service 
> descriptor that restores the 144 text
> 
>   - Implications:
> 
> - If folks don't vote on this, we're stuck in a bad place (effectively, 
> no one should issue EV onion certs, because they'd post a compat/interop risk)
> 
>  
> 
> 2) The redline text is authoritative (e.g. as Ben has distributed)
> 
>   - In this case, we're saying that the PDFs, not the ballot text, are what 
> is authoritative.
> 
>   - This means you can no longer read ballots on our website "as is", but 
> must ALSO view/post the supporting materials
> 
>   - Supporting Argument: The Bylaws seem to support this with respect to 
> Section 2.3(a).
> 
>   - Solution Suggestion: Hold a ballot to agree on this interpretation for 
> this specific ballot
> 
>   - Solution Suggestion p2: Hold a 

Re: [cabfpub] Revised Notice of Review Period - Ballot 198 - .Onion Revisions

[Ryan Sleevi via Public]

Yup. I'm curious for Apple's and Amazon's feedback, since they've been most
active in bylaw discussions :)

We've got several paths to clear this up, hence my straw poll outlining
options I could think of that would allow us to do so (trying to do so w/in
2 weeks - e.g. prior to the IP Review period expiring)

On Tue, May 16, 2017 at 3:44 PM, Ben Wilson  wrote:

> I think the end goal is to have a version 1.6.3 of the EV Guidelines with
> the language indicated in the redlined version of Appendix F that I
> circulated a short while ago.  So I’d prefer that we find there was no
> ambiguity and that Kirk start the review period over with the correct
> language and we call that good, but of course the cleanest route would be
> that Ballot 198 be declared defective because of ambiguity and a new ballot
> be presented for a new vote.  Fortunately this issue only affects the EV
> Guidelines, which doesn’t have any ballots in play, as far as I know.
>
>
>
> *From:* Ryan Sleevi [mailto:sle...@google.com]
> *Sent:* Tuesday, May 16, 2017 12:39 PM
> *To:* CA/Browser Forum Public Discussion List 
> *Cc:* Ben Wilson 
> *Subject:* Re: [cabfpub] Revised Notice of Review Period - Ballot 198 -
> .Onion Revisions
>
>
>
> As Ben has highlighted, the result of 198 created a new set of issues.
>
>
>
> Kirk's original message includes the full text of the ballot (MOTION
> BEGINS), which, unfortunately, used text different from what was adopted in
> Ballot 144 (and part of the current EVGs) when Jeremy made his
> modifications.
>
>
>
> In examining 198 - https://cabforum.org/pipermail/public/2017-April/
> 010706.html - it's clear in Jeremy's redlined versions (which,
> mistakenly, I reviewed as truth), the 'intent' was a small change. See
> https://cabforum.org/pipermail/public/attachments/
> 20170424/80683ba2/attachment-0001.pdf
>
>
>
> However, as Balloted, it requires a full replacement of the text adopted
> in 144, in a way that's structurally incompatible with the ASN.1 encoding.
>
>
>
> Worse, this is something that was discussed during the voting reform
> discussions - both situations where redlines and text differ (as in this
> case) and questions about redlining as 'source of truth'. We tried to
> address it as best as possible, but also somewhat punted the issue as
> unlikely :)
>
>
>
> I think it's worth highlighting this concern broadly, because we have
> several possible interpretations:
>
>
>
> 1) The MOTION BEGINS/MOTION ENDS is authoritative (e.g. as Kirk has
> distributed)
>
>   - In this case, we've now introduced a bug into the processing that is
> not easily undone.
>
>   - Supporting Argument: This is how we've always done things.
>
>   - Solution Suggestion: Hold a ballot immediately to try to fix this
> before the end of the IP review.
>
> - Approach 1: Nullify the ballot? That is, to keep the version of the
> BRs the same.
>
> - Approach 2: Direct the Chair not to publish any new versions of the
> BRs (thus triggering compliance for CAs) until the matter is resolved
>
> - Approach 3: Introduce a new ballot with a new OID for the service
> descriptor that restores the 144 text
>
>   - Implications:
>
> - If folks don't vote on this, we're stuck in a bad place
> (effectively, no one should issue EV onion certs, because they'd post a
> compat/interop risk)
>
>
>
> 2) The redline text is authoritative (e.g. as Ben has distributed)
>
>   - In this case, we're saying that the PDFs, not the ballot text, are
> what is authoritative.
>
>   - This means you can no longer read ballots on our website "as is", but
> must ALSO view/post the supporting materials
>
>   - Supporting Argument: The Bylaws seem to support this with respect to
> Section 2.3(a).
>
>   - Solution Suggestion: Hold a ballot to agree on this interpretation for
> this specific ballot
>
>   - Solution Suggestion p2: Hold a (same/different?) ballot to the bylaws
> clarify this for future ballots
>
>   - Implications:
>
>- We should figure out what this means for future ballots if we go this
> route.
>
>- It also means our ballot postings to the website are probably
> incomplete
>
>
>
> 3) The ballot is invalid (due to the inconsistency)
>
>   - In this case, we're saying the ballot is null because of the mismatch
>
>   - Supporting Argument: The Bylaws in 2.3(a) indicate that a Draft
> Guideline Ballot proposing a Final Maintenance Guideline will include a
> redline or comparison, and that such redline or comparison be made against
> the Final Guideline section(s) as they exist at the time the ballot is
> proposed. Jeremy's redline was not against that section, ergo, was not a
> valid ballot.
>
>   - Solution Suggestion: Hold a ballot to agree on this interpretation for
> this specific ballot
>
>   - Solution Suggestion p2: Adopt it fixed
>
>
>
> In short, I think we should probably resolve this with a ballot - which
> can be completed in two weeks. The IP 

Re: [cabfpub] [EXTERNAL]Re: Revised Notice of Review Period - Ballot 198 - .Onion Revisions

[Ben Wilson via Public]

In response to Jeremy’s post, the Governance Reform WG could re-examine 
sections 2.2 and 2.3 of the Bylaws and make suggested improvements as the WG 
works on other sections of the Bylaws.  The goal would be to write clearer 
rules on how ballots are to be submitted, interpreted, and incorporated into 
guidelines.

 

In response to Ryan’s comments below, I would like to emphasize the importance 
of the redlined version—it is by looking at how proposed edits to the official 
text (in between motion begins and motion ends), will be incorporated into the 
document that the ballot proposer (and we, who should all be reviewing the 
redline) can spot any inconsistencies.  These inconsistencies happen too often, 
and we should be looking at ways to minimize their occurrence.  (Also, if you 
have a ballot, there are currently two ways to create a redlined version—Github 
and Word versions on the wiki.)

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Ryan Sleevi via 
Public
Sent: Tuesday, May 16, 2017 2:00 PM
To: Kirk Hall 
Cc: Ryan Sleevi ; CA/Browser Forum Public Discussion List 

Subject: Re: [cabfpub] [EXTERNAL]Re: Revised Notice of Review Period - Ballot 
198 - .Onion Revisions

 

Right, to be clear, I was not suggesting you made a mistake. You did everything 
by the book :)

 

Rather, your Review Notice included the balloted text (motion begins/motion 
ends), but not the redline. In Jeremy's "ballot-thing" (for I don't know what 
we want to term it), there was the text you included - and the redline.

 

This is one of those ambiguities in the Bylaws and IP Policy that I was trying 
to call out. Is the Ballot (e.g. the thing called Ballot in the Bylaws) 
https://cabforum.org/pipermail/public/2017-April/010706.html ? If so, then the 
Ballot is 'both' the text you included, and the redlines. In Jeremy's case, the 
two were in conflict - the redline presented something different than the 
motion text. The Bylaws describe a Ballot as including a redline/comparison 
(which Jeremy did), but it's different than what the motion begins/ends text 
says.

 

I can't seem to find any requirements on the form of Review Notice, but it 
sounds like we're in agreement that, regardless of what the Review Notice 
states, what it applies to is "the Ballot". If we agree the Ballot is the 
motion begins/ends text (e.g. what you've published in the Review Notice, and 
what was voted on), then that's what it applies to. If we agree the Ballot is 
on the redline text (e.g. what Ben shared), then the Review Notice and the 
Ballot are different, but the Ballot still supercedes the Review Notice.

 

On Tue, May 16, 2017 at 3:43 PM, Kirk Hall  > wrote:

I have not followed all the details of this discussion, but I will offer my 
opinion on one point: any errors in the Review Notice do not affect the ballot 
or results of voting on the ballot.

 

For this ballot, if I included the wrong text in the Review Notice, can Jeremy 
please send me the correct text and I will circulate a corrected Review Notice 
and start the voting over again.

 

I typically look for the original ballot on the list from the proposer that 
started the process (plus any revisions that occurred during the discussion 
period), and put that in the Review Notice after a successful vote.  I’m not 
sure if that caused a mistake here.

 

From: Public [mailto:public-boun...@cabforum.org 
 ] On Behalf Of Ryan Sleevi via Public
Sent: Tuesday, May 16, 2017 11:39 AM
To: CA/Browser Forum Public Discussion List  >
Cc: Ryan Sleevi  >
Subject: [EXTERNAL]Re: [cabfpub] Revised Notice of Review Period - Ballot 198 - 
.Onion Revisions

 

As Ben has highlighted, the result of 198 created a new set of issues.

 

Kirk's original message includes the full text of the ballot (MOTION BEGINS), 
which, unfortunately, used text different from what was adopted in Ballot 144 
(and part of the current EVGs) when Jeremy made his modifications.

 

In examining 198 - https://cabforum.org/pipermail/public/2017-April/010706.html 
- it's clear in Jeremy's redlined versions (which, mistakenly, I reviewed as 
truth), the 'intent' was a small change. See 
https://cabforum.org/pipermail/public/attachments/20170424/80683ba2/attachment-0001.pdf

 

However, as Balloted, it requires a full replacement of the text adopted in 
144, in a way that's structurally incompatible with the ASN.1 encoding.

 

Worse, this is something that was discussed during the voting reform 
discussions - both situations where redlines and text differ (as in this case) 
and questions about redlining as 'source of truth'. We tried to address it as 
best as possible, but also somewhat punted the issue as unlikely :)

 

I think it's 

Re: [cabfpub] [EXTERNAL]Re: Revised Notice of Review Period - Ballot 198 - .Onion Revisions

[Ryan Sleevi via Public]

Right, to be clear, I was not suggesting you made a mistake. You did
everything by the book :)

Rather, your Review Notice included the balloted text (motion begins/motion
ends), but not the redline. In Jeremy's "ballot-thing" (for I don't know
what we want to term it), there was the text you included - and the redline.

This is one of those ambiguities in the Bylaws and IP Policy that I was
trying to call out. Is the Ballot (e.g. the thing called Ballot in the
Bylaws) https://cabforum.org/pipermail/public/2017-April/010706.html ? If
so, then the Ballot is 'both' the text you included, and the redlines. In
Jeremy's case, the two were in conflict - the redline presented something
different than the motion text. The Bylaws describe a Ballot as including a
redline/comparison (which Jeremy did), but it's different than what the
motion begins/ends text says.

I can't seem to find any requirements on the form of Review Notice, but it
sounds like we're in agreement that, regardless of what the Review Notice
states, what it applies to is "the Ballot". If we agree the Ballot is the
motion begins/ends text (e.g. what you've published in the Review Notice,
and what was voted on), then that's what it applies to. If we agree the
Ballot is on the redline text (e.g. what Ben shared), then the Review
Notice and the Ballot are different, but the Ballot still supercedes the
Review Notice.

On Tue, May 16, 2017 at 3:43 PM, Kirk Hall 
wrote:

> I have not followed all the details of this discussion, but I will offer
> my opinion on one point: any errors in the Review Notice do not affect the
> ballot or results of voting on the ballot.
>
>
>
> For this ballot, if I included the wrong text in the Review Notice, can
> Jeremy please send me the correct text and I will circulate a corrected
> Review Notice and start the voting over again.
>
>
>
> I typically look for the original ballot on the list from the proposer
> that started the process (plus any revisions that occurred during the
> discussion period), and put that in the Review Notice after a successful
> vote.  I’m not sure if that caused a mistake here.
>
>
>
> *From:* Public [mailto:public-boun...@cabforum.org] *On Behalf Of *Ryan
> Sleevi via Public
> *Sent:* Tuesday, May 16, 2017 11:39 AM
> *To:* CA/Browser Forum Public Discussion List 
> *Cc:* Ryan Sleevi 
> *Subject:* [EXTERNAL]Re: [cabfpub] Revised Notice of Review Period -
> Ballot 198 - .Onion Revisions
>
>
>
> As Ben has highlighted, the result of 198 created a new set of issues.
>
>
>
> Kirk's original message includes the full text of the ballot (MOTION
> BEGINS), which, unfortunately, used text different from what was adopted in
> Ballot 144 (and part of the current EVGs) when Jeremy made his
> modifications.
>
>
>
> In examining 198 - https://cabforum.org/pipermail/public/2017-April/
> 010706.html - it's clear in Jeremy's redlined versions (which,
> mistakenly, I reviewed as truth), the 'intent' was a small change. See
> https://cabforum.org/pipermail/public/attachments/
> 20170424/80683ba2/attachment-0001.pdf
>
>
>
> However, as Balloted, it requires a full replacement of the text adopted
> in 144, in a way that's structurally incompatible with the ASN.1 encoding.
>
>
>
> Worse, this is something that was discussed during the voting reform
> discussions - both situations where redlines and text differ (as in this
> case) and questions about redlining as 'source of truth'. We tried to
> address it as best as possible, but also somewhat punted the issue as
> unlikely :)
>
>
>
> I think it's worth highlighting this concern broadly, because we have
> several possible interpretations:
>
>
>
> 1) The MOTION BEGINS/MOTION ENDS is authoritative (e.g. as Kirk has
> distributed)
>
>   - In this case, we've now introduced a bug into the processing that is
> not easily undone.
>
>   - Supporting Argument: This is how we've always done things.
>
>   - Solution Suggestion: Hold a ballot immediately to try to fix this
> before the end of the IP review.
>
> - Approach 1: Nullify the ballot? That is, to keep the version of the
> BRs the same.
>
> - Approach 2: Direct the Chair not to publish any new versions of the
> BRs (thus triggering compliance for CAs) until the matter is resolved
>
> - Approach 3: Introduce a new ballot with a new OID for the service
> descriptor that restores the 144 text
>
>   - Implications:
>
> - If folks don't vote on this, we're stuck in a bad place
> (effectively, no one should issue EV onion certs, because they'd post a
> compat/interop risk)
>
>
>
> 2) The redline text is authoritative (e.g. as Ben has distributed)
>
>   - In this case, we're saying that the PDFs, not the ballot text, are
> what is authoritative.
>
>   - This means you can no longer read ballots on our website "as is", but
> must ALSO view/post the supporting materials
>
>   - Supporting Argument: The Bylaws seem to support this with 

Re: [cabfpub] Domain validation

[Jeremy Rowley via Public]

No, but it’s not a ballot. It’s just a discussion.

 

From: Kirk Hall [mailto:kirk.h...@entrustdatacard.com] 
Sent: Tuesday, May 16, 2017 1:45 PM
To: CA/Browser Forum Public Discussion List ; Ryan Sleevi 

Cc: Jeremy Rowley 
Subject: RE: [cabfpub] Domain validation

 

Jeremy, was this ballot discussed in the Validation Working Group?

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Jeremy Rowley 
via Public
Sent: Tuesday, May 16, 2017 12:39 PM
To: Ryan Sleevi  >
Cc: Jeremy Rowley  >; CA/Browser Forum Public Discussion List 
 >
Subject: [EXTERNAL]Re: [cabfpub] Domain validation

 

The original proposal actually utilized those sections and required checking 
WHOIS for changes within 90 days of issuance. I did want to discuss that during 
this process, but we can table that for the reuse portion.

 

From: Ryan Sleevi [mailto:sle...@google.com] 
Sent: Tuesday, May 16, 2017 10:36 AM
To: Jeremy Rowley  >
Cc: CA/Browser Forum Public Discussion List  >
Subject: Re: [cabfpub] Domain validation

 

 

 

On Tue, May 16, 2017 at 12:25 PM, Ryan Sleevi  > wrote:

So, first and foremost, it's unclear whether you're proposing this as a 'new' 
Ballot 190, or 'in addition to' Ballot 190. It's unclear if you're trying to 
break the problems out, or to solve the problems themselves.

 

I certainly am biased towards approaching this like most organizations approach 
code reviews - attempt to solve the smallest possible problem, provided it's 
solved comprehensively. This is why, for example, I broke out validation and 
reuse into separate draft ballots - because they are separable problems, even 
if closely related.

 

My understanding of your goals, although understandably limited here, is that 
something might be suited as:

 

- Ballot 190 [with whatever short-term fixes were accumulated since the passage 
of BRs 1.4.1]

- [Solve the language use issue - 'confirming control' vs 'validation' vs 
'authenticate']. This would be as a singular ballot, and seemingly is 
independent from these other issues.

- [Solve the random value language]. This too seems solely limited to Section 
2, so it doesn't seem to need to entail the other bits.

- [Solve the wildcard / subdomain issue]. This seems to be independent of any 
of the other aspects, but is also tricky and subtle enough to be worth its own 
discussion.

- [Solve the reuse issue]. Clearly, saving the 'contentious' for last, even if 
the simple goal is to clarify the reuse. As you know, there's a broader 
spectrum of issues at play here. We have the preamble in 3.2.2.4, we have the 
individual restrictions per method, and we even have requirements like those in 
4.1.2, that we want to make sure are entirely self-consistent.

 

That's just a thought, based on the understanding of the issues. It seems like 
each of these can be broken into separate ballots. They're potentially issues, 
but I don't know that trying to solve them 'all in one go' would be the best 
way to resolve them, considering they don't seem interdependent on eachother 
(that is, reuse is not tied to wildcard validation, AFAICT), and some may be 
either more subtle or thornier to sort out.

 

Regardless, _each_ of these would have to be reviewed in the full context of 
the BRs to make sure we don't end up with any conflicts from other sections 
(again, 4.1.2 is an example, as is 4.2.1 in a less-obvious manner but still 
potentially conflicting), and to figure out the best way to resolve those 
issues.

 

I'm not sure "reuse" should go in 3.2.2.4 at all, for example, but that's 
something we could discuss independent of any of the other perceived issues.

 

Oh, and one last piece of advice I offer when reviewing code :)

 

- Don't restructure your code for 'future feature X' until you know what the 
shape of 'future feature X' will look like. To me, that means avoid 
restructuring reuse 'so we can reduce it later' - unless/until we're ready to 
reduce the reuse period :) 



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

Re: [cabfpub] Revised Notice of Review Period - Ballot 198 - .Onion Revisions

[Jeremy Rowley via Public]

A “redo” will fix that ballot. However, the underlying question on which 
controls will remain unresolved. 

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Ben Wilson via 
Public
Sent: Tuesday, May 16, 2017 1:44 PM
To: Ryan Sleevi ; CA/Browser Forum Public Discussion List 

Cc: Ben Wilson 
Subject: Re: [cabfpub] Revised Notice of Review Period - Ballot 198 - .Onion 
Revisions

 

I think the end goal is to have a version 1.6.3 of the EV Guidelines with the 
language indicated in the redlined version of Appendix F that I circulated a 
short while ago.  So I’d prefer that we find there was no ambiguity and that 
Kirk start the review period over with the correct language and we call that 
good, but of course the cleanest route would be that Ballot 198 be declared 
defective because of ambiguity and a new ballot be presented for a new vote.  
Fortunately this issue only affects the EV Guidelines, which doesn’t have any 
ballots in play, as far as I know. 

 

From: Ryan Sleevi [mailto:sle...@google.com] 
Sent: Tuesday, May 16, 2017 12:39 PM
To: CA/Browser Forum Public Discussion List  >
Cc: Ben Wilson  >
Subject: Re: [cabfpub] Revised Notice of Review Period - Ballot 198 - .Onion 
Revisions

 

As Ben has highlighted, the result of 198 created a new set of issues.

 

Kirk's original message includes the full text of the ballot (MOTION BEGINS), 
which, unfortunately, used text different from what was adopted in Ballot 144 
(and part of the current EVGs) when Jeremy made his modifications.

 

In examining 198 - https://cabforum.org/pipermail/public/2017-April/010706.html 
- it's clear in Jeremy's redlined versions (which, mistakenly, I reviewed as 
truth), the 'intent' was a small change. See 
https://cabforum.org/pipermail/public/attachments/20170424/80683ba2/attachment-0001.pdf

 

However, as Balloted, it requires a full replacement of the text adopted in 
144, in a way that's structurally incompatible with the ASN.1 encoding.

 

Worse, this is something that was discussed during the voting reform 
discussions - both situations where redlines and text differ (as in this case) 
and questions about redlining as 'source of truth'. We tried to address it as 
best as possible, but also somewhat punted the issue as unlikely :)

 

I think it's worth highlighting this concern broadly, because we have several 
possible interpretations:

 

1) The MOTION BEGINS/MOTION ENDS is authoritative (e.g. as Kirk has distributed)

  - In this case, we've now introduced a bug into the processing that is not 
easily undone.

  - Supporting Argument: This is how we've always done things.

  - Solution Suggestion: Hold a ballot immediately to try to fix this before 
the end of the IP review.

- Approach 1: Nullify the ballot? That is, to keep the version of the BRs 
the same.

- Approach 2: Direct the Chair not to publish any new versions of the BRs 
(thus triggering compliance for CAs) until the matter is resolved

- Approach 3: Introduce a new ballot with a new OID for the service 
descriptor that restores the 144 text

  - Implications:

- If folks don't vote on this, we're stuck in a bad place (effectively, no 
one should issue EV onion certs, because they'd post a compat/interop risk)

 

2) The redline text is authoritative (e.g. as Ben has distributed)

  - In this case, we're saying that the PDFs, not the ballot text, are what is 
authoritative.

  - This means you can no longer read ballots on our website "as is", but must 
ALSO view/post the supporting materials

  - Supporting Argument: The Bylaws seem to support this with respect to 
Section 2.3(a).

  - Solution Suggestion: Hold a ballot to agree on this interpretation for this 
specific ballot

  - Solution Suggestion p2: Hold a (same/different?) ballot to the bylaws 
clarify this for future ballots

  - Implications:

   - We should figure out what this means for future ballots if we go this 
route.

   - It also means our ballot postings to the website are probably incomplete

 

3) The ballot is invalid (due to the inconsistency)

  - In this case, we're saying the ballot is null because of the mismatch

  - Supporting Argument: The Bylaws in 2.3(a) indicate that a Draft Guideline 
Ballot proposing a Final Maintenance Guideline will include a redline or 
comparison, and that such redline or comparison be made against the Final 
Guideline section(s) as they exist at the time the ballot is proposed. Jeremy's 
redline was not against that section, ergo, was not a valid ballot.

  - Solution Suggestion: Hold a ballot to agree on this interpretation for this 
specific ballot

  - Solution Suggestion p2: Adopt it fixed

 

In short, I think we should probably resolve this with a ballot - which can be 
completed in two weeks. The IP Review Notice has been 

Re: [cabfpub] Domain validation

[Kirk Hall via Public]

Jeremy, was this ballot discussed in the Validation Working Group?

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Jeremy Rowley 
via Public
Sent: Tuesday, May 16, 2017 12:39 PM
To: Ryan Sleevi 
Cc: Jeremy Rowley ; CA/Browser Forum Public 
Discussion List 
Subject: [EXTERNAL]Re: [cabfpub] Domain validation

The original proposal actually utilized those sections and required checking 
WHOIS for changes within 90 days of issuance. I did want to discuss that during 
this process, but we can table that for the reuse portion.

From: Ryan Sleevi [mailto:sle...@google.com]
Sent: Tuesday, May 16, 2017 10:36 AM
To: Jeremy Rowley 
>
Cc: CA/Browser Forum Public Discussion List 
>
Subject: Re: [cabfpub] Domain validation



On Tue, May 16, 2017 at 12:25 PM, Ryan Sleevi 
> wrote:
So, first and foremost, it's unclear whether you're proposing this as a 'new' 
Ballot 190, or 'in addition to' Ballot 190. It's unclear if you're trying to 
break the problems out, or to solve the problems themselves.

I certainly am biased towards approaching this like most organizations approach 
code reviews - attempt to solve the smallest possible problem, provided it's 
solved comprehensively. This is why, for example, I broke out validation and 
reuse into separate draft ballots - because they are separable problems, even 
if closely related.

My understanding of your goals, although understandably limited here, is that 
something might be suited as:

- Ballot 190 [with whatever short-term fixes were accumulated since the passage 
of BRs 1.4.1]
- [Solve the language use issue - 'confirming control' vs 'validation' vs 
'authenticate']. This would be as a singular ballot, and seemingly is 
independent from these other issues.
- [Solve the random value language]. This too seems solely limited to Section 
2, so it doesn't seem to need to entail the other bits.
- [Solve the wildcard / subdomain issue]. This seems to be independent of any 
of the other aspects, but is also tricky and subtle enough to be worth its own 
discussion.
- [Solve the reuse issue]. Clearly, saving the 'contentious' for last, even if 
the simple goal is to clarify the reuse. As you know, there's a broader 
spectrum of issues at play here. We have the preamble in 3.2.2.4, we have the 
individual restrictions per method, and we even have requirements like those in 
4.1.2, that we want to make sure are entirely self-consistent.

That's just a thought, based on the understanding of the issues. It seems like 
each of these can be broken into separate ballots. They're potentially issues, 
but I don't know that trying to solve them 'all in one go' would be the best 
way to resolve them, considering they don't seem interdependent on eachother 
(that is, reuse is not tied to wildcard validation, AFAICT), and some may be 
either more subtle or thornier to sort out.

Regardless, _each_ of these would have to be reviewed in the full context of 
the BRs to make sure we don't end up with any conflicts from other sections 
(again, 4.1.2 is an example, as is 4.2.1 in a less-obvious manner but still 
potentially conflicting), and to figure out the best way to resolve those 
issues.

I'm not sure "reuse" should go in 3.2.2.4 at all, for example, but that's 
something we could discuss independent of any of the other perceived issues.

Oh, and one last piece of advice I offer when reviewing code :)

- Don't restructure your code for 'future feature X' until you know what the 
shape of 'future feature X' will look like. To me, that means avoid 
restructuring reuse 'so we can reduce it later' - unless/until we're ready to 
reduce the reuse period :)
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Revised Notice of Review Period - Ballot 198 - .Onion Revisions

[Ben Wilson via Public]

I think the end goal is to have a version 1.6.3 of the EV Guidelines with the 
language indicated in the redlined version of Appendix F that I circulated a 
short while ago.  So I’d prefer that we find there was no ambiguity and that 
Kirk start the review period over with the correct language and we call that 
good, but of course the cleanest route would be that Ballot 198 be declared 
defective because of ambiguity and a new ballot be presented for a new vote.  
Fortunately this issue only affects the EV Guidelines, which doesn’t have any 
ballots in play, as far as I know. 

 

From: Ryan Sleevi [mailto:sle...@google.com] 
Sent: Tuesday, May 16, 2017 12:39 PM
To: CA/Browser Forum Public Discussion List 
Cc: Ben Wilson 
Subject: Re: [cabfpub] Revised Notice of Review Period - Ballot 198 - .Onion 
Revisions

 

As Ben has highlighted, the result of 198 created a new set of issues.

 

Kirk's original message includes the full text of the ballot (MOTION BEGINS), 
which, unfortunately, used text different from what was adopted in Ballot 144 
(and part of the current EVGs) when Jeremy made his modifications.

 

In examining 198 - https://cabforum.org/pipermail/public/2017-April/010706.html 
- it's clear in Jeremy's redlined versions (which, mistakenly, I reviewed as 
truth), the 'intent' was a small change. See 
https://cabforum.org/pipermail/public/attachments/20170424/80683ba2/attachment-0001.pdf

 

However, as Balloted, it requires a full replacement of the text adopted in 
144, in a way that's structurally incompatible with the ASN.1 encoding.

 

Worse, this is something that was discussed during the voting reform 
discussions - both situations where redlines and text differ (as in this case) 
and questions about redlining as 'source of truth'. We tried to address it as 
best as possible, but also somewhat punted the issue as unlikely :)

 

I think it's worth highlighting this concern broadly, because we have several 
possible interpretations:

 

1) The MOTION BEGINS/MOTION ENDS is authoritative (e.g. as Kirk has distributed)

  - In this case, we've now introduced a bug into the processing that is not 
easily undone.

  - Supporting Argument: This is how we've always done things.

  - Solution Suggestion: Hold a ballot immediately to try to fix this before 
the end of the IP review.

- Approach 1: Nullify the ballot? That is, to keep the version of the BRs 
the same.

- Approach 2: Direct the Chair not to publish any new versions of the BRs 
(thus triggering compliance for CAs) until the matter is resolved

- Approach 3: Introduce a new ballot with a new OID for the service 
descriptor that restores the 144 text

  - Implications:

- If folks don't vote on this, we're stuck in a bad place (effectively, no 
one should issue EV onion certs, because they'd post a compat/interop risk)

 

2) The redline text is authoritative (e.g. as Ben has distributed)

  - In this case, we're saying that the PDFs, not the ballot text, are what is 
authoritative.

  - This means you can no longer read ballots on our website "as is", but must 
ALSO view/post the supporting materials

  - Supporting Argument: The Bylaws seem to support this with respect to 
Section 2.3(a).

  - Solution Suggestion: Hold a ballot to agree on this interpretation for this 
specific ballot

  - Solution Suggestion p2: Hold a (same/different?) ballot to the bylaws 
clarify this for future ballots

  - Implications:

   - We should figure out what this means for future ballots if we go this 
route.

   - It also means our ballot postings to the website are probably incomplete

 

3) The ballot is invalid (due to the inconsistency)

  - In this case, we're saying the ballot is null because of the mismatch

  - Supporting Argument: The Bylaws in 2.3(a) indicate that a Draft Guideline 
Ballot proposing a Final Maintenance Guideline will include a redline or 
comparison, and that such redline or comparison be made against the Final 
Guideline section(s) as they exist at the time the ballot is proposed. Jeremy's 
redline was not against that section, ergo, was not a valid ballot.

  - Solution Suggestion: Hold a ballot to agree on this interpretation for this 
specific ballot

  - Solution Suggestion p2: Adopt it fixed

 

In short, I think we should probably resolve this with a ballot - which can be 
completed in two weeks. The IP Review Notice has been triggered, but its 
unclear as to whether Review Notices need to also include the Ballot text 
itself (e.g. the Ballot is, presumably, what was posted to public@cabforum.org 
  and voted on - which included the redline 
changes). That is, it's unclear whether the text Kirk included in the Review 
Notice - which is different than the ballot (since it omits the redlines) - 
supersedes/replaces the Ballot itself.

 

Does this capture every possible interpretation? Are the others?

 

On Tue, May 16, 2017 at 

Re: [cabfpub] [EXTERNAL]Re: Revised Notice of Review Period - Ballot 198 - .Onion Revisions

[Kirk Hall via Public]

I have not followed all the details of this discussion, but I will offer my 
opinion on one point: any errors in the Review Notice do not affect the ballot 
or results of voting on the ballot.

For this ballot, if I included the wrong text in the Review Notice, can Jeremy 
please send me the correct text and I will circulate a corrected Review Notice 
and start the voting over again.

I typically look for the original ballot on the list from the proposer that 
started the process (plus any revisions that occurred during the discussion 
period), and put that in the Review Notice after a successful vote.  I’m not 
sure if that caused a mistake here.

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Ryan Sleevi via 
Public
Sent: Tuesday, May 16, 2017 11:39 AM
To: CA/Browser Forum Public Discussion List 
Cc: Ryan Sleevi 
Subject: [EXTERNAL]Re: [cabfpub] Revised Notice of Review Period - Ballot 198 - 
.Onion Revisions

As Ben has highlighted, the result of 198 created a new set of issues.

Kirk's original message includes the full text of the ballot (MOTION BEGINS), 
which, unfortunately, used text different from what was adopted in Ballot 144 
(and part of the current EVGs) when Jeremy made his modifications.

In examining 198 - https://cabforum.org/pipermail/public/2017-April/010706.html 
- it's clear in Jeremy's redlined versions (which, mistakenly, I reviewed as 
truth), the 'intent' was a small change. See 
https://cabforum.org/pipermail/public/attachments/20170424/80683ba2/attachment-0001.pdf

However, as Balloted, it requires a full replacement of the text adopted in 
144, in a way that's structurally incompatible with the ASN.1 encoding.

Worse, this is something that was discussed during the voting reform 
discussions - both situations where redlines and text differ (as in this case) 
and questions about redlining as 'source of truth'. We tried to address it as 
best as possible, but also somewhat punted the issue as unlikely :)

I think it's worth highlighting this concern broadly, because we have several 
possible interpretations:

1) The MOTION BEGINS/MOTION ENDS is authoritative (e.g. as Kirk has distributed)
  - In this case, we've now introduced a bug into the processing that is not 
easily undone.
  - Supporting Argument: This is how we've always done things.
  - Solution Suggestion: Hold a ballot immediately to try to fix this before 
the end of the IP review.
- Approach 1: Nullify the ballot? That is, to keep the version of the BRs 
the same.
- Approach 2: Direct the Chair not to publish any new versions of the BRs 
(thus triggering compliance for CAs) until the matter is resolved
- Approach 3: Introduce a new ballot with a new OID for the service 
descriptor that restores the 144 text
  - Implications:
- If folks don't vote on this, we're stuck in a bad place (effectively, no 
one should issue EV onion certs, because they'd post a compat/interop risk)

2) The redline text is authoritative (e.g. as Ben has distributed)
  - In this case, we're saying that the PDFs, not the ballot text, are what is 
authoritative.
  - This means you can no longer read ballots on our website "as is", but must 
ALSO view/post the supporting materials
  - Supporting Argument: The Bylaws seem to support this with respect to 
Section 2.3(a).
  - Solution Suggestion: Hold a ballot to agree on this interpretation for this 
specific ballot
  - Solution Suggestion p2: Hold a (same/different?) ballot to the bylaws 
clarify this for future ballots
  - Implications:
   - We should figure out what this means for future ballots if we go this 
route.
   - It also means our ballot postings to the website are probably incomplete

3) The ballot is invalid (due to the inconsistency)
  - In this case, we're saying the ballot is null because of the mismatch
  - Supporting Argument: The Bylaws in 2.3(a) indicate that a Draft Guideline 
Ballot proposing a Final Maintenance Guideline will include a redline or 
comparison, and that such redline or comparison be made against the Final 
Guideline section(s) as they exist at the time the ballot is proposed. Jeremy's 
redline was not against that section, ergo, was not a valid ballot.
  - Solution Suggestion: Hold a ballot to agree on this interpretation for this 
specific ballot
  - Solution Suggestion p2: Adopt it fixed

In short, I think we should probably resolve this with a ballot - which can be 
completed in two weeks. The IP Review Notice has been triggered, but its 
unclear as to whether Review Notices need to also include the Ballot text 
itself (e.g. the Ballot is, presumably, what was posted to 
public@cabforum.org and voted on - which included 
the redline changes). That is, it's unclear whether the text Kirk included in 
the Review Notice - which is different than the ballot (since it omits the 
redlines) - supersedes/replaces the Ballot itself.

Does this capture every possible 

Re: [cabfpub] Domain validation

[Jeremy Rowley via Public]

The original proposal actually utilized those sections and required checking 
WHOIS for changes within 90 days of issuance. I did want to discuss that 
during this process, but we can table that for the reuse portion.



From: Ryan Sleevi [mailto:sle...@google.com]
Sent: Tuesday, May 16, 2017 10:36 AM
To: Jeremy Rowley 
Cc: CA/Browser Forum Public Discussion List 
Subject: Re: [cabfpub] Domain validation







On Tue, May 16, 2017 at 12:25 PM, Ryan Sleevi  > wrote:

So, first and foremost, it's unclear whether you're proposing this as a 'new' 
Ballot 190, or 'in addition to' Ballot 190. It's unclear if you're trying to 
break the problems out, or to solve the problems themselves.



I certainly am biased towards approaching this like most organizations 
approach code reviews - attempt to solve the smallest possible problem, 
provided it's solved comprehensively. This is why, for example, I broke out 
validation and reuse into separate draft ballots - because they are separable 
problems, even if closely related.



My understanding of your goals, although understandably limited here, is that 
something might be suited as:



- Ballot 190 [with whatever short-term fixes were accumulated since the 
passage of BRs 1.4.1]

- [Solve the language use issue - 'confirming control' vs 'validation' vs 
'authenticate']. This would be as a singular ballot, and seemingly is 
independent from these other issues.

- [Solve the random value language]. This too seems solely limited to Section 
2, so it doesn't seem to need to entail the other bits.

- [Solve the wildcard / subdomain issue]. This seems to be independent of any 
of the other aspects, but is also tricky and subtle enough to be worth its own 
discussion.

- [Solve the reuse issue]. Clearly, saving the 'contentious' for last, even if 
the simple goal is to clarify the reuse. As you know, there's a broader 
spectrum of issues at play here. We have the preamble in 3.2.2.4, we have the 
individual restrictions per method, and we even have requirements like those 
in 4.1.2, that we want to make sure are entirely self-consistent.



That's just a thought, based on the understanding of the issues. It seems like 
each of these can be broken into separate ballots. They're potentially issues, 
but I don't know that trying to solve them 'all in one go' would be the best 
way to resolve them, considering they don't seem interdependent on eachother 
(that is, reuse is not tied to wildcard validation, AFAICT), and some may be 
either more subtle or thornier to sort out.



Regardless, _each_ of these would have to be reviewed in the full context of 
the BRs to make sure we don't end up with any conflicts from other sections 
(again, 4.1.2 is an example, as is 4.2.1 in a less-obvious manner but still 
potentially conflicting), and to figure out the best way to resolve those 
issues.



I'm not sure "reuse" should go in 3.2.2.4 at all, for example, but that's 
something we could discuss independent of any of the other perceived issues.



Oh, and one last piece of advice I offer when reviewing code :)



- Don't restructure your code for 'future feature X' until you know what the 
shape of 'future feature X' will look like. To me, that means avoid 
restructuring reuse 'so we can reduce it later' - unless/until we're ready to 
reduce the reuse period :)



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

Re: [cabfpub] Revised Notice of Review Period - Ballot 198 - .Onion Revisions

[Ryan Sleevi via Public]

As Ben has highlighted, the result of 198 created a new set of issues.

Kirk's original message includes the full text of the ballot (MOTION
BEGINS), which, unfortunately, used text different from what was adopted in
Ballot 144 (and part of the current EVGs) when Jeremy made his
modifications.

In examining 198 -
https://cabforum.org/pipermail/public/2017-April/010706.html - it's clear
in Jeremy's redlined versions (which, mistakenly, I reviewed as truth), the
'intent' was a small change. See
https://cabforum.org/pipermail/public/attachments/20170424/80683ba2/attachment-0001.pdf

However, as Balloted, it requires a full replacement of the text adopted in
144, in a way that's structurally incompatible with the ASN.1 encoding.

Worse, this is something that was discussed during the voting reform
discussions - both situations where redlines and text differ (as in this
case) and questions about redlining as 'source of truth'. We tried to
address it as best as possible, but also somewhat punted the issue as
unlikely :)

I think it's worth highlighting this concern broadly, because we have
several possible interpretations:

1) The MOTION BEGINS/MOTION ENDS is authoritative (e.g. as Kirk has
distributed)
  - In this case, we've now introduced a bug into the processing that is
not easily undone.
  - Supporting Argument: This is how we've always done things.
  - Solution Suggestion: Hold a ballot immediately to try to fix this
before the end of the IP review.
- Approach 1: Nullify the ballot? That is, to keep the version of the
BRs the same.
- Approach 2: Direct the Chair not to publish any new versions of the
BRs (thus triggering compliance for CAs) until the matter is resolved
- Approach 3: Introduce a new ballot with a new OID for the service
descriptor that restores the 144 text
  - Implications:
- If folks don't vote on this, we're stuck in a bad place (effectively,
no one should issue EV onion certs, because they'd post a compat/interop
risk)

2) The redline text is authoritative (e.g. as Ben has distributed)
  - In this case, we're saying that the PDFs, not the ballot text, are what
is authoritative.
  - This means you can no longer read ballots on our website "as is", but
must ALSO view/post the supporting materials
  - Supporting Argument: The Bylaws seem to support this with respect to
Section 2.3(a).
  - Solution Suggestion: Hold a ballot to agree on this interpretation for
this specific ballot
  - Solution Suggestion p2: Hold a (same/different?) ballot to the bylaws
clarify this for future ballots
  - Implications:
   - We should figure out what this means for future ballots if we go this
route.
   - It also means our ballot postings to the website are probably
incomplete

3) The ballot is invalid (due to the inconsistency)
  - In this case, we're saying the ballot is null because of the mismatch
  - Supporting Argument: The Bylaws in 2.3(a) indicate that a Draft
Guideline Ballot proposing a Final Maintenance Guideline will include a
redline or comparison, and that such redline or comparison be made against
the Final Guideline section(s) as they exist at the time the ballot is
proposed. Jeremy's redline was not against that section, ergo, was not a
valid ballot.
  - Solution Suggestion: Hold a ballot to agree on this interpretation for
this specific ballot
  - Solution Suggestion p2: Adopt it fixed

In short, I think we should probably resolve this with a ballot - which can
be completed in two weeks. The IP Review Notice has been triggered, but its
unclear as to whether Review Notices need to also include the Ballot text
itself (e.g. the Ballot is, presumably, what was posted to
public@cabforum.org and voted on - which included the redline changes).
That is, it's unclear whether the text Kirk included in the Review Notice -
which is different than the ballot (since it omits the redlines) -
supersedes/replaces the Ballot itself.

Does this capture every possible interpretation? Are the others?

On Tue, May 16, 2017 at 1:00 PM, Ben Wilson via Public 
wrote:

> All,
>
> Attached is the redlined version of Appendix F of the EV Guidelines
> (v.1.6.3) based on the language of the ballot.  There was a discrepancy
> between the earlier PDF attachment to the ballot and the text in email that
> announced the ballot.  It appears that the PDF was based on an old,
> out-of-date version of Appendix F .
>
> In the attached redlined version I have tried to preserve the intent of
> Ballot 198.  I will be posting version 1.6.3 of the EV Guidelines to the
> CA/Browser Forum website shortly.  All versions (PDF/Word/redlined/w-o
> redlining) will be uploaded to here https://cabforum.org/wiki/EV on the
> wiki as well.
>
> Yours truly,
>
> Ben Wilson
>
>
>
> *From:* Public [mailto:public-boun...@cabforum.org] *On Behalf Of *Kirk
> Hall via Public
> *Sent:* Monday, May 8, 2017 5:18 PM
> *To:* CA/Browser Forum Public Discussion List 
> *Cc:* Kirk Hall 

[cabfpub] Final Minutes for CA/Browser Forum Teleconference 27 April 2017

[Kirk Hall via Public]

Final Minutes for CA/Browser Forum Teleconference 27 April 2017 (as approved 
May 11, 2017))

Attendees: Arno Fiedler (D-Trust), Atsushi Inaba (Globalsign), Ben Wilson 
(DigicertBruce Morton (Entrust), Christopher Kemmerer (SSL.com), Connie Enke 
(SwissSign), Curt Spann (Apple), Dean Coclin (Symantec), Dimitris Zacharopoulos 
(Harica), Doug Beattie (Globalsign), Erwann Abalea (DocuSign), Fotis Loukos 
(SSL.com), Frank Corday (Trustwave), Geoff Keating, Apple, Gervase Markham 
(Mozilla), JC Jones (Mozilla), Josh Aas (Let's Encrypt), Ken Myers (US PKI), 
Kirk Hall (Entrust), Mads Henriksveen (BuyPass), Masakazu Asano (GlobalSign), 
Neil Dunbar, Trustcor, Peter Bowen (Amazon), Peter Miscovic, (Disig), Rich 
Smith (Comodo), Rick Andrews (Symantec), Robin Alden (Comodo), Ryan Sleevi 
(Google), Sissel Hoel, (Buypass), Tarah Wheeler (Symantec), Tim Shirley 
(Trustwave), Tyler Myers (GoDaddy), .

1.Roll Call

2.Read Antitrust Statement

3.Review Agenda.  The Agenda was approved.


4.(a) Approve Minutes of CABF teleconference of April 13, 2017 as amended.  
The Minutes were approved.



   (b) Complete F2F meeting minutes: Kirk noted that the following Minutes 
segments had not been posted to the wiki, and asked the volunteers to complete 
the missing Minutes:


Jeremy - Validation WG
Doug- Microsoft Program Update
Liang - 360 Update
Andrew Whalley - The Role and Relationship of the Forum

Kirk said he wasn't certain if anyone intended to post Minutes for the guest 
presentation by Eric Mill - GSA update.  He will ask Eric if he wants to 
provide minutes or a summary.  Kirk also noted that he had asked the leader of 
each breakout group for the three Future of Web sessions to provide Minutes, 
but none had done it so we will not provide Minutes for those sessions.

(c) Update on Cisco-provided WebEx account (Jos, Ben).  Kirk noted that Cisco 
had graciously created a WebEx account that the Forum could use for its 
teleconferences and also for working group meetings.  Ben and Dean said they 
would try using the new account for some working group meetings first.  
Credentials will only be provided to a limited number of leaders to avoid 
misuse.

5.Governance Change Working Group update.  Dean said the WG was making good 
progress on draft amendments to the Bylaws.  We will start using Webex on our 
bi-weekly calls and the goal is to have a complete set of documents to 
implement the governance changes by the time of the next F2F meeting in June.

6.Validation Working Group update.  Ben said the WG had met the prior week 
and worked on a number of draft ballots, which should be ready soon.

7.Policy Review Working Group update.  Ben said the WG had a meeting just 
before this Forum meeting, and continued to work on clarifying the use of terms 
like CA, CA operator, etc. in the Baseline Requirements.  They were also trying 
to better incorporate RFC 5280 terminology in the BRs.

8.Draft Code of Conduct.  Virginia was not on the call to review her draft 
of the proposed Code of Conduct.  Tarah, who had volunteered at the F2F to move 
forward with this project, said she had reviewed the draft and thanked Virginia 
for all her hard work.  There were no comments on the draft from the members.  
Kirk said the topic would be on the agenda for the next call, and he hoped 
Virginia could participate on that call to provide an overview.

9.Ballot Status.  Kirk noted the status of the following ballots:

Ballots in voting period: Ballot 197 - Effective Date of Ballot 193 Provisions 
- Ends May 3.



Ballots in discussion period: Ballot 198 - .Onion Revisions - Ends May 1.  
Ballot 199 - Require commonName in Root and Intermediate Certificates - Ends 
May 2.



Ballots in IPR Review Period: Ballot 189 - Amend BR 6.1.7 to clarify signing by 
root keys (ends May 15); Ballot 194 -  Effective Date of Ballot 193 Provisions 
(ends May 16); Ballot 195 - CAA Fixup (ends May 18); Ballot 196 - Define "Audit 
Period" (ends May 18).



Kirk noted that other draft ballots had been listed on the Agenda, and asked if 
anyone wanted to discuss any ballots during the call.



Ballot 198: Ryan said the ballot adds to the EV Guidelines the Tor service 
descriptor because the onion name is essentially a truncated hash of the public 
key used to identify hidden services.  The subject is computed by generating a 
1024 bit RSA key and hashing that with SHA1; the truncated hash of that is then 
encoded and the onion name results.  In the discussion as to why we are 
permitting onion certificates, the goal is to ensure that there is no ambiguity 
as to how the naming is done.  In this ballot the goal is to ensure the certs 
issued for onion clearly identified the public key that they are attesting to 
so if someone is exploiting a SHA1 collision they will do so by generating a 
different public key.  A goal of the ballot is to put additional information in 
the EV certificate to make sure you are going to the 

Re: [cabfpub] Domain validation

[Ryan Sleevi via Public]

On Tue, May 16, 2017 at 12:25 PM, Ryan Sleevi  wrote:

> So, first and foremost, it's unclear whether you're proposing this as a
> 'new' Ballot 190, or 'in addition to' Ballot 190. It's unclear if you're
> trying to break the problems out, or to solve the problems themselves.
>
> I certainly am biased towards approaching this like most organizations
> approach code reviews - attempt to solve the smallest possible problem,
> provided it's solved comprehensively. This is why, for example, I broke out
> validation and reuse into separate draft ballots - because they are
> separable problems, even if closely related.
>
> My understanding of your goals, although understandably limited here, is
> that something might be suited as:
>
> - Ballot 190 [with whatever short-term fixes were accumulated since the
> passage of BRs 1.4.1]
> - [Solve the language use issue - 'confirming control' vs 'validation' vs
> 'authenticate']. This would be as a singular ballot, and seemingly is
> independent from these other issues.
> - [Solve the random value language]. This too seems solely limited to
> Section 2, so it doesn't seem to need to entail the other bits.
> - [Solve the wildcard / subdomain issue]. This seems to be independent of
> any of the other aspects, but is also tricky and subtle enough to be worth
> its own discussion.
> - [Solve the reuse issue]. Clearly, saving the 'contentious' for last,
> even if the simple goal is to clarify the reuse. As you know, there's a
> broader spectrum of issues at play here. We have the preamble in 3.2.2.4,
> we have the individual restrictions per method, and we even have
> requirements like those in 4.1.2, that we want to make sure are entirely
> self-consistent.
>
> That's just a thought, based on the understanding of the issues. It seems
> like each of these can be broken into separate ballots. They're potentially
> issues, but I don't know that trying to solve them 'all in one go' would be
> the best way to resolve them, considering they don't seem interdependent on
> eachother (that is, reuse is not tied to wildcard validation, AFAICT), and
> some may be either more subtle or thornier to sort out.
>
> Regardless, _each_ of these would have to be reviewed in the full context
> of the BRs to make sure we don't end up with any conflicts from other
> sections (again, 4.1.2 is an example, as is 4.2.1 in a less-obvious manner
> but still potentially conflicting), and to figure out the best way to
> resolve those issues.
>
> I'm not sure "reuse" should go in 3.2.2.4 at all, for example, but that's
> something we could discuss independent of any of the other perceived issues.
>

Oh, and one last piece of advice I offer when reviewing code :)

- Don't restructure your code for 'future feature X' until you know what
the shape of 'future feature X' will look like. To me, that means avoid
restructuring reuse 'so we can reduce it later' - unless/until we're ready
to reduce the reuse period :)
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Domain validation

[Dimitris Zacharopoulos via Public]

On 16/5/2017 7:12 μμ, Jeremy Rowley wrote:


"The CA MUST record the subsection and version of the Baseline 
Requirements used to validate an Applicant’s control over each FQDN 
included in an issued certificate"

When is this expected to become effective?
- Immediately after the IPR period expires



Ok, I hope everyone understands what this means in terms of code changes.

In methods 3.2.2.4.1, 3.2.2.4.2, 3.2.2.4.3,  b (2), you say that the 
CA must verify that the WHOIS information for the Base Domain has not 
changed since the CA performed the verification process. Is this the 
WHOIS information record itself or should CAs be looking for the 
Domain Contact to appear in the WHOIS record? I'm asking because some 
WHOIS databases do not release Domain Contact information and CAs 
require an official document from the Domain Registrar that contains 
information about the domain owner and contacts for the initial domain 
validation.
- Right now the time period in that section specifies the Domain 
 language 825 days so it’s identical to the verification period. I put 
this in explicitly in case we wanted to reduce the period to of WHOIS 
re-confirmation to a lesser period (such as 90 days?). It should have 
said WHOIS or Domain Registrar though instead of just WHOIS. I also 
don’t mind dropping bullet point 2 if everyone is opposed to a 
WHOIS/Domain Registrar refresh.




No, I think checking for WHOIS change is fine if we agree on checking 
just the WHOIS record. For the example below, the WHOIS record itself 
does not reveal who the Domain Registrant is. It just states the Domain 
Handle, Domain Identifier, dates and Registrar info. If all this 
information remains the same, it is reasonable to assume that the 
Registrant also remains the same. I don't know if my description is 
fully captured in the currently proposed language.



For example, this is the WHOIS record for example.gr:

Domain Name:example.gr
Domain Handle:dr-1234-gr
Protocol Number:1234
Creation Date:24-07-1997
Expiration Date:31-12-2017
Updated Date:05-11-2015
Registrar:FOO
Registrar Referral URL:http://www.FOO.gr
Registrar Email:regist...@foo.gr 
Registrar Telephone:+30.123456
Whois Server:
Bundle Name:example.gr
Name Server:.example.gr
Name Server:XX.example.gr


According to your proposal, CAs only need to check if the record above 
has not changed?
- Yes. That is the point of bullet point 2. To try and address issues 
where domain ownership may have changed.




In this example, if the domain ownership changed, the dates would change 
and probably the Domain Handle and "Protocol Number". That should be 
enough to trigger a re-validation of the domain. The "Expiration Date" 
should also be a blocker if the issuance date is greater than the 
expiration date of the domain.



Thanks again,
Dimitris.
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Domain validation

[Ryan Sleevi via Public]

So, first and foremost, it's unclear whether you're proposing this as a
'new' Ballot 190, or 'in addition to' Ballot 190. It's unclear if you're
trying to break the problems out, or to solve the problems themselves.

I certainly am biased towards approaching this like most organizations
approach code reviews - attempt to solve the smallest possible problem,
provided it's solved comprehensively. This is why, for example, I broke out
validation and reuse into separate draft ballots - because they are
separable problems, even if closely related.

My understanding of your goals, although understandably limited here, is
that something might be suited as:

- Ballot 190 [with whatever short-term fixes were accumulated since the
passage of BRs 1.4.1]
- [Solve the language use issue - 'confirming control' vs 'validation' vs
'authenticate']. This would be as a singular ballot, and seemingly is
independent from these other issues.
- [Solve the random value language]. This too seems solely limited to
Section 2, so it doesn't seem to need to entail the other bits.
- [Solve the wildcard / subdomain issue]. This seems to be independent of
any of the other aspects, but is also tricky and subtle enough to be worth
its own discussion.
- [Solve the reuse issue]. Clearly, saving the 'contentious' for last, even
if the simple goal is to clarify the reuse. As you know, there's a broader
spectrum of issues at play here. We have the preamble in 3.2.2.4, we have
the individual restrictions per method, and we even have requirements like
those in 4.1.2, that we want to make sure are entirely self-consistent.

That's just a thought, based on the understanding of the issues. It seems
like each of these can be broken into separate ballots. They're potentially
issues, but I don't know that trying to solve them 'all in one go' would be
the best way to resolve them, considering they don't seem interdependent on
eachother (that is, reuse is not tied to wildcard validation, AFAICT), and
some may be either more subtle or thornier to sort out.

Regardless, _each_ of these would have to be reviewed in the full context
of the BRs to make sure we don't end up with any conflicts from other
sections (again, 4.1.2 is an example, as is 4.2.1 in a less-obvious manner
but still potentially conflicting), and to figure out the best way to
resolve those issues.

I'm not sure "reuse" should go in 3.2.2.4 at all, for example, but that's
something we could discuss independent of any of the other perceived issues.

On Tue, May 16, 2017 at 12:13 PM, Jeremy Rowley 
wrote:

> That’s fine.  How would you like it broken up? I could break it up by
> validation method or by issue statement.
>
>
>
> *From:* Ryan Sleevi [mailto:sle...@google.com]
> *Sent:* Tuesday, May 16, 2017 10:06 AM
> *To:* Jeremy Rowley 
> *Cc:* CA/Browser Forum Public Discussion List 
> *Subject:* Re: [cabfpub] Domain validation
>
>
>
>
>
>
>
> On Tue, May 16, 2017 at 11:55 AM, Jeremy Rowley <
> jeremy.row...@digicert.com> wrote:
>
> 1) The document is presented as a ballot because I based the revisions on
> 190.  If there are discrete sub-components someone doesn’t like, I don’t
> mind breaking it up into chunks.
>
>
>
> The problem is not about 'not liking'. It's about a tremendous amount of
> text that tries to solve a whole host of issues, all at once, and without
> clear identification of the goals or related changes. This makes it
> incredibly difficult to review, and all the more likely of a Ballot 193/197
> problem being introduced. Further, the approach to creating the ballot
> creates issues like recently discovered by Ben in Ballot 198, in which the
> 'proposed text' and the 'redlined version' actually substantially differed
> from what was actually adopted (more on that for another thread).
>
>
>
> It's not that I disagree with your goals - I think you've captured some
> very useful things to do. I'm just not sure there's any reasonable hope
> that we'd be confident it was appropriately reviewed, especially in light
> of the substantive discussion re: Ballot 190 that still needs adoption, and
> because of that, makes it very hard to consider voting in favor. This is,
> for what it's worth, notably similar to some of the subordinate CA
> discussions.
>
>
>
> While that comes across negative (and almost certainly would be reflected
> in a vote, should it come to that), I'm incredibly thrilled that someone
> such as yourself has taken a comprehensive look at it, and I'm thrilled
> that you've found and identified issues. Just the means of attempting to
> fix them is perhaps less than ideal, and much like I'd send back an overly
> complex code review back to the submitter as "overly complex; simplify",
> I'm trying to figure out if there's a way to tease out the issues or look
> at incrementalist approaches here.
>
>
>
> This is why even with a 'small' change (the OCSP profile), which only
> removes a few 

Re: [cabfpub] Domain validation

[Jeremy Rowley via Public]

That’s fine.  How would you like it broken up? I could break it up by 
validation method or by issue statement. 

 

From: Ryan Sleevi [mailto:sle...@google.com] 
Sent: Tuesday, May 16, 2017 10:06 AM
To: Jeremy Rowley 
Cc: CA/Browser Forum Public Discussion List 
Subject: Re: [cabfpub] Domain validation

 

 

 

On Tue, May 16, 2017 at 11:55 AM, Jeremy Rowley  > wrote: 

1) The document is presented as a ballot because I based the revisions on 190.  
If there are discrete sub-components someone doesn’t like, I don’t mind 
breaking it up into chunks.  

 

The problem is not about 'not liking'. It's about a tremendous amount of text 
that tries to solve a whole host of issues, all at once, and without clear 
identification of the goals or related changes. This makes it incredibly 
difficult to review, and all the more likely of a Ballot 193/197 problem being 
introduced. Further, the approach to creating the ballot creates issues like 
recently discovered by Ben in Ballot 198, in which the 'proposed text' and the 
'redlined version' actually substantially differed from what was actually 
adopted (more on that for another thread).

 

It's not that I disagree with your goals - I think you've captured some very 
useful things to do. I'm just not sure there's any reasonable hope that we'd be 
confident it was appropriately reviewed, especially in light of the substantive 
discussion re: Ballot 190 that still needs adoption, and because of that, makes 
it very hard to consider voting in favor. This is, for what it's worth, notably 
similar to some of the subordinate CA discussions.

 

While that comes across negative (and almost certainly would be reflected in a 
vote, should it come to that), I'm incredibly thrilled that someone such as 
yourself has taken a comprehensive look at it, and I'm thrilled that you've 
found and identified issues. Just the means of attempting to fix them is 
perhaps less than ideal, and much like I'd send back an overly complex code 
review back to the submitter as "overly complex; simplify", I'm trying to 
figure out if there's a way to tease out the issues or look at incrementalist 
approaches here.

 

This is why even with a 'small' change (the OCSP profile), which only removes a 
few lines of text, I tried to extensively annotate the reasonings behind each 
change, the dependencies, and their relationship - see 
https://github.com/sleevi/cabforum-docs/pull/2

 

I'm also not sure I'd agree with some of your problem statements, so that's 
where helping identify what you see as the problem can sort out an appropriate 
solution :)



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

Re: [cabfpub] Domain validation

[Jeremy Rowley via Public]

This is excellent work and helps people understand each method a lot better.
- Thanks! Let me know if you disagree with anything. 

"The CA MUST record the subsection and version of the Baseline Requirements 
used to validate an Applicant’s control over each FQDN included in an issued 
certificate" 
When is this expected to become effective?
- Immediately after the IPR period expires

In methods 3.2.2.4.1, 3.2.2.4.2, 3.2.2.4.3,  b (2), you say that the CA must 
verify that the WHOIS information for the Base Domain has not changed since the 
CA performed the verification process. Is this the WHOIS information record 
itself or should CAs be looking for the Domain Contact to appear in the WHOIS 
record? I'm asking because some WHOIS databases do not release Domain Contact 
information and CAs require an official document from the Domain Registrar that 
contains information about the domain owner and contacts for the initial domain 
validation.
- Right now the time period in that section specifies the Domain  language 825 
days so it’s identical to the verification period. I put this in explicitly in 
case we wanted to reduce the period to of WHOIS re-confirmation to a lesser 
period (such as 90 days?). It should have said WHOIS or Domain Registrar though 
instead of just WHOIS. I also don’t mind dropping bullet point 2 if everyone is 
opposed to a WHOIS/Domain Registrar refresh.

For example, this is the WHOIS record for example.gr:


Domain Name:example.gr
Domain Handle:dr-1234-gr
Protocol Number:1234
Creation Date:24-07-1997
Expiration Date:31-12-2017
Updated Date:05-11-2015
Registrar:FOO
Registrar Referral URL:http://www.FOO.gr
Registrar Email:regist...@foo.gr  
Registrar Telephone:+30.123456
Whois Server: 
Bundle Name:example.gr
Name Server:.example.gr
Name Server:XX.example.gr


According to your proposal, CAs only need to check if the record above has not 
changed?
- Yes. That is the point of bullet point 2. To try and address issues where 
domain ownership may have changed.


Also, there is a small typo in the 3rd paragraph of 3.2.2.4.2 a (FQNs --> 
FQDNs).
- Thanks!



 



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

Re: [cabfpub] Domain validation

[Ryan Sleevi via Public]

On Tue, May 16, 2017 at 11:55 AM, Jeremy Rowley 
wrote:
>
> 1) The document is presented as a ballot because I based the revisions on
> 190.  If there are discrete sub-components someone doesn’t like, I don’t
> mind breaking it up into chunks.
>

The problem is not about 'not liking'. It's about a tremendous amount of
text that tries to solve a whole host of issues, all at once, and without
clear identification of the goals or related changes. This makes it
incredibly difficult to review, and all the more likely of a Ballot 193/197
problem being introduced. Further, the approach to creating the ballot
creates issues like recently discovered by Ben in Ballot 198, in which the
'proposed text' and the 'redlined version' actually substantially differed
from what was actually adopted (more on that for another thread).

It's not that I disagree with your goals - I think you've captured some
very useful things to do. I'm just not sure there's any reasonable hope
that we'd be confident it was appropriately reviewed, especially in light
of the substantive discussion re: Ballot 190 that still needs adoption, and
because of that, makes it very hard to consider voting in favor. This is,
for what it's worth, notably similar to some of the subordinate CA
discussions.

While that comes across negative (and almost certainly would be reflected
in a vote, should it come to that), I'm incredibly thrilled that someone
such as yourself has taken a comprehensive look at it, and I'm thrilled
that you've found and identified issues. Just the means of attempting to
fix them is perhaps less than ideal, and much like I'd send back an overly
complex code review back to the submitter as "overly complex; simplify",
I'm trying to figure out if there's a way to tease out the issues or look
at incrementalist approaches here.

This is why even with a 'small' change (the OCSP profile), which only
removes a few lines of text, I tried to extensively annotate the reasonings
behind each change, the dependencies, and their relationship - see
https://github.com/sleevi/cabforum-docs/pull/2

I'm also not sure I'd agree with some of your problem statements, so that's
where helping identify what you see as the problem can sort out an
appropriate solution :)
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Domain validation

[Jeremy Rowley via Public]

Answering in reverse order:

 

2) Subdomains are labels to the left of a verified FQDN. Authorization domains 
are labels to the right. The reasons for a definition are:

a. Under Section 3.2.2.4, the CA is verifying the FQDN.  This verification 
process for some methods may rely on an Authorization Domain Name but the 
verification is tied to a FQDN (per 3.2.2.4). 

b. Most CAs reuse verification of an FQDN to issue certificates that are 
sub-domains of a verified FQDN. Whether this is allowed is ambiguous under 
169/190. 

c. Wildcard domains are always sub-domains of a verified FQDN. Wildcards are 
called out in the definition of an Authorization Domain Name. However, 
verification of a Wildcard Domain Name is never addressed in the actual section.

d. There could be cases where we don’t want to permit a method to issue 
certificates for sub-domains.  Better to split the permissions out so we can 
discuss each method individually and provide clarity around the circumstances 
permitting reuse of validation information.

 

1) The document is presented as a ballot because I based the revisions on 190.  
If there are discrete sub-components someone doesn’t like, I don’t mind 
breaking it up into chunks.  Some of the reasons for the proposal:

a) As mentioned above, wildcard domains are questionable about how they are 
validated.

b) The language is inconsistent. For example, method 1 says the CA is 
“confirming control”. We then switch terminology to “validation”. Following 
that switch, we move to “authenticate”. Do each of these words mean something 
different? 

c) The language is unclear on reuse of validation information. Splitting the 
info out per section so we can change it on a per-validation type basis. Right 
now reuse is not defined, which means it could either require a validation per 
issuance or permit reuse for the 825 day period.

d) Under method 2, who creates the Random value? The CA specifies the value and 
send its via email. Seems like the CA should create it as well. 

e) Under method 2, the interplay in these three sentences is odd:

“The Random Value SHALL be unique in each email, fax, SMS, or postal mail.”

“The CA or Delegated Third Party MAY resend the email, fax, SMS, or postal mil 
in its entirety, including re-use of the Random Value, provided that the 
communication's entire contents and recipient(s) remain unchanged.”

“The Random Value SHALL remain valid for use in a confirming response for no 
more than 30 days from its creation. The CPS MAY specify a shorter validity 
period for Random Values, in which case the CA MUST follow its CPS.”

Does this mean you can resend for 30 days? Can you send it after 30 days? Why 
does one sentence say it must be unique but the other permit resending? 

 

Etc.

 

 

From: Ryan Sleevi [mailto:sle...@google.com] 
Sent: Monday, May 15, 2017 4:55 PM
To: CA/Browser Forum Public Discussion List 
Cc: Jeremy Rowley 
Subject: Re: [cabfpub] Domain validation

 

Jeremy,

 

I think the trend has been to try to keep revisions simple - so that we don't 
introduce any unintentional scope. Could you expand on the reasoning for 
coupling these? As we saw with Ballot 193/197, it seems like it makes it more 
error prone.

 

You posed it as a ballot, so it makes it hard to comment on line items (Using 
word to "track changes" is not a very publicly accountable or managable 
process), but I'm hoping to better understand.

 

Could you

1) Highlight what you believe are inconsistencies in the existing language?

2) Highlight why you believe there are differences between subdomains and 
authorized domain names?

 

 

On Mon, May 15, 2017 at 4:41 PM, Jeremy Rowley via Public  > wrote:

While working on implementing the methods defined by ballot 169, we noticed a 
lot of inconsistencies in the language and process. This made some of the 
methods confusing, especially on how they applied to reuse of information and 
verification of subdomains/wildcards.  Attached is a proposal that we think 
clarifies the process and tightens up the language. 

 

A couple of notes:

1.  The proposal doesn’t intend to substantially change any of the methods. 
However, this is DigiCert’s interpretation of the requirements. Given the 
previous language, disagreement on the interpretation is likely and will 
highlight the need for a clarifying ballot.
2.  This method doesn’t necessarily replace 190. If longer discussion is 
needed (because there are lots of changes), then this could be a subsequent 
revision to the validation methods and include more stringent controls (like 
reverifying WHOIS information within 30 days and restricting sub-domain 
methods). For now, I tried to keep the process and reuse the same.
3.  The proposal separates out sub domain reuse, reuse of documentation, 
and splits the longer methods into discrete steps.  There are lots of redundant