Rfc822Names I’m not 100% tied to permitting rfc822Names, but customers request them occasionally and like to stick them in the cert (such as the OU or E field). I’d like to accommodate them by including email in the proper place if there is a way to do so without affecting browser security. The “reasonable measures” language came from the Mozilla root policy, which is the only policy that contains a specific requirement to validate email addresses. If we’d like something more stringent, I originally planned to propose:
“The subjectAltName MAY include one or more rfc822Name entries provided each entry is an email address compliant with RFC5280. Prior to including an email address, the CA MUST verify the Applicant’s control over the email address by either verifying the domain portion of the mail under Section 3.2.2.4 or confirming the Applicant's control over the email by sending a Random Value to the email address and then receiving a confirming response utilizing the Random Value. If a Random Value is used, the Random Value SHALL be unique in each email. The CA or Delegated Third Party MAY resend the email in its entirety, including re‐ use of the Random Value, provided that the communication's entire contents and recipient(s) remain unchanged. The Random Value SHALL remain valid for use in a confirming response for no more than 30 days from its creation.” This is a lot more stringent than current browser requirements for email validation, but I see nothing wrong with that as these are server certs. WFA otherName The HotSpot 2.0 program was designed to secure wireless sign-up access points. The goal was two-fold: 1) The WFA wanted to secure the connection between the hostpot authentication server and the connecting device and 2) help users identify the entity operating a hotspot location and understand which hotspot location represented the correct connection. For example, when I’m at the airport, I see a couple dozen hotspots, all of which are named “Starbucks”. I don’t know which hotspot Starbucks intends as its customer portal. Use of the friendly name helps Starbucks funnel customers to their actual sign-up and distinguish their hotspot from potential phishers. The value propositions for permitting public trust with HotSpot are: 1) Most of the hardware manufactures have completed or are nearing completion of WFA certification of their devices. However, one a barriers to roll-out has been the interstitial displayed during the connection process. Although, certain platforms can now display and use Friendly Names, the customer experience is interrupted during the sign up as these are self-signed certificates. Adding the possibility of public trust enhances the goal of the WFA by providing a seamless sign-on experience for users connecting with hand-held devices. 2) Use of public trust increases the security of the WFA community. With this change publicly-trusted WFA certs will be compliant with the baseline requirements, and the certs will inherit this group’s wisdom in planning and enforcing security upgrades. For example, a WFA cert containing a server name will benefit from the work we just completed on improving validation methods, leading to a better security ecosystem overall. Although increasing the number of entities relying on public trust has the potential to make improvements more difficult to implement, the positive is more people benefit from increased security and more consumers are protected from attacks. 3) The browsers are part of the HotSpot program. The WFA membership includes Apple, Microsoft, and Google. As Ryan points out, the representatives are not necessarily the same, but, nevertheless, browsers are interested in the project. This group should provide browsers with the option of reusing their trust store as part of the program (Erwann pointed out that Microsoft has already done this). Forcing browsers to have two separate trust stores on the same platform doesn’t make much sense where the two programs are essentially compatible minus a few points. 4) Allowing WFA otherNames invites interoperability from other groups. I think showing the public that this group is willing to interoperate with the WFA invites other groups to bring their use cases forward and see whether we can accommodate them. I’d rather know the various ways people would like to use public trust than have everyone assume the public trust industry is impossible to work with. I’m sure there are others, but those are my reasons for wanting to see the CAB Forum permit interoperability. Jeremy From: Ryan Sleevi [mailto:[email protected]] Sent: Wednesday, January 4, 2017 6:20 PM To: CA/Browser Forum Public Discussion List <[email protected]> Cc: Jeremy Rowley <[email protected]> Subject: Re: [cabfpub] Ballot 184: rfc822Names and otherNames How tied are you to allowing rfc822Name? "Reasonable measures" feels very much like the "any equivalent method", and it also feels very much like it will open up the gates of S/MIME, for which the GovReform is still working through. For example, can you incorporate language such as 3.2.2.4.2 / 3.2.2.4.4 to specify more explicitly what 'reasonable' means? Can you remove it entirely? I'm still very uncertain about the value proposition of 7.1.4.2.1.3 / 7.1.4.2.1.5 and why it's desirable, at all, to use BR-compliant CAs for that. I'm hoping you can make a compelling case here. On Wed, Jan 4, 2017 at 5:03 PM, Jeremy Rowley via Public <[email protected] <mailto:[email protected]> > wrote: Thank you everyone for the feedback so far. Attached is an updated draft based on the comments provided. Apologies for the lack of redlining, but I reformatted the entire section into various permitted entries (thanks Gerv) which made the entire thing more readable. Let me know what you think. Jeremy 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 where each included entry is one of the following: 7.1.4.2.1.1. dNSName The subjectAltName extension MAY include one or more dNSName entries provided each entry is either a Fully‐Qualified Domain Name or a Wildcard Domain Name. The CA MUST verify each Fully-Qualified Domain Name and Wildcard Domain Name entry in accordance with Section 3.2.2.4. Except where the entry is an Internal Name using onion as the right‐most label in an entry in the subjectAltName Extension or commonName field in accordance with Appendix F of the EV Guidelines, a dNSName entry MUST NOT contain an Internal Name. 7.1.4.2.1.2. iPAddress The subjectAltName MAY include one or more iPAddress entries provided each entry is an IP address verified in accordance with Section 3.2.2.5. The entry MUST NOT contain a Reserved IP Address. 7.1.4.2.1.3. rfc822Name The subjectAltName MAY include one or more rfc822Name entries provided each entry is an email address compliant with RFC5280. Prior to including an email address, the CA MUST take reasonable measures to verify that the entity submitting the request controls the email account associated with the email address referenced in the certificate or has been authorized by the email account holder to act on the account holder’s behalf. 7.1.4.2.1.4. otherName with SRVName { 1.3.6.1.5.5.7.0.18.8.7 } type-id The subjectAltName MAY include one or more SRVNames (as defined in RFC4986) as an otherName entry with the SRVName type-id. The CA MUST verify the name portion of the entry in accordance with Section 3.2.2.4. SRVName entries MUST NOT contain Wildcard Domain Names. If a Technically Constrained Subordinate CA Certificate includes a dNSName constraint but does not have a technical constraint for SRVNames, the CA MUST NOT issue certificates containing SRVNames from the Technically Constrained Subordinate CA Certificate. A Technically Constrained Subordinate CA Certificate that includes a technical constraint for SRVNames MUST include permitted name subtrees and MAY include excluded name subtrees. 7.1.4.2.1.5. otherName with id-wfa-hotspot-friendlyName { 1.3.6.1.4.1.40808.1.1.1 } type-id The subjectAltName MAY include one or more entries of the id-wfa-hotspot-friendlyName type-id. The CA MAY only include id-wfa-hotpost-friendlyName entries compliant with the Hotspot OSU Certificate Policy as officially published by the Wi-Fi Alliance at <https://www.wi-fi.org/discover-wi-fi/wi-fi-certified-passpoint> https://www.wi-fi.org. Prior to including a id-wfa-hotpost-friendlyName entry, the CA MUST: A) Authenticate the authority of the certificate requester in accordance with Section 3.2.5; B) Authenticate the Subject Identity information in accordance with Section 3.2.2.1; and C) Conduct a trademark search for the entry with the U.S. Patent and Trademark Office and equivalent international trademark office such as the WIPO ROMARIN. _______________________________________________ Public mailing list [email protected] <mailto:[email protected]> https://cabforum.org/mailman/listinfo/public
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
