Re: [wpkops] [T17Q11] SV: [pkix] X.509 whitelist proposal

Massimiliano Pala <director@openca.org> Thu, 24 July 2014 14:33 UTC

Return-Path: <director@openca.org>
X-Original-To: wpkops@ietfa.amsl.com
Delivered-To: wpkops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 926211A034B for <wpkops@ietfa.amsl.com>; Thu, 24 Jul 2014 07:33:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.092
X-Spam-Level: **
X-Spam-Status: No, score=2.092 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_NET=0.611, HOST_EQ_IT=1.245, HOST_EQ_STATICB=1.372, SPF_PASS=-0.001] autolearn=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 w_LE7wDubLcQ for <wpkops@ietfa.amsl.com>; Thu, 24 Jul 2014 07:33:16 -0700 (PDT)
Received: from mo.hackmasters.net (static-217-133-36-163.clienti.tiscali.it [217.133.36.163]) by ietfa.amsl.com (Postfix) with ESMTP id 3D1371A024E for <wpkops@ietf.org>; Thu, 24 Jul 2014 07:33:15 -0700 (PDT)
Received: from nyc.openca.org (dragon.hackmasters.net [127.0.0.1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mo.hackmasters.net (Postfix) with ESMTPS id 6E64C15C0007 for <wpkops@ietf.org>; Thu, 24 Jul 2014 16:33:14 +0200 (CEST)
Received: from localhost (unknown [127.0.0.1]) by nyc.openca.org (Postfix) with ESMTP id 1D862154B0C7 for <wpkops@ietf.org>; Thu, 24 Jul 2014 14:26:17 +0000 (UTC)
X-Virus-Scanned: amavisd-new at openca.org
Received: from nyc.openca.org ([127.0.0.1]) by localhost (blackmamba.openca.dyndns.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vn1g-3czDnyW for <wpkops@ietf.org>; Thu, 24 Jul 2014 10:26:15 -0400 (EDT)
Received: from dhcp-b553.meeting.ietf.org (BlackMamba.OpenCA.DynDNS.Org [127.0.0.1]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by nyc.openca.org (Postfix) with ESMTPSA id 946E3154B08D for <wpkops@ietf.org>; Thu, 24 Jul 2014 10:26:15 -0400 (EDT)
Message-ID: <53D11786.3070903@openca.org>
Date: Thu, 24 Jul 2014 10:26:14 -0400
From: Massimiliano Pala <director@openca.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: wpkops@ietf.org
References: <000b01cfa1bc$b6872ef0$23958cd0$@x500.eu> <53C85314.3040102@yaanatech.com> <003301cfa26b$039c77a0$0ad566e0$@x500.eu> <53C90EC4.1070006@netmagic.com> <002501cfa286$53ffbca0$fbff35e0$@x500.eu> <CAMm+Lwiu+9-p2g7k+rjveH_4J2aGUPjFrcyQeFcC9znp2KZG_g@mail.gmail.com> <003a01cfa294$ab8c1e60$02a45b20$@x500.eu>
In-Reply-To: <003a01cfa294$ab8c1e60$02a45b20$@x500.eu>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/wpkops/gfFyAL1iJWG9HEGWkSIeyqzh32Y
Subject: Re: [wpkops] [T17Q11] SV: [pkix] X.509 whitelist proposal
X-BeenThere: wpkops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <wpkops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/wpkops>, <mailto:wpkops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/wpkops/>
List-Post: <mailto:wpkops@ietf.org>
List-Help: <mailto:wpkops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/wpkops>, <mailto:wpkops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Jul 2014 14:33:20 -0000

Hi Erik, all,

At first glance (very clear), It seems to me that this proposal is in 
between SCVP (that might be a bit complicated to implement in small 
SCADA devices) (RFC 5055), TAMP (RFC 5934), and CMC 
(id-cmc-trustedAnchors) (RFC 5272 - Section 6.15 / RFC 6402) messages.

I would suggest you look into those those options as well.

Cheers,
Max


On 7/18/14, 10:29 AM, Erik Andersen wrote:
> Hi Phillip,
>
> Thanks for your comment. I will certainly look at SCVP.
>
> I expect the proposal will primarily be picked-up by companies working on smart grid support not too biased by old thinking.
>
> The (smart) grid uses the SCADA (Supervisory Control And Data Acquisition) protocols, a very large set of protocol standards. These standards are developed by IEC TC57  and being implemented all over the world. We have several SCADA experts even in a small country like Denmark. WG15 of IEC TC57 is working on Smart Grid security and is working closely with ITU-T Study Group 17 to extend X.509 to cover their needs.
>
> To answer your question. Software support for PKI adapted to Smart Grid will most likely be provided by those developing SCADA. Siemens could be a major player. At least they have a heavy interest in the matter. It could be big business. Even in a small country like Denmark, there will be millions of communicating entities, including smart meters, heat pumps, solar cells, load stations for cars, substations, wind turbines, power stations, etc.
>
> Smart Grid will be a prime target for terrorist attacks. Whether we can provide the necessary security, time will show.
>
> We also see a need for machine readable certificate policies. As an example, currently X.509 (and 5280) says that an unsupported non-critical extension shall be ignored by the RP. That is not good enough, but that is how browsers work.
>
> Kind regards,
>
> Erik
>
> -----Oprindelig meddelelse-----
> Fra: hallam@gmail.com [mailto:hallam@gmail.com] På vegne af Phillip Hallam-Baker
> Sendt: 18. juli 2014 15:22
> Til: Erik Andersen
> Cc: Tony Rutkowski; tony@yaanatech.com; Stephen Farrell; pkix@ietf.org; Directory list; wpkops@ietf.org; SG17-Q11
> Emne: Re: [wpkops] [T17Q11] SV: [pkix] X.509 whitelist proposal
>
> Hmm, what are you trying to achieve here. Are you trying to develop a standard that is likely to be adopted and used by Microsoft, IBM, Google and the CA industry or are you trying to get ITU imprimatur for something that is already developed?
>
> If it is the first then I can't see any likelihood that an ITU publication would help in the slightest. The mainstream IT industry is adamant that communications standards have to be open standards. And paying for a standard completely kills it dead. So does use of ASN.1
>
> IETF does already have SCVP which has many of the features you propose and W3C did XKMS back in the day. These days however the trend is for JSON.
>
>
> I have a proposal for a 'broker' type scheme that is a bit more general than the one you propose. Rather than being a broker for just PKI information, the broker is potentially a one stop shop for all the information that a client might need to connect to another network entity or validate a connection request.
>
> http://prismproof.org/ has links to the papers which are the OmniQuery and OmniPublish Web Services.
>
>
> On Fri, Jul 18, 2014 at 8:46 AM, Erik Andersen <era@x500.eu> wrote:
>> Hi Tony,
>>
>>
>>
>> I have no intention to submit a contribution without the permission
>> from the Danish ministry. I would be killed.  Before I can submit it,
>> it has to be approved by two different Danish authorities. The
>> agreement is that I first distribute it among experts to get any
>> constructive comments that could improve the proposal before getting
>> it through the approval process within Denmark.
>>
>>
>>
>> One use case is as follows:
>>
>>
>>
>> An electrical substation (e.g. transformation) has many interconnected
>> entities. One of these entities is the contact to the outside world.
>> If something happens within the substation, the situation has to be
>> detected, commands have to be sent to other entities that that have to
>> process the command and react to the commands. All this must happens
>> within 10 ms. False commands would be disastrous in this environment,
>> so authentication is necessary, but there is no time to validate a
>> long certification path, to consult OCSP, etc. It is an environment
>> very different from a browser environment and old solutions do not work here.
>>
>>
>>
>> Kind regards,
>>
>>
>>
>> Erik
>>
>>
>>
>> Fra: Tony Rutkowski [mailto:trutkowski@netmagic.com]
>> Sendt: 18. juli 2014 14:11
>> Til: Erik Andersen; tony@yaanatech.com; stephen.farrell@cs.tcd.ie
>> Cc: pkix@ietf.org; wpkops@ietf.org; SG17-Q11
>> Emne: Re: [T17Q11] SV: [pkix] X.509 whitelist proposal
>>
>>
>>
>> Hi Erik,
>>
>> You have been participating long enough in the ITU-T to know that it
>> is an intergovernmental body, and one cannot simply create a
>> contribution using a Member nation's name - even if you are a citizen
>> - because you don't like the "red tape."  It is the Danish
>> Administration - the Ministry of Business and Growth - that gets to
>> make submissions for Denmark, not you.
>>
>> Denmark ten years ago reduced its ITU financial contribution by more
>> than a half, and has not submitted a document into the ITU-T since at
>> least 2001.  It thus seems unlikely this will occur.
>>
>> You now say that "the proposal has been submitted to that group [IEC
>> TC57 WG15} for comments," whereas your previous message said it "has
>> requested the inclusion of whitelist support in X.509."
>>
>> I don't mean to be harsh or difficult here, but your proposal is far
>> reaching with profound effects on X.509/PKI communities and
>> implementations.  This material also appears to be your own personal
>> proposal with no other apparent support.  You should be proceeding to
>> get reactions and support from others on your ideas before attributing
>> them to a Member State or using your position as Q11/17 rapporteur to
>> advance them.
>>
>> --tony
>>
>> On 2014-07-18 5:31 AM, Erik Andersen wrote:
>>
>> There is some pressure by the major electricity company
>> (http://energinet.dk/EN/Sider/default.aspx)  to make me the Danish
>> Member representative in ITU-T SG17. It takes a lot of red tape. I am
>> also active in IEC TC57 WG15. As I mentioned, the proposal has been
>> submitted to that group for comments.
>>
>>
>>
>>
>> _______________________________________________
>> wpkops mailing list
>> wpkops@ietf.org
>> https://www.ietf.org/mailman/listinfo/wpkops
>>
> _______________________________________________
> wpkops mailing list
> wpkops@ietf.org
> https://www.ietf.org/mailman/listinfo/wpkops