From nobody Wed Aug 6 02:19:54 2014 Return-Path: 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 3F1DD1B2CF4 for ; Wed, 6 Aug 2014 02:19:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.51 X-Spam-Level: X-Spam-Status: No, score=0.51 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DK=1.009, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 WkobgIcPT0ff for ; Wed, 6 Aug 2014 02:19:46 -0700 (PDT) Received: from mail03.dandomain.dk (mail03.dandomain.dk [194.150.112.203]) (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 9DDF31B2CEC for ; Wed, 6 Aug 2014 02:19:45 -0700 (PDT) Received: from Morten ([62.44.134.3]) by mail03.dandomain.dk (DanDomain Mailserver) with ASMTP id 3201408061119412059; Wed, 06 Aug 2014 11:19:41 +0200 From: "Erik Andersen" To: "'Sill, Alan'" References: <000b01cfa1bc$b6872ef0$23958cd0$@x500.eu> <53C85314.3040102@yaanatech.com> <42131021-11E3-4806-9C05-0D6F40190A1C@ttu.edu> In-Reply-To: <42131021-11E3-4806-9C05-0D6F40190A1C@ttu.edu> Date: Wed, 6 Aug 2014 11:19:42 +0200 Message-ID: <003001cfb157$8e82c680$ab885380$@x500.eu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0031_01CFB168.52102A60" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQFen6BH0OQwBY9AWxzuVVIZFItMGQHZLJJdAhs4DJychcg2kA== Content-Language: da Archived-At: http://mailarchive.ietf.org/arch/msg/wpkops/uLsWIbk5AfhvKvd1B5JjLsmIxxE Cc: pkix@ietf.org, wpkops@ietf.org, tony@yaanatech.com, stephen.farrell@cs.tcd.ie Subject: Re: [wpkops] [pkix] X.509 whitelist proposal X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 09:19:50 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0031_01CFB168.52102A60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Alan, Thanks for your comments. My proposal is a very initial proposal. I was just eager to see reaction to the general approach. I has primarily been concerned with the case where a RP only have 1-2 ms to validate a received a PDU, meaning that the validation has to happen a thousand times faster than in a traditional Web environment. I will be very happy to receive some of the solutions you have seen work in practice. I am always open to new ideas. Kind regards, Erik Fra: Sill, Alan [mailto:alan.sill@ttu.edu] Sendt: 31. juli 2014 23:17 Til: Erik Andersen Cc: Sill, Alan; stephen.farrell@cs.tcd.ie; pkix@ietf.org; wpkops@ietf.org; tony@yaanatech.com Emne: Re: [pkix] X.509 whitelist proposal Erik, 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. --tony -------- 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 http://www.x500standard.com/uploads/extensions/whitelistInX509.pdf 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 _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix ------=_NextPart_000_0031_01CFB168.52102A60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Alan,

 

Thanks for your comments. My proposal is a = very initial proposal. I was just eager to see reaction to the general = approach.

 

I has primarily been concerned with the = case where a RP only have 1-2 ms to validate a received a PDU, meaning = that the validation has to happen a thousand times faster than in a = traditional Web environment.

 

I will be very happy to receive some of = the solutions you have seen work in practice. I am always open to new = ideas.

 

Kind regards,

 

Erik

 

Fra:= = Sill, Alan [mailto:alan.sill@ttu.edu]
Sendt: 31. juli 2014 = 23:17
Til: Erik Andersen
Cc: Sill, Alan; = stephen.farrell@cs.tcd.ie; pkix@ietf.org; wpkops@ietf.org; = tony@yaanatech.com
Emne: Re: [pkix] X.509 whitelist = proposal

 

Erik, =

 

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 <tony@yaanatech.com> = 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 <era@x500.eu>

To:

Directory = list <x500standard@freelists.org>, = SG17-Q11 <T13sg17q11@lists.itu.int><= /o:p>

CC:

SG17-Q10 <t13sg17q10@lists.itu.int><= /o:p>

 = ;

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 http://www.x500standard.com/uploads/extensions/wh= itelistInX509.pdf=

 =

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= =

 = ;


<wh= itelistInX509.pdf>_______________________________________________
p= kix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix=

 

------=_NextPart_000_0031_01CFB168.52102A60-- From nobody Fri Aug 8 10:09:23 2014 Return-Path: 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 A93121B2D0B; Wed, 6 Aug 2014 03:02:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Hwue4mqHW7w; Wed, 6 Aug 2014 03:02:34 -0700 (PDT) Received: from epona04.ttu.edu (epona04.ttu.edu [129.118.201.80]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A1FE1B2D01; Wed, 6 Aug 2014 03:02:33 -0700 (PDT) Received: from empusa01.ttu.edu (129.118.201.4) by epona04.ttu.edu (129.118.201.80) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 6 Aug 2014 05:02:32 -0500 Received: from CYCLOPS05.ttu.edu ([169.254.2.4]) by empusa01.ttu.edu ([129.118.201.4]) with mapi id 14.03.0181.006; Wed, 6 Aug 2014 05:02:32 -0500 From: "Sill, Alan" To: Erik Andersen Thread-Topic: [pkix] X.509 whitelist proposal Thread-Index: AQHPohGMDcmyPIB3PUCZy6of34/ykpu7GUAAgAiligCAAAusAA== Date: Wed, 6 Aug 2014 10:02:31 +0000 Message-ID: <190B39E6-A6C4-4AB6-A021-77A9AB6609C7@ttu.edu> References: <000b01cfa1bc$b6872ef0$23958cd0$@x500.eu> <53C85314.3040102@yaanatech.com> <42131021-11E3-4806-9C05-0D6F40190A1C@ttu.edu> <003001cfb157$8e82c680$ab885380$@x500.eu> In-Reply-To: <003001cfb157$8e82c680$ab885380$@x500.eu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.118.242.5] Content-Type: multipart/alternative; boundary="_000_190B39E6A6C44AB6A02177A9AB6609C7ttuedu_" MIME-Version: 1.0 X-TechMail-Edge-Route: TTU Archived-At: http://mailarchive.ietf.org/arch/msg/wpkops/ZZHPmAVwKNMc3nuJ3XwnwoK0hbs X-Mailman-Approved-At: Fri, 08 Aug 2014 10:09:19 -0700 Cc: "pkix@ietf.org" , "wpkops@ietf.org" , "tony@yaanatech.com" , "Sill, Alan" , "stephen.farrell@cs.tcd.ie" Subject: Re: [wpkops] [pkix] X.509 whitelist proposal X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 10:02:38 -0000 --_000_190B39E6A6C44AB6A02177A9AB6609C7ttuedu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Erik, thanks for the reply and questions. The situations that I describe for comparison are derived from automated gr= id processing environments, in which it is not unusual to have tens of thou= sands of processes start at once and also to need a very fast locally-based= system for authorization based on strong identity. The classic grid security infrastructure (GSI) works by use of limited-life= time extended attribute certificate proxies obtained in advance of the oper= ation from authorization servers operated by virtual organizations (VOs). A= uthorization occurs locally, based on a pre-defined list of DNs kept up to = date out of band to establish membership in a VO. To make this work, a certificate can be obtained from any CA within the tru= st network, but must be registered ahead of use into the VO membership serv= er (called a VOMS server) to establish that the DN of that certificate is i= n the authorized list. Prior to use in an X.509 secured environment, the us= er obtains a limited-lifetime proxy by presenting the certificate to the VO= MS server and getting back a proxy containing the EAC fields. When the proxy is presented to the end-point of use, the list of authorized= DNs for that proxy is checked, along with the validity of the EAC fields. = This allows a cryptographically strong assurance that the DN is in the auth= orized list for operations on that endpoint. Subtleties that have evolved over time allow expression of groups and roles= to be carried by the proxy, so that a given certificate by itself can be a= ssociated with different operations at different end points. Thus not only = membership in the VO, but what that particular DN is allowed to assert that= it can do, can all be controlled with very fast local verification of auth= orization based on the proxy presented. Overall this is essentially as fast as presenting a straight X.509 certific= ate, but allows much finer control over local authorization for particular = operations by that DN. I think it is one option among many that might work in your environment. Th= ere are also options in which the proxy is generated and/or held on behalf = of the user by an intermediary server, called a MyProxy server, that can be= deployed in various environments to simplify the proxy operations on behal= f of a certificate holder (either human or automated); and there are also o= ptions in which the entire X.509 infrastructure can be handled automaticall= y or tied into other secure identity systems, but the above captures the ba= sic workflow with regard to how membership and local authorization can be h= andled quickly through the X.509 components. In point of practice, most local authorization servers communicate with the= resources in their vicinity using XACML over SAML to handle local assertio= ns at speed, which works well in environments up to many tens of thousands = of local relying resources. The communication between these local authoriza= tion servers and the central VOMS server to update membership lists is also= done securely at low update rates (typically a few to many times per day) = to synchronize the DNs, groups and roles for the VO membership lists. A starting point for learning more on this might be http://www.ogf.org/docu= ments/GFD.78.pdf -- the Grid Security Infrastructure Message Specification.= You may also wish to read http://www.ogf.org/documents/GFD.189.pdf -- Rely= ing Party Defined Namespace Constraints Policies in a Policy Bridge PKI Env= ironment, http://www.ogf.org/documents/GFD.125.pdf -- the Grid Certificate = Profile (shortly to be revised to GFD.225 with recent updates), and http://= www.ogf.org/documents/GFD.182.pdf -- the VOMS Attribute Certificate Format. These are just my opinions but are intended to answer your questions and I = hope will provide background for my suggestion that a local authorization s= ystem based on strong authentication can work to meet your needs in a distr= ibuted environment. Feel free to contact me offline and best regards, Alan On Aug 6, 2014, at 11:19 AM, Erik Andersen = > wrote: Hi Alan, Thanks for your comments. My proposal is a very initial proposal. I was jus= t eager to see reaction to the general approach. I has primarily been concerned with the case where a RP only have 1-2 ms to= validate a received a PDU, meaning that the validation has to happen a tho= usand times faster than in a traditional Web environment. I will be very happy to receive some of the solutions you have seen work in= practice. I am always open to new ideas. Kind regards, Erik Fra: Sill, Alan [mailto:alan.sill@ttu.edu] Sendt: 31. juli 2014 23:17 Til: Erik Andersen Cc: Sill, Alan; stephen.farrell@cs.tcd.ie= ; pkix@ietf.org; wpkops@ietf.org; tony@yaanatech.com Emne: Re: [pkix] X.509 whitelist proposal Erik, With the desire to wind this discussion back to its actual content and avoi= d 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 infrastructur= e environments. The solution invariably is to implement a separate authorization layer that= can work with the existing certificate infrastructure, which is out or sco= pe 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 th= e 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 li= mited 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 authorizatio= n technologies has been done and again offer to have that discussion off th= ese 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. --tony -------- 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 whitelis= t support in X.509. A preliminary proposal for such a feature may be found = as http://www.x500standard.com/uploads/extensions/whitelistInX509.pdf The feature may in some way be combined with the trust broker concept, whic= h probably will involve a number of changes. As it is quite important that we have workable solution, any comment is wel= come. I hope you will find the time to review the proposal before it is sub= mitted to ITU-T. Kind regards, Erik _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix --_000_190B39E6A6C44AB6A02177A9AB6609C7ttuedu_ Content-Type: text/html; charset="us-ascii" Content-ID: <9E6AB3330ED1814FB85E90D2D42BF1C5@default.ttu.edu> Content-Transfer-Encoding: quoted-printable Erik, thanks for the reply and questions.

The situations that I describe for comparison are derived from automat= ed grid processing environments, in which it is not unusual to have tens of= thousands of processes start at once and also to need a very fast locally-= based system for authorization based on strong identity.

The classic grid security infrastructure (GSI) works by use of limited= -lifetime extended attribute certificate proxies obtained in advance of the= operation from authorization servers operated by virtual organizations (VO= s). Authorization occurs locally, based on a pre-defined list of DNs kept up to date out of band to establis= h membership in a VO.

To make this work, a certificate can be obtained from any CA within th= e trust network, but must be registered ahead of use into the VO membership= server (called a VOMS server) to establish that the DN of that certificate= is in the authorized list. Prior to use in an X.509 secured environment, the user obtains a limited-lifetim= e proxy by presenting the certificate to the VOMS server and getting back a= proxy containing the EAC fields.

When the proxy is presented to the end-point of use, the list of autho= rized DNs for that proxy is checked, along with the validity of the EAC fie= lds. This allows a cryptographically strong assurance that the DN is in the= authorized list for operations on that endpoint.

Subtleties that have evolved over time allow expression of groups and = roles to be carried by the proxy, so that a given certificate by itself can= be associated with different operations at different end points. Thus not = only membership in the VO, but what that particular DN is allowed to assert that it can do, can all be control= led with very fast local verification of authorization based on the proxy p= resented.

Overall this is essentially as fast as presenting a straight X.509 cer= tificate, but allows much finer control over local authorization for partic= ular operations by that DN.

I think it is one option among many that might work in your environmen= t. There are also options in which the proxy is generated and/or held on be= half of the user by an intermediary server, called a MyProxy server, that c= an be deployed in various environments to simplify the proxy operations on behalf of a certificate holder (either= human or automated); and there are also options in which the entire X.509 = infrastructure can be handled automatically or tied into other secure ident= ity systems, but the above captures the basic workflow with regard to how membership and local authorization c= an be handled quickly through the X.509 components. 

In point of practice, most local authorization servers communicate wit= h the resources in their vicinity using XACML over SAML to handle local ass= ertions at speed, which works well in environments up to many tens of thous= ands of local relying resources. The communication between these local authorization servers and the centra= l VOMS server to update membership lists is also done securely at low updat= e rates (typically a few to many times per day) to synchronize the DNs, gro= ups and roles for the VO membership lists.

A starting point for learning more on this might be http://www.ogf.org/documents/GFD.78.= pdf -- the Grid Security Infrastructure Message Specification. You= may also wish to read http://www.ogf.org/documents/GFD.189.pdf -- Relying Party Defined Namespace Constraints Policies in a Policy B= ridge PKI Environment, http://www.ogf.org/documents/GFD.125.pdf -- the Grid Certificate = Profile (shortly to be revised to GFD.225 with recent updates), and http://www.ogf.org/documents/GFD.182.pdf -- the VOMS Attribute Cer= tificate Format.

These are just my opinions but are intended to answer your questions a= nd I hope will provide background for my suggestion that a local authorizat= ion system based on strong authentication can work to meet your needs in a = distributed environment.

Feel free to contact me offline and best regards,
Alan



On Aug 6, 2014, at 11:19 AM, Erik Andersen <era@x500.eu> wrote:

Hi Alan,
 
Thanks for your comments. My proposal is a = very initial proposal. I was just eager to see reaction to the general appr= oach.
 
I has primarily been concerned with the cas= e where a RP only have 1-2 ms to validate a received a PDU, meaning that th= e validation has to happen a thousand times faster than in a traditional Web environment.
 
I will be very happy to receive some of the= solutions you have seen work in practice. I am always open to new ideas.
 
Kind regards,
 
Erik
 
Fra:<= /span> Sill, Alan [mailto:alan.sill@ttu.edu] 
Sendt: 31. juli 20= 14 23:17
Til: Erik Andersen=
Cc: Sill, Alan; stephen.farrell@cs.tcd.ie; pkix@ietf.o= rg; wpkops@ietf.org; tony@yaanatech.c= om
Emne: Re: [pkix] X= .509 whitelist proposal
 
Erik,
 
With the desire to wind this discussion back to its actual content and avoi= d 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 sco= pe 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 th= e 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-limi= ted extended attribute certificates.
 
My suggestion, with great respect and due deference to its proposers, is to= drop the referenced proposal until exploration of appropriate authorizatio= n technologies has been done and again offer to have that discussion off th= ese 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 <tony@yaana= tech.com> wrote:


Hi Stev= e,

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 <era@x500.eu>=
To:
CC:

 <= /span>

IEC TC57 WG15 (smart grid security) has requested the inclusion of w= hitelist support in X.509. A preliminary proposal for such a feature may be= found as http://www.x500standard.com/uploads/extensions/whitelistInX509.pdf=
 
The feature may in some way be combined with the trust broker concep= t, 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
 <= /span>

<whitelistInX509.pdf>_______________________________________________<= br> pkix mailing list
pkix@ietf.org
= https://www.ietf.org/mailman/listinfo/pkix

--_000_190B39E6A6C44AB6A02177A9AB6609C7ttuedu_-- From nobody Tue Aug 12 10:13:05 2014 Return-Path: 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 BF1721A0382 for ; Tue, 12 Aug 2014 10:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.669 X-Spam-Level: X-Spam-Status: No, score=-0.669 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham 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 8L1LVQ3e0RWa for ; Tue, 12 Aug 2014 10:12:56 -0700 (PDT) Received: from ipedge2.entrust.com (ipedge2.entrust.com [216.191.252.25]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D6F41A0342 for ; Tue, 12 Aug 2014 10:12:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,850,1400040000"; d="scan'208,217";a="1713508" Received: from unknown (HELO sottexchcas.corp.ad.entrust.com) ([10.4.51.224]) by ipedge2.entrust.com with ESMTP/TLS/AES128-SHA; 12 Aug 2014 13:12:55 -0400 Received: from SOTTEXCH11.corp.ad.entrust.com ([fe80::303b:8584:c6f4:be18]) by SOTTEXCHCAS2.corp.ad.entrust.com ([::1]) with mapi id 14.03.0195.001; Tue, 12 Aug 2014 13:12:54 -0400 From: Tim Moses To: "wpkops@ietf.org" Thread-Topic: Browser behaviour draft Thread-Index: Ac+ms94oJr0mgv4pQF68oJysomSRsgPnKZ0g Date: Tue, 12 Aug 2014 17:12:53 +0000 Message-ID: <5B68A271B9C97046963CB6A5B8D6F62CFCCA3BBD@SOTTEXCH11.corp.ad.entrust.com> References: <0986C055-3FA5-4EF9-8E3C-B8B9684FBAAE@entrust.com> In-Reply-To: <0986C055-3FA5-4EF9-8E3C-B8B9684FBAAE@entrust.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.160.46] Content-Type: multipart/alternative; boundary="_000_5B68A271B9C97046963CB6A5B8D6F62CFCCA3BBDSOTTEXCH11corpa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/wpkops/TmdmL2ZNh1y5v1eOlAUaaaUIS4o Subject: Re: [wpkops] Browser behaviour draft X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 17:13:02 -0000 --_000_5B68A271B9C97046963CB6A5B8D6F62CFCCA3BBDSOTTEXCH11corpa_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q29sbGVhZ3VlcyDigJMgSGF2aW5nIHJlY2VpdmVkIG5vIG9iamVjdGlvbnMsIHRoZSBCcm93c2Vy IEJlaGF2aW91ciBkcmFmdCBpZiBkdWx5IGFkdmFuY2VkIHRvIFdvcmtpbmcgR3JvdXAgZHJhZnQu ICBUaGFua3MgYSBsb3QuICBBbGwgdGhlIGJlc3QuICBUaW0uDQoNCkZyb206IFRpbSBNb3Nlcw0K U2VudDogV2VkbmVzZGF5LCBKdWx5IDIzLCAyMDE0IDQ6MjMgUE0NClRvOiB3cGtvcHNAaWV0Zi5v cmcNClN1YmplY3Q6IEJyb3dzZXIgYmVoYXZpb3VyIGRyYWZ0DQoNCkNvbGxlYWd1ZXMgLSBJIHdv dWxkIGxpa2UgdG8gYWR2YW5jZSB0aGUgQnJvd3NlciBCZWhhdmlvdXIgZHJhZnQgLi4uDQoNCmh0 dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtd2lsc29uLXdwa29wcy1icm93c2Vy LXByb2Nlc3NpbmcvDQoNCiAuLi4gdG8gV0cgZHJhZnQuDQoNCklmIHlvdSB3aXNoIHRvIGNvbW1l bnQsIHBsZWFzZSBkbyBzbyBieSAyMDE0LTA4LTA4Lg0KDQpUaGFuayB5b3UuICBBbGwgdGhlIGJl c3QuIFRpbS4NCg== --_000_5B68A271B9C97046963CB6A5B8D6F62CFCCA3BBDSOTTEXCH11corpa_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4g MS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNvbGxlYWd1ZXMg4oCTIEhhdmluZyByZWNl aXZlZCBubyBvYmplY3Rpb25zLCB0aGUgQnJvd3NlciBCZWhhdmlvdXIgZHJhZnQgaWYgZHVseSBh ZHZhbmNlZCB0byBXb3JraW5nIEdyb3VwIGRyYWZ0LiZuYnNwOyBUaGFua3MgYSBsb3QuJm5ic3A7 IEFsbCB0aGUgYmVzdC4mbmJzcDsgVGltLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gVGltIE1vc2Vz DQo8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBKdWx5IDIzLCAyMDE0IDQ6MjMgUE08YnI+ DQo8Yj5Ubzo8L2I+IHdwa29wc0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBCcm93c2Vy IGJlaGF2aW91ciBkcmFmdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5Db2xsZWFndWVzIC0gSSB3b3VsZCBsaWtlIHRvIGFkdmFuY2UgdGhlIEJy b3dzZXIgQmVoYXZpb3VyIGRyYWZ0IC4uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LXdpbHNvbi13cGtvcHMtYnJvd3Nlci1wcm9jZXNzaW5nLyI+aHR0cDovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC13aWxzb24td3Brb3BzLWJyb3dzZXItcHJvY2Vz c2luZy88L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOy4uLiB0byBXRyBkcmFmdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgeW91IHdpc2ggdG8gY29tbWVudCwgcGxlYXNl IGRvIHNvIGJ5IDIwMTQtMDgtMDguPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rIHlvdS4gJm5ic3A7QWxsIHRoZSBiZXN0LiBUaW0uJm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_5B68A271B9C97046963CB6A5B8D6F62CFCCA3BBDSOTTEXCH11corpa_--