Re: [wpkops] X.509 whitelist proposal

Stephen Farrell <> Fri, 18 July 2014 12:03 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B92D81A0AB0; Fri, 18 Jul 2014 05:03:03 -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, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jX4hXJnk69kc; Fri, 18 Jul 2014 05:02:58 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 261AF1A033D; Fri, 18 Jul 2014 05:02:58 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1684CBE7B; Fri, 18 Jul 2014 13:02:57 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AE913BCp4Qu5; Fri, 18 Jul 2014 13:02:54 +0100 (IST)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id 8E5EEBEE9; Fri, 18 Jul 2014 13:02:54 +0100 (IST)
Message-ID: <>
Date: Fri, 18 Jul 2014 13:02:54 +0100
From: Stephen Farrell <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
References: <000b01cfa1bc$b6872ef0$23958cd0$> <>
In-Reply-To: <>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [wpkops] 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: Fri, 18 Jul 2014 12:03:03 -0000

Hi Tony,

Seems like an odd proposal all right.

Technically, I'd say it could do with a lot more work before
it'd be ready for prime time. For example, if a node only
wants to talk to a few others, why are there so many CAs or
"delegators" involved. Seems a bit silly to me tbh but maybe
I'm not getting the use-case. Its also obviously pretty much
an outline rather than a worked-out proposal. I'd also have
thought this likely to be sorted at another layer, e.g.
within CoAP maybe, where pre-shared keys with DTLS will be
common, and where there would as a result be no PKI at all.

Process wise, from the IETF perspective, I think we no longer
care really. While we used work closely with the ITU-T folks
on X.509, I've not really seen any benefit from that myself
for some years now. And afaik anyone who cares just implements
from RFC 5280 anyway so changes to X.509 are pretty much fine
to ignore.

But I'd be interested in hearing if there are in fact IETF
participants who continue to think its important that we pay
attention to these kinds of changes to X.509. And, if you do,
then please say what if anything you think we ought say about
such changes proposed within ITU-T. (On or off-list is fine.)


On 17/07/14 23:49, 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.
> --tony
> -------- Original Message --------
> Subject:     [T17Q11] X.509 whitelist support
> Date:     Thu, 17 Jul 2014 14:43:30 +0200
> From:     Erik Andersen <>
> To:     Directory list <>rg>, 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,
> Erik