Re: [ipwave] wish list for CAs for vehicular networks

[Alexandre Petrescu <[e-mail]>]

In private I was suggested a few improvements about 'commodity'
browsers, CABForum and federations of CAs; so here is the new wish list:

                 Wish list for CAs for vehicular networks

- must be reachable on IPv6, and their website too.
- must be present built-in in commodity web browsers, and open source
   because that guarantees trust built at large scale and helps spot the
   bugs quickly for the benefit of all.
- must express their requirements to vehicular networks in terms of
   capabilities of certificates.  For example, a CA may agree to sign
   only a number of certs (1000?) per vehicle, but no more.  Or might
   suggest new fields in these X.509 certs that they are ready to confirm
   (to certify).
- must sign and offer almost for free certificates for vehicular
   networks.  It's not because the car industry makes much money that a
   lot has to be wasted on artificial costs.  The way for CA to make
   money should be different than direct charging the vehicular industry.

- there might be possibilities of considering new web browsers (other
   than the 'commodity').
- maybe a relationship with IOTOPS WG of IETF could be considered.
- the CABForum outside of IETF might be considered (but unreachable on
   IPv6, currently).
- maybe new federations of CAs could be considered, in which the
   vehicular industries might built their own world, but that should not
   be a path towards seggregating away from the Internet trust.

- must contribute to make Internet better, and not seggregate the
   vehicular networks from the Internet.

Please comment on this wish list.

Maybe we can write a brief Internet Draft about wishes about security, 
Internet, and Intelligent Transportation Systems.

Alex


Le 21/04/2021 à 19:43, Alexandre Petrescu a écrit :
> This is my list of requirements for CAs for vehicular networks: -
> must be reachable on IPv6, and their website too. - must be present
> built-in in open source web browsers. - must express their
> requirements to vehicular networks in terms of capabilities of
> certificates.  For example, a CA may agree to sign only a number of
> certs (1000?) per vehicle, but no more.  Or might suggest new fields
> in these X.509 certs that they are ready to confirm (to certify). -
> must sign and offer almost for free certificates for vehicular 
> networks.  It's not because the car industry makes much money that a 
> lot has to be wasted on artificial costs.  The way for CA to make 
> money should be different than direct charging the vehicular
> industry. - must contribute to make Internet better, and not
> seggregate the vehicular networks from the Internet.
> 
> And this below is our dicussion that helped me frame these
> requirements, and I thank you for the discussion.
> 
> Le 20/04/2021 à 11:51, Alexandre Petrescu a écrit : [...]
> 
>>> - Scoop@F http://www.scoop.developpement-durable.gouv.fr/ 
>>> <http://www.scoop.developpement-durable.gouv.fr/> :
> 
> This is not reachable on IPv6.
> 
>>> 
>>> 
>>> which is about deploying 3000 cars + 2000 km of roads
>>> 
>>> 
>>> - InterCor https://intercor-project.eu/ 
>>> <https://intercor-project.eu/>,
> 
> This is not reachable on IPv6.
> 
> 
>>> 
>>> - C-Roads Platform https://www.c-roads.eu/platform.html 
>>> <https://www.c-roads.eu/platform.html>
> 
> This is not reachable on IPv6.
> 
> 
>>> 
>>> 
>>> InterCor and C-Roads are about harmonising C-ITS specifications
>>> in Europe
>>> 
>>> 
>>> - INDID 
>>> https://www.c-roads.eu/pilots/core-members/france/Partner/project/show/indid.html
>>> 
>>> 
>>> 
>>> <https://www.c-roads.eu/pilots/core-members/france/Partner/project/show/indid.html>.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> All these projects are using ETSI TS 103 097 certificates, which
>>> is a profile of 1609.2 to secure C-ITS messages:
>> 
>> But there are also other projects funded by the EU in the same
>> domain (connected automated mobility with self-driving cars) and
>> where more open certificates are being used, with more open source
>> software.
>> 
>>> 
>>> https://ec.europa.eu/transport/sites/transport/files/c-its_certificate_policy_release_1.pdf
>>> 
> 
> 
> This is reachable on IPv6.
> 
>>> 
>>> 
>>> <https://ec.europa.eu/transport/sites/transport/files/c-its_certificate_policy_release_1.pdf>
>>> 
>>> 
>>> 
>>> 
>>> 
>>> As mentioned by Jerome, one use case of the RFC 8902 could be to
>>> sign CAM and DENM messages on facilities layer and not geonet as 
>>> specified in ETSI.
>> 
>> Yes, but has that been done?  HAs someone put CAM messages on IP on
>> a 4G link and signed with 1609.2 certificates?  I think not.
>> 
>> It would be good if it worked, but it would need the CAs to know
>> these certifiicate formats, and the CAs would need to be known in
>> common browsers.
>> 
>>> Yes, in projects dealing with C-ITS security interoperability, we
>>> use MQTT to exchange C-ITS messages between many countries to
>>> ensure continuity of service when vehicle is crossing borders.
>> 
>> Ok, good to know.
>> 
>>> 
>>> 
>>> We could also use the RFC for Vehicle-To-Internet simply to
>>> upload log of vehicle for example etc…
>> 
>> Yes, but what CA would be put in the server of that log?  Would
>> that CA be a self-made CA with openssl (or other open source
>> software), or would it be a widely known CA like the CAs present in
>> firefox, for example?
>> 
>> My guess is that you assume a self-made CAs, and I agree with it
>> for experimentation.
>> 
>> But for deployment there would be a need for the existing CAs in
>> the browsers to implement these 1609.2 certs.  And they are paying.
>> I doubt it could work.
>> 
>>> 
>>> 
>>> 
>>>>> The reason is because the former is all open source software
>>>>> and freely accessible standards, whereas  1609.2 are closed
>>>>> documents and ETSI ITS certificate software is not integrated
>>>>> in mainline software like openssl.
>>> 
>>> 
>>> There's a java implementation of 1609.2/103 097 here: 
>>> https://github.com/pvendil/c2c-common 
>>> <https://github.com/pvendil/c2c-common>. I already used it.
> 
> This is not reachable on IPv6.  Several people who contributed to
> IETF also asked github support to put it on IPv6.  There is no answer
> since some time now.
> 
> I would suggest the person who maintains that java implementation of
>  1609.2 to put it on another server that is reachable on IPv6.  Or 
> otherwise to ask too, like the others have, github.com to be on
> IPv6.
> 
> 
>> Yes, but the spec is paying.  That does inspire seriousness but
>> might inspire risk for the confidence.
>> 
>>> 
>>> 
>>>>> ITS-specific CAs are closed, hard to access and the
>>>>> certificate are
>>> 
>>> expensive.  hard to access and the certificate are expensive.
>>> 
>>> 
>>> you can get certificates from 
>>> https://www.ghsiss.com/v2x-certificates/ 
>>> <https://www.ghsiss.com/v2x-certificates/>
> 
> This is not reachable on IPv6.  And ISS CA (Integrated Security 
> Services) is not in my browser either.
> 
> In comparison, Microsec might provide certificates in bilateral 
> agreements that might cost less, or almost 0.  And Microsec is
> reachable on IPv, and is in my browser.
> 
> There is also the Let's Encrypt CA that is reachable on IPv6.  I
> think they might offer certificates free of charge too.
> 
> These kinds of CAs (Microsec and Let's Encrypt) are good candidates
> to whom to propose interoperability for vehicular networks on IPv6.
> 
> There might be other such CAs?
> 
> So, the question is whether Microsec and Let's Encrypt (who are on
> IPv6 and offer somehow very cheap or almost free certificates), offer
>  compliance with RFC 8902?  If yes, is it with ITS Certificates
> (1609.2) or with X.509 certificates?
> 
> Alex
> 
>> 
>> Thanks for the pointer, I did not know ghsiss.  Are they paying 
>> certificates?
>> 
>> Recently I worked with Microsec and they might also propose 
>> certificates for cheaper (free), if it is for evaluation, or for 
>> academia, or similar.  And Microsec CA _is_ present in the
>> browsers. But can Microsec sign these 1609.2 certificates and still
>> not ask me (end user) to pay for the certificates?
>> 
>> Another thing to consider is whether or not ghsiss (and Microsec
>> for that matter) are reachable on IPv6.  That is also a make kor
>> break condition of use.  It is worth trying.
>> 
>> Thanks for the message.
>> 
>> Alex
>> 
>>> 
>>> 
>>> 
>>>>> In  my personal opinion, it remains good if IPWAVE provides
>>>>> a guideline on how to secure IP vehicular communication,
>>>>> including interoperability between systems (although I have
>>>>> at that time limited resources to actively contribute to
>>>>> this), as several options are on the table and we need to
>>>>> guarantee the trust chain, even considering different
>>>>> protocol or standards being used.
>>> 
>>> 
>>> I’m also interested to work on security interoperability in C-ITS
>>> and we could add:
>>> 
>>> 
>>> - Misbehaving in vehicular network
>>> 
>>> - Revocation management
>>> 
>>> - Pseudonym management/change to avoid tracking and to ensure 
>>> privacy
>>> 
>>> 
>>> Thank you Russ for your time on this RFC and for your valuable 
>>> review.
>>> 
>>> 
>>> 
>>> Kind regards
>>> 
>>> Mounira
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> ---------- Forwarded message --------- De : *Alexandre Petrescu* 
>>> <[e-mail]
>>> <mailto:[e-mail]>> Date: jeu. 15 avr. 2021 à
>>> 22:44 Subject: Re: [ipwave] RFC8902 - TLS with ITS Certificates,
>>> EXPERIMENTAL, and the one PKI and one Internet To: Jérôme Härri
>>> <[e-mail] <mailto:[e-mail]>>,
>>> IPWAVE WG <[e-mail] <mailto:[e-mail]>>
>>> 
>>> 
>>> 
>>> 
>>> Le 15/04/2021 à 12:35, Jérôme Härri a écrit :
>>>> Dear Alex,
>>>> 
>>>> Thanks. Indeed such discrepancies is particularly an issue when
>>>> it comes to merging wireless and wired (V2I). For example, you
>>>> send a DENM over 5G reaching a MEC. It will remove the ETSI KPI
>>>> and do something on its own (not fully sure what exactly), or
>>>> if you use MQTT type of interaction, where it is even less
>>>> clear (what a broker will do on a DENM sent over JSON is not
>>>> fully clear to keep track of any kind of security/data
>>>> integrity...
>>>> 
>>>> For that matter, there was one effort from C-ROAD to develop 
>>>> something called 'Facilities' PKI, saying that the ITS KPI are
>>>> at facilities layer and no longer at geonet. The advantage is
>>>> that at least now, you do not need to remove the KPI when
>>>> moving and exchanging DENM (or else) in backend. But I am not
>>>> sure of the current status or even if this WI is actually
>>>> active.
>>>> 
>>>> Now, I do not fully agree with you with the equivalence of the
>>>>  internet KPI and ITS KPI. Indeed, the principle is the same,
>>>> but in the test you mention, the trust chain is not guaranteed
>>>> (you edit your own root-CA for the purpose of the tests, but
>>>> for example in one of our cross-border deployment (e.g. DE-FR),
>>>> this solution does not work, as a German car will not recognize
>>>> the CA from a French root-CA. So, the key issue I see is not
>>>> really (or only) on security but on Trust. The ITS KPI is one
>>>> option, there might be others, but 'open ssl' strategies still
>>>> face the trust-chain issue.
>>> 
>>> Jérôme,
>>> 
>>> I agree with you.
>>> 
>>> In the discussion above I think you meant 'PKI' throughout
>>> (Public Key Infrastructure), and not 'KPI' (Key Performance
>>> Indicator).
>>> 
>>> That said, the question you formulate about how a car-to-server
>>> MQTT interaction on IP would be authenticated by certificates
>>> that are verified by CAs that are absent from normal browsers, or
>>> how the CAs that are present in normal browsers would help
>>> authenticating CAM messages sent on IP - is a very relevant
>>> question.
>>> 
>>> Alex
>>>> 
>>>> Best Regards,
>>>> 
>>>> Jérôme
>>>> 
>>>> -----Original Message----- From: its <[e-mail]
>>> <mailto:[e-mail]>> On Behalf
>>>> Of Alexandre Petrescu Sent: Thursday, 15 April 2021 12:20 To: 
>>>> IPWAVE WG <[e-mail] <mailto:[e-mail]>> Subject:
>>>> [ipwave] RFC8902
>>> - TLS with ITS
>>>> Certificates, EXPERIMENTAL, and the one PKI and one Internet
>>>> 
>>>> Hi, IPWAVErs,
>>>> 
>>>> A colleague pointed me to this recently issued RFC 8902 about
>>>> TLS with ITS Certificates.
>>>> 
>>>> This RFC is of an EXPERIMENTAL Category.
>>>> 
>>>> It might be in agreement with other IEEE standards such as
>>>> 1609.2.
>>>> 
>>>> But I must say that I think it further deepens the discrepancy
>>>>  between what is PKI in the Internet and what is the closed PKI
>>>> for ITS.  That is a discrepancy that exists for a long time,
>>>> and I must share that - IMHO - I am surprised that the IETF
>>>> issues an RFC that further promotes such a discrepancy.
>>>> 
>>>> This discrepancy is the following: in a few trials I
>>>> participated, and some about I heard of, people use normal PKI
>>>> with openssl and normal certificates in cars, over IP, on
>>>> cellular links like 4G. They work fine.  The CA is a local CA
>>>> (not a commercial CA), but the concept _is_ compatible with
>>>> normal CAs.  These dont use the ETSI ITS-specific certificates,
>>>> neither the 1609.2 certificates.
>>>> 
>>>> I think there are more such trial deployments using local (but
>>>>  standard, openssl PKIs and certificates) than there are
>>>> trials using ETSI ITS certificates or 1609.2 certificates.  The
>>>> reason is because the former is all open source software and
>>>> freely accessible standards, whereas 1609.2 are closed
>>>> documents and ETSI ITS certificate software is not integrated
>>>> in mainline software like openssl.
>>>> 
>>>> There are many easily accessible CAs (Certificate Authorities) 
>>>> that are integrated in the Internet and in main web browsers, 
>>>> whereas the ITS-specific CAs are closed, hard to access and
>>>> the certificate are expensive.  Many strong oppinions maintain
>>>> that it should stay that way: cars PKI different than Internet
>>>> PKI.
>>>> 
>>>> There should be one Internet, and that means one trust, and
>>>> one PKI.
>>>> 
>>>> Everything else should not be done at IETF, I think; hence my 
>>>> comment about this particular RFC.
>>>> 
>>>> That is my humble oppinion.
>>>> 
>>>> I would like to hear other oppinions?  Maybe I miss
>>>> something...
>>>> 
>>>> Alex
>>>> 
>>>> _______________________________________________ its mailing
>>>> list [e-mail] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/its 
>>> <https://www.ietf.org/mailman/listinfo/its>
>>>> 
>>>> _______________________________________________ its mailing
>>>> list [e-mail] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/its 
>>> <https://www.ietf.org/mailman/listinfo/its>
>>>> 
>>> 
>>> _______________________________________________ its mailing list
>>>  [e-mail] <mailto:[e-mail]> 
>>> https://www.ietf.org/mailman/listinfo/its 
>>> <https://www.ietf.org/mailman/listinfo/its>
>>> 
>>> 
>>> _______________________________________________ its mailing list
>>>  [e-mail] https://www.ietf.org/mailman/listinfo/its
>>> 
>> 
>> _______________________________________________ its mailing list 
>> [e-mail] https://www.ietf.org/mailman/listinfo/its
> 
> _______________________________________________ its mailing list 
> [e-mail] https://www.ietf.org/mailman/listinfo/its