Ah - good point. The omission of email validation was not intentional. I had it the previous version but omitted the language when combining the SRV text. I'll re-add the language once we've agreed on the friendly name portion. Thanks Rob!
Jeremy -----Original Message----- From: Rob Stradling [mailto:[email protected]] Sent: Tuesday, January 3, 2017 2:10 PM To: Jeremy Rowley <[email protected]> Cc: CA/Browser Forum Public Discussion List <[email protected]>; Ryan Sleevi <[email protected]> Subject: Re: [cabfpub] Proposed Ballot 183 - Allowing 822 Names and (limited) otherNames "3) a rfc822Name containing an RFC 5322 email address" Hi Jeremy. I see why you've written that (5322 obsoleted 2822, which obsoleted 822, and "822" appears in the string "rfc822Name"). However, I think it would be better to defer to 5280, since that is the document that defines the rfc822Name field. RFC5280 section 4.2.1.6 says: When the subjectAltName extension contains an Internet mail address, the address MUST be stored in the rfc822Name. The format of an rfc822Name is a "Mailbox" as defined in Section 4.1.2 of [RFC2821]. A Mailbox has the form "Local-part@Domain". Note that a Mailbox has no phrase (such as a common name) before it, has no comment (text surrounded in parentheses) after it, and is not surrounded by "<" and ">". Rules for encoding Internet mail addresses that include internationalized domain names are specified in Section 7.5. (Neither 5280 nor 2821 have been updated by any newer RFCs) BTW, I don't see any requirement in this ballot to validate the email address in any way before putting it into an rfc822Name field. Is that intentional? On 03/01/17 20:32, Jeremy Rowley via Public 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. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
