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

"Sill, Alan" <> Thu, 31 July 2014 21:17 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8C3671A0171; Thu, 31 Jul 2014 14:17:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SIpZRdHPikIy; Thu, 31 Jul 2014 14:17:15 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A8ADB1A010A; Thu, 31 Jul 2014 14:17:15 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Thu, 31 Jul 2014 16:17:14 -0500
Received: from ([]) by ([]) with mapi id 14.03.0181.006; Thu, 31 Jul 2014 16:17:13 -0500
From: "Sill, Alan" <>
To: Erik Andersen <>
Thread-Topic: [pkix] X.509 whitelist proposal
Thread-Index: AQHPohGMDcmyPIB3PUCZy6of34/ykpu7GUAA
Date: Thu, 31 Jul 2014 21:17:13 +0000
Message-ID: <>
References: <000b01cfa1bc$b6872ef0$23958cd0$> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_4213102111E348069C050D6F40190A1Cttuedu_"
MIME-Version: 1.0
X-TechMail-Edge-Route: TTU
X-Mailman-Approved-At: Thu, 31 Jul 2014 14:25:26 -0700
Cc: "" <>, "" <>, "" <>, "Sill, Alan" <>, "" <>
Subject: Re: [wpkops] [pkix] X.509 whitelist proposal
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 31 Jul 2014 21:17:18 -0000


With the desire to wind this discussion back to its actual content and avoid for the present further discussion of procedures, let me say that the use case proposed is a familiar one in the world of extended use of PKI as an authentication piece of access control systems in distributed infrastructure environments.

The solution invariably is to implement a separate authorization layer that can work with the existing certificate infrastructure, which is out or scope as a work item for any of the proposed groups.

My personal belief is that this is not worth pursuing in its present form. I would be happy, off-list or on an individual basis, to pass on some of the solutions that I have seen work in practice in distributed computational, storage and other related control settings, some of which can be achieved within the existing X.509 settings through the use, for example, of time limited or otherwise membership-limited extended attribute certificates.

My suggestion, with great respect and due deference to its proposers, is to drop the referenced proposal until exploration of appropriate authorization technologies has been done and again offer to have that discussion off these lists or on a different one.

Alan Sill, TTU
VP of Standards, Open Grid Forum

On Jul 18, 2014, at 12:49 AM, Tony Rutkowski <<>> wrote:

Hi Steve,

The note below was distributed earlier on the ITU-T SG17
sub-group Q11/17 list by the group's rapporteur.  It might
be useful to gauge industry reaction in IETF and CA/B
Forum venues.

Note that although the document appears on an ITU-T
template, it has not been submitted.   In addition, although
the source is indicated as "Denmark," it is not apparent
that the source is any other than than the rapporteur
himself, who is identified as the contact.  Lastly, although
the note asserts that "IEC TC57 WG15 (smart grid
security) has requested the inclusion of whitelist
support in X.509," there is no apparent liaison to
this effect.


-------- Original Message --------
Subject:        [T17Q11] X.509 whitelist support
Date:   Thu, 17 Jul 2014 14:43:30 +0200
From:   Erik Andersen <><>
To:     Directory list <><>, SG17-Q11 <><>
CC:     SG17-Q10 <><>

IEC TC57 WG15 (smart grid security) has requested the inclusion of whitelist support in X.509. A preliminary proposal for such a feature may be found as

The feature may in some way be combined with the trust broker concept, which probably will involve a number of changes.

As it is quite important that we have workable solution, any comment is welcome. I hope you will find the time to review the proposal before it is submitted to ITU-T.

Kind regards,


pkix mailing list<>