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

[Alexandre Petrescu <[e-mail]>]

Le 22/04/2021 à 19:16, Mounira MSAHLI a écrit :
> 
> But how you can sign with a certificate retrieved from the browser 
> without the private key ?

Sorry, I may need to clarify: the CA built-in in the browser might serve 
only to verify the the CAM messages are signed in properly; they are not 
used to sign CAM messages.

In order to sign the CAM messages, the PC would need the certificates 
that the CA provided earlier (these 'almost free' certificates Microsec, 
or another, might provide).  These have a prive key that the PC owner 
generates.

I am not talking about the private key of the CA.

Maybe I am not clear enough...

Alex

> 
> Regards
> Mounira
> 
> Le jeu. 22 avr. 2021 à 17:52, Mounira MSAHLI <[e-mail] 
> <mailto:[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/
>         <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]
>         <mailto:[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/>
>              > <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/>
>              > <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>
>              > <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>
>              >
>              >
>             <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>>
>              >
>              >
>              >
>              > 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>>. 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/>
>              > <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]>
>             <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]>>>, IPWAVE WG <[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]>>> 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]>>> 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]>>
>              > 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]>
>             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>
>