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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
