Re: [cabfpub] Public Digest, Vol 69, Issue 89

Wayne and all, We can discuss these issues at the next Governance WG meeting. Best regards, Virginia Fournier Senior Standards Counsel  Apple Inc. ☏ 669-227-9595 ✉︎ v...@apple.com On Jan 19, 2018, at 3:54 PM, public-requ...@cabforum.org wrote: Send Public

Re: [cabfpub] [EXTERNAL] Verification of Domain Contact and Domain Authorization Document

> On Jan 19, 2018, at 12:16 PM, Kirk Hall wrote: > > Sorry for the misquotation – I left off “*** directly with the Domain Name > Registrar,” which is generally what we have been discussing – a WhoIs lookup > to see who owns the domain. That wasn’t my

Re: [cabfpub] Pre-Ballot 206 - Amendment to IPR Policy & Bylaws re Working Group Formation

On Fri, Jan 19, 2018 at 12:03 PM, Virginia Fournier via Public < public@cabforum.org> wrote: > Yes, a Working Group can form its own subcommittees within itself. > I don't think this statement is obviously true. The current bylaws define these "subcommittees" (called Working Groups) - the new

Re: [cabfpub] [EXTERNAL] Verification of Domain Contact and Domain Authorization Document

Sorry for the misquotation – I left off “*** directly with the Domain Name Registrar,” which is generally what we have been discussing – a WhoIs lookup to see who owns the domain. But do you see my point that “validating the Applicant as the Domain Contact” (current language) could simply

Re: [cabfpub] [EXTERNAL] Verification of Domain Contact and Domain Authorization Document

Rich, I assume once you have a fraudulent certificate, then you will have to something else to finalize the attack. You could compromise the site, but then you should have used method 6 to validate the domain. You could perform a DNS attack, but then you should have used method 7 to validate

Re: [cabfpub] [EXTERNAL] Verification of Domain Contact and Domain Authorization Document

> On Jan 19, 2018, at 11:23 AM, Kirk Hall wrote: > > First, I think everyone knows what CAs are supposed to do under Method 1 I’m fairly sure this is not the case… > , and the lack of misissuance reports means CAs are doing it right. Here’s > how Method 1

Re: [cabfpub] [EXTERNAL] Verification of Domain Contact and Domain Authorization Document

BR 3.2.2.4 states “This section defines the permitted processes and procedures for validating the Applicant's ownership or control of the domain.” Confirming ownership is BR compliant. I always thought that ownership should be preferred. An attacker can have control, but they won’t have

Re: [cabfpub] [EXTERNAL] Verification of Domain Contact and Domain Authorization Document

Mads, I appreciate you trying to save this method, but IMO there is nothing that can be done to strengthen this method enough to protect it against social engineering. Your proposal relies on the assumption that EVERY validation agent of EVERY CA MUST have at least the same level of understanding

Re: [cabfpub] [EXTERNAL] Verification of Domain Contact and Domain Authorization Document

On Fri, Jan 19, 2018 at 1:51 AM, Mads Egil Henriksveen via Public < public@cabforum.org> wrote: > Hi > > > > Buypass, Entrust Datacard and GlobalSign have been working on some text to > strengthen 3.2.2.4.1 instead of removing it - find the draft text below. > The draft was discussed in the

Re: [cabfpub] [EXTERNAL] Verification of Domain Contact and Domain Authorization Document

First, I think everyone knows what CAs are supposed to do under Method 1, and the lack of misissuance reports means CAs are doing it right. Here’s how Method 1 starts now: “Conforming the Applicant's control over the FQDN by validating the Applicant as the Domain Contact by verifying that:

Re: [cabfpub] [EXTERNAL] Verification of Domain Contact and Domain Authorization Document

That data is correct as GoDaddy Registered the domain name. If the Applicant is CA/Browser Forum and the Registrant is GoDaddy, then method 1 will fail by design. Bruce. From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Geoff Keating via Public Sent: January 19, 2018 1:44 PM To:

Re: [cabfpub] Pre-Ballot 206 - Amendment to IPR Policy & Bylaws re Working Group Formation

Yes, a Working Group can form its own subcommittees within itself. Someone asked whether all of the WGs would be subgroups under the Server Certificate WG - and that is clearly not the intent. Also, please note that the same Bylaws and IPR policy apply to all WGs. The structure is intended

Re: [cabfpub] [EXTERNAL] Verification of Domain Contact and Domain Authorization Document

The ‘Domain Contact’ is not just a name. For example, for cabforum.org , it’s all of this data: Registrant Name: Domain Administrator Registrant Organization: Go Daddy Operating Company, LLC Registrant Street: 14455 N Hayden Rd Suite 219 Registrant City: Scottsdale

Re: [cabfpub] [EXTERNAL] Verification of Domain Contact and Domain Authorization Document

Jeff - here are the three relevant definitions: Applicant: The natural person or Legal Entity that applies for (or seeks renewal of) a Certificate. Once the Certificate issues, the Applicant is referred to as the Subscriber. Domain Contact: The Domain Name Registrant, technical contact, or

Re: [cabfpub] [EXTERNAL] Verification of Domain Contact and Domain Authorization Document

I think this proposed change actually makes 3.2.2.4.1 weaker. Previously it was necessary to validate that the Applicant and the Domain Contact were the same—some CAs might not have been doing this properly, but it was what the words said. Now you’re just validating that the Applicant has the

Re: [cabfpub] [EXTERNAL] Verification of Domain Contact and Domain Authorization Document

Are you saying you actually use method #5? I keep asking CAs, and I have yet to hear from one that actually uses method #5. Most of the concern seems to be around method #1. -Tim From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Entschew, Enrico via Public Sent: Friday,

Re: [cabfpub] [EXTERNAL] Verification of Domain Contact and Domain Authorization Document

Hi all, D-TRUST fully supports the ongoing discussion on improving BR section 3.2.2.4.1 and 3.2.2.4.5. In our opinion all options on improving the methods need to be taken into account. Only if there is no way of optimizing the procedure in order to prohibit potential misissuance scenarios

Re: [cabfpub] Pre-Ballot 206 - Amendment to IPR Policy & Bylaws re Working Group Formation

Yes, I understood that, and maybe I just need to get my head around it. It seems weird to me, and very different from our current structure. It’s not what we drew on the whiteboard wherever we were, but maybe it’ll work fine. -Tim From: vfourn...@apple.com [mailto:vfourn...@apple.com]

Re: [cabfpub] [EXTERNAL] Verification of Domain Contact and Domain Authorization Document

Hi Gerv The current version 3.2.2.4.1 says: 3.2.2.4.1 Validating the Applicant as a Domain Contact Confirming the Applicant's control over the FQDN by validating the Applicant is the Domain Contact directly with the Domain Name Registrar. This method may only be used if: 1. The CA

[cabfpub] Critical Vulnerability Scenario

I know every CA already has a disaster plan in place to maintain certain level of continuity in case of failure, weather and etc. But is there a global contingency plan in place if a critical vulnerability was found in one of the key systems which required immediate change over to a different

Re: [cabfpub] Pre-Ballot 206 - Amendment to IPR Policy & Bylaws re Working Group Formation

On 19/01/18 01:32, Virginia Fournier via Public wrote: > *All of the above 5 WGs would be individual, independent, separate > groups and would not be subcommittees, subgroups, ancillaries, or > subordinates of any other group.* The (current) work of e.g. the Validation WG is clearly a subset of

Re: [cabfpub] [EXTERNAL] Verification of Domain Contact and Domain Authorization Document

On 19/01/18 06:51, Mads Egil Henriksveen via Public wrote: > Buypass, Entrust Datacard and GlobalSign have been working on some text > to strengthen 3.2.2.4.1 instead of removing it - find the draft text > below. The draft was discussed in the Validation Working Group meeting > yesterday. We would