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

[Alexandre Petrescu <[e-mail]>]

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

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

Alex

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