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

J.C. Jones jjones at mozilla.com
Mon Jun 6 12:48:40 MST 2016


Peter, Jeremy:

This ballot text looks good to me as well.

J.C.

On Fri, Jun 3, 2016 at 8:48 PM, Peter Bowen <pzb at amzn.com> wrote:

> Looks good to me.  If others agree it looks good, I’ll see about endorsing.
>
> > On Jun 2, 2016, at 8:25 AM, Jeremy Rowley <jeremy.rowley at digicert.com>
> wrote:
> >
> > 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, theCAs 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]
> 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
> >
> >
> >
> > _______________________________________________
> > Public mailing list
> > Public at cabforum.org
> > https://cabforum.org/mailman/listinfo/public
> >
> >
> > _______________________________________________
> > Validation mailing list
> > Validation at cabforum.org
> > https://cabforum.org/mailman/listinfo/validation
>
> _______________________________________________
> Validation mailing list
> Validation at cabforum.org
> https://cabforum.org/mailman/listinfo/validation
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/validation/attachments/20160606/12395ea0/attachment.html 


More information about the Validation mailing list