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

Alexandre Petrescu <> Mon, 26 April 2021 15:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9C0D33A22FD for <>; Mon, 26 Apr 2021 08:03:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.632
X-Spam-Status: No, score=-1.632 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, RCVD_IN_DNSWL_MED=-2.3, 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 EWeuypkL8790 for <>; Mon, 26 Apr 2021 08:03:13 -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 02F1F3A22FC for <>; Mon, 26 Apr 2021 08:03:12 -0700 (PDT)
Received: from ( []) by (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 13QF39rQ030257; Mon, 26 Apr 2021 17:03:09 +0200
Received: from (localhost []) by localhost (Postfix) with SMTP id 658792031B9; Mon, 26 Apr 2021 17:03:09 +0200 (CEST)
Received: from ( []) by (Postfix) with ESMTP id 5580D201860; Mon, 26 Apr 2021 17:03:09 +0200 (CEST)
Received: from [] ([]) by (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 13QF38SL028537; Mon, 26 Apr 2021 17:03:08 +0200
To: Russ Housley <>, =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= <>
References: <> <01d601d731e3$140e2ed0$3c2a8c70$> <>
From: Alexandre Petrescu <>
Message-ID: <>
Date: Mon, 26 Apr 2021 17:03:07 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0
MIME-Version: 1.0
In-Reply-To: <>
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: Mon, 26 Apr 2021 15:03:18 -0000

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.


> Russ
>> On Apr 15, 2021, at 6:35 AM, Jérôme Härri
>> <> 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 <> 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