[cabfpub] EV Wildcards

Fri Mar 20 22:07:48 UTC 2015

“Globalsign does follow what we believe to be best practice by not allowing
mixed domain ownership at a DV level without identifying a true owner to
relying parties”

Steve-can you clarify the statement above and how it relates to the cert
shown in this post:
http://news.netcraft.com/archives/2013/10/07/phishers-using-cloudflare-for-s
sl.html

I may be misinterpreting what is shown so please correct me if that is the
case but how does a relying party know who the true owner is of
“chounyuu.com” (one of the SANs in that cert) for example?

Dean

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Steve Roylance
Sent: Friday, March 20, 2015 5:30 AM
To: public at cabforum.org
Subject: Re: [cabfpub] EV Wildcards

Hi all.

Just to set the history books straight, on my vote from Nov 2012, which
almost got through bar one browser.  It was not to prevent the use of
wildcards, but to allow the  clear identify the owner of the public private
key pair to be displayed when multiple FQDNs were added to a Domain
Validated certificate where those FQDNs did not have the same base domain.
e.g. If you wanted foo.com and foo.co.uk you needed to have an OV, but
foo.bar.com and bar.com was acceptable as a DV (Which is I guess suggesting
a stronger form of Wildcard if you look at it this way, but not quite as we
wanted to keep the option of wildcards but prevent what’s still possible
today which is effectively wild/mixed domains.  We wanted to ensure that the
person who owned or controlled the key pair was clearly identified in the
case of mixed FQDNs and it was not up to the relying party to try to ‘guess’
which of the domain names included in a certificate might be the one
owning/controlling the key pair on behalf of the others (As you cannot
assume it’s the domain name which floats up to the deprecated CN  position
or is first in the SAN list).

It’s very topical now to discussions considering the need to identify the
owner of key pairs operated by CA’s on behalf of others and yes, Globalsign
does follow what we believe to be best practice by not allowing mixed domain
ownership at a DV level without identifying a true owner to relying parties.

How time goes by so quickly!

From: Steve Roylance < <mailto:steve.roylance at globalsign.com>
steve.roylance at globalsign.com>
Date: Thursday, 15 November 2012 17:27
To: < <mailto:public at cabforum.org> public at cabforum.org>, CABForum Management
< <mailto:management at cabforum.org> management at cabforum.org>
Subject: Ballot 92 - Subject Alternative Names

 <https://www.cabforum.org/wiki/92%20-%20Subject%20Alternative%20Names>
https://www.cabforum.org/wiki/92%20-%20Subject%20Alternative%20Names

Steve Roylance of GlobalSign made the following motion and Yngve Pettersen
of Opera and Jeremy Rowley of Digicert have endorsed it:

... Motion begins...

Effective on the 1st July 2013

... Erratum begins ...

The following sections will be amended in the Baseline Requirements
document.

INSERT in Section 4. Definitions the following:

Public IP Address: An IP Address that is not a Reserved IP Address.

REPLACE Section 9.2.1 (Subject Alternative Name Extension) with the
following:

9.2.1 Subject Alternative Name Extension

Certificate Field: extensions:subjectAltName

Required/Optional: Required

Contents: This extension MUST contain at least one entry that is either a
Fully-Qualified Domain Name or Public IP Address. Each subjectAltName entry
MUST either be a Domain Name or an IP Address. The CA MUST confirm the
Applicant’s control of each dNSName or Public IP Address entry in accordance
with Section 11.1.

SubjectAltName entries MAY include domain Names containing wildcard
characters.

If the subjectAltName is:

1) a Public IP Address,

2) a Registered Domain Name that has a Domain Name Registrant different than
(and not an Affiliate of) the Domain Name Registrant of any other Registered
Domain Name in the subjectAltName extension in the Certificate, or

3) a Reserved IP Address or Internal Server Name.

then the CA MUST verify the identity of an entity that controls the private
key in accordance with Section 11.2 and include the Subject Identity
Information in the issued Certificate in accordance with 9.2.4. The CA MAY
include explanatory information in the Subject Organizational Unit field or
a non-subject certificate field to clarify the Subject Identity Information
included in the Certificate.

Prior to issuing a Certificate containing an Internal Server Name or
Reserved IP Address, the CA SHALL notify the Applicant that the use of such
Certificates has been deprecated by the CA / Browser Forum and that the
practice will be eliminated by October 2016. As of the Effective Date, the
CA SHALL NOT issue a certificate with an Expiry Date later than 1 November
2015 if the subjectAlternativeName contains a Reserved IP Address or
Internal Server Name. Effective 1 October 2016, CAs SHALL revoke all
unexpired Certificates whose subjectAlternativeName extension or Subject
commonName field contains a Reserved IP Address or Internal Server Name.

REPLACE Section 9.2.2 (Subject Common Name Field) with the following:

9.2.2 Subject Common Name Field

Certificate Field: subject:commonName (OID 2.5.4.3)

Required/Optional: Deprecated (Discouraged, but not prohibited)

Contents: If present, this field MUST contain a single Public IP address or
single Fully-Qualified Domain Name that is one of the values contained in
the Certificate’s subjectAltName extension (see Section 9.2.1). Reserved IP
Addresses and Internal Server Names are prohibited.

REPLACE Section 10.2.3 (Information Requirements) with the following:

10.2.3 Information Requirements

The certificate request MAY include all factual information about the
Applicant to be included in the Certificate, and such additional information
as is necessary for the CA to obtain from the Applicant in order to comply
with these Requirements and the CA’s Certificate Policy and/or Certification
Practice Statement. In cases where the certificate request does not contain
all the necessary information about the Applicant, the CA SHALL obtain the
remaining information from the Applicant or, having obtained it from a
reliable, independent, third-party data source, confirm it with the
Applicant.

Applicant information MUST include, but not be limited to, at least one
Subject Alternative Name as defined in Section 9.2.1.

INSERT in Section 11.1 (Authorization by Domain Name Registrant) the
following two new sections:

11.1.3 Wildcard Domain Validation

Before issuing a certificate with a wildcard character (*) in a CN or
subjectAltName of type DNS-ID, the CA MUST establish and follow a documented
procedure† that determines if the wildcard character occurs in the first
label position to the left of a “registry-controlled” label or “public
suffix” (e.g. “*.com”, “*. <http://co.uk/> co.uk”, see RFC 6454 Section 8.2
for further explanation). If a wildcard would fall within the label
immediately to the left of a registry-controlled† or public suffix, CAs
SHALL refuse issuance unless the applicant proves its rightful control of
the entire Domain Namespace. (e.g. CAs SHALL NOT issue “*. <http://co.uk/>
co.uk”, but MAY issue “*. <http://example.co.uk/> example.co.uk” to Example
Ltd.)

†Determination of what is “registry-controlled” versus the registerable
portion of a Country Code Top-Level Domain Namespace is not standardized at
the time of writing and is not a property of the DNS itself. Current best
practice is to consult a “public suffix list” such as
<http://publicsuffix.org/> http://publicsuffix.org/. If the process for
making this determination is standardized by an RFC, then such a procedure
SHOULD be preferred.

... Erratum ends ...

The review period for this ballot shall commence at 21:00 UTC on 15 November
2012 and will close at 21:00 UTC on 22 November 2012. Unless the motion is
withdrawn during the review period, the voting period will start immediately
thereafter and will close at 21:00 UTC on 29 November 2012. Votes must be
cast by posting an on-list reply to this thread.

... Motions ends ...

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:  <http://www.cabforum.org/forum.html>
http://www.cabforum.org/forum.html

In order for the motion to be adopted, two thirds or more of the votes cast
by members in the CA category and one half or more of the votes cast by
members in the browser category must be in favor. Also, at least six members
must participate in the ballot, either by voting in favor, voting against or
abstaining.

Steve

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Jeremy Rowley
Sent: 19 March 2015 23:26
To: Eddy Nigg; public at cabforum.org
Subject: Re: [cabfpub] EV Wildcards

Oh yeah.  I forgot to mention another proposal was to eliminate wildcard
certs for DV.  This was raised a while ago by Globalsign and actually went
to a ballot. It failed at that time by browser vote.

Resurrection of this proposal was brought up at the face-to-face, but there
wasn’t significant discussion there (since the topic was primarily about EV
wildcards, not DV)

Jeremy

From:  <mailto:public-bounces at cabforum.org> public-bounces at cabforum.org [
<mailto:public-bounces at cabforum.org> mailto:public-bounces at cabforum.org] On
Behalf Of Eddy Nigg
Sent: Thursday, March 19, 2015 5:21 PM
To: Jeremy Rowley;  <mailto:public at cabforum.org> public at cabforum.org
Subject: Re: [cabfpub] EV Wildcards

Thanks again Jeremy!

I would like to state the following fact as food for thought on this
subject....

Today one can secure a (main) site with an EV certificate and have all
content of that site including frames and iframes secured with a regular SSL
certificate including wild cards. Browsers have always allowed this with the
notable exception of Opera that had at some point a configuration setting
for an "All EV" requirement. So if you are on an EV site, this doesn't mean
that your connection is really secured with EV - a lot of information can be
still leaked to other parties that have not undergone an extended validation
and that's usually not what you want (but you don't know usually).

If we consider this fact, I can't see why EV shouldn't be wild card enabled.
Or to take it a step further, why should wild cards be possible with some
weak domain control validation only? It's widely known that such wild card
DVs can be easily abused.

On the other hand, EV has undergone a serious verification and the use of an
EV certificates for malicious purpose by the certificate holder is almost
zero. Except if it loses the key or something, but that's an entirely
different story.

On 03/20/2015 01:00 AM, Jeremy Rowley wrote:

During the face-to-face, the forum discussed allowing wildcard characters in
EV certificates.  The reasons for allowing it were:

1)      The lack of wildcard characters is one reason many large enterprises
choose OV/DV over EV.  As entities move increasingly to cloud-based
solutions and as IPv4 addresses become an increasingly limited resource,
wildcards are being used in more and more places. 

2)      EV domain validation is tied to the baseline requirements.  The
baseline requirements, even with the proposed domain validation revisions,
permit validation of the base domain of an FQDN.  Validation does not
necessarily happen at each subdomain level. Therefore, putting wildcard
characters doesn’t increase the risk as CAs aren’t looking specifically at
the FQDN (except as part of the high risk check).

The reasons against allowing it were:

1)      CAs are looking at the FQDN as part of the high risk check.  (The
counter to this was that high risk checks are highly language and CA
dependent – I might not catch that bankofamerica.mydomain.com is a high risk
domain if I’m operating outside the US)

2)      Eliminating wildcards ensures the requester knows exactly what
domains are being covered by the EV cert. 

There were probably more arguments for and against, but I think this gets
the discussion started. 

Jeremy

_______________________________________________
Public mailing list
 <mailto:Public at cabforum.org> Public at cabforum.org
 <https://cabforum.org/mailman/listinfo/public>
https://cabforum.org/mailman/listinfo/public

-- 

Regards 

Signer: 

Eddy Nigg, COO/CTO

 <http://www.startcom.org> StartCom Ltd.

XMPP: 

 <xmpp:startcom at startcom.org> startcom at startcom.org

Blog: 

 <http://blog.startcom.org> Join the Revolution!

Twitter: 

 <http://twitter.com/eddy_nigg> Follow Me

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20150320/38e59de1/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6130 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20150320/38e59de1/attachment-0001.p7s>