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

Tue Jan 3 20:16:14 UTC 2017

That still seems exceptionally vague for wfa-hotspot-friendlyName. Could
you tighten it up, or explain why it's ambiguous?

For example, if an individual member of the WiFi Alliance says "Yeah,
that's OK", is that deemed appropriate?

On Tue, Jan 3, 2017 at 12:13 PM, Jeremy Rowley via Public <
public at cabforum.org> wrote:

> Sure – I thought I’d keep it more general than that in case we wanted to
> include additional otherNames, but we can always address scenarios as they
> arise.
>
>
>
> Assuming the otherName for WFA is non-controversial, we can combine the
> SRV ballot with this proposal:
>
>
>
> *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 verify
> the entry in accordance with the requirements deemed appropriate 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.
>
>
>
> Jeremy
>
>
>
> *From:* Peter Bowen [mailto:pzb at amzn.com]
> *Sent:* Tuesday, January 3, 2017 11:07 AM
> *To:* CA/Browser Forum Public Discussion List <public at cabforum.org>
> *Cc:* Jeremy Rowley <jeremy.rowley at digicert.com>
> *Subject:* Re: [cabfpub] Proposed Ballot 183 - Allowing 822 Names and
> (limited) otherNames
>
>
>
> I think we should be more specific on the otherName requirements bit.  Can
> it change to “for id-wfa-hotspot-friendlyName, the CA MUST …”?  (I’m not
> sure what specification is relevant here)
>
>
>
>
>
> On Jan 3, 2017, at 8:35 AM, Jeremy Rowley via Public <public at cabforum.org>
> wrote:
>
>
>
> This proposal modifies section 7.1.4.3.1. to permit inclusion of
> rfc822Names and the WFA otherName type.  Here’s my draft ballot. Any
> thoughts?
>
>
>
> Modify Section 7.1.4.2.1. as follows:
>
>
>
> *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, *2) * or an iPAddress containing the IP
> address of a server,*3) a rfc822Name containing an RFC 5322 email
> address, or 4) an otherName with the id-wfa-hotspot-friendlyName type where
> id-wfa-hotspot-friendlyName OBJECT IDENTIFIER ::= {
> 1.3.6.1.4.1.40808.1.1.1 }. * *For each dNSName and iPAddress included, *the
> CA MUST confirm 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. *For each rfc822Name
> included, the CA MUST confirm the Applicant controls either the included
> email address or the domain portion of the email address. For permitted
> otherNames types, the CA MUST follow the requirements established by the
> entity specifying the otherName type.  *Wildcard FQDNs are permitted.
>
>
>
> 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.
>
>
>
>
>
> <OtherName Ballot.pdf>_______________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170103/e99b3761/attachment-0003.html>