[cabfpub] Ballot 92 - Subject Alternative Names
steve.roylance at globalsign.com
Fri Nov 16 09:19:47 UTC 2012
I know that Jeremy answered on my behalf, but as you addressed to me I
wanted to reply too. Please see the reply to Ryan Sleevi on this subject
where I provide some more information. Basically we want to stop the
ability to create 'ownerless' skeleton keys.
From: Rich Smith <richard.smith at comodo.com>
Organization: Comodo Group, Inc.
Reply-To: <richard.smith at comodo.com>
Date: Thursday, 15 November 2012 21:52
To: Steve Roylance <steve.roylance at globalsign.com>, <public at cabforum.org>
Subject: RE: [cabfpub] Ballot 92 - Subject Alternative Names
Since many clients and servers will still choke on a cert with no Common
Name. Prohibiting Reserved IPs and Internal host names in the CN field
effectively prohibits single site certificates for Reserved IPs and internal
names. What's the reasoning behind this?
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Steve Roylance
Sent: Thursday, November 15, 2012 12:28 PM
To: public at cabforum.org; CABForum Management
Subject: [cabfpub] Ballot 92 - Subject Alternative Names
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
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
9.2.1 Subject Alternative Name Extension
Certificate Field: extensions:subjectAltName
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
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 126.96.36.199)
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 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”, “*.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 “*.co.uk”, but MAY issue
“*.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
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
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 5001 bytes
Desc: not available
More information about the Public