From nobody Thu Apr 15 03:20:22 2021 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06FFE3A19C7 for ; Thu, 15 Apr 2021 03:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.649 X-Spam-Level: X-Spam-Status: No, score=0.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJwA0sAnXQmh for ; Thu, 15 Apr 2021 03:20:19 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 781F13A19C3 for ; Thu, 15 Apr 2021 03:20:19 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 13FAKGQJ008867 for ; Thu, 15 Apr 2021 12:20:16 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id C9BD3205C1C for ; Thu, 15 Apr 2021 12:20:16 +0200 (CEST) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id C0EA1205BD3 for ; Thu, 15 Apr 2021 12:20:16 +0200 (CEST) Received: from [10.14.0.23] ([10.14.0.23]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 13FAKGxo017982 for ; Thu, 15 Apr 2021 12:20:16 +0200 To: IPWAVE WG From: Alexandre Petrescu Message-ID: Date: Thu, 15 Apr 2021 12:20:16 +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 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 7bit Archived-At: Subject: [ipwave] RFC8902 - TLS with ITS Certificates, EXPERIMENTAL, and the one PKI and one Internet X-BeenThere: its@ietf.org 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 10:20:21 -0000 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 From nobody Thu Apr 15 03:35:48 2021 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B131C3A1A5D for ; Thu, 15 Apr 2021 03:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a0JYv8jbK8_J for ; Thu, 15 Apr 2021 03:35:42 -0700 (PDT) Received: from smtp.eurecom.fr (smtp.eurecom.fr [193.55.113.210]) by ietfa.amsl.com (Postfix) with ESMTP id 297323A1A5A for ; Thu, 15 Apr 2021 03:35:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.82,223,1613430000"; d="scan'208";a="2908337" Received: from monza.eurecom.fr ([192.168.106.15]) by drago1i.eurecom.fr with ESMTP; 15 Apr 2021 12:35:39 +0200 Received: from portege33 (unknown [192.168.200.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by monza.eurecom.fr (Postfix) with ESMTPSA id 681581C7 for ; Thu, 15 Apr 2021 12:35:39 +0200 (CEST) From: =?iso-8859-1?B?Suly9G1lIEjkcnJp?= To: "'IPWAVE WG'" References: In-Reply-To: Date: Thu, 15 Apr 2021 12:35:38 +0200 Organization: EURECOM Message-ID: <01d601d731e3$140e2ed0$3c2a8c70$@eurecom.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGNE4eOrl1DVgZsmuuV5v0KN1fNOKtJm4nQ Content-Language: en Archived-At: Subject: Re: [ipwave] RFC8902 - TLS with ITS Certificates, EXPERIMENTAL, and the one PKI and one Internet X-BeenThere: its@ietf.org 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 10:35:47 -0000 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.=20 Best Regards, J=E9r=F4me -----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@ietf.org https://www.ietf.org/mailman/listinfo/its From nobody Thu Apr 15 04:46:29 2021 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CCDC3A1CB2 for ; Thu, 15 Apr 2021 04:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gncF2qeFdo3U for ; Thu, 15 Apr 2021 04:46:23 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB31C3A1CB0 for ; Thu, 15 Apr 2021 04:46:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 19C64300BD6 for ; Thu, 15 Apr 2021 07:46:20 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id lLCwpTqTeYyO for ; Thu, 15 Apr 2021 07:46:17 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 99003300AA6; Thu, 15 Apr 2021 07:46:17 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) From: Russ Housley In-Reply-To: <01d601d731e3$140e2ed0$3c2a8c70$@eurecom.fr> Date: Thu, 15 Apr 2021 07:46:18 -0400 Cc: IPWAVE WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <01d601d731e3$140e2ed0$3c2a8c70$@eurecom.fr> To: =?utf-8?B?SsOpcsO0bWUgSMOkcnJp?= , Alexandre Petrescu X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: Re: [ipwave] RFC8902 - TLS with ITS Certificates, EXPERIMENTAL, and the one PKI and one Internet X-BeenThere: its@ietf.org 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 11:46:28 -0000 Alex and J=C3=A9r=C3=B4me: 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=C3=A9r=C3=B4me H=C3=A4rri = wrote: >=20 > Dear Alex, >=20 > 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... >=20 > 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.=20 >=20 > 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.=20 >=20 > Best Regards, >=20 > J=C3=A9r=C3=B4me >=20 > -----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 >=20 > Hi, IPWAVErs, >=20 > A colleague pointed me to this recently issued RFC 8902 about TLS with = ITS > Certificates. >=20 > This RFC is of an EXPERIMENTAL Category. >=20 > It might be in agreement with other IEEE standards such as 1609.2. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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:=20 > cars PKI different than Internet PKI. >=20 > There should be one Internet, and that means one trust, and one PKI. >=20 > Everything else should not be done at IETF, I think; hence my comment = about > this particular RFC. >=20 > That is my humble oppinion. >=20 > I would like to hear other oppinions? Maybe I miss something... >=20 > Alex >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From nobody Thu Apr 15 04:51:52 2021 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF8B33A1C8E for ; Thu, 15 Apr 2021 04:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tKGytYc4_n-g for ; Thu, 15 Apr 2021 04:51:46 -0700 (PDT) Received: from smtp.eurecom.fr (smtp.eurecom.fr [193.55.113.210]) by ietfa.amsl.com (Postfix) with ESMTP id 248D13A090B for ; Thu, 15 Apr 2021 04:51:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.82,223,1613430000"; d="scan'208";a="2909236" Received: from monza.eurecom.fr ([192.168.106.15]) by drago1i.eurecom.fr with ESMTP; 15 Apr 2021 13:51:43 +0200 Received: from portege33 (unknown [192.168.200.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by monza.eurecom.fr (Postfix) with ESMTPSA id 3672864B; Thu, 15 Apr 2021 13:51:44 +0200 (CEST) From: =?utf-8?B?SsOpcsO0bWUgSMOkcnJp?= To: "'Russ Housley'" , "'Alexandre Petrescu'" Cc: "'IPWAVE WG'" References: <01d601d731e3$140e2ed0$3c2a8c70$@eurecom.fr> In-Reply-To: Date: Thu, 15 Apr 2021 13:51:43 +0200 Organization: EURECOM Message-ID: <02b401d731ed$b4ec3c70$1ec4b550$@eurecom.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGNE4eOrl1DVgZsmuuV5v0KN1fNOAJW1Y3IAXY5mWurK0q5UA== Content-Language: en Archived-At: Subject: Re: [ipwave] RFC8902 - TLS with ITS Certificates, EXPERIMENTAL, and the one PKI and one Internet X-BeenThere: its@ietf.org 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 11:51:51 -0000 Dear Russ, I see. Actually, my reply was not related to IETF activities but more on = general terms.=20 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=C3=A9r=C3=B4me -----Original Message----- From: Russ Housley =20 Sent: Thursday, 15 April 2021 13:46 To: J=C3=A9r=C3=B4me H=C3=A4rri ; Alexandre = Petrescu Cc: IPWAVE WG Subject: Re: [ipwave] RFC8902 - TLS with ITS Certificates, EXPERIMENTAL, = and the one PKI and one Internet Alex and J=C3=A9r=C3=B4me: 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=C3=A9r=C3=B4me H=C3=A4rri = wrote: >=20 > Dear Alex, >=20 > Thanks. Indeed such discrepancies is particularly an issue when it=20 > comes to merging wireless and wired (V2I). For example, you send a=20 > DENM over 5G reaching a MEC. It will remove the ETSI KPI and do=20 > 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=20 > do on a DENM sent over JSON is not fully clear to keep track of any = kind of security/data integrity... >=20 > For that matter, there was one effort from C-ROAD to develop something = > called 'Facilities' PKI, saying that the ITS KPI are at facilities=20 > 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=20 > else) in backend. But I am not sure of the current status or even if = this WI is actually active. >=20 > Now, I do not fully agree with you with the equivalence of the=20 > internet KPI and ITS KPI. Indeed, the principle is the same, but in=20 > 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=20 > 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,=20 > there might be others, but 'open ssl' strategies still face the = trust-chain issue. >=20 > Best Regards, >=20 > J=C3=A9r=C3=B4me >=20 > -----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,=20 > and the one PKI and one Internet >=20 > Hi, IPWAVErs, >=20 > A colleague pointed me to this recently issued RFC 8902 about TLS with = > ITS Certificates. >=20 > This RFC is of an EXPERIMENTAL Category. >=20 > It might be in agreement with other IEEE standards such as 1609.2. >=20 > 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=20 > is a discrepancy that exists for a long time, and I must share that -=20 > IMHO > - I am surprised that the IETF issues an RFC that further promotes=20 > such a discrepancy. >=20 > 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=20 > certificates in cars, over IP, on cellular links like 4G. They work=20 > fine. The CA is a local CA (not a commercial CA), but the concept=20 > _is_ compatible with normal CAs. These dont use the ETSI ITS-specific = > certificates, neither the 1609.2 certificates. >=20 > I think there are more such trial deployments using local (but=20 > standard, openssl PKIs and certificates) than there are trials using=20 > ETSI ITS certificates or 1609.2 certificates. The reason is because=20 > the former is all open source software and freely accessible=20 > standards, whereas > 1609.2 are closed documents and ETSI ITS certificate software is not=20 > integrated in mainline software like openssl. >=20 > There are many easily accessible CAs (Certificate Authorities) that=20 > are integrated in the Internet and in main web browsers, whereas the=20 > ITS-specific CAs are closed, hard to access and the certificate are=20 > expensive. Many strong oppinions maintain that it should stay that = way: > cars PKI different than Internet PKI. >=20 > There should be one Internet, and that means one trust, and one PKI. >=20 > Everything else should not be done at IETF, I think; hence my comment=20 > about this particular RFC. >=20 > That is my humble oppinion. >=20 > I would like to hear other oppinions? Maybe I miss something... >=20 > Alex >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From nobody Thu Apr 15 07:02:52 2021 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC1A43A210F for ; Thu, 15 Apr 2021 07:02:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14WOiuzlowxc for ; Thu, 15 Apr 2021 07:02:44 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C6F03A041D for ; Thu, 15 Apr 2021 07:02:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 0E2C5300B7E for ; Thu, 15 Apr 2021 10:02:41 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Lq452Jeas475 for ; Thu, 15 Apr 2021 10:02:38 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 4EE61300B35; Thu, 15 Apr 2021 10:02:38 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) From: Russ Housley In-Reply-To: <02b401d731ed$b4ec3c70$1ec4b550$@eurecom.fr> Date: Thu, 15 Apr 2021 10:02:39 -0400 Cc: IPWAVE WG Content-Transfer-Encoding: quoted-printable Message-Id: <13C8EED2-C9D4-4DEB-86E7-9057612243E5@vigilsec.com> References: <01d601d731e3$140e2ed0$3c2a8c70$@eurecom.fr> <02b401d731ed$b4ec3c70$1ec4b550$@eurecom.fr> To: =?utf-8?B?SsOpcsO0bWUgSMOkcnJp?= X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: Re: [ipwave] RFC8902 - TLS with ITS Certificates, EXPERIMENTAL, and the one PKI and one Internet X-BeenThere: its@ietf.org 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 14:02:49 -0000 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=C3=A9r=C3=B4me H=C3=A4rri = wrote: >=20 > Dear Russ, >=20 > I see. Actually, my reply was not related to IETF activities but more = on general terms.=20 >=20 > 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. >=20 > Thanks, >=20 > BR, >=20 > J=C3=A9r=C3=B4me >=20 > -----Original Message----- > From: Russ Housley =20 > Sent: Thursday, 15 April 2021 13:46 > To: J=C3=A9r=C3=B4me H=C3=A4rri ; Alexandre = Petrescu > Cc: IPWAVE WG > Subject: Re: [ipwave] RFC8902 - TLS with ITS Certificates, = EXPERIMENTAL, and the one PKI and one Internet >=20 > Alex and J=C3=A9r=C3=B4me: >=20 > First, the IETF did not publish RFC 8902. That went through the = independent stream. >=20 > 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: >=20 > 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. >=20 > 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. >=20 > Russ >=20 >=20 >> On Apr 15, 2021, at 6:35 AM, J=C3=A9r=C3=B4me H=C3=A4rri = wrote: >>=20 >> Dear Alex, >>=20 >> Thanks. Indeed such discrepancies is particularly an issue when it=20 >> comes to merging wireless and wired (V2I). For example, you send a=20 >> DENM over 5G reaching a MEC. It will remove the ETSI KPI and do=20 >> something on its own (not fully sure what exactly), or if you use = MQTT=20 >> type of interaction, where it is even less clear (what a broker will=20= >> do on a DENM sent over JSON is not fully clear to keep track of any = kind of security/data integrity... >>=20 >> For that matter, there was one effort from C-ROAD to develop = something=20 >> called 'Facilities' PKI, saying that the ITS KPI are at facilities=20 >> layer and no longer at geonet. The advantage is that at least now, = you=20 >> do not need to remove the KPI when moving and exchanging DENM (or=20 >> else) in backend. But I am not sure of the current status or even if = this WI is actually active. >>=20 >> Now, I do not fully agree with you with the equivalence of the=20 >> internet KPI and ITS KPI. Indeed, the principle is the same, but in=20= >> the test you mention, the trust chain is not guaranteed (you edit = your=20 >> 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=20 >> recognize the CA from a French root-CA. So, the key issue I see is = not=20 >> really (or only) on security but on Trust. The ITS KPI is one option,=20= >> there might be others, but 'open ssl' strategies still face the = trust-chain issue. >>=20 >> Best Regards, >>=20 >> J=C3=A9r=C3=B4me >>=20 >> -----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,=20= >> and the one PKI and one Internet >>=20 >> Hi, IPWAVErs, >>=20 >> A colleague pointed me to this recently issued RFC 8902 about TLS = with=20 >> ITS Certificates. >>=20 >> This RFC is of an EXPERIMENTAL Category. >>=20 >> It might be in agreement with other IEEE standards such as 1609.2. >>=20 >> But I must say that I think it further deepens the discrepancy = between=20 >> what is PKI in the Internet and what is the closed PKI for ITS. That=20= >> is a discrepancy that exists for a long time, and I must share that -=20= >> IMHO >> - I am surprised that the IETF issues an RFC that further promotes=20 >> such a discrepancy. >>=20 >> This discrepancy is the following: in a few trials I participated, = and=20 >> some about I heard of, people use normal PKI with openssl and normal=20= >> certificates in cars, over IP, on cellular links like 4G. They work=20= >> fine. The CA is a local CA (not a commercial CA), but the concept=20 >> _is_ compatible with normal CAs. These dont use the ETSI = ITS-specific=20 >> certificates, neither the 1609.2 certificates. >>=20 >> I think there are more such trial deployments using local (but=20 >> standard, openssl PKIs and certificates) than there are trials using=20= >> ETSI ITS certificates or 1609.2 certificates. The reason is because=20= >> the former is all open source software and freely accessible=20 >> standards, whereas >> 1609.2 are closed documents and ETSI ITS certificate software is not=20= >> integrated in mainline software like openssl. >>=20 >> There are many easily accessible CAs (Certificate Authorities) that=20= >> are integrated in the Internet and in main web browsers, whereas the=20= >> ITS-specific CAs are closed, hard to access and the certificate are=20= >> expensive. Many strong oppinions maintain that it should stay that = way: >> cars PKI different than Internet PKI. >>=20 >> There should be one Internet, and that means one trust, and one PKI. >>=20 >> Everything else should not be done at IETF, I think; hence my comment=20= >> about this particular RFC. >>=20 >> That is my humble oppinion. >>=20 >> I would like to hear other oppinions? Maybe I miss something... >>=20 >> Alex >>=20 >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its >>=20 >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its >=20 >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From nobody Thu Apr 15 13:42:11 2021 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1F073A300D for ; Thu, 15 Apr 2021 13:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.668 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o6dmP7IbgXQB for ; Thu, 15 Apr 2021 13:42:02 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D81A3A2F06 for ; Thu, 15 Apr 2021 13:41:47 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (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 pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id D57EE207F74; Thu, 15 Apr 2021 22:41:44 +0200 (CEST) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id C724A207F39; Thu, 15 Apr 2021 22:41:44 +0200 (CEST) Received: from [10.14.1.28] ([10.14.1.28]) by muguet2-sys.intra.cea.fr (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$@eurecom.fr> From: Alexandre Petrescu Message-ID: <0600020f-b6ca-4d6d-2499-817586bc3548@gmail.com> 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$@eurecom.fr> 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-BeenThere: its@ietf.org 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. 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 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@ietf.org https://www.ietf.org/mailman/listinfo/its > > _______________________________________________ its mailing list > its@ietf.org https://www.ietf.org/mailman/listinfo/its > From nobody Fri Apr 16 05:14:12 2021 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAA533A235A for ; Fri, 16 Apr 2021 05:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vVxmh1ZnY27f for ; Fri, 16 Apr 2021 05:14:05 -0700 (PDT) Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA2373A2366 for ; Fri, 16 Apr 2021 05:14:04 -0700 (PDT) Received: by mail-qk1-x734.google.com with SMTP id d15so15543287qkc.9 for ; Fri, 16 Apr 2021 05:14:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=zl6Z3S6m7dqh9cLMy4ox5wTKYxplXDENtZ3M8MsT/Fw=; b=gehecXPIlnGZgfmlrsJ6WL4QxC1DRvRGLIYWXmQvlQUL4bFDahelZAm0Ect4qjfWP1 6ObMToZNYeogXkYxlxIeMCPWBYj+Brt81RPucao0bgAm88WFc+D0nRvWAdlGEVaHcv3c crndfuLUjCBW/Y7ppQDnQWIl/FyTCBJcrkzlOkuXR2oTYEIPxYeuNgKLTjIkMr7bmA0K fbTH4uMJkkbAXj6isZ14AITHQORr9ApXvKQxN5tFQCvI1kN1teQFYAkQvMmiriASrPIa rFHCq+3jFkqpXz9aJDO/B/0736f60rn2Mi26m0NPcFIBaoDq0kfSJh2hfQm9x6LShNZO yWIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=zl6Z3S6m7dqh9cLMy4ox5wTKYxplXDENtZ3M8MsT/Fw=; b=Ckgq9YucT4d0AqdpPDFfdm+/O1B3nSzZ7hdohdE8pio1dQPXjiD7hcvzal7TG7g4+u 7rW35b1HlS/61S0TuXKaib2xRZMr7XZpcI/40M9TG1dKZon3IqXSVhiIkqM6GtRFsezn h3H6walPbaFd7pfpTMzmeIaLncpDkl12zvXOTLcQ1kTMo0cEtfFnBO1vo04FalaQJdL6 e6oNxL46GYOT+ChUhGATPeY8b/rkShKUA0Svx4ZmTWRjt1YpgNR9om7QJ/pktHKL57y2 3znTsuNCUaM+tvYLu5i1xK/iEcDyD+wIkLbsGs4OX693NAFeapSIxMfzcQ8dHqfU9s0q i3PA== X-Gm-Message-State: AOAM530892I5sOIusOKYyvtYZ6Tt/qWL60bzeR+IcMLffr1JbR6cSiPX EhsTvX/XTfnf5rFXUwzNG8R5dE0iKs//mA1oFf2PraGBRW4= X-Google-Smtp-Source: ABdhPJx06G0pGGtgmklT50ude4F/TyDvVueNMb2EKST8mR/Md7YTf0Q8cSVRQFbeVKlqGQCQka9+3MLfw3GoFyjFsFE= X-Received: by 2002:a05:620a:24a:: with SMTP id q10mr8545886qkn.366.1618575242963; Fri, 16 Apr 2021 05:14:02 -0700 (PDT) MIME-Version: 1.0 References: <01d601d731e3$140e2ed0$3c2a8c70$@eurecom.fr> <0600020f-b6ca-4d6d-2499-817586bc3548@gmail.com> In-Reply-To: From: Mounira MSAHLI Date: Fri, 16 Apr 2021 14:13:52 +0200 Message-ID: To: its@ietf.org Content-Type: multipart/alternative; boundary="000000000000662f5f05c015ea66" Archived-At: Subject: Re: [ipwave] RFC8902 - TLS with ITS Certificates, EXPERIMENTAL, and the one PKI and one Internet X-BeenThere: its@ietf.org 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: Fri, 16 Apr 2021 12:14:11 -0000 --000000000000662f5f05c015ea66 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear all, Dear Russ, Dear Jerome, Dear Alex, I=E2=80=99m sorry for the delay. I would like to provide some clarification= s concerning: >> 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/ : which is about deploying 3000 cars + 2000 km of roads - InterCor https://intercor-project.eu/, - C-Roads Platform 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/indi= d.html . All these projects are using ETSI TS 103 097 certificates, which is a profile of 1609.2 to secure C-ITS messages: https://ec.europa.eu/transport/sites/transport/files/c-its_certificate_poli= cy_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, 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. We could also use the RFC for Vehicle-To-Internet simply to upload log of vehicle for example etc=E2=80=A6 >> 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. I already used it. >> 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/ >> 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=E2=80=99m also interested to work on security interoperability in C-ITS a= nd 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 > Date: jeu. 15 avr. 2021 =C3=A0 22:44 > Subject: Re: [ipwave] RFC8902 - TLS with ITS Certificates, EXPERIMENTAL, > and the one PKI and one Internet > To: J=C3=A9r=C3=B4me H=C3=A4rri , IPWAVE WG > > > > > Le 15/04/2021 =C3=A0 12:35, J=C3=A9r=C3=B4me H=C3=A4rri a =C3=A9crit : > > 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=C3=A9r=C3=B4me, > > 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=C3=A9r=C3=B4me > > > > -----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@ietf.org https://www.ietf.org/mailman/listinfo/its > > > > _______________________________________________ its mailing list > > its@ietf.org https://www.ietf.org/mailman/listinfo/its > > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > --000000000000662f5f05c015ea66 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Dear all, Dear Russ, Dear Jerome, Dear Ale= x,=C2=A0

=

=

I=E2=80=99m sorry = for the delay. I=C2=A0would=C2=A0like=C2=A0to=C2=A0provide some= =C2=A0clarifications concerning:=C2=A0



>> This discrepancy is the following: in a few trials I par= ticipated, and=C2=A0

some about I heard of, people use normal PKI with openssl and nor= mal=C2=A0

certificates in cars, over IP, on cellular links like 4G.=C2=A0 T= hey work=C2=A0

fine.


But, I want to highlight that the European commission are=C2=A0 f= unding several Cooperative ITS (C-ITS) deployment projects such as: =C2=A0<= /span>


- Scoop@F http://www.scoop.developpement-durable.gou= v.fr/ :=C2=A0


which is about deploying 3000 cars + 2000 km of roads=C2=A0


- InterCor https://inter= cor-project.eu/,=C2=A0

- C-Roads Platform https://www.c-roads.eu/platform.html<= /a>


InterCor and C-Roads are about harmonising C-ITS specifications i= n Europe=C2=A0


- INDID https://www.c-roads.eu/pilots/core-mem= bers/france/Partner/project/show/indid.html.=C2=A0


All these projects are using ETSI TS 103 097 certificates, which = is a profile of 1609.2 to secure C-ITS messages:=C2=A0

https://ec.europa.eu/transport/sites/transpo= rt/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, in projects dealing with C-ITS security interoperability, we = use MQTT to exchange C-ITS messages between many countries to=C2=A0ensure continuity of=C2=A0service when vehicle is crossing borders.= =C2=A0


We could also use the RFC for Vehicle-To-Internet simply to uploa= d log of vehicle for example etc=E2=80=A6=C2=A0



>> The reason is because the former is all open source soft= ware and freely accessible standards, whereas=C2=A0 1609.2 are closed docum= ents and ETSI ITS certificate software is not integrated in mainline softwa= re like openssl.


There's a java implementation of 1609.2/103 097 here:=C2=A0https://github.com/pvendil= /c2c-common.=C2=A0I already used it.=C2=A0


>> ITS-specific CAs are closed, hard to access and the cert= ificate are=C2=A0

expensive.=C2=A0 hard to access and the certificate are expensive= .=C2=A0=C2=A0


you can get certificates from=C2=A0https://www.ghsiss.com= /v2x-certificates/



>> In=C2=A0 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 res= ources to actively contribute to this), as several options are on the table= and we need to guarantee the trust chain, even considering different proto= col or standards being used.


I=E2=80=99m also interested to work on security interoperability = in C-ITS and we could add:=C2=A0


- Misbehaving in vehicular network=C2=A0

- Revocation management=C2=A0

- Pseudonym management/change to avoid tracking and to ensu= re privacy=C2=A0


Thank you Russ for your time on this RFC and for your valuable re= view.=C2=A0



Kind regards=C2=A0

Mounira=C2=A0








---------- Forwarded message ---------
De= =C2=A0: Alexandre Petrescu<= /strong> <alexandre.petrescu@gmail.com>
Date:= jeu. 15 avr. 2021 =C3=A0=C2=A022:44
Subject: Re: [ipwave] RFC8902 - TLS= with ITS Certificates, EXPERIMENTAL, and the one PKI and one Internet
T= o: J=C3=A9r=C3=B4me H=C3=A4rri <Jerome.Haerri@eurecom.fr>, IPWAVE WG <its@ietf.org>
=



Le 15/04/2021 =C3=A0 12:35, J=C3=A9r=C3=B4me H=C3=A4rri a =C3=A9crit :
> 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<= br> > 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=C3=A9r=C3=B4me,

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=C3=A9r=C3=B4me
>
> -----Original Message----- From: its <its-bounces@ietf.org> On Behalf
> Of Alexandre Petrescu Sent: Thursday, 15 April 2021 12:20 To: IPWAVE > WG <its@ietf.org<= /a>> 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.=C2=A0 That is a discrepancy that exists for a long time, and I mu= st
> 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.=C2=A0 The CA is a local CA (not a commercial CA), but = the
> concept _is_ compatible with normal CAs.=C2=A0 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.=C2=A0 The reason is beca= use
> 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 <= br> > ITS-specific CAs are closed, hard to access and the certificate are > expensive.=C2=A0 Many strong oppinions maintain that it should stay th= at
> 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<= br> > about this particular RFC.
>
> That is my humble oppinion.
>
> I would like to hear other oppinions?=C2=A0 Maybe I miss something...<= br> >
> Alex
>
> _______________________________________________ its mailing list
> its@ietf.org https://www.ietf.org/mailman/listinfo/its
>
> _______________________________________________ its mailing list
> its@ietf.org https://www.ietf.org/mailman/listinfo/its
>

_______________________________________________
its mailing list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its
--000000000000662f5f05c015ea66-- From nobody Mon Apr 19 14:25:22 2021 Return-Path: X-Original-To: its@ietf.org Delivered-To: its@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EE2F03A44D6; Mon, 19 Apr 2021 14:25:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Liaison Statement Management Tool To: "Carlos Bernardos" , "Russ Housley" Cc: =?utf-8?q?=C3=89ric_Vyncke?= , Carlos Bernardos , Erik Kline , IP Wireless Access in Vehicular Environments Discussion List , Leon Wong , Russ Housley X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161886751987.24140.2499163095987313731@ietfa.amsl.com> Date: Mon, 19 Apr 2021 14:25:19 -0700 Archived-At: Subject: [ipwave] New Liaison Statement, "LS on the latest results on the Vehicular Multimedia deliverables from ITU FG-VM" X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 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, 19 Apr 2021 21:25:20 -0000 Title: LS on the latest results on the Vehicular Multimedia deliverables from ITU FG-VM Submission Date: 2021-04-19 URL of the IETF Web page: https://datatracker.ietf.org/liaison/1733/ From: shaba To: Carlos Bernardos ,Russ Housley Cc: Erik Kline ,Carlos Bernardos ,IP Wireless Access in Vehicular Environments Discussion List ,Russ Housley ,Éric Vyncke Response Contacts: Leon Wong Technical Contacts: Purpose: For information Body: We are pleased to inform you about the current status and results of the ITU Focus Group on Vehicular Multimedia (FG-VM), established by the ITU-T Study Group 16 in 2018. The FG-VM had already finalized the first technical report on “Use Cases and Requirements for Vehicular Multimedia” [Flipbook]. This technical report was further improved by the parent ITU T Study Group 16, who has approved a new ITU-T Recommendation "Use cases and requirements for the vehicular multimedia networks" Rec.ITU-T F.749.3. In addition, at the recent April 2021 meeting, the FG-VM has finalized its second Technical Report on “Architecture of Vehicle Multimedia Systems” [FGVM-O-058]. This second deliverable was also submitted for consideration of the parent ITU T Study Group 16, which plans to review and endorse it as ITU-T Recommendation similarly to the first deliverable. The new FG-VM deliverable is attached to this liaison. The FG-VM started working on a third deliverable which will cover Vehicular Multimedia Implementation aspects, under the WG3 leadership. We will keep you informed and would welcome joint participation and collaboration with your group as well as participation from individual experts. Next FG-VM plenary meeting will take place on 29-30 June 2021. A couple of interim meetings of WG3 are planned. See more information on: – FG-VM home page: https://www.itu.int/en/ITU-T/focusgroups/vm Please kindly note that all FG-VM documents are accessible, through a free ITU Account, in our SharePoint site (https://extranet.itu.int/sites/itu-t/focusgroups/vm/SitePages/Home.aspx) (a free ITU Account is needed in order to access FG-VM documents. Create an account here if you do not have one. Please select “I AM A NEW USER” and then, if applicable, select “NON ITU MEMBERS”/ Media and Other Organizations). A mailing list is also available for self-subscription, please check the FG-VM home page and/or contact tsbfgvm@itu.int for further information you may need. Attachment: 1 – FGVM-O-058 - Technical Report on “Architecture of Vehicle Multimedia Systems” (Approved on 13 April 2021) Attachments: sp16-fg-vm-oLS-00051 https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2021-04-19-itu-t-fg-vm-ipwave-ls-on-the-latest-results-on-the-vehicular-multimedia-deliverables-from-itu-fg-vm-attachment-1.docx From nobody Tue Apr 20 02:51:29 2021 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 039F03A1AD0 for ; Tue, 20 Apr 2021 02:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.668 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UcckB01tu2sY for ; Tue, 20 Apr 2021 02:51:24 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 118C13A1AD3 for ; Tue, 20 Apr 2021 02:51:23 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 13K9pJJV004110 for ; Tue, 20 Apr 2021 11:51:19 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 5A0EF203AF1 for ; Tue, 20 Apr 2021 11:51:19 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 50490200B3A for ; Tue, 20 Apr 2021 11:51:19 +0200 (CEST) Received: from [10.14.6.91] ([10.14.6.91]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 13K9pIxh010534 for ; Tue, 20 Apr 2021 11:51:18 +0200 To: its@ietf.org References: <01d601d731e3$140e2ed0$3c2a8c70$@eurecom.fr> <0600020f-b6ca-4d6d-2499-817586bc3548@gmail.com> From: Alexandre Petrescu Message-ID: <19dce5f5-8dca-55c2-4d46-bb83046562ab@gmail.com> Date: Tue, 20 Apr 2021 11:51:17 +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: 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-BeenThere: its@ietf.org 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: Tue, 20 Apr 2021 09:51:29 -0000 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/ > : > > > which is about deploying 3000 cars + 2000 km of roads > > > - InterCor https://intercor-project.eu/ > , > > - C-Roads Platform 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 > > . > > > > > 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 > > > > > > 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 > . 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/ > 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* > > > 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 >, IPWAVE WG > > > > > > 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 > 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@ietf.org > https://www.ietf.org/mailman/listinfo/its > >> >> _______________________________________________ its mailing list >> its@ietf.org > https://www.ietf.org/mailman/listinfo/its > >> > > _______________________________________________ its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > > > _______________________________________________ its mailing list > its@ietf.org https://www.ietf.org/mailman/listinfo/its > From nobody Wed Apr 21 10:43:30 2021 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9183E3A30E5 for ; Wed, 21 Apr 2021 10:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.668 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VN5rjc0aQWeC for ; Wed, 21 Apr 2021 10:43:23 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A410B3A30E4 for ; Wed, 21 Apr 2021 10:43:23 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 13LHhIoQ004778 for ; Wed, 21 Apr 2021 19:43:18 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id D0675206024 for ; Wed, 21 Apr 2021 19:43:18 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id C6AF5204BE4 for ; Wed, 21 Apr 2021 19:43:18 +0200 (CEST) Received: from [10.14.0.28] ([10.14.0.28]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 13LHhHRS025004 for ; Wed, 21 Apr 2021 19:43:17 +0200 To: its@ietf.org References: <01d601d731e3$140e2ed0$3c2a8c70$@eurecom.fr> <0600020f-b6ca-4d6d-2499-817586bc3548@gmail.com> <19dce5f5-8dca-55c2-4d46-bb83046562ab@gmail.com> From: Alexandre Petrescu Message-ID: <1ec103fe-7a50-cb2c-0763-30cc6362bf13@gmail.com> Date: Wed, 21 Apr 2021 19:43:17 +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: <19dce5f5-8dca-55c2-4d46-bb83046562ab@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] requirements for CAs for vehicular networks X-BeenThere: its@ietf.org 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: Wed, 21 Apr 2021 17:43:29 -0000 This is my list of requirements for CAs for vehicular networks: - must be reachable on IPv6, and their website too. - must be present built-in in open source web browsers. - must express their requirements to vehicular networks in terms of capabilities of certificates. For example, a CA may agree to sign only a number of certs (1000?) per vehicle, but no more. Or might suggest new fields in these X.509 certs that they are ready to confirm (to certify). - must sign and offer almost for free certificates for vehicular networks. It's not because the car industry makes much money that a lot has to be wasted on artificial costs. The way for CA to make money should be different than direct charging the vehicular industry. - must contribute to make Internet better, and not seggregate the vehicular networks from the Internet. And this below is our dicussion that helped me frame these requirements, and I thank you for the discussion. Le 20/04/2021 à 11:51, Alexandre Petrescu a écrit : [...] >> - Scoop@F http://www.scoop.developpement-durable.gouv.fr/ >> : This is not reachable on IPv6. >> >> >> which is about deploying 3000 cars + 2000 km of roads >> >> >> - InterCor https://intercor-project.eu/ >> , This is not reachable on IPv6. >> >> - C-Roads Platform https://www.c-roads.eu/platform.html >> This is not reachable on IPv6. >> >> >> 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 >> >> >> . >> >> >> >> >> >> 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 This is reachable on IPv6. >> >> >> >> >> >> >> >> 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 >> . I already used it. This is not reachable on IPv6. Several people who contributed to IETF also asked github support to put it on IPv6. There is no answer since some time now. I would suggest the person who maintains that java implementation of 1609.2 to put it on another server that is reachable on IPv6. Or otherwise to ask too, like the others have, github.com to be on IPv6. > 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/ >> This is not reachable on IPv6. And ISS CA (Integrated Security Services) is not in my browser either. In comparison, Microsec might provide certificates in bilateral agreements that might cost less, or almost 0. And Microsec is reachable on IPv, and is in my browser. There is also the Let's Encrypt CA that is reachable on IPv6. I think they might offer certificates free of charge too. These kinds of CAs (Microsec and Let's Encrypt) are good candidates to whom to propose interoperability for vehicular networks on IPv6. There might be other such CAs? So, the question is whether Microsec and Let's Encrypt (who are on IPv6 and offer somehow very cheap or almost free certificates), offer compliance with RFC 8902? If yes, is it with ITS Certificates (1609.2) or with X.509 certificates? Alex > > 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* >> > >> 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 > >, IPWAVE WG > > >> >> >> >> >> 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 > > 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@ietf.org >> https://www.ietf.org/mailman/listinfo/its >> >>> >>> _______________________________________________ its mailing list >>> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its >> >>> >> >> _______________________________________________ its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its >> >> >> >> _______________________________________________ its mailing list >> its@ietf.org https://www.ietf.org/mailman/listinfo/its >> > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From nobody Thu Apr 22 08:52:55 2021 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70E263A15B7 for ; Thu, 22 Apr 2021 08:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.669 X-Spam-Level: X-Spam-Status: No, score=0.669 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_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id duALbk_4KcW2 for ; Thu, 22 Apr 2021 08:52:48 -0700 (PDT) Received: from smtp2-g21.free.fr (smtp2-g21.free.fr [IPv6:2a01:e0c:1:1599::11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 479213A15AC for ; Thu, 22 Apr 2021 08:52:48 -0700 (PDT) Received: from [IPv6:2a01:e0a:937:bc30::c8b2:2e1d] (unknown [IPv6:2a01:e0a:937:bc30::c8b2:2e1d]) by smtp2-g21.free.fr (Postfix) with ESMTP id 3242A2003EF for ; Thu, 22 Apr 2021 17:52:41 +0200 (CEST) To: its@ietf.org References: <01d601d731e3$140e2ed0$3c2a8c70$@eurecom.fr> <0600020f-b6ca-4d6d-2499-817586bc3548@gmail.com> <19dce5f5-8dca-55c2-4d46-bb83046562ab@gmail.com> <1ec103fe-7a50-cb2c-0763-30cc6362bf13@gmail.com> From: Alexandre Petrescu Message-ID: Date: Thu, 22 Apr 2021 17:52:41 +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: <1ec103fe-7a50-cb2c-0763-30cc6362bf13@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] wish list for CAs for vehicular networks X-BeenThere: its@ietf.org 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, 22 Apr 2021 15:52:54 -0000 In private I was suggested a few improvements about 'commodity' browsers, CABForum and federations of CAs; so here is the new wish list: Wish list for CAs for vehicular networks - must be reachable on IPv6, and their website too. - must be present built-in in commodity web browsers, and open source because that guarantees trust built at large scale and helps spot the bugs quickly for the benefit of all. - must express their requirements to vehicular networks in terms of capabilities of certificates. For example, a CA may agree to sign only a number of certs (1000?) per vehicle, but no more. Or might suggest new fields in these X.509 certs that they are ready to confirm (to certify). - must sign and offer almost for free certificates for vehicular networks. It's not because the car industry makes much money that a lot has to be wasted on artificial costs. The way for CA to make money should be different than direct charging the vehicular industry. - there might be possibilities of considering new web browsers (other than the 'commodity'). - maybe a relationship with IOTOPS WG of IETF could be considered. - the CABForum outside of IETF might be considered (but unreachable on IPv6, currently). - maybe new federations of CAs could be considered, in which the vehicular industries might built their own world, but that should not be a path towards seggregating away from the Internet trust. - must contribute to make Internet better, and not seggregate the vehicular networks from the Internet. Please comment on this wish list. Maybe we can write a brief Internet Draft about wishes about security, Internet, and Intelligent Transportation Systems. Alex Le 21/04/2021 à 19:43, Alexandre Petrescu a écrit : > This is my list of requirements for CAs for vehicular networks: - > must be reachable on IPv6, and their website too. - must be present > built-in in open source web browsers. - must express their > requirements to vehicular networks in terms of capabilities of > certificates. For example, a CA may agree to sign only a number of > certs (1000?) per vehicle, but no more. Or might suggest new fields > in these X.509 certs that they are ready to confirm (to certify). - > must sign and offer almost for free certificates for vehicular > networks. It's not because the car industry makes much money that a > lot has to be wasted on artificial costs. The way for CA to make > money should be different than direct charging the vehicular > industry. - must contribute to make Internet better, and not > seggregate the vehicular networks from the Internet. > > And this below is our dicussion that helped me frame these > requirements, and I thank you for the discussion. > > Le 20/04/2021 à 11:51, Alexandre Petrescu a écrit : [...] > >>> - Scoop@F http://www.scoop.developpement-durable.gouv.fr/ >>> : > > This is not reachable on IPv6. > >>> >>> >>> which is about deploying 3000 cars + 2000 km of roads >>> >>> >>> - InterCor https://intercor-project.eu/ >>> , > > This is not reachable on IPv6. > > >>> >>> - C-Roads Platform https://www.c-roads.eu/platform.html >>> > > This is not reachable on IPv6. > > >>> >>> >>> 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 >>> >>> >>> >>> . >>> >>> >>> >>> >>> >>> >>> 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 >>> > > > This is reachable on IPv6. > >>> >>> >>> >>> >>> >>> >>> >>> >>> 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 >>> . I already used it. > > This is not reachable on IPv6. Several people who contributed to > IETF also asked github support to put it on IPv6. There is no answer > since some time now. > > I would suggest the person who maintains that java implementation of > 1609.2 to put it on another server that is reachable on IPv6. Or > otherwise to ask too, like the others have, github.com to be on > IPv6. > > >> 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/ >>> > > This is not reachable on IPv6. And ISS CA (Integrated Security > Services) is not in my browser either. > > In comparison, Microsec might provide certificates in bilateral > agreements that might cost less, or almost 0. And Microsec is > reachable on IPv, and is in my browser. > > There is also the Let's Encrypt CA that is reachable on IPv6. I > think they might offer certificates free of charge too. > > These kinds of CAs (Microsec and Let's Encrypt) are good candidates > to whom to propose interoperability for vehicular networks on IPv6. > > There might be other such CAs? > > So, the question is whether Microsec and Let's Encrypt (who are on > IPv6 and offer somehow very cheap or almost free certificates), offer > compliance with RFC 8902? If yes, is it with ITS Certificates > (1609.2) or with X.509 certificates? > > Alex > >> >> 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* >>> >> > 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 >>> >, >>> IPWAVE WG > >>> >>> >>> >>> >>> 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 >> > 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@ietf.org >>> https://www.ietf.org/mailman/listinfo/its >>> >>>> >>>> _______________________________________________ its mailing >>>> list its@ietf.org >>> https://www.ietf.org/mailman/listinfo/its >>> >>>> >>> >>> _______________________________________________ its mailing list >>> its@ietf.org >>> https://www.ietf.org/mailman/listinfo/its >>> >>> >>> >>> _______________________________________________ its mailing list >>> its@ietf.org https://www.ietf.org/mailman/listinfo/its >>> >> >> _______________________________________________ its mailing list >> its@ietf.org https://www.ietf.org/mailman/listinfo/its > > _______________________________________________ its mailing list > its@ietf.org https://www.ietf.org/mailman/listinfo/its From nobody Thu Apr 22 08:53:07 2021 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD4573A15AF for ; Thu, 22 Apr 2021 08:53:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.846 X-Spam-Level: X-Spam-Status: No, score=-1.846 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GhPHCGd8k41G for ; Thu, 22 Apr 2021 08:53:01 -0700 (PDT) Received: from mail-qv1-xf32.google.com (mail-qv1-xf32.google.com [IPv6:2607:f8b0:4864:20::f32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3DC83A15DA for ; Thu, 22 Apr 2021 08:53:00 -0700 (PDT) Received: by mail-qv1-xf32.google.com with SMTP id dp18so17608081qvb.5 for ; Thu, 22 Apr 2021 08:53:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=M6yYKzkC5P8dDB9W4vj1N9FnmgWnD+ltCTvkjoHRwi8=; b=hgc+k46moqogVwEX09izzfYY5cAkbvDw5bfcl3+h1J7e5WhW5ZMz6qTzstS4C3Hray SUNGHx97sm9igmO9fN1lHkoyb5FYjVrsDxSEwLIcDUxzVkECjgs6ZKprR9nhAC7heWuD r4LcfFik94CQuvB+MaoaCzbnRtwV3lSBdepEkp5ltC3HcfpNesZI405cOpmFYKfRx0K+ CzWXPo1ve7J4OdYmuJF1HMHz6uMb6Lnsb5JwSOfmzTi+zhrv3WJIC1T3w9liN5VpX4bE XedOWh1dv/0RqtkwVIPvtYK7zr5dICVoayHvcpat0GelsLYP7OdMJ9qyYMkI+a9iDFj1 WaBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=M6yYKzkC5P8dDB9W4vj1N9FnmgWnD+ltCTvkjoHRwi8=; b=sV8B8trr4uALhmq7/Hb6sigPii9iyQeRYTuHZ37+H816AzfHZZL6ceDdMzCEhknEJ4 JG5ydnYdEB0rTMshTLat+5VmrwwNZfRFNGeolM1g1Gi4lo6v7n1U9piAwJKyGPPQyo9T e1AdMr6yPa6R+931BbW8J9VkJJUI2WcRPzsPjnu72YoXXxszb50mUnXZCQ0VWEDDYoyb 80r7L2XpB5OHYjPKyhi5NswYQWefU2MEJgESsFulrDs3GW4MUpr+aVYiuWBEfNRFaG7q iw8ZOmeXd/wrTef29/9uaQe6OVpxgq/y9QDhBXuqUV948F7SqnDfUQvm9RACOne9dusI hiqQ== X-Gm-Message-State: AOAM530I5+24CUydineV0ZfSMV6BC8Yst2JodUTbL1XtQkMt0NSzyU1M vbbMkODbNMlIn5wJyC/Hsne+VRS2Anb6ELCGEeo= X-Google-Smtp-Source: ABdhPJyzcOlCGOP/SOqBdXgMtcmV5+FsXkU+VzD7XgzWfp5Y7EOKnORzUX/QZIrDcdjn2c2LtgJwaZrdiAIRhD9EmO8= X-Received: by 2002:a0c:9e0f:: with SMTP id p15mr4286408qve.27.1619106778552; Thu, 22 Apr 2021 08:52:58 -0700 (PDT) MIME-Version: 1.0 References: <01d601d731e3$140e2ed0$3c2a8c70$@eurecom.fr> <0600020f-b6ca-4d6d-2499-817586bc3548@gmail.com> <19dce5f5-8dca-55c2-4d46-bb83046562ab@gmail.com> In-Reply-To: From: Mounira MSAHLI Date: Thu, 22 Apr 2021 17:52:47 +0200 Message-ID: To: Alexandre Petrescu , its@ietf.org Content-Type: multipart/alternative; boundary="000000000000639ba805c091ac5a" Archived-At: Subject: Re: [ipwave] RFC8902 - TLS with ITS Certificates, EXPERIMENTAL, and the one PKI and one Internet X-BeenThere: its@ietf.org 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, 22 Apr 2021 15:53:07 -0000 --000000000000639ba805c091ac5a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > > > 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-Road= s > 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). > > > > >> 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 > > > > >> Yes, but what CA would be put in the server of that log? Would that C= A > > 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 case of TLS Client Using the ITS Certificate and TLS Server Uses the > X.509 Certificate is already covered by the RFC 8902. > > > >> 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: > > IEEE Std 1609.2 (IEEE Standard for Wireless Access in Vehicular > Environments); > > =E2=80=A2 ETSI TS 102 940 (ITS-S security (PKI) architecture and applicat= ion > groups); > > =E2=80=A2 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. > > > >> And Microsec CA _is_ present in the browsers > > > You mean the certificate authority. You want to sign CAM with certificate > authority ? > > > I did not get the point could you clarify more please. > > > > >> 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 ? > > Scoop + Intercor projects are already finished in December 2019. > > > > 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. > > > > Best Regards > > Mounira > > Le mar. 20 avr. 2021 =C3=A0 11:51, Alexandre Petrescu < > alexandre.petrescu@gmail.com> a =C3=A9crit : > >> Hi, Mounira, >> >> Le 16/04/2021 =C3=A0 14:13, Mounira MSAHLI a =C3=A9crit : >> > >> > Dear all, Dear Russ, Dear Jerome, Dear Alex, >> > >> > >> > >> > I=E2=80=99m 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/ >> > : >> > >> > >> > which is about deploying 3000 cars + 2000 km of roads >> > >> > >> > - InterCor https://intercor-project.eu/ >> > , >> > >> > - C-Roads Platform 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/i= ndid.html >> > >> > < >> https://www.c-roads.eu/pilots/core-members/france/Partner/project/show/i= ndid.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_p= olicy_release_1.pdf >> > >> > < >> https://ec.europa.eu/transport/sites/transport/files/c-its_certificate_p= olicy_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=E2=80=A6 >> >> 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 >> > . 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/ >> > >> >> 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=E2=80=99m 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* >> > > >> > Date: jeu. 15 avr. 2021 =C3=A0 22:44 Subject: Re: [ipwave] RFC8902 - T= LS >> > with ITS Certificates, EXPERIMENTAL, and the one PKI and one >> > Internet To: J=C3=A9r=C3=B4me H=C3=A4rri > > >, IPWAVE WG > > > >> > >> > >> > >> > >> > Le 15/04/2021 =C3=A0 12:35, J=C3=A9r=C3=B4me H=C3=A4rri a =C3=A9crit : >> >> 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=C3=A9r=C3=B4me, >> > >> > 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=C3=A9r=C3=B4me >> >> >> >> -----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@ietf.org >> > https://www.ietf.org/mailman/listinfo/its >> > >> >> >> >> _______________________________________________ its mailing list >> >> its@ietf.org >> > https://www.ietf.org/mailman/listinfo/its >> > >> >> >> > >> > _______________________________________________ its mailing list >> > its@ietf.org >> > https://www.ietf.org/mailman/listinfo/its >> > >> > >> > >> > _______________________________________________ its mailing list >> > its@ietf.org https://www.ietf.org/mailman/listinfo/its >> > >> >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its >> > --000000000000639ba805c091ac5a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable



Hi Alex,=C2=A0


>> But there are also ot= her projects funded by the EU in the same domain (connected automated mobil= ity 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. T= he common certificate data structure standard is ETSI TS 103 097 ( version = 1.3.1 which is a profile of 1609.2).



>> Yes, but has that b= een done?=C2=A0 HAs someone put CAM messages on IP on a 4G=C2=A0

link and signed with 1609.2 = certificates?=C2=A0 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=C2=A0



>> Yes, but what CA wo= uld be put in the server of that log?=C2=A0 Would that CA=C2=A0

be a self-made CA with opens= sl (or other open source software), or would=C2=A0

it be a widely known CA like= the CAs present in firefox, for example?


<= /p>

My guess is that you assume = a self-made CAs, and I agree with it for=C2=A0

experimentation.


<= /p>

>> But for deployment = there would be a need for the existing CAs in the=C2=A0

browsers to implement these = 1609.2 certs.=C2=A0 And they are paying.=C2=A0 I doubt=C2=A0

it could work.


<= /p>

The case of TLS Client Using = the ITS Certificate and TLS Server Uses the X.509 Certificate is already co= vered by the RFC 8902.=C2=A0


>> Recently I worked wi= th Microsec and they might also propose certificates=C2=A0

for cheaper (free), if it is= for evaluation, or for academia, or=C2=A0

similar.=C2=A0 And Microsec = CA _is_ present in the browsers.=C2=A0 But can=C2=A0

Microsec sign these 1609.2 c= ertificates and still not ask me (end user)=C2=A0

to pay for the certificates?= =C2=A0


<= /p>

I find that Microsec cert ar= e compliant to standards below:=C2=A0

=C2=A0 IEEE Std 1609.2 (IEEE= Standard for Wireless Access in Vehicular Environments);

=E2=80=A2 ETSI TS 102 940 (I= TS-S security (PKI) architecture and application groups);

=E2=80=A2 ETSI TS 102 941 (T= rust and Privacy Management)

ETSI TS 103 097 (Certificate and message structure definitions for C2C= PKI).


<= /p>

So if you have end user micr= os cert, you can use it to sign C-ITS messages.=C2=A0


<= /p>

>> And Microsec CA _is= _ present in the browsers


<= /p>

You mean the certificate aut= hority. You want to sign CAM with certificate authority ?=C2=A0


<= /p>

I did not get the point coul= d you clarify more please.=C2=A0


<= /p>


>> http://www.scoop.developpement-durable.gouv.fr/> :


<= /p>

>> This is not reachab= le on IPv6.


<= /p>

You mean the web page of the= project or the PKI of the project ?=C2=A0

Scoop + Intercor projects ar= e already finished in December 2019.=C2=A0


<= /p>


<= /p>

Any way the business model o= f 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.=C2=A0


<= /p>


<= /p>

Best = Regards=C2=A0

M= ounira


Le=C2=A0mar. 20 avr. 2021 =C3=A0=C2=A011:51, Alexandre Petr= escu <= alexandre.petrescu@gmail.com> a =C3=A9crit=C2=A0:
Hi, Mounira,

Le 16/04/2021 =C3=A0 14:13, Mounira MSAHLI a =C3=A9crit :
>
> Dear all, Dear Russ, Dear Jerome, Dear Alex,
>
>
>
> I=E2=80=99m 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.=C2=A0 They w= ork
>
> fine.
>
>
> But, I want to highlight that the European commission are=C2=A0 fundin= g
> 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/> :
>
>
> which is about deploying 3000 cars + 2000 km of roads
>
>
> - InterCor 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>
>
>
> 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
>=C2=A0
> <https://ww= w.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<= br> >=C2=A0 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.

>
> http= s://ec.europa.eu/transport/sites/transport/files/c-its_certificate_policy_r= elease_1.pdf
>=C2=A0
> <= https://ec.europa.eu/transport/sites/transport/files/c-its_certificate_poli= cy_release_1.pdf>
>
>
>
> As mentioned by Jerome, one use case of the RFC 8902 could be to sign<= br> >=C2=A0 CAM and DENM messages on facilities layer and not geonet as
> specified in ETSI.

Yes, but has that been done?=C2=A0 HAs someone put CAM messages on IP on a = 4G
link and signed with 1609.2 certificates?=C2=A0 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<= br> > 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=E2=80=A6

Yes, but what CA would be put in the server of that log?=C2=A0 Would that C= A
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.=C2=A0 And they are paying.=C2=A0 = I doubt
it could work.

>
>
>
>>> The reason is because the former is all open source software a= nd
>>> freely accessible standards, whereas=C2=A0 1609.2 are closed d= ocuments
>>> and ETSI ITS certificate software is not integrated in mainlin= e
>>> 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>. I alrea= dy used it.

Yes, but the spec is paying.=C2=A0 That does inspire seriousness but might =
inspire risk for the confidence.

>
>
>>> ITS-specific CAs are closed, hard to access and the certificat= e
>>> are
>
> expensive.=C2=A0 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/>
Thanks for the pointer, I did not know ghsiss.=C2=A0 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.=C2=A0 And Microsec CA _is_ present in the browsers.=C2=A0 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.=C2=A0 That is also a make kor break condition of use.=C2=A0 It is worth trying.

Thanks for the message.

Alex

>
>
>
>>> In=C2=A0 my personal opinion, it remains good if IPWAVE provid= es a
>>> guideline on how to secure IP vehicular communication, includi= ng
>>> interoperability between systems (although I have at that time=
>>> limited resources to actively contribute to this), as several<= br> >>> options are on the table and we need to guarantee the trust >>> chain, even considering different protocol or standards being<= br> >>> used.
>
>
> I=E2=80=99m 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>>=
> Date: jeu. 15 avr. 2021 =C3=A0 22:44 Subject: Re: [ipwave] RFC8902 - T= LS
> with ITS Certificates, EXPERIMENTAL, and the one PKI and one
> Internet To: J=C3=A9r=C3=B4me H=C3=A4rri <Jerome.Haerri@eurecom.fr
> <mailto:Jerome.Haerri@eurecom.fr>>, IPWAVE WG <its@ietf.org
> <mailto:its@ietf.= org>>
>
>
>
>
> Le 15/04/2021 =C3=A0 12:35, J=C3=A9r=C3=B4me H=C3=A4rri a =C3=A9crit :=
>> 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 exampl= e
>> in one of our cross-border deployment (e.g. DE-FR), this solution<= br> >> 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-cha= in
>> issue.
>
> J=C3=A9r=C3=B4me,
>
> I agree with you.
>
> In the discussion above I think you meant 'PKI' throughout (Pu= blic
> Key Infrastructure), and not 'KPI' (Key Performance Indicator)= .
>
> That said, the question you formulate about how a car-to-server MQTT <= br> > interaction on IP would be authenticated by certificates that are
> verified by CAs that are absent from normal browsers, or how the CAs <= br> > that are present in normal browsers would help authenticating CAM
> messages sent on IP - is a very relevant question.
>
> Alex
>>
>> Best Regards,
>>
>> J=C3=A9r=C3=B4me
>>
>> -----Original Message----- From: its <its-bounces@ietf.org
> <mailto:i= ts-bounces@ietf.org>> On Behalf
>> Of Alexandre Petrescu Sent: Thursday, 15 April 2021 12:20 To:
>> IPWAVE WG <it= s@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.=C2=A0 That is a discrepancy that exists for a long time, and = I
>> must share that - IMHO - I am surprised that the IETF issues an RF= C
>> 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. <= br> >> They work fine.=C2=A0 The CA is a local CA (not a commercial CA), = but
>> the concept _is_ compatible with normal CAs.=C2=A0 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.=C2=A0 The reas= on 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.=C2=A0 Many strong oppinions maintain th= at 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?=C2=A0 Maybe I miss something= ...
>>
>> Alex
>>
>> _______________________________________________ its mailing list <= br> >> its@ietf.org= <mailto:its@ietf.org<= /a>>
> https://www.ietf.org/mailman/listinfo/its
> <https://www.ietf.org/mailman/listinfo/its><= br> >>
>> _______________________________________________ its mailing list <= br> >> its@ietf.org= <mailto:its@ietf.org<= /a>>
> https://www.ietf.org/mailman/listinfo/its
> <https://www.ietf.org/mailman/listinfo/its><= br> >>
>
> _______________________________________________ its mailing list
> its@ietf.org <= ;mailto:its@ietf.org&= gt;
> https://www.ietf.org/mailman/listinfo/its
> <https://www.ietf.org/mailman/listinfo/its><= br> >
>
> _______________________________________________ its mailing list
> its@ietf.org https://www.ietf.org/mailman/listinfo/its
>

_______________________________________________
its mailing list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its
--000000000000639ba805c091ac5a-- From nobody Thu Apr 22 10:16:42 2021 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C985A3A0CBE for ; Thu, 22 Apr 2021 10:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.846 X-Spam-Level: X-Spam-Status: No, score=-1.846 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2K1DbUW8NU8W for ; Thu, 22 Apr 2021 10:16:35 -0700 (PDT) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 748ED3A0B9D for ; Thu, 22 Apr 2021 10:16:35 -0700 (PDT) Received: by mail-qt1-x835.google.com with SMTP id d6so16128853qtx.13 for ; Thu, 22 Apr 2021 10:16:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=aeg/u7b6bMzrF8BLvd9a4ShXwOy6QpJniDFcoM/8iDI=; b=cNO70NiJ22/PY5zWwpjXnR7kHxCkS1yrHqjxKO+bC6MXFbgvTRPGd8V9APojv5ebM3 C/t9tA3GUpzzgRDTL0rQK8gMVc5+dkUd8Y93UgNMWoeAnmz59nokkPYJ99kpezDhcUIU JEp9Xzzdhs/T6XKcAgQKLNyXOJX0p4Ju7ZAbebbMPcjpKReHa8g2l1B+/bhAIKA4Gn9a LL/1PM8Zu9HzrFYGnYY+1/UtOzQAiAvR/kWMvYZGF8LaKFhOTVKZQBnRCQxdpN7D1ZUQ VqFaqCJyTD6m9gxifT+AwUduZVgvQC42YCT3B6LbX+cI0tJpgIs+lS6f4OCF1lZtTd1F nGvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=aeg/u7b6bMzrF8BLvd9a4ShXwOy6QpJniDFcoM/8iDI=; b=bQdP8lZy2YaF42jKnl4mN737Ex22QZz4OchiArNMJI1Ya/2orATXEeTLTgHC2z6Qpi ri2G0FTTvg6Z6i5AcSwNsAM3TVkjIgsKvGtm+B+SE93ouj/dW4w+K5h/nwqiz5Zffo4e RCICvsKVtbD8z7kkaqQeqrdLeWa41/bqO+nftQBA2KwuXiDsCgKEqwO8Chy6R1d8spi2 nUpS910QsQ9RehaShpX/dJpc7q9sfEkqF2NPgJn3mc2fw7Wn4YqxsyUpAdD92doSSkKk qUGGXDZt2EiDcOBHj5CFZSDmS3hseSxMG3Fdx5vIvOTtp22aOtF6Sv0RWn2yp/mP09O+ MLYA== X-Gm-Message-State: AOAM533KqFqzr46c4jpqVg9T8AHAJJCtP+ABBXOrivPnU3lDl+OD1Bq1 tmlvrfgQSp/EtwcM2G8L4NZp0E+kX49yTyKEM38= X-Google-Smtp-Source: ABdhPJxfAf43gmkgEbbHJ4uo+5UE/cIVwAc9KS2KH4xo/Skvj9rM1LE8FLIq70KGwuw/Zo6fq9WjV7keqzrEmTGKV5Y= X-Received: by 2002:a05:622a:446:: with SMTP id o6mr4151472qtx.257.1619111793272; Thu, 22 Apr 2021 10:16:33 -0700 (PDT) MIME-Version: 1.0 References: <01d601d731e3$140e2ed0$3c2a8c70$@eurecom.fr> <0600020f-b6ca-4d6d-2499-817586bc3548@gmail.com> <19dce5f5-8dca-55c2-4d46-bb83046562ab@gmail.com> In-Reply-To: From: Mounira MSAHLI Date: Thu, 22 Apr 2021 19:16:22 +0200 Message-ID: To: Alexandre Petrescu , its@ietf.org Content-Type: multipart/alternative; boundary="0000000000004a2d1205c092d76e" Archived-At: Subject: Re: [ipwave] RFC8902 - TLS with ITS Certificates, EXPERIMENTAL, and the one PKI and one Internet X-BeenThere: its@ietf.org 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, 22 Apr 2021 17:16:41 -0000 --0000000000004a2d1205c092d76e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable But how you can sign with a certificate retrieved from the browser without the private key ? Regards Mounira Le jeu. 22 avr. 2021 =C3=A0 17:52, Mounira MSAHLI a =C3=A9crit : > >> >> 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 ope= n >> 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 standar= d >> is ETSI TS 103 097 ( version 1.3.1 which is a profile of 1609.2). >> >> >> >> >> 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 teste= d >> on hybrid communication ITS-G5 and 5G >> >> >> >> >> 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 case of TLS Client Using the ITS Certificate and TLS Server Uses the >> X.509 Certificate is already covered by the RFC 8902. >> >> >> >> 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: >> >> IEEE Std 1609.2 (IEEE Standard for Wireless Access in Vehicular >> Environments); >> >> =E2=80=A2 ETSI TS 102 940 (ITS-S security (PKI) architecture and applica= tion >> groups); >> >> =E2=80=A2 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. >> >> >> >> And Microsec CA _is_ present in the browsers >> >> >> You mean the certificate authority. You want to sign CAM with certificat= e >> authority ? >> >> >> I did not get the point could you clarify more please. >> >> >> >> >> 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 ? >> >> Scoop + Intercor projects are already finished in December 2019. >> >> >> >> 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 th= e >> PKI. >> >> >> >> Best Regards >> >> Mounira >> >> Le mar. 20 avr. 2021 =C3=A0 11:51, Alexandre Petrescu < >> alexandre.petrescu@gmail.com> a =C3=A9crit : >> >>> Hi, Mounira, >>> >>> Le 16/04/2021 =C3=A0 14:13, Mounira MSAHLI a =C3=A9crit : >>> > >>> > Dear all, Dear Russ, Dear Jerome, Dear Alex, >>> > >>> > >>> > >>> > I=E2=80=99m 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/ >>> > : >>> > >>> > >>> > which is about deploying 3000 cars + 2000 km of roads >>> > >>> > >>> > - InterCor https://intercor-project.eu/ >>> > , >>> > >>> > - C-Roads Platform 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 >>> >. >>> > >>> > >>> > >>> > >>> > 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 >>> > >>> > >>> > >>> > >>> > 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 4= G >>> 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=E2=80=A6 >>> >>> 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 woul= d >>> 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 doub= t >>> 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 >>> > . 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/ >>> > >>> >>> Thanks for the pointer, I did not know ghsiss. Are they paying >>> certificates? >>> >>> Recently I worked with Microsec and they might also propose certificate= s >>> 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=E2=80=99m 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* >>> > > >>> > Date: jeu. 15 avr. 2021 =C3=A0 22:44 Subject: Re: [ipwave] RFC8902 - = TLS >>> > with ITS Certificates, EXPERIMENTAL, and the one PKI and one >>> > Internet To: J=C3=A9r=C3=B4me H=C3=A4rri >> > >, IPWAVE WG >> > > >>> > >>> > >>> > >>> > >>> > Le 15/04/2021 =C3=A0 12:35, J=C3=A9r=C3=B4me H=C3=A4rri a =C3=A9crit = : >>> >> 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=C3=A9r=C3=B4me, >>> > >>> > 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=C3=A9r=C3=B4me >>> >> >>> >> -----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@ietf.org >>> > https://www.ietf.org/mailman/listinfo/its >>> > >>> >> >>> >> _______________________________________________ its mailing list >>> >> its@ietf.org >>> > https://www.ietf.org/mailman/listinfo/its >>> > >>> >> >>> > >>> > _______________________________________________ its mailing list >>> > its@ietf.org >>> > https://www.ietf.org/mailman/listinfo/its >>> > >>> > >>> > >>> > _______________________________________________ its mailing list >>> > its@ietf.org https://www.ietf.org/mailman/listinfo/its >>> > >>> >>> _______________________________________________ >>> its mailing list >>> its@ietf.org >>> https://www.ietf.org/mailman/listinfo/its >>> >> --0000000000004a2d1205c092d76e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

But how you can sign with = a certificate retrieved from the browser without the private key ?=C2=A0

Regards=C2=A0
Mounira=C2=A0

Le=C2=A0jeu. 22= avr. 2021 =C3=A0=C2=A017:52, Mounira MSAHLI <msahli1717@gmail.com> a =C3=A9crit=C2=A0:
=



Hi Alex,=C2=A0


>> But the= re are also other projects funded by the EU in the same domain (connected a= utomated 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. T= he common certificate data structure standard is ETSI TS 103 097 ( version = 1.3.1 which is a profile of 1609.2).



>> Yes, but has that b= een done?=C2=A0 HAs someone put CAM messages on IP on a 4G=C2=A0

link and signed with 1609.2 = certificates?=C2=A0 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=C2=A0



>> Yes, but what CA wo= uld be put in the server of that log?=C2=A0 Would that CA=C2=A0

be a self-made CA with opens= sl (or other open source software), or would=C2=A0

it be a widely known CA like= the CAs present in firefox, for example?


<= /p>

My guess is that you assume = a self-made CAs, and I agree with it for=C2=A0

experimentation.


<= /p>

>> But for deployment = there would be a need for the existing CAs in the=C2=A0

browsers to implement these = 1609.2 certs.=C2=A0 And they are paying.=C2=A0 I doubt=C2=A0

it could work.


<= /p>

The case of TLS Client Using = the ITS Certificate and TLS Server Uses the X.509 Certificate is already co= vered by the RFC 8902.=C2=A0


>> Recently I worked wi= th Microsec and they might also propose certificates=C2=A0

for cheaper (free), if it is= for evaluation, or for academia, or=C2=A0

similar.=C2=A0 And Microsec = CA _is_ present in the browsers.=C2=A0 But can=C2=A0

Microsec sign these 1609.2 c= ertificates and still not ask me (end user)=C2=A0

to pay for the certificates?= =C2=A0


<= /p>

I find that Microsec cert ar= e compliant to standards below:=C2=A0

=C2=A0 IEEE Std 1609.2 (IEEE= Standard for Wireless Access in Vehicular Environments);

=E2=80=A2 ETSI TS 102 940 (I= TS-S security (PKI) architecture and application groups);

=E2=80=A2 ETSI TS 102 941 (T= rust and Privacy Management)

ETSI TS 103 097 (Certificate and message structure definitions for C2C= PKI).


<= /p>

So if you have end user micr= os cert, you can use it to sign C-ITS messages.=C2=A0


<= /p>

>> And Microsec CA _is= _ present in the browsers


<= /p>

You mean the certificate aut= hority. You want to sign CAM with certificate authority ?=C2=A0


<= /p>

I did not get the point coul= d you clarify more please.=C2=A0


<= /p>


>> http://www.scoop.developpement-durable.gouv.fr/> :


<= /p>

>> This is not reachab= le on IPv6.


<= /p>

You mean the web page of the= project or the PKI of the project ?=C2=A0

Scoop + Intercor projects ar= e already finished in December 2019.=C2=A0


<= /p>


<= /p>

Any way the business model o= f 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.=C2=A0


<= /p>


<= /p>

Best = Regards=C2=A0

M= ounira


Le=C2=A0mar. 20 avr. 2021 =C3=A0=C2=A011:51, Alexandre Petr= escu <= alexandre.petrescu@gmail.com> a =C3=A9crit=C2=A0:
Hi, Mounira,

Le 16/04/2021 =C3=A0 14:13, Mounira MSAHLI a =C3=A9crit :
>
> Dear all, Dear Russ, Dear Jerome, Dear Alex,
>
>
>
> I=E2=80=99m 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.=C2=A0 They w= ork
>
> fine.
>
>
> But, I want to highlight that the European commission are=C2=A0 fundin= g
> 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/> :
>
>
> which is about deploying 3000 cars + 2000 km of roads
>
>
> - InterCor 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>
>
>
> 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
>=C2=A0
> <https://ww= w.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<= br> >=C2=A0 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.

>
> http= s://ec.europa.eu/transport/sites/transport/files/c-its_certificate_policy_r= elease_1.pdf
>=C2=A0
> <= https://ec.europa.eu/transport/sites/transport/files/c-its_certificate_poli= cy_release_1.pdf>
>
>
>
> As mentioned by Jerome, one use case of the RFC 8902 could be to sign<= br> >=C2=A0 CAM and DENM messages on facilities layer and not geonet as
> specified in ETSI.

Yes, but has that been done?=C2=A0 HAs someone put CAM messages on IP on a = 4G
link and signed with 1609.2 certificates?=C2=A0 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<= br> > 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=E2=80=A6

Yes, but what CA would be put in the server of that log?=C2=A0 Would that C= A
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.=C2=A0 And they are paying.=C2=A0 = I doubt
it could work.

>
>
>
>>> The reason is because the former is all open source software a= nd
>>> freely accessible standards, whereas=C2=A0 1609.2 are closed d= ocuments
>>> and ETSI ITS certificate software is not integrated in mainlin= e
>>> 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>. I alrea= dy used it.

Yes, but the spec is paying.=C2=A0 That does inspire seriousness but might =
inspire risk for the confidence.

>
>
>>> ITS-specific CAs are closed, hard to access and the certificat= e
>>> are
>
> expensive.=C2=A0 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/>
Thanks for the pointer, I did not know ghsiss.=C2=A0 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.=C2=A0 And Microsec CA _is_ present in the browsers.=C2=A0 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.=C2=A0 That is also a make kor break condition of use.=C2=A0 It is worth trying.

Thanks for the message.

Alex

>
>
>
>>> In=C2=A0 my personal opinion, it remains good if IPWAVE provid= es a
>>> guideline on how to secure IP vehicular communication, includi= ng
>>> interoperability between systems (although I have at that time=
>>> limited resources to actively contribute to this), as several<= br> >>> options are on the table and we need to guarantee the trust >>> chain, even considering different protocol or standards being<= br> >>> used.
>
>
> I=E2=80=99m 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>>=
> Date: jeu. 15 avr. 2021 =C3=A0 22:44 Subject: Re: [ipwave] RFC8902 - T= LS
> with ITS Certificates, EXPERIMENTAL, and the one PKI and one
> Internet To: J=C3=A9r=C3=B4me H=C3=A4rri <Jerome.Haerri@eurecom.fr
> <mailto:Jerome.Haerri@eurecom.fr>>, IPWAVE WG <its@ietf.org
> <mailto:its@ietf.= org>>
>
>
>
>
> Le 15/04/2021 =C3=A0 12:35, J=C3=A9r=C3=B4me H=C3=A4rri a =C3=A9crit :=
>> 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 exampl= e
>> in one of our cross-border deployment (e.g. DE-FR), this solution<= br> >> 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-cha= in
>> issue.
>
> J=C3=A9r=C3=B4me,
>
> I agree with you.
>
> In the discussion above I think you meant 'PKI' throughout (Pu= blic
> Key Infrastructure), and not 'KPI' (Key Performance Indicator)= .
>
> That said, the question you formulate about how a car-to-server MQTT <= br> > interaction on IP would be authenticated by certificates that are
> verified by CAs that are absent from normal browsers, or how the CAs <= br> > that are present in normal browsers would help authenticating CAM
> messages sent on IP - is a very relevant question.
>
> Alex
>>
>> Best Regards,
>>
>> J=C3=A9r=C3=B4me
>>
>> -----Original Message----- From: its <its-bounces@ietf.org
> <mailto:i= ts-bounces@ietf.org>> On Behalf
>> Of Alexandre Petrescu Sent: Thursday, 15 April 2021 12:20 To:
>> IPWAVE WG <it= s@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.=C2=A0 That is a discrepancy that exists for a long time, and = I
>> must share that - IMHO - I am surprised that the IETF issues an RF= C
>> 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. <= br> >> They work fine.=C2=A0 The CA is a local CA (not a commercial CA), = but
>> the concept _is_ compatible with normal CAs.=C2=A0 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.=C2=A0 The reas= on 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.=C2=A0 Many strong oppinions maintain th= at 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?=C2=A0 Maybe I miss something= ...
>>
>> Alex
>>
>> _______________________________________________ its mailing list <= br> >> its@ietf.org= <mailto:its@ietf.org<= /a>>
> https://www.ietf.org/mailman/listinfo/its
> <https://www.ietf.org/mailman/listinfo/its><= br> >>
>> _______________________________________________ its mailing list <= br> >> its@ietf.org= <mailto:its@ietf.org<= /a>>
> https://www.ietf.org/mailman/listinfo/its
> <https://www.ietf.org/mailman/listinfo/its><= br> >>
>
> _______________________________________________ its mailing list
> its@ietf.org <= ;mailto:its@ietf.org&= gt;
> https://www.ietf.org/mailman/listinfo/its
> <https://www.ietf.org/mailman/listinfo/its><= br> >
>
> _______________________________________________ its mailing list
> its@ietf.org https://www.ietf.org/mailman/listinfo/its
>

_______________________________________________
its mailing list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its
--0000000000004a2d1205c092d76e-- From nobody Thu Apr 22 10:30:59 2021 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CEB33A0E29 for ; Thu, 22 Apr 2021 10:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.845 X-Spam-Level: X-Spam-Status: No, score=-1.845 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5OOm7w6HsNtJ for ; Thu, 22 Apr 2021 10:30:53 -0700 (PDT) Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com [IPv6:2607:f8b0:4864:20::f2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A99D03A0E26 for ; Thu, 22 Apr 2021 10:30:52 -0700 (PDT) Received: by mail-qv1-xf2b.google.com with SMTP id er3so13897652qvb.6 for ; Thu, 22 Apr 2021 10:30:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=m/GFU5McYVE5zzpOSUdl9vPyfK07ieSp+SDABWUujCc=; b=CiDYmYskrcfI0r20MbKyPQ5k00xQh9cuvVr8PhZs++aPr16a2QlR4y/eixyvwgBokC RiGP0STEqzaGwH8y7EqY4vKg4fqH5n9aIn4xJ7r+GlbZKCMaYKPcwluZOlTXvLVS2eo/ sQg3oJkVKLKign+Vjm+ImhAQ3UB57tSdloamQzL+zB22JHmGny4+qIsPObtTXwxk+6g4 hySmpuKJrh2ejNA6SCsQPe+oOVu1o+aOPk/wFuCh9bGRms83DwoNNq9q4b5UcKjn5dko mVkwJxCvlGa/Iup1lz+gBx81JOjhtkYdeOKd+Q1W0woKJdigwmGtistT9w9AMvnZFb8E 59AA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=m/GFU5McYVE5zzpOSUdl9vPyfK07ieSp+SDABWUujCc=; b=i2EDpIGNv6WZaJHcG9z5CMrklHAJ9vr2ZJ1ObYYPrsig5m50Qt5Y7a75mTk4eKjZBR VU5p289dJx30YpmKn9ab33DJ1L//3kC4FAoXeO5ZQgxSgMD46XnfAut/db3VCxPIXjQ5 nys1Eiy4i4FxlWMyjfQ4PdCQwzWxZvErqMp276Nmxbk4mIfdOH5XZ6bJRFlo0RFNfcRw j/l0hGlZxP+36Nf9BPrQ7r3rIhyfibRV3gp/X96XxS++8MQqWfMOadVdlqJvIbB1lEYb s9TX1H/MWhPudHIFaxNZ+Afn341g/m9haLFxjgj9fpxCctEzQsRMt7yrgTWbbTmFyFrZ 8XVg== X-Gm-Message-State: AOAM530jcJzrpPVb8fUHtH9CYBWuxMcfoEfqJWoCCD3Vl5BpJ9IMQE5u p5mhJKPTAnbY5XSnFhJ1PigdI7adA9z6EypcmLuY/PkuDBw= X-Google-Smtp-Source: ABdhPJziFZBCKnl/ZvZBP7nJLHC5G5jrN09iCjimpwT+VZYdRKSADAjYZrSyijIoJszdoihEgy3E/ZWoQXPTHTA+fXA= X-Received: by 2002:a05:6214:504:: with SMTP id v4mr4543967qvw.4.1619112650552; Thu, 22 Apr 2021 10:30:50 -0700 (PDT) MIME-Version: 1.0 References: <01d601d731e3$140e2ed0$3c2a8c70$@eurecom.fr> <0600020f-b6ca-4d6d-2499-817586bc3548@gmail.com> <19dce5f5-8dca-55c2-4d46-bb83046562ab@gmail.com> <1ec103fe-7a50-cb2c-0763-30cc6362bf13@gmail.com> In-Reply-To: From: Mounira MSAHLI Date: Thu, 22 Apr 2021 19:30:39 +0200 Message-ID: To: Alexandre Petrescu Cc: its@ietf.org Content-Type: multipart/alternative; boundary="00000000000063397d05c0930abe" Archived-At: Subject: Re: [ipwave] wish list for CAs for vehicular networks X-BeenThere: its@ietf.org 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, 22 Apr 2021 17:30:58 -0000 --00000000000063397d05c0930abe Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable >> - must express their requirements to vehicular networks in terms of capabilities of certificates. For example, a CA may agree to sign only a number of certs (1000?) per vehicle, but no more. Or might suggest new fields in these X.509 certs that they are ready to confirm (to certify). I think the number of used pseudonym certificates depends on the strategy change of pseudonyms implemented in C-ITS station to avoid tracking and to ensure privacy >> - must sign and offer almost for free certificates for vehicular networks. It's not because the car industry makes much money that a lot has to be wasted on artificial costs. The way for CA to make money should be different than direct charging the vehicular industry. The EU commission is providing a PKI for member states who are not deploying C-ITS PKI, I think for free. >> Maybe we can write a brief Internet Draft about wishes about security, Internet, and Intelligent Transportation Systems. You mean ethical aspects ? Kind Regards Mounira Le jeu. 22 avr. 2021 =C3=A0 17:52, Alexandre Petrescu < alexandre.petrescu@gmail.com> a =C3=A9crit : > In private I was suggested a few improvements about 'commodity' > browsers, CABForum and federations of CAs; so here is the new wish list: > > Wish list for CAs for vehicular networks > > - must be reachable on IPv6, and their website too. > - must be present built-in in commodity web browsers, and open source > because that guarantees trust built at large scale and helps spot the > bugs quickly for the benefit of all. > - must express their requirements to vehicular networks in terms of > capabilities of certificates. For example, a CA may agree to sign > only a number of certs (1000?) per vehicle, but no more. Or might > suggest new fields in these X.509 certs that they are ready to confirm > (to certify). > - must sign and offer almost for free certificates for vehicular > networks. It's not because the car industry makes much money that a > lot has to be wasted on artificial costs. The way for CA to make > money should be different than direct charging the vehicular industry. > > - there might be possibilities of considering new web browsers (other > than the 'commodity'). > - maybe a relationship with IOTOPS WG of IETF could be considered. > - the CABForum outside of IETF might be considered (but unreachable on > IPv6, currently). > - maybe new federations of CAs could be considered, in which the > vehicular industries might built their own world, but that should not > be a path towards seggregating away from the Internet trust. > > - must contribute to make Internet better, and not seggregate the > vehicular networks from the Internet. > > Please comment on this wish list. > > Maybe we can write a brief Internet Draft about wishes about security, > Internet, and Intelligent Transportation Systems. > > Alex > > > Le 21/04/2021 =C3=A0 19:43, Alexandre Petrescu a =C3=A9crit : > > This is my list of requirements for CAs for vehicular networks: - > > must be reachable on IPv6, and their website too. - must be present > > built-in in open source web browsers. - must express their > > requirements to vehicular networks in terms of capabilities of > > certificates. For example, a CA may agree to sign only a number of > > certs (1000?) per vehicle, but no more. Or might suggest new fields > > in these X.509 certs that they are ready to confirm (to certify). - > > must sign and offer almost for free certificates for vehicular > > networks. It's not because the car industry makes much money that a > > lot has to be wasted on artificial costs. The way for CA to make > > money should be different than direct charging the vehicular > > industry. - must contribute to make Internet better, and not > > seggregate the vehicular networks from the Internet. > > > > And this below is our dicussion that helped me frame these > > requirements, and I thank you for the discussion. > > > > Le 20/04/2021 =C3=A0 11:51, Alexandre Petrescu a =C3=A9crit : [...] > > > >>> - Scoop@F http://www.scoop.developpement-durable.gouv.fr/ > >>> : > > > > This is not reachable on IPv6. > > > >>> > >>> > >>> which is about deploying 3000 cars + 2000 km of roads > >>> > >>> > >>> - InterCor https://intercor-project.eu/ > >>> , > > > > This is not reachable on IPv6. > > > > > >>> > >>> - C-Roads Platform https://www.c-roads.eu/platform.html > >>> > > > > This is not reachable on IPv6. > > > > > >>> > >>> > >>> 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/in= did.html > >>> > >>> > >>> > >>> < > https://www.c-roads.eu/pilots/core-members/france/Partner/project/show/in= did.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_po= licy_release_1.pdf > >>> > > > > > > This is reachable on IPv6. > > > >>> > >>> > >>> < > https://ec.europa.eu/transport/sites/transport/files/c-its_certificate_po= licy_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=E2=80=A6 > >> > >> 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 > >>> . I already used it. > > > > This is not reachable on IPv6. Several people who contributed to > > IETF also asked github support to put it on IPv6. There is no answer > > since some time now. > > > > I would suggest the person who maintains that java implementation of > > 1609.2 to put it on another server that is reachable on IPv6. Or > > otherwise to ask too, like the others have, github.com to be on > > IPv6. > > > > > >> 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/ > >>> > > > > This is not reachable on IPv6. And ISS CA (Integrated Security > > Services) is not in my browser either. > > > > In comparison, Microsec might provide certificates in bilateral > > agreements that might cost less, or almost 0. And Microsec is > > reachable on IPv, and is in my browser. > > > > There is also the Let's Encrypt CA that is reachable on IPv6. I > > think they might offer certificates free of charge too. > > > > These kinds of CAs (Microsec and Let's Encrypt) are good candidates > > to whom to propose interoperability for vehicular networks on IPv6. > > > > There might be other such CAs? > > > > So, the question is whether Microsec and Let's Encrypt (who are on > > IPv6 and offer somehow very cheap or almost free certificates), offer > > compliance with RFC 8902? If yes, is it with ITS Certificates > > (1609.2) or with X.509 certificates? > > > > Alex > > > >> > >> 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=E2=80=99m 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* > >>> >>> > Date: jeu. 15 avr. 2021 =C3=A0 > >>> 22:44 Subject: Re: [ipwave] RFC8902 - TLS with ITS Certificates, > >>> EXPERIMENTAL, and the one PKI and one Internet To: J=C3=A9r=C3=B4me H= =C3=A4rri > >>> >, > >>> IPWAVE WG > > >>> > >>> > >>> > >>> > >>> Le 15/04/2021 =C3=A0 12:35, J=C3=A9r=C3=B4me H=C3=A4rri a =C3=A9crit = : > >>>> 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=C3=A9r=C3=B4me, > >>> > >>> 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=C3=A9r=C3=B4me > >>>> > >>>> -----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@ietf.org > >>> https://www.ietf.org/mailman/listinfo/its > >>> > >>>> > >>>> _______________________________________________ its mailing > >>>> list its@ietf.org > >>> https://www.ietf.org/mailman/listinfo/its > >>> > >>>> > >>> > >>> _______________________________________________ its mailing list > >>> its@ietf.org > >>> https://www.ietf.org/mailman/listinfo/its > >>> > >>> > >>> > >>> _______________________________________________ its mailing list > >>> its@ietf.org https://www.ietf.org/mailman/listinfo/its > >>> > >> > >> _______________________________________________ its mailing list > >> its@ietf.org https://www.ietf.org/mailman/listinfo/its > > > > _______________________________________________ its mailing list > > its@ietf.org https://www.ietf.org/mailman/listinfo/its > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > --00000000000063397d05c0930abe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

>>=C2=A0- must express their= requirements to vehicular networks in terms of
=C2=A0 =C2= =A0capabilities of certificates.=C2=A0 For example, a CA may agree to sign<= /span>
=C2=A0 =C2=A0only a number of cert= s (1000?) per vehicle, but no more.=C2=A0 Or might
=C2=A0 =C2=A0suggest new fields in these X.509 certs that = they are ready to confirm
=C2=A0 = =C2=A0(to certify).

I think the number of used pseudonym certific= ates depends on the strategy change of pseudonyms implemented in C-ITS stat= ion to avoid tracking and to ensure privacy=C2=A0

>>=C2=A0- must sign and offer almost for free ce= rtificates for vehicular
=C2=A0 =C2=A0networks.=C2=A0 It= 9;s not because the car industry makes much money that a
=C2=A0 =C2=A0lot has to be wasted on artificial cost= s.=C2=A0 The way for CA to make
= =C2=A0 =C2=A0money should be different than direct charging the vehicular i= ndustry.

The EU commission is providing a PKI for member s= tates who are not deploying C-ITS PKI, I think for free.=C2=A0
=

>> Maybe we can write a brief Internet Draft about wishe= s about security,=C2=A0
Internet, and Intelligent Transportation Systems= .

You mean ethical aspects ?=C2=A0

Kind Regards=C2=A0
Mounira=C2=A0


<= br>
= Le=C2=A0jeu. 22 avr. 2021 =C3=A0=C2=A017:52, Alexandre Petrescu <alexandre.petrescu@gmail.com&g= t; a =C3=A9crit=C2=A0:
In private I was suggested= a few improvements about 'commodity'
browsers, CABForum and federations of CAs; so here is the new wish list:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Wish list for= CAs for vehicular networks

- must be reachable on IPv6, and their website too.
- must be present built-in in commodity web browsers, and open source
=C2=A0 =C2=A0because that guarantees trust built at large scale and helps s= pot the
=C2=A0 =C2=A0bugs quickly for the benefit of all.
- must express their requirements to vehicular networks in terms of
=C2=A0 =C2=A0capabilities of certificates.=C2=A0 For example, a CA may agre= e to sign
=C2=A0 =C2=A0only a number of certs (1000?) per vehicle, but no more.=C2=A0= Or might
=C2=A0 =C2=A0suggest new fields in these X.509 certs that they are ready to= confirm
=C2=A0 =C2=A0(to certify).
- must sign and offer almost for free certificates for vehicular
=C2=A0 =C2=A0networks.=C2=A0 It's not because the car industry makes mu= ch money that a
=C2=A0 =C2=A0lot has to be wasted on artificial costs.=C2=A0 The way for CA= to make
=C2=A0 =C2=A0money should be different than direct charging the vehicular i= ndustry.

- there might be possibilities of considering new web browsers (other
=C2=A0 =C2=A0than the 'commodity').
- maybe a relationship with IOTOPS WG of IETF could be considered.
- the CABForum outside of IETF might be considered (but unreachable on
=C2=A0 =C2=A0IPv6, currently).
- maybe new federations of CAs could be considered, in which the
=C2=A0 =C2=A0vehicular industries might built their own world, but that sho= uld not
=C2=A0 =C2=A0be a path towards seggregating away from the Internet trust.
- must contribute to make Internet better, and not seggregate the
=C2=A0 =C2=A0vehicular networks from the Internet.

Please comment on this wish list.

Maybe we can write a brief Internet Draft about wishes about security,
Internet, and Intelligent Transportation Systems.

Alex


Le 21/04/2021 =C3=A0 19:43, Alexandre Petrescu a =C3=A9crit :
> This is my list of requirements for CAs for vehicular networks: -
> must be reachable on IPv6, and their website too. - must be present > built-in in open source web browsers. - must express their
> requirements to vehicular networks in terms of capabilities of
> certificates.=C2=A0 For example, a CA may agree to sign only a number = of
> certs (1000?) per vehicle, but no more.=C2=A0 Or might suggest new fie= lds
> in these X.509 certs that they are ready to confirm (to certify). - > must sign and offer almost for free certificates for vehicular
> networks.=C2=A0 It's not because the car industry makes much money= that a
> lot has to be wasted on artificial costs.=C2=A0 The way for CA to make=
> money should be different than direct charging the vehicular
> industry. - must contribute to make Internet better, and not
> seggregate the vehicular networks from the Internet.
>
> And this below is our dicussion that helped me frame these
> requirements, and I thank you for the discussion.
>
> Le 20/04/2021 =C3=A0 11:51, Alexandre Petrescu a =C3=A9crit : [...] >
>>> - Scoop@F http://www.scoop.developpement= -durable.gouv.fr/
>>> <http://www.scoop.developpement-durab= le.gouv.fr/> :
>
> This is not reachable on IPv6.
>
>>>
>>>
>>> which is about deploying 3000 cars + 2000 km of roads
>>>
>>>
>>> - InterCor https://intercor-project.eu/
>>> <https://intercor-project.eu/>,
>
> This is not reachable on IPv6.
>
>
>>>
>>> - C-Roads Platform https://www.c-roads.eu/platform.= html
>>> <https://www.c-roads.eu/platform.html> >
> This is not reachable on IPv6.
>
>
>>>
>>>
>>> InterCor and C-Roads are about harmonising C-ITS specification= s
>>> in Europe
>>>
>>>
>>> - INDID
>>> https:= //www.c-roads.eu/pilots/core-members/france/Partner/project/show/indid.html=
>>>
>>>
>>>
>>> <ht= tps://www.c-roads.eu/pilots/core-members/france/Partner/project/show/indid.= html>.
>>>
>>>
>>>
>>>
>>>
>>>
>>> All these projects are using ETSI TS 103 097 certificates, whi= ch
>>> 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
>>>
>
>
> This is reachable on IPv6.
>
>>>
>>>
>>> <https://ec.europa.eu/transport/sites/transport/files/c-its_certific= ate_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?=C2=A0 HAs someone put CAM messages on= IP on
>> a 4G link and signed with 1609.2 certificates?=C2=A0 I think not.<= br> >>
>> 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<= br> >> common browsers.
>>
>>> Yes, in projects dealing with C-ITS security interoperability,= we
>>> use MQTT to exchange C-ITS messages between many countries to<= br> >>> 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=E2=80=A6
>>
>> Yes, but what CA would be put in the server of that log?=C2=A0 Wou= ld
>> 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 i= n
>> 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.=C2=A0 And they are p= aying.
>> I doubt it could work.
>>
>>>
>>>
>>>
>>>>> The reason is because the former is all open source so= ftware
>>>>> and freely accessible standards, whereas=C2=A0 1609.2 = are closed
>>>>> documents and ETSI ITS certificate software is not int= egrated
>>>>> 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>.= I already used it.
>
> This is not reachable on IPv6.=C2=A0 Several people who contributed to=
> IETF also asked github support to put it on IPv6.=C2=A0 There is no an= swer
> since some time now.
>
> I would suggest the person who maintains that java implementation of >=C2=A0 1609.2 to put it on another server that is reachable on IPv6.=C2= =A0 Or
> otherwise to ask too, like the others have, github.com to be on
> IPv6.
>
>
>> Yes, but the spec is paying.=C2=A0 That does inspire seriousness b= ut
>> might inspire risk for the confidence.
>>
>>>
>>>
>>>>> ITS-specific CAs are closed, hard to access and the >>>>> certificate are
>>>
>>> expensive.=C2=A0 hard to access and the certificate are expens= ive.
>>>
>>>
>>> you can get certificates from
>>> https://www.ghsiss.com/v2x-certificates/ >>> <https://www.ghsiss.com/v2x-certificates/<= /a>>
>
> This is not reachable on IPv6.=C2=A0 And ISS CA (Integrated Security <= br> > Services) is not in my browser either.
>
> In comparison, Microsec might provide certificates in bilateral
> agreements that might cost less, or almost 0.=C2=A0 And Microsec is > reachable on IPv, and is in my browser.
>
> There is also the Let's Encrypt CA that is reachable on IPv6.=C2= =A0 I
> think they might offer certificates free of charge too.
>
> These kinds of CAs (Microsec and Let's Encrypt) are good candidate= s
> to whom to propose interoperability for vehicular networks on IPv6. >
> There might be other such CAs?
>
> So, the question is whether Microsec and Let's Encrypt (who are on=
> IPv6 and offer somehow very cheap or almost free certificates), offer<= br> >=C2=A0 compliance with RFC 8902?=C2=A0 If yes, is it with ITS Certifica= tes
> (1609.2) or with X.509 certificates?
>
> Alex
>
>>
>> Thanks for the pointer, I did not know ghsiss.=C2=A0 Are they payi= ng
>> certificates?
>>
>> Recently I worked with Microsec and they might also propose
>> certificates for cheaper (free), if it is for evaluation, or for <= br> >> academia, or similar.=C2=A0 And Microsec CA _is_ present in the >> browsers. But can Microsec sign these 1609.2 certificates and stil= l
>> 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.=C2=A0 That is also a make = kor
>> break condition of use.=C2=A0 It is worth trying.
>>
>> Thanks for the message.
>>
>> Alex
>>
>>>
>>>
>>>
>>>>> In=C2=A0 my personal opinion, it remains good if IPWAV= E provides
>>>>> a guideline on how to secure IP vehicular communicatio= n,
>>>>> 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<= br> >>>>> protocol or standards being used.
>>>
>>>
>>> I=E2=80=99m also interested to work on security interoperabili= ty 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 Petresc= u*
>>> <alexandre.petrescu@gmail.com
>>> <mailto:alexandre.petrescu@gmail.com>> Date: jeu. 15 avr. = 2021 =C3=A0
>>> 22:44 Subject: Re: [ipwave] RFC8902 - TLS with ITS Certificate= s,
>>> EXPERIMENTAL, and the one PKI and one Internet To: J=C3=A9r=C3= =B4me H=C3=A4rri
>>> <Jerome.Haerri@eurecom.fr <mailto:Jerome.Haerri@eurecom.fr>>,
>>> IPWAVE WG <its@ietf.org <mailto:its@ietf.org>>
>>>
>>>
>>>
>>>
>>> Le 15/04/2021 =C3=A0 12:35, J=C3=A9r=C3=B4me H=C3=A4rri a =C3= =A9crit :
>>>> 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 ETS= I 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 n= ot
>>>> fully clear to keep track of any kind of security/data
>>>> integrity...
>>>>
>>>> For that matter, there was one effort from C-ROAD to devel= op
>>>> 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<= br> >>>> moving and exchanging DENM (or else) in backend. But I am = not
>>>> sure of the current status or even if this WI is actually<= br> >>>> active.
>>>>
>>>> Now, I do not fully agree with you with the equivalence of= the
>>>>=C2=A0 internet KPI and ITS KPI. Indeed, the principle is t= he same,
>>>> but in the test you mention, the trust chain is not guaran= teed
>>>> (you edit your own root-CA for the purpose of the tests, b= ut
>>>> for example in one of our cross-border deployment (e.g. DE= -FR),
>>>> this solution does not work, as a German car will not reco= gnize
>>>> the CA from a French root-CA. So, the key issue I see is n= ot
>>>> really (or only) on security but on Trust. The ITS KPI is = one
>>>> option, there might be others, but 'open ssl' stra= tegies still
>>>> face the trust-chain issue.
>>>
>>> J=C3=A9r=C3=B4me,
>>>
>>> I agree with you.
>>>
>>> In the discussion above I think you meant 'PKI' throug= hout
>>> (Public Key Infrastructure), and not 'KPI' (Key Perfor= mance
>>> Indicator).
>>>
>>> That said, the question you formulate about how a car-to-serve= r
>>> MQTT interaction on IP would be authenticated by certificates<= br> >>> 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=C3=A9r=C3=B4me
>>>>
>>>> -----Original Message----- From: its <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>> Subject:
>>>> [ipwave] RFC8902
>>> - TLS with ITS
>>>> Certificates, EXPERIMENTAL, and the one PKI and one Intern= et
>>>>
>>>> Hi, IPWAVErs,
>>>>
>>>> A colleague pointed me to this recently issued RFC 8902 ab= out
>>>> 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 discrep= ancy
>>>>=C2=A0 between what is PKI in the Internet and what is the = closed PKI
>>>> for ITS.=C2=A0 That is a discrepancy that exists for a lon= g time,
>>>> and I must share that - IMHO - I am surprised that the IET= F
>>>> 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<= br> >>>> cellular links like 4G. They work fine.=C2=A0 The CA is a = local CA
>>>> (not a commercial CA), but the concept _is_ compatible wit= h
>>>> normal CAs.=C2=A0 These dont use the ETSI ITS-specific cer= tificates,
>>>> neither the 1609.2 certificates.
>>>>
>>>> I think there are more such trial deployments using local = (but
>>>>=C2=A0 standard, openssl PKIs and certificates) than there = are
>>>> trials using ETSI ITS certificates or 1609.2 certificates.= =C2=A0 The
>>>> reason is because the former is all open source software a= nd
>>>> freely accessible standards, whereas 1609.2 are closed
>>>> documents and ETSI ITS certificate software is not integra= ted
>>>> in mainline software like openssl.
>>>>
>>>> There are many easily accessible CAs (Certificate Authorit= ies)
>>>> that are integrated in the Internet and in main web browse= rs,
>>>> whereas the ITS-specific CAs are closed, hard to access an= d
>>>> the certificate are expensive.=C2=A0 Many strong oppinions= maintain
>>>> that it should stay that way: cars PKI different than Inte= rnet
>>>> PKI.
>>>>
>>>> There should be one Internet, and that means one trust, an= d
>>>> 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?=C2=A0 Maybe I miss >>>> something...
>>>>
>>>> Alex
>>>>
>>>> _______________________________________________ its mailin= g
>>>> list its= @ietf.org <mailto:= its@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/its =
>>> <https://www.ietf.org/mailman/listinfo/its= >
>>>>
>>>> _______________________________________________ its mailin= g
>>>> list its= @ietf.org <mailto:= its@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/its =
>>> <https://www.ietf.org/mailman/listinfo/its= >
>>>>
>>>
>>> _______________________________________________ its mailing li= st
>>>=C2=A0 its@ie= tf.org <mailto:its= @ietf.org>
>>> https://www.ietf.org/mailman/listinfo/its =
>>> <https://www.ietf.org/mailman/listinfo/its= >
>>>
>>>
>>> _______________________________________________ its mailing li= st
>>>=C2=A0 its@ie= tf.org https://www.ietf.org/mailman/listinfo/its >>>
>>
>> _______________________________________________ its mailing list <= br> >> its@ietf.org= https://www.ietf.org/mailman/listinfo/its
>
> _______________________________________________ its mailing list
> its@ietf.org https://www.ietf.org/mailman/listinfo/its

_______________________________________________
its mailing list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its
--00000000000063397d05c0930abe-- From nobody Fri Apr 23 03:58:27 2021 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B10A3A1875 for ; Fri, 23 Apr 2021 03:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.667 X-Spam-Level: X-Spam-Status: No, score=0.667 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] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FshMGl0roLvg for ; Fri, 23 Apr 2021 03:58:22 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C70263A1876 for ; Fri, 23 Apr 2021 03:58:21 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 13NAwHVu005828; Fri, 23 Apr 2021 12:58:17 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 259582066FE; Fri, 23 Apr 2021 12:58:17 +0200 (CEST) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 17D932042FD; Fri, 23 Apr 2021 12:58:17 +0200 (CEST) Received: from [10.14.5.236] ([10.14.5.236]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 13NAwF2d009833; Fri, 23 Apr 2021 12:58:15 +0200 To: Mounira MSAHLI , its@ietf.org References: <01d601d731e3$140e2ed0$3c2a8c70$@eurecom.fr> <0600020f-b6ca-4d6d-2499-817586bc3548@gmail.com> <19dce5f5-8dca-55c2-4d46-bb83046562ab@gmail.com> From: Alexandre Petrescu Message-ID: Date: Fri, 23 Apr 2021 12:58:15 +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-BeenThere: its@ietf.org 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: Fri, 23 Apr 2021 10:58:27 -0000 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/ > > : > > >>> 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 > > > 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/ > >> > : >> >> >> which is about deploying 3000 cars + 2000 km of roads >> >> >> - InterCor https://intercor-project.eu/ > >> >, >> >> - C-Roads Platform 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 > > > > > > > > >> >> > > > > > > > > >. >> >> >> >> >> 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 > > > > > > > > >> >> > > > > > > > > > >> >> >> >> 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 > >> >. 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/ > >> > > > 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* >> > >> >> 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 >> >>, IPWAVE WG >> >> >> >> >> >> >> 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 >> >> > 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@ietf.org > >> https://www.ietf.org/mailman/listinfo/its > >> > >>> >>> _______________________________________________ its mailing > list >>> its@ietf.org > >> https://www.ietf.org/mailman/listinfo/its > >> > >>> >> >> _______________________________________________ its mailing list >> its@ietf.org > >> https://www.ietf.org/mailman/listinfo/its > >> > >> >> >> _______________________________________________ its mailing list >> its@ietf.org > https://www.ietf.org/mailman/listinfo/its > >> > > _______________________________________________ its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > From nobody Fri Apr 23 04:01:27 2021 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23EA83A0CFB for ; Fri, 23 Apr 2021 04:01:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.667 X-Spam-Level: X-Spam-Status: No, score=0.667 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] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mgOjhtkkmwXL for ; Fri, 23 Apr 2021 04:01:21 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5097C3A1895 for ; Fri, 23 Apr 2021 04:01:20 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 13NB1H2q016765; Fri, 23 Apr 2021 13:01:17 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id D29372066DC; Fri, 23 Apr 2021 13:01:17 +0200 (CEST) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id C4B152043E2; Fri, 23 Apr 2021 13:01:17 +0200 (CEST) Received: from [10.14.5.236] ([10.14.5.236]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 13NB1FL5011210; Fri, 23 Apr 2021 13:01:15 +0200 To: Mounira MSAHLI , its@ietf.org References: <01d601d731e3$140e2ed0$3c2a8c70$@eurecom.fr> <0600020f-b6ca-4d6d-2499-817586bc3548@gmail.com> <19dce5f5-8dca-55c2-4d46-bb83046562ab@gmail.com> From: Alexandre Petrescu Message-ID: Date: Fri, 23 Apr 2021 13:01:15 +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-BeenThere: its@ietf.org 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: Fri, 23 Apr 2021 11:01:26 -0000 Le 22/04/2021 à 19:16, Mounira MSAHLI a écrit : > > But how you can sign with a certificate retrieved from the browser > without the private key ? Sorry, I may need to clarify: the CA built-in in the browser might serve only to verify the the CAM messages are signed in properly; they are not used to sign CAM messages. In order to sign the CAM messages, the PC would need the certificates that the CA provided earlier (these 'almost free' certificates Microsec, or another, might provide). These have a prive key that the PC owner generates. I am not talking about the private key of the CA. Maybe I am not clear enough... Alex > > Regards > Mounira > > Le jeu. 22 avr. 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). > > > > >> 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 > > > > >> 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 case of TLS Client Using the ITS Certificate and TLS Server > Uses the X.509 Certificate is already covered by the RFC 8902. > > > >> 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: > >   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. > > > >> And Microsec CA _is_ present in the browsers > > > You mean the certificate authority. You want to sign CAM with > certificate authority ? > > > I did not get the point could you clarify more please. > > > > >> 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 ? > > Scoop + Intercor projects are already finished in December 2019. > > > > 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. > > > > Best Regards > > Mounira > > > Le mar. 20 avr. 2021 à 11:51, Alexandre Petrescu > > 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/ > > > > : > > > > > > which is about deploying 3000 cars + 2000 km of roads > > > > > > - InterCor https://intercor-project.eu/ > > > >, > > > > - C-Roads Platform 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 > > > > > > >. > > > > > > > > > > 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 > > > > > > > > > > > > > > > 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 > > > >. 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/ > > > > > > 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* > > > >> > > 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 > > >>, IPWAVE WG > > >> > > > > > > > > > > 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 > > > >> 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@ietf.org > > > https://www.ietf.org/mailman/listinfo/its > > > > > >> > >> _______________________________________________ its > mailing list > >> its@ietf.org > > > https://www.ietf.org/mailman/listinfo/its > > > > > >> > > > > _______________________________________________ its > mailing list > > its@ietf.org > > > https://www.ietf.org/mailman/listinfo/its > > > > > > > > > > _______________________________________________ its > mailing list > > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > From nobody Fri Apr 23 04:14:19 2021 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 147E53A1901 for ; Fri, 23 Apr 2021 04:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.667 X-Spam-Level: X-Spam-Status: No, score=0.667 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] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CNBbin67R5rC for ; Fri, 23 Apr 2021 04:14:13 -0700 (PDT) Received: from smtp2-g21.free.fr (smtp2-g21.free.fr [IPv6:2a01:e0c:1:1599::11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FE303A1900 for ; Fri, 23 Apr 2021 04:14:13 -0700 (PDT) Received: from [IPv6:2a01:e0a:937:bc30::c8b2:2e1d] (unknown [IPv6:2a01:e0a:937:bc30::c8b2:2e1d]) by smtp2-g21.free.fr (Postfix) with ESMTP id 212C12003C1; Fri, 23 Apr 2021 13:14:06 +0200 (CEST) To: Mounira MSAHLI Cc: its@ietf.org References: <01d601d731e3$140e2ed0$3c2a8c70$@eurecom.fr> <0600020f-b6ca-4d6d-2499-817586bc3548@gmail.com> <19dce5f5-8dca-55c2-4d46-bb83046562ab@gmail.com> <1ec103fe-7a50-cb2c-0763-30cc6362bf13@gmail.com> From: Alexandre Petrescu Message-ID: Date: Fri, 23 Apr 2021 13:14:06 +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] wish list for CAs for vehicular networks X-BeenThere: its@ietf.org 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: Fri, 23 Apr 2021 11:14:18 -0000 Le 22/04/2021 à 19:30, Mounira MSAHLI a écrit : > >>> - must express their requirements to vehicular networks in terms >>> of > capabilities of certificates. For example, a CA may agree to sign > only a number of certs (1000?) per vehicle, but no more. Or might > suggest new fields in these X.509 certs that they are ready to > confirm (to certify). > > I think the number of used pseudonym certificates depends on the > strategy change of pseudonyms implemented in C-ITS station to avoid > tracking and to ensure privacy. I agree, it might be so. It should be the CA provider who could express that requirement. If we can invite a CA provider to express their requirements, then there could be advancement. > >>> - must sign and offer almost for free certificates for vehicular > networks. It's not because the car industry makes much money that a > lot has to be wasted on artificial costs. The way for CA to make > money should be different than direct charging the vehicular > industry. > > The EU commission is providing a PKI for member states who are not > deploying C-ITS PKI, I think for free. I dont know which precisely PKI is one referring to? In my mind, and I might be not right, a PKI is actually the set of CAs that are present built-in in web browsers. No more, no less. In that sense, the EU commission might not be able to provide all these CAs... It's the CAs themselves that provide it. Let me speculate on what you might be referring to when saying that the COmmission might be providing a PKI for member states. I suspect (not sure) that one refers to https://cpoc.jrc.ec.europa.eu/ This website is not reachable on IPv6. That is already a huge problem to surpass. When that is done, one can talk in more detail about it. For my part, I once looked at that site on IPv4, and I found files with ".oer" extension, presumably certificates. I never saw that extension before, so I asked the website contacts about that format? I received no answer. I did not push further. I think either they live in their own world seggregated, or I might be myself misunderstanding so many things (and hence live in my own world :-) >>> Maybe we can write a brief Internet Draft about wishes about >>> security, Internet, and Intelligent Transportation Systems. > > You mean ethical aspects ? I meant to say to maybe write an Internet Draft about security and ITS. It might include ethical aspects, but not sure which ones? What do you think about an Internet Draft? Maybe one saw the message from chairmanship that currently there is little work ongoing, and maybe a shutdown of the group is considered. Alex > > Kind Regards Mounira > > > > Le jeu. 22 avr. 2021 à 17:52, Alexandre Petrescu > > > a écrit : > > In private I was suggested a few improvements about 'commodity' > browsers, CABForum and federations of CAs; so here is the new wish > list: > > Wish list for CAs for vehicular networks > > - must be reachable on IPv6, and their website too. - must be > present built-in in commodity web browsers, and open source because > that guarantees trust built at large scale and helps spot the bugs > quickly for the benefit of all. - must express their requirements to > vehicular networks in terms of capabilities of certificates. For > example, a CA may agree to sign only a number of certs (1000?) per > vehicle, but no more. Or might suggest new fields in these X.509 > certs that they are ready to confirm (to certify). - must sign and > offer almost for free certificates for vehicular networks. It's not > because the car industry makes much money that a lot has to be > wasted on artificial costs. The way for CA to make money should be > different than direct charging the vehicular industry. > > - there might be possibilities of considering new web browsers (other > than the 'commodity'). - maybe a relationship with IOTOPS WG of IETF > could be considered. - the CABForum outside of IETF might be > considered (but unreachable on IPv6, currently). - maybe new > federations of CAs could be considered, in which the vehicular > industries might built their own world, but that should not be a > path towards seggregating away from the Internet trust. > > - must contribute to make Internet better, and not seggregate the > vehicular networks from the Internet. > > Please comment on this wish list. > > Maybe we can write a brief Internet Draft about wishes about > security, Internet, and Intelligent Transportation Systems. > > Alex > > > Le 21/04/2021 à 19:43, Alexandre Petrescu a écrit : >> This is my list of requirements for CAs for vehicular networks: - >> must be reachable on IPv6, and their website too. - must be present >> built-in in open source web browsers. - must express their >> requirements to vehicular networks in terms of capabilities of >> certificates. For example, a CA may agree to sign only a number of >> certs (1000?) per vehicle, but no more. Or might suggest new >> fields in these X.509 certs that they are ready to confirm (to >> certify). - must sign and offer almost for free certificates for >> vehicular networks. It's not because the car industry makes much >> money that a lot has to be wasted on artificial costs. The way >> for CA to make money should be different than direct charging the >> vehicular industry. - must contribute to make Internet better, and >> not seggregate the vehicular networks from the Internet. >> >> And this below is our dicussion that helped me frame these >> requirements, and I thank you for the discussion. >> >> Le 20/04/2021 à 11:51, Alexandre Petrescu a écrit : [...] >> >>>> - Scoop@F http://www.scoop.developpement-durable.gouv.fr/ > >>>> > : >> >> This is not reachable on IPv6. >> >>>> >>>> >>>> which is about deploying 3000 cars + 2000 km of roads >>>> >>>> >>>> - InterCor https://intercor-project.eu/ > >>>> >, >> >> This is not reachable on IPv6. >> >> >>>> >>>> - C-Roads Platform https://www.c-roads.eu/platform.html > >>>> > >> >> This is not reachable on IPv6. >> >> >>>> >>>> >>>> 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 > > > >>>> >>>> >>>> >>>> > > > >. >>>> >>>> >>>> >>>> >>>> >>>> >>>> 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 > > > >>>> >> >> >> This is reachable on IPv6. >> >>>> >>>> >>>> > > > > >>>> >>>> >>>> >>>> >>>> >>>> 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 > >>>> >. I already used it. >> >> This is not reachable on IPv6. Several people who contributed to >> IETF also asked github support to put it on IPv6. There is no >> answer since some time now. >> >> I would suggest the person who maintains that java implementation >> of 1609.2 to put it on another server that is reachable on IPv6. Or >> otherwise to ask too, like the others have, github.com > to be on >> IPv6. >> >> >>> 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/ > >>>> > >> >> This is not reachable on IPv6. And ISS CA (Integrated Security >> Services) is not in my browser either. >> >> In comparison, Microsec might provide certificates in bilateral >> agreements that might cost less, or almost 0. And Microsec is >> reachable on IPv, and is in my browser. >> >> There is also the Let's Encrypt CA that is reachable on IPv6. I >> think they might offer certificates free of charge too. >> >> These kinds of CAs (Microsec and Let's Encrypt) are good candidates >> to whom to propose interoperability for vehicular networks on >> IPv6. >> >> There might be other such CAs? >> >> So, the question is whether Microsec and Let's Encrypt (who are on >> IPv6 and offer somehow very cheap or almost free certificates), >> offer compliance with RFC 8902? If yes, is it with ITS >> Certificates (1609.2) or with X.509 certificates? >> >> Alex >> >>> >>> 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* >>> >>>> >> 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 >>> > >>, >>>> IPWAVE WG > >> >>>> >>>> >>>> >>>> >>>> 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 >>>> >> >>>> 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@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/its > >>>> > >>>>> >>>>> _______________________________________________ its mailing >>>>> list its@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/its > >>>> > >>>>> >>>> >>>> _______________________________________________ its mailing >>>> list its@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/its > >>>> > >>>> >>>> >>>> _______________________________________________ its mailing >>>> list its@ietf.org > https://www.ietf.org/mailman/listinfo/its > >>>> >>> >>> _______________________________________________ its mailing list >>> its@ietf.org > https://www.ietf.org/mailman/listinfo/its > >> >> _______________________________________________ its mailing list >> its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > > _______________________________________________ its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > From nobody Fri Apr 23 04:30:36 2021 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A8AD3A19E7 for ; Fri, 23 Apr 2021 04:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.633 X-Spam-Level: X-Spam-Status: No, score=-1.633 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] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JFusudTJXKDT for ; Fri, 23 Apr 2021 04:30:24 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 430133A19CC for ; Fri, 23 Apr 2021 04:30:23 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 13NBUKWn012514; Fri, 23 Apr 2021 13:30:20 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 905BE206728; Fri, 23 Apr 2021 13:30:20 +0200 (CEST) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 846CA20178B; Fri, 23 Apr 2021 13:30:20 +0200 (CEST) Received: from [10.14.5.64] ([10.14.5.64]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 13NBUKUD021684; Fri, 23 Apr 2021 13:30:20 +0200 To: Mounira MSAHLI , its@ietf.org References: <01d601d731e3$140e2ed0$3c2a8c70$@eurecom.fr> <0600020f-b6ca-4d6d-2499-817586bc3548@gmail.com> <19dce5f5-8dca-55c2-4d46-bb83046562ab@gmail.com> From: Alexandre Petrescu Message-ID: <9ac5851c-ab4c-5876-5138-3a93b0b5a8d5@gmail.com> Date: Fri, 23 Apr 2021 13:30:20 +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: 7bit Archived-At: Subject: Re: [ipwave] RFC8902 - TLS with ITS Certificates, EXPERIMENTAL, and the one PKI and one Internet X-BeenThere: its@ietf.org 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: Fri, 23 Apr 2021 11:30:35 -0000 [...] > You mean the certificate authority. You want to sign CAM with > certificate authority ? Sorry, error of saying. I did not mean the CA to sign the CAM. I mean the CA signs the certs it gives me, and I sign the CAM with these certs. The receiver verifies using the CA they already have in built-in in their browsers. (in some OS like Windows, there is also another list of built-in CAs, which is coupled tightly with that OS's browser; but that is it: a built-in list of CAs). [...] >>> 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 ? Thanks for the distinction. That is a perfect distinctor to formulate in a wish list, or in a list of requirements: Both the server and the web page of the project should be reachable on IPv6. I am not sure which protocol is used to communicate with the CA, maybe OCSP, maybe others. But these protocols must all be run on IPv6 for a CA that supports vehicular networks. If necessary, they could also be on IPv4. For the web page: for me personally, if a website of a trust provider is available on IPv6 it inspires further trust. But I am also aware that some websites, including Google, have very strange behaviour with respect to security when on IPv6. For example, if I use the SMTP server on IPv6 on Google it some times complains saying this is a new device, and makes additional cumbersome security checks. It is in fact a new protocol that Google knows very well since long time (they promote IPv6 since long time now). These are problems that should not appear in vehicular networks, if addressed well. Alex From nobody Sun Apr 25 03:08:37 2021 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 013553A13B6 for ; Sun, 25 Apr 2021 03:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rx-g36TEEx3V for ; Sun, 25 Apr 2021 03:08:30 -0700 (PDT) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9A293A13B3 for ; Sun, 25 Apr 2021 03:08:29 -0700 (PDT) Received: by mail-qt1-x831.google.com with SMTP id u8so39521319qtq.12 for ; Sun, 25 Apr 2021 03:08:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aQEVcIMhG/W973cMFuhbghLzduM0jiJSIVDBtI6ZL90=; b=LPRDGqCqeYBTXps5g8TRFiP+HldLXM3Zom/rycG5IGU8Ywj+h4TlskT3RRrBdtM6lO 2wk1e2uU4ZE47cu+aAICe5g9I+EFfXLZAV0EDBBC0YV7w6FFs4wRLn1p/woBrtXxsgQ1 fP6ILuZqrRcZaAM5MH18LpAoJE8Fadz8qYVX5uLsv/iafGX+HLkpKJr/e04Tb4Q7Y84O RuutITR5sA9B1zz5p77yPX++8LekgegIZuTykW8L/w6AZmTqwtkFXihB9nx7w4Hztv+K f0fH8YaSuJpLGaOPkMnZ2JXb8xJs+tsvFSuI+9Ky3rO9a9JXzD5ST0gpFxY8l/rUHa62 eH7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aQEVcIMhG/W973cMFuhbghLzduM0jiJSIVDBtI6ZL90=; b=KyLz4yZiFiQIy2QoF2CflkQKVbjRH98TtrMtFlFmuKdU5lc4PmYMuWUfWn7Yqr0+Nd pnUCh0Yp3F4Bf9i7Wh35vlfM8jTmGGGCi4qFcp+loJCTqh50pvzcIs+jEAdhvJi/Ke/t TCTVodv/WQd1OvOMU14Ov9dDwcmZnBJfN7/XyT8exPUxO3h7CvH8WHoRxC4uE7OTRg6P n8bWkbB4ICFnxriQFh6iyB4mFOOnI2l0ZHDTn5c+lG7it5WltsY0BwgPaxLKFxWprPfj spc7/IcGW0H73ep9pHff6kJ235SAkOzSv/gQkiYyKBl1tynwuL8LCQvwAca8qq/1KVS6 3YvA== X-Gm-Message-State: AOAM530QMGVsM3smNZgJIMCbvEziGexYt6oayLQWvbdl70tJ1E3wHQcW YZjOwzMp2LOn4KFNT6QV4EUSXJCn61auaKq95vo= X-Google-Smtp-Source: ABdhPJxDDzWAp9cJMOSpeHFVvJJGIKlSf98RZN6D+I5OOiQRBYWq4oJFfF8gdtTwrVPFcThd/Np6BNFJ8aje+bEyk94= X-Received: by 2002:ac8:604a:: with SMTP id k10mr11974916qtm.276.1619345307737; Sun, 25 Apr 2021 03:08:27 -0700 (PDT) MIME-Version: 1.0 References: <01d601d731e3$140e2ed0$3c2a8c70$@eurecom.fr> <0600020f-b6ca-4d6d-2499-817586bc3548@gmail.com> <19dce5f5-8dca-55c2-4d46-bb83046562ab@gmail.com> In-Reply-To: From: Mounira MSAHLI Date: Sun, 25 Apr 2021 12:08:16 +0200 Message-ID: To: Alexandre Petrescu Cc: its@ietf.org Content-Type: multipart/alternative; boundary="000000000000d61f4005c0c9357d" Archived-At: Subject: Re: [ipwave] RFC8902 - TLS with ITS Certificates, EXPERIMENTAL, and the one PKI and one Internet X-BeenThere: its@ietf.org 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: Sun, 25 Apr 2021 10:08:35 -0000 --000000000000d61f4005c0c9357d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 >> 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 >> 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. It was reviewed by many IETF specialists on TLS and security so it is ready to be tested in deployment project. Mounira Le ven. 23 avr. 2021 =C3=A0 12:58, Alexandre Petrescu < alexandre.petrescu@gmail.com> a =C3=A9crit : > Hi, Mounira, > > Le 22/04/2021 =C3=A0 17:52, Mounira MSAHLI a =C3=A9crit : > > > > > > 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); > > > > =E2=80=A2 ETSI TS 102 940 (ITS-S security (PKI) architecture and applic= ation > > groups); > > > > =E2=80=A2 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/ > > > : > > > > > >>> 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 =C3=A0 11:51, Alexandre Petrescu > > > > > a =C3=A9crit : > > > > Hi, Mounira, > > > > Le 16/04/2021 =C3=A0 14:13, Mounira MSAHLI a =C3=A9crit : > >> > >> Dear all, Dear Russ, Dear Jerome, Dear Alex, > >> > >> > >> > >> I=E2=80=99m 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/ > > > >> > > : > >> > >> > >> which is about deploying 3000 cars + 2000 km of roads > >> > >> > >> - InterCor https://intercor-project.eu/ > > > >> >, > >> > >> - C-Roads Platform 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/in= did.html > > > > > > > > > > > > > > > > > < > https://www.c-roads.eu/pilots/core-members/france/Partner/project/show/in= did.html > > > >> > >> > > < > https://www.c-roads.eu/pilots/core-members/france/Partner/project/show/in= did.html > > > > > > > > > > > > > > > > > < > https://www.c-roads.eu/pilots/core-members/france/Partner/project/show/in= did.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_po= licy_release_1.pdf > > > > > > > > > > > > > > > > > < > https://ec.europa.eu/transport/sites/transport/files/c-its_certificate_po= licy_release_1.pdf > > > >> > >> > > < > https://ec.europa.eu/transport/sites/transport/files/c-its_certificate_po= licy_release_1.pdf > > > > > > > > > > > > > > > > > < > https://ec.europa.eu/transport/sites/transport/files/c-its_certificate_po= licy_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=E2=80=A6 > > > > 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 > > > >> > >. 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/ > > > >> > > > > > > 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=E2=80=99m 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* > >> > > > > >> > >> Date: jeu. 15 avr. 2021 =C3=A0 22:44 Subject: Re: [ipwave] RFC8902 > > - TLS > >> with ITS Certificates, EXPERIMENTAL, and the one PKI and one > >> Internet To: J=C3=A9r=C3=B4me H=C3=A4rri > > >> > >>, IPWAVE WG > > >> >> > >> > >> > >> > >> > >> Le 15/04/2021 =C3=A0 12:35, J=C3=A9r=C3=B4me H=C3=A4rri a =C3=A9crit : > >>> 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=C3=A9r=C3=B4me, > >> > >> 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=C3=A9r=C3=B4me > >>> > >>> -----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@ietf.org > > > >> https://www.ietf.org/mailman/listinfo/its > > > >> > > > >>> > >>> _______________________________________________ its mailing > > list > >>> its@ietf.org > > > >> https://www.ietf.org/mailman/listinfo/its > > > >> > > > >>> > >> > >> _______________________________________________ its mailing list > >> its@ietf.org > > > >> https://www.ietf.org/mailman/listinfo/its > > > >> > > > >> > >> > >> _______________________________________________ its mailing list > >> its@ietf.org > > https://www.ietf.org/mailman/listinfo/its > > > >> > > > > _______________________________________________ its mailing list > > its@ietf.org > > https://www.ietf.org/mailman/listinfo/its > > > > > --000000000000d61f4005c0c9357d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Alex


>> I would like to ask: can one implement ETSI= TS 103 097 completely independently of having >> the 1609.2 document= ?=C2=A0 This is very important for an implementer with low ressources, beca= use the ETSI TS document is free access whereas the 1609.2 is paying.


You can find the= ASN1 structure of IEEE 1609.2=C2=A0 certificate and signature in the annex= of ETSI TS 103 097 v 1.3.1=C2=A0


>> A commodity PC receiving a CAM message in th= e car will never trust it if it arrived via a 4G interface.=C2=A0 If that C= AM 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-e= nd' trust.


If the message is signed with a valid certificate with a valid trust cha= in, we can trust it regardless the transmission channel if it is short rang= e=C2=A0and=C2=A0long range


>> First, I fully disagree with that RFC, but that = is a personal oppinion. It is an EXPERIMENTAL RFC, so I can live with it. I= t has some problems that we can discuss about separately.


You disagree with the form of the document but not th= e content. It was reviewed by many IETF specialists on TLS and security so = it is ready=C2=A0 to be tested in deployment project.=C2=A0

=


Mounira=C2=A0


Le=C2=A0ven. 23 avr. 2021 =C3=A0=C2=A012:58, = Alexandre Petrescu <alexandre.petrescu@gmail.com> a =C3=A9crit=C2=A0:
<= /div>
Hi, Mounira,

Le 22/04/2021 =C3=A0 17:52, Mounira MSAHLI a =C3=A9crit :
>
>
> Hi Alex,
>
>
>>> But there are also other projects funded by the EU in the same=
>>> domain (connected automated mobility with self-driving cars) a= nd
>>>=C2=A0 where more open certificates are being used, with more o= pen
>>> 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?=C2=A0 This is very important f= or
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?=C2=A0 HAs someone put CAM message= s on IP
>>>=C2=A0 on a 4G link and signed with 1609.2 certificates?=C2=A0 = 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.=C2=A0 That browser would need a CA in its built-in list.=C2=A0 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.=C2=A0 The trust on 4G is the Internet trus= t,
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.=C2=A0 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?=C2=A0= 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 >=C2=A0 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
>>>=C2=A0 the browsers to implement these 1609.2 certs.=C2=A0 And = they are
>>> paying.=C2=A0 I doubt it could work.
>
>
> The case of TLS Client Using the ITS Certificate and TLS Server Uses <= br> > 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 f= or
>>> academia, or similar.=C2=A0 And Microsec CA _is_ present in th= e
>>> browsers.=C2=A0 But can Microsec sign these 1609.2 certificate= s and
>>> still not ask me (end=C2=A0 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);
>
> =E2=80=A2 ETSI TS 102 940 (ITS-S security (PKI) architecture and appli= cation
> groups);
>
> =E2=80=A2 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.=C2=A0 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.=C2=A0 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.g= ouv.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.=C2=A0 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.=C2=A0 I heard very good things about their advancements and demonstrations.

> Any way the business model of C-ITS PKI, in all mentioned project is <= br> > SaaS. If you want to get access to this service via IPv6, you can ask<= br> > the PKI.

I think there is indeed a business model for PKIs used for vehicular
networks.=C2=A0 But that business model should approach more the existing <= br> 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&= #39;)
that should be adapted, and not vice-versa.

In this advancement of the business model, the most important criterion is the trust.=C2=A0 Without trust there can be no money made.

One cant build two alternate trusts: one for the Internet, and one for
Internet of cars.=C2=A0 They must be together one trust.

Alex

>
>
>
> Best Regards
>
> Mounira
>
>
> Le mar. 20 avr. 2021 =C3=A0 11:51, Alexandre Petrescu
> <= alexandre.petrescu@gmail.com <mailto:alexandre.petrescu@gmail.com>>=
> a =C3=A9crit :
>
> Hi, Mounira,
>
> Le 16/04/2021 =C3=A0 14:13, Mounira MSAHLI a =C3=A9crit :
>>
>> Dear all, Dear Russ, Dear Jerome, Dear Alex,
>>
>>
>>
>> I=E2=80=99m 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-dur= able.gouv.fr/
> <http://www.scoop.developpement-durable.gouv.= fr/>
>> <http://www.scoop.developpement-durable.g= ouv.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-pr= oject.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>>
>>
>>
>> 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-r= oads.eu/pilots/core-members/france/Partner/project/show/indid.html><= br> >>
>>
> <https://ww= w.c-roads.eu/pilots/core-members/france/Partner/project/show/indid.html=
>
>
>
>
>
>
>
>
<https://www.c-r= oads.eu/pilots/core-members/france/Partner/project/show/indid.html>&= gt;.
>>
>>
>>
>>
>> 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.
>
>>
>>
> http= s://ec.europa.eu/transport/sites/transport/files/c-its_certificate_policy_r= elease_1.pdf
>
>
>
>
>
>
>
>
<https= ://ec.europa.eu/transport/sites/transport/files/c-its_certificate_policy_re= lease_1.pdf>
>>
>>
> <= https://ec.europa.eu/transport/sites/transport/files/c-its_certificate_poli= cy_release_1.pdf
>
>
>
>
>
>
>
>
<https= ://ec.europa.eu/transport/sites/transport/files/c-its_certificate_policy_re= lease_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?=C2=A0 HAs someone put CAM messages on IP = on a
> 4G link and signed with 1609.2 certificates?=C2=A0 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=E2=80=A6
>
> Yes, but what CA would be put in the server of that log?=C2=A0 Would t= hat
>=C2=A0 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 <= br> > experimentation.
>
> But for deployment there would be a need for the existing CAs in the <= br> > browsers to implement these 1609.2 certs.=C2=A0 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=C2=A0 1609.2 are clos= ed
> 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>>. I a= lready used it.
>
> Yes, but the spec is paying.=C2=A0 That does inspire seriousness but > might inspire risk for the confidence.
>
>>
>>
>>>> ITS-specific CAs are closed, hard to access and the
>>>> certificate are
>>
>> expensive.=C2=A0 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/>>= ;
>
> Thanks for the pointer, I did not know ghsiss.=C2=A0 Are they paying <= br> > 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.=C2=A0 And Microsec CA _is_ present in the browse= rs.
>=C2=A0 But can Microsec sign these 1609.2 certificates and still not as= k
> me (end user) to pay for the certificates?
>
> Another thing to consider is whether or not ghsiss (and Microsec for <= br> > that matter) are reachable on IPv6.=C2=A0 That is also a make kor brea= k
> condition of use.=C2=A0 It is worth trying.
>
> Thanks for the message.
>
> Alex
>
>>
>>
>>
>>>> In=C2=A0 my personal opinion, it remains good if IPWAVE pr= ovides 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 seve= ral
>>>> options are on the table and we need to guarantee the trus= t
>>>> chain, even considering different protocol or standards be= ing
>>>> used.
>>
>>
>> I=E2=80=99m also interested to work on security interoperability i= n
> 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* <= br> >> <alexandre.petrescu@gmail.com
> <mailto:alexandre.petrescu@gmail.com>
> <mailto:alexandre.petrescu@gmail.com
> <mailto:alexandre.petrescu@gmail.com>>>
>> Date: jeu. 15 avr. 2021 =C3=A0 22:44 Subject: Re: [ipwave] RFC8902=
> - TLS
>> with ITS Certificates, EXPERIMENTAL, and the one PKI and one
>> Internet To: J=C3=A9r=C3=B4me H=C3=A4rri <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@i= etf.org <mailto:it= s@ietf.org>>>
>>
>>
>>
>>
>> Le 15/04/2021 =C3=A0 12:35, J=C3=A9r=C3=B4me H=C3=A4rri a =C3=A9cr= it :
>>> 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 d= o
>>> 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 <= br> >>> 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 <= br> >>> 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, b= ut
>>> in the test you mention, the trust chain is not guaranteed (yo= u
>>> 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=C3=A9r=C3=B4me,
>>
>> I agree with you.
>>
>> In the discussion above I think you meant 'PKI' throughout=
> (Public
>> Key Infrastructure), and not 'KPI' (Key Performance Indica= tor).
>>
>> 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=C3=A9r=C3=B4me
>>>
>>> -----Original Message----- From: its <its-bounces@ietf.org
> <mailto:i= ts-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@ie= tf.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.=C2=A0 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.=C2=A0 The CA is a local CA (not a commercial C= A), but
>>> the concept _is_ compatible with normal CAs.=C2=A0 These dont = use the
>>> ETSI ITS-specific certificates, neither the 1609.2 certificate= s.
>>>
>>> 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.=C2=A0 The<= br> > 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 softwar= e
>>> 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 th= e
>>> certificate are expensive.=C2=A0 Many strong oppinions maintai= n
> that it
>>> should stay that way: cars PKI different than Internet PKI. >>>
>>> There should be one Internet, and that means one trust, and on= e
>>> 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?=C2=A0 Maybe I miss somet= hing...
>>>
>>> Alex
>>>
>>> _______________________________________________ its mailing > list
>>> its@ietf.org= <mailto:its@ietf.= org> <mailto:it= s@ietf.org
> <mailto:its@ietf.= org>>
>> https://www.ietf.org/mailman/listinfo/its
> <https://www.ietf.org/mailman/listinfo/its><= br> >> <https://www.ietf.org/mailman/listinfo/its<= br> > <https://www.ietf.org/mailman/listinfo/its>&= gt;
>>>
>>> _______________________________________________ its mailing > list
>>> its@ietf.org= <mailto:its@ietf.= org> <mailto:it= s@ietf.org
> <mailto:its@ietf.= org>>
>> https://www.ietf.org/mailman/listinfo/its
> <https://www.ietf.org/mailman/listinfo/its><= br> >> <https://www.ietf.org/mailman/listinfo/its<= br> > <https://www.ietf.org/mailman/listinfo/its>&= gt;
>>>
>>
>> _______________________________________________ its mailing list <= br> >> its@ietf.org= <mailto:its@ietf.org<= /a>> <mailto:its@ie= tf.org
> <mailto:its@ietf.= org>>
>> https://www.ietf.org/mailman/listinfo/its
> <https://www.ietf.org/mailman/listinfo/its><= br> >> <https://www.ietf.org/mailman/listinfo/its<= br> > <https://www.ietf.org/mailman/listinfo/its>&= gt;
>>
>>
>> _______________________________________________ its mailing list <= br> >> its@ietf.org= <mailto:its@ietf.org<= /a>>
> https://www.ietf.org/mailman/listinfo/its
> <https://www.ietf.org/mailman/listinfo/its><= br> >>
>
> _______________________________________________ its mailing list
> its@ietf.org <= ;mailto:its@ietf.org&= gt;
> https://www.ietf.org/mailman/listinfo/its
> <https://www.ietf.org/mailman/listinfo/its><= br> >
--000000000000d61f4005c0c9357d-- From nobody Sun Apr 25 03:20:08 2021 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50F973A146A for ; Sun, 25 Apr 2021 03:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ac5MkdxXUFpz for ; Sun, 25 Apr 2021 03:20:01 -0700 (PDT) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A137F3A1458 for ; Sun, 25 Apr 2021 03:20:01 -0700 (PDT) Received: by mail-qt1-x82a.google.com with SMTP id a18so15827557qtj.10 for ; Sun, 25 Apr 2021 03:20:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=F/oeV8piQ7s3fNVhLkTtghly3tDa5fS9JU7bioeQj4o=; b=Vzy8fXKcCaBu5/4sRKvODO49v4n+ksaKk3cexsYXRUeN4lBbzsSujcWhHT981rRwMo A5wdpaTmh7QgZjg1FqhgFfJhskj7/ynIUoiHt+kyJ5HBZ8RmIK+/uDdQ580MFlJ5eoq+ JWHBZZ0Kb5rxxLhoUX1aeg0J5JxEzFtRzwSNvYSltC/JWIrfpcR7ilvKFEtzO9mhVJVx zjVYUd+zburDyp2HmUvcjAq6FbZARVqZtgQwdToAn2SF8Hwap98eFoJ+HHlYb4gwbtyg +gkQxZZWxWINt49Q2Yw/GgNMfWzCu5pyzIMiTrKXoz3DvGew9pSbBwA693DCIJQVeMLY BJaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=F/oeV8piQ7s3fNVhLkTtghly3tDa5fS9JU7bioeQj4o=; b=m/lSBzEFy0y1Eq5hmgOf0kUq80XI+AubLXFYlkes7Gla/qqZ62bhps7n9zd5mStvEI BBAHDuslonvIsdpx9hMPgSx9nFw1+ZgLBdg819v9WYq7C9F0Tw2Kv5QvgN5SwpRf/hcG RHhl9asED+vVZo8M4c6iowNjeU5eE8Ad1DYmj0IXx0gncU1QyOnIiWkVZ70SMr6z+EO0 23l2ZZJ5MwFJ1uskdmtxBzQv+B1uiuofEnMqesNcn1peXCy5H3s8jV7x7KY5Ed5BFMih oUVnA/Duv0ltPBjdxMH66uq0bzMgpUCONFXxH+pxOFfyuyuUI+fL4irTt5b46S5IILRA Rrjw== X-Gm-Message-State: AOAM530hE1IpDn1NdsxbDd9RrFgrBWJAoH3e1ZsKQSghvTuQpn/V4wvw AUeCpLyYJ2ZAd9jR8llM5u70W/muLbTGB4k3I/M= X-Google-Smtp-Source: ABdhPJxhD3QCEeKel1pvFZhJMq9UOLGUAIE4p9uMsp2vn+k172VLtHPjbxa+bSC3Tlgm5IKAyd72nUILDllVTM5PbNo= X-Received: by 2002:ac8:5c14:: with SMTP id i20mr11985742qti.175.1619345999506; Sun, 25 Apr 2021 03:19:59 -0700 (PDT) MIME-Version: 1.0 References: <01d601d731e3$140e2ed0$3c2a8c70$@eurecom.fr> <0600020f-b6ca-4d6d-2499-817586bc3548@gmail.com> <19dce5f5-8dca-55c2-4d46-bb83046562ab@gmail.com> <1ec103fe-7a50-cb2c-0763-30cc6362bf13@gmail.com> In-Reply-To: From: Mounira MSAHLI Date: Sun, 25 Apr 2021 12:19:48 +0200 Message-ID: To: Alexandre Petrescu Cc: its@ietf.org Content-Type: multipart/alternative; boundary="00000000000011b2ae05c0c95f57" Archived-At: Subject: Re: [ipwave] wish list for CAs for vehicular networks X-BeenThere: its@ietf.org 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: Sun, 25 Apr 2021 10:20:07 -0000 --00000000000011b2ae05c0c95f57 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable >> It should be the CA provider who could express that requirement. I don=E2=80=99t agree with you in this point, it is up to the car manufactu= rer and road operator to specify the security and privacy constraints for the vehicle and to fix the number of pseudonyms needed in the vehicle. BTW, there is an ETSI standard dealing with pseudonym change strategy: https://www.etsi.org/deliver/etsi_tr/103400_103499/103415/01.01.01_60/tr_10= 3415v010101p.pdf In page 27, you can find examples of pseudonym parameters values from C-ITS projects and normative organizations. After the publication of this pre-study, the ec.europa published c-its_certificate_policy-v1.1-track_changes.pdf with recommandation in section 2.7.1: The number of maximum number of parallel ATs which are valid in parallel (i.e. at the same moment in time) for ITS-S shall not be more than 100. PKI is the Public Key Infrastructure >> In that sense, the EU commission might not be able to provide all these >> CAs... It's the CAs themselves that provide it. It is about one PKI for all not 1 PKI/country(without C-ITS PKI). >> I meant to say to maybe write an Internet Draft about security and ITS. >> It might include ethical aspects, but not sure which ones? >> What do you think about an Internet Draft? Yes, it could be interesting to think about an Internet Draft since we have many security open questions. Unfortunately, I don=E2=80=99t have resources= but we could discuss. Mounira Le ven. 23 avr. 2021 =C3=A0 13:14, Alexandre Petrescu < alexandre.petrescu@gmail.com> a =C3=A9crit : > > > Le 22/04/2021 =C3=A0 19:30, Mounira MSAHLI a =C3=A9crit : > > > >>> - must express their requirements to vehicular networks in terms > >>> of > > capabilities of certificates. For example, a CA may agree to sign > > only a number of certs (1000?) per vehicle, but no more. Or might > > suggest new fields in these X.509 certs that they are ready to > > confirm (to certify). > > > > I think the number of used pseudonym certificates depends on the > > strategy change of pseudonyms implemented in C-ITS station to avoid > > tracking and to ensure privacy. > > I agree, it might be so. > > It should be the CA provider who could express that requirement. > > If we can invite a CA provider to express their requirements, then there > could be advancement. > > > > >>> - must sign and offer almost for free certificates for vehicular > > networks. It's not because the car industry makes much money that a > > lot has to be wasted on artificial costs. The way for CA to make > > money should be different than direct charging the vehicular > > industry. > > > > The EU commission is providing a PKI for member states who are not > > deploying C-ITS PKI, I think for free. > > I dont know which precisely PKI is one referring to? > > In my mind, and I might be not right, a PKI is actually the set of CAs > that are present built-in in web browsers. No more, no less. > > In that sense, the EU commission might not be able to provide all these > CAs... It's the CAs themselves that provide it. > > Let me speculate on what you might be referring to when saying that the > COmmission might be providing a PKI for member states. > > I suspect (not sure) that one refers to https://cpoc.jrc.ec.europa.eu/ > This website is not reachable on IPv6. That is already a huge problem > to surpass. When that is done, one can talk in more detail about it. > > For my part, I once looked at that site on IPv4, and I found files with > ".oer" extension, presumably certificates. I never saw that extension > before, so I asked the website contacts about that format? I received > no answer. I did not push further. I think either they live in their > own world seggregated, or I might be myself misunderstanding so many > things (and hence live in my own world :-) > > >>> Maybe we can write a brief Internet Draft about wishes about > >>> security, Internet, and Intelligent Transportation Systems. > > > > You mean ethical aspects ? > > I meant to say to maybe write an Internet Draft about security and ITS. > > It might include ethical aspects, but not sure which ones? > > What do you think about an Internet Draft? > > Maybe one saw the message from chairmanship that currently there is > little work ongoing, and maybe a shutdown of the group is considered. > > Alex > > > > > Kind Regards Mounira > > > > > > > > Le jeu. 22 avr. 2021 =C3=A0 17:52, Alexandre Petrescu > > > > > a =C3=A9crit : > > > > In private I was suggested a few improvements about 'commodity' > > browsers, CABForum and federations of CAs; so here is the new wish > > list: > > > > Wish list for CAs for vehicular networks > > > > - must be reachable on IPv6, and their website too. - must be > > present built-in in commodity web browsers, and open source because > > that guarantees trust built at large scale and helps spot the bugs > > quickly for the benefit of all. - must express their requirements to > > vehicular networks in terms of capabilities of certificates. For > > example, a CA may agree to sign only a number of certs (1000?) per > > vehicle, but no more. Or might suggest new fields in these X.509 > > certs that they are ready to confirm (to certify). - must sign and > > offer almost for free certificates for vehicular networks. It's not > > because the car industry makes much money that a lot has to be > > wasted on artificial costs. The way for CA to make money should be > > different than direct charging the vehicular industry. > > > > - there might be possibilities of considering new web browsers (other > > than the 'commodity'). - maybe a relationship with IOTOPS WG of IETF > > could be considered. - the CABForum outside of IETF might be > > considered (but unreachable on IPv6, currently). - maybe new > > federations of CAs could be considered, in which the vehicular > > industries might built their own world, but that should not be a > > path towards seggregating away from the Internet trust. > > > > - must contribute to make Internet better, and not seggregate the > > vehicular networks from the Internet. > > > > Please comment on this wish list. > > > > Maybe we can write a brief Internet Draft about wishes about > > security, Internet, and Intelligent Transportation Systems. > > > > Alex > > > > > > Le 21/04/2021 =C3=A0 19:43, Alexandre Petrescu a =C3=A9crit : > >> This is my list of requirements for CAs for vehicular networks: - > >> must be reachable on IPv6, and their website too. - must be present > >> built-in in open source web browsers. - must express their > >> requirements to vehicular networks in terms of capabilities of > >> certificates. For example, a CA may agree to sign only a number of > >> certs (1000?) per vehicle, but no more. Or might suggest new > >> fields in these X.509 certs that they are ready to confirm (to > >> certify). - must sign and offer almost for free certificates for > >> vehicular networks. It's not because the car industry makes much > >> money that a lot has to be wasted on artificial costs. The way > >> for CA to make money should be different than direct charging the > >> vehicular industry. - must contribute to make Internet better, and > >> not seggregate the vehicular networks from the Internet. > >> > >> And this below is our dicussion that helped me frame these > >> requirements, and I thank you for the discussion. > >> > >> Le 20/04/2021 =C3=A0 11:51, Alexandre Petrescu a =C3=A9crit : [...] > >> > >>>> - Scoop@F http://www.scoop.developpement-durable.gouv.fr/ > > > >>>> > > : > >> > >> This is not reachable on IPv6. > >> > >>>> > >>>> > >>>> which is about deploying 3000 cars + 2000 km of roads > >>>> > >>>> > >>>> - InterCor https://intercor-project.eu/ > > > >>>> >, > >> > >> This is not reachable on IPv6. > >> > >> > >>>> > >>>> - C-Roads Platform https://www.c-roads.eu/platform.html > > > >>>> > > > >> > >> This is not reachable on IPv6. > >> > >> > >>>> > >>>> > >>>> 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/in= did.html > > > > > > > < > https://www.c-roads.eu/pilots/core-members/france/Partner/project/show/in= did.html > > > >>>> > >>>> > >>>> > >>>> > > < > https://www.c-roads.eu/pilots/core-members/france/Partner/project/show/in= did.html > > > > > > > < > https://www.c-roads.eu/pilots/core-members/france/Partner/project/show/in= did.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_po= licy_release_1.pdf > > > > > > > < > https://ec.europa.eu/transport/sites/transport/files/c-its_certificate_po= licy_release_1.pdf > > > >>>> > >> > >> > >> This is reachable on IPv6. > >> > >>>> > >>>> > >>>> > > < > https://ec.europa.eu/transport/sites/transport/files/c-its_certificate_po= licy_release_1.pdf > > > > > > > < > https://ec.europa.eu/transport/sites/transport/files/c-its_certificate_po= licy_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=E2=80=A6 > >>> > >>> 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 > > > >>>> > >. I already used it. > >> > >> This is not reachable on IPv6. Several people who contributed to > >> IETF also asked github support to put it on IPv6. There is no > >> answer since some time now. > >> > >> I would suggest the person who maintains that java implementation > >> of 1609.2 to put it on another server that is reachable on IPv6. Or > >> otherwise to ask too, like the others have, github.com > > to be on > >> IPv6. > >> > >> > >>> 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/ > > > >>>> > > > >> > >> This is not reachable on IPv6. And ISS CA (Integrated Security > >> Services) is not in my browser either. > >> > >> In comparison, Microsec might provide certificates in bilateral > >> agreements that might cost less, or almost 0. And Microsec is > >> reachable on IPv, and is in my browser. > >> > >> There is also the Let's Encrypt CA that is reachable on IPv6. I > >> think they might offer certificates free of charge too. > >> > >> These kinds of CAs (Microsec and Let's Encrypt) are good candidates > >> to whom to propose interoperability for vehicular networks on > >> IPv6. > >> > >> There might be other such CAs? > >> > >> So, the question is whether Microsec and Let's Encrypt (who are on > >> IPv6 and offer somehow very cheap or almost free certificates), > >> offer compliance with RFC 8902? If yes, is it with ITS > >> Certificates (1609.2) or with X.509 certificates? > >> > >> Alex > >> > >>> > >>> 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=E2=80=99m 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* >>>> > >>>> > >> Date: jeu. 15 avr. 2021 =C3=A0 > >>>> 22:44 Subject: Re: [ipwave] RFC8902 - TLS with ITS > >>>> Certificates, EXPERIMENTAL, and the one PKI and one Internet > >>>> To: J=C3=A9r=C3=B4me H=C3=A4rri >>>> > > > >>, > >>>> IPWAVE WG > > >> > >>>> > >>>> > >>>> > >>>> > >>>> Le 15/04/2021 =C3=A0 12:35, J=C3=A9r=C3=B4me H=C3=A4rri a =C3=A9crit= : > >>>>> 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=C3=A9r=C3=B4me, > >>>> > >>>> 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=C3=A9r=C3=B4me > >>>>> > >>>>> -----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@ietf.org > > > >>>> https://www.ietf.org/mailman/listinfo/its > > > >>>> > > > >>>>> > >>>>> _______________________________________________ its mailing > >>>>> list its@ietf.org > > > >>>> https://www.ietf.org/mailman/listinfo/its > > > >>>> > > > >>>>> > >>>> > >>>> _______________________________________________ its mailing > >>>> list its@ietf.org > > > >>>> https://www.ietf.org/mailman/listinfo/its > > > >>>> > > > >>>> > >>>> > >>>> _______________________________________________ its mailing > >>>> list its@ietf.org > > https://www.ietf.org/mailman/listinfo/its > > > >>>> > >>> > >>> _______________________________________________ its mailing list > >>> its@ietf.org > > https://www.ietf.org/mailman/listinfo/its > > > >> > >> _______________________________________________ its mailing list > >> its@ietf.org > > https://www.ietf.org/mailman/listinfo/its > > > > > > _______________________________________________ its mailing list > > its@ietf.org > > https://www.ietf.org/mailman/listinfo/its > > > > > --00000000000011b2ae05c0c95f57 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=

>> It should be the CA provider who could express tha= t requirement.


I don=E2=80=99t agree with you in this point, it is up to the car= manufacturer and road operator to specify the security and privacy constra= ints for the vehicle and to fix the number of pseudonyms needed in the vehi= cle. BTW, there is an ETSI standard dealing with pseudonym change strategy:= =C2=A0


https://www.etsi.org/deliver/etsi_tr= /103400_103499/103415/01.01.01_60/tr_103415v010101p.pdf


In page 27, you can find =C2=A0examples of pseudonym parameters v= alues from C-ITS projects and normative organizations.=C2=A0


After the publication of this pre-study, the ec.europa published = c-its_certificate_policy-v1.1-track_changes.pdf with recommandation in sect= ion 2.7.1:

The number of maximum number of parallel ATs which are valid in p= arallel (i.e. at the same moment in time) for ITS-S shall not be more than = 100.=C2=A0


PKI is the Public Key Infrastructure=C2= =A0


>> In that sense, the EU commission might not be able to pr= ovide all these

>> CAs... It's the CAs themselves that provide it.


It is about one PKI for all not 1 PKI/country(without C-ITS PKI).= =C2=A0


>> I meant to say to maybe write an Internet Draft about se= curity and ITS.

>> It might include ethical aspects, but not sure which one= s?

>> What do you think about an Internet Draft?


Yes, it could be interesting to think about an Internet Draft sin= ce we have many security open questions. Unfortunately, I don=E2=80=99t hav= e resources but we could discuss.=C2=A0


=

Mounira=C2=A0

=


L= e=C2=A0ven. 23 avr. 2021 =C3=A0=C2=A013:14, Alexandre Petrescu <alexandre.petrescu@gmail.com&g= t; a =C3=A9crit=C2=A0:


Le 22/04/2021 =C3=A0 19:30, Mounira MSAHLI a =C3=A9crit :
>
>>> - must express their requirements to vehicular networks in ter= ms
>>> of
> capabilities of certificates.=C2=A0 For example, a CA may agree to sig= n
> only a number of certs (1000?) per vehicle, but no more.=C2=A0 Or migh= t
> suggest new fields in these X.509 certs that they are ready to
> confirm (to certify).
>
> I think the number of used pseudonym certificates depends on the
> strategy change of pseudonyms implemented in C-ITS station to avoid > tracking and to ensure privacy.

I agree, it might be so.

It should be the CA provider who could express that requirement.

If we can invite a CA provider to express their requirements, then there could be advancement.

>
>>> - must sign and offer almost for free certificates for vehicul= ar
> networks.=C2=A0 It's not because the car industry makes much money= that a
>=C2=A0 lot has to be wasted on artificial costs.=C2=A0 The way for CA t= o make
> money should be different than direct charging the vehicular
> industry.
>
> The EU commission is providing a PKI for member states who are not > deploying C-ITS PKI, I think for free.

I dont know which precisely PKI is one referring to?

In my mind, and I might be not right, a PKI is actually the set of CAs
that are present built-in in web browsers.=C2=A0 No more, no less.

In that sense, the EU commission might not be able to provide all these
CAs... It's the CAs themselves that provide it.

Let me speculate on what you might be referring to when saying that the
COmmission might be providing a PKI for member states.

I suspect (not sure) that one refers to https://cpoc.jrc.ec.europa.eu/=
This website is not reachable on IPv6.=C2=A0 That is already a huge problem=
to surpass.=C2=A0 When that is done, one can talk in more detail about it.<= br>
For my part, I once looked at that site on IPv4, and I found files with
".oer" extension, presumably certificates.=C2=A0 I never saw that= extension
before, so I asked the website contacts about that format?=C2=A0 I received=
no answer.=C2=A0 I did not push further.=C2=A0 I think either they live in = their
own world seggregated, or I might be myself misunderstanding so many
things (and hence live in my own world :-)

>>> Maybe we can write a brief Internet Draft about wishes about <= br> >>> security, Internet, and Intelligent Transportation Systems. >
> You mean ethical aspects ?

I meant to say to maybe write an Internet Draft about security and ITS.

It might include ethical aspects, but not sure which ones?

What do you think about an Internet Draft?

Maybe one saw the message from chairmanship that currently there is
little work ongoing, and maybe a shutdown of the group is considered.

Alex

>
> Kind Regards Mounira
>
>
>
> Le jeu. 22 avr. 2021 =C3=A0 17:52, Alexandre Petrescu
> <= alexandre.petrescu@gmail.com <mailto:alexandre.petrescu@gmail.com>>=
> a =C3=A9crit :
>
> In private I was suggested a few improvements about 'commodity'= ;
> browsers, CABForum and federations of CAs; so here is the new wish > list:
>
> Wish list for CAs for vehicular networks
>
> - must be reachable on IPv6, and their website too. - must be
> present built-in in commodity web browsers, and open source because > that guarantees trust built at large scale and helps spot the bugs
> quickly for the benefit of all. - must express their requirements to <= br> > vehicular networks in terms of capabilities of certificates.=C2=A0 For=
> example, a CA may agree to sign only a number of certs (1000?) per > vehicle, but no more.=C2=A0 Or might suggest new fields in these X.509=
> certs that they are ready to confirm (to certify). - must sign and > offer almost for free certificates for vehicular networks.=C2=A0 It= 9;s not
> because the car industry makes much money that a lot has to be
> wasted on artificial costs.=C2=A0 The way for CA to make money should = be
> different than direct charging the vehicular industry.
>
> - there might be possibilities of considering new web browsers (other<= br> > than the 'commodity'). - maybe a relationship with IOTOPS WG o= f IETF
> could be considered. - the CABForum outside of IETF might be
> considered (but unreachable on IPv6, currently). - maybe new
> federations of CAs could be considered, in which the vehicular
> industries might built their own world, but that should not be a
> path towards seggregating away from the Internet trust.
>
> - must contribute to make Internet better, and not seggregate the
> vehicular networks from the Internet.
>
> Please comment on this wish list.
>
> Maybe we can write a brief Internet Draft about wishes about
> security, Internet, and Intelligent Transportation Systems.
>
> Alex
>
>
> Le 21/04/2021 =C3=A0 19:43, Alexandre Petrescu a =C3=A9crit :
>> This is my list of requirements for CAs for vehicular networks: - =
>> must be reachable on IPv6, and their website too. - must be presen= t
>> built-in in open source web browsers. - must express their
>> requirements to vehicular networks in terms of capabilities of >> certificates.=C2=A0 For example, a CA may agree to sign only a num= ber of
>> certs (1000?) per vehicle, but no more.=C2=A0 Or might suggest new=
>> fields in these X.509 certs that they are ready to confirm (to >> certify). - must sign and offer almost for free certificates for <= br> >> vehicular networks.=C2=A0 It's not because the car industry ma= kes much
>> money that a lot has to be wasted on artificial costs.=C2=A0 The w= ay
>> for CA to make money should be different than direct charging the =
>> vehicular industry. - must contribute to make Internet better, and=
>> not seggregate the vehicular networks from the Internet.
>>
>> And this below is our dicussion that helped me frame these
>> requirements, and I thank you for the discussion.
>>
>> Le 20/04/2021 =C3=A0 11:51, Alexandre Petrescu a =C3=A9crit : [...= ]
>>
>>>> - Scoop@F http://www.scoop.developpe= ment-durable.gouv.fr/
> <http://www.scoop.developpement-durable.gouv.= fr/>
>>>> <http://www.scoop.developpement-d= urable.gouv.fr/
> <http://www.scoop.developpement-durable.gouv.= fr/>> :
>>
>> This is not reachable on IPv6.
>>
>>>>
>>>>
>>>> which is about deploying 3000 cars + 2000 km of roads
>>>>
>>>>
>>>> - InterCor https://intercor-project.eu/
> <https://intercor-project.eu/>
>>>> <https://intercor-project.eu/ <https://int= ercor-project.eu/>>,
>>
>> This is not reachable on IPv6.
>>
>>
>>>>
>>>> - C-Roads Platform https://www.c-roads.eu/platf= orm.html
> <https://www.c-roads.eu/platform.html>
>>>> <https://www.c-roads.eu/platform.html<= br> > <https://www.c-roads.eu/platform.html>>
>>
>> This is not reachable on IPv6.
>>
>>
>>>>
>>>>
>>>> InterCor and C-Roads are about harmonising C-ITS specifica= tions
>>>> in Europe
>>>>
>>>>
>>>> - INDID
>>>>
> https://www.c-= roads.eu/pilots/core-members/france/Partner/project/show/indid.html
>
>
>
<https://www.c-r= oads.eu/pilots/core-members/france/Partner/project/show/indid.html><= br> >>>>
>>>>
>>>>
>>>>
> <https://ww= w.c-roads.eu/pilots/core-members/france/Partner/project/show/indid.html=
>
>
>
<https://www.c-r= oads.eu/pilots/core-members/france/Partner/project/show/indid.html>&= gt;.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> 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) a= nd
>>>=C2=A0 where more open certificates are being used, with more o= pen
>>> source software.
>>>
>>>>
>>>>
> http= s://ec.europa.eu/transport/sites/transport/files/c-its_certificate_policy_r= elease_1.pdf
>
>
>
<https= ://ec.europa.eu/transport/sites/transport/files/c-its_certificate_policy_re= lease_1.pdf>
>>>>
>>
>>
>> This is reachable on IPv6.
>>
>>>>
>>>>
>>>>
> <= https://ec.europa.eu/transport/sites/transport/files/c-its_certificate_poli= cy_release_1.pdf
>
>
>
<https= ://ec.europa.eu/transport/sites/transport/files/c-its_certificate_policy_re= lease_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?=C2=A0 HAs someone put CAM message= s on IP
>>> on a 4G link and signed with 1609.2 certificates?=C2=A0 I thin= k not.
>>>
>>> It would be good if it worked, but it would need the CAs to kn= ow
>>>=C2=A0 these certifiicate formats, and the CAs would need to be= known
>>> in common browsers.
>>>
>>>> Yes, in projects dealing with C-ITS security interoperabil= ity,
>>>> we use MQTT to exchange C-ITS messages between many countr= ies
>>>> to ensure continuity of service when vehicle is crossing <= br> >>>> borders.
>>>
>>> Ok, good to know.
>>>
>>>>
>>>>
>>>> We could also use the RFC for Vehicle-To-Internet simply t= o
>>>> upload log of vehicle for example etc=E2=80=A6
>>>
>>> Yes, but what CA would be put in the server of that log?=C2=A0= Would
>>> that CA be a self-made CA with openssl (or other open source <= br> >>> software), or would it be a widely known CA like the CAs prese= nt
>>> in firefox, for example?
>>>
>>> My guess is that you assume a self-made CAs, and I agree with = it
>>>=C2=A0 for experimentation.
>>>
>>> But for deployment there would be a need for the existing CAs = in
>>>=C2=A0 the browsers to implement these 1609.2 certs.=C2=A0 And = they are
>>> paying. I doubt it could work.
>>>
>>>>
>>>>
>>>>
>>>>>> The reason is because the former is all open sourc= e
>>>>>> software and freely accessible standards, whereas= =C2=A0 1609.2
>>>>>> are closed documents and ETSI ITS certificate soft= ware is
>>>>>> not integrated in mainline software like openssl.<= br> >>>>
>>>>
>>>> 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>>. I a= lready used it.
>>
>> This is not reachable on IPv6.=C2=A0 Several people who contribute= d to
>> IETF also asked github support to put it on IPv6.=C2=A0 There is n= o
>> answer since some time now.
>>
>> I would suggest the person who maintains that java implementation =
>> of 1609.2 to put it on another server that is reachable on IPv6. O= r
>> otherwise to ask too, like the others have, github.com
> <http://github.com> to be on
>> IPv6.
>>
>>
>>> Yes, but the spec is paying.=C2=A0 That does inspire seriousne= ss but
>>> might inspire risk for the confidence.
>>>
>>>>
>>>>
>>>>>> ITS-specific CAs are closed, hard to access and th= e
>>>>>> certificate are
>>>>
>>>> expensive.=C2=A0 hard to access and the certificate are ex= pensive.
>>>>
>>>>
>>>> you can get certificates from
>>>> https://www.ghsiss.com/v2x-certificates/<= /a>
> <https://www.ghsiss.com/v2x-certificates/> >>>> <https://www.ghsiss.com/v2x-certificates= /
> <https://www.ghsiss.com/v2x-certificates/>>= ;
>>
>> This is not reachable on IPv6.=C2=A0 And ISS CA (Integrated Securi= ty
>> Services) is not in my browser either.
>>
>> In comparison, Microsec might provide certificates in bilateral >> agreements that might cost less, or almost 0.=C2=A0 And Microsec i= s
>> reachable on IPv, and is in my browser.
>>
>> There is also the Let's Encrypt CA that is reachable on IPv6.= =C2=A0 I
>> think they might offer certificates free of charge too.
>>
>> These kinds of CAs (Microsec and Let's Encrypt) are good candi= dates
>> to whom to propose interoperability for vehicular networks on
>> IPv6.
>>
>> There might be other such CAs?
>>
>> So, the question is whether Microsec and Let's Encrypt (who ar= e on
>>=C2=A0 IPv6 and offer somehow very cheap or almost free certificate= s),
>> offer compliance with RFC 8902?=C2=A0 If yes, is it with ITS
>> Certificates (1609.2) or with X.509 certificates?
>>
>> Alex
>>
>>>
>>> Thanks for the pointer, I did not know ghsiss.=C2=A0 Are they = paying
>>> certificates?
>>>
>>> Recently I worked with Microsec and they might also propose >>> certificates for cheaper (free), if it is for evaluation, or f= or
>>>=C2=A0 academia, or similar.=C2=A0 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 Micros= ec
>>>=C2=A0 for that matter) are reachable on IPv6.=C2=A0 That is al= so a make kor
>>>=C2=A0 break condition of use.=C2=A0 It is worth trying.
>>>
>>> Thanks for the message.
>>>
>>> Alex
>>>
>>>>
>>>>
>>>>
>>>>>> In=C2=A0 my personal opinion, it remains good if I= PWAVE provides
>>>>>> a guideline on how to secure IP vehicular communic= ation,
>>>>>> including interoperability between systems (althou= gh I have
>>>>>> at that time limited resources to actively contrib= ute to
>>>>>> this), as several options are on the table and we = need to
>>>>>> guarantee the trust chain, even considering differ= ent
>>>>>> protocol or standards being used.
>>>>
>>>>
>>>> I=E2=80=99m also interested to work on security interopera= bility in
>>>> C-ITS and we could add:
>>>>
>>>>
>>>> - Misbehaving in vehicular network
>>>>
>>>> - Revocation management
>>>>
>>>> - Pseudonym management/change to avoid tracking and to ens= ure
>>>> privacy
>>>>
>>>>
>>>> Thank you Russ for your time on this RFC and for your valu= able
>>>>=C2=A0 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>>> Date: jeu. 15 avr. 2021= =C3=A0
>>>> 22:44 Subject: Re: [ipwave] RFC8902 - TLS with ITS
>>>> Certificates, EXPERIMENTAL, and the one PKI and one Intern= et
>>>> To: J=C3=A9r=C3=B4me H=C3=A4rri <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@ie= tf.org>>>
>>>>
>>>>
>>>>
>>>>
>>>> Le 15/04/2021 =C3=A0 12:35, J=C3=A9r=C3=B4me H=C3=A4rri a = =C3=A9crit :
>>>>> Dear Alex,
>>>>>
>>>>> Thanks. Indeed such discrepancies is particularly an i= ssue
>>>>> when it comes to merging wireless and wired (V2I). For=
>>>>> example, you send a DENM over 5G reaching a MEC. It wi= ll
>>>>> remove the ETSI KPI and do something on its own (not f= ully
>>>>> sure what exactly), or if you use MQTT type of interac= tion,
>>>>> 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 d= evelop
>>>>>=C2=A0 something called 'Facilities' PKI, sayin= g that the ITS KPI
>>>>> are at facilities layer and no longer at geonet. The <= br> >>>>> advantage is that at least now, you do not need to rem= ove
>>>>> the KPI when moving and exchanging DENM (or else) in b= ackend.
>>>>> But I am not sure of the current status or even if thi= s WI
>>>>> is actually active.
>>>>>
>>>>> Now, I do not fully agree with you with the equivalenc= e 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 depl= oyment
>>>>> (e.g. DE-FR), this solution does not work, as a German= car
>>>>> will not recognize the CA from a French root-CA. So, t= he key
>>>>> issue I see is not really (or only) on security but on=
>>>>> Trust. The ITS KPI is one option, there might be other= s, but
>>>>> 'open ssl' strategies still face the trust-cha= in issue.
>>>>
>>>> J=C3=A9r=C3=B4me,
>>>>
>>>> I agree with you.
>>>>
>>>> In the discussion above I think you meant 'PKI' th= roughout
>>>> (Public Key Infrastructure), and not 'KPI' (Key Pe= rformance
>>>> Indicator).
>>>>
>>>> That said, the question you formulate about how a car-to-s= erver
>>>> MQTT interaction on IP would be authenticated by certifica= tes
>>>> that are verified by CAs that are absent from normal brows= ers,
>>>> or how the CAs that are present in normal browsers would h= elp
>>>> authenticating CAM messages sent on IP - is a very relevan= t
>>>> question.
>>>>
>>>> Alex
>>>>>
>>>>> Best Regards,
>>>>>
>>>>> J=C3=A9r=C3=B4me
>>>>>
>>>>> -----Original Message----- From: its <its-bounces@ietf.org
> <mailto:i= ts-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@ie= tf.org>>> Subject:
>>>>> [ipwave] RFC8902
>>>> - TLS with ITS
>>>>> Certificates, EXPERIMENTAL, and the one PKI and one In= ternet
>>>>>
>>>>> Hi, IPWAVErs,
>>>>>
>>>>> A colleague pointed me to this recently issued RFC 890= 2 about
>>>>> TLS with ITS Certificates.
>>>>>
>>>>> This RFC is of an EXPERIMENTAL Category.
>>>>>
>>>>> It might be in agreement with other IEEE standards suc= h as
>>>>> 1609.2.
>>>>>
>>>>> But I must say that I think it further deepens the >>>>> discrepancy between what is PKI in the Internet and wh= at is
>>>>> the closed PKI for ITS.=C2=A0 That is a discrepancy th= at exists
>>>>> for a long time, and I must share that - IMHO - I am <= br> >>>>> surprised that the IETF issues an RFC that further pro= motes
>>>>> such a discrepancy.
>>>>>
>>>>> This discrepancy is the following: in a few trials I <= br> >>>>> participated, and some about I heard of, people use no= rmal
>>>>> PKI with openssl and normal certificates in cars, over= IP, on
>>>>> cellular links like 4G. They work fine.=C2=A0 The CA i= s a local CA
>>>>> (not a commercial CA), but the concept _is_ compatible= with
>>>>> normal CAs.=C2=A0 These dont use the ETSI ITS-specific=
>>>>> certificates, neither the 1609.2 certificates.
>>>>>
>>>>> I think there are more such trial deployments using lo= cal
>>>>> (but standard, openssl PKIs and certificates) than the= re are
>>>>>=C2=A0 trials using ETSI ITS certificates or 1609.2 cer= tificates.
>>>>> The reason is because the former is all open source so= ftware
>>>>> and freely accessible standards, whereas 1609.2 are cl= osed
>>>>> documents and ETSI ITS certificate software is not int= egrated
>>>>> in mainline software like openssl.
>>>>>
>>>>> There are many easily accessible CAs (Certificate
>>>>> Authorities) that are integrated in the Internet and i= n main
>>>>> web browsers, whereas the ITS-specific CAs are closed,= hard
>>>>> to access and the certificate are expensive.=C2=A0 Man= y 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; h= ence my
>>>>> comment about this particular RFC.
>>>>>
>>>>> That is my humble oppinion.
>>>>>
>>>>> I would like to hear other oppinions?=C2=A0 Maybe I mi= ss
>>>>> something...
>>>>>
>>>>> Alex
>>>>>
>>>>> _______________________________________________ its ma= iling
>>>>> 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><= br> >>>> <https://www.ietf.org/mailman/listinfo/= its
> <https://www.ietf.org/mailman/listinfo/its>&= gt;
>>>>>
>>>>> _______________________________________________ its ma= iling
>>>>> 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><= br> >>>> <https://www.ietf.org/mailman/listinfo/= its
> <https://www.ietf.org/mailman/listinfo/its>&= gt;
>>>>>
>>>>
>>>> _______________________________________________ its mailin= g
>>>> 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><= br> >>>> <https://www.ietf.org/mailman/listinfo/= its
> <https://www.ietf.org/mailman/listinfo/its>&= gt;
>>>>
>>>>
>>>> _______________________________________________ its mailin= g
>>>> list its= @ietf.org <mailto:= its@ietf.org>
> https://www.ietf.org/mailman/listinfo/its
> <https://www.ietf.org/mailman/listinfo/its><= br> >>>>
>>>
>>> _______________________________________________ its mailing li= st
>>>=C2=A0 its@ie= tf.org <mailto:its= @ietf.org>
> https://www.ietf.org/mailman/listinfo/its
> <https://www.ietf.org/mailman/listinfo/its><= br> >>
>> _______________________________________________ its mailing list <= br> >> its@ietf.org= <mailto:its@ietf.org<= /a>>
> https://www.ietf.org/mailman/listinfo/its
> <https://www.ietf.org/mailman/listinfo/its><= br> >
> _______________________________________________ its mailing list
> its@ietf.org <= ;mailto:its@ietf.org&= gt;
> https://www.ietf.org/mailman/listinfo/its
> <https://www.ietf.org/mailman/listinfo/its><= br> >
--00000000000011b2ae05c0c95f57-- From nobody Mon Apr 26 03:15:03 2021 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 129D33A17A3 for ; Mon, 26 Apr 2021 03:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.668 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pU79CrOV-5sQ for ; Mon, 26 Apr 2021 03:14:56 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1502F3A17A2 for ; Mon, 26 Apr 2021 03:14:55 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 13QAEo6h027962; Mon, 26 Apr 2021 12:14:50 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id EC5C1204017; Mon, 26 Apr 2021 12:14:49 +0200 (CEST) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id DD48320313A; Mon, 26 Apr 2021 12:14:49 +0200 (CEST) Received: from [10.14.5.24] ([10.14.5.24]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 13QAEktU014555; Mon, 26 Apr 2021 12:14:46 +0200 To: Mounira MSAHLI Cc: its@ietf.org References: <01d601d731e3$140e2ed0$3c2a8c70$@eurecom.fr> <0600020f-b6ca-4d6d-2499-817586bc3548@gmail.com> <19dce5f5-8dca-55c2-4d46-bb83046562ab@gmail.com> From: Alexandre Petrescu Message-ID: Date: Mon, 26 Apr 2021 12:14:46 +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-BeenThere: its@ietf.org 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 10:15:01 -0000 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 > > > 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/ > >> >> : >> >> >>>> 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 >> > >> >> 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/ > >> > >>> >> >> : >>> >>> >>> which is about deploying 3000 cars + 2000 km of roads >>> >>> >>> - InterCor https://intercor-project.eu/ > >> > >>> > >>, >>> >>> - C-Roads Platform 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 > > > > >> >> >> >> >> >> >> >> > > > > > >>> >>> >> > > > > >> >> >> >> >> >> >> >> > > > > >>. >>> >>> >>> >>> >>> 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 > > > > >> >> >> >> >> >> >> >> > > > > > >>> >>> >> > > > > >> >> >> >> >> >> >> >> > > > > >> >>> >>> >>> >>> 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 > >> > >>> >> >>. 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/ > >> > >>> >> >> >> >> 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* >>> >> >> > >> >> >>> >>> 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 >> > > >>> >> >> >>>, IPWAVE WG >> > >>> >>> >>> >>> >>> >>> >>> 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 >> > >>> > >>> >> 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@ietf.org > >> >> >>> https://www.ietf.org/mailman/listinfo/its > >> > >>> >> >> >>>> >>>> _______________________________________________ its mailing >> list >>>> its@ietf.org > >> >> >>> https://www.ietf.org/mailman/listinfo/its > >> > >>> >> >> >>>> >>> >>> _______________________________________________ its mailing list >>> its@ietf.org > >> >> >>> https://www.ietf.org/mailman/listinfo/its > >> > >>> >> >> >>> >>> >>> _______________________________________________ its mailing list >>> its@ietf.org > >> https://www.ietf.org/mailman/listinfo/its > >> > >>> >> >> _______________________________________________ its mailing list >> its@ietf.org > >> https://www.ietf.org/mailman/listinfo/its > >> > >> > From nobody Mon Apr 26 03:40:31 2021 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B0933A1975 for ; Mon, 26 Apr 2021 03:40:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.668 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFNUYdSwuRsg for ; Mon, 26 Apr 2021 03:40:25 -0700 (PDT) Received: from smtp2-g21.free.fr (smtp2-g21.free.fr [IPv6:2a01:e0c:1:1599::11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EECCF3A1948 for ; Mon, 26 Apr 2021 03:40:24 -0700 (PDT) Received: from [IPv6:2a01:e0a:937:bc30::c8b2:2e1d] (unknown [IPv6:2a01:e0a:937:bc30::c8b2:2e1d]) by smtp2-g21.free.fr (Postfix) with ESMTP id 676512003FC; Mon, 26 Apr 2021 12:40:16 +0200 (CEST) To: Mounira MSAHLI Cc: its@ietf.org References: <01d601d731e3$140e2ed0$3c2a8c70$@eurecom.fr> <0600020f-b6ca-4d6d-2499-817586bc3548@gmail.com> <19dce5f5-8dca-55c2-4d46-bb83046562ab@gmail.com> <1ec103fe-7a50-cb2c-0763-30cc6362bf13@gmail.com> From: Alexandre Petrescu Message-ID: Date: Mon, 26 Apr 2021 12:40:16 +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] wish list for CAs for vehicular networks X-BeenThere: its@ietf.org 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 10:40:30 -0000 Le 25/04/2021 à 12:19, Mounira MSAHLI a écrit : > >>> It should be the CA provider who could express that requirement. > > > I don’t agree with you in this point, it is up to the car > manufacturer and road operator to specify the security and privacy > constraints for the vehicle and to fix the number of pseudonyms > needed in the vehicle. BTW, there is an ETSI standard dealing with > pseudonym change strategy: > > > https://www.etsi.org/deliver/etsi_tr/103400_103499/103415/01.01.01_60/tr_103415v010101p.pdf Thanks, I have clicked on it. It is indeed reachable from my IPv6-only commodity PC. In the wishlist for CAs for vehicular networks, there should be that their specs should be not only free access, but also mandatorily be present on an IPv6 website, or FTP. > In page 27, you can find examples of pseudonym parameters values > from C-ITS projects and normative organizations. Yes, I looked. It is good for the C-ITS projects and normative organizations that they have their specs into an ETSI document. But I think that CAs also should have their needs expressed. It is the CAs that implement these principles. When they implement it they might come up with feedback that should be taken into account. > After the publication of this pre-study, the ec.europa published > c-its_certificate_policy-v1.1-track_changes.pdf with recommandation > in section 2.7.1: > > The number of maximum number of parallel ATs which are valid in > parallel (i.e. at the same moment in time) for ITS-S shall not be > more than 100. Ok. ec.europa is the European Commission, a form of Executive, or government body. I doubt other governments have something to say about the way the CAs work elsewhere than in the vehicular networks. It is only in vehicular networks that ec.europa (dare I say 'wrongly') believes has something to say in such detail as the lifetime of pseudonyms. I can tell that I noticed in the past several times the gouv.fr (a government in a particular country) trying to become itself a CA for example for when people declare revenues on the web, for tax application. It was more than 10 years ago. It failed. But it resulted in the creation of a specific activity at a trust provider in that country. And that CA is now selling services to gouv.fr as much as they sell trust services to other clients. And that CA is present built-in in browsers and OSs. That is the way it scales. There are many other organizations, some larger than some governments, who do pretend to be CAs, and many people trust themm. But each time it is a seggregated 'limited domain', and the CAs are installed manually in the browsers and in the OSs. > > > PKI is the Public Key Infrastructure > > >>> In that sense, the EU commission might not be able to provide all >>> these > >>> CAs... It's the CAs themselves that provide it. > > > It is about one PKI for all not 1 PKI/country(without C-ITS PKI). It is indeed more than one PKI per country, but it is still just one PKI for that set of countries. It is still a trust for a 'seggregated', 'silo', 'limited domain' part of the larger Internet. >>> I meant to say to maybe write an Internet Draft about security >>> and ITS. > >>> It might include ethical aspects, but not sure which ones? > >>> What do you think about an Internet Draft? > > > Yes, it could be interesting to think about an Internet Draft since > we have many security open questions. Unfortunately, I don’t have > resources but we could discuss. I might try to re-edit the wish list based on our discussion. I included the need for specs availability on IPv6. Can you comment on this wish list? Wish list for CAs for vehicular networks - the CA must be reachable on IPv6, and their website too. - the specs of CAs for vehicular networks must be available on IPv6 (e.g. on an IPv6 website, FTP directory, or GIT shared space). - the specs of CA must be implementable independently of other paying sources such as (some) from IEEE or ISO. For example, the ETSI ITS spec that IMPORTS 1609.2 does not qualify because in the end it is paying. But the X.509 in RFC 5280 does not rely on other paying documents in order to implement (I think?). - the CA must offer OCSP reachability on IPv6. - must be present built-in in commodity web browsers, and open source because that guarantees trust built at large scale and helps spot the bugs quickly for the benefit of all. - must express their requirements to vehicular networks in terms of capabilities of certificates. For example, a CA may agree to sign only a number of certs (1000?) per vehicle, but no more. Or might suggest new fields in these X.509 certs that they are ready to confirm (to certify). - must sign and offer almost for free certificates for vehicular networks. It's not because the car industry makes much money that a lot has to be wasted on artificial costs. The way for CA to make money should be different than direct charging the vehicular industry. - there might be possibilities of considering new web browsers (other than the 'commodity'). - maybe a relationship with IOTOPS WG of IETF could be considered. - the CABForum outside of IETF might be considered (but unreachable on IPv6, currently). - maybe new federations of CAs could be considered, in which the vehicular industries might built their own world, but that should not be a path towards seggregating away from the Internet trust. - must contribute to make Internet better, and not seggregate the vehicular networks from the Internet. Please comment on this wish list. Alex > > > Mounira > > > > Le ven. 23 avr. 2021 à 13:14, Alexandre Petrescu > > > a écrit : > > > > Le 22/04/2021 à 19:30, Mounira MSAHLI a écrit : >> >>>> - must express their requirements to vehicular networks in >>>> terms of >> capabilities of certificates. For example, a CA may agree to sign >> only a number of certs (1000?) per vehicle, but no more. Or might >> suggest new fields in these X.509 certs that they are ready to >> confirm (to certify). >> >> I think the number of used pseudonym certificates depends on the >> strategy change of pseudonyms implemented in C-ITS station to >> avoid tracking and to ensure privacy. > > I agree, it might be so. > > It should be the CA provider who could express that requirement. > > If we can invite a CA provider to express their requirements, then > there could be advancement. > >> >>>> - must sign and offer almost for free certificates for >>>> vehicular >> networks. It's not because the car industry makes much money that >> a lot has to be wasted on artificial costs. The way for CA to >> make money should be different than direct charging the vehicular >> industry. >> >> The EU commission is providing a PKI for member states who are not >> deploying C-ITS PKI, I think for free. > > I dont know which precisely PKI is one referring to? > > In my mind, and I might be not right, a PKI is actually the set of > CAs that are present built-in in web browsers. No more, no less. > > In that sense, the EU commission might not be able to provide all > these CAs... It's the CAs themselves that provide it. > > Let me speculate on what you might be referring to when saying that > the COmmission might be providing a PKI for member states. > > I suspect (not sure) that one refers to > https://cpoc.jrc.ec.europa.eu/ This > website is not reachable on IPv6. That is already a huge problem to > surpass. When that is done, one can talk in more detail about it. > > For my part, I once looked at that site on IPv4, and I found files > with ".oer" extension, presumably certificates. I never saw that > extension before, so I asked the website contacts about that format? > I received no answer. I did not push further. I think either they > live in their own world seggregated, or I might be myself > misunderstanding so many things (and hence live in my own world :-) > >>>> Maybe we can write a brief Internet Draft about wishes about >>>> security, Internet, and Intelligent Transportation Systems. >> >> You mean ethical aspects ? > > I meant to say to maybe write an Internet Draft about security and > ITS. > > It might include ethical aspects, but not sure which ones? > > What do you think about an Internet Draft? > > Maybe one saw the message from chairmanship that currently there is > little work ongoing, and maybe a shutdown of the group is > considered. > > Alex > >> >> Kind Regards Mounira >> >> >> >> Le jeu. 22 avr. 2021 à 17:52, Alexandre Petrescu >> > >> >> a écrit : >> >> In private I was suggested a few improvements about 'commodity' >> browsers, CABForum and federations of CAs; so here is the new wish >> list: >> >> Wish list for CAs for vehicular networks >> >> - must be reachable on IPv6, and their website too. - must be >> present built-in in commodity web browsers, and open source >> because that guarantees trust built at large scale and helps spot >> the bugs quickly for the benefit of all. - must express their >> requirements to vehicular networks in terms of capabilities of >> certificates. For example, a CA may agree to sign only a number of >> certs (1000?) per vehicle, but no more. Or might suggest new >> fields in these X.509 certs that they are ready to confirm (to >> certify). - must sign and offer almost for free certificates for >> vehicular networks. It's not because the car industry makes much >> money that a lot has to be wasted on artificial costs. The way for >> CA to make money should be different than direct charging the >> vehicular industry. >> >> - there might be possibilities of considering new web browsers >> (other than the 'commodity'). - maybe a relationship with IOTOPS WG >> of IETF could be considered. - the CABForum outside of IETF might >> be considered (but unreachable on IPv6, currently). - maybe new >> federations of CAs could be considered, in which the vehicular >> industries might built their own world, but that should not be a >> path towards seggregating away from the Internet trust. >> >> - must contribute to make Internet better, and not seggregate the >> vehicular networks from the Internet. >> >> Please comment on this wish list. >> >> Maybe we can write a brief Internet Draft about wishes about >> security, Internet, and Intelligent Transportation Systems. >> >> Alex >> >> >> Le 21/04/2021 à 19:43, Alexandre Petrescu a écrit : >>> This is my list of requirements for CAs for vehicular networks: >>> - must be reachable on IPv6, and their website too. - must be >>> present built-in in open source web browsers. - must express >>> their requirements to vehicular networks in terms of capabilities >>> of certificates. For example, a CA may agree to sign only a >>> number of certs (1000?) per vehicle, but no more. Or might >>> suggest new fields in these X.509 certs that they are ready to >>> confirm (to certify). - must sign and offer almost for free >>> certificates for vehicular networks. It's not because the car >>> industry makes much money that a lot has to be wasted on >>> artificial costs. The way for CA to make money should be >>> different than direct charging the vehicular industry. - must >>> contribute to make Internet better, and not seggregate the >>> vehicular networks from the Internet. >>> >>> And this below is our dicussion that helped me frame these >>> requirements, and I thank you for the discussion. >>> >>> Le 20/04/2021 à 11:51, Alexandre Petrescu a écrit : [...] >>> >>>>> - Scoop@F http://www.scoop.developpement-durable.gouv.fr/ > >> > >>>>> >> >> : >>> >>> This is not reachable on IPv6. >>> >>>>> >>>>> >>>>> which is about deploying 3000 cars + 2000 km of roads >>>>> >>>>> >>>>> - InterCor https://intercor-project.eu/ > >> > >>>>> > >>, >>> >>> This is not reachable on IPv6. >>> >>> >>>>> >>>>> - C-Roads Platform https://www.c-roads.eu/platform.html > >> > >>>>> >> >> >>> >>> This is not reachable on IPv6. >>> >>> >>>>> >>>>> >>>>> 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 > > >> >> >> > > > >>>>> >>>>> >>>>> >>>>> >> > > >> >> >> > > >>. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> 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 > > >> >> >> > > > >>>>> >>> >>> >>> This is reachable on IPv6. >>> >>>>> >>>>> >>>>> >> > > >> >> >> > > >> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> 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 > >> > >>>>> >> >>. I already used it. >>> >>> This is not reachable on IPv6. Several people who contributed >>> to IETF also asked github support to put it on IPv6. There is >>> no answer since some time now. >>> >>> I would suggest the person who maintains that java >>> implementation of 1609.2 to put it on another server that is >>> reachable on IPv6. Or otherwise to ask too, like the others have, >>> github.com > >> > to be on >>> IPv6. >>> >>> >>>> 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/ > >> > >>>>> >> >> >>> >>> This is not reachable on IPv6. And ISS CA (Integrated Security >>> Services) is not in my browser either. >>> >>> In comparison, Microsec might provide certificates in bilateral >>> agreements that might cost less, or almost 0. And Microsec is >>> reachable on IPv, and is in my browser. >>> >>> There is also the Let's Encrypt CA that is reachable on IPv6. I >>> think they might offer certificates free of charge too. >>> >>> These kinds of CAs (Microsec and Let's Encrypt) are good >>> candidates to whom to propose interoperability for vehicular >>> networks on IPv6. >>> >>> There might be other such CAs? >>> >>> So, the question is whether Microsec and Let's Encrypt (who are >>> on IPv6 and offer somehow very cheap or almost free >>> certificates), offer compliance with RFC 8902? If yes, is it >>> with ITS Certificates (1609.2) or with X.509 certificates? >>> >>> Alex >>> >>>> >>>> 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* >>>>> > >>>>> >> >>> 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 >>>>> > >> >> >>>, >>>>> IPWAVE WG > > >> >>> >>>>> >>>>> >>>>> >>>>> >>>>> 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 >> > >>>>> > >>> >>>>> 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@ietf.org >>>>>> > >> >> >>>>> https://www.ietf.org/mailman/listinfo/its > >> > >>>>> >> >> >>>>>> >>>>>> _______________________________________________ its >>>>>> mailing list its@ietf.org >>>>>> > >> >> >>>>> https://www.ietf.org/mailman/listinfo/its > >> > >>>>> >> >> >>>>>> >>>>> >>>>> _______________________________________________ its mailing >>>>> list its@ietf.org > >> >> >>>>> https://www.ietf.org/mailman/listinfo/its > >> > >>>>> >> >> >>>>> >>>>> >>>>> _______________________________________________ its mailing >>>>> list its@ietf.org > >> https://www.ietf.org/mailman/listinfo/its > >> > >>>>> >>>> >>>> _______________________________________________ its mailing >>>> list its@ietf.org > >> https://www.ietf.org/mailman/listinfo/its > >> > >>> >>> _______________________________________________ its mailing list >>> its@ietf.org > >> https://www.ietf.org/mailman/listinfo/its > >> > >> >> _______________________________________________ its mailing list >> its@ietf.org > >> https://www.ietf.org/mailman/listinfo/its > >> > >> > From nobody Mon Apr 26 06:54:17 2021 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB1753A2072 for ; Mon, 26 Apr 2021 06:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGTSsbHXbBpX for ; Mon, 26 Apr 2021 06:54:12 -0700 (PDT) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6B2F3A2071 for ; Mon, 26 Apr 2021 06:54:12 -0700 (PDT) Received: by mail-qk1-x72a.google.com with SMTP id u20so24316383qku.10 for ; Mon, 26 Apr 2021 06:54:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WvkzVYd44HeEjHoyD2R0gW8/ay9uFZ/PWPq+dqzdcv4=; b=VZf6ncDPtZnRkvnJl9AoIn8YjvzfIJ+MXk7UlayqQQVbtBoUglH+4Vyb2/2K/w/8fP DvBPQC06FmjfIsWHTRdVvfBq8TPlI08x+z0/DAbAA7qjVvxqJF6ua3uGQRtxeEh7BjkN yQA+osdg+YbofuA+SgOwmb0mWNMAqmMdaxm09cbZxFaYAbcGryWmTbFqhmCPRWUarAX8 aaRMRVei0mLxt5mE5ww0IH4yveyA+titUgGyWEm9OHxcnleKqfDW01WbjN59MIEQ5ly9 jsXmbtlv5RXR8JfGNgqWd44FwzYQQyvj7kNYgBYQKwA4XqS6/FSfeZZzfuu8Ydzvyjpp DNHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WvkzVYd44HeEjHoyD2R0gW8/ay9uFZ/PWPq+dqzdcv4=; b=qQqAoJNsyMS78Q1Z/ESeyqTv3q8OOEFWe3rjnO6+3BDN4Q8xOfdn20SFERfhwx+ioE RczF9/UTT8nx0sJf6N5xcrytSIMbLN6Tvs2LfDlwdZrDKgg79yL3dS4P7Gq2oGJtvqK1 bT6WNJJ/cJ1okBPwyjb9C9+VZhMU7O7n7Qw0Xs6MiI9AhUmqHMO9w0kJpZ0RPp04JtKq lA68+qcf0d8FzQBszhJ2g+rzB36dGh2dfbKusMfAD2wNrASVxPyL3ZcJua7R8vo/409y B0GkRs3NnJ/cTrbAeoClyhOkrciet/zagUEj0IxoIjcjnvGgo0xQfN73/FbR9Nm+6ErX 04cQ== X-Gm-Message-State: AOAM531NVxl0bSehPBGqx7HSIpAS4I3MVCGxyPbeg4jOoN//RvAhFrlI p2gn8u+3XCGfGdQnQxeROK6ppdlc3KJ1dc9+I4EfFtsN4qY= X-Google-Smtp-Source: ABdhPJwOIi7PAqAG0indePHRfHA4pd/m5LhM+c8GtZz7Dx8Z7rE4fQ5Sz1yY6gRpMMsg+UHvYIFr8seuwdR7PevOhv8= X-Received: by 2002:a05:620a:1085:: with SMTP id g5mr17686082qkk.332.1619445250679; Mon, 26 Apr 2021 06:54:10 -0700 (PDT) MIME-Version: 1.0 References: <01d601d731e3$140e2ed0$3c2a8c70$@eurecom.fr> <0600020f-b6ca-4d6d-2499-817586bc3548@gmail.com> <19dce5f5-8dca-55c2-4d46-bb83046562ab@gmail.com> <1ec103fe-7a50-cb2c-0763-30cc6362bf13@gmail.com> In-Reply-To: From: Mounira MSAHLI Date: Mon, 26 Apr 2021 15:53:59 +0200 Message-ID: To: Alexandre Petrescu Cc: its@ietf.org Content-Type: multipart/alternative; boundary="000000000000e6652605c0e07a87" Archived-At: Subject: Re: [ipwave] wish list for CAs for vehicular networks X-BeenThere: its@ietf.org 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 13:54:16 -0000 --000000000000e6652605c0e07a87 Content-Type: text/plain; charset="UTF-8" > > Can you comment on this wish list? > > Wish list for CAs for vehicular networks > > >> - the CA must be reachable on IPv6, and their website too. > Could you please mention why not IPv4 ? > - the specs of CAs for vehicular networks must be available on IPv6 > (e.g. on an IPv6 website, FTP directory, or GIT shared space). > You mean certificate policy. I have the same question. You are specifying the IP protocol for the PKI website. I agree that document must be published and available to PKI users but why IPV6 ? - the specs of CA must be implementable independently of other paying > sources such as (some) from IEEE or ISO. For example, the ETSI ITS > spec that IMPORTS 1609.2 does not qualify because in the end it is > paying. But the X.509 in RFC 5280 does not rely on other paying > documents in order to implement (I think?). > William could answer you this question better than me because it was already asked by ETSI. - the CA must offer OCSP reachability on IPv6. > I find that all recommandations are related to the use of IPv6 not really the security or privacy in C-ITS. By analogy with what you are suggesting, I think that you would prefer to use IPv6 for the upload of log and download of updates and all V2I communications not only V2PKI connexion. Mounira --000000000000e6652605c0e07a87 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Can you comment on this wish list?=C2=A0
=C2=A0
Wish list for = CAs for vehicular networks

>> - the CA must be reachabl= e on IPv6, and their website too.
=C2=A0 =C2=A0 =C2=A0= =C2=A0 Could you please mention why not IPv4 ?=C2=A0
=C2=A0
- the specs of CAs for vehicular networks must be availab= le on IPv6
=C2=A0 =C2=A0(e.g. on an IPv6 website, FTP directory, or GIT = shared space).

You mean certificate pol= icy. I have the same question. You are specifying the IP protocol for the P= KI website. I agree that document must be published and available to PKI us= ers but why IPV6 ?=C2=A0

- the specs o= f CA must be implementable independently of other paying
=C2=A0 =C2=A0so= urces such as (some) from IEEE or ISO.=C2=A0 For example, the ETSI ITS
= =C2=A0 =C2=A0spec that IMPORTS 1609.2 does not qualify because in the end i= t is
=C2=A0 =C2=A0paying.=C2=A0 But the X.509 in RFC 5280 does not rely = on other paying
=C2=A0 =C2=A0documents in order to implement (I think?).=

William could answer you this question= better than me because it was already asked by ETSI. =C2=A0

=
- the CA must offer OCSP reachability on IPv6.
=C2=A0
I find that all recommandations are relate= d to the use of IPv6 not really the=C2=A0
security or privacy in = C-ITS. By analogy with what you are suggesting, I think =C2=A0that you woul= d prefer to use IPv6 for the upload of log and download of updates and all = V2I communications not only V2PKI connexion.=C2=A0


Mounira=C2=A0

--000000000000e6652605c0e07a87-- From nobody Mon Apr 26 07:08:14 2021 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA1FA3A20F5 for ; Mon, 26 Apr 2021 07:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GH_6hlnwxHOn for ; Mon, 26 Apr 2021 07:08:10 -0700 (PDT) Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com [IPv6:2607:f8b0:4864:20::f2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 026933A20F4 for ; Mon, 26 Apr 2021 07:08:09 -0700 (PDT) Received: by mail-qv1-xf2b.google.com with SMTP id a30so502892qvb.12 for ; Mon, 26 Apr 2021 07:08:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=mWmkSga5ObI6Co676IR+HMBIJnKBEEsKkLqly7D87/k=; b=Gjmeyj5RR6eaLINZWv5Gm/XAzEIvSyFPnliWTDHBhtjjHvKQT++5MXCcI3Bg403qjN m1hYlHwGupvQLYg4mHp7DATccV5v5KoY2PGhrpKDGBjXYJZYbTME3B/lddJGWwLCiosY aD2Uep31qb0aPT+p9xaZQq29qRhcZKMXfSJEjIJZ+vH8KzrV7TXHD1nEu/Exrha0S7+b nSaAJazAnLdbl1Qp0d4uVYGTknAZ5AL5fiDYnNLocmfdZ0HXBUkMRPIsGBYy1FQA5rQ/ 9wr/midBAv0fiTtt24/K/TNXT3yLnF35Qey9qLm6K/Q7uEOFpbrdx1OdVUaMYb4JM/+8 kaXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=mWmkSga5ObI6Co676IR+HMBIJnKBEEsKkLqly7D87/k=; b=S07Et8zw/VcKPqGLaijqyQgEbzcL8GISAhRhAMEuKeeODOyjqBvV/rcCXam/WDiDcG QDFWMZ9qhcN2Ifq0Y6TezB/jHxQuZvIqQVVpbj20bFnc58a7TyJyTyL42h/8dQ4l0YTi V+uygkQdifwCla/CTVSTOryVb8Z5g1aYwpAn/sj+Gw1pu01Nn36cgE0khffv/6bqd5XW HvODylQNuX0r9qKgZeV2fnVFjtqSLuhA7Vfg3//GKy8mKO0D7oQCd0WIhpg30mBLwHe+ 7XBeoUTrElPhtEQl4d5L+/kIXy5+mOtJdH+iT7mGKETcVbvQJCVuxBc4h2c/A91NTHZt YqqA== X-Gm-Message-State: AOAM530exSYgI0eanQfmIOf3TlW0rg6zOcody+rF7SF1eI1EdLxNBuG8 iiWtG19GVOnqSDLBvu9MgnBG91VcLUxevdyoFfNunWdxxfY= X-Google-Smtp-Source: ABdhPJz5Qypddn2KHOTNTHPw/lj/a3XU+1V/Uoa2YESlSsvUMYr9fuvmXILwVXCTmZrWW8cD5Br3fc0zYKAHH5+V+bw= X-Received: by 2002:a0c:9e0f:: with SMTP id p15mr17706559qve.27.1619446087822; Mon, 26 Apr 2021 07:08:07 -0700 (PDT) MIME-Version: 1.0 References: <01d601d731e3$140e2ed0$3c2a8c70$@eurecom.fr> <0600020f-b6ca-4d6d-2499-817586bc3548@gmail.com> <19dce5f5-8dca-55c2-4d46-bb83046562ab@gmail.com> In-Reply-To: From: Mounira MSAHLI Date: Mon, 26 Apr 2021 16:07:56 +0200 Message-ID: To: Alexandre Petrescu , its@ietf.org Content-Type: multipart/alternative; boundary="000000000000cc343405c0e0ac1c" Archived-At: Subject: Re: [ipwave] RFC8902 - TLS with ITS Certificates, EXPERIMENTAL, and the one PKI and one Internet X-BeenThere: its@ietf.org 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 14:08:13 -0000 --000000000000cc343405c0e0ac1c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable >> 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. In my memory, the RFC was presented by William in IPWAVE GROUP in 2019. But IPWAVE did not host this activity as it was outside the charter as currently written. Although there was a possibility to rewrite the charter, but we had to wait until the two current documents being worked on by IPWAVE had been completed so as not to defocus the group. If your conclusion is that =C2=AB this RFC is not really relevant to ITS", = this is hard to agree with because the large deployment of C-ITS. As mentioned by William before, ITS deployments across the US, Europe and Australia are currently using 1609.2 certificates. Mounira > >> --000000000000cc343405c0e0ac1c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>> If there were a need to discuss that RF= C 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 detail= ed
reviews, as this one has, are useful.=C2=A0 Better have an RFC on the= topic
rather than silence.


In my memory, the RFC = was presented by William in IPWAVE GROUP in 2019. But IPWAVE did not host t= his activity as it was outside the=C2=A0charter=C2=A0as currently written. = Although there was a possibility to rewrite the=C2=A0charter, but we had to= wait until the two current documents being worked on by IPWAVE had been co= mpleted so as not to defocus the group. =C2=A0



If your conclusion is that=C2=A0=C2=AB=C2=A0this = RFC is not really relevant to ITS", this is hard to agree with because= the large deployment of C-ITS. As mentioned by William before,= =C2=A0ITS deployments across the US, Europe and Australia a= re currently using 1609.2 certificates.=C2=A0


Mounira=C2=A0

=

--000000000000cc343405c0e0ac1c-- From nobody Mon Apr 26 07:25:29 2021 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B6D93A2189 for ; Mon, 26 Apr 2021 07:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fIiLFtmv6KvQ for ; Mon, 26 Apr 2021 07:25:23 -0700 (PDT) Received: from esa.hc3962-90.iphmx.com (esa.hc3962-90.iphmx.com [216.71.140.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50F213A2186 for ; Mon, 26 Apr 2021 07:25:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qccesdkim1; t=1619447123; x=1620051923; h=from:to:date:message-id:references:in-reply-to: mime-version:subject; bh=wIzZEkawBwtFax98aLjnKHpCKRk3mllwuC7Usl58qhw=; b=LmrZ/WnmU7RT72regSzKsv7g7n62PECEkCcDcDyvOw7aUbaP4oBSJKCs ElV/FTxBpOHrdgvp7IBdbOMvT+XMKCwmTYsvm1UNYZRHT9D1w43+1H2n4 e6DZsSC7g36df1qN5daAKnu+tWEFajOY1JBAESHXPQYEQyY6fb+2J1neQ U=; IronPort-SDR: GasatlI4ApCI/4tM8kVgpTyD7hBZqVAFqe7NB9uzyfvp3El8K15/WCBAbdfnWKecWubcsk03YZ QgQ3dIYu6fSZN6PkFLbnhXYcWYcPt/9iSPzUOneYBnpS4wOh2KUcd8qWwkJtkh1wdN3EmCsW00 7grttKAs6R2cOpSrFMXvA2oavIgRSMidRRM0ncxtH7aOHEzwdCSmDEk0WBnIXdeijcDBW192Uk 9IlSaP97KhXKiQ0drsHoXgy9I+1miJbZBWNuYAluhC4NWlMTqry0o6+lUmx8UC5n7JHWX/FAGK yYU= X-IronPort-RemoteIP: 104.47.70.106 X-IronPort-MID: 22795 X-IronPort-Reputation: None X-IronPort-Listener: OutgoingMail X-IronPort-SenderGroup: RELAY_O365 X-IronPort-MailFlowPolicy: $RELAYED Thread-Topic: Re: [ipwave] RFC8902 - TLS with ITS Certificates, EXPERIMENTAL, and the one PKI and one Internet Received: from mail-bn7nam10lp2106.outbound.protection.outlook.com (HELO NAM10-BN7-obe.outbound.protection.outlook.com) ([104.47.70.106]) by ob1.hc3962-90.iphmx.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Apr 2021 14:25:20 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iQiOzcgyQ6Okn2BIRyMFlkz8KlHdYSeEABf9XWme3H5p5/ke1DZFoDpp/5caZ18vYfUOkm4dtsC+SVSzEtF2y1OjT9+8U3tV8FGGwZmhSPynUFVKKuVC0ZF1Lsu2DBH9+4YLr2JY6Yefc6IdRS/JDVkn63wCjeLQxT4gnm44HM2R0Sgj3Fa5W7B1BUWkDogMdqffGwXDe/48eMz6Crr9ijHzvFOPZVqZRtDlpM3Wx/D7xbfnhgXVI5HxoNmskINj6YyHxr/HocQlSpk6UUYUVFQKlZZfiuqeWoZ29/Zs3ktwO+aC0e6dMUXzi4Gy23HPTq34lYSSvhxhuz01HRIAMg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wIzZEkawBwtFax98aLjnKHpCKRk3mllwuC7Usl58qhw=; b=HX9Evsn2dBef5T0oeetvH8Ntc7VBQYC9UuRUuPbSmQZaVz7svISvdvu6n8pt9p1/dzEjK6XSmLsAqALN11O5Sqv9k+4YFrVm4q7if3wPWttJY/YKYq5OmeEE8jqJetiBNZnWaNbxywrwq5p7bdbWAlx9503ww6DnghRVcFs4hjDftqdF/Inc+Xw+gvbtr1RHnf9pDSwy6sx8eb66gSObeLaUXKxCmRxDp29jDm+rqaLrvhl3WDNEO/aFSUTZ6yDdqnlxA9zEbEHaj35kPE285cpOVa9n/g8TXIAbepe5gTgAKbZePZc1mTsUcc7lI3qpQ+/12VdbGymAUVtoIDvZvw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=qti.qualcomm.com; dmarc=pass action=none header.from=qti.qualcomm.com; dkim=pass header.d=qti.qualcomm.com; arc=none Received: from MN2PR02MB6591.namprd02.prod.outlook.com (2603:10b6:208:15f::17) by BL0PR02MB6482.namprd02.prod.outlook.com (2603:10b6:208:1ce::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.21; Mon, 26 Apr 2021 14:25:18 +0000 Received: from MN2PR02MB6591.namprd02.prod.outlook.com ([fe80::8178:7533:16e:f843]) by MN2PR02MB6591.namprd02.prod.outlook.com ([fe80::8178:7533:16e:f843%7]) with mapi id 15.20.4065.026; Mon, 26 Apr 2021 14:25:18 +0000 From: William Whyte To: Mounira MSAHLI , Alexandre Petrescu , "its@ietf.org" Thread-Index: AQHXMeMhko1+RkzEsUCq4zk+NPGTeKq2C7cAgAEElRaABiFYgIADifKQgAE/woCAAxayAIAB1UwAgAAEnLA= Date: Mon, 26 Apr 2021 14:25:18 +0000 Message-ID: References: <01d601d731e3$140e2ed0$3c2a8c70$@eurecom.fr> <0600020f-b6ca-4d6d-2499-817586bc3548@gmail.com> <19dce5f5-8dca-55c2-4d46-bb83046562ab@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none; gmail.com; dmarc=none action=none header.from=qti.qualcomm.com; x-originating-ip: [173.48.177.63] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 35c2dc87-907f-4362-b4e0-08d908bf1e2d x-ms-traffictypediagnostic: BL0PR02MB6482: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ehhbZ6IOBay8lOwacJ8TJmLXJqySL+WtarBnOZwRJThjUzsywj/jz//yCA6+3EzaHx/26lGsraQWa0aqaXvbYzNuibXmn1PKbfBJTFKRUa8J2JVHtHv8s/3TrT/1PLZWD6IMk2tKFJHGxip9tpRGzZM6ndBblIpv3W0JrxSsKwGQyYwB1TVitsYdzbphzIKNJvwIss/pBZYUWSc+VaRj4UhdIgcgNkz3qSmji0U+ZYEgDJhu0XP8/OmiE+wjU5k5wRM+cz9jx191p6epEijAG5RaEhGc+xTXWtWWClFNgmWo+FBo1CF9kZDjYt0HS8X/F7D+XG/6sSo4C997+QAmHZmi2sueoSr9pWyBqEjNEC7DpBrbwVRHZ9Bum4lSKHl2XnfCmXRRI4ix7weEPyRQp9Toc95oCr7pcd3FnJtWENEKX/j13cX0nRRwnvJZxTjJ4+27HS9757on22aYsOOSpEarzoYFGdOoYecAr4TM6nI7I8rMgrMahE+kD5qxOHLPOAC2txFSTSlSl0H4WKiAZuCu7jLG+4LK/s+SlrD4vPemBMwbgYeHLUfsfnp2FBWgyKLBKAGemeDpXwrA2ZGVA09K2uvdLE9MFEw/ol0lVI4= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR02MB6591.namprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(346002)(39860400002)(366004)(136003)(396003)(6506007)(5660300002)(52536014)(8936002)(53546011)(8676002)(76116006)(66476007)(66946007)(2906002)(186003)(71200400001)(33656002)(7696005)(86362001)(66556008)(66446008)(64756008)(316002)(110136005)(55016002)(26005)(9686003)(66574015)(38100700002)(478600001)(122000001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?utf-8?B?NnpseVZCSFhpMU9wcnFUdkFuYy9HcTA1eFhIYUFKZW1BeUpZNjkvcm8vdUh3?= =?utf-8?B?YjZKR1dOOTVGbEZ1Ukp5djR5RklZNXplclJ5N3U3WTYxTmNoL2pNdEo5bXlr?= =?utf-8?B?MmhBeGtScjNqMlBJdE5aVUM2WjcveWViWlludjRzSnl1bUNPdDJkbktOQ2th?= =?utf-8?B?L1FFZ09DY1lnNXg3dFVtc0N2Nm1HRXhFbzg2Y0ordndLUldHclJOT2FwNHQx?= =?utf-8?B?c0RxbHJOWlBaK2FmSjRpZjZSL09Da3Zib3F5ZzBNajhHb3NVYkRYVWxNMHc2?= =?utf-8?B?TzJzTzZtNTB0dkVUR0xWOEl1V2lQclV4ZERibFdxai9SWXRYY3BZb1FUTkFX?= =?utf-8?B?bU1LVzhjamRacE52ZnNpcU9TRzh5bmxzdUFaai9jSWRSRkVFdkFmL1FwOXRM?= =?utf-8?B?YzRxUHdiejlzdnB0bEtGZ3JpbkgwYkNBbEY4TnkrbkJKWi9LNzVZYTRIQ0xu?= =?utf-8?B?TVgzSXY1TnlBVEE1WGdGUk96RmRhc1l3aC92Uy8zWUVOUGRNMkdTS05FaFpX?= =?utf-8?B?QkxRSklGd3hkUmV0cGZXRGF3NzZnRW54MHgwL2NhRm05dW04NjFrK2tSMWFG?= =?utf-8?B?MERVckxnc2E2ZmRZVVpkSXQvWThyZDBtZEcvU1NHU2hMcWF4QlJMNmp0OVMx?= =?utf-8?B?SkQyYTk4Nk1nYkxwc09keHk5dWpJazFZdmFyRHFzTUpCWlZORjFwd0Faa0s5?= =?utf-8?B?VEFFNnRYczhRZUJQTVBaV3llRTVCKzhBTngvbXdiUno4SHV0aG1ETHBJOVpO?= =?utf-8?B?Q3Y0RGdIeDI4RWdNWEg5WldLRXVNZmlrdHQwNmlacXBFWXJ1ODRpaUd6YVFK?= =?utf-8?B?UnRQcldYY1RES0VVMGZBS3ZvYXVVNlNpOVhZbGlPUDdNNVEySzJQRVc4dGE5?= =?utf-8?B?RkZlSzZ2SkNDM3B3Vy9DVDc5djc4K0NXUG0rUjZlKzN5Q3RVWFNUbGFFbEcw?= =?utf-8?B?K0JEY21Qam5YSHBZOThUUFZ4eCtzSk5BemlaNEhONWdyTVRpbjFKUEJ4OWla?= =?utf-8?B?UU1ObjRGMUdWZ3NvdjBGY3RGQmtMWmF0SGs2aWJVVzVodk4rc2FEUHhSZitn?= =?utf-8?B?eURSR0diWEcrMVBLSFVBRU1QQktTdGdYZmlUQm40bk5VczIwOFNMM0FqYThQ?= =?utf-8?B?YjY1c1B3RkpITlViQXRTNVR1dmV5bjBQRjA0VjVYaE56WXB6aGZzckUyZzJv?= =?utf-8?B?RytyYVlaeWwvZXdYWkxaS3JERkV0RzJ1bFZNY0doc1hwZGkvSHZOY3hYSGFy?= =?utf-8?B?a0hCNnRkUDZoN2Rvbm01MlBURWx2NjNqdFRPaGJJZjRnKzY4dkZ5MUNPMWdG?= =?utf-8?B?WTNLVHB1WEZxT0dVeU5LSE9QaUgrcEowVjcrODczQW1LN1IvV3VsV201bmMv?= =?utf-8?B?R3A5WGpvVWNVMXRoT1YyVlArMTVqSHRxM0NEK3hZZE41QnAwb2pUa1d3SGVv?= =?utf-8?B?eVBvaGZQaENpem5QVURvUlFpa2pXcGYxSGxuTGlBUEVuWDJ1bEE3UjI0dVVN?= =?utf-8?B?cUxnaGhkSVo1M1FocyttQ3VTUkRvTk10K0ZoZ2YxdFlYZGgvSlVLRlkySU0w?= =?utf-8?B?ay9LY2hPQm9zMVd4TTBWOSt2RDVqS0ZWT2pxS3NmQklLMHRtWEE0Q3U3c1pL?= =?utf-8?B?TER4SERDVGZ0N2tJYmQ5OUZiSmhiTVpxMmZDMGxIUkNKaXdabGQ0bkdvZnpo?= =?utf-8?B?dzd5N1UzT21JZ1dIam9aYnFteDhGOThTUkVTYmloRXBHaDUwRGF5dHZLTHhC?= =?utf-8?Q?J4fSPDBTNehzQxs9LwvoAQ7cw8qNaRA8axgJeMx?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR02MB659123EFA17E7C6E7E4C969DF2429MN2PR02MB6591namp_" MIME-Version: 1.0 X-OriginatorOrg: qti.qualcomm.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR02MB6591.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 35c2dc87-907f-4362-b4e0-08d908bf1e2d X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Apr 2021 14:25:18.6249 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 98e9ba89-e1a1-4e38-9007-8bdabc25de1d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: tPrPbdq/Mdx15Ynk6bNGIern8efRNLia2tBv91JCRnNPHve5hgRCojtVot9wJAoy3n+eWAI4y45Scb3wn4mgfw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR02MB6482 Archived-At: Subject: Re: [ipwave] RFC8902 - TLS with ITS Certificates, EXPERIMENTAL, and the one PKI and one Internet X-BeenThere: its@ietf.org 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 14:25:28 -0000 --_000_MN2PR02MB659123EFA17E7C6E7E4C969DF2429MN2PR02MB6591namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Pj4gSWYgeW91ciBjb25jbHVzaW9uIGlzIHRoYXQgwqsgdGhpcyBSRkMgaXMgbm90IHJlYWxseSBy ZWxldmFudCB0byBJVFMiLCB0aGlzIGlzIGhhcmQgdG8gYWdyZWUgd2l0aCBiZWNhdXNlIHRoZSBs YXJnZSBkZXBsb3ltZW50IG9mIEMtSVRTLiBBcyBtZW50aW9uZWQgYnkgV2lsbGlhbSBiZWZvcmUs IElUUyBkZXBsb3ltZW50cyBhY3Jvc3MgdGhlIFVTLCBFdXJvcGUgYW5kIEF1c3RyYWxpYSBhcmUg Y3VycmVudGx5IHVzaW5nIDE2MDkuMiBjZXJ0aWZpY2F0ZXMuDQoNCkFsc28sIElTTyAyMTE3NyBy ZWZlcmVuY2VzIGFuZCBidWlsZHMgb24gUkZDIDg5MDIsIGFuZCAyMTE3NyBpcyBpbiB0dXJuIHJl ZmVyZW5jZWQgYnkgYSBudW1iZXIgb2YgU0FFIElUUyBzdGFuZGFyZHMgaW4gdGhlIFVTLg0KDQpX aWxsaWFtDQoNCkZyb206IGl0cyA8aXRzLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBN b3VuaXJhIE1TQUhMSQ0KU2VudDogTW9uZGF5LCBBcHJpbCAyNiwgMjAyMSAxMDowOCBBTQ0KVG86 IEFsZXhhbmRyZSBQZXRyZXNjdSA8YWxleGFuZHJlLnBldHJlc2N1QGdtYWlsLmNvbT47IGl0c0Bp ZXRmLm9yZw0KU3ViamVjdDogW0VYVF0gUmU6IFtpcHdhdmVdIFJGQzg5MDIgLSBUTFMgd2l0aCBJ VFMgQ2VydGlmaWNhdGVzLCBFWFBFUklNRU5UQUwsIGFuZCB0aGUgb25lIFBLSSBhbmQgb25lIElu dGVybmV0DQoNCj4+IElmIHRoZXJlIHdlcmUgYSBuZWVkIHRvIGRpc2N1c3MgdGhhdCBSRkMgdGhl biBpdCB3b3VsZCBoYXZlIGJlZW4NCmRpc2N1c3NlZCBwdWJsaWNseSB3aGVuIGl0IHdhcyBhbiBJ LUQuDQoNCj4+IFRoaXMgaXMgbm90IGEgbmVnYXRpdmUgcmVtYXJrLCBhbmQgYWxsIFJGQ3MgdGhh dCBnbyB0aHJvdWdoIGRldGFpbGVkDQpyZXZpZXdzLCBhcyB0aGlzIG9uZSBoYXMsIGFyZSB1c2Vm dWwuICBCZXR0ZXIgaGF2ZSBhbiBSRkMgb24gdGhlIHRvcGljDQpyYXRoZXIgdGhhbiBzaWxlbmNl Lg0KDQoNCg0KDQpJbiBteSBtZW1vcnksIHRoZSBSRkMgd2FzIHByZXNlbnRlZCBieSBXaWxsaWFt IGluIElQV0FWRSBHUk9VUCBpbiAyMDE5LiBCdXQgSVBXQVZFIGRpZCBub3QgaG9zdCB0aGlzIGFj dGl2aXR5IGFzIGl0IHdhcyBvdXRzaWRlIHRoZSBjaGFydGVyIGFzIGN1cnJlbnRseSB3cml0dGVu LiBBbHRob3VnaCB0aGVyZSB3YXMgYSBwb3NzaWJpbGl0eSB0byByZXdyaXRlIHRoZSBjaGFydGVy LCBidXQgd2UgaGFkIHRvIHdhaXQgdW50aWwgdGhlIHR3byBjdXJyZW50IGRvY3VtZW50cyBiZWlu ZyB3b3JrZWQgb24gYnkgSVBXQVZFIGhhZCBiZWVuIGNvbXBsZXRlZCBzbyBhcyBub3QgdG8gZGVm b2N1cyB0aGUgZ3JvdXAuDQoNCg0KDQoNCg0KSWYgeW91ciBjb25jbHVzaW9uIGlzIHRoYXQgwqsg dGhpcyBSRkMgaXMgbm90IHJlYWxseSByZWxldmFudCB0byBJVFMiLCB0aGlzIGlzIGhhcmQgdG8g YWdyZWUgd2l0aCBiZWNhdXNlIHRoZSBsYXJnZSBkZXBsb3ltZW50IG9mIEMtSVRTLiBBcyBtZW50 aW9uZWQgYnkgV2lsbGlhbSBiZWZvcmUsIElUUyBkZXBsb3ltZW50cyBhY3Jvc3MgdGhlIFVTLCBF dXJvcGUgYW5kIEF1c3RyYWxpYSBhcmUgY3VycmVudGx5IHVzaW5nIDE2MDkuMiBjZXJ0aWZpY2F0 ZXMuDQoNCg0KDQpNb3VuaXJhDQoNCg== --_000_MN2PR02MB659123EFA17E7C6E7E4C969DF2429MN2PR02MB6591namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q291cmllcjsNCglwYW5vc2UtMToyIDcgNCA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1 IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTotd2Via2l0LXN0YW5k YXJkOw0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KLyogU3R5bGUgRGVmaW5pdGlv bnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2lu OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiIHN0eWxlPSJ3b3JkLXdy YXA6YnJlYWstd29yZCI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgc3R5bGU9Im1h cmdpbjowaW47dGV4dC1hbGlnbjpqdXN0aWZ5Ij4mZ3Q7Jmd0OyA8c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7 Y29sb3I6IzI2MjYyNiI+DQpJZiB5b3VyIGNvbmNsdXNpb24gaXMgdGhhdCZuYnNwO8KrJm5ic3A7 dGhpcyBSRkMgaXMgbm90IHJlYWxseSByZWxldmFudCB0byBJVFMmcXVvdDssIHRoaXMgaXMgaGFy ZCB0byBhZ3JlZSB3aXRoIGJlY2F1c2UgdGhlIGxhcmdlIGRlcGxveW1lbnQgb2YgQy1JVFMuIEE8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdl YmtpdC1zdGFuZGFyZCZxdW90OyxzZXJpZjtjb2xvcjpibGFjayI+cyBtZW50aW9uZWQgYnkgV2ls bGlhbSBiZWZvcmUsJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZjtjb2xvcjojMjYyNjI2 Ij5JVFMNCiBkZXBsb3ltZW50cyBhY3Jvc3MgdGhlIFVTLCBFdXJvcGUgYW5kIEF1c3RyYWxpYSBh cmUgY3VycmVudGx5IHVzaW5nIDE2MDkuMiBjZXJ0aWZpY2F0ZXMuJm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImZvbnQtc3RyZXRjaDpub3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWxzbywgSVNP IDIxMTc3IHJlZmVyZW5jZXMgYW5kIGJ1aWxkcyBvbiBSRkMgODkwMiwgYW5kIDIxMTc3IGlzIGlu IHR1cm4gcmVmZXJlbmNlZCBieSBhIG51bWJlciBvZiBTQUUgSVRTIHN0YW5kYXJkcyBpbiB0aGUg VVMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldpbGxpYW08bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IGl0cyAmbHQ7aXRzLWJv dW5jZXNAaWV0Zi5vcmcmZ3Q7IDxiPk9uIEJlaGFsZiBPZiA8L2I+DQpNb3VuaXJhIE1TQUhMSTxi cj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEFwcmlsIDI2LCAyMDIxIDEwOjA4IEFNPGJyPg0KPGI+ VG86PC9iPiBBbGV4YW5kcmUgUGV0cmVzY3UgJmx0O2FsZXhhbmRyZS5wZXRyZXNjdUBnbWFpbC5j b20mZ3Q7OyBpdHNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW0VYVF0gUmU6IFtpcHdh dmVdIFJGQzg5MDIgLSBUTFMgd2l0aCBJVFMgQ2VydGlmaWNhdGVzLCBFWFBFUklNRU5UQUwsIGFu ZCB0aGUgb25lIFBLSSBhbmQgb25lIEludGVybmV0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyZndDsg SWYgdGhlcmUgd2VyZSBhIG5lZWQgdG8gZGlzY3VzcyB0aGF0IFJGQyB0aGVuIGl0IHdvdWxkIGhh dmUgYmVlbjxicj4NCmRpc2N1c3NlZCBwdWJsaWNseSB3aGVuIGl0IHdhcyBhbiBJLUQuPGJyPg0K PGJyPg0KJmd0OyZndDsgVGhpcyBpcyBub3QgYSBuZWdhdGl2ZSByZW1hcmssIGFuZCBhbGwgUkZD cyB0aGF0IGdvIHRocm91Z2ggZGV0YWlsZWQ8YnI+DQpyZXZpZXdzLCBhcyB0aGlzIG9uZSBoYXMs IGFyZSB1c2VmdWwuJm5ic3A7IEJldHRlciBoYXZlIGFuIFJGQyBvbiB0aGUgdG9waWM8YnI+DQpy YXRoZXIgdGhhbiBzaWxlbmNlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgc3R5bGU9Im1hcmdpbjowaW47dGV4dC1hbGlnbjpqdXN0aWZ5O2ZvbnQtc3RyZXRjaDpu b3JtYWw7bWluLWhlaWdodDoxN3B4Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTpDb3VyaWVyO2NvbG9yOiMyNjI2MjYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO3RleHQtYWxpZ246anVzdGlmeTtmb250LXN0cmV0Y2g6 bm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7Y29sb3I6IzI2MjYyNiI+SW4gbXkgbWVtb3J5LCB0 aGUgUkZDIHdhcyBwcmVzZW50ZWQgYnkgV2lsbGlhbSBpbiBJUFdBVkUgR1JPVVAgaW4gMjAxOS4g QnV0IElQV0FWRSBkaWQgbm90IGhvc3QgdGhpcyBhY3Rpdml0eSBhcyBpdA0KIHdhcyBvdXRzaWRl IHRoZSZuYnNwO2NoYXJ0ZXImbmJzcDthcyBjdXJyZW50bHkgd3JpdHRlbi4gQWx0aG91Z2ggdGhl cmUgd2FzIGEgcG9zc2liaWxpdHkgdG8gcmV3cml0ZSB0aGUmbmJzcDtjaGFydGVyLCBidXQgd2Ug aGFkIHRvIHdhaXQgdW50aWwgdGhlIHR3byBjdXJyZW50IGRvY3VtZW50cyBiZWluZyB3b3JrZWQg b24gYnkgSVBXQVZFIGhhZCBiZWVuIGNvbXBsZXRlZCBzbyBhcyBub3QgdG8gZGVmb2N1cyB0aGUg Z3JvdXAuICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGlu O3RleHQtYWxpZ246anVzdGlmeTtmb250LXN0cmV0Y2g6bm9ybWFsO21pbi1oZWlnaHQ6MTdweCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7LHNlcmlmO2NvbG9yOiMyNjI2MjYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO3RleHQtYWxpZ246anVzdGlmeTtmb250LXN0cmV0 Y2g6bm9ybWFsO21pbi1oZWlnaHQ6MTdweCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmO2NvbG9yOiMyNjI2 MjYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO3Rl eHQtYWxpZ246anVzdGlmeTtmb250LXN0cmV0Y2g6bm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7 Y29sb3I6IzI2MjYyNiI+SWYgeW91ciBjb25jbHVzaW9uIGlzIHRoYXQmbmJzcDvCqyZuYnNwO3Ro aXMgUkZDIGlzIG5vdCByZWFsbHkgcmVsZXZhbnQgdG8gSVRTJnF1b3Q7LCB0aGlzIGlzIGhhcmQg dG8gYWdyZWUgd2l0aCBiZWNhdXNlIHRoZSBsYXJnZQ0KIGRlcGxveW1lbnQgb2YgQy1JVFMuIEE8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdl YmtpdC1zdGFuZGFyZCZxdW90OyxzZXJpZjtjb2xvcjpibGFjayI+cyBtZW50aW9uZWQgYnkgV2ls bGlhbSBiZWZvcmUsJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZjtjb2xvcjojMjYyNjI2 Ij5JVFMgZGVwbG95bWVudHMgYWNyb3NzIHRoZSBVUywNCiBFdXJvcGUgYW5kIEF1c3RyYWxpYSBh cmUgY3VycmVudGx5IHVzaW5nIDE2MDkuMiBjZXJ0aWZpY2F0ZXMuJm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47dGV4dC1hbGlnbjpqdXN0aWZ5O2ZvbnQt c3RyZXRjaDpub3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjow aW47dGV4dC1hbGlnbjpqdXN0aWZ5O2ZvbnQtc3RyZXRjaDpub3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oyxz ZXJpZjtjb2xvcjojMjYyNjI2Ij5Nb3VuaXJhJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_MN2PR02MB659123EFA17E7C6E7E4C969DF2429MN2PR02MB6591namp_-- From nobody Mon Apr 26 07:29:32 2021 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EEC43A21F9 for ; Mon, 26 Apr 2021 07:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8BZYFEXuhpQr for ; Mon, 26 Apr 2021 07:29:20 -0700 (PDT) Received: from esa.hc3962-90.iphmx.com (esa.hc3962-90.iphmx.com [216.71.140.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E08DB3A21DF for ; Mon, 26 Apr 2021 07:29:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qccesdkim1; t=1619447358; x=1620052158; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=VNKj5kZW+lyzy/mUdb1KFFjliB915qEpA1qodcZynDo=; b=IV3Piv6n2B5S8CJitdA3wwazhTOuuzgb/KNoSH1BTcs6Fe4RhDdqDYja 6kV49K4ptJRRANmdnG/np4v+Zp8C4RsiajiODslrMTvv8BvTuCDTPee7Q /Aidbjq/EIH1rEGzlVCpD1pCjSeN2tXUebzj02yZyNU12yVnG3nFtBpZj U=; IronPort-SDR: PQHjTxUpWegQsudhF60B9udBJFVXaCK0fVnnNzVLj4oB/an32/YPjhzr4vywgNf2wotWQyhgFo kvvIq+27164qml/j+/H2sQPKpG3N4E8pppvsRnjMvlpVXFyjspcmTIbYqCGZ9QfdYJB3pi2eR5 IGNpA1/y5FGxkphXFVPjuwQq6pJtFdL2lCLMu+Jl5BnegeJ7oeWpC3Z6yY5AkPlZI2YRl++Ny1 y8EWBQcWhLVpZ+xV4YuYTq7KpHKC6KYh953DuWxeCOV8lr+E/E9P2uQ3nirIeZVJMKzuHX7V0s 59I= X-IronPort-RemoteIP: 104.47.56.175 X-IronPort-MID: 21739 X-IronPort-Reputation: None X-IronPort-Listener: OutgoingMail X-IronPort-SenderGroup: RELAY_O365 X-IronPort-MailFlowPolicy: $RELAYED Thread-Topic: Re: [ipwave] wish list for CAs for vehicular networks Received: from mail-co1nam11lp2175.outbound.protection.outlook.com (HELO NAM11-CO1-obe.outbound.protection.outlook.com) ([104.47.56.175]) by ob1.hc3962-90.iphmx.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Apr 2021 14:29:17 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=F2F9oJcDn6O2JR7p1tGzIgJO9bvFWG2QE5d8dEaMASRswADQ/yKefR+YSNZj+V7IFkFSe6c8sBU1QWUlUj23XvsrC+EQD1TDQST6E7X7zAk/MzcReVFWcdxE9Uih8QK3ZaGT0YzC96V3RtvAB25zQ3xbGlDu0HYPy88Q8UMf9gWZviNyY0ioV1hcuvG5NnOACjZa/ft2QiG5DxNMoJkssUOqHGs5OpLqRMZLut3fauofVW2s9UMwLueNDs7e2RfiVPojw7Yv4zXXKGRGho8z8bVIyE+7TCY0q/IRR66EnbuvehHeNcd1EWO9IqSZhdqCg9UjW5OmpOVGAnb3naF1zw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VNKj5kZW+lyzy/mUdb1KFFjliB915qEpA1qodcZynDo=; b=gZYmlUkEemPbByQ1ejyADfjxrTthZBJ7HXmPne+PAbTyPsjzUPoIczfbsw9V5jgRUaXU+xFuLUTv45hSk1t8AcrqCnBPEmxe/qZlU91VVdbfFAbkcYH3X3p9xcdQnVDRCVJFPgyEy5dMuAopBRa9Ir6bXNNQZOqgeKpWOoTJQTD9lY5d1M1/WreZLsBzAagD8JRIuV2CsX6FoplQFkVd42+EvLxtToNNiykpjk2BgqBUCnVgy6iCDBmUC95Y8UPgGh/4kpTeVHk2bNWT2AJBpmTuw/dayVprjZNm6kfSKuwhohI6RvTOtz18YQeN6aCEQfi7bV4euE4s+pqAZTuqvw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=qti.qualcomm.com; dmarc=pass action=none header.from=qti.qualcomm.com; dkim=pass header.d=qti.qualcomm.com; arc=none Received: from MN2PR02MB6591.namprd02.prod.outlook.com (2603:10b6:208:15f::17) by MN2PR02MB5837.namprd02.prod.outlook.com (2603:10b6:208:114::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.23; Mon, 26 Apr 2021 14:29:15 +0000 Received: from MN2PR02MB6591.namprd02.prod.outlook.com ([fe80::8178:7533:16e:f843]) by MN2PR02MB6591.namprd02.prod.outlook.com ([fe80::8178:7533:16e:f843%7]) with mapi id 15.20.4065.026; Mon, 26 Apr 2021 14:29:15 +0000 From: William Whyte To: Mounira MSAHLI , Alexandre Petrescu CC: "its@ietf.org" Thread-Index: AQHXN4+awWhPVRb0MkmmKa9bu5nfd6rAy02AgAEpIACAAxV9AIABmA0AgAA2IICAAAjfIA== Date: Mon, 26 Apr 2021 14:29:15 +0000 Message-ID: References: <01d601d731e3$140e2ed0$3c2a8c70$@eurecom.fr> <0600020f-b6ca-4d6d-2499-817586bc3548@gmail.com> <19dce5f5-8dca-55c2-4d46-bb83046562ab@gmail.com> <1ec103fe-7a50-cb2c-0763-30cc6362bf13@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none; gmail.com; dmarc=none action=none header.from=qti.qualcomm.com; x-originating-ip: [173.48.177.63] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fa24131f-508d-402f-6319-08d908bfab7e x-ms-traffictypediagnostic: MN2PR02MB5837: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: AWkfguNSIfpqyJTSeBcmbUQqAGpnjnRmoiR2L3XxI5mA+xZyKR+gsDTyKNph4d5WS2v6nMtBb74HefTzB8N26Fi1+W3d5OTbQ33LAxdAIgRRup4HAvAzWf316CUhH8I5xzeCamcTIQZeD/uGr3dz3u1v+gF+/gyu1Gv8ntECeQdfhLcj3VCMVGLR6sLs48LcrepiUrJ79FAkdtMpg+aorli4abbj7xhzN2U9Ry6tGfADqPmgC6ge7VgCVX0g63D5ZrKL9PDiE3UYSDPNE7OuktVkk7mIey8xZzeLGwJwafrDXLPwP4vDM96QikKYoJtWJLgSf83C0zOm3SSizS6Dq6U0ePSr5G4IoYsEbtVVSKMZzr2tq099SGiafZr5ykSmZhWbqft7b2MOI9s0+Unk2lNBZ7OQDl/DxOOCpRwLyDsNipr7l54F7769ZKGtUHuk+VaergrnKnnMJaDPALjVCx+ol04yiDx7TDVnl9H6jO2JPSBla7c5kX/YVsMBZjjfYR6SUQbNOOchcyfwmNXVKpFScBpeaC+pKbUsDaiS2EQg25o8C4MebNMjQYi08adIvypqDkrIzwg33xqAIcDIuDvfSea8XzSfIf4Q//g8sRE= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR02MB6591.namprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(396003)(136003)(39860400002)(376002)(366004)(66946007)(76116006)(9686003)(33656002)(478600001)(2906002)(122000001)(5660300002)(186003)(110136005)(8936002)(6506007)(53546011)(66476007)(66446008)(7696005)(4326008)(8676002)(64756008)(66556008)(55016002)(83380400001)(26005)(52536014)(71200400001)(86362001)(316002)(38100700002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?utf-8?B?OUVIa3RMdVNldzAzTjBqNTFGbHd1dlRwR2JKTURCbDFQNVd6NEo0QXJacE9s?= =?utf-8?B?eWY5V3hDM29ISmg1aGtCSTdWK1h2RDcyNEtNUEQzODQ0Mk5UUGhucUhOSzJF?= =?utf-8?B?M0ZacWNtbDRveVB5WGphUXJibXBUNXBOcWN3djVLbEduSExLd1hPak5KVmNC?= =?utf-8?B?SFllMjlrc1JhT0ZJbjFYRk5ocDNQa09iWFBFUmpqU1c4ZGN5eGQwRU14QnVi?= =?utf-8?B?M2J3TFRQaGpVMzNYYWEwVk4zdDRUYTAxQ0Z2NGtZUTY4TGxNeHpBR1l0cjdV?= =?utf-8?B?SWtqQytybWh1SlBOZ2k2SzhPUk8yWEFlNU9odEpxSVR6VFVFa29NWHhLbUZx?= =?utf-8?B?R3ZQakhDYWNTdkZrTU9BTTBidTNuM0RtNnZIY0hWWm9ZZ05KM3dOOWtRa29C?= =?utf-8?B?NElrNndCamU4STQwem92S3lQTkRRa0FLanY4YjRLZlZQZk1ObnRPNi9sTVc1?= =?utf-8?B?VVRZTUMyRVUvalFxNHF6Ly9ERWNzZHNCOEdJQVpocVNKcTA4YnJFcnhFSUlM?= =?utf-8?B?NEExR3YxT1pTN2Y0Z0RpRkpJRklRMkRyaEQva0g2V3JPbm5LM0YrKzNsci8r?= =?utf-8?B?aW9FaGc0SjhIemoyLzlnK052U0pqdXArdVNVcXZUWXMwY05pcDJTZjhFcmh4?= =?utf-8?B?SzJUR1prWmE1eE05UE9jMEZ3Vmh5K2c1OEpTLzJ6RUtJa0pVZ1BUQ3N5bThH?= =?utf-8?B?TGJucUlmNkVvR0E3Tko4S3FUY2NwOTQxT2w2NnpaR0NQanNNZzNGUHd6MnJk?= =?utf-8?B?dnAveTd0U1pIdmZlcDJVRitZc2h1MVFMY1V3QTIwU2Y5WURKSDZ4d1A2andM?= =?utf-8?B?dzdWMVpQa0Y2ZzFQT1BiWkwzdnorSDE2WHlvZTJZNzZiemdRVFhSdGhQbDE5?= =?utf-8?B?aVJoSWZab0hzdE9ZMnpKZFBkTlUwVmNVNTZ3VXl1UlpUWUhuRU5JZnc5bmh3?= =?utf-8?B?eEhicHZ1L29XMGZKRzdycGErcXM5ZHpXdlNHK2NOU1N1SDZZQzZZUFFZUEFr?= =?utf-8?B?ajNPTG1qbm5jclBxdFRNYmFTOUFwSHhYVFpibnBVdFJuY0NBTkdUWldRZEdz?= =?utf-8?B?YnJKb0pGMHlJNTVJdzZFWkRPWGE4dlowL2ZaL1duNllnWnB2RUxKekxXb0c5?= =?utf-8?B?NzR2ek1NbnU1NFUzSGl4VTRGWGw0ZFg0c0dCU2FoVXR2dFZqTW11NDBUNGZB?= =?utf-8?B?T01oa1YwY1hnbktybnB6a1ZLZUJmTjFpSFRjbGJlTGVuaVNzNWgzeTZ3RUJh?= =?utf-8?B?UFl0b3FpS3Z4YjM0SnZoSys0TXdGaXp6NzMyOTVrVEZ6OGYvWDNUWjFkWkpl?= =?utf-8?B?UTJMdHhwQ1oxUzBVMFV1aGpIMmd3N2hURzZ0SG0rZUJ1Tjl6aDFua3IxNXZE?= =?utf-8?B?UmxOVkdWa29CSndUeWhBcHI2c1FMRzl2YkFncEl3Y1AvUmdEZGhVYWp6WnQ2?= =?utf-8?B?THBkSXF2eWlVTmRqZ0FNbzFlTVBrQzBmWFFsTVYrUWVXZGlkc0RJTm9pTzhX?= =?utf-8?B?ZnR3NnIxTlVvRFk2RUZZMVFtV1RLNmZIOWdsdHA0TTkvU29iR1Uzd09hOS9n?= =?utf-8?B?WDl2MzcyOCtpb0VoaEFpMGdOZGZEcXdIbEx0dkRCME91TzRRb291NXYxMkUr?= =?utf-8?B?RC94bDNUZ1dsM0NPa0VVTnVPQVFpbUpqcnd6VExHV1EyT1l6b2FrYzUwQjVC?= =?utf-8?B?SUZoRmhzL2xVVnk3c1dCTHBjOFlLVHZERXRWVXVpN2o1SjNvT0NqTWhZQnU0?= =?utf-8?Q?QbgIQzqQ60mrpPZl7irr0NvbydMrP0nbsxdBagz?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR02MB6591ADE2799245EEFF7F7D1DF2429MN2PR02MB6591namp_" MIME-Version: 1.0 X-OriginatorOrg: qti.qualcomm.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR02MB6591.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: fa24131f-508d-402f-6319-08d908bfab7e X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Apr 2021 14:29:15.7085 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 98e9ba89-e1a1-4e38-9007-8bdabc25de1d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: isY02HMPOhjFkbPUNNrUgW9o1XHb85YbqVZbGFXG+mnNFOCTbIMASAZ6CCLoE/H715VSFw3EXK5tENxOP4MzyQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR02MB5837 Archived-At: Subject: Re: [ipwave] wish list for CAs for vehicular networks X-BeenThere: its@ietf.org 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 14:29:31 -0000 --_000_MN2PR02MB6591ADE2799245EEFF7F7D1DF2429MN2PR02MB6591namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Pj4gLSB0aGUgc3BlY3Mgb2YgQ0EgbXVzdCBiZSBpbXBsZW1lbnRhYmxlIGluZGVwZW5kZW50bHkg b2Ygb3RoZXIgcGF5aW5nDQogICBzb3VyY2VzIHN1Y2ggYXMgKHNvbWUpIGZyb20gSUVFRSBvciBJ U08uICBGb3IgZXhhbXBsZSwgdGhlIEVUU0kgSVRTDQogICBzcGVjIHRoYXQgSU1QT1JUUyAxNjA5 LjIgZG9lcyBub3QgcXVhbGlmeSBiZWNhdXNlIGluIHRoZSBlbmQgaXQgaXMNCiAgIHBheWluZy4g IEJ1dCB0aGUgWC41MDkgaW4gUkZDIDUyODAgZG9lcyBub3QgcmVseSBvbiBvdGhlciBwYXlpbmcN CiAgIGRvY3VtZW50cyBpbiBvcmRlciB0byBpbXBsZW1lbnQgKEkgdGhpbms/KS4NCg0KPj4gV2ls bGlhbSBjb3VsZCBhbnN3ZXIgeW91IHRoaXMgcXVlc3Rpb24gYmV0dGVyIHRoYW4gbWUgYmVjYXVz ZSBpdCB3YXMgYWxyZWFkeSBhc2tlZCBieSBFVFNJLg0KDQpZZXMsIDE2MDkuMiBuZWVkcyB0byBi ZSBwdXJjaGFzZWQgZnJvbSBJRUVFLiBFVFNJIGhhcyByZXByb2R1Y2VkIHRoZSBBU04uMSAod2l0 aCBwZXJtaXNzaW9uIGZyb20gSUVFRSkgYnV0IHRoZXJlIGFyZSBzb21lIHN1YnRsZXRpZXMgb2Yg aW1wbGVtZW50YXRpb24gYW5kIGhvdyB0aGUgY3J5cHRvIG9wZXJhdGlvbnMgYXJlIGNhcnJpZWQg b3V0IHRoYXQgYXJlbuKAmXQgY2FwdHVyZWQgaW4gdGhlIEFTTi4xIGFsb25lLg0KDQpJ4oCZZCBu b3RlIHRoYXQgQWxleOKAmXMgcHJlZmVyZW5jZSBmb3Igc3RhbmRhcmRzIHRvIGJlIGZyZWVseSBh dmFpbGFibGUgaWYgdGhleSBhcmUgdG8gYmUgcmVmZXJlbmNlZCBieSBJRVRGIGlzIGEgcmVhc29u YWJsZSBwb2ludCBvZiB2aWV3LCBidXQgaXTigJlzIG5vdCBJRVRGIHBvbGljeTsgSUVURiBwb2xp Y3kgYWxsb3dzIG5vbi1mcmVlIHN0YW5kYXJkcyB0byBiZSByZWZlcmVuY2VkLg0KDQpDaGVlcnMs DQoNCldpbGxpYW0NCg0KDQpGcm9tOiBpdHMgPGl0cy1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhh bGYgT2YgTW91bmlyYSBNU0FITEkNClNlbnQ6IE1vbmRheSwgQXByaWwgMjYsIDIwMjEgOTo1NCBB TQ0KVG86IEFsZXhhbmRyZSBQZXRyZXNjdSA8YWxleGFuZHJlLnBldHJlc2N1QGdtYWlsLmNvbT4N CkNjOiBpdHNAaWV0Zi5vcmcNClN1YmplY3Q6IFtFWFRdIFJlOiBbaXB3YXZlXSB3aXNoIGxpc3Qg Zm9yIENBcyBmb3IgdmVoaWN1bGFyIG5ldHdvcmtzDQoNCkNhbiB5b3UgY29tbWVudCBvbiB0aGlz IHdpc2ggbGlzdD8NCg0KV2lzaCBsaXN0IGZvciBDQXMgZm9yIHZlaGljdWxhciBuZXR3b3Jrcw0K DQo+PiAtIHRoZSBDQSBtdXN0IGJlIHJlYWNoYWJsZSBvbiBJUHY2LCBhbmQgdGhlaXIgd2Vic2l0 ZSB0b28uDQogICAgICAgIENvdWxkIHlvdSBwbGVhc2UgbWVudGlvbiB3aHkgbm90IElQdjQgPw0K DQotIHRoZSBzcGVjcyBvZiBDQXMgZm9yIHZlaGljdWxhciBuZXR3b3JrcyBtdXN0IGJlIGF2YWls YWJsZSBvbiBJUHY2DQogICAoZS5nLiBvbiBhbiBJUHY2IHdlYnNpdGUsIEZUUCBkaXJlY3Rvcnks IG9yIEdJVCBzaGFyZWQgc3BhY2UpLg0KDQpZb3UgbWVhbiBjZXJ0aWZpY2F0ZSBwb2xpY3kuIEkg aGF2ZSB0aGUgc2FtZSBxdWVzdGlvbi4gWW91IGFyZSBzcGVjaWZ5aW5nIHRoZSBJUCBwcm90b2Nv bCBmb3IgdGhlIFBLSSB3ZWJzaXRlLiBJIGFncmVlIHRoYXQgZG9jdW1lbnQgbXVzdCBiZSBwdWJs aXNoZWQgYW5kIGF2YWlsYWJsZSB0byBQS0kgdXNlcnMgYnV0IHdoeSBJUFY2ID8NCg0KLSB0aGUg c3BlY3Mgb2YgQ0EgbXVzdCBiZSBpbXBsZW1lbnRhYmxlIGluZGVwZW5kZW50bHkgb2Ygb3RoZXIg cGF5aW5nDQogICBzb3VyY2VzIHN1Y2ggYXMgKHNvbWUpIGZyb20gSUVFRSBvciBJU08uICBGb3Ig ZXhhbXBsZSwgdGhlIEVUU0kgSVRTDQogICBzcGVjIHRoYXQgSU1QT1JUUyAxNjA5LjIgZG9lcyBu b3QgcXVhbGlmeSBiZWNhdXNlIGluIHRoZSBlbmQgaXQgaXMNCiAgIHBheWluZy4gIEJ1dCB0aGUg WC41MDkgaW4gUkZDIDUyODAgZG9lcyBub3QgcmVseSBvbiBvdGhlciBwYXlpbmcNCiAgIGRvY3Vt ZW50cyBpbiBvcmRlciB0byBpbXBsZW1lbnQgKEkgdGhpbms/KS4NCg0KV2lsbGlhbSBjb3VsZCBh bnN3ZXIgeW91IHRoaXMgcXVlc3Rpb24gYmV0dGVyIHRoYW4gbWUgYmVjYXVzZSBpdCB3YXMgYWxy ZWFkeSBhc2tlZCBieSBFVFNJLg0KDQotIHRoZSBDQSBtdXN0IG9mZmVyIE9DU1AgcmVhY2hhYmls aXR5IG9uIElQdjYuDQoNCkkgZmluZCB0aGF0IGFsbCByZWNvbW1hbmRhdGlvbnMgYXJlIHJlbGF0 ZWQgdG8gdGhlIHVzZSBvZiBJUHY2IG5vdCByZWFsbHkgdGhlDQpzZWN1cml0eSBvciBwcml2YWN5 IGluIEMtSVRTLiBCeSBhbmFsb2d5IHdpdGggd2hhdCB5b3UgYXJlIHN1Z2dlc3RpbmcsIEkgdGhp bmsgIHRoYXQgeW91IHdvdWxkIHByZWZlciB0byB1c2UgSVB2NiBmb3IgdGhlIHVwbG9hZCBvZiBs b2cgYW5kIGRvd25sb2FkIG9mIHVwZGF0ZXMgYW5kIGFsbCBWMkkgY29tbXVuaWNhdGlvbnMgbm90 IG9ubHkgVjJQS0kgY29ubmV4aW9uLg0KDQoNCk1vdW5pcmENCg0K --_000_MN2PR02MB6591ADE2799245EEFF7F7D1DF2429MN2PR02MB6591namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uZ21haWwtaW0NCgl7bXNvLXN0eWxl LW5hbWU6Z21haWwtaW07fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiIgc3R5 bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Jmd0OyAtIHRoZSBzcGVjcyBvZiBDQSBtdXN0IGJlIGlt cGxlbWVudGFibGUgaW5kZXBlbmRlbnRseSBvZiBvdGhlciBwYXlpbmc8YnI+DQombmJzcDsgJm5i c3A7c291cmNlcyBzdWNoIGFzIChzb21lKSBmcm9tIElFRUUgb3IgSVNPLiZuYnNwOyBGb3IgZXhh bXBsZSwgdGhlIEVUU0kgSVRTPGJyPg0KJm5ic3A7ICZuYnNwO3NwZWMgdGhhdCBJTVBPUlRTIDE2 MDkuMiBkb2VzIG5vdCBxdWFsaWZ5IGJlY2F1c2UgaW4gdGhlIGVuZCBpdCBpczxicj4NCiZuYnNw OyAmbmJzcDtwYXlpbmcuJm5ic3A7IEJ1dCB0aGUgWC41MDkgaW4gUkZDIDUyODAgZG9lcyBub3Qg cmVseSBvbiBvdGhlciBwYXlpbmc8YnI+DQombmJzcDsgJm5ic3A7ZG9jdW1lbnRzIGluIG9yZGVy IHRvIGltcGxlbWVudCAoSSB0aGluaz8pLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Jmd0 OyBXaWxsaWFtIGNvdWxkIGFuc3dlciB5b3UgdGhpcyBxdWVzdGlvbiBiZXR0ZXIgdGhhbiBtZSBi ZWNhdXNlIGl0IHdhcyBhbHJlYWR5IGFza2VkIGJ5IEVUU0kuICZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5ZZXMsIDE2MDkuMiBuZWVkcyB0byBiZSBwdXJjaGFzZWQgZnJvbSBJRUVFLiBF VFNJIGhhcyByZXByb2R1Y2VkIHRoZSBBU04uMSAod2l0aCBwZXJtaXNzaW9uIGZyb20gSUVFRSkg YnV0IHRoZXJlIGFyZSBzb21lIHN1YnRsZXRpZXMgb2YgaW1wbGVtZW50YXRpb24gYW5kIGhvdyB0 aGUgY3J5cHRvIG9wZXJhdGlvbnMgYXJlIGNhcnJpZWQgb3V0IHRoYXQgYXJlbuKAmXQgY2FwdHVy ZWQgaW4gdGhlIEFTTi4xIGFsb25lLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J4oCZZCBub3Rl IHRoYXQgQWxleOKAmXMgcHJlZmVyZW5jZSBmb3Igc3RhbmRhcmRzIHRvIGJlIGZyZWVseSBhdmFp bGFibGUgaWYgdGhleSBhcmUgdG8gYmUgcmVmZXJlbmNlZCBieSBJRVRGIGlzIGEgcmVhc29uYWJs ZSBwb2ludCBvZiB2aWV3LCBidXQgaXTigJlzIG5vdCBJRVRGIHBvbGljeTsgSUVURiBwb2xpY3kg YWxsb3dzIG5vbi1mcmVlIHN0YW5kYXJkcyB0byBiZSByZWZlcmVuY2VkLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5DaGVlcnMsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldpbGxpYW08bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g MGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gaXRzICZsdDtpdHMt Ym91bmNlc0BpZXRmLm9yZyZndDsgPGI+T24gQmVoYWxmIE9mIDwvYj4NCk1vdW5pcmEgTVNBSExJ PGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgQXByaWwgMjYsIDIwMjEgOTo1NCBBTTxicj4NCjxi PlRvOjwvYj4gQWxleGFuZHJlIFBldHJlc2N1ICZsdDthbGV4YW5kcmUucGV0cmVzY3VAZ21haWwu Y29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gaXRzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+ IFtFWFRdIFJlOiBbaXB3YXZlXSB3aXNoIGxpc3QgZm9yIENBcyBmb3IgdmVoaWN1bGFyIG5ldHdv cmtzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5DYW4geW91IGNvbW1lbnQgb24gdGhpcyB3aXNoIGxpc3Q/Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iZ21haWwtaW0iPldpc2ggbGlzdCBmb3IgQ0FzIGZv ciB2ZWhpY3VsYXIgbmV0d29ya3M8L3NwYW4+PGJyPg0KPGJyPg0KJmd0OyZndDsgLSB0aGUgQ0Eg bXVzdCBiZSByZWFjaGFibGUgb24gSVB2NiwgYW5kIHRoZWlyIHdlYnNpdGUgdG9vLjxvOnA+PC9v OnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBDb3VsZCB5b3UgcGxlYXNlIG1lbnRpb24gd2h5IG5vdCBJ UHY0ID8mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+LSB0aGUgc3BlY3Mgb2YgQ0FzIGZvciB2ZWhpY3VsYXIgbmV0d29ya3Mg bXVzdCBiZSBhdmFpbGFibGUgb24gSVB2Njxicj4NCiZuYnNwOyAmbmJzcDsoZS5nLiBvbiBhbiBJ UHY2IHdlYnNpdGUsIEZUUCBkaXJlY3RvcnksIG9yIEdJVCBzaGFyZWQgc3BhY2UpLjxvOnA+PC9v OnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WW91 IG1lYW4gY2VydGlmaWNhdGUgcG9saWN5LiBJIGhhdmUgdGhlIHNhbWUgcXVlc3Rpb24uIFlvdSBh cmUgc3BlY2lmeWluZyB0aGUgSVAgcHJvdG9jb2wgZm9yIHRoZSBQS0kgd2Vic2l0ZS4gSSBhZ3Jl ZSB0aGF0IGRvY3VtZW50IG11c3QgYmUgcHVibGlzaGVkIGFuZCBhdmFpbGFibGUgdG8gUEtJIHVz ZXJzIGJ1dCB3aHkgSVBWNiA/Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6 MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gdGhlIHNwZWNzIG9mIENBIG11c3QgYmUgaW1w bGVtZW50YWJsZSBpbmRlcGVuZGVudGx5IG9mIG90aGVyIHBheWluZzxicj4NCiZuYnNwOyAmbmJz cDtzb3VyY2VzIHN1Y2ggYXMgKHNvbWUpIGZyb20gSUVFRSBvciBJU08uJm5ic3A7IEZvciBleGFt cGxlLCB0aGUgRVRTSSBJVFM8YnI+DQombmJzcDsgJm5ic3A7c3BlYyB0aGF0IElNUE9SVFMgMTYw OS4yIGRvZXMgbm90IHF1YWxpZnkgYmVjYXVzZSBpbiB0aGUgZW5kIGl0IGlzPGJyPg0KJm5ic3A7 ICZuYnNwO3BheWluZy4mbmJzcDsgQnV0IHRoZSBYLjUwOSBpbiBSRkMgNTI4MCBkb2VzIG5vdCBy ZWx5IG9uIG90aGVyIHBheWluZzxicj4NCiZuYnNwOyAmbmJzcDtkb2N1bWVudHMgaW4gb3JkZXIg dG8gaW1wbGVtZW50IChJIHRoaW5rPykuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaWxsaWFtIGNvdWxkIGFuc3dlciB5b3UgdGhp cyBxdWVzdGlvbiBiZXR0ZXIgdGhhbiBtZSBiZWNhdXNlIGl0IHdhcyBhbHJlYWR5IGFza2VkIGJ5 IEVUU0kuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4tIHRoZSBDQSBtdXN0IG9mZmVyIE9DU1AgcmVhY2hhYmlsaXR5IG9u IElQdjYuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JIGZpbmQgdGhhdCBhbGwgcmVjb21tYW5kYXRpb25zIGFyZSByZWxhdGVkIHRv IHRoZSB1c2Ugb2YgSVB2NiBub3QgcmVhbGx5IHRoZSZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+c2VjdXJpdHkgb3IgcHJpdmFjeSBpbiBD LUlUUy4gQnkgYW5hbG9neSB3aXRoIHdoYXQgeW91IGFyZSBzdWdnZXN0aW5nLCBJIHRoaW5rICZu YnNwO3RoYXQgeW91IHdvdWxkIHByZWZlciB0byB1c2UgSVB2NiBmb3IgdGhlIHVwbG9hZCBvZiBs b2cgYW5kIGRvd25sb2FkIG9mIHVwZGF0ZXMgYW5kIGFsbCBWMkkgY29tbXVuaWNhdGlvbnMgbm90 IG9ubHkgVjJQS0kgY29ubmV4aW9uLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1vdW5pcmEmbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_MN2PR02MB6591ADE2799245EEFF7F7D1DF2429MN2PR02MB6591namp_-- From nobody Mon Apr 26 07:59:54 2021 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ACD73A22D1 for ; Mon, 26 Apr 2021 07:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.669 X-Spam-Level: X-Spam-Status: No, score=0.669 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_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LdRmN2FsRs6W for ; Mon, 26 Apr 2021 07:59:47 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AE153A22CE for ; Mon, 26 Apr 2021 07:59:47 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 13QExi7d041377; Mon, 26 Apr 2021 16:59:44 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id EF381206C42; Mon, 26 Apr 2021 16:59:43 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id DECA0202AD5; Mon, 26 Apr 2021 16:59:43 +0200 (CEST) Received: from [10.14.5.141] ([10.14.5.141]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 13QExgY5026336; Mon, 26 Apr 2021 16:59:43 +0200 To: William Whyte , Mounira MSAHLI Cc: "its@ietf.org" References: <01d601d731e3$140e2ed0$3c2a8c70$@eurecom.fr> <0600020f-b6ca-4d6d-2499-817586bc3548@gmail.com> <19dce5f5-8dca-55c2-4d46-bb83046562ab@gmail.com> <1ec103fe-7a50-cb2c-0763-30cc6362bf13@gmail.com> From: Alexandre Petrescu Message-ID: <2c4e66a9-526a-1d6e-fff8-b8eee2091111@gmail.com> Date: Mon, 26 Apr 2021 16:59:42 +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] wish list for CAs for vehicular networks X-BeenThere: its@ietf.org 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 14:59:53 -0000 Le 26/04/2021 à 16:29, William Whyte a écrit : >>> - the specs of CA must be implementable independently of other >>> paying > sources such as (some) from IEEE or ISO. For example, the ETSI ITS > spec that IMPORTS 1609.2 does not qualify because in the end it is > paying. But the X.509 in RFC 5280 does not rely on other paying > documents in order to implement (I think?). > >>> William could answer you this question better than me because it >>> was > already asked by ETSI. > > Yes, 1609.2 needs to be purchased from IEEE. ETSI has reproduced the > ASN.1 (with permission from IEEE) but there are some subtleties of > implementation and how the crypto operations are carried out that > aren’t captured in the ASN.1 alone. > > I’d note that Alex’s preference for standards to be freely available > if they are to be referenced by IETF is a reasonable point of view, Thanks, but I did not really say that. I said that if one wants to implement the ETSI TS 103 097 whose grammar is free of access one still needs to pay IEEE for the 1609.2 grammar because of that 'IMPORT' statement present in the former. That is between ETSI and IEEE. I was not talking about RFCs and IETF. But for RFCs it is clear as well: if one wants to implement an RFC one must have full specifications fully at hand and for no price. One would need to pay the pipe to access it (i.e. the ISP), the computer to program, the coffee, but not the document itself. > but it’s not IETF policy; IETF policy allows non-free standards to > be referenced. Probably. I would need to check which policy one means more precisely. But it is clear to me that IETF would not put out an RFC which needs other closed documents in order to be implemented. It is because one cant talk about text in I-Ds if we do not know the contents of the documents that they refer to (if these are closed). Alex > > Cheers, > > William > > *From:* its *On Behalf Of * Mounira MSAHLI > *Sent:* Monday, April 26, 2021 9:54 AM *To:* Alexandre Petrescu > *Cc:* its@ietf.org *Subject:* [EXT] > Re: [ipwave] wish list for CAs for vehicular networks > > Can you comment on this wish list? > > Wish list for CAs for vehicular networks > >>> - the CA must be reachable on IPv6, and their website too. > > Could you please mention why not IPv4 ? > > - the specs of CAs for vehicular networks must be available on IPv6 > (e.g. on an IPv6 website, FTP directory, or GIT shared space). > > You mean certificate policy. I have the same question. You are > specifying the IP protocol for the PKI website. I agree that > document must be published and available to PKI users but why IPV6 ? > > - the specs of CA must be implementable independently of other paying > sources such as (some) from IEEE or ISO. For example, the ETSI ITS > spec that IMPORTS 1609.2 does not qualify because in the end it is > paying. But the X.509 in RFC 5280 does not rely on other paying > documents in order to implement (I think?). > > William could answer you this question better than me because it was > already asked by ETSI. > > - the CA must offer OCSP reachability on IPv6. > > I find that all recommandations are related to the use of IPv6 not > really the > > security or privacy in C-ITS. By analogy with what you are > suggesting, I think that you would prefer to use IPv6 for the > upload of log and download of updates and all V2I communications not > only V2PKI connexion. > > Mounira > From nobody Mon Apr 26 08:03:19 2021 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C0D33A22FD for ; Mon, 26 Apr 2021 08:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.632 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EWeuypkL8790 for ; Mon, 26 Apr 2021 08:03:13 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02F1F3A22FC for ; Mon, 26 Apr 2021 08:03:12 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (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 pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 658792031B9; Mon, 26 Apr 2021 17:03:09 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 5580D201860; Mon, 26 Apr 2021 17:03:09 +0200 (CEST) Received: from [10.14.5.141] ([10.14.5.141]) by muguet1-sys.intra.cea.fr (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?= Cc: IPWAVE WG References: <01d601d731e3$140e2ed0$3c2a8c70$@eurecom.fr> From: Alexandre Petrescu Message-ID: <5d251ef1-ffb0-0a3e-346a-9077517c6a40@gmail.com> 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-BeenThere: its@ietf.org 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. Alex > > 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@ietf.org https://www.ietf.org/mailman/listinfo/its >> >> _______________________________________________ its mailing list >> its@ietf.org https://www.ietf.org/mailman/listinfo/its > From nobody Mon Apr 26 08:03:35 2021 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A3A63A22FF for ; Mon, 26 Apr 2021 08:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g4UHy0W0odf3 for ; Mon, 26 Apr 2021 08:03:29 -0700 (PDT) Received: from esa.hc3962-90.iphmx.com (esa.hc3962-90.iphmx.com [216.71.142.165]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B34523A2300 for ; Mon, 26 Apr 2021 08:03:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qccesdkim1; t=1619449409; x=1620054209; h=from:to:cc:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version:subject; bh=LPKRfZYXCf4TxQ6VPO/xlEvhcvkS/66wxv1+YywOYpA=; b=qTsiE+imheyvpERuPjYICGuk0KvZwPRRY6FgZUcHu2uApzWQVC+Mq/sR AEl9lpCycYcpXxwU1q0qvUdJ7q36bSKuAq6cOO4JUGXKTdvFThizZ7lT+ gm/QlwsNcibVqBxbtzh55QHY80JSfMUYBrpP6JydNSRahEinDP58Qqj9+ Y=; IronPort-SDR: 3CFjrYxBDzgsmDPUldj4GqLeDRacIBJ5gCx9Z0SbVzYFWrTQIShEPcr00mNM9aFuz0Rt8+17G3 pDn1gl+e1+D6Ajr6ZxR28Hn+g0rTp77W/L/AxlCbYdNjuMxbMlxI15cgVTtYWi93T0W8EKcIJ1 toGSsOr9UY5I8wXEWhp5uHAGPykZ+0+0qwfSjdMWmlL1Y22sX+57cp0L1oi+HZeGn+bUTfI1FX J7zWr3QsBs3OiHaFQEXZWhRY3ZPju+ys6ZIi5yR0q6xK/kB0oXoHvQ4kZupqT5A4lXC32WTwzA tcE= X-IronPort-RemoteIP: 104.47.55.103 X-IronPort-MID: 21838 X-IronPort-Reputation: None X-IronPort-Listener: OutgoingMail X-IronPort-SenderGroup: RELAY_O365 X-IronPort-MailFlowPolicy: $RELAYED Thread-Topic: Re: [ipwave] wish list for CAs for vehicular networks Received: from mail-mw2nam10lp2103.outbound.protection.outlook.com (HELO NAM10-MW2-obe.outbound.protection.outlook.com) ([104.47.55.103]) by ob1.hc3962-90.iphmx.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Apr 2021 15:03:28 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PmTI4Lm8lyBesQ3GhW3T27Jf4nAogEv5MrZzrdlhE5amilrNkIWadJT0j9rf1bT18he7PbjF/OFbmex5PaEurk1YyXjaYvwfyb/iIjghagHHmn0Hx7xPLTJID2JJ/Bko8q0b7lb2YnwseBnVUvANII5f6LRaP0DsLZso7hukhJdT0W0T4acwIGBDRztwFCedB4QU8FCWqdGSdgT0NeBckQYUGJIknJJTt1BrAUmJ2PZwKSuTZy5AXq2rMvx8aKzgchWOuxVsKdcLNjtgR74QA3K2MtJ6QWI69DgavVfNmPQhkKhY0FNNytjnZgmfz+tnPqkQjKqWTZie1eIS+fg0mA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LPKRfZYXCf4TxQ6VPO/xlEvhcvkS/66wxv1+YywOYpA=; b=efEm+Kr2Xba/JIBGO4TUIpnfDXdGp3r010YzyQ5nxV89CIohrIs9y9Qzc4UFq6w/8hBiFNR0y9d71PF6whmv3eGmfEpMtPG5vCazuleYR9xx4353cj3c+wBCRFFrTaEYQTgAVGVYr2s0llaEKc1DKFw+vIoZkTNsMhW/19i1pBOey+mf84aFE5+vCcFCyYq3pECafRPYJKEjBbCCBJmrE7DhOUupUNOeseMWrFfu8pauOH2vTxSNhuC8boQNR0gvi2kYhTRDRKuPRfyUgjaMI5RFn3nynNl8NfBZI/BvfaEZ23aJsST4tvA6YNw2DMpltfD98fl+1nQpZQUenCk5NQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=qti.qualcomm.com; dmarc=pass action=none header.from=qti.qualcomm.com; dkim=pass header.d=qti.qualcomm.com; arc=none Received: from MN2PR02MB6591.namprd02.prod.outlook.com (2603:10b6:208:15f::17) by MN2PR02MB5775.namprd02.prod.outlook.com (2603:10b6:208:119::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.25; Mon, 26 Apr 2021 15:03:24 +0000 Received: from MN2PR02MB6591.namprd02.prod.outlook.com ([fe80::8178:7533:16e:f843]) by MN2PR02MB6591.namprd02.prod.outlook.com ([fe80::8178:7533:16e:f843%7]) with mapi id 15.20.4065.026; Mon, 26 Apr 2021 15:03:23 +0000 From: William Whyte To: Alexandre Petrescu , Mounira MSAHLI CC: "its@ietf.org" Thread-Index: AQHXN4+awWhPVRb0MkmmKa9bu5nfd6rAy02AgAEpIACAAxV9AIABmA0AgAA2IICAAAjfIIAACX0AgAAAvtA= Date: Mon, 26 Apr 2021 15:03:23 +0000 Message-ID: References: <01d601d731e3$140e2ed0$3c2a8c70$@eurecom.fr> <0600020f-b6ca-4d6d-2499-817586bc3548@gmail.com> <19dce5f5-8dca-55c2-4d46-bb83046562ab@gmail.com> <1ec103fe-7a50-cb2c-0763-30cc6362bf13@gmail.com> <2c4e66a9-526a-1d6e-fff8-b8eee2091111@gmail.com> In-Reply-To: <2c4e66a9-526a-1d6e-fff8-b8eee2091111@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none; gmail.com; dmarc=none action=none header.from=qti.qualcomm.com; x-originating-ip: [173.48.177.63] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 64ac8a23-d579-44d6-5fff-08d908c47046 x-ms-traffictypediagnostic: MN2PR02MB5775: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: e2XHlTjoMHmDE31BlRTOqm8eOcm0HjyCioTDtQdx2wwYpQDRRMRy71mTg5JLAXkinXnV3Jj6NimA4QIjBr4bc4E7iGL9xqWXo7cTnPu+uqJuEiwjYiP0HgfnKyDOcc/eTS890nImS2HxBdVUoDp8Icvb4TxrBUEPs0GeDHgkf87pKpoo2JUXvTC5kggaJz4UOOowIJq21F3/k0via3T/+/2kZa9+MKM/qsMfvKv5D0hMqayAo+PNzv0bEOPV4ZWmj+zIB3dea5cjLUzPPlenPOn9WQ67jJl97E904phwF2fk3Sd9QwWBMuXGKYkDpNG9frd6qoXKlb2mo6sHEyPgX+K1R3ZULJP3/sPxUkSdEljLmF5mQTSuuWH6Cci1SvnwN63lv25aY7aThAFZ36Ew3fe2ElSOENFi5gPZK5FIzx7y2/79/7C3AyABOPjCGdc/sUPb7xFCSjwxH//sk3A4eGUJAidZU7Dc6kfq4PqPnr3vS4RJhZKikRfXzL+ttMdG00go1LWpeuxSlfWcL7kURMInHsB1sKag2RN1JU5AKJ8KeSbpUb6frOcOVfSGXg1a9a1Edu9EO3nGhj+4es3BpTOZD+foUMiMwjS3pt01cXA= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR02MB6591.namprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(136003)(376002)(366004)(396003)(39860400002)(110136005)(83380400001)(76116006)(4326008)(66946007)(122000001)(5660300002)(186003)(8676002)(7696005)(26005)(478600001)(53546011)(33656002)(6506007)(38100700002)(55016002)(86362001)(66446008)(66476007)(64756008)(71200400001)(316002)(52536014)(66556008)(9686003)(66574015)(8936002)(2906002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?utf-8?B?UUZQWFl6QkkyeFovOTdHWVdxOFFtNHFJUVpsbU14aGtKa0hQc0hLZmNMKzFR?= =?utf-8?B?NVoxcmFVU0srTGNmQmljdnBaYVR2Tk9sVGUvL0dwLzFFc3V3RHNoVEY4VFB3?= =?utf-8?B?aXJMM0ViV2VmRWt1MmZpc0xGbGFwZElobjRxdVRuQnY3VU10Mm14VlYrSUJB?= =?utf-8?B?RktwclJoWFlLbml2MXdmR0grUVA4SGFMK2Y2UGp1dURYS2ZuUjRhR3FyQi9k?= =?utf-8?B?bWFwQ3gyeWF5aXhPWjRkMmpTYjhGZnZHa0oxRGx3Yllqc3VrZzVnN3VvMU5v?= =?utf-8?B?WlRQcHRjUURJN3JrL0VPRjBiemRXb0d1dFREVHVCNHlnRVZLekFWWmhaNmtY?= =?utf-8?B?TlVjeWVXaEpUdjZMYzZjZWYrYnZsR05USzJKbWh6Vld1dlF2bVk1MlE3M08x?= =?utf-8?B?UTVsNmhtMGlicCtlL05abWZZL0FjWGZNUmtOUFl4cTZNVnFYSHdCUHZtVkFW?= =?utf-8?B?aVRFR0FDZHh0Yms5NlNlMFNBVHAwSksyVnFNWk9GU3dxWjd1NFZsc3FUTGpm?= =?utf-8?B?QzNzU08xVm1vZ1lkWWJxdDJNU0VwRnNsVkNEdXZ0R0ViRHNvaUhTRHJHKzly?= =?utf-8?B?TnNKMXNURFlxN2JFTFQzUkQzcFlRUVhSbWozOVdlakZhankxMko0SnpQeUpi?= =?utf-8?B?MTVLTG1HVWd2NWdQcnFlQXhWc0o1aFFkeXdtNjY0VDk5dnl1akpHQ0IwSlZE?= =?utf-8?B?ajJNS0dFOGM0Nzd3Q1BKRERibHNiME9qYzV3QUtRYW10QzVVdkJJWGNPSmNU?= =?utf-8?B?L3E5ZEx5bFFlYnEzM0NTdjR6cUJKMnpiZllCZU94SHhpQ1JDeFd0dGRCbHdl?= =?utf-8?B?TFpucmRPTmxPNWxJT3dhZXVmVC9OWnVnckxXMHVoNi9tcDBJd2dqcnAvU3ph?= =?utf-8?B?ZHRFVHJUTHRqR1hNWmxHTWhZTlpNbnhDbE9iQ1FiK1ZnVkloRVg1M202bVhZ?= =?utf-8?B?d1JrbXBSQStEckdwSXR2Nm9OcCtjRVdEMUMxZ3QzK0RiSTdkeG81WXdOaUo3?= =?utf-8?B?cnBROWdjdERiNytzYzJXZnRZbTlyMFBiQVNEVVByNDNMZ0ZkZUpYcS9VMU5a?= =?utf-8?B?TTRZbVZBZUUweHFNdjNFbDFtWXRkZ0xzMlR4YmlCMVR3VG9RRkVlUmRDdldv?= =?utf-8?B?d093ZWU2NmpXZzh3cWFlV3R5VmFxeENORDZ2TXJsL3A1WUc5UmZ0VzJBbGQ1?= =?utf-8?B?K25LV3BVajFlTkpwYkl0b01xU2d6ODRJbnd3ZENRZ3NBU2FoN29OME1ZclhF?= =?utf-8?B?Qlc4Q0g3Z0h5aFZqZlZuSFQxbmVvVks4dFBOV3MvNFdCZU9QMXg0VFZBeXRB?= =?utf-8?B?N0JxcGIwUWpTUDdMN0laREloTC9TaG50Y2U1eXFBWGFrM3REMnA2WjdyUk9o?= =?utf-8?B?MFp1VEpHODE1ME8wWWZGK0QyYXcrZWdxcWNLNCt5eklkUnpkSFJOdHdudWNj?= =?utf-8?B?Rjk4RnZCeTdHNEN6YnJGYnFBSUhhZWloUTl6dWdGSlBGWkxERys4em12aDh2?= =?utf-8?B?L2tLZEVFSm54blpaSkpZSHdOSXdBYU43dGd6WDFZbkhvbG9valRaeWlpaU5M?= =?utf-8?B?QjRKU0J4NXRLd0xtc00vVjFyZWhqeVRtNGU0WW9GMEsxODBEREZyc3AyQUR6?= =?utf-8?B?ZG1wZ2NvcTl5WkE4LzE3anVOWXRUTXRvSUtlbDhOSGtJYTgxTkJocUw5VklT?= =?utf-8?B?bGp3MzhvOUxzdVFieU9uOVVidkk0dXdWYkE1eWwxcXpkSkhMZk03cXlQY29m?= =?utf-8?Q?y0r6T9hj12qV5j3y5iRER+HSj9a1hOBZmCo2vSo?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: qti.qualcomm.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR02MB6591.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 64ac8a23-d579-44d6-5fff-08d908c47046 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Apr 2021 15:03:23.8574 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 98e9ba89-e1a1-4e38-9007-8bdabc25de1d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: NbVmwW+ZWXneZDGlpesAstLT4kPG8vVpSyxba4AIHXsoQ4Ry1T8bysEqd9Ujj4om8namAvIbo1+yHFFroulDvQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR02MB5775 Archived-At: Subject: Re: [ipwave] wish list for CAs for vehicular networks X-BeenThere: its@ietf.org 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:34 -0000 VGhlIElNUE9SVCBzdGF0ZW1lbnQgaW1wb3J0cyB0aGUgMTYwOS4yIEFTTi4xLCBidXQgRVRTSSBo YXMgcGVybWlzc2lvbnMgdG8gcmVwdWJsaXNoIGl0Lg0KDQo+PiBJdCBpcyBiZWNhdXNlIG9uZSBj YW50IHRhbGsgYWJvdXQgdGV4dCBpbiBJLURzIGlmIHdlIGRvIG5vdCBrbm93IHRoZQ0KY29udGVu dHMgb2YgdGhlIGRvY3VtZW50cyB0aGF0IHRoZXkgcmVmZXIgdG8gKGlmIHRoZXNlIGFyZSBjbG9z ZWQpLg0KDQoiYXZhaWxhYmxlIGZvciBhIHByaWNlIiBpcyBub3QgdGhlIHNhbWUgYXMgY2xvc2Vk LCBhbmQgSUVURiBwb2xpY3kgZG9lcyBub3QgY29uc2lkZXIgZG9jdW1lbnRzIGNsb3NlZCBpZiB0 aGV5IGFyZSBwdWJsaWNseSBhdmFpbGFibGUgZm9yIGEgcHJpY2UuDQoNCkNoZWVycywNCg0KV2ls bGlhbQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQWxleGFuZHJlIFBldHJl c2N1IDxhbGV4YW5kcmUucGV0cmVzY3VAZ21haWwuY29tPiANClNlbnQ6IE1vbmRheSwgQXByaWwg MjYsIDIwMjEgMTE6MDAgQU0NClRvOiBXaWxsaWFtIFdoeXRlIDx3d2h5dGVAcXRpLnF1YWxjb21t LmNvbT47IE1vdW5pcmEgTVNBSExJIDxtc2FobGkxNzE3QGdtYWlsLmNvbT4NCkNjOiBpdHNAaWV0 Zi5vcmcNClN1YmplY3Q6IFtFWFRdIFJlOiBbaXB3YXZlXSB3aXNoIGxpc3QgZm9yIENBcyBmb3Ig dmVoaWN1bGFyIG5ldHdvcmtzDQoNCg0KDQpMZSAyNi8wNC8yMDIxIMOgIDE2OjI5LCBXaWxsaWFt IFdoeXRlIGEgw6ljcml0IDoNCj4+PiAtIHRoZSBzcGVjcyBvZiBDQSBtdXN0IGJlIGltcGxlbWVu dGFibGUgaW5kZXBlbmRlbnRseSBvZiBvdGhlciANCj4+PiBwYXlpbmcNCj4gc291cmNlcyBzdWNo IGFzIChzb21lKSBmcm9tIElFRUUgb3IgSVNPLiAgRm9yIGV4YW1wbGUsIHRoZSBFVFNJIElUUyAN Cj4gc3BlYyB0aGF0IElNUE9SVFMgMTYwOS4yIGRvZXMgbm90IHF1YWxpZnkgYmVjYXVzZSBpbiB0 aGUgZW5kIGl0IGlzIA0KPiBwYXlpbmcuICBCdXQgdGhlIFguNTA5IGluIFJGQyA1MjgwIGRvZXMg bm90IHJlbHkgb24gb3RoZXIgcGF5aW5nIA0KPiBkb2N1bWVudHMgaW4gb3JkZXIgdG8gaW1wbGVt ZW50IChJIHRoaW5rPykuDQo+IA0KPj4+IFdpbGxpYW0gY291bGQgYW5zd2VyIHlvdSB0aGlzIHF1 ZXN0aW9uIGJldHRlciB0aGFuIG1lIGJlY2F1c2UgaXQgDQo+Pj4gd2FzDQo+IGFscmVhZHkgYXNr ZWQgYnkgRVRTSS4NCj4gDQo+IFllcywgMTYwOS4yIG5lZWRzIHRvIGJlIHB1cmNoYXNlZCBmcm9t IElFRUUuIEVUU0kgaGFzIHJlcHJvZHVjZWQgdGhlIA0KPiBBU04uMSAod2l0aCBwZXJtaXNzaW9u IGZyb20gSUVFRSkgYnV0IHRoZXJlIGFyZSBzb21lIHN1YnRsZXRpZXMgb2YgDQo+IGltcGxlbWVu dGF0aW9uIGFuZCBob3cgdGhlIGNyeXB0byBvcGVyYXRpb25zIGFyZSBjYXJyaWVkIG91dCB0aGF0 IA0KPiBhcmVu4oCZdCBjYXB0dXJlZCBpbiB0aGUgQVNOLjEgYWxvbmUuDQo+IA0KPiBJ4oCZZCBu b3RlIHRoYXQgQWxleOKAmXMgcHJlZmVyZW5jZSBmb3Igc3RhbmRhcmRzIHRvIGJlIGZyZWVseSBh dmFpbGFibGUgDQo+IGlmIHRoZXkgYXJlIHRvIGJlIHJlZmVyZW5jZWQgYnkgSUVURiBpcyBhIHJl YXNvbmFibGUgcG9pbnQgb2YgdmlldywNCg0KVGhhbmtzLCBidXQgSSBkaWQgbm90IHJlYWxseSBz YXkgdGhhdC4NCg0KSSBzYWlkIHRoYXQgaWYgb25lIHdhbnRzIHRvIGltcGxlbWVudCB0aGUgRVRT SSBUUyAxMDMgMDk3IHdob3NlIGdyYW1tYXINCmlzIGZyZWUgb2YgYWNjZXNzIG9uZSBzdGlsbCBu ZWVkcyB0byBwYXkgSUVFRSBmb3IgdGhlIDE2MDkuMiBncmFtbWFyDQpiZWNhdXNlIG9mIHRoYXQg J0lNUE9SVCcgc3RhdGVtZW50IHByZXNlbnQgaW4gdGhlIGZvcm1lci4gIFRoYXQgaXMNCmJldHdl ZW4gRVRTSSBhbmQgSUVFRS4NCg0KSSB3YXMgbm90IHRhbGtpbmcgYWJvdXQgUkZDcyBhbmQgSUVU Ri4NCg0KQnV0IGZvciBSRkNzIGl0IGlzIGNsZWFyIGFzIHdlbGw6IGlmIG9uZSB3YW50cyB0byBp bXBsZW1lbnQgYW4gUkZDIG9uZQ0KbXVzdCBoYXZlIGZ1bGwgc3BlY2lmaWNhdGlvbnMgZnVsbHkg YXQgaGFuZCBhbmQgZm9yIG5vIHByaWNlLiAgT25lIHdvdWxkDQpuZWVkIHRvIHBheSB0aGUgcGlw ZSB0byBhY2Nlc3MgaXQgKGkuZS4gdGhlIElTUCksIHRoZSBjb21wdXRlciB0bw0KcHJvZ3JhbSwg dGhlIGNvZmZlZSwgYnV0IG5vdCB0aGUgZG9jdW1lbnQgaXRzZWxmLg0KDQoNCj4gYnV0IGl04oCZ cyBub3QgSUVURiBwb2xpY3k7IElFVEYgcG9saWN5IGFsbG93cyBub24tZnJlZSBzdGFuZGFyZHMg dG8NCj4gYmUgcmVmZXJlbmNlZC4NCg0KUHJvYmFibHkuICBJIHdvdWxkIG5lZWQgdG8gY2hlY2sg d2hpY2ggcG9saWN5IG9uZSBtZWFucyBtb3JlIHByZWNpc2VseS4NCg0KQnV0IGl0IGlzIGNsZWFy IHRvIG1lIHRoYXQgSUVURiB3b3VsZCBub3QgcHV0IG91dCBhbiBSRkMgd2hpY2ggbmVlZHMNCm90 aGVyIGNsb3NlZCBkb2N1bWVudHMgaW4gb3JkZXIgdG8gYmUgaW1wbGVtZW50ZWQuDQoNCkl0IGlz IGJlY2F1c2Ugb25lIGNhbnQgdGFsayBhYm91dCB0ZXh0IGluIEktRHMgaWYgd2UgZG8gbm90IGtu b3cgdGhlDQpjb250ZW50cyBvZiB0aGUgZG9jdW1lbnRzIHRoYXQgdGhleSByZWZlciB0byAoaWYg dGhlc2UgYXJlIGNsb3NlZCkuDQoNCkFsZXgNCg0KPiANCj4gQ2hlZXJzLA0KPiANCj4gV2lsbGlh bQ0KPiANCj4gKkZyb206KiBpdHMgPGl0cy1ib3VuY2VzQGlldGYub3JnPiAqT24gQmVoYWxmIE9m ICogTW91bmlyYSBNU0FITEkgDQo+ICpTZW50OiogTW9uZGF5LCBBcHJpbCAyNiwgMjAyMSA5OjU0 IEFNICpUbzoqIEFsZXhhbmRyZSBQZXRyZXNjdSANCj4gPGFsZXhhbmRyZS5wZXRyZXNjdUBnbWFp bC5jb20+ICpDYzoqIGl0c0BpZXRmLm9yZyAqU3ViamVjdDoqIFtFWFRdIA0KPiBSZTogW2lwd2F2 ZV0gd2lzaCBsaXN0IGZvciBDQXMgZm9yIHZlaGljdWxhciBuZXR3b3Jrcw0KPiANCj4gQ2FuIHlv dSBjb21tZW50IG9uIHRoaXMgd2lzaCBsaXN0Pw0KPiANCj4gV2lzaCBsaXN0IGZvciBDQXMgZm9y IHZlaGljdWxhciBuZXR3b3Jrcw0KPiANCj4+PiAtIHRoZSBDQSBtdXN0IGJlIHJlYWNoYWJsZSBv biBJUHY2LCBhbmQgdGhlaXIgd2Vic2l0ZSB0b28uDQo+IA0KPiBDb3VsZCB5b3UgcGxlYXNlIG1l bnRpb24gd2h5IG5vdCBJUHY0ID8NCj4gDQo+IC0gdGhlIHNwZWNzIG9mIENBcyBmb3IgdmVoaWN1 bGFyIG5ldHdvcmtzIG11c3QgYmUgYXZhaWxhYmxlIG9uIElQdjYgDQo+IChlLmcuIG9uIGFuIElQ djYgd2Vic2l0ZSwgRlRQIGRpcmVjdG9yeSwgb3IgR0lUIHNoYXJlZCBzcGFjZSkuDQo+IA0KPiBZ b3UgbWVhbiBjZXJ0aWZpY2F0ZSBwb2xpY3kuIEkgaGF2ZSB0aGUgc2FtZSBxdWVzdGlvbi4gWW91 IGFyZSANCj4gc3BlY2lmeWluZyB0aGUgSVAgcHJvdG9jb2wgZm9yIHRoZSBQS0kgd2Vic2l0ZS4g SSBhZ3JlZSB0aGF0DQo+IGRvY3VtZW50IG11c3QgYmUgcHVibGlzaGVkIGFuZCBhdmFpbGFibGUg dG8gUEtJIHVzZXJzIGJ1dCB3aHkgSVBWNiA/DQo+IA0KPiAtIHRoZSBzcGVjcyBvZiBDQSBtdXN0 IGJlIGltcGxlbWVudGFibGUgaW5kZXBlbmRlbnRseSBvZiBvdGhlciBwYXlpbmcNCj4gc291cmNl cyBzdWNoIGFzIChzb21lKSBmcm9tIElFRUUgb3IgSVNPLiAgRm9yIGV4YW1wbGUsIHRoZSBFVFNJ IElUUw0KPiBzcGVjIHRoYXQgSU1QT1JUUyAxNjA5LjIgZG9lcyBub3QgcXVhbGlmeSBiZWNhdXNl IGluIHRoZSBlbmQgaXQgaXMNCj4gcGF5aW5nLiAgQnV0IHRoZSBYLjUwOSBpbiBSRkMgNTI4MCBk b2VzIG5vdCByZWx5IG9uIG90aGVyIHBheWluZw0KPiBkb2N1bWVudHMgaW4gb3JkZXIgdG8gaW1w bGVtZW50IChJIHRoaW5rPykuDQo+IA0KPiBXaWxsaWFtIGNvdWxkIGFuc3dlciB5b3UgdGhpcyBx dWVzdGlvbiBiZXR0ZXIgdGhhbiBtZSBiZWNhdXNlIGl0IHdhcyANCj4gYWxyZWFkeSBhc2tlZCBi eSBFVFNJLg0KPiANCj4gLSB0aGUgQ0EgbXVzdCBvZmZlciBPQ1NQIHJlYWNoYWJpbGl0eSBvbiBJ UHY2Lg0KPiANCj4gSSBmaW5kIHRoYXQgYWxsIHJlY29tbWFuZGF0aW9ucyBhcmUgcmVsYXRlZCB0 byB0aGUgdXNlIG9mIElQdjYgbm90IA0KPiByZWFsbHkgdGhlDQo+IA0KPiBzZWN1cml0eSBvciBw cml2YWN5IGluIEMtSVRTLiBCeSBhbmFsb2d5IHdpdGggd2hhdCB5b3UgYXJlIA0KPiBzdWdnZXN0 aW5nLCBJIHRoaW5rICB0aGF0IHlvdSB3b3VsZCBwcmVmZXIgdG8gdXNlIElQdjYgZm9yIHRoZQ0K PiB1cGxvYWQgb2YgbG9nIGFuZCBkb3dubG9hZCBvZiB1cGRhdGVzIGFuZCBhbGwgVjJJIGNvbW11 bmljYXRpb25zIG5vdA0KPiBvbmx5IFYyUEtJIGNvbm5leGlvbi4NCj4gDQo+IE1vdW5pcmENCj4g DQo= From nobody Mon Apr 26 08:09:23 2021 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F23C3A24E5 for ; Mon, 26 Apr 2021 08:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.632 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OgYIAzPnw4tu for ; Mon, 26 Apr 2021 08:09:12 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A48533A24A3 for ; Mon, 26 Apr 2021 08:09:09 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 13QF9781044355; Mon, 26 Apr 2021 17:09:07 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 14325206CBC; Mon, 26 Apr 2021 17:09:07 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 045F3206C6E; Mon, 26 Apr 2021 17:09:07 +0200 (CEST) Received: from [10.14.5.141] ([10.14.5.141]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 13QF95JF031285; Mon, 26 Apr 2021 17:09:06 +0200 To: William Whyte , Mounira MSAHLI Cc: "its@ietf.org" References: <01d601d731e3$140e2ed0$3c2a8c70$@eurecom.fr> <0600020f-b6ca-4d6d-2499-817586bc3548@gmail.com> <19dce5f5-8dca-55c2-4d46-bb83046562ab@gmail.com> <1ec103fe-7a50-cb2c-0763-30cc6362bf13@gmail.com> <2c4e66a9-526a-1d6e-fff8-b8eee2091111@gmail.com> From: Alexandre Petrescu Message-ID: Date: Mon, 26 Apr 2021 17:09:05 +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] wish list for CAs for vehicular networks X-BeenThere: its@ietf.org 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:09:23 -0000 Le 26/04/2021 à 17:03, William Whyte a écrit : > The IMPORT statement imports the 1609.2 ASN.1, but ETSI has > permissions to republish it. > >>> It is because one cant talk about text in I-Ds if we do not know >>> the > contents of the documents that they refer to (if these are closed). > > "available for a price" is not the same as closed, and IETF policy > does not consider documents closed if they are publicly available for > a price. Fair enough. RFCs are open and fully available at no price. 1609.2 is neither. ETSI TS is open and fully available at no price but is tainted by the 1609.2 reference, so in the end it is closed and paying. In the end, one has to think about whether one wants the vehicular networks to be connected to the Internet and use the Internet trust, or otherwise be 'limited domains' (RFC8799). Alex > > Cheers, > > William > > -----Original Message----- From: Alexandre Petrescu > Sent: Monday, April 26, 2021 11:00 AM > To: William Whyte ; Mounira MSAHLI > Cc: its@ietf.org Subject: [EXT] Re: [ipwave] > wish list for CAs for vehicular networks > > > > Le 26/04/2021 à 16:29, William Whyte a écrit : >>>> - the specs of CA must be implementable independently of other >>>> paying >> sources such as (some) from IEEE or ISO. For example, the ETSI >> ITS spec that IMPORTS 1609.2 does not qualify because in the end it >> is paying. But the X.509 in RFC 5280 does not rely on other >> paying documents in order to implement (I think?). >> >>>> William could answer you this question better than me because >>>> it was >> already asked by ETSI. >> >> Yes, 1609.2 needs to be purchased from IEEE. ETSI has reproduced >> the ASN.1 (with permission from IEEE) but there are some subtleties >> of implementation and how the crypto operations are carried out >> that aren’t captured in the ASN.1 alone. >> >> I’d note that Alex’s preference for standards to be freely >> available if they are to be referenced by IETF is a reasonable >> point of view, > > Thanks, but I did not really say that. > > I said that if one wants to implement the ETSI TS 103 097 whose > grammar is free of access one still needs to pay IEEE for the 1609.2 > grammar because of that 'IMPORT' statement present in the former. > That is between ETSI and IEEE. > > I was not talking about RFCs and IETF. > > But for RFCs it is clear as well: if one wants to implement an RFC > one must have full specifications fully at hand and for no price. > One would need to pay the pipe to access it (i.e. the ISP), the > computer to program, the coffee, but not the document itself. > > >> but it’s not IETF policy; IETF policy allows non-free standards to >> be referenced. > > Probably. I would need to check which policy one means more > precisely. > > But it is clear to me that IETF would not put out an RFC which needs > other closed documents in order to be implemented. > > It is because one cant talk about text in I-Ds if we do not know the > contents of the documents that they refer to (if these are closed). > > Alex > >> >> Cheers, >> >> William >> >> *From:* its *On Behalf Of * Mounira MSAHLI >> *Sent:* Monday, April 26, 2021 9:54 AM *To:* Alexandre Petrescu >> *Cc:* its@ietf.org *Subject:* [EXT] >> Re: [ipwave] wish list for CAs for vehicular networks >> >> Can you comment on this wish list? >> >> Wish list for CAs for vehicular networks >> >>>> - the CA must be reachable on IPv6, and their website too. >> >> Could you please mention why not IPv4 ? >> >> - the specs of CAs for vehicular networks must be available on >> IPv6 (e.g. on an IPv6 website, FTP directory, or GIT shared >> space). >> >> You mean certificate policy. I have the same question. You are >> specifying the IP protocol for the PKI website. I agree that >> document must be published and available to PKI users but why IPV6 >> ? >> >> - the specs of CA must be implementable independently of other >> paying sources such as (some) from IEEE or ISO. For example, the >> ETSI ITS spec that IMPORTS 1609.2 does not qualify because in the >> end it is paying. But the X.509 in RFC 5280 does not rely on other >> paying documents in order to implement (I think?). >> >> William could answer you this question better than me because it >> was already asked by ETSI. >> >> - the CA must offer OCSP reachability on IPv6. >> >> I find that all recommandations are related to the use of IPv6 not >> really the >> >> security or privacy in C-ITS. By analogy with what you are >> suggesting, I think that you would prefer to use IPv6 for the >> upload of log and download of updates and all V2I communications >> not only V2PKI connexion. >> >> Mounira >> From nobody Mon Apr 26 08:12:32 2021 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 675823A2497 for ; Mon, 26 Apr 2021 08:12:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.632 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vtQTYehJVutb for ; Mon, 26 Apr 2021 08:12:26 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F5E23A2499 for ; Mon, 26 Apr 2021 08:12:25 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 13QFCMUA023073; Mon, 26 Apr 2021 17:12:22 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id AE653206C0B; Mon, 26 Apr 2021 17:12:22 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 9E4F62036FA; Mon, 26 Apr 2021 17:12:22 +0200 (CEST) Received: from [10.14.5.141] ([10.14.5.141]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 13QFCL0L000551; Mon, 26 Apr 2021 17:12:22 +0200 To: William Whyte , Mounira MSAHLI , "its@ietf.org" References: <01d601d731e3$140e2ed0$3c2a8c70$@eurecom.fr> <0600020f-b6ca-4d6d-2499-817586bc3548@gmail.com> <19dce5f5-8dca-55c2-4d46-bb83046562ab@gmail.com> From: Alexandre Petrescu Message-ID: Date: Mon, 26 Apr 2021 17:12:21 +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-BeenThere: its@ietf.org 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:12:30 -0000 Le 26/04/2021 à 16:25, William Whyte a écrit : > >> If your conclusion is that « this RFC is not really relevant to > ITS", this is hard to agree with because the large deployment of C-ITS. > As mentioned by William before, ITS deployments across the US, Europe > and Australia are currently using 1609.2 certificates. > > Also, ISO 21177 references and builds on RFC 8902, and 21177 is in turn > referenced by a number of SAE ITS standards in the US. Again, a few documents (ISO 21177 and SAE ITS) about which I must shut up because I dont know what to say, because I cant see them. I will not buy them. But, if needed, I can make comments about RFC8902 contents because it is open and free. I suspect that nobody wants RFC8902 modified because that would imply modifications to ISO and SAE ITS documents, so, I better dont make these comments. Alex > > William > > *From:* its *On Behalf Of * Mounira MSAHLI > *Sent:* Monday, April 26, 2021 10:08 AM > *To:* Alexandre Petrescu ; its@ietf.org > *Subject:* [EXT] Re: [ipwave] RFC8902 - TLS with ITS Certificates, > EXPERIMENTAL, and the one PKI and one Internet > > >> 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. > > In my memory, the RFC was presented by William in IPWAVE GROUP in 2019. > But IPWAVE did not host this activity as it was outside the charter as > currently written. Although there was a possibility to rewrite > the charter, but we had to wait until the two current documents being > worked on by IPWAVE had been completed so as not to defocus the group. > > If your conclusion is that « this RFC is not really relevant to ITS", > this is hard to agree with because the large deployment of C-ITS. As > mentioned by William before, ITS deployments across the US, Europe and > Australia are currently using 1609.2 certificates. > > Mounira > From nobody Mon Apr 26 08:33:52 2021 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 376553A2548 for ; Mon, 26 Apr 2021 08:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.632 X-Spam-Level: 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, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8xUQZzgZDsaU for ; Mon, 26 Apr 2021 08:33:48 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59DE33A2547 for ; Mon, 26 Apr 2021 08:33:48 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 13QFXk5Y002748 for ; Mon, 26 Apr 2021 17:33:46 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3A2DE206C12 for ; Mon, 26 Apr 2021 17:33:46 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 27C74206C0B for ; Mon, 26 Apr 2021 17:33:46 +0200 (CEST) Received: from [10.14.5.141] ([10.14.5.141]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 13QFXjFR010896 for ; Mon, 26 Apr 2021 17:33:45 +0200 To: IPWAVE WG From: Alexandre Petrescu Message-ID: <3ef672fb-0eda-aad3-0bbd-31836f99acf2@gmail.com> Date: Mon, 26 Apr 2021 17:33:45 +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 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: fr Archived-At: Subject: [ipwave] RFC8691 and RFC8902 X-BeenThere: its@ietf.org 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:33:51 -0000 Can TLS v2 run over IPv6 over 802.11 in OCB mode and use 1609.2 certificates? Until then, one cant publish text that says that "it is anticipated that its [TLS extension's] use will be widespread." I still wonder how could this document have been published as an RFC... it is way beyond my understanding... sorry to say so. Alex From nobody Mon Apr 26 09:21:45 2021 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83B263A2731 for ; Mon, 26 Apr 2021 09:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.846 X-Spam-Level: X-Spam-Status: No, score=-1.846 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ReXqFkODmzHj for ; Mon, 26 Apr 2021 09:21:39 -0700 (PDT) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05CDB3A2741 for ; Mon, 26 Apr 2021 09:21:38 -0700 (PDT) Received: by mail-qk1-x736.google.com with SMTP id 190so355565qkl.11 for ; Mon, 26 Apr 2021 09:21:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=x7yTMhXTsJSghMA82LUVT739qJ1QCkgySb5SORT7dlA=; b=dQCayOnjW/wrNue012ur9oSv02DZUduz9L03jYbRM8fQrbG0SxuPW869jv+UUa85PP AyfQ3aOKr79JDTCKocLufOJGY4+SC4LPeTRD4FWYLXsvGKmXKdlGmUjwsRorsctone9x 1DpwfzY+LkImXK0swHezRY2l41b3eKWsqY3SW1vDPJsfD5Ey72vOipH18XqWN/dbv4B2 /D+drH//3sR90h25E6tRgAt2F/pPSIsICyzg0+Uy4c8B4SoamLGjSA1XuJEwLNYNuS/I GagEuZ7uGdd5z9ceVT3VyB1o7B+p548TQHNxxe+WrqQ3CYDoQIR0OSisE7H/tYYTVOtK SRLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=x7yTMhXTsJSghMA82LUVT739qJ1QCkgySb5SORT7dlA=; b=t6aFn8jXOzCQNap+k5aG2IfA00kNkwwrDtGEjOFXKz5rAX3yXAfoEOV3klHJKHBA9F Aix3K9i8Ywg+Qh555qR6ZFMWI2jAmSLqNV6ConFhY9D3U3ieMAEH6yW25w5+aluJtkGe n/nTWcU5PNiH/0DwrcPGvj2y7s3tAAta1Uby9VXKulfvHmFAsCXTKX5kxSoh/K5lUO5S Nr/iNjg+aZgAutcslAnlAUCR7ksnLqwxSy6PrTiwAbvDkNgtyzJHl7xR/a18f5wfZXJ/ lSKhXxJruuoq8VI4cXIuBGvT968oqklWCLibLK6hvKZFUhkhvSVX5B3yoeX22ZfNZNze b4fQ== X-Gm-Message-State: AOAM530Q6XaQLRlimDyeOMXFvuUTLljRA84kYZDxzEpe532mZ1iyM0WZ N9UVSJEL30PCulTQD9PLL+cs6cj0OqvaKDJq3XM= X-Google-Smtp-Source: ABdhPJzKxTQQ8vygaJ/yRA2rOBX7TIRQN3BeCplRw+d6fJ5hA/3au+ST3R9THCPtNcKLgA5byqKT3T1qy6lB073i+h8= X-Received: by 2002:ae9:ed84:: with SMTP id c126mr17978084qkg.309.1619454095474; Mon, 26 Apr 2021 09:21:35 -0700 (PDT) MIME-Version: 1.0 References: <3ef672fb-0eda-aad3-0bbd-31836f99acf2@gmail.com> In-Reply-To: <3ef672fb-0eda-aad3-0bbd-31836f99acf2@gmail.com> From: Mounira MSAHLI Date: Mon, 26 Apr 2021 18:21:24 +0200 Message-ID: To: Alexandre Petrescu Cc: IPWAVE WG Content-Type: multipart/alternative; boundary="00000000000017456e05c0e28a80" Archived-At: Subject: Re: [ipwave] RFC8691 and RFC8902 X-BeenThere: its@ietf.org 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 16:21:44 -0000 --00000000000017456e05c0e28a80 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable >> Can TLS v2 run over IPv6 over 802.11 in OCB mode and use 1609.2 certificates? Why: IPv6 over 802.11 in OCB is not compatible with TLS 1.3 ? Mounira Le lun. 26 avr. 2021 =C3=A0 17:33, Alexandre Petrescu < alexandre.petrescu@gmail.com> a =C3=A9crit : > Can TLS v2 run over IPv6 over 802.11 in OCB mode and use 1609.2 > certificates? > > Until then, one cant publish text that says that "it is anticipated that > its [TLS extension's] use will be widespread." > > I still wonder how could this document have been published as an RFC... > it is way beyond my understanding... sorry to say so. > > Alex > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > --00000000000017456e05c0e28a80 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>>= ; Can TLS v2 run over IPv6 over 802.11 in OCB mode and use 1609.2 =C2=A0cer= tificates?=C2=A0

Why: IPv6 ove= r 802.11 in OCB is not compatible with TLS 1.3 ?=C2=A0

Mounira

Le=C2=A0lun. 26 avr. 2021 =C3=A0=C2=A017:33, Alexandre Petr= escu <alexandre.petrescu= @gmail.com> a =C3=A9crit=C2=A0:
Can TLS v2= run over IPv6 over 802.11 in OCB mode and use 1609.2
certificates?

Until then, one cant publish text that says that "it is anticipated th= at
its [TLS extension's] use will be widespread."

I still wonder how could this document have been published as an RFC... it is way beyond my understanding... sorry to say so.

Alex

_______________________________________________
its mailing list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its
--00000000000017456e05c0e28a80-- From nobody Mon Apr 26 09:55:12 2021 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FDD13A289E for ; Mon, 26 Apr 2021 09:55:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.632 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m9lSzgq1SZZf for ; Mon, 26 Apr 2021 09:55:06 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28C213A289C for ; Mon, 26 Apr 2021 09:55:05 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 13QGt2SL010533; Mon, 26 Apr 2021 18:55:02 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 0062D206D92; Mon, 26 Apr 2021 18:55:02 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id E4003206D57; Mon, 26 Apr 2021 18:55:01 +0200 (CEST) Received: from [10.14.5.141] ([10.14.5.141]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 13QGt1Yk007030; Mon, 26 Apr 2021 18:55:01 +0200 To: Mounira MSAHLI Cc: IPWAVE WG References: <3ef672fb-0eda-aad3-0bbd-31836f99acf2@gmail.com> From: Alexandre Petrescu Message-ID: <970faf67-00b1-24b1-a2b0-7847491dd3a4@gmail.com> Date: Mon, 26 Apr 2021 18:55:01 +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] RFC8691 and RFC8902 X-BeenThere: its@ietf.org 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 16:55:10 -0000 Le 26/04/2021 à 18:21, Mounira MSAHLI a écrit : >>> Can TLS v2 run over IPv6 over 802.11 in OCB mode and use 1609.2 > certificates? > > Why: IPv6 over 802.11 in OCB is not compatible with TLS 1.3 ? In principle it should be, but has one tried it? Then, if one tried it, did her (or him) try the RFC8902 extension? Alex > > Mounira > > Le lun. 26 avr. 2021 à 17:33, Alexandre Petrescu > > > a écrit : > > Can TLS v2 run over IPv6 over 802.11 in OCB mode and use 1609.2 > certificates? > > Until then, one cant publish text that says that "it is anticipated > that its [TLS extension's] use will be widespread." > > I still wonder how could this document have been published as an > RFC... it is way beyond my understanding... sorry to say so. > > Alex > > _______________________________________________ its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > From nobody Mon Apr 26 10:18:39 2021 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 837613A298B for ; Mon, 26 Apr 2021 10:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.669 X-Spam-Level: X-Spam-Status: No, score=0.669 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_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LovRw7YwKTap for ; Mon, 26 Apr 2021 10:18:32 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94FD73A297B for ; Mon, 26 Apr 2021 10:18:32 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 13QHITDD026137; Mon, 26 Apr 2021 19:18:29 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id CD42A206D87; Mon, 26 Apr 2021 19:18:29 +0200 (CEST) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id B3A3C206D81; Mon, 26 Apr 2021 19:18:29 +0200 (CEST) Received: from [10.14.0.208] ([10.14.0.208]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 13QHIN43014703; Mon, 26 Apr 2021 19:18:24 +0200 To: William Whyte , Mounira MSAHLI Cc: "its@ietf.org" References: <01d601d731e3$140e2ed0$3c2a8c70$@eurecom.fr> <0600020f-b6ca-4d6d-2499-817586bc3548@gmail.com> <19dce5f5-8dca-55c2-4d46-bb83046562ab@gmail.com> <1ec103fe-7a50-cb2c-0763-30cc6362bf13@gmail.com> From: Alexandre Petrescu Message-ID: Date: Mon, 26 Apr 2021 19:18:22 +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] permission X-BeenThere: its@ietf.org 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 17:18:38 -0000 Le 26/04/2021 à 16:29, William Whyte a écrit : >>> - the specs of CA must be implementable independently of other >>> paying > sources such as (some) from IEEE or ISO. For example, the ETSI ITS > spec that IMPORTS 1609.2 does not qualify because in the end it is > paying. But the X.509 in RFC 5280 does not rely on other paying > documents in order to implement (I think?). > >>> William could answer you this question better than me because it >>> was > already asked by ETSI. > > Yes, 1609.2 needs to be purchased from IEEE. ETSI has reproduced the > ASN.1 (with permission from IEEE) Is that permission from IEEE only for ETSI or is it for me too? Because the text says: "This clause provides the relevant ASN.1 modules from IEEE Std 1609.2 [1] (and its amendments), reprinted with permission from IEEE, Copyright © 2016." To me, that means a permission to print, but not necessarily to put in code. Alex but there are some subtleties of > implementation and how the crypto operations are carried out that > aren’t captured in the ASN.1 alone. > > I’d note that Alex’s preference for standards to be freely available > if they are to be referenced by IETF is a reasonable point of view, > but it’s not IETF policy; IETF policy allows non-free standards to be > referenced. > > Cheers, > > William > > *From:* its *On Behalf Of * Mounira MSAHLI > *Sent:* Monday, April 26, 2021 9:54 AM *To:* Alexandre Petrescu > *Cc:* its@ietf.org *Subject:* [EXT] > Re: [ipwave] wish list for CAs for vehicular networks > > Can you comment on this wish list? > > Wish list for CAs for vehicular networks > >>> - the CA must be reachable on IPv6, and their website too. > > Could you please mention why not IPv4 ? > > - the specs of CAs for vehicular networks must be available on IPv6 > (e.g. on an IPv6 website, FTP directory, or GIT shared space). > > You mean certificate policy. I have the same question. You are > specifying the IP protocol for the PKI website. I agree that document > must be published and available to PKI users but why IPV6 ? > > - the specs of CA must be implementable independently of other > paying sources such as (some) from IEEE or ISO. For example, the > ETSI ITS spec that IMPORTS 1609.2 does not qualify because in the end > it is paying. But the X.509 in RFC 5280 does not rely on other > paying documents in order to implement (I think?). > > William could answer you this question better than me because it was > already asked by ETSI. > > - the CA must offer OCSP reachability on IPv6. > > I find that all recommandations are related to the use of IPv6 not > really the > > security or privacy in C-ITS. By analogy with what you are > suggesting, I think that you would prefer to use IPv6 for the upload > of log and download of updates and all V2I communications not only > V2PKI connexion. > > Mounira > From nobody Mon Apr 26 12:13:13 2021 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAFCE3A2375 for ; Mon, 26 Apr 2021 12:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.632 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqY5ZWkh0Ezb for ; Mon, 26 Apr 2021 12:13:06 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F46B3A2373 for ; Mon, 26 Apr 2021 12:13:06 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 13QJD4nx047487 for ; Mon, 26 Apr 2021 21:13:04 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 2B511206DFF for ; Mon, 26 Apr 2021 21:13:04 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 2194F206C0B for ; Mon, 26 Apr 2021 21:13:04 +0200 (CEST) Received: from [10.14.1.122] ([10.14.1.122]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 13QJD29l032020 for ; Mon, 26 Apr 2021 21:13:03 +0200 To: its@ietf.org References: <2613B82E-CE1C-4E1F-9AA5-CA3605097FD1@cisco.com> <2eb82021-504a-243c-fc77-8783c0573789@gmail.com> <981b8bd1-bef1-7d4a-a2b3-f3a7edf2e8a7@gmail.com> <96a0feab-312d-a8b9-60af-00d105aca3a5@gmail.com> <171e6328-479a-6018-ee33-49066efb8d43@gmail.com> <866c1a90-c0eb-35e7-137f-f0615b5d606c@gmail.com> <75fc258f-3a25-0d13-0abc-4a0e8a2748d6@gmail.com> From: Alexandre Petrescu Message-ID: Date: Mon, 26 Apr 2021 21:13:02 +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: <75fc258f-3a25-0d13-0abc-4a0e8a2748d6@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] V2X and Mitsubishi X-BeenThere: its@ietf.org 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 19:13:12 -0000 I learn from TV advertisement that Mitsubishi puts V2X on hybrid rechargeable vehicles now on market. It is a great news at first sight. Only VW announced similar things here until now (see below Car2X). But, V2X means that the vehicle can plug into a variety of electric sockets at home, on building, on grids... It does not mean it sends CAM messages. It does not even mean that it sends messages to the charging spot. Once again this V2X term means something entirely new I hear for the first time. I am not sure whether we want this term V2X better reflected in draft-ietf-ipwave-vehicular-networking-20 or that people at 3GPP want to update their definition of V2X, or not. With such huge disconnects on such simple things as the term V2X it might be that there is little hope in progressing towards unification. Alex Le 02/03/2020 à 17:03, Alexandre Petrescu a écrit : > A club in Austria tested the Car2X of VW Golf 8 and reported in > Austrian there > https://www.oeamtc.at/thema/verkehr/car-to-x-kommunikation-36583208 > > An English text pointing to that URL is this: > >> Monday 24 of February 2020 >> >> The latest generation of the VW Golf is the first vehicle to be >> equipped with Car-to-X communication (C2X) as standard. >> >> "This technology enables the car to exchange information with >> other vehicles as well as with the infrastructure," explains ÖAMTC >> technician Friedrich Eppel. >> >> In practice, this works - to put it simply - like this: If the >> Golf's sensors detect a danger or if an emergency braking >> manoeuvre is initiated or the airbag is triggered in the event of >> an accident, it automatically warns other vehicles in the vicinity >> by radio signal. Conversely, it registers warnings and information >> coming from other vehicles or the infrastructure and passes them >> on to the driver. While driving, for example, the driver is warned >> that an accident has occurred several hundred metres ahead of him. >> >> The Mobility Club has investigated this system together with its >> partners - with promising results. >> > On another related note, I learn that the online configurator > includes 'Car2X version High' as a series equipment (not an add on > more expensive) on all Golf 8 models advertised on the web in > France. > > Finally, I am interested to learn whether VW Golf 8 Car2X > understands the Road-Side Units deployed in France that beacon DENM > and CAM messages to all cars on the road. > > Alex > > Le 14/01/2020 à 09:58, Alexandre Petrescu a écrit : >> Thank you for the update. >> >> I guess s/he would need to access the Internet in order to "sign >> in"(?) >> >> Alex >> >> Le 14/01/2020 à 07:48, Dr. Hans-Joachim Fischer a écrit : >>> >>> Dear all, >>> >>> >>> Volkswagen confirmed to me that Golf 8 has an ITS station unit >>> with ITS-G5 built in. In order to get it activated the owner >>> needs to "sign in". >>> >>> >>> Hans-Joachim >>> >>> Am 13.01.2020 um 17:38 schrieb Alexandre Petrescu: >>>> the first hands-on reviews of the VW 8 are in the printed >>>> press: no sign of WLANp, nor ITS-G5 or C2C messaging as of >>>> yet. It might be because the reviewer is not interested in >>>> these aspects (no other mentioning of other connectivity >>>> features like webradio or wifi on board or remote software >>>> update) or it might be because these WLANp features are absent >>>> from actual deployment. >>>> >>>> the first VW Golf 8 is announced to be sold in France for mid >>>> 2020, with prices announced in March. >>>> >>>> Le 04/12/2019 à 17:10, Alexandre Petrescu a écrit : >>>>> I got to learn about VW Golf 8th generation (VW Golf 8, VW 8 >>>>> for our discussion). >>>>> >>>>> On Oct. 24th they announced it on the web; it says uniquely >>>>> (strangely) 'WLANp' and 'Car2X'. These seem terms only use >>>>> by VW, while others say 802.11p or Car2Car Consortium or >>>>> V2X. The announcement in French text says 'WiFi' instead of >>>>> 802.11p, which is wrong again. >>>>> >>>>> Some of the features in the announcement text make think >>>>> there is some Bluetooth and NFC in there as well >>>>> (WeConnect), and also CarPlay, AndroidAuto. I cant figure >>>>> out whether there is SIM card inside, like in Tesla. (be it >>>>> software or a typical hard sim). >>>>> >>>>> VW 8 might hit the road in Spring or Summer 2020. >>>>> >>>>> It is not clear whether the Car2X/WLANp features are series >>>>> features, or extras to be paid for. Other announcements in >>>>> America (Caddillac was that?) did the same, and the 11p was >>>>> something additional to be sold for a series car. >>>>> >>>>> Once VW 8 is on the market, there are few places (Grenoble, >>>>> Paris area, Versailles) where I discussed with people and >>>>> might be interested to learn whether that VW 8 understands >>>>> the RSUs in these areas. >>>>> >>>>> VW made a similar announcement of a series car 'Arteon' in >>>>> 2017 and later in 2018 that is controlled by infrastructure >>>>> (respect speed limits); that could only be with V2X. However, >>>>> it did not materialize once the car hit the roads. Or at >>>>> least I am not aware of that materialization. >>>>> >>>>> A discussion I had with someone who knows someone explains >>>>> that a competitor of VW (Daimler) is more interested in the >>>>> cellular aspects (e.g. LTE-V2X, even if this term itself is >>>>> more of a VW term some times), and not at all in 802.11p, >>>>> which is itself not right (the right term is 802.11-OCB). >>>>> >>>>> (a final note about cellular systems with V2X capabilities: >>>>> the features of cellular systems that are specific to cars >>>>> like direct V2V connectivity, or V2V2I, were announced many >>>>> times in the past for 2.5G, 3G and 4G; they were never put >>>>> to market either). >>>>> >>>>> Alex >>>>> >>>>> _______________________________________________ its mailing >>>>> list its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>> >>>> _______________________________________________ its mailing >>>> list its@ietf.org https://www.ietf.org/mailman/listinfo/its >>> >>> -- Dr. Hans-Joachim Fischer Managing Director >>> >>> -------------------------------------------------------------------------------- >>> >>> >>> >>> >>> ESF News edition 2019/1 https://fischer-tech.eu/News/ >>> >>> -------------------------------------------------------------------------------- >>> >>> >>> >>> >>> CEN/TC 278/WG 16/PT 1605 https://www.itsstandards.eu/cits/shc >>> CooperativeSecureITS@itsstandards.info >>> >>> -------------------------------------------------------------------------------- >>> >>> >>> >>> + + + Instaurare omnia in Christo + + + >>> -------------------------------------------------------------------------------- >>> >>> >>> >>> The information contained in this message is confidential and >>> may be legally privileged. This email is intended for the >>> addressee(s). Addressees may be individual persons or members of >>> mailing list. If you are not an addressee, you are hereby >>> notified that any use, dissemination, or reproduction of this >>> email and its optional attachements is strictly prohibited and >>> may be unlawful. If you are not an addressee, please contact the >>> sender by return e-mail and destroy all copies of the original >>> message. >>> -------------------------------------------------------------------------------- >>> >>> >>> >>> ESF GmbH Fichtenweg 9 89143 Blaubeuren +49 (7344) 175340 (Direct >>> line Dr. Fischer) +49 (7344) 919188 (Central office) +49 (7344) >>> 919123 (Fax) https://fischer-tech.eu : Main web of ESF GmbH >>> http://its-standards.eu : News on cooperative ITS >>> standardization >>> -------------------------------------------------------------------------------- >>> >>> >>> >>> >>> -------------------------------------------------------------------------------- >>> >>> >>> >>> ESF online-news:http://fischer-tech.eu/Feeds/esf.rss C-ITS >>> online news:http://its-standards.info/Feeds/cits.rss ESF Online >>> Nachrichten:http://fischer-tech.de/Feeds/esfD.rss >>> ------------------------------------------------------------------------------- >>> >>> >>> >>> >> >> _______________________________________________ its mailing list >> its@ietf.org https://www.ietf.org/mailman/listinfo/its > > _______________________________________________ its mailing list > its@ietf.org https://www.ietf.org/mailman/listinfo/its > From nobody Tue Apr 27 00:00:43 2021 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B65C73A0EBA for ; Tue, 27 Apr 2021 00:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NMEM8LOoLOP5 for ; Tue, 27 Apr 2021 00:00:37 -0700 (PDT) Received: from smtp2.eurecom.fr (smtp2.eurecom.fr [193.55.113.211]) by ietfa.amsl.com (Postfix) with ESMTP id 4DEA33A135E for ; Tue, 27 Apr 2021 00:00:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.82,254,1613430000"; d="scan'208";a="1683581" Received: from monza.eurecom.fr ([192.168.106.15]) by drago2i.eurecom.fr with ESMTP; 27 Apr 2021 09:00:33 +0200 Received: from portege33 (portege33.eurecom.fr [172.17.31.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by monza.eurecom.fr (Postfix) with ESMTPSA id 322F9655; Tue, 27 Apr 2021 09:00:33 +0200 (CEST) From: =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= To: "'Alexandre Petrescu'" , "'William Whyte'" , "'Mounira MSAHLI'" Cc: References: <01d601d731e3$140e2ed0$3c2a8c70$@eurecom.fr> <0600020f-b6ca-4d6d-2499-817586bc3548@gmail.com> <19dce5f5-8dca-55c2-4d46-bb83046562ab@gmail.com> <1ec103fe-7a50-cb2c-0763-30cc6362bf13@gmail.com> In-Reply-To: Date: Tue, 27 Apr 2021 09:00:33 +0200 Organization: EURECOM Message-ID: <006401d73b33$044a2d60$0cde8820$@eurecom.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en Thread-Index: AQGNE4eOrl1DVgZsmuuV5v0KN1fNOAJW1Y3IAudJi94CHB5pXwIot11sAYO0IMoCGrZz7QJ5DJU0Ap+9g7ICysu2/ALhiy8/AkOLmU4CO4rRIgEvXwBrAgiVwUuqX0/1AA== Archived-At: Subject: Re: [ipwave] permission X-BeenThere: its@ietf.org 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: Tue, 27 Apr 2021 07:00:42 -0000 Dear Alex, Dear All, I am not sure to follow here. ETSI provides on its website the ASN1 code = (a zip file) for the ETSI security framework version 1.3 (and you can = parse it into C or C++ code). We are using it on a network simulator = VANETZA. Neither the side nor the content of the .zip file indicate we = cannot use it. I am not making any commercial product though... Of course, there is a difference between accessing the document or the = ASN1 code. The ETSI Security standard v1.3 provides a full description = of the 'main' message blocks and functional requirements for all DAY 1 = ETSI services. Indeed, the ETSI document points to some 1609.2 = structures in 1609.2 documents, which I could not access, but I could = get the structures details from the ASN1 code. From my understanding and = my experience in implementing the 1.3.1 code, I do not need 1609.2 = document to make it work, all functional requirements are in the ETSI = document. One point: I only implemented the security framework stack, not the = algorithms to build public/private keys or certificate chains. Maybe for = that, there is an issue...not sure, BR, J=C3=A9r=C3=B4me -----Original Message----- From: its On Behalf Of Alexandre Petrescu Sent: Monday, 26 April 2021 19:18 To: William Whyte ; Mounira MSAHLI = Cc: its@ietf.org Subject: Re: [ipwave] permission Le 26/04/2021 =C3=A0 16:29, William Whyte a =C3=A9crit : >>> - the specs of CA must be implementable independently of other=20 >>> paying > sources such as (some) from IEEE or ISO. For example, the ETSI ITS=20 > spec that IMPORTS 1609.2 does not qualify because in the end it is=20 > paying. But the X.509 in RFC 5280 does not rely on other paying=20 > documents in order to implement (I think?). >=20 >>> William could answer you this question better than me because it was > already asked by ETSI. >=20 > Yes, 1609.2 needs to be purchased from IEEE. ETSI has reproduced the > ASN.1 (with permission from IEEE) Is that permission from IEEE only for ETSI or is it for me too? Because the text says: "This clause provides the relevant ASN.1 modules = from IEEE Std 1609.2 [1] (and its amendments), reprinted with permission = from IEEE, Copyright =C2=A9 2016." To me, that means a permission to print, but not necessarily to put in = code. Alex but there are some subtleties of > implementation and how the crypto operations are carried out that=20 > aren=E2=80=99t captured in the ASN.1 alone. >=20 > I=E2=80=99d note that Alex=E2=80=99s preference for standards to be = freely available=20 > if they are to be referenced by IETF is a reasonable point of view,=20 > but it=E2=80=99s not IETF policy; IETF policy allows non-free = standards to be =20 > referenced. >=20 > Cheers, >=20 > William >=20 > *From:* its *On Behalf Of * Mounira MSAHLI > *Sent:* Monday, April 26, 2021 9:54 AM *To:* Alexandre Petrescu=20 > *Cc:* its@ietf.org *Subject:* [EXT] > Re: [ipwave] wish list for CAs for vehicular networks >=20 > Can you comment on this wish list? >=20 > Wish list for CAs for vehicular networks >=20 >>> - the CA must be reachable on IPv6, and their website too. >=20 > Could you please mention why not IPv4 ? >=20 > - the specs of CAs for vehicular networks must be available on IPv6=20 > (e.g. on an IPv6 website, FTP directory, or GIT shared space). >=20 > You mean certificate policy. I have the same question. You are=20 > specifying the IP protocol for the PKI website. I agree that document = > must be published and available to PKI users but why IPV6 ? >=20 > - the specs of CA must be implementable independently of other paying=20 > sources such as (some) from IEEE or ISO. For example, the ETSI ITS=20 > spec that IMPORTS 1609.2 does not qualify because in the end it is=20 > paying. But the X.509 in RFC 5280 does not rely on other paying=20 > documents in order to implement (I think?). >=20 > William could answer you this question better than me because it was =20 > already asked by ETSI. >=20 > - the CA must offer OCSP reachability on IPv6. >=20 > I find that all recommandations are related to the use of IPv6 not=20 > really the >=20 > security or privacy in C-ITS. By analogy with what you are suggesting, = > I think that you would prefer to use IPv6 for the upload of log and=20 > download of updates and all V2I communications not only V2PKI=20 > connexion. >=20 > Mounira >=20 _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its From nobody Tue Apr 27 08:36:40 2021 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD7F03A1190 for ; Tue, 27 Apr 2021 08:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.632 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7-gWNvw81fN for ; Tue, 27 Apr 2021 08:36:31 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 161973A10F1 for ; Tue, 27 Apr 2021 08:36:30 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 13RFaQSC011972; Tue, 27 Apr 2021 17:36:26 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 9D379204EC4; Tue, 27 Apr 2021 17:36:26 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 8BA03204EC3; Tue, 27 Apr 2021 17:36:26 +0200 (CEST) Received: from [10.14.2.97] ([10.14.2.97]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 13RFaMQX003626; Tue, 27 Apr 2021 17:36:23 +0200 To: =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= , "'William Whyte'" , "'Mounira MSAHLI'" Cc: its@ietf.org References: <01d601d731e3$140e2ed0$3c2a8c70$@eurecom.fr> <0600020f-b6ca-4d6d-2499-817586bc3548@gmail.com> <19dce5f5-8dca-55c2-4d46-bb83046562ab@gmail.com> <1ec103fe-7a50-cb2c-0763-30cc6362bf13@gmail.com> <006401d73b33$044a2d60$0cde8820$@eurecom.fr> From: Alexandre Petrescu Message-ID: <77971e43-c900-806d-24ad-17aa57b4d36f@gmail.com> Date: Tue, 27 Apr 2021 17:36:22 +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: <006401d73b33$044a2d60$0cde8820$@eurecom.fr> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] permission X-BeenThere: its@ietf.org 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: Tue, 27 Apr 2021 15:36:39 -0000 First, let me say that I might have been wrong when I said that the ETSI code does not compile because it needed IEEE code. I must say that I never tried myself to generate the C code from ASN.1 and then compile it, for these certificates; but tried it for CAM and SPAT. Your description seems to say the ETSI code for these certificates (including the IEEE code in it) is working ok. I do not disagree. One side note is the following: one might wonder why is that IEEE document closed and paying if it is revealed in another free document (the ETSI's). One might suspect IEEE would not be happy to protect code which is later revealed by ETSI. IEEE loses money? Or I might be wrong altogether again. To clarify that, let me continue the discussion: Le 27/04/2021 à 09:00, Jérôme Härri a écrit : > Dear Alex, Dear All, > > I am not sure to follow here. ETSI provides on its website the ASN1 > code (a zip file) for the ETSI security framework version 1.3 (and > you can parse it into C or C++ code). That ASN1 code you mention, it is probably the "ASN1 structure of IEEE 1609.2 certificate and signature in the annex of ETSI TS 103 097 v 1.3.1" that Mounira was talking about. That pdf file contains the ASN.1 code too. It is sufficient to copy paste it in a textual file and then feed that into the asn1.c free softwaare package to generate C files that further compile into a library. Then call the functions from that library. > We are using it on a network simulator VANETZA. Ok, noted. It is a traffic simulator, I think. It is not a real implementation in a car that might need to interoperate. > Neither the side nor the content of the .zip file indicate we cannot > use it. I am not making any commercial product though... I have not seen the zip file, but if I were a user I would check it very carefully. The ETSI pdf file says the following with respect to Copyright: > No part may be reproduced or utilized in any form or by any means, > electronic or mechanical, including photocopying and microfilm except > as authorized by written permission of ETSI. The content of the PDF > version shall not be modified without the written authorization of > ETSI. The copyright and the foregoing restriction extend to > reproduction in all media. © ETSI 2017. All rights reserved. [...] > The present document contains material from IEEE Std 1609.2-2016 [1] > and its amendment(s), reprinted with permission from IEEE, and > Copyright © 2016. So, the question is whether VANETZA obtained that written permission from ETSI to use that ASN1 code? And if yes, have they then provided 'you' with that permission as well? (by 'you', I mean anyone who downloads VANETZA). Maybe they have, maybe they have not. But they are subject to that rule. > Of course, there is a difference between accessing the document or > the ASN1 code. The ETSI Security standard v1.3 provides a full > description of the 'main' message blocks and functional requirements > for all DAY 1 ETSI services. Indeed, the ETSI document points to some > 1609.2 structures in 1609.2 documents, which I could not access, but > I could get the structures details from the ASN1 code. Yes, but does one also understand the _meaning_ of the fields in that code? Do everybody understand it in the same way? Only with a common understanding of these fields do we reach interoperability between implementations. Otherwise we have independent compliance to standards, but not necessarily interoperability. That is the path to 'limited domains'. > From my understanding and my experience in implementing the 1.3.1 > code, I do not need 1609.2 document to make it work, all functional > requirements are in the ETSI document. I think you mean that you use the IEEE parts that are in the ETSI document. These IEEE parts are there verbatim in the ASN1 description. They are somehow self described (e.g. it is easy to understand the field that says "Latitude ::= NinetyDegreeInt"), but for full and common understanding one needs the full textual description from the IEEE document. For example, how are the points between two integer values rounded? (e.g. do the points between 800000000 and 800000001 belong to the former or to the latter? 'Floor' or 'up' function?) Maybe the IEEE document tells in its textual description. > One point: I only implemented the security framework stack, not the > algorithms to build public/private keys or certificate chains. Maybe > for that, there is an issue...not sure, I think you are right in that you might obtain ok compliance to the standard ETSI, but I am not sure it is interoperable with others that are themselves compliant with the ETSI standards in their own. All VW Golf 8 cars understand their respective Car2X messages but certainly not the V2X of Mitsubishi, and neither vice-versa. Alex > > BR, > > Jérôme > > -----Original Message----- From: its On > Behalf Of Alexandre Petrescu Sent: Monday, 26 April 2021 19:18 To: > William Whyte ; Mounira MSAHLI > Cc: its@ietf.org Subject: Re: [ipwave] > permission > > > > Le 26/04/2021 à 16:29, William Whyte a écrit : >>>> - the specs of CA must be implementable independently of other >>>> paying >> sources such as (some) from IEEE or ISO. For example, the ETSI ITS >> spec that IMPORTS 1609.2 does not qualify because in the end it is >> paying. But the X.509 in RFC 5280 does not rely on other paying >> documents in order to implement (I think?). >> >>>> William could answer you this question better than me because >>>> it was >> already asked by ETSI. >> >> Yes, 1609.2 needs to be purchased from IEEE. ETSI has reproduced >> the ASN.1 (with permission from IEEE) > > Is that permission from IEEE only for ETSI or is it for me too? > > Because the text says: "This clause provides the relevant ASN.1 > modules from IEEE Std 1609.2 [1] (and its amendments), reprinted > with permission from IEEE, Copyright © 2016." > > To me, that means a permission to print, but not necessarily to put > in code. > > Alex > > but there are some subtleties of >> implementation and how the crypto operations are carried out that >> aren’t captured in the ASN.1 alone. >> >> I’d note that Alex’s preference for standards to be freely >> available if they are to be referenced by IETF is a reasonable >> point of view, but it’s not IETF policy; IETF policy allows >> non-free standards to be referenced. >> >> Cheers, >> >> William >> >> *From:* its *On Behalf Of * Mounira MSAHLI >> *Sent:* Monday, April 26, 2021 9:54 AM *To:* Alexandre Petrescu >> *Cc:* its@ietf.org *Subject:* [EXT] >> Re: [ipwave] wish list for CAs for vehicular networks >> >> Can you comment on this wish list? >> >> Wish list for CAs for vehicular networks >> >>>> - the CA must be reachable on IPv6, and their website too. >> >> Could you please mention why not IPv4 ? >> >> - the specs of CAs for vehicular networks must be available on IPv6 >> (e.g. on an IPv6 website, FTP directory, or GIT shared space). >> >> You mean certificate policy. I have the same question. You are >> specifying the IP protocol for the PKI website. I agree that >> document must be published and available to PKI users but why IPV6 >> ? >> >> - the specs of CA must be implementable independently of other >> paying sources such as (some) from IEEE or ISO. For example, the >> ETSI ITS spec that IMPORTS 1609.2 does not qualify because in the >> end it is paying. But the X.509 in RFC 5280 does not rely on >> other paying documents in order to implement (I think?). >> >> William could answer you this question better than me because it >> was already asked by ETSI. >> >> - the CA must offer OCSP reachability on IPv6. >> >> I find that all recommandations are related to the use of IPv6 not >> really the >> >> security or privacy in C-ITS. By analogy with what you are >> suggesting, I think that you would prefer to use IPv6 for the >> upload of log and download of updates and all V2I communications >> not only V2PKI connexion. >> >> Mounira >> > > _______________________________________________ its mailing list > its@ietf.org https://www.ietf.org/mailman/listinfo/its >