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

[Mounira MSAHLI <[e-mail]>]

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

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

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

You mean ethical aspects ?

Kind Regards
Mounira



Le jeu. 22 avr. 2021 à 17:52, Alexandre Petrescu <
[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/> :
> >
> > 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
>
> _______________________________________________
> its mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/its
>