[cabfpub] [EXTERNAL]Re: Verification of Domain Contact and Domain Authorization Document
Adriano Santoni
adriano.santoni at staff.aruba.it
Thu Jan 4 15:24:29 UTC 2018
👍
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-bounces at cabforum.org] *On Behalf Of
> *Ryan Sleevi via Public
> *Sent:* Wednesday, January 3, 2018 10:03 PM
> *To:* Bruce Morton <Bruce.Morton at entrustdatacard.com>; CA/Browser
> Forum Public Discussion List <public at cabforum.org>
> *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 at cabforum.org <mailto:public at 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-bounces at cabforum.org
> <mailto:public-bounces at cabforum.org>] *On Behalf Of *Jeremy Rowley
> via Public
> *Sent:* January 3, 2018 5:25 PM
> *To:* geoffk at apple.com <mailto:geoffk at apple.com>
> *Cc:* CA/Browser Forum Public Discussion List <public at cabforum.org
> <mailto:public at 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:* geoffk at apple.com <mailto:geoffk at apple.com>
> [mailto:geoffk at apple.com]
> *Sent:* Wednesday, January 3, 2018 2:54 PM
> *To:* Jeremy Rowley <jeremy.rowley at digicert.com
> <mailto:jeremy.rowley at digicert.com>>
> *Cc:* CA/Browser Forum Public Discussion List <public at cabforum.org
> <mailto:public at cabforum.org>>; Ryan Sleevi <sleevi at google.com
> <mailto:sleevi at google.com>>; Adriano Santoni
> <adriano.santoni at staff.aruba.it
> <mailto:adriano.santoni at 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
> <jeremy.rowley at digicert.com
> <mailto:jeremy.rowley at 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:*geoffk at apple.com <mailto:geoffk at apple.com>
> [mailto:geoffk at apple.com]
> *Sent:*Tuesday, January 2, 2018 4:34 PM
> *To:*Jeremy Rowley <jeremy.rowley at digicert.com
> <mailto:jeremy.rowley at digicert.com>>; CA/Browser Forum Public
> Discussion List <public at cabforum.org <mailto:public at cabforum.org>>
> *Cc:*Ryan Sleevi <sleevi at google.com
> <mailto:sleevi at google.com>>; Adriano Santoni
> <adriano.santoni at staff.aruba.it
> <mailto:adriano.santoni at 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 at cabforum.org <mailto:public at 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 domain information shows Google, Inc. as
> owninggoogle.com <http://google.com/>
> 5. Certificate issues.
>
> Obviously this would be caught in every CA’s high risk
> checks, but the point remains valid. Regardless of the
> expertise and thoroughness of the org check, the specs
> lack any time between the verified org and the actual
> domain because orgs are not unique on a global basis.
>
> For item 4, you have to verify that “the Applicant is the
> Domain Contact”. Obviously it’s insufficient to just compare
> names—you must verify every element of the WHOIS contact
> matches the Applicant, that’s typically name, postal address,
> phone number, and e-mail.
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org <mailto:Public at cabforum.org>
> https://cabforum.org/mailman/listinfo/public
>
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20180104/a014620d/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4025 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.cabforum.org/pipermail/public/attachments/20180104/a014620d/attachment-0003.p7s>
More information about the Public
mailing list