[cabfpub] Ballot 92 - Subject Alternative Names

Erwann Abalea erwann.abalea at keynectis.com
Tue Nov 20 10:53:44 UTC 2012

The new 9.2.2 clause prohibits this. You can't choose to follow either 
9.2.1 or 9.2.2.

And I personally approve all the proposed changes.


Le 20/11/2012 11:47, Janssen, M.A. (Mark) - Logius a écrit :
> So, do I understand it correctly that an OV cert which includes a 
> Reserved IP Address or an Internal Server Name in the Subject Common 
> Name Field is not prohibited? If so this should be made clear in the 
> ballot.
> Thanks.
> Best Regards,
> *Mark Janssen*
> Senior Advisor PKIoverheid
> ........................................................................
> *Logius
> The ministry of the Interior and Kingdom Relations (BZK)*
> Wilhelmina van Pruisenweg 52 | 2595 AN | The Hague
> P.O. Box 96810 | 2509 JE | The Hague
> ........................................................................
> T +31(0) 70 8887 967
> F +31(0) 70 8887 882
> mark.janssen at logius.nl <mailto:mark.janssen at logius.nl>
> http://www.logius.nl/ 
> <https://webmail.ictu.nl/exchweb/bin/redir.asp?URL=http://www.logius.nl/>
> ........................................................................
> *Service e-government*
> ........................................................................
> Please consider the environment - do you really need to print this mail?
> *Van:*public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] 
> *Namens *Jeremy Rowley
> *Verzonden:* donderdag 15 november 2012 23:27
> *Aan:* richard.smith at comodo.com; 'Steve Roylance'; public at cabforum.org
> *Onderwerp:* Re: [cabfpub] Ballot 92 - Subject Alternative Names
> The reason is the same as the rest of the changes in this ballot.  
> Relying parties should have some information about the entity behind a 
> certificate.  With internal servers names, there isn't a link between 
> a validated domain and a specific entity.  With a DV certificate, this 
> problem is exasperated since the relying party has absolutely no 
> information about the certificate holder of an internal name 
> certificate (a DV certificate containing only mail.server contains no 
> independently verified information)   This change ensures that all 
> certificates are tied to some verified information.
> Jeremy
> *From:*public-bounces at cabforum.org 
> <mailto:public-bounces at cabforum.org> 
> [mailto:public-bounces at cabforum.org] *On Behalf Of *Rich Smith
> *Sent:* Thursday, November 15, 2012 2:52 PM
> *To:* 'Steve Roylance'; public at cabforum.org <mailto: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> 
> [mailto:public-bounces at cabforum.org] 
> <mailto:[mailto:public-bounces at cabforum.org]> *On Behalf Of *Steve 
> Roylance
> *Sent:* Thursday, November 15, 2012 12:28 PM
> *To:* public at cabforum.org <mailto:public at cabforum.org>; CABForum 
> Management
> *Subject:* [cabfpub] Ballot 92 - Subject Alternative Names
> 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
> 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", "*.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/. 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 abstaining.
> ------------------------------------------------------------------------
> Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien 
> u niet de geadresseerde bent of dit bericht abusievelijk aan u is 
> toegezonden, wordt u verzocht dat aan de afzender te melden en het 
> bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor 
> schade, van welke aard ook, die verband houdt met risico's verbonden 
> aan het elektronisch verzenden van berichten.
> This message may contain information that is not intended for you. If 
> you are not the addressee or if this message was sent to you by 
> mistake, you are requested to inform the sender and delete the 
> message. The State accepts no liability for damage of any kind 
> resulting from the risks inherent in the electronic transmission of 
> messages. .
> _______________________________________________
> 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/20121120/c4498406/attachment-0004.html>

More information about the Public mailing list