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

Ryan Sleevi sleevi at google.com
Tue Jan 3 13:39:12 MST 2017


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>
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.
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20170103/6e6dc836/attachment.html>


More information about the Public mailing list