- From: Song Li <ls@newskysecurity.com>
- Date: Tue, 7 Jun 2016 16:57:00 -0700
- To: Junichi Hashimoto <xju-hashimoto@kddi.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>
- Message-ID: <CAJmxCGCipq+dUTQRDCe5VUw0O-2BcUp93OOF8L-X_8zi17XSVA@mail.gmail.com>
Allow me to jump in for these questions. There are two types of ssl certificates: wild card and multi-domain. If example.com is going to have a wild card certificate, it will cover all example.com subdomains, such as www.example.com api.example.com, etc. If admin of example.com choose to use multi-domain certificates, the certificates will cover a limited number of domains of 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> 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> >> >> /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>> 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 | paul.boyes@inrix.com >> <mailto:bryan@inrix.com> | 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>> >>> wrote: >>> >>> Excellent !____ >>> I have just browsed through – Thank you for your hard work!!____ >>> /pw____ >>> __ __ >>> *From:* Crofts, Adam [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 | 87311607____ >>> Mob: +44 (0) 7790 094350 >>> 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 > <>------------------------------------------------<> > >
Received on Tuesday, 7 June 2016 23:58:43 UTC