Re: [cabfpub] [EXTERNAL]Re: Ballot 218: Remove validation methods #1 and #5

[Bruce Morton via Public]

Jeremy,

 

Thanks for the feedback. For comparison, let’s say I wanted to swap out method 
#1 for method #2. Can you provide the bulleted list for how 3.2.2.1, 3.2.2.4.2 
and 3.2.5 would be performed?

 

Thanks again, Bruce.

 

From: Jeremy Rowley [mailto:jeremy.row...@digicert.com] 
Sent: January 4, 2018 10:59 AM
To: Bruce Morton ; CA/Browser Forum Public 
Discussion List ; Ryan Sleevi 
Subject: RE: [cabfpub] [EXTERNAL]Re: Ballot 218: Remove validation methods #1 
and #5

 

3. BR 3.2.2.4.1 is performed using registrar information to confirm the 
organization has registered the domain name. The QIIS is used to identify 
relationships if the domain is registered to a parent or subsidiary.

- This is the hand-wavy part. Looking in WHOIS to see some org listed does not 
tie the org to the domain. Anyone can list anything in the WHOIS corporate 
details.  

 

4.BR 3.2.5 is performed by finding contact information for the organization 
using a QIIS. The authorization contact is called at the organization using 
this information. The authorization contact is asked to confirm that a 
certificate with the organization name, using the domain name(s) requested, can 
be issued to the certificate requester. 

- Do you do this step for every domain? I’m guessing it’s done once every 825 
days when you verify the org to confirm the account is controlled by that org.  
Is there any tie between the person called and the domain name other than that 
the person called requested the certificate for the domain? 

 

What’s missing from this process is any awareness of the domain owner that a 
certificate is being requested by Company ABC.  Because WHOIS is unverified 
information with respect to company info, there’s no actual technical tie 
between the org and the domain. Because names are not globally unique, there’s 
no determination whether the correct entity applied for the certificate (ie - 
DigiCert, Inc. a Utah corp and DigiCert, Inc. a Malaysian entity). 

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Bruce Morton via 
Public
Sent: Thursday, January 4, 2018 7:49 AM
To: Ryan Sleevi mailto:sle...@google.com> >
Cc: CA/Browser Forum Public Discussion List mailto:public@cabforum.org> >
Subject: Re: [cabfpub] [EXTERNAL]Re: Ballot 218: Remove validation methods #1 
and #5

 

Hi Ryan,

 

Here are some details on how we perform this method.

 

For an OV certificate, we perform method #1 as follows:

 

1.  Order is received with the subject name, SANs, a certificate requester 
and an authorization contact. The authorization contact must be employed by the 
organization in the subject name.
2.  BR 3.2.2.1 is performed to confirm the identity of the organization. 
This task is done with using a QIIS.
3.  BR 3.2.2.4.1 is performed using registrar information to confirm the 
organization has registered the domain name. The QIIS is used to identify 
relationships if the domain is registered to a parent or subsidiary.
4.  BR 3.2.5 is performed by finding contact information for the 
organization using a QIIS. The authorization contact is called at the 
organization using this information. The authorization contact is asked to 
confirm that a certificate with the organization name, using the domain name(s) 
requested, can be issued to the certificate requester. 

 

 

Thanks, Bruce.

 

From: Ryan Sleevi [mailto:sle...@google.com] 
Sent: January 4, 2018 12:09 AM
To: Bruce Morton mailto:bruce.mor...@entrustdatacard.com> >
Cc: Rich Smith mailto:richard.sm...@comodo.com> >; 
CA/Browser Forum Public Discussion List mailto:public@cabforum.org> >; Kirk Hall mailto:kirk.h...@entrustdatacard.com> >
Subject: Re: [EXTERNAL]Re: [cabfpub] Ballot 218: Remove validation methods #1 
and #5

 

 

 

On Wed, Jan 3, 2018 at 5:27 PM, Bruce Morton mailto:bruce.mor...@entrustdatacard.com> > wrote:

I disagree.

 

Removing, changing and adding back in method #1 is not a productive exercise. 
This method has been used for probably 20 years and yet we never see any 
notifications, articles, alerts, etc. of how this method was defeated by an 
attacker.

 

I think it's exceptionally dangerous to rest on that, particularly since CAs 
such as Entrust don't make available to the public their processes and controls 
to inspect whether or not they're vulnerable. I am greatly appreciative to 
Jeremy sharing the case of customers from a CA they acquired not being 
validated to the level that DigiCert holds itself - but that's hardly to be 
expected, unless we are to suggest DigiCert should buy out every other CA.

 

It was this philosophical opposition that resulted in MD5 being exploited 'in 
the wild' - CAs ignoring the literature and research and demanding 'proof it 
applied'

 

Does Entrust (or the CAs it has acquired) use this method? Can you share the 
details that are used to do this?

 

I stand by the assertion that while it may be possible to restrict what is done 
under 3.2.2.4.1 to be 'secure', that is n

Re: [cabfpub] [EXTERNAL]Re: Ballot 218: Remove validation methods #1 and #5

[Ryan Sleevi via Public]

On Thu, Jan 4, 2018 at 9:48 AM, Bruce Morton <
bruce.mor...@entrustdatacard.com> wrote:

> Hi Ryan,
>
>
>
> Here are some details on how we perform this method.
>
>
>
> For an OV certificate, we perform method #1 as follows:
>
>
>
> 1.  Order is received with the subject name, SANs, a certificate
> requester and an authorization contact. The authorization contact must be
> employed by the organization in the subject name.
>
How can you vet that? You've not vetted anything yet, so how can you vet
the Applicant's employment status? I think you're trying to hint at this in
4, but that's unclear.

> 2.  BR 3.2.2.1 is performed to confirm the identity of the
> organization. This task is done with using a QIIS.
>
Note that the concerns about QIIS apply here - as we've seen with
situations like "Stripe, Inc" in Kentucky. At this point, you've verified
that some organization exists, but that's based entirely on
Applicant-provided data (namely, the Applicant provided the
organization-to-vet in 1, which is under their control - e.g. "Stripe, Inc"
in Kentucky)


> 3.  BR 3.2.2.4.1 is performed using registrar information to confirm
> the organization has registered the domain name. The QIIS is used to
> identify relationships if the domain is registered to a parent or
> subsidiary.
>
As Jeremy highlighted, this is both insufficiently described and inherently
dangerous. That you have is that _an_ organization with a name such as
"Stripe, Inc" requested a certificate. Are you obtaining the full
jurisdiction of incorporation information from the registrar (I would be
curious which registrars they are, given the various collection policies
that contractually apply)? If not, then you're back to relying on the
'fuzzy match' - for example, does the registrar say "Stripe, Inc" at this
address applied for it? As shown with both the QGIS and QIIS situations,
this is not a particularly robust method - and that's assuming y'all were
trying to "do it right"

> 4.  BR 3.2.5 is performed by finding contact information for the
> organization using a QIIS. The authorization contact is called at the
> organization using this information. The authorization contact is asked to
> confirm that a certificate with the organization name, using the domain
> name(s) requested, can be issued to the certificate requester.
>
This doesn't link the Applicant's employment status - just the
authorization. Further, given that Entrust has argued strongly in favor of
reusing past validations, I'm guessing that this authorization is then
applied to subsequent requests. Further, given the BRs allow you to reuse
data and documents, do you use such authorizations for additional domain
names?



>
>
>
>
> Thanks, Bruce.
>
>
>
> *From:* Ryan Sleevi [mailto:sle...@google.com]
> *Sent:* January 4, 2018 12:09 AM
> *To:* Bruce Morton 
> *Cc:* Rich Smith ; CA/Browser Forum Public
> Discussion List ; Kirk Hall <
> kirk.h...@entrustdatacard.com>
> *Subject:* Re: [EXTERNAL]Re: [cabfpub] Ballot 218: Remove validation
> methods #1 and #5
>
>
>
>
>
>
>
> On Wed, Jan 3, 2018 at 5:27 PM, Bruce Morton <
> bruce.mor...@entrustdatacard.com> wrote:
>
> I disagree.
>
>
>
> Removing, changing and adding back in method #1 is not a productive
> exercise. This method has been used for probably 20 years and yet we never
> see any notifications, articles, alerts, etc. of how this method was
> defeated by an attacker.
>
>
>
> I think it's exceptionally dangerous to rest on that, particularly since
> CAs such as Entrust don't make available to the public their processes and
> controls to inspect whether or not they're vulnerable. I am greatly
> appreciative to Jeremy sharing the case of customers from a CA they
> acquired not being validated to the level that DigiCert holds itself - but
> that's hardly to be expected, unless we are to suggest DigiCert should buy
> out every other CA.
>
>
>
> It was this philosophical opposition that resulted in MD5 being exploited
> 'in the wild' - CAs ignoring the literature and research and demanding
> 'proof it applied'
>
>
>
> Does Entrust (or the CAs it has acquired) use this method? Can you share
> the details that are used to do this?
>
>
>
> I stand by the assertion that while it may be possible to restrict what is
> done under 3.2.2.4.1 to be 'secure', that is not what it is in the
> language, and what is presently executed is demonstrably insecure. If we
> are to suggest that we, as an industry, care about security of our users,
> then we should make tradeoffs that favor security.
>
>
>
>
>
> Note, I agree that method #1 can be approved in the BRs, but please advise
> which CAs have not already improved this method in practice? If a CA finds
> a BR requirement to be weak, they should either not use it or improve the
> process in their own practices. I assume that many BR requirements were not
> intended to have loopholes, but were written to allow competitiveness in
> the way they are adopted.
>
>
>
> Fundamentally, I disagre

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

[Ryan Sleevi via Public]

This does not resolve the issues mentioned.

On Thu, Jan 4, 2018 at 7:47 AM, Mads Egil Henriksveen via Public <
public@cabforum.org> wrote:

> Removing method  1 is not the only way to solve this ambiguity, it could
> also be solved by changing the language of 3.2.2.4.1 into something like
> this (changes are redlined in attached document):
>
>
>
> *3.2.2.4.1 Validating the Applicant as a Domain Name Registrant*
>
> Confirming the Applicant's control over the FQDN by validating the
> Applicant is the Domain Name Registrant. This method may only be used if:
>
> 1. The CA authenticates the Applicant's identity under BR Section 3.2.2.1
> and the authority of the Applicant Representative under BR Section 3.2.5, OR
> The Applicant identity and address must match the Domain Name Registrant.
>
> 2. The CA authenticates the Applicant's identity under EV Guidelines
> Section 11.2 and the agency of the Certificate Approver under EV Guidelines
> Section 11.8; OR
> The Applicant must be the same legal entity as the Domain Name Registrant
>
>
>
> Note: Once the FQDN has been validated using this method, the CA MAY also
> issue Certificates for other
>
> FQDNs that end with all the labels of the validated FQDN. This method is
> suitable for validating Wildcard
>
> Domain Names.
>
>
>
> This would also allow for using method 1 for the use cases I have
> identified.
>
>
>
> Regards
>
> Mads
>
>
>
> *From:* Public [mailto:public-boun...@cabforum.org] *On Behalf Of *Jeremy
> Rowley via Public
> *Sent:* onsdag 3. januar 2018 23:25
> *To:* geo...@apple.com
> *Cc:* CA/Browser Forum Public Discussion List 
> *Subject:* Re: [cabfpub] Verification of Domain Contact and Domain
> Authorization Document
>
>
>
> The ambiguity is exactly why we need to remove method 1. I’ve seen all of
> the following:
>
> 1)  Approval based on a name match
>
> 2)  Approval based on an email match (same email as requester or the
> email is a corporate email) – note that this is a Domain Contact match
>
> 3)  Approval based on address and name match
>
> 4)  Approval based on a letter from the registrar
>
> 5)  Approval based on a call to the registrar
>
> 6)  Approval based on a validation email to the registrar
>
>
>
> All of these are equally permitted by the language, IMO, because “by
> validating the Applicant has the same name as the Domain Contact
> directly with the Domain Name Registrar” can mean a LOT of things.
>
>
>
> *From:* geo...@apple.com [mailto:geo...@apple.com ]
> *Sent:* Wednesday, January 3, 2018 2:54 PM
> *To:* Jeremy Rowley 
> *Cc:* CA/Browser Forum Public Discussion List ; Ryan
> Sleevi ; Adriano Santoni  it>
> *Subject:* Re: [cabfpub] Verification of Domain Contact and Domain
> Authorization Document
>
>
>
> It looks like we’re going to be removing 3.2.2.4.1, so this will be moot,
> but just to explain the interpretation, 3.2.2.4.1 says that what you are
> doing (this sentence is the entire description of the method, the rest of
> the section just limits its application) is "Confirming the Applicant's
> control over the FQDN by validating the Applicant is the Domain Contact
> directly with the Domain Name Registrar.”
>
>
>
> This is not a name match.  If the BRs wanted to say “by validating the
> Applicant has the same name as the Domain Contact”, they would say so.
> This is a one-and-the-same match, it uses the word “is”.  In the example
> below, the CA must ensure that “Google Inc., the Utah corporation” is the
> same one as shown in the WHOIS information, and all the WHOIS information
> is relevant in confirming this.
>
>
>
> Another important clarification is that if you use 3.2.2.1, it doesn’t
> just verify “the name of the applicant”; it says that "the CA SHALL
> verify the identity and address of the organization”, not just the name.
>  (Um… actually, if you read it closely, you might not verify the name at
> all, if you identify the organization in another way, maybe with some kind
> of ID number.  That’s probably a bug.)
>
>
>
> On 2 Jan 2018, at 8:47 pm, Jeremy Rowley 
> wrote:
>
>
>
> I disagree. The requirements do not specify that.  All that is required is
> the name of the applicant was verified under 3.2.2.1 and that the register
> specify the domain contact is the applicant. If Google, Inc. is specified
> as the domain contact, no address matching is required.
>
>
>
> *From:* geo...@apple.com [mailto:geo...@apple.com ]
> *Sent:* Tuesday, January 2, 2018 4:34 PM
> *To:* Jeremy Rowley ; CA/Browser Forum Public
> Discussion List 
> *Cc:* Ryan Sleevi ; Adriano Santoni <
> adriano.sant...@staff.aruba.it>
> *Subject:* Re: [cabfpub] Verification of Domain Contact and Domain
> Authorization Document
>
>
>
>
>
>
>
> On Dec 22, 2017, at 12:09 PM, Jeremy Rowley via Public <
> public@cabforum.org> wrote:
>
>
>
> The attack vector is easier than that.
>
>1. I use very stringent processes to verify that Google, Inc. is a
>legit company in Utah.
>2. I verify that Jeremy did indeed incorporat

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

[Ryan Sleevi via Public]

I stand by the assertion and can happily demonstrate it. While it may be
that your position is that such commercial CAs exercise their fiduciary
duty by considering the long-term impact of such 'short-term' hacks, I do
not believe it can or should be disputed that the incentive structure is as
I described, and it is constantly such a balancing act. You took it as a
pejorative remark, clearly, but I am highlighting that is is a struggle
between the CA's fiduciary duty to maximize shareholder value and the
common resource that is the security ecosystem.

In any event, it seems that an argument that rests on "CA's can be trusted
to do the right thing" is both unreasonable and unsustainable, and the
ample evidence suggests that - more often from ignorance than malice -
ambiguity in requirements, or broad strokes, do not output the desired
results. Further, we should assess the practical impact - that is, is
3.2.2.4.1 being used, by who, and by how - if we are to mount a defense
that it should not be removed. We have evidence of its abuse, we know that
less than half of the trusted CA's participate in the CA/Browser Forum, and
we know that auditors are even more liberal in their interpretation given
_their_ fiduciary duty to their clients and financial incentives, so it's
not at all unreasonable to remove (given the ample alternatives) and then
later revisit if there is something equivalently secure.

On Thu, Jan 4, 2018 at 9:59 AM, Tim Hollebeek 
wrote:

> This characterization of CAs in general is simply not true and I wish you
> would stop making it.  It’s a bunch of overly broad statements and
> mischaracterizations.
>
>
>
> There are some bad actors out there, and some bad practices out there that
> need to be eliminated, but using that to tar the entire industry with a
> broad brush is misleading in the extreme.
>
>
>
> -Tim
>
>
>
> *From:* Public [mailto:public-boun...@cabforum.org] *On Behalf Of *Ryan
> Sleevi via Public
> *Sent:* Wednesday, January 3, 2018 10:03 PM
> *To:* Bruce Morton ; CA/Browser Forum
> Public Discussion List 
> *Subject:* Re: [cabfpub] [EXTERNAL]Re: Verification of Domain Contact and
> Domain Authorization Document
>
>
>
> Given that CAs have competing interests - namely, to sell certificates
> first and foremost, while at the same time not doing anything too egregious
> to get noticed and thus distrusted - I don't think it's reasonable,
> particularly given the economic incentives and industrial behaviour, to
> suggest that CAs would find this as something to reject.
>
>
>
> Most CAs, at the end of the day, mint certs for money. CAs particularly
> concerned about appearances such as market share are further incentivized
> to make minting certs easier. It is thus unsurprising that this sort of
> incentive structure results in what we might term 'exploitative' (in a
> security mindset), while the CA might call it 'innovative' or 'customer
> friendly'.
>
>
>
> On Wed, Jan 3, 2018 at 5:41 PM, Bruce Morton via Public <
> public@cabforum.org> wrote:
>
> The requirement may mean a LOT of things, but it is also qualified by
> language such as “This method may only be used if: 1. The CA authenticates
> the Applicant's identity under BR Section 3.2.2.1 and the authority of the
> Applicant Representative under BR Section 3.2.5.”
>
>
>
> I assume it will be stated that the language in 3.2.2.1 and 3.2.5 also
> mean a LOT of things, but this is the job of the CA to create a policy
> which is effective. Per BR 5, the CA should also do risk assessments and
> security plans. Using this methodology will help the CA close the loopholes
> in its processes. Of course, if the CA still finds the risk too high, then
> they can stop using the method.
>
>
>
> Bruce.
>
>
>
> *From:* Public [mailto:public-boun...@cabforum.org] *On Behalf Of *Jeremy
> Rowley via Public
> *Sent:* January 3, 2018 5:25 PM
> *To:* geo...@apple.com
> *Cc:* CA/Browser Forum Public Discussion List 
> *Subject:* [EXTERNAL]Re: [cabfpub] Verification of Domain Contact and
> Domain Authorization Document
>
>
>
> The ambiguity is exactly why we need to remove method 1. I’ve seen all of
> the following:
>
> 1)  Approval based on a name match
>
> 2)  Approval based on an email match (same email as requester or the
> email is a corporate email) – note that this is a Domain Contact match
>
> 3)  Approval based on address and name match
>
> 4)  Approval based on a letter from the registrar
>
> 5)  Approval based on a call to the registrar
>
> 6)  Approval based on a validation email to the registrar
>
>
>
> All of these are equally permitted by the language, IMO, because “by
> validating the Applicant has the same name as the Domain Contact
> directly with the Domain Name Registrar” can mean a LOT of things.
>
>
>
> *From:* geo...@apple.com [mailto:geo...@apple.com ]
> *Sent:* Wednesday, January 3, 2018 2:54 PM
> *To:* Jeremy Rowley 
> *Cc:* CA/Browser Forum Public Discussion List ; Ryan
> Sleevi ; Adriano Santoni  it>

Re: [cabfpub] [EXTERNAL]Re: Ballot 218: Remove validation methods #1 and #5

[Jeremy Rowley via Public]

3. BR 3.2.2.4.1 is performed using registrar information to confirm the 
organization has registered the domain name. The QIIS is used to identify 
relationships if the domain is registered to a parent or subsidiary.

- This is the hand-wavy part. Looking in WHOIS to see some org listed does not 
tie the org to the domain. Anyone can list anything in the WHOIS corporate 
details.  

 

4.BR 3.2.5 is performed by finding contact information for the organization 
using a QIIS. The authorization contact is called at the organization using 
this information. The authorization contact is asked to confirm that a 
certificate with the organization name, using the domain name(s) requested, can 
be issued to the certificate requester. 

- Do you do this step for every domain? I’m guessing it’s done once every 825 
days when you verify the org to confirm the account is controlled by that org.  
Is there any tie between the person called and the domain name other than that 
the person called requested the certificate for the domain? 

 

What’s missing from this process is any awareness of the domain owner that a 
certificate is being requested by Company ABC.  Because WHOIS is unverified 
information with respect to company info, there’s no actual technical tie 
between the org and the domain. Because names are not globally unique, there’s 
no determination whether the correct entity applied for the certificate (ie - 
DigiCert, Inc. a Utah corp and DigiCert, Inc. a Malaysian entity). 

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Bruce Morton via 
Public
Sent: Thursday, January 4, 2018 7:49 AM
To: Ryan Sleevi 
Cc: CA/Browser Forum Public Discussion List 
Subject: Re: [cabfpub] [EXTERNAL]Re: Ballot 218: Remove validation methods #1 
and #5

 

Hi Ryan,

 

Here are some details on how we perform this method.

 

For an OV certificate, we perform method #1 as follows:

 

1.  Order is received with the subject name, SANs, a certificate requester 
and an authorization contact. The authorization contact must be employed by the 
organization in the subject name.
2.  BR 3.2.2.1 is performed to confirm the identity of the organization. 
This task is done with using a QIIS.
3.  BR 3.2.2.4.1 is performed using registrar information to confirm the 
organization has registered the domain name. The QIIS is used to identify 
relationships if the domain is registered to a parent or subsidiary.
4.  BR 3.2.5 is performed by finding contact information for the 
organization using a QIIS. The authorization contact is called at the 
organization using this information. The authorization contact is asked to 
confirm that a certificate with the organization name, using the domain name(s) 
requested, can be issued to the certificate requester. 

 

 

Thanks, Bruce.

 

From: Ryan Sleevi [mailto:sle...@google.com] 
Sent: January 4, 2018 12:09 AM
To: Bruce Morton mailto:bruce.mor...@entrustdatacard.com> >
Cc: Rich Smith mailto:richard.sm...@comodo.com> >; 
CA/Browser Forum Public Discussion List mailto:public@cabforum.org> >; Kirk Hall mailto:kirk.h...@entrustdatacard.com> >
Subject: Re: [EXTERNAL]Re: [cabfpub] Ballot 218: Remove validation methods #1 
and #5

 

 

 

On Wed, Jan 3, 2018 at 5:27 PM, Bruce Morton mailto:bruce.mor...@entrustdatacard.com> > wrote:

I disagree.

 

Removing, changing and adding back in method #1 is not a productive exercise. 
This method has been used for probably 20 years and yet we never see any 
notifications, articles, alerts, etc. of how this method was defeated by an 
attacker.

 

I think it's exceptionally dangerous to rest on that, particularly since CAs 
such as Entrust don't make available to the public their processes and controls 
to inspect whether or not they're vulnerable. I am greatly appreciative to 
Jeremy sharing the case of customers from a CA they acquired not being 
validated to the level that DigiCert holds itself - but that's hardly to be 
expected, unless we are to suggest DigiCert should buy out every other CA.

 

It was this philosophical opposition that resulted in MD5 being exploited 'in 
the wild' - CAs ignoring the literature and research and demanding 'proof it 
applied'

 

Does Entrust (or the CAs it has acquired) use this method? Can you share the 
details that are used to do this?

 

I stand by the assertion that while it may be possible to restrict what is done 
under 3.2.2.4.1 to be 'secure', that is not what it is in the language, and 
what is presently executed is demonstrably insecure. If we are to suggest that 
we, as an industry, care about security of our users, then we should make 
tradeoffs that favor security.

 

 

Note, I agree that method #1 can be approved in the BRs, but please advise 
which CAs have not already improved this method in practice? If a CA finds a BR 
requirement to be weak, they should either not use it or improve the process in 
their own practices. I assume that many BR requirements were not intended

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

[Adriano Santoni via Public]

👍


Il 04/01/2018 15:59, Tim Hollebeek via Public ha scritto:


This characterization of CAs in general is simply not true and I wish 
you would stop making it.  It’s a bunch of overly broad statements and 
mischaracterizations.


There are some bad actors out there, and some bad practices out there 
that need to be eliminated, but using that to tar the entire industry 
with a broad brush is misleading in the extreme.


-Tim

*From:* Public [mailto:public-boun...@cabforum.org] *On Behalf Of 
*Ryan Sleevi via Public

*Sent:* Wednesday, January 3, 2018 10:03 PM
*To:* Bruce Morton ; CA/Browser 
Forum Public Discussion List 
*Subject:* Re: [cabfpub] [EXTERNAL]Re: Verification of Domain Contact 
and Domain Authorization Document


Given that CAs have competing interests - namely, to sell certificates 
first and foremost, while at the same time not doing anything too 
egregious to get noticed and thus distrusted - I don't think it's 
reasonable, particularly given the economic incentives and industrial 
behaviour, to suggest that CAs would find this as something to reject.


Most CAs, at the end of the day, mint certs for money. CAs 
particularly concerned about appearances such as market share are 
further incentivized to make minting certs easier. It is thus 
unsurprising that this sort of incentive structure results in what we 
might term 'exploitative' (in a security mindset), while the CA might 
call it 'innovative' or 'customer friendly'.


On Wed, Jan 3, 2018 at 5:41 PM, Bruce Morton via Public 
mailto:public@cabforum.org>> wrote:


The requirement may mean a LOT of things, but it is also qualified
by language such as “This method may only be used if: 1. The CA
authenticates the Applicant's identity under BR Section 3.2.2.1
and the authority of the Applicant Representative under BR Section
3.2.5.”

I assume it will be stated that the language in 3.2.2.1 and 3.2.5
also mean a LOT of things, but this is the job of the CA to create
a policy which is effective. Per BR 5, the CA should also do risk
assessments and security plans. Using this methodology will help
the CA close the loopholes in its processes. Of course, if the CA
still finds the risk too high, then they can stop using the method.

Bruce.

*From:* Public [mailto:public-boun...@cabforum.org
] *On Behalf Of *Jeremy Rowley
via Public
*Sent:* January 3, 2018 5:25 PM
*To:* geo...@apple.com 
*Cc:* CA/Browser Forum Public Discussion List mailto:public@cabforum.org>>
*Subject:* [EXTERNAL]Re: [cabfpub] Verification of Domain Contact
and Domain Authorization Document

The ambiguity is exactly why we need to remove method 1. I’ve seen
all of the following:

1)Approval based on a name match

2)Approval based on an email match (same email as requester or the
email is a corporate email) – note that this is a Domain Contact match

3)Approval based on address and name match

4)Approval based on a letter from the registrar

5)Approval based on a call to the registrar

6)Approval based on a validation email to the registrar

All of these are equally permitted by the language, IMO, because
“by validating the Applicant has the same name as the Domain
Contact directly with the Domain Name Registrar” can mean a LOT of
things.

*From:* geo...@apple.com 
[mailto:geo...@apple.com]
*Sent:* Wednesday, January 3, 2018 2:54 PM
*To:* Jeremy Rowley mailto:jeremy.row...@digicert.com>>
*Cc:* CA/Browser Forum Public Discussion List mailto:public@cabforum.org>>; Ryan Sleevi mailto:sle...@google.com>>; Adriano Santoni
mailto:adriano.sant...@staff.aruba.it>>
*Subject:* Re: [cabfpub] Verification of Domain Contact and Domain
Authorization Document

It looks like we’re going to be removing 3.2.2.4.1, so this will
be moot, but just to explain the interpretation, 3.2.2.4.1 says
that what you are doing (this sentence is the entire description
of the method, the rest of the section just limits its
application) is "Confirming the Applicant's control over the FQDN
by validating the Applicant is the Domain Contact directly with
the Domain Name Registrar.”

This is not a name match.  If the BRs wanted to say “by validating
the Applicant has the same name as the Domain Contact”, they would
say so.  This is a one-and-the-same match, it uses the word “is”. 
In the example below, the CA must ensure that “Google Inc., the
Utah corporation” is the same one as shown in the WHOIS
information, and all the WHOIS information is relevant in
confirming this.

Another important clarification is that if you use 3.2.2.1, it
doesn’t just verify “the name of the applicant”; it says that "the
CA SHALL verify the identity and address of the organization”, not
just the name.  (Um… actually, if you

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

[Tim Hollebeek via Public]

This characterization of CAs in general is simply not true and I wish you would 
stop making it.  It’s a bunch of overly broad statements and 
mischaracterizations.

 

There are some bad actors out there, and some bad practices out there that need 
to be eliminated, but using that to tar the entire industry with a broad brush 
is misleading in the extreme.

 

-Tim

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Ryan Sleevi via 
Public
Sent: Wednesday, January 3, 2018 10:03 PM
To: Bruce Morton ; CA/Browser Forum Public 
Discussion List 
Subject: Re: [cabfpub] [EXTERNAL]Re: Verification of Domain Contact and Domain 
Authorization Document

 

Given that CAs have competing interests - namely, to sell certificates first 
and foremost, while at the same time not doing anything too egregious to get 
noticed and thus distrusted - I don't think it's reasonable, particularly given 
the economic incentives and industrial behaviour, to suggest that CAs would 
find this as something to reject.

 

Most CAs, at the end of the day, mint certs for money. CAs particularly 
concerned about appearances such as market share are further incentivized to 
make minting certs easier. It is thus unsurprising that this sort of incentive 
structure results in what we might term 'exploitative' (in a security mindset), 
while the CA might call it 'innovative' or 'customer friendly'.

 

On Wed, Jan 3, 2018 at 5:41 PM, Bruce Morton via Public mailto:public@cabforum.org> > wrote:

The requirement may mean a LOT of things, but it is also qualified by language 
such as “This method may only be used if: 1. The CA authenticates the 
Applicant's identity under BR Section 3.2.2.1 and the authority of the 
Applicant Representative under BR Section 3.2.5.”

 

I assume it will be stated that the language in 3.2.2.1 and 3.2.5 also mean a 
LOT of things, but this is the job of the CA to create a policy which is 
effective. Per BR 5, the CA should also do risk assessments and security plans. 
Using this methodology will help the CA close the loopholes in its processes. 
Of course, if the CA still finds the risk too high, then they can stop using 
the method.

 

Bruce.

 

From: Public [mailto:public-boun...@cabforum.org 
 ] On Behalf Of Jeremy Rowley via Public
Sent: January 3, 2018 5:25 PM
To: geo...@apple.com  
Cc: CA/Browser Forum Public Discussion List mailto:public@cabforum.org> >
Subject: [EXTERNAL]Re: [cabfpub] Verification of Domain Contact and Domain 
Authorization Document

 

The ambiguity is exactly why we need to remove method 1. I’ve seen all of the 
following:

1)  Approval based on a name match

2)  Approval based on an email match (same email as requester or the email 
is a corporate email) – note that this is a Domain Contact match

3)  Approval based on address and name match

4)  Approval based on a letter from the registrar

5)  Approval based on a call to the registrar

6)  Approval based on a validation email to the registrar

 

All of these are equally permitted by the language, IMO, because “by validating 
the Applicant has the same name as the Domain Contact directly with the Domain 
Name Registrar” can mean a LOT of things.

 

From: geo...@apple.com   [mailto:geo...@apple.com] 
Sent: Wednesday, January 3, 2018 2:54 PM
To: Jeremy Rowley mailto:jeremy.row...@digicert.com> >
Cc: CA/Browser Forum Public Discussion List mailto:public@cabforum.org> >; Ryan Sleevi mailto:sle...@google.com> >; Adriano Santoni mailto:adriano.sant...@staff.aruba.it> >
Subject: Re: [cabfpub] Verification of Domain Contact and Domain Authorization 
Document

 

It looks like we’re going to be removing 3.2.2.4.1, so this will be moot, but 
just to explain the interpretation, 3.2.2.4.1 says that what you are doing 
(this sentence is the entire description of the method, the rest of the section 
just limits its application) is "Confirming the Applicant's control over the 
FQDN by validating the Applicant is the Domain Contact directly with the Domain 
Name Registrar.”

 

This is not a name match.  If the BRs wanted to say “by validating the 
Applicant has the same name as the Domain Contact”, they would say so.  This is 
a one-and-the-same match, it uses the word “is”.  In the example below, the CA 
must ensure that “Google Inc., the Utah corporation” is the same one as shown 
in the WHOIS information, and all the WHOIS information is relevant in 
confirming this.

 

Another important clarification is that if you use 3.2.2.1, it doesn’t just 
verify “the name of the applicant”; it says that "the CA SHALL verify the 
identity and address of the organization”, not just the name.  (Um… actually, 
if you read it closely, you might not verify the name at all, if you identify 
the organization in another way, maybe with some kind of ID number.  That’s 
probably a bug.)

 

On 2 Jan 2018, at 8:47 pm, Jeremy Rowley mailto:jere

Re: [cabfpub] [EXTERNAL]Re: Ballot 218: Remove validation methods #1 and #5

[Bruce Morton via Public]

Hi Ryan,

Here are some details on how we perform this method.

For an OV certificate, we perform method #1 as follows:


1.  Order is received with the subject name, SANs, a certificate requester 
and an authorization contact. The authorization contact must be employed by the 
organization in the subject name.

2.  BR 3.2.2.1 is performed to confirm the identity of the organization. 
This task is done with using a QIIS.

3.  BR 3.2.2.4.1 is performed using registrar information to confirm the 
organization has registered the domain name. The QIIS is used to identify 
relationships if the domain is registered to a parent or subsidiary.

4.  BR 3.2.5 is performed by finding contact information for the 
organization using a QIIS. The authorization contact is called at the 
organization using this information. The authorization contact is asked to 
confirm that a certificate with the organization name, using the domain name(s) 
requested, can be issued to the certificate requester.


Thanks, Bruce.

From: Ryan Sleevi [mailto:sle...@google.com]
Sent: January 4, 2018 12:09 AM
To: Bruce Morton 
Cc: Rich Smith ; CA/Browser Forum Public Discussion 
List ; Kirk Hall 
Subject: Re: [EXTERNAL]Re: [cabfpub] Ballot 218: Remove validation methods #1 
and #5



On Wed, Jan 3, 2018 at 5:27 PM, Bruce Morton 
mailto:bruce.mor...@entrustdatacard.com>> 
wrote:
I disagree.

Removing, changing and adding back in method #1 is not a productive exercise. 
This method has been used for probably 20 years and yet we never see any 
notifications, articles, alerts, etc. of how this method was defeated by an 
attacker.

I think it's exceptionally dangerous to rest on that, particularly since CAs 
such as Entrust don't make available to the public their processes and controls 
to inspect whether or not they're vulnerable. I am greatly appreciative to 
Jeremy sharing the case of customers from a CA they acquired not being 
validated to the level that DigiCert holds itself - but that's hardly to be 
expected, unless we are to suggest DigiCert should buy out every other CA.

It was this philosophical opposition that resulted in MD5 being exploited 'in 
the wild' - CAs ignoring the literature and research and demanding 'proof it 
applied'

Does Entrust (or the CAs it has acquired) use this method? Can you share the 
details that are used to do this?

I stand by the assertion that while it may be possible to restrict what is done 
under 3.2.2.4.1 to be 'secure', that is not what it is in the language, and 
what is presently executed is demonstrably insecure. If we are to suggest that 
we, as an industry, care about security of our users, then we should make 
tradeoffs that favor security.


Note, I agree that method #1 can be approved in the BRs, but please advise 
which CAs have not already improved this method in practice? If a CA finds a BR 
requirement to be weak, they should either not use it or improve the process in 
their own practices. I assume that many BR requirements were not intended to 
have loopholes, but were written to allow competitiveness in the way they are 
adopted.

Fundamentally, I disagree with this framing. System security works by ensuring 
the minimum level of security is appropriate - not that every CA will be smart 
enough, well-versed in the nuance enough, and/or financially motivated enough 
to 'not be creative'.

I think that the current ballot 218 is bypassing the working group process 
where a working group was created by ballot to improve the validation methods. 
Is this the intension?

This is not, nor has it never been, required by our Bylaws. There have been 
suggestions from some CAs to try to do this, but this has historically turned 
out to be a stalling tactic.

Does Entrust employ 3.2.2.4.1? If so, given that it's required to track the 
validation methods it uses, can you share approximately how many or what 
percentage of certs you use it for, and how you use it? This can go leaps and 
bounds to providing meaningful data about the potential impact to the ecosystem 
from disallowing it, without the deliberative delays.


If we are going to support abrupt ballots, then I would suggest that they at 
least be split into one topic and discuss method #1 and #5 independently.

Finally, what is the rush? Why can’t this change be discussed at the bi-weekly 
CAB Forum meeting or Validation Working Group meeting at least once before a 
pre-ballot is produced? And why effective March 1, 2018? Not only has method #1 
been highly effective for 20 years, but we have also just updated the 
validation methods to support ballot 190. More time would allow CAs to add 
changes to their release cycles and allow Subscribers to learn new validation 
processes they will now have to adopt.

Security comes first. That sounds like a considerable stalling tactic, to be 
honest. Is this because Entrust specifically uses 3.2.2.4.1, or are you 
opposing it on procedural grounds? This, too, will help understand both 

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

[Mads Egil Henriksveen via Public]

Removing method  1 is not the only way to solve this ambiguity, it could also 
be solved by changing the language of 3.2.2.4.1 into something like this 
(changes are redlined in attached document):

3.2.2.4.1 Validating the Applicant as a Domain Name Registrant
Confirming the Applicant's control over the FQDN by validating the Applicant is 
the Domain Name Registrant. This method may only be used if:
1. The CA authenticates the Applicant's identity under BR Section 3.2.2.1 and 
the authority of the Applicant Representative under BR Section 3.2.5, OR
The Applicant identity and address must match the Domain Name Registrant.
2. The CA authenticates the Applicant's identity under EV Guidelines Section 
11.2 and the agency of the Certificate Approver under EV Guidelines Section 
11.8; OR
The Applicant must be the same legal entity as the Domain Name Registrant

Note: Once the FQDN has been validated using this method, the CA MAY also issue 
Certificates for other
FQDNs that end with all the labels of the validated FQDN. This method is 
suitable for validating Wildcard
Domain Names.

This would also allow for using method 1 for the use cases I have identified.

Regards
Mads

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Jeremy Rowley 
via Public
Sent: onsdag 3. januar 2018 23:25
To: geo...@apple.com
Cc: CA/Browser Forum Public Discussion List 
Subject: Re: [cabfpub] Verification of Domain Contact and Domain Authorization 
Document

The ambiguity is exactly why we need to remove method 1. I’ve seen all of the 
following:
1)  Approval based on a name match
2)  Approval based on an email match (same email as requester or the email 
is a corporate email) – note that this is a Domain Contact match
3)  Approval based on address and name match
4)  Approval based on a letter from the registrar
5)  Approval based on a call to the registrar
6)  Approval based on a validation email to the registrar

All of these are equally permitted by the language, IMO, because “by validating 
the Applicant has the same name as the Domain Contact directly with the Domain 
Name Registrar” can mean a LOT of things.

From: geo...@apple.com [mailto:geo...@apple.com]
Sent: Wednesday, January 3, 2018 2:54 PM
To: Jeremy Rowley 
mailto:jeremy.row...@digicert.com>>
Cc: CA/Browser Forum Public Discussion List 
mailto:public@cabforum.org>>; Ryan Sleevi 
mailto:sle...@google.com>>; Adriano Santoni 
mailto:adriano.sant...@staff.aruba.it>>
Subject: Re: [cabfpub] Verification of Domain Contact and Domain Authorization 
Document

It looks like we’re going to be removing 3.2.2.4.1, so this will be moot, but 
just to explain the interpretation, 3.2.2.4.1 says that what you are doing 
(this sentence is the entire description of the method, the rest of the section 
just limits its application) is "Confirming the Applicant's control over the 
FQDN by validating the Applicant is the Domain Contact directly with the Domain 
Name Registrar.”

This is not a name match.  If the BRs wanted to say “by validating the 
Applicant has the same name as the Domain Contact”, they would say so.  This is 
a one-and-the-same match, it uses the word “is”.  In the example below, the CA 
must ensure that “Google Inc., the Utah corporation” is the same one as shown 
in the WHOIS information, and all the WHOIS information is relevant in 
confirming this.

Another important clarification is that if you use 3.2.2.1, it doesn’t just 
verify “the name of the applicant”; it says that "the CA SHALL verify the 
identity and address of the organization”, not just the name.  (Um… actually, 
if you read it closely, you might not verify the name at all, if you identify 
the organization in another way, maybe with some kind of ID number.  That’s 
probably a bug.)

On 2 Jan 2018, at 8:47 pm, Jeremy Rowley 
mailto:jeremy.row...@digicert.com>> wrote:

I disagree. The requirements do not specify that.  All that is required is the 
name of the applicant was verified under 3.2.2.1 and that the register specify 
the domain contact is the applicant. If Google, Inc. is specified as the domain 
contact, no address matching is required.

From: geo...@apple.com [mailto:geo...@apple.com]
Sent: Tuesday, January 2, 2018 4:34 PM
To: Jeremy Rowley 
mailto:jeremy.row...@digicert.com>>; CA/Browser 
Forum Public Discussion List mailto:public@cabforum.org>>
Cc: Ryan Sleevi mailto:sle...@google.com>>; Adriano Santoni 
mailto:adriano.sant...@staff.aruba.it>>
Subject: Re: [cabfpub] Verification of Domain Contact and Domain Authorization 
Document




On Dec 22, 2017, at 12:09 PM, Jeremy Rowley via Public 
mailto:public@cabforum.org>> wrote:

The attack vector is easier than that.

  1.  I use very stringent processes to verify that Google, Inc. is a legit 
company in Utah.
  2.  I verify that Jeremy did indeed incorporate Google, Inc.
  3.  I call Jeremy at the phone listed for Google, Inc., the Utah corporation
  4.  The dom