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 <[email protected]> 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. * *T*he 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. > > > > >
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
