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

[Mounira MSAHLI <[e-mail]>]

>
>
>
> 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
>>
>