Re: [ipwave] wish list for CAs for vehicular networks

Alexandre Petrescu <alexandre.petrescu@gmail.com> Mon, 26 April 2021 15:09 UTC

Return-Path: <alexandre.petrescu@gmail.com>
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 <its@ietfa.amsl.com>; 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 <its@ietfa.amsl.com>; 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 <its@ietf.org>; 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 <wwhyte@qti.qualcomm.com>, Mounira MSAHLI <msahli1717@gmail.com>
Cc: "its@ietf.org" <its@ietf.org>
References: <acc0f475-7f7b-bfbe-1099-913f0cef4de6@gmail.com> <01d601d731e3$140e2ed0$3c2a8c70$@eurecom.fr> <0600020f-b6ca-4d6d-2499-817586bc3548@gmail.com> <CAMEeBw9eaPBRT26BqqmXdEpqFzSTGt8w46wmexfg7ax4aRP-pQ@mail.gmail.com> <CAA2OGZCntE+FUtzKwxrsH7i_q70jjZuPoUjRG7cYmEVRHFJU8g@mail.gmail.com> <19dce5f5-8dca-55c2-4d46-bb83046562ab@gmail.com> <1ec103fe-7a50-cb2c-0763-30cc6362bf13@gmail.com> <e822da34-84df-bce0-6497-479ed1016898@gmail.com> <CAA2OGZA5-xr-mo7u7rtJvApu3XwFJLfmZsTz2Q=+RAxG=Rac6Q@mail.gmail.com> <f75e41a0-a86a-fa44-1183-28fcb0f626d9@gmail.com> <CAA2OGZDyBi1y48Smm1eA0Ogn78L_ck0-mTin+hMyzL9RUN1tJw@mail.gmail.com> <fc4cf84a-45ec-bc69-140a-998970a95b1c@gmail.com> <CAA2OGZA7i7dDU+6dv8RobT5TKFTkqxJ-PvbVYcCa=N9Xf2n4rg@mail.gmail.com> <MN2PR02MB6591ADE2799245EEFF7F7D1DF2429@MN2PR02MB6591.namprd02.prod.outlook.com> <2c4e66a9-526a-1d6e-fff8-b8eee2091111@gmail.com> <MN2PR02MB6591E532393FDA922B65570BF2429@MN2PR02MB6591.namprd02.prod.outlook.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <c5d83dad-f991-f254-1cce-6ac5dbbb494b@gmail.com>
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: <MN2PR02MB6591E532393FDA922B65570BF2429@MN2PR02MB6591.namprd02.prod.outlook.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/qGt5wuooqsD7k0thu8HkbJUgapQ>
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 <its.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/its>, <mailto:its-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/its/>
List-Post: <mailto:its@ietf.org>
List-Help: <mailto:its-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/its>, <mailto:its-request@ietf.org?subject=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
> <alexandre.petrescu@gmail.com> Sent: Monday, April 26, 2021 11:00 AM 
> To: William Whyte <wwhyte@qti.qualcomm.com>om>; Mounira MSAHLI
> <msahli1717@gmail.com> 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 <its-bounces@ietf.org> *On Behalf Of * Mounira MSAHLI 
>> *Sent:* Monday, April 26, 2021 9:54 AM *To:* Alexandre Petrescu 
>> <alexandre.petrescu@gmail.com> *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
>>