Re: [ipwave] RFC8902 - TLS with ITS Certificates, EXPERIMENTAL, and the one PKI and one Internet

[Mounira MSAHLI <[e-mail]>]

But how you can sign with a certificate retrieved from the browser without
the private key ?

Regards
Mounira

Le jeu. 22 avr. 2021 à 17:52, Mounira MSAHLI <[e-mail]> a
écrit :

>
>>
>> Hi Alex,
>>
>>
>> >> 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.
>>
>>
>> We are 19 member states in C-ROADS Platform. I did co-chair of TF1
>> C-Roads platform in 2018, dealing with security aspects and its
>> interoperability in C-ITS. The common certificate data structure standard
>> is ETSI TS 103 097 ( version 1.3.1 which is a profile of 1609.2).
>>
>>
>>
>> >> 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.
>>
>>
>> Why not? I did not get the point of the common browsers but it was tested
>> on hybrid communication ITS-G5 and 5G
>>
>>
>>
>> >> 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 case of TLS Client Using the ITS Certificate and TLS Server Uses the
>> X.509 Certificate is already covered by the RFC 8902.
>>
>>
>> >> 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?
>>
>>
>> I find that Microsec cert are compliant to standards below:
>>
>>   IEEE Std 1609.2 (IEEE Standard for Wireless Access in Vehicular
>> Environments);
>>
>> • ETSI TS 102 940 (ITS-S security (PKI) architecture and application
>> groups);
>>
>> • ETSI TS 102 941 (Trust and Privacy Management)
>>
>> ETSI TS 103 097 (Certificate and message structure definitions for
>> C2CPKI).
>>
>>
>> So if you have end user micros cert, you can use it to sign C-ITS
>> messages.
>>
>>
>> >> And Microsec CA _is_ present in the browsers
>>
>>
>> You mean the certificate authority. You want to sign CAM with certificate
>> authority ?
>>
>>
>> I did not get the point could you clarify more please.
>>
>>
>>
>> >> http://www.scoop.developpement-durable.gouv.fr/> :
>>
>>
>> >> This is not reachable on IPv6.
>>
>>
>> You mean the web page of the project or the PKI of the project ?
>>
>> Scoop + Intercor projects are already finished in December 2019.
>>
>>
>>
>> Any way the business model of C-ITS PKI, in all mentioned project is
>> SaaS. If you want to get access to this service via IPv6, you can ask the
>> PKI.
>>
>>
>>
>> Best Regards
>>
>> Mounira
>>
>> Le mar. 20 avr. 2021 à 11:51, Alexandre Petrescu <
>> [e-mail]> a écrit :
>>
>>> Hi, Mounira,
>>>
>>> Le 16/04/2021 à 14:13, Mounira MSAHLI a écrit :
>>> >
>>> > Dear all, Dear Russ, Dear Jerome, Dear Alex,
>>> >
>>> >
>>> >
>>> > I’m sorry for the delay. I would like to provide some
>>> > clarificationsconcerning:
>>> >
>>> >
>>> >
>>> >>> 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.
>>> >
>>> >
>>> > But, I want to highlight that the European commission are  funding
>>> > several Cooperative ITS (C-ITS) deployment projects such as:
>>> >
>>> >
>>> > - Scoop@F http://www.scoop.developpement-durable.gouv.fr/
>>> > <http://www.scoop.developpement-durable.gouv.fr/> :
>>> >
>>> >
>>> > which is about deploying 3000 cars + 2000 km of roads
>>> >
>>> >
>>> > - InterCor https://intercor-project.eu/
>>> > <https://intercor-project.eu/>,
>>> >
>>> > - C-Roads Platform https://www.c-roads.eu/platform.html
>>> > <https://www.c-roads.eu/platform.html>
>>> >
>>> >
>>> > 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
>>> >
>>> > <
>>> 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.
>>>
>>> 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/>
>>>
>>> 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
>>>
>>