[cabfpub] Ballot 96 - Wildcard Certificates and New gTLDs

[Eddy Nigg (StartCom Ltd.)]

On 02/05/2013 11:39 PM, From Jeremy Rowley:
> Jeremy Rowley made the following motion, and Rick Andrews and Steve 
> Roylance endorsed it:
>

StartCom votes NO.

Explanation - the proposed change regarding the wild cards is redundant 
since the CA is required to confirm a domain control or ownership of the 
relevant domain name. Since no *.com validation should be possible, the 
proposed safeguards are redundant and not necessary.

Regarding the proposed change in respect to new generic TLDs, since no 
domain control validation could have been performed by the CA in the 
past for any non-existing TLD, we believe certificates containing such 
non-existing TLDs shouldn't be issued in first place. Also such 
certificates will be disallowed in the future according to the BR itself 
and we believe that this practice should have been abolished in the past 
already.

We don't think it's wise to give any exclusions at all and this process 
and proposed change to the BR is suspect to be prone to failures and 
mistakes. Therefore we cannot support this ballot.

> Add the following as new Section 11.1.3:
>
> 11.1    Authorization by Domain Name Registrant
>
> 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 MUST refuse issuance unless 
> the applicant proves its rightful control of the entire Domain 
> Namespace. (e.g. CAs MUST NOT issue “*.co.uk” or “*.local”, but MAY 
> issue “*.example.com” to Example Co.).
>
> Prior to September 1, 2013, each CA MUST revoke any valid certificate 
> that does not comply with this section of the Requirements.
>
> †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.
>
> Add the following as new Section 11.1.4:
>
> 11.1.4 New gTLD Domains
>
> CAs SHOULD NOT issue Certificates containing a new gTLD under 
> consideration by ICANN. Prior to issuing a Certificate containing an 
> Internal Server Name with a gTLD that ICANN has announced as under 
> consideration to make operational, the CA MUST provide a warning to 
> the applicant that the gTLD may soon become resolvable and that, at 
> that time, the CA will revoke the Certificate unless the applicant 
> promptly registers the domain name.
>
> Within 30 days after ICANN has approved a new gTLD for operation, as 
> evidenced by  publication of a contract with the gTLD operator on 
> [www.icann.org] each CA MUST (1) compare the new gTLD against the CA’s 
> records of valid certificates and (2) cease issuing Certificates 
> containing a Domain Name that includes the new gTLD until after the CA 
> has first verified the Subscriber's control over or exclusive right to 
> use the Domain Name  in accordance with Section 11.1.
>
> Within 120 days after the publication of a contract for a new gTLD is 
> published on [www.icann.org], CAs MUST revoke each Certificate 
> containing a Domain Name that includes the new gTLD unless the 
> Subscriber is either the Domain Name Registrant or can demonstrate 
> control over the Domain Name.
>
> ... Erratum Ends ...
>
>


Regards
Signer: 	Eddy Nigg, COO/CTO
	StartCom Ltd. <http://www.startcom.org>
XMPP: 	startcom at startcom.org <xmpp:startcom at startcom.org>
Blog: 	Join the Revolution! <http://blog.startcom.org>
Twitter: 	Follow Me <http://twitter.com/eddy_nigg>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20130215/6593c615/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4540 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.cabforum.org/pipermail/public/attachments/20130215/6593c615/attachment-0001.p7s>