[cabf_validation] [cabfpub] FW: BR – Contradiction on gTLDs

Thu Jun 2 08:25:03 MST 2016

Updated draft of the SRV ballot:

The following motion has been proposed by ___________________ and endorsed by ____________________:

-- MOTION BEGINS –

Effective immediately, the follow changes are made to the Baseline Requirements:

A)    Section 4.2.2 of the Baseline Requirements is replaced with “No Stipulation”

B)    Add the following definition to Section 1.6.1: 

Wildcard Domain Name: A Domain Name formed by prepending '*.' to a FQDN.

C)    Section 7.1.4.2.1 is amended as follows: 

Certificate Field: extensions:subjectAltName 

Required/Optional: Required 

Contents: This extension MUST contain at least one entry. Each entry MUST be either a dNSName containing the Fully‐Qualified Domain Name, Wildcard Domain Name, or an iPAddress containing the IP address of a server, or an otherName of type SRVName as defined in RFC4985. An entry MUST NOT be an Internal name or Reserved IP Address. The CA MUST confirm the entry as follows:

a)      For a Fully‐Qualified Domain Name or Wildcard Domain Name entry, the CA MUST verify the entry in accordance with Section 3.2.2.4;

b)     For a SRVName entry, the CA MUST verify the Name portion of the entry in accordance with Section 3.2.2.4; and 

c)      For an IP address entry, the CA MUST verify the entry in accordance with Section 3.2.2.5 or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate. Wildcard FQDNs are permitted. 

As exceptions to RFC5280 and X.509, dNSName entries MAY contain Wildcard Domain Names, and FQDNs and Wildcard Domain Names MAY contain the underscore character ("_") in any location where the hyphen character ("-") is allowed. SRVName entries MUST NOT contain Wildcard Domain Names.

If a name constrained CA has a dNSName constraint but does not have a constraint for SRVNames, the CA MUST NOT issue certificates containing SRVNames.

As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name, 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. Also as of the Effective Date, the CAs SHALL NOT issue a certificate with an Expiry Date later than 1 November 2015 with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal 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 Name. Effective May 1, 2015, each CA SHALL revoke all unexpired Certificates with an Internal Name using onion as the right‐most label in an entry in the subjectAltName Extension or commonName field unless such Certificate was issued in accordance with Appendix F of the EV Guidelines.

---- END BALLOT ----

From: public-bounces at cabforum.org <mailto:public-bounces at cabforum.org>  [mailto:public-bounces at cabforum.org] On Behalf Of Richard Barnes
Sent: Tuesday, May 24, 2016 6:59 AM
To: Ryan Sleevi <sleevi at google.com <mailto:sleevi at google.com> >
Cc: Dean Coclin <Dean_Coclin at symantec.com <mailto:Dean_Coclin at symantec.com> >; public at cabforum.org <mailto:public at cabforum.org> 
Subject: Re: [cabfpub] FW: BR – Contradiction on gTLDs

+1

On Tue, May 24, 2016 at 6:08 AM, Ryan Sleevi <sleevi at google.com <mailto:sleevi at google.com> > wrote:

Yes, this is just one of the 'legacy leftovers' that could be cleaned up in a subsequent ballot. CAs MUST NOT issue certificates for Internal Names now.

On Tue, May 24, 2016 at 2:52 AM, Dean Coclin <Dean_Coclin at symantec.com <mailto:Dean_Coclin at symantec.com> > wrote:

Forum-Please review this question.

Dean

From: Adam, Daniel (US - San Francisco) 
Sent: Friday, May 20, 2016 3:59 AM
To: Sheehy, Don 
Subject: Can you send this to the CA/B Forum public list?

Subject: BR – Contradiction on gTLDs

Baseline Requirements 1.3.4 defines an ‘Internal Name’ as: A string of characters (not an IP address) in a Common Name or Subject Alternative Name field of a Certificate that cannot be verified as globally unique within the public DNS at the time of certificate issuance because it does not end with a Top Level Domain registered in IANA’s Root Zone Database.

Section 4.2.2 states that CAs SHOULD NOT issue certificates containing new gTLDs under consideration by ICANN and warn the applicant of this etc.. This suggests that, although not recommended, it is still permissible for CAs to issue these type of certificates. However, this appears to be contradicted in Section 7.1.4.2.1 which states that CAs SHALL NOT issue certificates containing an Internal Name that expire later than 1 November 2015. Since we are well past that date, this is interpreted as CAs SHALL NOT issue any more certificates containing Internal Names, which includes any gTLDs that are under consideration by ICANN as those are publically unresolvable (and by definition, an ‘Internal Name’) until the day they are included in the IANA Root Zone.

Therefore, isn’t this criterion in 4.2.2 redundant as these certificates are not supposed to be issued anymore?

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

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/validation/attachments/20160602/0d71e4f6/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4964 bytes
Desc: not available
Url : https://cabforum.org/pipermail/validation/attachments/20160602/0d71e4f6/attachment-0001.bin 