- From: Junichi Hashimoto <xju-hashimoto@kddi.com>
- Date: Wed, 8 Jun 2016 09:53:35 +0900
- To: Song Li <ls@newskysecurity.com>
- Cc: "Gavigan, Kevin" <kgavigan@jaguarlandrover.com>, Paul Boyes <Paul.Boyes@inrix.com>, Peter Winzell <Peter.Winzell@melcogot.com>, "Crofts, Adam" <acrofts1@jaguarlandrover.com>, public-automotive <public-automotive@w3.org>, Peter Virk <pvirk1@jaguarlandrover.com>, Lovene Bhatia <lbhatia@jaguarlandrover.com>
Hi Song, I think certificate type is a different topic but if your example solves my concern, please share the idea. In the draft[1], we see the following sample code: var vehicle = new WebSocket(“wss://localhost:4343”); To implement this, the local server has to keep a certificate which common name is 'localhost' and also keep the corresponding private key. Because this key is a part of the local server 'app', it is very hard to prevent attackers retrieving this key. This cause issues. e.g., - Falsification of data - Man-in-the-middle between apps and the local server Additionally, the certificate and the key are valid on anywhere, anydevice. I don't think major providers allow such use. [1] https://www.w3.org/auto/wg/wiki/Vehicle_Information_Service_Specification#Security_and_Privacy_Considerations Regards, Junichi On 2016/06/08 8:57, Song Li wrote: > Allow me to jump in for these questions. > > There are two types of ssl certificates: wild card and multi-domain. If > example.com <http://example.com> is going to have a wild card > certificate, it will cover all example.com <http://example.com> > subdomains, such as www.example.com <http://www.example.com> > api.example.com <http://api.example.com>, etc. If admin of example.com > <http://example.com> choose to use multi-domain certificates, the > certificates will cover a limited number of domains of example.com > <http://example.com>. Multiple domains can share the same certificate in > both cases, they do not have to have different certificates, but they can. > > Certificates are deployed to servers and they should not be shared with > people who are not admins of the domains. Certificates are deployed on > the servers hosting the domain(s), and only public key portion of the > certificates will be sent over the wire. Things get more complicated if > CDN is used to speed up content distribution, but can be solved using > multi-domain certificates. Clients, such as browsers / java code, > verifies the certificates before communicating with server for secured > content. > > Let me know if you need examples / implementation details. Our company's > using a wild card certificated for our https://www.newskysecurity.com > domains. > > Regards > > Song Li > > Co-founder and CTO > NewSky Security <https://newskysecurity.com> > > On Tue, Jun 7, 2016 at 4:23 PM, Junichi Hashimoto > <xju-hashimoto@kddi.com <mailto:xju-hashimoto@kddi.com>> wrote: > > Hi Kevin, > > Implementers would like to know how to manage the certificates for > https/wss connection in the server. For example, they would like to > know whether each server should have different certificates or not, > how the certificates should be kept securely, etc. > > Junichi > > On 2016/06/08 0:36, Gavigan, Kevin wrote: > > Hi, > > I've updated the Security section to include some general points > that > apply to both WebSockets and RESTful web services: > > https://www.w3.org/auto/wg/wiki/Vehicle_Information_Service_Specification#Security_and_Privacy_Considerations > > Kind regards, > > Kevin > > /Kevin Gavigan BSc, MSc, PhD, MCP, MCTS/ > /Software Architect/ > /Connected Infotainment/ > /Electrical, Electronic and Software Engineering (EESE)// > / > Jaguar Land Rover > / > / > /Mobile: 07990 084866 > / > /Email:/ kgavigan@jaguarlandrover.com > <mailto:kgavigan@jaguarlandrover.com> > <mailto:kgavigan@jaguarlandrover.com > <mailto:kgavigan@jaguarlandrover.com>> > > /Office address:/ > GO03/057 • Building 523, Gaydon • Maildrop: (G03)/ > /Jaguar Land Rover • Banbury Road • Gaydon • Warwick • CV35 0RR > > On 7 June 2016 at 14:18, Paul Boyes <Paul.Boyes@inrix.com > <mailto:Paul.Boyes@inrix.com> > <mailto:Paul.Boyes@inrix.com <mailto:Paul.Boyes@inrix.com>>> wrote: > > Excellent indeed. I will look at this in detail later today. > > *Paul J. Boyes* | INRIX | Director of Telematics and Standards - > OpenCar | 206-276-9675 <tel:206-276-9675> | > paul.boyes@inrix.com <mailto:paul.boyes@inrix.com> > <mailto:bryan@inrix.com <mailto:bryan@inrix.com>> | > www.inrix.com <http://www.inrix.com> > > <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.inrix.com_&d=BQMFAg&c=QbuapHRvbn0JdC8vTVkPHg&r=PRAN7lum5Ra662QLho8LU3bhFjBvLXn3bBkFbW0Amjo&m=V5l0WXfOEJwhcE0JsN06mQ5SQhpXL-DuAuK3YcnTZoc&s=OqQVi_DcS5rv8or8hZdFvY0re6YF0Wl-_8okxrxOF0w&e=> > > On Jun 7, 2016, at 3:56 AM, Peter Winzell > <Peter.Winzell@melcogot.com > <mailto:Peter.Winzell@melcogot.com> > <mailto:Peter.Winzell@melcogot.com > <mailto:Peter.Winzell@melcogot.com>>> > wrote: > > Excellent !____ > I have just browsed through – Thank you for your hard > work!!____ > /pw____ > __ __ > *From:* Crofts, Adam > [mailto:acrofts1@jaguarlandrover.com > <mailto:acrofts1@jaguarlandrover.com>] > *Sent:* Monday, June 6, 2016 12:58 PM > *To:* public-automotive > *Cc:* Kevin Gavigan; Peter Virk; Lovene Bhatia > *Subject:* Draft Specification for Service Based > Approach Using > WebSockets____ > __ __ > Hi All, ____ > __ __ > Kevin and I have drafted a specification for the service > based > approach using WebSockets, as discussed in Issue 81 > <https://github.com/w3c/automotive/issues/81>. The draft > can be > found in the working group wiki here > > <https://www.w3.org/auto/wg/wiki/Vehicle_Information_Service_Specification#WebSocket_2>.____ > __ __ > The specification builds upon the approach raised by Powell > Kinney, using a single WebSocket to send JSON data > structures to > the server. The JSON structure specifies the desired vehicle > signal specification (VSS) path, an action parameter to > specify > get, set, subscribe or unsubscribe as well as a number > of optional > parameters.____ > __ __ > This specification allows:____ > > * Use of the VSS, including wildcards and indexing____ > * GET/SET over WebSocket____ > * SUBSCRIBE to receive change notifications, allowing > settable > change thresholds and upper/lower bounds____ > * SUBSCRIBE to receive notifications at a given time > interval.____ > * UNSUBSCRIBE via a subscription handle____ > * UNSUBSCRIBE from all notifications____ > * Security tokens to be passed from the client to the > server, > such as OAuth 2.0____ > > We'll go through this on the call on Tuesday night and look > forward to hearing your thoughts.____ > __ __ > Kind regards, ____ > __ __ > Adam____ > __ __ > -- ____ > *Adam C**rofts MEng (Hons) MIET*____ > Connected Infotainment____ > Vehicle Engineering____ > Tel: +44 (0) 1926 921607 > <tel:%2B44%20%280%29%201926%20921607> | 87311607____ > Mob: +44 (0) 7790 094350 > <tel:%2B44%20%280%29%207790%20094350> > Desk: G03/054, Building 523, Gaydon____ > Mail Drop: G/26/3, Building 523, Gaydon____ > __ __ > ____ > __ __ > Jaguar Land Rover Limited____ > Registered Office: Abbey Road, Whitley, Coventry CV3 4LF > ____ > Registered in England No: 1672070____ > __ __ > This e-mail and any attachments contain confidential > information > for a specific individual and purpose. The information > is private > and privileged and intended solely for the use of the > individual > to whom it is addressed. If you are not the intended > recipient, > please e-mail us immediately. We apologise for any > inconvenience > caused but you are hereby notified that any disclosure, > copying or > distribution or the taking of any action in reliance on the > information contained herein is strictly prohibited. > > > > > > -- > <>------------------------------------------------<> > au x HAKUTO MOON CHALLENGE > http://au-hakuto.jp/ > KDDI/au competing in the Google Lunar XPRIZE > Providing communication technology support for > the Japanese team - HAKUTO > <>------------------------------------------------<> > > -- <>------------------------------------------------<> au x HAKUTO MOON CHALLENGE http://au-hakuto.jp/ KDDI/au competing in the Google Lunar XPRIZE Providing communication technology support for the Japanese team - HAKUTO <>------------------------------------------------<>
Received on Wednesday, 8 June 2016 01:04:12 UTC