Re: [ipwave] permission

Alexandre Petrescu <alexandre.petrescu@gmail.com> Tue, 27 April 2021 15:36 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 CD7F03A1190 for <its@ietfa.amsl.com>; 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 <its@ietfa.amsl.com>; 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 <its@ietf.org>; 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?= <Jerome.Haerri@eurecom.fr>, "'William Whyte'" <wwhyte@qti.qualcomm.com>, "'Mounira MSAHLI'" <msahli1717@gmail.com>
Cc: 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> <c50aa38c-ab00-6ded-71e0-fd45d83c82dd@gmail.com> <006401d73b33$044a2d60$0cde8820$@eurecom.fr>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
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: <https://mailarchive.ietf.org/arch/msg/its/HlQxMi2y7hpqWEKlvmX1QNC447E>
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 <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: 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 <its-bounces@ietf.org> On
> Behalf Of Alexandre Petrescu Sent: Monday, 26 April 2021 19:18 To:
> William Whyte <wwhyte@qti.qualcomm.com>om>; Mounira MSAHLI 
> <msahli1717@gmail.com> 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 <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
>> 
> 
> _______________________________________________ its mailing list 
> its@ietf.org https://www.ietf.org/mailman/listinfo/its
>