[cabfpub] FW: BR – Contradiction on gTLDs

Wed May 25 04:00:06 MST 2016

Replacing 4.2.2 with "No Stipulation" sooner than 2016-10-01 introduces new
risk.

2016-10-01 is the "revoke all Internal name certificates" (see 7.1.4.2.1).
The current Section 4.2.2 includes an "advance revocation" timeline for
names that ICANN is contracting with. I suspect further massaging is
necessary to retain that paragraph. (While I'm aware that even if we passed
a ballot two weeks from now, it would be after 1 October 2016, I'm
concerned for the set of domains approved by ICANN whose 120 day period
would occur between now and 1 October 2016)

I'm sure this level of pedantry comes as no surprise.

The other is still the desire to decouple underscores from the wildcard
bits. The underscores in the DNS are gross, not permitted today, and cause
enough interoperability trouble that even if some are using them, aren't
something to be encouraged. People who absolutely insist on such
certificates can be met with wildcards, but again, it's something that
should be deprecated, not encouraged.

On Wed, May 25, 2016 at 3:39 AM, Jeremy Rowley <jeremy.rowley at digicert.com>
wrote:

> Sounds great. Thanks Tim.
>
>
>
> *From:* Tim Hollebeek [mailto:THollebeek at trustwave.com]
> *Sent:* Wednesday, May 25, 2016 4:10 AM
> *To:* Jeremy Rowley <jeremy.rowley at digicert.com>; Richard Barnes <
> rbarnes at mozilla.com>; Ryan Sleevi <sleevi at google.com>
> *Cc:* Dean Coclin <Dean_Coclin at symantec.com>; public at cabforum.org
> *Subject:* RE: [cabfpub] FW: BR – Contradiction on gTLDs
>
>
>
>
>
> How about replacing:
>
>
>
> *As exceptions to RFC5280 and X.509, Wildcard Domain Names are permitted
> in dNSName entries and the underscore character ("_") is permitted in FQDNs
> and Wildcard Domain Names in any location where the hyphen character ("-")
> is allowed. Wildcard Domain Names are not allowed in SRVName entries.*
>
>
>
> With:
>
>
>
> *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.*
>
>
>
> Just to make it clear these are requirements.
>
>
>
> -Tim
>
>
>
> *From:* public-bounces at cabforum.org [mailto:public-bounces at cabforum.org
> <public-bounces at cabforum.org>] *On Behalf Of *Jeremy Rowley
> *Sent:* Wednesday, May 25, 2016 11:59 AM
> *To:* Richard Barnes; Ryan Sleevi
> *Cc:* Dean Coclin; public at cabforum.org
> *Subject:* Re: [cabfpub] FW: BR – Contradiction on gTLDs
>
>
>
> Could we combine this with Peter’s SRV ballot since they affect the same
> section?  Here’s a first draft of a potential 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, Wildcard Domain Names are permitted
> in dNSName entries and the underscore character ("_") is permitted in FQDNs
> and Wildcard Domain Names in any location where the hyphen character ("-")
> is allowed. Wildcard Domain Names are not allowed in SRVName entries.*
>
>
>
> *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 where the Name portion is in an excluded dNSName subtree.  Such a
> CA also MUST NOT issue certificates containing SRVNames where the Name
> portion is not in a permitted dNSName subtree if at least one permitted
> dNSName subtree exists.*
>
>
>
> 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 CA 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
> <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>
> *Cc:* Dean Coclin <Dean_Coclin at symantec.com>; 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> 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>
> 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
> https://cabforum.org/mailman/listinfo/public
> <http://scanmail.trustwave.com/?c=4062&d=iPfF1xNvY-Di6rdPKoXw30G5ElNV25Leun0oJee3Ug&s=5&u=https%3a%2f%2fcabforum%2eorg%2fmailman%2flistinfo%2fpublic>
>
>
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
> <http://scanmail.trustwave.com/?c=4062&d=iPfF1xNvY-Di6rdPKoXw30G5ElNV25Leun0oJee3Ug&s=5&u=https%3a%2f%2fcabforum%2eorg%2fmailman%2flistinfo%2fpublic>
>
>
>
>
> ------------------------------
>
>
> This transmission may contain information that is privileged,
> confidential, and/or exempt from disclosure under applicable law. If you
> are not the intended recipient, you are hereby notified that any
> disclosure, copying, distribution, or use of the information contained
> herein (including any reliance thereon) is strictly prohibited. If you
> received this transmission in error, please immediately contact the sender
> and destroy the material in its entirety, whether in electronic or hard
> copy format.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20160525/bada3131/attachment-0001.html 