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

[Alexandre Petrescu <[e-mail]>]

Le 25/04/2021 à 12:19, Mounira MSAHLI a écrit :
> 
>>> It should be the CA provider who could express that requirement.
> 
> 
> I don’t agree with you in this point, it is up to the car
> manufacturer and road operator to specify the security and privacy
> constraints for the vehicle and to fix the number of pseudonyms
> needed in the vehicle. BTW, there is an ETSI standard dealing with
> pseudonym change strategy:
> 
> 
> https://www.etsi.org/deliver/etsi_tr/103400_103499/103415/01.01.01_60/tr_103415v010101p.pdf

Thanks, I have clicked on it.  It is indeed reachable from my IPv6-only 
commodity PC.

In the wishlist for CAs for vehicular networks, there should be that 
their specs should be not only free access, but also mandatorily be 
present on an IPv6 website, or FTP.

> In page 27, you can find  examples of pseudonym parameters values
> from C-ITS projects and normative organizations.

Yes, I looked.  It is good for the C-ITS projects and normative 
organizations that they have their specs into an ETSI document.

But I think that CAs also should have their needs expressed.  It is the 
CAs that implement these principles.  When they implement it they might 
come up with feedback that should be taken into account.

> After the publication of this pre-study, the ec.europa published 
> c-its_certificate_policy-v1.1-track_changes.pdf with recommandation
> in section 2.7.1:
> 
> The number of maximum number of parallel ATs which are valid in
> parallel (i.e. at the same moment in time) for ITS-S shall not be
> more than 100.

Ok.

ec.europa is the European Commission, a form of Executive, or government 
body.

I doubt other governments have something to say about the way the CAs 
work elsewhere than in the vehicular networks.  It is only in vehicular 
networks that ec.europa (dare I say 'wrongly') believes has something to 
say in such detail as the lifetime of pseudonyms.

I can tell that I noticed in the past several times the gouv.fr (a 
government in a particular country) trying to become itself a CA for 
example for when people declare revenues on the web, for tax 
application.  It was more than 10 years ago.  It failed.  But it 
resulted in the creation of a specific activity at a trust provider in 
that country.  And that CA is now selling services to gouv.fr as much as 
they sell trust services to other clients.  And that CA is present 
built-in in browsers and OSs.

That is the way it scales.

There are many other organizations, some larger than some governments, 
who do pretend to be CAs, and many people trust themm.  But each time it 
is a seggregated 'limited domain', and the CAs are installed manually in 
the browsers and in the OSs.

> 
> 
> PKI is the Public Key Infrastructure
> 
> 
>>> In that sense, the EU commission might not be able to provide all
>>> these
> 
>>> CAs... It's the CAs themselves that provide it.
> 
> 
> It is about one PKI for all not 1 PKI/country(without C-ITS PKI).

It is indeed more than one PKI per country, but it is still just one PKI 
for that set of countries.  It is still a trust for a 'seggregated', 
'silo', 'limited domain' part of the larger Internet.

>>> I meant to say to maybe write an Internet Draft about security
>>> and ITS.
> 
>>> It might include ethical aspects, but not sure which ones?
> 
>>> What do you think about an Internet Draft?
> 
> 
> Yes, it could be interesting to think about an Internet Draft since
> we have many security open questions. Unfortunately, I don’t have
> resources but we could discuss.

I might try to re-edit the wish list based on our discussion.  I 
included the need for specs availability on IPv6.

Can you comment on this wish list?

                 Wish list for CAs for vehicular networks

- the CA must be reachable on IPv6, and their website too.
- the specs of CAs for vehicular networks must be available on IPv6
   (e.g. on an IPv6 website, FTP directory, or GIT shared space).
- the specs of CA must be implementable independently of other paying
   sources such as (some) from IEEE or ISO.  For example, the ETSI ITS
   spec that IMPORTS 1609.2 does not qualify because in the end it is
   paying.  But the X.509 in RFC 5280 does not rely on other paying
   documents in order to implement (I think?).

- the CA must offer OCSP reachability on IPv6.

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

Alex

> 
> 
> Mounira
> 
> 
> 
> Le ven. 23 avr. 2021 à 13:14, Alexandre Petrescu 
> <[e-mail] <mailto:[e-mail]>>
> a écrit :
> 
> 
> 
> Le 22/04/2021 à 19:30, Mounira MSAHLI a écrit :
>> 
>>>> - 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).
>> 
>> I think the number of used pseudonym certificates depends on the 
>> strategy change of pseudonyms implemented in C-ITS station to
>> avoid tracking and to ensure privacy.
> 
> I agree, it might be so.
> 
> It should be the CA provider who could express that requirement.
> 
> If we can invite a CA provider to express their requirements, then
> there could be advancement.
> 
>> 
>>>> - 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.
>> 
>> The EU commission is providing a PKI for member states who are not 
>> deploying C-ITS PKI, I think for free.
> 
> I dont know which precisely PKI is one referring to?
> 
> In my mind, and I might be not right, a PKI is actually the set of
> CAs that are present built-in in web browsers.  No more, no less.
> 
> In that sense, the EU commission might not be able to provide all
> these CAs... It's the CAs themselves that provide it.
> 
> Let me speculate on what you might be referring to when saying that
> the COmmission might be providing a PKI for member states.
> 
> I suspect (not sure) that one refers to 
> https://cpoc.jrc.ec.europa.eu/ <https://cpoc.jrc.ec.europa.eu/> This
> website is not reachable on IPv6.  That is already a huge problem to
> surpass.  When that is done, one can talk in more detail about it.
> 
> For my part, I once looked at that site on IPv4, and I found files
> with ".oer" extension, presumably certificates.  I never saw that
> extension before, so I asked the website contacts about that format?
> I received no answer.  I did not push further.  I think either they
> live in their own world seggregated, or I might be myself
> misunderstanding so many things (and hence live in my own world :-)
> 
>>>> Maybe we can write a brief Internet Draft about wishes about 
>>>> security, Internet, and Intelligent Transportation Systems.
>> 
>> You mean ethical aspects ?
> 
> I meant to say to maybe write an Internet Draft about security and
> ITS.
> 
> It might include ethical aspects, but not sure which ones?
> 
> What do you think about an Internet Draft?
> 
> Maybe one saw the message from chairmanship that currently there is 
> little work ongoing, and maybe a shutdown of the group is
> considered.
> 
> Alex
> 
>> 
>> Kind Regards Mounira
>> 
>> 
>> 
>> Le jeu. 22 avr. 2021 à 17:52, Alexandre Petrescu 
>> <[e-mail]
> <mailto:[e-mail]> 
> <mailto:[e-mail] 
> <mailto:[e-mail]>>>
>> a écrit :
>> 
>> 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/>
>> <http://www.scoop.developpement-durable.gouv.fr/
> <http://www.scoop.developpement-durable.gouv.fr/>>
>>>>> <http://www.scoop.developpement-durable.gouv.fr/
> <http://www.scoop.developpement-durable.gouv.fr/>
>> <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/>
>> <https://intercor-project.eu/ <https://intercor-project.eu/>>
>>>>> <https://intercor-project.eu/ <https://intercor-project.eu/>
> <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>
>> <https://www.c-roads.eu/platform.html
> <https://www.c-roads.eu/platform.html>>
>>>>> <https://www.c-roads.eu/platform.html
> <https://www.c-roads.eu/platform.html>
>> <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>
>> 
>> 
>> 
> <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>>
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>> 
> <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>
>> 
>> 
>> 
> <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>
>> 
>> 
>> 
> <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>>
>>>>> 
>>> 
>>> 
>>> This is reachable on IPv6.
>>> 
>>>>> 
>>>>> 
>>>>> 
>> 
> <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>
>> 
>> 
>> 
> <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>
>> <https://github.com/pvendil/c2c-common
> <https://github.com/pvendil/c2c-common>>
>>>>> <https://github.com/pvendil/c2c-common
> <https://github.com/pvendil/c2c-common>
>> <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
> <http://github.com>
>> <http://github.com <http://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/>
>> <https://www.ghsiss.com/v2x-certificates/
> <https://www.ghsiss.com/v2x-certificates/>>
>>>>> <https://www.ghsiss.com/v2x-certificates/
> <https://www.ghsiss.com/v2x-certificates/>
>> <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]>
>>>>> <mailto:[e-mail]
> <mailto:[e-mail]>>
>>>>> <mailto:[e-mail]
> <mailto:[e-mail]>
>> <mailto:[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]>
>>>>> <mailto:[e-mail]
> <mailto:[e-mail]>>
>> <mailto:[e-mail] <mailto:[e-mail]> 
>> <mailto:[e-mail]
> <mailto:[e-mail]>>>>,
>>>>> IPWAVE WG <[e-mail] <mailto:[e-mail]>
> <mailto:[e-mail] <mailto:[e-mail]>>
>> <mailto:[e-mail] <mailto:[e-mail]> <mailto:[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]>
>> <mailto:[e-mail] <mailto:[e-mail]>>
>>>>> <mailto:[e-mail] <mailto:[e-mail]>
> <mailto:[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]>
> <mailto:[e-mail] <mailto:[e-mail]>>
>> <mailto:[e-mail] <mailto:[e-mail]> <mailto:[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]>
>>>>>> <mailto:[e-mail]
> <mailto:[e-mail]>> <mailto:[e-mail] <mailto:[e-mail]>
>> <mailto:[e-mail] <mailto:[e-mail]>>>
>>>>> https://www.ietf.org/mailman/listinfo/its
> <https://www.ietf.org/mailman/listinfo/its>
>> <https://www.ietf.org/mailman/listinfo/its
> <https://www.ietf.org/mailman/listinfo/its>>
>>>>> <https://www.ietf.org/mailman/listinfo/its
> <https://www.ietf.org/mailman/listinfo/its>
>> <https://www.ietf.org/mailman/listinfo/its
> <https://www.ietf.org/mailman/listinfo/its>>>
>>>>>> 
>>>>>> _______________________________________________ its
>>>>>> mailing list [e-mail] <mailto:[e-mail]>
>>>>>> <mailto:[e-mail]
> <mailto:[e-mail]>> <mailto:[e-mail] <mailto:[e-mail]>
>> <mailto:[e-mail] <mailto:[e-mail]>>>
>>>>> https://www.ietf.org/mailman/listinfo/its
> <https://www.ietf.org/mailman/listinfo/its>
>> <https://www.ietf.org/mailman/listinfo/its
> <https://www.ietf.org/mailman/listinfo/its>>
>>>>> <https://www.ietf.org/mailman/listinfo/its
> <https://www.ietf.org/mailman/listinfo/its>
>> <https://www.ietf.org/mailman/listinfo/its
> <https://www.ietf.org/mailman/listinfo/its>>>
>>>>>> 
>>>>> 
>>>>> _______________________________________________ its mailing 
>>>>> list [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
> <mailto:[e-mail]>> <mailto:[e-mail] <mailto:[e-mail]>
>> <mailto:[e-mail] <mailto:[e-mail]>>>
>>>>> https://www.ietf.org/mailman/listinfo/its
> <https://www.ietf.org/mailman/listinfo/its>
>> <https://www.ietf.org/mailman/listinfo/its
> <https://www.ietf.org/mailman/listinfo/its>>
>>>>> <https://www.ietf.org/mailman/listinfo/its
> <https://www.ietf.org/mailman/listinfo/its>
>> <https://www.ietf.org/mailman/listinfo/its
> <https://www.ietf.org/mailman/listinfo/its>>>
>>>>> 
>>>>> 
>>>>> _______________________________________________ its mailing 
>>>>> list [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
> <mailto:[e-mail]>>
>> https://www.ietf.org/mailman/listinfo/its
> <https://www.ietf.org/mailman/listinfo/its>
>> <https://www.ietf.org/mailman/listinfo/its
> <https://www.ietf.org/mailman/listinfo/its>>
>>>>> 
>>>> 
>>>> _______________________________________________ its mailing
>>>> list [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
> <mailto:[e-mail]>>
>> https://www.ietf.org/mailman/listinfo/its
> <https://www.ietf.org/mailman/listinfo/its>
>> <https://www.ietf.org/mailman/listinfo/its
> <https://www.ietf.org/mailman/listinfo/its>>
>>> 
>>> _______________________________________________ its mailing list 
>>> [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
> <mailto:[e-mail]>>
>> https://www.ietf.org/mailman/listinfo/its
> <https://www.ietf.org/mailman/listinfo/its>
>> <https://www.ietf.org/mailman/listinfo/its
> <https://www.ietf.org/mailman/listinfo/its>>
>> 
>> _______________________________________________ its mailing list 
>> [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
> <mailto:[e-mail]>>
>> https://www.ietf.org/mailman/listinfo/its
> <https://www.ietf.org/mailman/listinfo/its>
>> <https://www.ietf.org/mailman/listinfo/its
> <https://www.ietf.org/mailman/listinfo/its>>
>> 
>