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

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

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 
> <alexandre.petrescu@gmail.com <mailto:alexandre.petrescu@gmail.com>>
>  a écrit :
> 
> Hi, Mounira,
> 
> Le 22/04/2021 à 17:52, Mounira MSAHLI 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).
> 
> 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.
> 
>>>> 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.
> 
> 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 
>>>> 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.
> 
>> 
>> 
>>>> Recently I worked with Microsec and they might also propose 
>>>> certificates for cheaper (free), if it is for evaluation, or 
>>>> for academia, or similar.  And Microsec CA _is_ present in the 
>>>> browsers.  But can Microsec sign these 1609.2 certificates and 
>>>> still not ask me (end  user) to pay for the certificates?
>> 
>> 
>> I find that Microsec cert are compliant to standards below:
> 
> 'compliant', but does it work in practice?
> 
> If yes, then it is great!
> 
>> 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.
> 
> Good to know.
> 
>> 
>> 
>>>> And Microsec CA _is_ present in the browsers
>> 
>> 
>> 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.
> 
>> 
>> 
>> I did not get the point could you clarify more please.
>> 
>> 
>> 
>>>> http://www.scoop.developpement-durable.gouv.fr/
> <http://www.scoop.developpement-durable.gouv.fr/>
>> <http://www.scoop.developpement-durable.gouv.fr/
> <http://www.scoop.developpement-durable.gouv.fr/>>> :
>> 
>> 
>>>> This is not reachable on IPv6.
>> 
>> 
>> You mean the web page of the project or the PKI of the project ?
> 
> 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.
> 
>> 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.
> 
> 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 
>> <alexandre.petrescu@gmail.com
> <mailto:alexandre.petrescu@gmail.com> 
> <mailto:alexandre.petrescu@gmail.com 
> <mailto:alexandre.petrescu@gmail.com>>>
>> a écrit :
>> 
>> Hi, Mounira,
>> 
>> Le 16/04/2021 à 14:13, Mounira MSAHLI a écrit :
>>> 
>>> Dear all, Dear Russ, Dear Jerome, Dear Alex,
>>> 
>>> 
>>> 
>>> I’m sorry for the delay. I would like to provide some 
>>> clarificationsconcerning:
>>> 
>>> 
>>> 
>>>>> This discrepancy is the following: in a few trials I 
>>>>> participated, and
>>> 
>>> some about I heard of, people use normal PKI with openssl and
>> normal
>>> 
>>> certificates in cars, over IP, on cellular links like 4G.
>> They work
>>> 
>>> fine.
>>> 
>>> 
>>> But, I want to highlight that the European commission are
>> funding
>>> several Cooperative ITS (C-ITS) deployment projects such as:
>>> 
>>> 
>>> - Scoop@F http://www.scoop.developpement-durable.gouv.fr/
> <http://www.scoop.developpement-durable.gouv.fr/>
>> <http://www.scoop.developpement-durable.gouv.fr/
> <http://www.scoop.developpement-durable.gouv.fr/>>
>>> <http://www.scoop.developpement-durable.gouv.fr/
> <http://www.scoop.developpement-durable.gouv.fr/>
>> <http://www.scoop.developpement-durable.gouv.fr/
> <http://www.scoop.developpement-durable.gouv.fr/>>> :
>>> 
>>> 
>>> which is about deploying 3000 cars + 2000 km of roads
>>> 
>>> 
>>> - InterCor https://intercor-project.eu/
> <https://intercor-project.eu/>
>> <https://intercor-project.eu/ <https://intercor-project.eu/>>
>>> <https://intercor-project.eu/ <https://intercor-project.eu/>
> <https://intercor-project.eu/ <https://intercor-project.eu/>>>,
>>> 
>>> - C-Roads Platform https://www.c-roads.eu/platform.html
> <https://www.c-roads.eu/platform.html>
>> <https://www.c-roads.eu/platform.html
> <https://www.c-roads.eu/platform.html>>
>>> <https://www.c-roads.eu/platform.html
> <https://www.c-roads.eu/platform.html>
>> <https://www.c-roads.eu/platform.html
> <https://www.c-roads.eu/platform.html>>>
>>> 
>>> 
>>> InterCor and C-Roads are about harmonising C-ITS
>> specifications in
>>> Europe
>>> 
>>> 
>>> - INDID
>>> 
>> 
> https://www.c-roads.eu/pilots/core-members/france/Partner/project/show/indid.html
>
>
>
> 
<https://www.c-roads.eu/pilots/core-members/france/Partner/project/show/indid.html>
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
> <https://www.c-roads.eu/pilots/core-members/france/Partner/project/show/indid.html
>
>
>
> 
<https://www.c-roads.eu/pilots/core-members/france/Partner/project/show/indid.html>>
>>> 
>>> 
>> 
> <https://www.c-roads.eu/pilots/core-members/france/Partner/project/show/indid.html
>
>
>
> 
<https://www.c-roads.eu/pilots/core-members/france/Partner/project/show/indid.html>
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
> <https://www.c-roads.eu/pilots/core-members/france/Partner/project/show/indid.html
>
>
>
> 
<https://www.c-roads.eu/pilots/core-members/france/Partner/project/show/indid.html>>>.
>>> 
>>> 
>>> 
>>> 
>>> All these projects are using ETSI TS 103 097 certificates,
>> which is a
>>> profile of 1609.2 to secure C-ITS messages:
>> 
>> But there are also other projects funded by the EU in the same 
>> domain (connected automated mobility with self-driving cars) and 
>> where more open certificates are being used, with more open source 
>> software.
>> 
>>> 
>>> 
>> 
> https://ec.europa.eu/transport/sites/transport/files/c-its_certificate_policy_release_1.pdf
>
>
>
> 
<https://ec.europa.eu/transport/sites/transport/files/c-its_certificate_policy_release_1.pdf>
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
> <https://ec.europa.eu/transport/sites/transport/files/c-its_certificate_policy_release_1.pdf
>
>
>
> 
<https://ec.europa.eu/transport/sites/transport/files/c-its_certificate_policy_release_1.pdf>>
>>> 
>>> 
>> 
> <https://ec.europa.eu/transport/sites/transport/files/c-its_certificate_policy_release_1.pdf
>
>
>
> 
<https://ec.europa.eu/transport/sites/transport/files/c-its_certificate_policy_release_1.pdf>
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
> <https://ec.europa.eu/transport/sites/transport/files/c-its_certificate_policy_release_1.pdf
>
>
>
> 
<https://ec.europa.eu/transport/sites/transport/files/c-its_certificate_policy_release_1.pdf>>>
>>> 
>>> 
>>> 
>>> As mentioned by Jerome, one use case of the RFC 8902 could be
>> to sign
>>> CAM and DENM messages on facilities layer and not geonet as 
>>> specified in ETSI.
>> 
>> Yes, but has that been done?  HAs someone put CAM messages on IP on
>> a 4G link and signed with 1609.2 certificates?  I think not.
>> 
>> It would be good if it worked, but it would need the CAs to know 
>> these certifiicate formats, and the CAs would need to be known in 
>> common browsers.
>> 
>>> Yes, in projects dealing with C-ITS security interoperability,
>>> we use MQTT to exchange C-ITS messages
>> between many
>>> countries to ensure continuity of service when vehicle is
>> crossing
>>> borders.
>> 
>> Ok, good to know.
>> 
>>> 
>>> 
>>> We could also use the RFC for Vehicle-To-Internet simply to
>> upload
>>> log of vehicle for example etc…
>> 
>> Yes, but what CA would be put in the server of that log?  Would 
>> that CA be a self-made CA with openssl (or other open source 
>> software), or would it be a widely known CA like the CAs present in
>> firefox, for example?
>> 
>> My guess is that you assume a self-made CAs, and I agree with it 
>> for experimentation.
>> 
>> But for deployment there would be a need for the existing CAs in 
>> the browsers to implement these 1609.2 certs.  And they are paying.
>> I doubt it could work.
>> 
>>> 
>>> 
>>> 
>>>>> The reason is because the former is all open source
>> software and
>>>>> freely accessible standards, whereas  1609.2 are closed
>> documents
>>>>> and ETSI ITS certificate software is not integrated in 
>>>>> mainline software like openssl.
>>> 
>>> 
>>> There's a java implementation of 1609.2/103 097 here: 
>>> https://github.com/pvendil/c2c-common
> <https://github.com/pvendil/c2c-common>
>> <https://github.com/pvendil/c2c-common
> <https://github.com/pvendil/c2c-common>>
>>> <https://github.com/pvendil/c2c-common
> <https://github.com/pvendil/c2c-common>
>> <https://github.com/pvendil/c2c-common
> <https://github.com/pvendil/c2c-common>>>. I already used it.
>> 
>> Yes, but the spec is paying.  That does inspire seriousness but 
>> might inspire risk for the confidence.
>> 
>>> 
>>> 
>>>>> ITS-specific CAs are closed, hard to access and the 
>>>>> certificate are
>>> 
>>> expensive.  hard to access and the certificate are expensive.
>>> 
>>> 
>>> you can get certificates from 
>>> https://www.ghsiss.com/v2x-certificates/
> <https://www.ghsiss.com/v2x-certificates/>
>> <https://www.ghsiss.com/v2x-certificates/
> <https://www.ghsiss.com/v2x-certificates/>>
>>> <https://www.ghsiss.com/v2x-certificates/
> <https://www.ghsiss.com/v2x-certificates/>
>> <https://www.ghsiss.com/v2x-certificates/
> <https://www.ghsiss.com/v2x-certificates/>>>
>> 
>> Thanks for the pointer, I did not know ghsiss.  Are they paying 
>> certificates?
>> 
>> Recently I worked with Microsec and they might also propose 
>> certificates for cheaper (free), if it is for evaluation, or for 
>> academia, or similar.  And Microsec CA _is_ present in the 
>> browsers. But can Microsec sign these 1609.2 certificates and still
>> not ask me (end user) to pay for the certificates?
>> 
>> Another thing to consider is whether or not ghsiss (and Microsec 
>> for that matter) are reachable on IPv6.  That is also a make kor 
>> break condition of use.  It is worth trying.
>> 
>> Thanks for the message.
>> 
>> Alex
>> 
>>> 
>>> 
>>> 
>>>>> In  my personal opinion, it remains good if IPWAVE provides
>>>>> a guideline on how to secure IP vehicular communication,
>> including
>>>>> interoperability between systems (although I have at that 
>>>>> time limited resources to actively contribute to this), as 
>>>>> several options are on the table and we need to guarantee the
>>>>> trust chain, even considering different protocol or standards
>>>>> being used.
>>> 
>>> 
>>> I’m also interested to work on security interoperability in
>> C-ITS and
>>> we could add:
>>> 
>>> 
>>> - Misbehaving in vehicular network
>>> 
>>> - Revocation management
>>> 
>>> - Pseudonym management/change to avoid tracking and to ensure 
>>> privacy
>>> 
>>> 
>>> Thank you Russ for your time on this RFC and for your valuable 
>>> review.
>>> 
>>> 
>>> 
>>> Kind regards
>>> 
>>> Mounira
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> ---------- Forwarded message --------- De : *Alexandre Petrescu* 
>>> <alexandre.petrescu@gmail.com 
>>> <mailto:alexandre.petrescu@gmail.com>
>> <mailto:alexandre.petrescu@gmail.com
> <mailto:alexandre.petrescu@gmail.com>>
>> <mailto:alexandre.petrescu@gmail.com
> <mailto:alexandre.petrescu@gmail.com>
>> <mailto:alexandre.petrescu@gmail.com
> <mailto:alexandre.petrescu@gmail.com>>>>
>>> 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 <Jerome.Haerri@eurecom.fr
> <mailto:Jerome.Haerri@eurecom.fr>
>> <mailto:Jerome.Haerri@eurecom.fr 
>> <mailto:Jerome.Haerri@eurecom.fr>>
>>> <mailto:Jerome.Haerri@eurecom.fr 
>>> <mailto:Jerome.Haerri@eurecom.fr>
>> <mailto:Jerome.Haerri@eurecom.fr
> <mailto:Jerome.Haerri@eurecom.fr>>>>, IPWAVE WG <its@ietf.org 
> <mailto:its@ietf.org>
>> <mailto:its@ietf.org <mailto:its@ietf.org>>
>>> <mailto:its@ietf.org <mailto:its@ietf.org> <mailto:its@ietf.org
> <mailto:its@ietf.org>>>>
>>> 
>>> 
>>> 
>>> 
>>> Le 15/04/2021 à 12:35, Jérôme Härri a écrit :
>>>> Dear Alex,
>>>> 
>>>> Thanks. Indeed such discrepancies is particularly an issue
>> when it
>>>> comes to merging wireless and wired (V2I). For example, you
>> send a
>>>> DENM over 5G reaching a MEC. It will remove the ETSI KPI and
>>>> do something on its own (not fully sure what exactly), or if
>> you use
>>>> MQTT type of interaction, where it is even less clear (what a 
>>>> broker will do on a DENM sent over JSON is not fully clear
>> to keep
>>>> track of any kind of security/data integrity...
>>>> 
>>>> For that matter, there was one effort from C-ROAD to develop 
>>>> something called 'Facilities' PKI, saying that the ITS KPI
>> are at
>>>> facilities layer and no longer at geonet. The advantage is
>> that at
>>>> least now, you do not need to remove the KPI when moving and 
>>>> exchanging DENM (or else) in backend. But I am not sure of the 
>>>> current status or even if this WI is actually active.
>>>> 
>>>> Now, I do not fully agree with you with the equivalence of the 
>>>> internet KPI and ITS KPI. Indeed, the principle is the same, 
>>>> but in the test you mention, the trust chain is not guaranteed
>>>>  (you edit your own root-CA for the purpose of the tests, but 
>>>> for
>> example
>>>> in one of our cross-border deployment (e.g. DE-FR), this
>> solution
>>>> does not work, as a German car will not recognize the CA from
>>>> a French root-CA. So, the key issue I see is not really (or
>> only) on
>>>> security but on Trust. The ITS KPI is one option, there might 
>>>> be others, but 'open ssl' strategies still face the
>>>> trust-chain issue.
>>> 
>>> Jérôme,
>>> 
>>> I agree with you.
>>> 
>>> In the discussion above I think you meant 'PKI' throughout
>> (Public
>>> Key Infrastructure), and not 'KPI' (Key Performance Indicator).
>>> 
>>> That said, the question you formulate about how a
>> car-to-server MQTT
>>> interaction on IP would be authenticated by certificates that
>> are
>>> verified by CAs that are absent from normal browsers, or how
>> the CAs
>>> that are present in normal browsers would help authenticating
>> CAM
>>> messages sent on IP - is a very relevant question.
>>> 
>>> Alex
>>>> 
>>>> Best Regards,
>>>> 
>>>> Jérôme
>>>> 
>>>> -----Original Message----- From: its <its-bounces@ietf.org
> <mailto:its-bounces@ietf.org>
>> <mailto:its-bounces@ietf.org <mailto:its-bounces@ietf.org>>
>>> <mailto:its-bounces@ietf.org <mailto:its-bounces@ietf.org>
> <mailto:its-bounces@ietf.org <mailto:its-bounces@ietf.org>>>>
>> On Behalf
>>>> Of Alexandre Petrescu Sent: Thursday, 15 April 2021 12:20 To: 
>>>> IPWAVE WG <its@ietf.org <mailto:its@ietf.org>
> <mailto:its@ietf.org <mailto:its@ietf.org>>
>> <mailto:its@ietf.org <mailto:its@ietf.org> <mailto:its@ietf.org
> <mailto:its@ietf.org>>>> Subject: [ipwave]
>>>> RFC8902
>>> - TLS with ITS
>>>> Certificates, EXPERIMENTAL, and the one PKI and one Internet
>>>> 
>>>> Hi, IPWAVErs,
>>>> 
>>>> A colleague pointed me to this recently issued RFC 8902
>> about TLS
>>>> with ITS Certificates.
>>>> 
>>>> This RFC is of an EXPERIMENTAL Category.
>>>> 
>>>> It might be in agreement with other IEEE standards such as
>> 1609.2.
>>>> 
>>>> But I must say that I think it further deepens the discrepancy 
>>>> between what is PKI in the Internet and what is the closed
>> PKI for
>>>> ITS.  That is a discrepancy that exists for a long time, and I 
>>>> must share that - IMHO - I am surprised that the IETF issues
>> an RFC
>>>> that further promotes such a discrepancy.
>>>> 
>>>> This discrepancy is the following: in a few trials I
>> participated,
>>>> and some about I heard of, people use normal PKI with
>> openssl and
>>>> normal certificates in cars, over IP, on cellular links like
>> 4G.
>>>> They work fine.  The CA is a local CA (not a commercial CA), 
>>>> but the concept _is_ compatible with normal CAs.  These dont 
>>>> use the ETSI ITS-specific certificates, neither the 1609.2 
>>>> certificates.
>>>> 
>>>> I think there are more such trial deployments using local (but 
>>>> standard, openssl PKIs and certificates) than there are trials 
>>>> using ETSI ITS certificates or 1609.2 certificates.  The
>> reason is
>>>> because the former is all open source software and freely 
>>>> accessible standards, whereas 1609.2 are closed documents
>> and ETSI
>>>> ITS certificate software is not integrated in mainline
>>>> software like openssl.
>>>> 
>>>> There are many easily accessible CAs (Certificate Authorities) 
>>>> that are integrated in the Internet and in main web browsers, 
>>>> whereas the ITS-specific CAs are closed, hard to access and the
>>>> certificate are expensive.  Many strong oppinions maintain
>> that it
>>>> should stay that way: cars PKI different than Internet PKI.
>>>> 
>>>> There should be one Internet, and that means one trust, and
>>>> one PKI.
>>>> 
>>>> Everything else should not be done at IETF, I think; hence my 
>>>> comment about this particular RFC.
>>>> 
>>>> That is my humble oppinion.
>>>> 
>>>> I would like to hear other oppinions?  Maybe I miss 
>>>> something...
>>>> 
>>>> Alex
>>>> 
>>>> _______________________________________________ its mailing
>> list
>>>> its@ietf.org <mailto:its@ietf.org> <mailto:its@ietf.org
> <mailto:its@ietf.org>> <mailto:its@ietf.org <mailto:its@ietf.org>
>> <mailto:its@ietf.org <mailto:its@ietf.org>>>
>>> https://www.ietf.org/mailman/listinfo/its
> <https://www.ietf.org/mailman/listinfo/its>
>> <https://www.ietf.org/mailman/listinfo/its
> <https://www.ietf.org/mailman/listinfo/its>>
>>> <https://www.ietf.org/mailman/listinfo/its
> <https://www.ietf.org/mailman/listinfo/its>
>> <https://www.ietf.org/mailman/listinfo/its
> <https://www.ietf.org/mailman/listinfo/its>>>
>>>> 
>>>> _______________________________________________ its mailing
>> list
>>>> its@ietf.org <mailto:its@ietf.org> <mailto:its@ietf.org
> <mailto:its@ietf.org>> <mailto:its@ietf.org <mailto:its@ietf.org>
>> <mailto:its@ietf.org <mailto:its@ietf.org>>>
>>> https://www.ietf.org/mailman/listinfo/its
> <https://www.ietf.org/mailman/listinfo/its>
>> <https://www.ietf.org/mailman/listinfo/its
> <https://www.ietf.org/mailman/listinfo/its>>
>>> <https://www.ietf.org/mailman/listinfo/its
> <https://www.ietf.org/mailman/listinfo/its>
>> <https://www.ietf.org/mailman/listinfo/its
> <https://www.ietf.org/mailman/listinfo/its>>>
>>>> 
>>> 
>>> _______________________________________________ its mailing list 
>>> its@ietf.org <mailto:its@ietf.org> <mailto:its@ietf.org
> <mailto:its@ietf.org>> <mailto:its@ietf.org <mailto:its@ietf.org>
>> <mailto:its@ietf.org <mailto:its@ietf.org>>>
>>> https://www.ietf.org/mailman/listinfo/its
> <https://www.ietf.org/mailman/listinfo/its>
>> <https://www.ietf.org/mailman/listinfo/its
> <https://www.ietf.org/mailman/listinfo/its>>
>>> <https://www.ietf.org/mailman/listinfo/its
> <https://www.ietf.org/mailman/listinfo/its>
>> <https://www.ietf.org/mailman/listinfo/its
> <https://www.ietf.org/mailman/listinfo/its>>>
>>> 
>>> 
>>> _______________________________________________ its mailing list 
>>> its@ietf.org <mailto:its@ietf.org> <mailto:its@ietf.org
> <mailto:its@ietf.org>>
>> https://www.ietf.org/mailman/listinfo/its
> <https://www.ietf.org/mailman/listinfo/its>
>> <https://www.ietf.org/mailman/listinfo/its
> <https://www.ietf.org/mailman/listinfo/its>>
>>> 
>> 
>> _______________________________________________ its mailing list 
>> its@ietf.org <mailto:its@ietf.org> <mailto:its@ietf.org
> <mailto:its@ietf.org>>
>> https://www.ietf.org/mailman/listinfo/its
> <https://www.ietf.org/mailman/listinfo/its>
>> <https://www.ietf.org/mailman/listinfo/its
> <https://www.ietf.org/mailman/listinfo/its>>
>> 
> 