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

Alexandre Petrescu <> Thu, 15 April 2021 20:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E1F073A300D for <>; Thu, 15 Apr 2021 13:42:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.668
X-Spam-Status: No, score=0.668 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id o6dmP7IbgXQB for <>; Thu, 15 Apr 2021 13:42:02 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0D81A3A2F06 for <>; Thu, 15 Apr 2021 13:41:47 -0700 (PDT)
Received: from ( []) by (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 13FKfifl005185; Thu, 15 Apr 2021 22:41:44 +0200
Received: from (localhost []) by localhost (Postfix) with SMTP id D57EE207F74; Thu, 15 Apr 2021 22:41:44 +0200 (CEST)
Received: from ( []) by (Postfix) with ESMTP id C724A207F39; Thu, 15 Apr 2021 22:41:44 +0200 (CEST)
Received: from [] ([]) by (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 13FKfiP3008009; Thu, 15 Apr 2021 22:41:44 +0200
To: =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= <>, "'IPWAVE WG'" <>
References: <> <01d601d731e3$140e2ed0$3c2a8c70$>
From: Alexandre Petrescu <>
Message-ID: <>
Date: Thu, 15 Apr 2021 22:41:44 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.1
MIME-Version: 1.0
In-Reply-To: <01d601d731e3$140e2ed0$3c2a8c70$>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [ipwave] RFC8902 - TLS with ITS Certificates, EXPERIMENTAL, and the one PKI and one Internet
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 15 Apr 2021 20:42:10 -0000

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.


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.

> Best Regards,
> Jérôme
> -----Original Message----- From: its <> On Behalf
> Of Alexandre Petrescu Sent: Thursday, 15 April 2021 12:20 To: IPWAVE
> WG <> 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 mailing list