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

[Russ Housley <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 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 <[e-mail]> 
> Sent: Thursday, 15 April 2021 13:46
> To: Jérôme Härri <[e-mail]>; Alexandre Petrescu <[e-mail]>
> Cc: IPWAVE WG <[e-mail]>
> Subject: Re: [ipwave] RFC8902 - TLS with ITS Certificates, EXPERIMENTAL, and the one PKI and one Internet
> 
> 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 <[e-mail]> wrote:
>> 
>> 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 <[e-mail]> On Behalf Of Alexandre Petrescu
>> Sent: Thursday, 15 April 2021 12:20
>> To: IPWAVE WG <[e-mail]>
>> Subject: [ipwave] RFC8902 - TLS with ITS Certificates, EXPERIMENTAL, 
>> and the one PKI and one Internet
>> 
>> Hi, IPWAVErs,
>> 
>> A colleague pointed me to this recently issued RFC 8902 about TLS with 
>> ITS Certificates.
>> 
>> This RFC is of an EXPERIMENTAL Category.
>> 
>> It might be in agreement with other IEEE standards such as 1609.2.
>> 
>> But I must say that I think it further deepens the discrepancy between 
>> what is PKI in the Internet and what is the closed PKI for ITS.  That 
>> is a discrepancy that exists for a long time, and I must share that - 
>> IMHO
>> - I am surprised that the IETF issues an RFC that further promotes 
>> such a discrepancy.
>> 
>> This discrepancy is the following: in a few trials I participated, and 
>> some about I heard of, people use normal PKI with openssl and normal 
>> certificates in cars, over IP, on cellular links like 4G.  They work 
>> fine.  The CA is a local CA (not a commercial CA), but the concept 
>> _is_ compatible with normal CAs.  These dont use the ETSI ITS-specific 
>> certificates, neither the 1609.2 certificates.
>> 
>> I think there are more such trial deployments using local (but 
>> standard, openssl PKIs and certificates) than there are trials using 
>> ETSI ITS certificates or 1609.2 certificates.  The reason is because 
>> the former is all open source software and freely accessible 
>> standards, whereas
>> 1609.2 are closed documents and ETSI ITS certificate software is not 
>> integrated in mainline software like openssl.
>> 
>> There are many easily accessible CAs (Certificate Authorities) that 
>> are integrated in the Internet and in main web browsers, whereas the 
>> ITS-specific CAs are closed, hard to access and the certificate are 
>> expensive.  Many strong oppinions maintain that it should stay that way:
>> cars PKI different than Internet PKI.
>> 
>> There should be one Internet, and that means one trust, and one PKI.
>> 
>> Everything else should not be done at IETF, I think; hence my comment 
>> about this particular RFC.
>> 
>> That is my humble oppinion.
>> 
>> I would like to hear other oppinions?  Maybe I miss something...
>> 
>> Alex
>> 
>> _______________________________________________
>> its mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/its
>> 
>> _______________________________________________
>> its mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/its
> 
> 
> _______________________________________________
> its mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/its