[cabfpub] Ballot 92 - Subject Alternative Names
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
> Best Regards,
> *Mark Janssen*
> Senior Advisor PKIoverheid
> 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>
> *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.
> *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
> *Sent:* Thursday, November 15, 2012 12:28 PM
> *To:* public at cabforum.org <mailto:public at cabforum.org>; CABForum
> *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
> 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
> 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 188.8.131.52)
> 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
> *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
> ... 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Public