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

Jeremy Rowley jeremy.rowley at digicert.com
Tue Jan 3 21:13:02 UTC 2017

I suppose I could put in exactly what the WFA requires for validation. Would including this language be sufficient?


The id-wfa-hotspot-friendlyName MUST contain exactly 1 language code and Friendly Name for an Operator. In the case where a Friendly Name is to be included in more than one human language, there shall be as many id-wfa-hotspot-Name objects as there are human languages included. The payload of the id-wfa-hotspot-friendlyName is the concatenation of the Language Code and Friendly Name. The Language Code is a 3-octet ISO-14962-1997 encoded string field that defines the language used in the Operator Name field. The Language Code field value is a two or three character language code selected from ISO-639 [13]. A two character language code value has 0 (“null” in ISO-14962-1997) appended to make it 3 octets in length. The Friendly Name is a variable length UTF-8 formatted field containing the operator’s name. The maximum length of this field is 252 octets. UTF-8 format is defined in [8]. For example, for two human languages the following Friendly Names would be included as two separate otherName objects in the SubjectAltName: "engWi-Fi Alliance" and "fraWi-Fi Alliance". Prior to including a Friendly Name the CA MUST 

o Authenticate the contacts listed in the customer profile 

o Verify the information listed in the certificate application for accuracy and validity for the given organization 

o Conduct a trademark search of the Friendly Name in the U.S. Patent and Trademark Office and equivalent international trademark office such as the WIPO ROMARIN. 


This eliminates any reliance on the WFA specification.



From: Public [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley via Public
Sent: Tuesday, January 3, 2017 2:08 PM
To: Ryan Sleevi <sleevi at google.com>
Cc: Jeremy Rowley <jeremy.rowley at digicert.com>; CA/Browser Forum Public Discussion List <public at cabforum.org>
Subject: Re: [cabfpub] Proposed Ballot 183 - Allowing 822 Names and (limited) otherNames


Agreed, but this line of reasoning always leads to simply not supporting third party projects because the projects may cause issues with the CAB Forum update. IMO, if a group wants to use publicly trusted certs, then that group inherits all the baggage that goes with it. We really control all the cards on this one as the interoperability is one-way. What would you propose to make sure we can update requirements in the future?  A statement like “CAB Forum can do whatever it wants without notice” is superfluous as this is already the case.




From: Ryan Sleevi [mailto:sleevi at google.com] 
Sent: Tuesday, January 3, 2017 1:54 PM
To: Jeremy Rowley <jeremy.rowley at digicert.com <mailto:jeremy.rowley at digicert.com> >
Cc: CA/Browser Forum Public Discussion List <public at cabforum.org <mailto:public at cabforum.org> >; Peter Bowen <pzb at amzn.com <mailto:pzb at amzn.com> >
Subject: Re: [cabfpub] Proposed Ballot 183 - Allowing 822 Names and (limited) otherNames




On Tue, Jan 3, 2017 at 12:46 PM, Jeremy Rowley <jeremy.rowley at digicert.com <mailto:jeremy.rowley at digicert.com> > wrote:

There is a public file (in the link I provided), but it requires filling out information to access. It’s the HotSpot 2.0 Technical documentation, which includes the Certificate Policy (“Hostspot 2-0 (R2) OSU Certificate Policy Specification”).  The documentation is already free to anyone who wants to enter information and agree to the terms of use.  


Ah, the many meanings of free ;) I suppose it wasn't clear that I was talking more about freedom than beer there :)


We essentially already have a liaison member from the WFA (DigiCert, Microsoft, Apple, and Google are all members).


I wouldn't put Google in that list - none of Google's CA/B Forum participants participate in HotSpot 2.0 nor communicate developments on either side of that profile to the other party. I would suggest, to date, only DigiCert does, and only to the extent you've shared anything to the Forum.


Obviously, the context was that we shouldn't be introducing this to the Web PKI unless we're sure we're not going to repeat all the same mistakes we're currently going through the SHA-1 exception process - or at least trying to learn from them. It would be foolish to ignore the feedback we've received from those affected by SHA-1 when considering expanding that scope. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170103/69e34a0d/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4964 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170103/69e34a0d/attachment-0001.p7s>

More information about the Public mailing list