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

[William Whyte <[e-mail]>]

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.

Cheers,

William

-----Original Message-----
From: Alexandre Petrescu <[e-mail]> 
Sent: Monday, April 26, 2021 11:00 AM
To: William Whyte <[e-mail]>; Mounira MSAHLI <[e-mail]>
Cc: [e-mail]
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 <[e-mail]> *On Behalf Of * Mounira MSAHLI 
> *Sent:* Monday, April 26, 2021 9:54 AM *To:* Alexandre Petrescu 
> <[e-mail]> *Cc:* [e-mail] *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
>