[cabfpub] Proposed Ballot 183 - Allowing 822 Names and (limited) otherNames

Jeremy Rowley jeremy.rowley at digicert.com
Tue Jan 3 13:46:36 MST 2017


There is a public file (in the link I provided), but it requires filling out information to access. It’s the HotSpot 2.0 Technical documentation, which includes the Certificate Policy (“Hostspot 2-0 (R2) OSU Certificate Policy Specification”).  The documentation is already free to anyone who wants to enter information and agree to the terms of use.  

 

We essentially already have a liaison member from the WFA (DigiCert, Microsoft, Apple, and Google are all members). 

 

From: Ryan Sleevi [mailto:sleevi at google.com] 
Sent: Tuesday, January 3, 2017 1:39 PM
To: Jeremy Rowley <jeremy.rowley at digicert.com>
Cc: CA/Browser Forum Public Discussion List <public at cabforum.org>; Peter Bowen <pzb at amzn.com>
Subject: Re: [cabfpub] Proposed Ballot 183 - Allowing 822 Names and (limited) otherNames

 

I guess I would be more precise: Can you specify a specific document to adhere to? A specific (public) process to evaluate?

 

I think finding support for this is mostly about finding ways to minimize risk for misissuance.

 

Should we expect/desire to have a liason member from the WFA? Should we encourage/require that such specifications be freely available in order to make use of / share the Web PKI? How do we avoid a situation, say, in N years, where the WFA members are asking for special exceptions to whatever the latest deprecation is?

 

On Tue, Jan 3, 2017 at 12:32 PM, Jeremy Rowley <jeremy.rowley at digicert.com <mailto:jeremy.rowley at digicert.com> > wrote:

They don’t publish a lot of information publicly. The documentation for how they use friendly-names is here: https://www.wi-fi.org/discover-wi-fi/wi-fi-certified-passpoint. As WFA is an actual organization, a single mebmer saying something okay is not the same as the entity approving something, but I see your point. Perhaps something that specifies it must be ratified and published ( For each id-wfa-hotspot-friendlyName entry, the CA MUST only include entries after receiving permission from the WiFi Alliance to utilize the id-wfa-hotspot-friendlyName type and MUST verify each entry in accordance with the requirements ratified and published by the WiFi Alliance. )?

 

7.1.4.2.1. Subject Alternative Name Extension 

Certificate Field: extensions:subjectAltName 

Required/Optional: Required 

Contents: This extension MUST contain at least one entry. Each entry MUST be one of the following entries: 1) either a dNSName containing the Fully‐Qualified Domain Name or a Wildcard Domain Name, 2)  or an iPAddress containing the IP address of a server,3) a rfc822Name containing an RFC 5322 email address, 4) an otherName with a id-wfa-hotspot-friendlyName type { 1.3.6.1.4.1.40808.1.1.1 } or 5) an otherName of type SRVName as defined in RFC4986.  The CA MUST confirm each entry as follows:

A)      For each dNSName entry, the CA MUST verify the entry in accordance with Section 3.2.2.4;

B)      For each SRVName entry, the CA MUST verify the Name portion of the entry in accordance with Section 3.2.2.4;

C)      For each iPAddress entry, the CA MUST verify the entry in accordance with Section 3.2.2.5;

D)      For each id-wfa-hotspot-friendlyName entry, the CA MUST only include entries after receiving permission from the WiFi Alliance to utilize the id-wfa-hotspot-friendlyName type and MUST verify each entry in accordance with the requirements ratified and published by the WiFi Alliance.    

 As an exception to RFC5280 and X.509, dNSName entries MAY contain Wildcard Domain Names. SRVName entries MUST NOT contain Wildcard Domain Names. If a name constrained CA has a dNSNAme constrain but does not have a constraint for SRVNames, the CA MUST NOT issue certificates containing SRVNames.

 that the Applicant controls the Fully‐Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate. Wildcard FQDNs are permitted. 

 For dNSNames, SRVNames, and iPAddress entries: 

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.

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20170103/8dd710b9/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: <http://cabforum.org/pipermail/public/attachments/20170103/8dd710b9/attachment-0001.bin>


More information about the Public mailing list