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

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 15 Apr 2021 12:20:16 +0200

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

---

From: Jérôme Härri <[email-masked]>
Date: Thu, 15 Apr 2021 12:35:38 +0200

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. 

Best Regards,

Jérôme

-----Original Message-----
From: its <[email-masked]> On Behalf Of Alexandre Petrescu
Sent: Thursday, 15 April 2021 12:20
To: IPWAVE WG <[email-masked]>
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.

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.

Everything else should not be done at IETF, I think; hence my comment about
this particular RFC.

Alex

_______________________________________________
its mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/its

---

From: Russ Housley <[email-masked]>
Date: Thu, 15 Apr 2021 07:46:18 -0400

Alex and Jérôme:

First, the IETF did not publish RFC 8902.  That went through the independent stream.

Second, this was briefed to the TLS WG and the IPWAVE WG.  The presentation to IPWAVE was at IETF 104.  The minutes say, in part:

  WW introduces TLS authentication using certificates in the format
  defined in ETSI ITS and IEEE WAVE.  The objective is to enable
  client/server authentication these certificates.  TLS WG has no
  interest, so WW proposes the work in IPWAVE WG.

The IPWAVE WG also did not have an interest in this work.  So, it it not at all surprising that the people that are using the ETSI ITS and IEEE WAVE certificates took another path.

Russ

> On Apr 15, 2021, at 6:35 AM, Jérôme Härri <[email-masked]> wrote:
> 
> Dear Alex,
>

---

From: Jérôme Härri <[email-masked]>
Date: Thu, 15 Apr 2021 13:51:43 +0200

Dear Russ,

I see. Actually, my reply was not related to IETF activities but more on general terms. 

I could not participate to IETF 104, so I will need to read more about it. 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.

Thanks,

BR,

Jérôme

-----Original Message-----
From: Russ Housley <[email-masked]> 
Sent: Thursday, 15 April 2021 13:46
To: Jérôme Härri <[email-masked]>; Alexandre Petrescu <[email-masked]>
Cc: IPWAVE WG <[email-masked]>
Subject: Re: [ipwave] RFC8902 - TLS with ITS Certificates, EXPERIMENTAL, and the one PKI and one Internet

Alex and Jérôme:

Russ

> 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...
> 
> 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.
> 
> Best Regards,
> 
> Jérôme
> 
> Subject: [ipwave] RFC8902 - TLS with ITS Certificates, EXPERIMENTAL, 
> and the one PKI and one Internet
> 
> Hi, IPWAVErs,
> 
> 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.
> 
> 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 
> 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
> There are many easily accessible CAs (Certificate Authorities) that 
> are integrated in the Internet and in main web browsers, whereas the

---

From: Russ Housley <[email-masked]>
Date: Thu, 15 Apr 2021 10:02:39 -0400

Carlos and I have observed very low energy in the IPWAVE WG for quite some time.  Our expectation is that the WG will be closed once the last document in the publication process becomes an Informational RFC.  See https://datatracker.ietf.org/group/ipwave/documents/

Russ

> On Apr 15, 2021, at 7:51 AM, Jérôme Härri <[email-masked]> wrote:
> 
> Dear Russ,
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 15 Apr 2021 22:41:44 +0200

Le 15/04/2021 à 12:35, Jérôme Härri a écrit :
> 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.
> 
> 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 

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 <[email-masked]> On Behalf
> Of Alexandre Petrescu Sent: Thursday, 15 April 2021 12:20 To: IPWAVE
> WG <[email-masked]> 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.
> 
> 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.
> 
> standards, whereas 1609.2 are closed documents and ETSI ITS
> certificate software is not integrated in mainline software like
> openssl.
> 
> expensive.  Many strong oppinions maintain that it should stay that
> way: cars PKI different than Internet PKI.
> 
> _______________________________________________ its mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/its
> 
> _______________________________________________ its mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/its
>

---

From: Mounira MSAHLI <[email-masked]>
Date: Fri, 16 Apr 2021 14:13:52 +0200

Dear all, Dear Russ, Dear Jerome, Dear Alex,

I’m sorry for the delay. I would like to provide some clarifications

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

which is about deploying 3000 cars + 2000 km of roads

- InterCor https://intercor-project.eu/,

- C-Roads Platform 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
.

All these projects are using ETSI TS 103 097 certificates, which is a
profile of 1609.2 to secure C-ITS messages:

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

We could also use the RFC for Vehicle-To-Internet simply to upload log of
vehicle for example etc…

>> 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. I already used it.

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

>> 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 <[email-masked]>
> Date: jeu. 15 avr. 2021 à 22:44
> To: Jérôme Härri <[email-masked]>, IPWAVE WG <[email-masked]>
>
>
>
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 20 Apr 2021 11:51:17 +0200

Hi, Mounira,

Le 16/04/2021 à 14:13, Mounira MSAHLI a écrit :
> I’m sorry for the delay. I would like to provide some 
> clarificationsconcerning:
> 
> 
> 
> 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/> :
> 
> 
> - InterCor https://intercor-project.eu/
> <https://intercor-project.eu/>,
> 
> <https://www.c-roads.eu/platform.html>
> 
> 
> <https://www.c-roads.eu/pilots/core-members/france/Partner/project/show/indid.html>.
> 
> 
> 
> 

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

> <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:
> 
> 
> ---------- Forwarded message --------- De : *Alexandre Petrescu*
> <[email-masked] <mailto:[email-masked]>> 
> 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 <[email-masked] 
> <mailto:[email-masked]>>, IPWAVE WG <[email-masked] 
> <mailto:[email-masked]>>
> 
> 
> 
> 
>> 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...
>> 
>> 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).
> 
>> -----Original Message----- From: its <[email-masked]
> <mailto:[email-masked]>> On Behalf
>> Of Alexandre Petrescu Sent: Thursday, 15 April 2021 12:20 To:
>> IPWAVE WG <[email-masked] <mailto:[email-masked]>> Subject: [ipwave]
>> RFC8902
> - TLS with ITS
>> 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.
>> 
>> 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.
>> 
>> 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.
>> 
>> Everything else should not be done at IETF, I think; hence my
>> comment about this particular RFC.
>> 
>> [email-masked] <mailto:[email-masked]>
> <https://www.ietf.org/mailman/listinfo/its>
>> 
>> [email-masked] <mailto:[email-masked]>
> <https://www.ietf.org/mailman/listinfo/its>
>> 
> 
> [email-masked] <mailto:[email-masked]> 
> <https://www.ietf.org/mailman/listinfo/its>
> 
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 21 Apr 2021 19:43:17 +0200

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 :
[...]

>> <http://www.scoop.developpement-durable.gouv.fr/> :

This is not reachable on IPv6.

>> <https://intercor-project.eu/>,

This is not reachable on IPv6.

>> <https://www.c-roads.eu/platform.html>

This is not reachable on IPv6.

>> https://ec.europa.eu/transport/sites/transport/files/c-its_certificate_policy_release_1.pdf 

This is reachable on IPv6.

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

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

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

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 22 Apr 2021 17:52:41 +0200

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.

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 
> 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 : [...]
> 
>>> 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.
>> 
>>> 
>>> 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.
>>> 
>>> 
> 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.
> 
>> Yes, but the spec is paying.  That does inspire seriousness but
>> might inspire risk for the confidence.
>> 
>>> 
>>> 
> 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.
> 
> 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
> 
>> 
>> 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:
>>> 
>>> 
>>> <[email-masked]
>>> <mailto:[email-masked]>> 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
>>> <[email-masked] <mailto:[email-masked]>>,
>>> IPWAVE WG <[email-masked] <mailto:[email-masked]>>
>>> 
>>> 
>>> 
>>> 
>>>> 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
>>>> 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.
>>>> 
>>>>  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
>>>> 
>>>> IPWAVE WG <[email-masked] <mailto:[email-masked]>> Subject:
>>>> [ipwave] RFC8902
>>> - TLS with ITS
>>>> A colleague pointed me to this recently issued RFC 8902 about
>>>> TLS with ITS Certificates.
>>>> 
>>>>  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.
>>>> 
>>>>  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.
>>>> 
>>>> 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.
>>>> 
>>>> _______________________________________________ its mailing
>>>> list [email-masked] <mailto:[email-masked]>
>>>> _______________________________________________ its mailing
>>>> list [email-masked] <mailto:[email-masked]>

---

From: Mounira MSAHLI <[email-masked]>
Date: Thu, 22 Apr 2021 17:52:47 +0200

> Hi Alex,
> (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).
>
>
>
> Why not? I did not get the point of the common browsers but it was tested
> on hybrid communication ITS-G5 and 5G
>
>
>
> The case of TLS Client Using the ITS Certificate and TLS Server Uses the
> X.509 Certificate is already covered by the RFC 8902.
>
>
> 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/> :
>
>
> 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 <
> [email-masked]> a écrit :
>
>> Hi, Mounira,
>>
>> >>> participated, and
>> > <
>> > <

---

From: Mounira MSAHLI <[email-masked]>
Date: Thu, 22 Apr 2021 19:16:22 +0200

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 <[email-masked]> a
écrit :

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

---

From: Mounira MSAHLI <[email-masked]>
Date: Thu, 22 Apr 2021 19:30:39 +0200

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

The EU commission is providing a PKI for member states who are not
deploying C-ITS PKI, I think for free.

You mean ethical aspects ?

Kind Regards
Mounira

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 23 Apr 2021 12:58:15 +0200

Hi, Mounira,

Le 22/04/2021 à 17:52, Mounira MSAHLI a écrit :
>>>  where more open certificates are being used, with more open 
>>> source software.
> 
> 
> 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).

It is good to know.

I would like to ask: can one implement ETSI TS 103 097 completely
independently of having the 1609.2 document?  This is very important for
an implementer with low ressources, because the ETSI TS document is free
access whereas the 1609.2 is paying.

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

The point is the following: if one puts a CAM message on 4G on IP, and
signed with a 1609.2 certificate, then that message would need to be
verified in a browser.  That browser would need a CA in its built-in
list.  That CA should be understanding the 1609.2 format.

It is ok to send CAM messages on ITS-G5 and signed with 1609.2
certificates, because that is not IP, and it is in closed domains where
one also puts a CA manually (not built in in browsers downloaded from
the Internet).

But even if there is trust on ITS-G5 relying on self-made CAs, that same
trust can not be extended to 4G.  The trust on 4G is the Internet trust,
i.e. built-in CAs in browsers.

A commodity PC receiving a CAM message in the car will never trust it if
it arrived via a 4G interface.  If that CAM arrived on an ITS-G5
interface, then there might be some trust (the ITS-G5 forwarding
computer might have CAs certs), but that is not 'end-to-end' trust.

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

YEs - this is what all demonstrators of cars I have seen in Europe do:
self-made certificates and self-made CAs.

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

First, I fully disagree with that RFC, but that is a personal oppinion.

It is an EXPERIMENTAL RFC, so I can live with it.

It has some problems that we can discuss about separately.

>>> browsers.  But can Microsec sign these 1609.2 certificates and
>>> still not ask me (end  user) to pay for the certificates?
> 
> 

'compliant', but does it work in practice?

If yes, then it is great!

> So if you have end user micros cert, you can use it to sign C-ITS 

Good to know.

> You mean the certificate authority. You want to sign CAM with 
> certificate authority ?

I meant to say that Microsec might provide me certificates for cars, for 
almost free.  I hope these certs have the right format.

Microsec CA is already present built in in the browsers.

So, I suspect that I could send CAM messages over IP over 4G, signed 
with these certificates that Microsec provided.

I must say that I dont know precisely how to sign IP messages by using 
certificates, but I do know how to send CAM messages on IP on 4G.  One 
woule be using the asn1.c open source to build the message, and BSD 
sockets to send them.

I suspect (dont know?) that signing an IP message might be a matter of 
calling a C function from the openssl open source package.

>>> http://www.scoop.developpement-durable.gouv.fr/
> <http://www.scoop.developpement-durable.gouv.fr/>> :
> 
> 

Yes, I mean that URL is not reachable on IPv6.  That says a lot about it.

There is one thing to talk about IPv6 and another thing to do it.

There is one thing to say that all vehicular communications must be on 
IPv6 and there is another thing to actually do it.

> Scoop + Intercor projects are already finished in December 2019.

Great, I think they were a great success.  I heard very good things 
about their advancements and demonstrations.

> SaaS. If you want to get access to this service via IPv6, you can ask
> the PKI.

I think there is indeed a business model for PKIs used for vehicular 
networks.  But that business model should approach more the existing 
business models of the large CAs that are built-in in browsers, rather 
than the business models of vehicular manufacturers.

It is the business model of vehicular manufacturers (their 'digitizing') 
that should be adapted, and not vice-versa.

In this advancement of the business model, the most important criterion 
is the trust.  Without trust there can be no money made.

One cant build two alternate trusts: one for the Internet, and one for 
Internet of cars.  They must be together one trust.

Alex

> 
> 
> 
> Best Regards
> 
> Mounira
> 
> 
> Le mar. 20 avr. 2021 à 11:51, Alexandre Petrescu 
> a écrit :
> <http://www.scoop.developpement-durable.gouv.fr/>
>> <http://www.scoop.developpement-durable.gouv.fr/
> <http://www.scoop.developpement-durable.gouv.fr/>> :
>> 
>> 
> <https://intercor-project.eu/>
>> <https://intercor-project.eu/ <https://intercor-project.eu/>>,
>> 
>> <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://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>>
> 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.
> 
>> use MQTT to exchange C-ITS messages
> between many
> 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?
> 
> browsers to implement these 1609.2 certs.  And they are paying. I 
> doubt it could work.
> 
>> 
>> 
>> 
> documents
>>>> and ETSI ITS certificate software is not integrated in
>>>> mainline software like openssl.
>> 
>> 
> <https://github.com/pvendil/c2c-common>
>> <https://github.com/pvendil/c2c-common
> <https://github.com/pvendil/c2c-common>>. I already used it.
> 
>> <https://www.ghsiss.com/v2x-certificates/
> <https://www.ghsiss.com/v2x-certificates/>>
> 
> 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?
> 
> <mailto:[email-masked]> 
> <mailto:[email-masked] 
> <mailto:[email-masked]>>>
> <mailto:[email-masked]>
>> <mailto:[email-masked]
> <mailto:[email-masked]>>>, IPWAVE WG <[email-masked] 
> <mailto:[email-masked]>
>> <mailto:[email-masked] <mailto:[email-masked]>>>
>> 
>> 
>> 
>> 
> (Public
> <mailto:[email-masked]>
>> <mailto:[email-masked] <mailto:[email-masked]>>>
> On Behalf
>>> IPWAVE WG <[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]>>> Subject: [ipwave]
>>> RFC8902
>> - TLS with ITS
> participated,
> list
>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>
>> <https://www.ietf.org/mailman/listinfo/its
> <https://www.ietf.org/mailman/listinfo/its>>
>>> 
> list
>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>
>> <https://www.ietf.org/mailman/listinfo/its
> <https://www.ietf.org/mailman/listinfo/its>>
>>> 
>> 
>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>
>> <https://www.ietf.org/mailman/listinfo/its
> <https://www.ietf.org/mailman/listinfo/its>>
>> 
>>

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 23 Apr 2021 13:01:15 +0200

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 <[email-masked] 
> <mailto:[email-masked]>> 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).
> 
> 
> 
>         Why not? I did not get the point of the common browsers but it
>         was tested on hybrid communication ITS-G5 and 5G
> 
> 
> 
>         for
>         The case of TLS Client Using the ITS Certificate and TLS Server
>         Uses the X.509 Certificate is already covered by the RFC 8902.
> 
> 
>            IEEE Std 1609.2 (IEEE Standard for Wireless Access in
>         Vehicular Environments);
> 
>         • ETSI TS 102 940 (ITS-S security (PKI) architecture and
>         application groups);
> 
>         So if you have end user micros cert, you can use it to sign
>         C-ITS messages.
> 
> 
>         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
> 
> 
>         <mailto:[email-masked]>> a écrit :
> 
>             Hi, Mounira,
> 
>              >>> ITS-specific CAs are closed, hard to access and the
>             certificate
>              >>> are
>              >
>              > Thank you Russ for your time on this RFC and for your
>             valuable
>              > review.
>              >
>              >
>              >
>              > Kind regards
>              >
>              > Mounira
>              >
>              >
>              >
>              >
>              >
>              >
>              >
>              >
>              >> -----Original Message----- From: its
>             <[email-masked] <mailto:[email-masked]>
>              > <mailto:[email-masked]
>             <mailto:[email-masked]>>> On Behalf
>             trials
>              >> There should be one Internet, and that means one trust,
>             and one
>              >> PKI.
>              >>

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 23 Apr 2021 13:14:06 +0200

Le 22/04/2021 à 19:30, Mounira MSAHLI a écrit :
> 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.

> industry.

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

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 
> - 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.
> 
> 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.
> 
> Maybe we can write a brief Internet Draft about wishes about 
> security, Internet, and Intelligent Transportation Systems.
> 
> Alex
> 
> 
>> 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.
>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> All these projects are using ETSI TS 103 097 certificates, 
>>>> which is a profile of 1609.2 to secure C-ITS messages:
>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 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.
>>> 
>>>  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.
>>> 
>>>> 
>>>> 
>>> software), or would it be a widely known CA like the CAs present 
>>> in firefox, for example?
>>> 
>>>>>> 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.
>>>> 
>>>> 
>> 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> to be on
>> IPv6.
>> 
>> 
>>>>>> certificate are
>>  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
>> 
>>> 
>>>> I’m also interested to work on security interoperability in 
>>>> C-ITS and we could add:
>>>> 
>>>> 
>>>> ---------- Forwarded message --------- De : *Alexandre 
>>>> Petrescu* <[email-masked] 
> <mailto:[email-masked]>>> Date: jeu. 15 avr. 2021 à
>>>> 22:44 Subject: Re: [ipwave] RFC8902 - TLS with ITS 
>>>> To: Jérôme Härri <[email-masked] 
> <mailto:[email-masked]>>>,
>>>>> 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...
>>>>> 
>>>>>  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
>>>> that are verified by CAs that are absent from normal browsers,
>>>> or how the CAs that are present in normal browsers would help
>>>> On
> Behalf
> <mailto:[email-masked] <mailto:[email-masked]>>> Subject:
>>>>> [ipwave] RFC8902
>>>> - TLS with ITS
>>>>> 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.
>>>>> 
>>>>> participated, and some about I heard of, people use normal 
>>>>> PKI with openssl and normal certificates in cars, over IP, on
>>>>> normal CAs.  These dont use the ETSI ITS-specific 
>>>>> 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. 
>>>>> 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.
>>>>> 
>>>>> list [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>
>>>>> list [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>
>>>> list [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 23 Apr 2021 13:30:20 +0200

[...]

> You mean the certificate authority. You want to sign CAM with 

Sorry, error of saying.

I did not mean the CA to sign the CAM.

I mean the CA signs the certs it gives me, and I sign the CAM with these
certs.  The receiver verifies using the CA they already have in built-in
in their browsers.

(in some OS like Windows, there is also another list of built-in CAs,
which is coupled tightly with that OS's browser; but that is it: a
built-in list of CAs).

[...]

> You mean the web page of the project or the PKI of the project ?

Thanks for the distinction.  That is a perfect distinctor to formulate
in a wish list, or in a list of requirements:

Both the server and the web page of the project should be reachable on IPv6.

I am not sure which protocol is used to communicate with the CA, maybe
OCSP, maybe others.  But these protocols must all be run on IPv6 for a
CA that supports vehicular networks.  If necessary, they could also be
on IPv4.

For the web page: for me personally, if a website of a trust provider is
available on IPv6 it inspires further trust.

But I am also aware that some websites, including Google, have very
strange behaviour with respect to security when on IPv6.  For example,
if I use the SMTP server on IPv6 on Google it some times complains
saying this is a new device, and makes additional cumbersome security
checks.  It is in fact a new protocol that Google knows very well since
long time (they promote IPv6 since long time now).

These are problems that should not appear in vehicular networks, if
addressed well.

Alex

---

From: Mounira MSAHLI <[email-masked]>
Date: Sun, 25 Apr 2021 12:08:16 +0200

Hi Alex

>> I would like to ask: can one implement ETSI TS 103 097 completely
independently of having >> the 1609.2 document?  This is very important for
an implementer with low ressources, because the ETSI TS document is free
access whereas the 1609.2 is paying.

You can find the ASN1 structure of IEEE 1609.2  certificate and signature
in the annex of ETSI TS 103 097 v 1.3.1

>> A commodity PC receiving a CAM message in the car will never trust it if
it arrived via a 4G interface.  If that CAM arrived on an ITS-G5 interface,
then there might be some trust (the ITS-G5 forwarding computer might have
CAs certs), but that is not 'end-to-end' trust.

If the message is signed with a valid certificate with a valid trust chain,
we can trust it regardless the transmission channel if it is short range
 and long range

>> First, I fully disagree with that RFC, but that is a personal oppinion.
It is an EXPERIMENTAL RFC, so I can live with it. It has some problems that
we can discuss about separately.

You disagree with the form of the document but not the content. It was
reviewed by many IETF specialists on TLS and security so it is ready  to be
tested in deployment project.

Mounira

Le ven. 23 avr. 2021 à 12:58, Alexandre Petrescu <
[email-masked]> a écrit :

> > which is a
> > to sign
> > software and
> > C-ITS and
> > when it
> > are at

---

From: Mounira MSAHLI <[email-masked]>
Date: Sun, 25 Apr 2021 12:19:48 +0200

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

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

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.

PKI is the Public Key Infrastructure

>> CAs... It's the CAs themselves that provide it.

It is about one PKI for all not 1 PKI/country(without C-ITS PKI).

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

Mounira

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 26 Apr 2021 12:14:46 +0200

Le 25/04/2021 à 12:08, Mounira MSAHLI a écrit :
>>> independently of having >> the 1609.2 document?  This is very
>>> important for an implementer with low ressources, because the
>>> ETSI TS document is free access whereas the 1609.2 is paying.
> 
> 
> You can find the ASN1 structure of IEEE 1609.2  certificate and 
> signature in the annex of ETSI TS 103 097 v 1.3.1

Yes, thanks for the pointer.

But that ASN1 structure says this:
> IMPORTS Ieee1609Dot2Data, ExplicitCertificate FROM IEEE1609dot2

That means that an implementer must have "IEEE1609dot2" in order to
implement it.  That is a paying document.

(it's the same situation with SPAT-EM and SPAT (one imports the other,
and hence must pay); but it is not the case with CAM and BSM (one does
not import the other, and hence one must not pay)).

>>> A commodity PC receiving a CAM message in the car will never 
>>> trust it if it arrived via a 4G interface.  If that CAM arrived 
>>> on an ITS-G5 interface, then there might be some trust (the 
>>> ITS-G5 forwarding computer might have CAs certs), but that is not
>>> 'end-to-end' trust.
> 
> 
> If the message is signed with a valid certificate with a valid trust
>  chain, we can trust it regardless the transmission channel if it is
>  short range and long range.

The question that might be raised is what is a 'valid certificate'.  In
order to be sure a certificate is valid, often times the commodity PC
relies on a CA certificate that is built-in into the browser, or in the
operating system.

Without such a CA built-in one should some times manually install CAs in
the PCs.  That works ok in small demonstration pilots, but it is not
well adapted for large scale deployments.  By that I do not mean the
'Large Scale Pilots' but I mean widespread adoption by the public at large.

>>> First, I fully disagree with that RFC, but that is a personal 
>>> oppinion. It is an EXPERIMENTAL RFC, so I can live with it. It 
>>> has some problems that we can discuss about separately.
> 
> 
> You disagree with the form of the document but not the content.

The form: not few would disagree with its ToC.

I also disagree with some aspects in its content.  I can write about it
separately.  I am not sure though that there is interest in progressing
it beyond being an EXPERIMENTAL RFC.

This is a contradiction that I learned to live with: some RFCs are
called Requests for Comments, but they dont really need comments.

If there were a need to discuss that RFC then it would have been
discussed publicly when it was an I-D.

This is not a negative remark, and all RFCs that go through detailed
reviews, as this one has, are useful.  Better have an RFC on the topic
rather than silence.

> It was reviewed by many IETF specialists on TLS and security so it is
> ready  to be tested in deployment project.

YEs, good to know.

Alex

> 
> 
> 
> 
> Mounira
> 
> 
> Le ven. 23 avr. 2021 à 12:58, Alexandre Petrescu 
>>>> domain (connected automated mobility with self-driving cars) 
>>>> and where more open certificates are being used, with more
>>>> open source software.
>> 
>> 
> independently of having the 1609.2 document?  This is very important
>  for an implementer with low ressources, because the ETSI TS document
>  is free access whereas the 1609.2 is paying.
> 
>>>> 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.
>> 
>> 
> The point is the following: if one puts a CAM message on 4G on IP, 
> and signed with a 1609.2 certificate, then that message would need to
> be verified in a browser.  That browser would need a CA in its 
> built-in list.  That CA should be understanding the 1609.2 format.
> 
> certificates, because that is not IP, and it is in closed domains 
> where one also puts a CA manually (not built in in browsers 
> downloaded from the Internet).
> 
> But even if there is trust on ITS-G5 relying on self-made CAs, that 
> same trust can not be extended to 4G.  The trust on 4G is the 
> Internet trust, i.e. built-in CAs in browsers.
> 
> A commodity PC receiving a CAM message in the car will never trust it
> if it arrived via a 4G interface.  If that CAM arrived on an ITS-G5
> YEs - this is what all demonstrators of cars I have seen in Europe 
> do: self-made certificates and self-made CAs.
> 
>>>> But for deployment there would be a need for the existing CAs 
>>>> in the browsers to implement these 1609.2 certs.  And they are 
>>>> certificates for cheaper (free), if it is for evaluation, or 
>>>> for academia, or similar.  And Microsec CA _is_ present in the 
> I meant to say that Microsec might provide me certificates for cars, 
> for almost free.  I hope these certs have the right format.
> 
> I must say that I dont know precisely how to sign IP messages by 
> using certificates, but I do know how to send CAM messages on IP on 
> 4G.  One woule be using the asn1.c open source to build the message,
>  and BSD sockets to send them.
> 
> I suspect (dont know?) that signing an IP message might be a matter 
> of calling a C function from the openssl open source package.
> 
>> 
>> 
> <http://www.scoop.developpement-durable.gouv.fr/>>> :
>> 
>> 
> There is one thing to say that all vehicular communications must be 
> on IPv6 and there is another thing to actually do it.
> 
>> 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.
> 
> business models of the large CAs that are built-in in browsers, 
> rather than the business models of vehicular manufacturers.
> 
> It is the business model of vehicular manufacturers (their 
> 'digitizing') that should be adapted, and not vice-versa.
> 
> In this advancement of the business model, the most important 
> criterion is the trust.  Without trust there can be no money made.
> 
> One cant build two alternate trusts: one for the Internet, and one 
> for Internet of cars.  They must be together one trust.
> 
> Alex
> 
>> 
>> 
>> 
>> Best Regards
>> 
>> Mounira
>> 
>> 
> <http://www.scoop.developpement-durable.gouv.fr/>>
> <http://www.scoop.developpement-durable.gouv.fr/>>> :
>>> 
>>> 
>> <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://www.c-roads.eu/platform.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://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>>>
>>> we use MQTT to exchange C-ITS messages
>> between many
> <https://github.com/pvendil/c2c-common>>
> <https://github.com/pvendil/c2c-common>>>. I already used it.
>> 
> <https://www.ghsiss.com/v2x-certificates/>>>
>> 
>> 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.
>>> 
>>> 
> <mailto:[email-masked]>>
> <mailto:[email-masked]>>>>
>> <mailto:[email-masked]>>
> <mailto:[email-masked]>>>>, IPWAVE WG <[email-masked] 
> <mailto:[email-masked]>
>> <mailto:[email-masked] <mailto:[email-masked]>>
>>> <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>>>
>>> 
>>> 
>>> 
>>> 
>>>> 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
>> example
>>>> 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.
>>> 
>> <mailto:[email-masked] <mailto:[email-masked]>>
>>> <mailto:[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]>>>>
>> On Behalf
> <mailto:[email-masked] <mailto:[email-masked]>>
>> <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>>> Subject: [ipwave]
>>>> RFC8902
>>> - TLS with ITS
>>>> 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.
>>>> 
>>>> ITS certificate software is not integrated in mainline
>>>> software like openssl.
>>>> 
> <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]>
> <https://www.ietf.org/mailman/listinfo/its>>>
>>>> 
> <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]>
> <https://www.ietf.org/mailman/listinfo/its>>>
>>>> 
>>> 
> <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]>
> <https://www.ietf.org/mailman/listinfo/its>>>
>>> 
>>>

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 26 Apr 2021 12:40:16 +0200

Le 25/04/2021 à 12:19, Mounira MSAHLI a écrit :
> 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:
> 
> 

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.

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

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

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

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

Alex

> 
> 
> Mounira
> 
> 
> 
> Le ven. 23 avr. 2021 à 13:14, Alexandre Petrescu 
>> strategy change of pseudonyms implemented in C-ITS station to
>> avoid tracking and to ensure privacy.
> 
> I agree, it might be so.
> 
> If we can invite a CA provider to express their requirements, then
> there could be advancement.
> 
>> 
>> 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.
>> 
> 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 :-)
> 
>> 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
>> 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 
>>> 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
>>> 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
>>>>> specifications in Europe
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> As mentioned by Jerome, one use case of the RFC 8902 could
>>>>> be to sign CAM and DENM messages on facilities layer and 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.
>>>> 
>>>>> 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.
>>>> 
>>>>> 
>>>>> 
>>>> 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.
>>>> 
>>>>>>> software and freely accessible standards, whereas
>>>>>>> 1609.2 are closed documents and ETSI ITS certificate
>>>>>>> software is not integrated in mainline software like
>>>>>>> openssl.
>>>>> 
>>>>> 
>>> 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.
>>>> 
>>>>> 
>>>>> 
>>> These kinds of CAs (Microsec and Let's Encrypt) are good
>>> candidates to whom to propose interoperability for vehicular
>>> networks on IPv6.
>>> 
>>> 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?
>>>> 
>>>> 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.
>>>>> 
>>>>> 
>>>>> valuable review.
> <mailto:[email-masked]>>>> Date: jeu. 15 avr. 2021 à
>> <mailto:[email-masked] <mailto:[email-masked]> 
> <mailto:[email-masked]>>>>,
>>>>>> 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
>>>>>> 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.
>>>>>> 
>>>>>> 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.
>>>>> 
>>>>> 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
>>>>>> 
>>>>>> Of Alexandre Petrescu Sent: Thursday, 15 April 2021 12:20
>>>>>> To: IPWAVE WG <[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked]>>>> Subject:
>>>>>> [ipwave] RFC8902
>>>>> - TLS with ITS
>>>>>> A colleague pointed me to this recently issued RFC 8902
>>>>>> about TLS with ITS Certificates.
>>>>>> 
>>>>>> 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.
>>>>>> 
>>>>>> 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
>>>>>> (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.
>>>>>> 
>>>>>> 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:
>>>>>> and one PKI.
>>>>>> Everything else should not be done at IETF, I think; hence
>>>>>> my comment about this particular RFC.
>>>>>> 
>>>>>> _______________________________________________ its
>>>>>> mailing list [email-masked] <mailto:[email-masked]>
>>>>>> <mailto:[email-masked]
>>>>>> _______________________________________________ its
>>>>>> mailing list [email-masked] <mailto:[email-masked]>
>>>>>> <mailto:[email-masked]

---

From: Mounira MSAHLI <[email-masked]>
Date: Mon, 26 Apr 2021 15:53:59 +0200

> >> - the CA must be reachable on IPv6, and their website too.
        Could you please mention why not IPv4 ?

>    (e.g. on an IPv6 website, FTP directory, or GIT shared space).

You mean certificate policy. I have the same question. You are specifying
the IP protocol for the PKI website. I agree that document must be
published and available to PKI users but why IPV6 ?

>    documents in order to implement (I think?).

William could answer you this question better than me because it was
already asked by ETSI.

I find that all recommandations are related to the use of IPv6 not really
the
security or privacy in C-ITS. By analogy with what you are suggesting, I
think  that you would prefer to use IPv6 for the upload of log and download
of updates and all V2I communications not only V2PKI connexion.

Mounira

---

From: Mounira MSAHLI <[email-masked]>
Date: Mon, 26 Apr 2021 16:07:56 +0200

In my memory, the RFC was presented by William in IPWAVE GROUP in 2019. But
IPWAVE did not host this activity as it was outside the charter as
currently written. Although there was a possibility to rewrite the charter,
but we had to wait until the two current documents being worked on by
IPWAVE had been completed so as not to defocus the group.

If your conclusion is that « this RFC is not really relevant to ITS", this
is hard to agree with because the large deployment of C-ITS. As mentioned
by William before, ITS deployments across the US, Europe and Australia are
currently using 1609.2 certificates.

Mounira

---

From: William Whyte <[email-masked]>
Date: Mon, 26 Apr 2021 14:25:18 +0000

>> If your conclusion is that « this RFC is not really relevant to ITS", this is hard to agree with because the large deployment of C-ITS. As mentioned by William before, ITS deployments across the US, Europe and Australia are currently using 1609.2 certificates.

Also, ISO 21177 references and builds on RFC 8902, and 21177 is in turn referenced by a number of SAE ITS standards in the US.

William

From: its <[email-masked]> On Behalf Of Mounira MSAHLI
Sent: Monday, April 26, 2021 10:08 AM
To: Alexandre Petrescu <[email-masked]>; [email-masked]
Subject: [EXT] Re: [ipwave] RFC8902 - TLS with ITS Certificates, EXPERIMENTAL, and the one PKI and one Internet

In my memory, the RFC was presented by William in IPWAVE GROUP in 2019. But IPWAVE did not host this activity as it was outside the charter as currently written. Although there was a possibility to rewrite the charter, but we had to wait until the two current documents being worked on by IPWAVE had been completed so as not to defocus the group.

If your conclusion is that « this RFC is not really relevant to ITS", this is hard to agree with because the large deployment of C-ITS. As mentioned by William before, ITS deployments across the US, Europe and Australia are currently using 1609.2 certificates.

Mounira

---

From: William Whyte <[email-masked]>
Date: Mon, 26 Apr 2021 14:29:15 +0000

>> William could answer you this question better than me because it was already asked by ETSI.

Yes, 1609.2 needs to be purchased from IEEE. ETSI has reproduced the ASN.1 (with permission from IEEE) but there are some subtleties of implementation and how the crypto operations are carried out that aren’t captured in the ASN.1 alone.

I’d note that Alex’s preference for standards to be freely available if they are to be referenced by IETF is a reasonable point of view, but it’s not IETF policy; IETF policy allows non-free standards to be referenced.

Cheers,

William

From: its <[email-masked]> On Behalf Of Mounira MSAHLI
Sent: Monday, April 26, 2021 9:54 AM
To: Alexandre Petrescu <[email-masked]>
Cc: [email-masked]
Subject: [EXT] Re: [ipwave] wish list for CAs for vehicular networks

You mean certificate policy. I have the same question. You are specifying the IP protocol for the PKI website. I agree that document must be published and available to PKI users but why IPV6 ?

William could answer you this question better than me because it was already asked by ETSI.

I find that all recommandations are related to the use of IPv6 not really the
security or privacy in C-ITS. By analogy with what you are suggesting, I think  that you would prefer to use IPv6 for the upload of log and download of updates and all V2I communications not only V2PKI connexion.

Mounira

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 26 Apr 2021 16:59:42 +0200

Le 26/04/2021 à 16:29, William Whyte a écrit :
> Yes, 1609.2 needs to be purchased from IEEE. ETSI has reproduced the 
> ASN.1 (with permission from IEEE) but there are some subtleties of 
> implementation and how the crypto operations are carried out that 
> aren’t captured in the ASN.1 alone.
> 
> I’d note that Alex’s preference for standards to be freely available 
> if they are to be referenced by IETF is a reasonable point of view,

Thanks, but I did not really say that.

I said that if one wants to implement the ETSI TS 103 097 whose grammar
is free of access one still needs to pay IEEE for the 1609.2 grammar
because of that 'IMPORT' statement present in the former.  That is
between ETSI and IEEE.

I was not talking about RFCs and IETF.

But for RFCs it is clear as well: if one wants to implement an RFC one
must have full specifications fully at hand and for no price.  One would
need to pay the pipe to access it (i.e. the ISP), the computer to
program, the coffee, but not the document itself.

> but it’s not IETF policy; IETF policy allows non-free standards to
> be referenced.

Probably.  I would need to check which policy one means more precisely.

But it is clear to me that IETF would not put out an RFC which needs
other closed documents in order to be implemented.

It is because one cant talk about text in I-Ds if we do not know the
contents of the documents that they refer to (if these are closed).

Alex

> 
> Cheers,
> 
> William
> 
> *From:* its <[email-masked]> *On Behalf Of * Mounira MSAHLI 
> *Sent:* Monday, April 26, 2021 9:54 AM *To:* Alexandre Petrescu 
> <[email-masked]> *Cc:* [email-masked] *Subject:* [EXT] 
> Re: [ipwave] wish list for CAs for vehicular networks
> 
> You mean certificate policy. I have the same question. You are 
> specifying the IP protocol for the PKI website. I agree that
> document must be published and available to PKI users but why IPV6 ?
> 
> security or privacy in C-ITS. By analogy with what you are 
> suggesting, I think  that you would prefer to use IPv6 for the
> upload of log and download of updates and all V2I communications not
> only V2PKI connexion.
> 
> Mounira
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 26 Apr 2021 17:03:07 +0200

Le 15/04/2021 à 13:46, Russ Housley a écrit :
> Alex and Jérôme:
> 
> First, the IETF did not publish RFC 8902.

Who published RFC8902 if not the IETF?

> That went through the independent stream.

I think independent streams are fine as long as they dont risk hurting.

> Second, this was briefed to the TLS WG and the IPWAVE WG.  The
> presentation to IPWAVE was at IETF 104.  The minutes say, in part:
> 
> The IPWAVE WG also did not have an interest in this work.  So, it it
> not at all surprising that the people that are using the ETSI ITS and
> IEEE WAVE certificates took another path.

It is a private path.  I do not disagree with private paths.

Alex

>> 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 
>> -----Original Message----- From: its <[email-masked]> On
>> Behalf Of Alexandre Petrescu Sent: Thursday, 15 April 2021 12:20 
>> To: IPWAVE WG <[email-masked]> Subject: [ipwave] RFC8902 - TLS with
>> ITS Certificates, EXPERIMENTAL, and the one PKI and one Internet
>> 
>> Hi, IPWAVErs,
>> 
>> 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.
>>

---

From: William Whyte <[email-masked]>
Date: Mon, 26 Apr 2021 15:03:23 +0000

The IMPORT statement imports the 1609.2 ASN.1, but ETSI has permissions to republish it.

"available for a price" is not the same as closed, and IETF policy does not consider documents closed if they are publicly available for a price.

Cheers,

William

-----Original Message-----
From: Alexandre Petrescu <[email-masked]> 
Sent: Monday, April 26, 2021 11:00 AM
To: William Whyte <[email-masked]>; Mounira MSAHLI <[email-masked]>
Cc: [email-masked]
Subject: [EXT] Re: [ipwave] wish list for CAs for vehicular networks

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 26 Apr 2021 17:09:05 +0200

Le 26/04/2021 à 17:03, William Whyte a écrit :
> "available for a price" is not the same as closed, and IETF policy
> does not consider documents closed if they are publicly available for
> a price.

Fair enough.

RFCs are open and fully available at no price.

1609.2 is neither.

ETSI TS is open and fully available at no price but is tainted by the 
1609.2 reference, so in the end it is closed and paying.

In the end, one has to think about whether one wants the vehicular 
networks to be connected to the Internet and use the Internet trust, or 
otherwise be 'limited domains' (RFC8799).

Alex

> 
> Cheers,
> 
> William
> 
> -----Original Message----- From: Alexandre Petrescu
> <[email-masked]> Sent: Monday, April 26, 2021 11:00 AM 
> To: William Whyte <[email-masked]>; Mounira MSAHLI
> <[email-masked]> Cc: [email-masked] Subject: [EXT] Re: [ipwave]
> wish list for CAs for vehicular networks
> 
> 
> 
>> 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?).
>> 
>> Yes, 1609.2 needs to be purchased from IEEE. ETSI has reproduced
>> the ASN.1 (with permission from IEEE) but there are some subtleties
>> of implementation and how the crypto operations are carried out
>> that aren’t captured in the ASN.1 alone.
>> 
>> I’d note that Alex’s preference for standards to be freely
>> available if they are to be referenced by IETF is a reasonable
>> point of view,
> 
> I said that if one wants to implement the ETSI TS 103 097 whose
> grammar is free of access one still needs to pay IEEE for the 1609.2
> grammar because of that 'IMPORT' statement present in the former.
> That is between ETSI and IEEE.
> 
> But for RFCs it is clear as well: if one wants to implement an RFC
> one must have full specifications fully at hand and for no price.
> One would need to pay the pipe to access it (i.e. the ISP), the
> computer to program, the coffee, but not the document itself.
> 
> 
>> - 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?).
>> 
>> upload of log and download of updates and all V2I communications
>> not only V2PKI connexion.
>> 
>> Mounira
>>

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 26 Apr 2021 17:12:21 +0200

Le 26/04/2021 à 16:25, William Whyte a écrit :
>  >> If your conclusion is that « this RFC is not really relevant to 
> ITS", this is hard to agree with because the large deployment of C-ITS. 
> As mentioned by William before, ITS deployments across the US, Europe 
> and Australia are currently using 1609.2 certificates.
> 
> Also, ISO 21177 references and builds on RFC 8902, and 21177 is in turn 
> referenced by a number of SAE ITS standards in the US.

Again, a few documents (ISO 21177 and SAE ITS) about which I must shut 
up because I dont know what to say, because I cant see them.  I will not 
buy them.

But, if needed, I can make comments about RFC8902 contents because it is 
open and free.

I suspect that nobody wants RFC8902 modified because that would imply 
modifications to ISO and SAE ITS documents, so, I better dont make these 
comments.

Alex

> *Sent:* Monday, April 26, 2021 10:08 AM
> *To:* Alexandre Petrescu <[email-masked]>; [email-masked]
> *Subject:* [EXT] Re: [ipwave] RFC8902 - TLS with ITS Certificates, 
> EXPERIMENTAL, and the one PKI and one Internet
> 
> In my memory, the RFC was presented by William in IPWAVE GROUP in 2019. 
> But IPWAVE did not host this activity as it was outside the charter as 
> currently written. Although there was a possibility to rewrite 
> the charter, but we had to wait until the two current documents being 
> worked on by IPWAVE had been completed so as not to defocus the group.
> 
> If your conclusion is that « this RFC is not really relevant to ITS", 
> this is hard to agree with because the large deployment of C-ITS. As 
> mentioned by William before, ITS deployments across the US, Europe and 
> Australia are currently using 1609.2 certificates.
> 
> Mounira
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 26 Apr 2021 19:18:22 +0200

Le 26/04/2021 à 16:29, William Whyte a écrit :
>>> paying
>  ASN.1 (with permission from IEEE)

Is that permission from IEEE only for ETSI or is it for me too?

Because the text says: "This clause provides the relevant ASN.1 modules 
from IEEE Std 1609.2 [1] (and its amendments), reprinted with
permission from IEEE, Copyright © 2016."

To me, that means a permission to print, but not necessarily to put in code.

Alex

  but there are some subtleties of
> but it’s not IETF policy; IETF policy allows non-free standards to be
>  referenced.
> 
> Cheers,
> 
> William
> 
> specifying the IP protocol for the PKI website. I agree that document
>  must be published and available to PKI users but why IPV6 ?
> 
> 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
> suggesting, I think  that you would prefer to use IPv6 for the upload
> of log and download of updates and all V2I communications not only
> V2PKI connexion.
> 
> Mounira
>

---

From: Jérôme Härri <[email-masked]>
Date: Tue, 27 Apr 2021 09:00:33 +0200

Dear Alex, Dear All,

I am not sure to follow here. ETSI provides on its website the ASN1 code (a zip file) for the ETSI security framework version 1.3 (and you can parse it into C or C++ code). We are using it on a network simulator VANETZA. Neither the side nor the content of the .zip file indicate we cannot use it. I am not making any commercial product though...

Of course, there is a difference between accessing the document or the ASN1 code. The ETSI Security standard v1.3 provides a full description of the 'main' message blocks and functional requirements for all DAY 1 ETSI services. Indeed, the ETSI document points to some 1609.2 structures in 1609.2 documents, which I could not access, but I could get the structures details from the ASN1 code. From my understanding and my experience in implementing the 1.3.1 code, I do not need 1609.2 document to make it work, all functional requirements are in the ETSI document.

One point:  I only implemented the security framework stack, not the algorithms to build public/private keys or certificate chains. Maybe for that, there is an issue...not sure,

BR,

Jérôme

-----Original Message-----
From: its <[email-masked]> On Behalf Of Alexandre Petrescu
Sent: Monday, 26 April 2021 19:18
To: William Whyte <[email-masked]>; Mounira MSAHLI <[email-masked]>
Cc: [email-masked]
Subject: Re: [ipwave] permission

Because the text says: "This clause provides the relevant ASN.1 modules from IEEE Std 1609.2 [1] (and its amendments), reprinted with permission from IEEE, Copyright © 2016."

Alex

> security or privacy in C-ITS. By analogy with what you are suggesting, 
> I think  that you would prefer to use IPv6 for the upload of log and 
> download of updates and all V2I communications not only V2PKI 
> connexion.
> 
> Mounira
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 27 Apr 2021 17:36:22 +0200

First, let me say that I might have been wrong when I said that the ETSI
code does not compile because it needed IEEE code.  I must say that I
never tried myself to generate the C code from ASN.1 and then compile
it, for these certificates; but tried it for CAM and SPAT.

Your description seems to say the ETSI code for these certificates
(including the IEEE code in it) is working ok.  I do not disagree.

One side note is the following: one might wonder why is that IEEE
document closed and paying if it is revealed in another free document
(the ETSI's).  One might suspect IEEE would not be happy to protect code
which is later revealed by ETSI.  IEEE loses money?

Or I might be wrong altogether again.

To clarify that, let me continue the discussion:

Le 27/04/2021 à 09:00, Jérôme Härri a écrit :
> Dear Alex, Dear All,
> 
> I am not sure to follow here. ETSI provides on its website the ASN1 
> code (a zip file) for the ETSI security framework version 1.3 (and 
> you can parse it into C or C++ code).

That ASN1 code you mention, it is probably the "ASN1 structure of IEEE
1609.2  certificate and signature in the annex of ETSI TS 103 097 v
1.3.1" that Mounira was talking about.

That pdf file contains the ASN.1 code too.  It is sufficient to copy
paste it in a textual file and then feed that into the asn1.c free
softwaare package to generate C files that further compile into a
library.  Then call the functions from that library.

> We are using it on a network simulator VANETZA.

Ok, noted.  It is a traffic simulator, I think.  It is not a real
implementation in a car that might need to interoperate.

> Neither the side nor the content of the .zip file indicate we cannot 
> use it. I am not making any commercial product though...

I have not seen the zip file, but if I were a user I would check it very
carefully.

The ETSI pdf file says the following with respect to Copyright:
> No part may be reproduced or utilized in any form or by any means, 
> electronic or mechanical, including photocopying and microfilm except
> as authorized by written permission of ETSI. The content of the PDF
> version shall not be modified without the written authorization of
> ETSI. The copyright and the foregoing restriction extend to
> reproduction in all media. © ETSI 2017. All rights reserved.
[...]
> The present document contains material from IEEE Std 1609.2-2016 [1]
>  and its amendment(s), reprinted with permission from IEEE, and 
> Copyright © 2016.

So, the question is whether VANETZA obtained that written permission
from ETSI to use that ASN1 code?  And if yes, have they then provided
'you' with that permission as well?  (by 'you', I mean anyone who
downloads VANETZA).

Maybe they have, maybe they have not.  But they are subject to that rule.

> Of course, there is a difference between accessing the document or 
> the ASN1 code. The ETSI Security standard v1.3 provides a full 
> description of the 'main' message blocks and functional requirements 
> for all DAY 1 ETSI services. Indeed, the ETSI document points to some
> 1609.2 structures in 1609.2 documents, which I could not access, but
> I could get the structures details from the ASN1 code.

Yes, but does one also understand the _meaning_ of the fields in that
code?  Do everybody understand it in the same way?  Only with a common
understanding of these fields do we reach interoperability between
implementations.  Otherwise we have independent compliance to standards,
but not necessarily interoperability.  That is the path to 'limited
domains'.

> From my understanding and my experience in implementing the 1.3.1 
> code, I do not need 1609.2 document to make it work, all functional 
> requirements are in the ETSI document.

I think you mean that you use the IEEE parts that are in the ETSI document.

These IEEE parts are there verbatim in the ASN1 description.  They are
somehow self described (e.g. it is easy to understand the field that
says "Latitude ::= NinetyDegreeInt"), but for full and common
understanding one needs the full textual description from the IEEE
document.  For example, how are the points between two integer values
rounded? (e.g. do the points between 800000000 and 800000001 belong to
the former or to the latter? 'Floor' or 'up' function?)  Maybe the IEEE
document tells in its textual description.

> One point:  I only implemented the security framework stack, not the 
> algorithms to build public/private keys or certificate chains. Maybe 
> for that, there is an issue...not sure,

I think you are right in that you might obtain ok compliance to the
standard ETSI, but I am not sure it is interoperable with others that
are themselves compliant with the ETSI standards in their own.

All VW Golf 8 cars understand their respective Car2X messages but
certainly not the V2X of Mitsubishi, and neither vice-versa.

Alex

> Behalf Of Alexandre Petrescu Sent: Monday, 26 April 2021 19:18 To:
> William Whyte <[email-masked]>; Mounira MSAHLI 
> <[email-masked]> Cc: [email-masked] Subject: Re: [ipwave] 
> permission
> 
> 
> 
>> the ASN.1 (with permission from IEEE)
> 
> Because the text says: "This clause provides the relevant ASN.1 
> modules from IEEE Std 1609.2 [1] (and its amendments), reprinted
> with permission from IEEE, Copyright © 2016."
> 
>> point of view, but it’s not IETF policy; IETF policy allows 
>> non-free standards to be referenced.
>> 
>> Cheers,
>> 
>> William
>> 
>> end it is paying.  But the X.509 in RFC 5280 does not rely on
>> other paying documents in order to implement (I think?).
>>