[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Entity life after compromise.



-----BEGIN PGP SIGNED MESSAGE-----

At 10:44 AM 6/25/98 +0200, Xavier Serret wrote:
>Hello all.
>
>In identity based systems like X.509, the life after certificate
>expiration and key compromise is just and administrative issue. The
>"only" things to do is make sure all people can access the CRL and to
>issue a new certificate with the new validity time (and new key). I
>Think that's way the use of "administrative" validity times for X.509
>certificates can be easily justified.
>
>The situation is really different in SPKI. Here the key is the entity
>itself, and its compromise invalidates all its existence. Once, an SPKI
>environment is set-up, it is clear that recreating the hole amount of
>certificates issued over a principal for another principal will be a
>difficult, if not impossible, task.

The claims above are not true.

X.509's use of names relies on keys.  This is because there is no 
universally agreed global name for people.  There is also no single root for 
X.509 certificate hierarchies.  Therefore, every X.509 certificate chain is, 
in fact, a fully-qualified SDSI name chain.  The key in that name chain
is the so-called "root key" for that particular X.509 hierarchy.

The key in that fully qualified name has the characteristic that if it goes 
away then the whole chain evaporates -- and therefore the SDSI name at the 
end of the chain evaporates.  The very same is true for X.509, since the 
X.509 name chain is simply another syntax for a SDSI name.  There is no 
difference in substance between the two.

[One might argue that an X.509 root key is well protected, so it is less
likely to go away.  That might or might not be true.  It might be better
protected than a user's lone key, but it is also more visible and more
widely used, and therefore more likely to invite attack.  The probable
lifetimes of these two keys might be comparable or the user's key might
even have a longer lifetime.]

For every SDSI name, there is a raw-SPKI (ie., SPKI with no SDSI names) 
representation in which each SDSI name is replaced by a corresponding public 
key.  Therefore, we can map any mechanism using names (either SDSI or X.509) 
into one using keys alone.

At this point, I could write many more pages (and probably should, for 
publication) but instead I'll hand the discussion back to you.

[...]

>More discussion about the secure time stamp certificate can also help.

It is true that any use of time in a security-sensitive context should use 
secure time stamps.  In general, everyone seems to finesse this issue -- 
assuming that local clocks can be trusted.

I have noted, BTW, that timestamp work seems all to rely on the assumption 
that there is a global clock available to all.  It would be interesting to 
see timestamp work that recognizes that clocks might not be synchronized.
In other words, it's time for timestamp work to recognize what Einstein and
Lorentz did almost 100 years ago -- that there is no global time, only
local time.

 - Carl

-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.5.3

iQCVAwUBNZOR9hN3Wx8QwqUtAQHB0gP/T+3jEypL6BeV1VZZiF9e5Zvq2+k1Xnz+
fpoTbIwi9+dK4799WhyOgomE9eyi95pMyrd8JiZI/pxbpkzybnaIWSdDLsp3PY3t
3VCAxl6na/gtkP/5hsQ1enxmKDWopLaPm+aqL4v/th81uAHlpo/ofL8VX4ggM/nL
R13bF8z0vEM=
=cecE
-----END PGP SIGNATURE-----


+------------------------------------------------------------------+
|Carl M. Ellison  cme@cybercash.com   http://www.clark.net/pub/cme |
|CyberCash, Inc.                      http://www.cybercash.com/    |
|207 Grindall Street  PGP 08FF BA05 599B 49D2  23C6 6FFD 36BA D342 |
|Baltimore MD 21230-4103  T:(410) 727-4288  F:(410)727-4293        |
+------------------------------------------------------------------+
From ???@??? Fri Jun 26 10:16:59 1998
Received: by mis01.reston.cybercash.com; id JAA16161; Fri, 26 Jun 1998 09:58:44 -0400 (EDT)
Received: by callandor.cybercash.com; id JAA03756; Fri, 26 Jun 1998 09:57:58 -0400
Received: from blacklodge.c2.net(208.139.36.35) by callandor.cybercash.com via smap (3.2)
	id xma003731; Fri, 26 Jun 98 09:57:46 -0400
Received: (from majordom@localhost) by blacklodge.c2.net (8.8.5/8.7.3) id GAA02908 for spki-outgoing; Fri, 26 Jun 1998 06:53:47 -0700 (PDT)
X-Authentication-Warning: blacklodge.c2.net: majordom set sender to owner-spki@c2.org using -f
Message-Id: <3.0.3.32.19980626095159.032543f8@mailhost.reston.cybercash.com>
X-Sender: cme@mailhost.reston.cybercash.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Fri, 26 Jun 1998 09:51:59 -0400
To: Xavier Serret <serret@tele.ucl.ac.be>
From: Carl Ellison <cme@cybercash.com>
Subject: P.S. Re: Entity life after compromise.
Cc: spki@c2.net
In-Reply-To: <3.0.3.32.19980626082007.031e5ea0@mailhost.reston.cybercash
 .com>
References: <35920DF0.95C8A59E@tele.ucl.ac.be>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-spki@c2.net
Precedence: bulk
Status:  O

-----BEGIN PGP SIGNED MESSAGE-----

At 08:20 AM 6/26/98 -0400, Carl Ellison wrote:
>At 10:44 AM 6/25/98 +0200, Xavier Serret wrote:
>>In identity based systems like X.509, the life after certificate
>>expiration and key compromise is just and administrative issue.

[...]

>>The situation is really different in SPKI. Here the key is the entity
>>itself, and its compromise invalidates all its existence.

[...]

>
>The claims above are not true.
>
>X.509's use of names relies on keys.  This is because there is no 
>universally agreed global name for people.

Actually, even if there were some universally agreed global name for people, 
X.509 still relies on keys.

My thinking had been that if there were some globally accepted name for a 
person, then that name (not being a key) is not subject to either 
cryptanalysis or theft.  It is an identifier of the person.

One of my soapbox issues is that there is no such identifier in the world 
today and, for that matter, there is not likely to be.  Therefore, every
so-called global name PKI (e.g., X.509 as normally cited) is in fact a
local name (e.g., SDSI) PKI.  The individual owning the namespace is a
CA, in the X.509 case, but it is still a local name PKI.

That aside, even if there were a global name for people, having the global 
name doesn't help you.  To map that name to a key, you need a certificate.  
To verify the certificate, you need a public key.  That key is subject to 
both cryptanalysis and theft.  If that key is invalidated, then the name is 
rendered useless.

Of course, the name can be re-used, under some replacement key for the CA.  
The process involves scrapping and re-issuing the entire hierarchy of 
certificates, in the X.509 case.

If you have the SDSI case, then one user's key can be invalidated, but that 
does not bring the whole world to a halt -- only the users of that one 
user's SDSI names.  When that user replaces his key, then he can reuse the 
name he had used before and just re-issue SDSI certificates for such names.

In early X.509 thinking, there was the assumption that there would be only 
one root, one hierarchy, and that hierarchy would map globally accepted 
distinguished names to individual keys.  Therefore, one could build an 
attribute certificate (or ACL entry) binding characteristics to that global 
distinguished name.  Those bindings don't go away when the root key is 
compromised. Instead, the root key is replaced and all certificates hanging 
from it are re-issued -- and then business as usual continues.

This early thinking is not valid.  There is not just one X.509 root.  There 
is no globally accepted name.  There are multiple X.509 hierarchies, all 
independent of one another, and each assigning names to individuals based on 
its own wishes.  In other words, each X.509 hierarchy is generating SDSI 
names for people.  Therefore, any attribute certificate or ACL entry needs 
to specify (implicitly or explicitly) the fully qualified SDSI name being 
used for the person in question.

If an attribute certificate or ACL entry uses a fully-qualified SDSI name 
and the key in that FQ name is invalidated, then that name needs to be 
re-written, and the attribute certificate or ACL entry needs to change.  
This could produce a ripple of changes.

If there were a single root key, then one could define a FQ SDSI name format 
that doesn't use the root key explicitly.  That would stop those entries 
from having to be revised when the root key is replaced.  If there were 
multiple root keys, but a single global name used by everyone to refer to 
some individual, then you could have a pool of root keys (like the ones 
carried by Navigator or IE) all of which would lead to equivalent results, 
and again the attribute certificate or ACL wouldn't need to include any key. 
Neither of those situations applies.

It is still desirable to have a design in which you don't have to 
replace all your attribute certificates or ACL entries when a root key 
changes.  One way to do that is to indirect through your own key to a root 
key.  That is, you can have a key over which you have your own control that 
maps to a root key:

(cert
  (issuer K_your_root_reference)
  (subject K_root)
  (propagate)
  (tag (*))
  (not-after ...)
)

You would periodically re-verify the validity of the root key and re-issue 
this certificate apporpriately -- or, if the root has been replaced, issue a 
certificate with the new root.  Meanwhile, all the names you use could be of 
the form:

(name K_your_root_reference n_1 n_2 n_3 ... n_k)

That way, your own work is subject to something under your own control, not 
under someone else's.  You can protect K_your... as strongly as you wish -- 
e.g., use it only on a machine that has no network connection, is kept in a 
locked room, is used only under three-party control, etc.  You almost never 
need to use that private key.

 - Carl

-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.5.3

iQCVAwUBNZOnfhN3Wx8QwqUtAQGXvwP+OE2op0hDMbpWH9O5e+ClsEodgudpk8AH
3xmTQI749NNotmmuYugt02a/YDAuqFf3lD3Vn1y4vzMuzMhs6LMaBwL5vORniKeY
UrhDPXJ5fPR0esnWSZCl/tdlzMzhn6TAEObogiR3G1MfiDawZJD5JY9WWFXNED6z
bOWIDtvVddc=
=P7O4
-----END PGP SIGNATURE-----


+------------------------------------------------------------------+
|Carl M. Ellison  cme@cybercash.com   http://www.clark.net/pub/cme |
|CyberCash, Inc.                      http://www.cybercash.com/    |
|207 Grindall Street  PGP 08FF BA05 599B 49D2  23C6 6FFD 36BA D342 |
|Baltimore MD 21230-4103  T:(410) 727-4288  F:(410)727-4293        |
+------------------------------------------------------------------+
From ???@??? Fri Jun 26 12:26:24 1998
Received: by mis01.reston.cybercash.com; id MAA20684; Fri, 26 Jun 1998 12:24:33 -0400 (EDT)
Received: by callandor.cybercash.com; id MAA25589; Fri, 26 Jun 1998 12:23:50 -0400
Received: from ns1.tele.ucl.ac.be(130.104.2.91) by callandor.cybercash.com via smap (3.2)
	id xma025470; Fri, 26 Jun 98 12:23:22 -0400
Received: from tele.ucl.ac.be (herakles [130.104.97.210])
	by ns1.tele.ucl.ac.be (8.9.0/mp-ns1) with ESMTP id SAA03317;
	Fri, 26 Jun 1998 18:19:15 +0200 (MET DST)
Message-ID: <3593CAE6.47F02490@tele.ucl.ac.be>
Date: Fri, 26 Jun 1998 18:23:02 +0200
From: Xavier Serret <serret@tele.ucl.ac.be>
X-Mailer: Mozilla 4.05 [en] (WinNT; I)
MIME-Version: 1.0
To: Carl Ellison <cme@cybercash.com>
CC: spki@c2.net
Subject: Re: P.S. Re: Entity life after compromise.
References: <35920DF0.95C8A59E@tele.ucl.ac.be> <3.0.3.32.19980626095159.032543f8@mailhost.reston.cybercash.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status:   

Carl, I think I see your point. But what I had in mind is the reverse
problem. I will try to explain myself:

I think that at the end what we are trying to do is to transfer
selective trust to selected entities. 
It happens that the best way to nominate an entity is its public key,
but the public key 'as such' is not trusted because it has no own
decision power, it only speaks for the entity that is controlling it.
The problem is that when a public key gets compromised and dismissed,
the entity identity goes also with it. Here, two problems appear:

What happens to the certificates (or statements) issued by this entity,
and to all the entities that depend on them. I think your discussion was
focusing on that point.

And more difficult (I guess): What happens to the entity itself? As it
is easy to see, this "poor" entity has lost his existence, and all the
authorizations delegated on it, and normally it will be only the key and
not the entity that is compromised. I was just trying to find a
mechanism, or some support structure, to help this entity on keeping its
existence and delegated trust. 

Finally I don't think we can let the actual behaviour as a *feature*, at
least without trying to find a solution (or recommendation for the
behaviour on upper layers) before.

PD: I won't be able to answer my mail within 15 days (This is just in
case there is any "personal" question).

-- 
----------------------------------------------------------------
                     Xavier Serret Avila

              Universite Catholique de Louvain
	      Laboratoire de Telecommunications
	      Batiment Stevin
	      2, Place du Levant
	      B-1348 - Louvain La Neuve
                               
mailto:serret@tele.ucl.ac.be          Tel.: +32 - (0)10 - 478072
                                      Fax : +32 - (0)10 - 472089
----------------------------------------------------------------
From ???@??? Sat Jun 27 15:42:17 1998
Received: by mis01.reston.cybercash.com; id PAA13706; Sat, 27 Jun 1998 15:43:29 -0400 (EDT)
Received: by callandor.cybercash.com; id PAA22373; Sat, 27 Jun 1998 15:42:39 -0400
Received: from blacklodge.c2.net(208.139.36.35) by callandor.cybercash.com via smap (3.2)
	id xma022362; Sat, 27 Jun 98 15:42:32 -0400
Received: (from majordom@localhost) by blacklodge.c2.net (8.8.5/8.7.3) id MAA29857 for spki-outgoing; Sat, 27 Jun 1998 12:26:01 -0700 (PDT)
X-Authentication-Warning: blacklodge.c2.net: majordom set sender to owner-spki@c2.org using -f
Message-Id: <3.0.3.32.19980627152445.032cd008@mailhost.reston.cybercash.com>
X-Sender: cme@mailhost.reston.cybercash.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Sat, 27 Jun 1998 15:24:45 -0400
To: spki@c2.net
From: Carl Ellison <cme@cybercash.com>
Subject: Re: P.S. Re: Entity life after compromise.
In-Reply-To: <3593CAE6.47F02490@tele.ucl.ac.be>
References: <35920DF0.95C8A59E@tele.ucl.ac.be>
 <3.0.3.32.19980626095159.032543f8@mailhost.reston.cybercash.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-spki@c2.net
Precedence: bulk
Status:   

-----BEGIN PGP SIGNED MESSAGE-----

At 06:23 PM 6/26/98 +0200, Xavier Serret wrote:
>Carl, I think I see your point. But what I had in mind is the reverse
>problem. I will try to explain myself:
>
>I think that at the end what we are trying to do is to transfer
>selective trust to selected entities. 
>It happens that the best way to nominate an entity is its public key,
>but the public key 'as such' is not trusted because it has no own
>decision power, it only speaks for the entity that is controlling it.
>The problem is that when a public key gets compromised and dismissed,
>the entity identity goes also with it. Here, two problems appear:
>
>What happens to the certificates (or statements) issued by this entity,
>and to all the entities that depend on them. I think your discussion was
>focusing on that point.

Yes, it did.

>And more difficult (I guess): What happens to the entity itself? As it
>is easy to see, this "poor" entity has lost his existence, and all the
>authorizations delegated on it, and normally it will be only the key and
>not the entity that is compromised. I was just trying to find a
>mechanism, or some support structure, to help this entity on keeping its
>existence and delegated trust. 

There is no way that the entity loses its existence by loss of a public key. 
A public key is simply a mathematically constrained randomly chosen value.  
It happens to refer to the keyholder, by virtue of the keyholder's 
protection of the corresponding private key, but it is not the keyholder's 
identity much less existence.  It's not even the keyholder's preferred name. 
The name by which the keyholder is commonly known remains the keyholder's, 
independent of invalidation of a public key.

What we're saying with SPKI is that the notion that there is a text-only 
name that universally identifies an entity is false.  There is no global 
identifier, globally accepted by all and meaningful to all.  There are many 
global identifiers, but they are not meaningful by themselves.

One global identifier is an entity's public key.  Like all other 
identifiers, they can come and go.  The entity, however, lives on.  So does 
his or her identity.  It's just that "identity" is not a synonym for 
"identifier".  A person's identity is not a byte string.

If the person's public key goes away, then he or she needs to generate a new 
one.  This new identifier is, as I said, not meaningful by itself.  Neither 
is any other byte string.  Like any other identifier, it needs to have 
meaning attached to it.

For example, one might use my protocol:

    http://www.clark.net/pub/cme/usenix.html

to attach meaning to the new identifier.  Alternatively, one can rely on new 
certificates to do the attachment, as I described in earlier messages.

 - Carl

-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.5.3

iQCVAwUBNZVG/RN3Wx8QwqUtAQGn6gP9EfgjIZgQLlp4IqHqG133w+LPWiE659xf
xPKPVrHwKB2HSjqUxHjbtSIde55TBSM9mGY45bXA0kH/uAsNE1XFzsovrl0oySDP
EWloPFlNw/8ZRnRB1smiVNhb//N5kY4H9telcuY6Kc00tPyww76Uu2Kb0JV1+wbD
Z3+/BtHslLw=
=FCkN
-----END PGP SIGNATURE-----


+------------------------------------------------------------------+
|Carl M. Ellison  cme@cybercash.com   http://www.clark.net/pub/cme |
|CyberCash, Inc.                      http://www.cybercash.com/    |
|207 Grindall Street  PGP 08FF BA05 599B 49D2  23C6 6FFD 36BA D342 |
|Baltimore MD 21230-4103  T:(410) 727-4288  F:(410)727-4293        |
+------------------------------------------------------------------+
From ???@??? Mon Jun 29 09:26:19 1998
Received: by mis01.reston.cybercash.com; id HAA21043; Sun, 28 Jun 1998 07:52:27 -0400 (EDT)
Received: by callandor.cybercash.com; id HAA23006; Sun, 28 Jun 1998 07:51:36 -0400
Received: from blacklodge.c2.net(208.139.36.35) by callandor.cybercash.com via smap (3.2)
	id xma022996; Sun, 28 Jun 98 07:51:16 -0400
Received: (from majordom@localhost) by blacklodge.c2.net (8.8.5/8.7.3) id EAA09682 for spki-outgoing; Sun, 28 Jun 1998 04:38:03 -0700 (PDT)
X-Authentication-Warning: blacklodge.c2.net: majordom set sender to owner-spki@c2.org using -f
From: DoWneR@mail.dma.be
Message-Id: <199806281136.NAA11863@bewoner.dma.be>
To: spki@c2.net
Date: Sun, 28 Jun 1998 13:36:00 +0100
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Final Year Thesis : SPKI
Sender: owner-spki@c2.net
Precedence: bulk
Status:   

Hi guys,

My name is Olivier Dellicour. I'm 24, I'm Belgian and I live in 
Brussels. I'm a Business Ingeneer student and like every students 
around the world I have to write a final year thesis. Mine is about 
electronic certification and SPKI. I have to compare SPKI 
certificate and its competitors (X.509, ...) and demonstrate that 
SPKI is better (at least try to !!!). As you can imagine, I'm not a 
100% "techi guy" even if I love computers and that's why I need your 
help! Could you plz give me some clues about where to find 
informations about SPKI, what are according to you the advantages of 
SPKI, is there other products competing with SPKI, is SPKI going to 
become a standard soon, ... In fact every information is welcome!!!
Thank you very much in advance,
Olivier
___________________________________________________
DELLICOUR Olivier
UCL - IAG - INGE23
Av. de Mai, 272
1200 Brussels
BELGIUM
___________________________________________________
From ???@??? Mon Jun 29 09:26:26 1998
Received: by mis01.reston.cybercash.com; id LAA22320; Sun, 28 Jun 1998 11:07:31 -0400 (EDT)
Received: by callandor.cybercash.com; id LAA00201; Sun, 28 Jun 1998 11:06:37 -0400
Received: from blacklodge.c2.net(208.139.36.35) by callandor.cybercash.com via smap (3.2)
	id xma000193; Sun, 28 Jun 98 11:06:25 -0400
Received: (from majordom@localhost) by blacklodge.c2.net (8.8.5/8.7.3) id IAA12068 for spki-outgoing; Sun, 28 Jun 1998 08:00:26 -0700 (PDT)
X-Authentication-Warning: blacklodge.c2.net: majordom set sender to owner-spki@c2.org using -f
Date: Sun, 28 Jun 1998 11:00:00 -0400 (EDT)
From: Judie Mulholland <judiemul@kc-inc.net>
Reply-To: Judie Mulholland <judiemul@kc-inc.net>
To: DoWneR@mail.dma.be
cc: spki@c2.net
Subject: Re: Final Year Thesis : SPKI
In-Reply-To: <199806281136.NAA11863@bewoner.dma.be>
Message-ID: <Pine.LNX.3.96.980628095943.1274A-100000@c3po.kc-inc.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-spki@c2.net
Precedence: bulk
Status:   

olivier

there is tons of stuff out there that you can easily dig up with the
search engines. however, what i am going to give you are some meta-sites
that you can use as a jumping off point:

first off, if you are doing a comparative approach, then you definitely
want to consult marc branchaud's master thesis (march 1997): 

"A Survey of Public Key Infrastructures"
(http://www.xcert.com/~marcnarc/PKI/thesis/).

as well, check out his:

PKI REFERENCES
http://www.xcert.com/~marcnarc/PKI/References.htm

although somewhat dated now, imho, this thesis contains an excellent
framework which enumerates most of the key characteristics that are common
to all pki infrastructures.

another one:

Summary of Important Requirements for A Public Key Infrastructure
http://www.jya.com/nrc0h.txt


plus (and i am just doing this from the top of my head, so no doubt i am
going to leave some important meta-sites out, but this is enought to get
you going):

Carl Ellison's Home Page:
http://www.clark.net/pub/cme/

http://www.clark.net/pub/cme/html/spki.html
SPKI Certificate Documentation
Carl M. Ellison

Public-Key Infrastructure (X.509) (pkix) 
Stephen Kent, Warwick Ford
http://www.ietf.cnri.reston.va.us/html.charters/pkix-charter.html

Commonwealth of Massachusetts
The PKI Page
http://www.state.ma.us/itd/legal/pki.htm

CIT Public Key Infrastructure (PKI) Group
http://www.alw.nih.gov/pki/index.html

Public Key Infrastructures and Related Topics (SSL, X.509, X.500, etc.) 
http://www.alw.nih.gov/~rmalick/Certs/

http://www.dstc.qut.edu.au/MSU/projects/pki/
Public Key Infrastructure (PKI)

NIST PKI Program
http://csrc.ncsl.nist.gov/pki/

http://www.columbia.edu/acis/rad/pki/
Public Key Infrastructure references

http://www.pca.dfn.de/eng/team/ske/pem-dok.html
Comprehensive list of Public Key Infrastructure (PKI) links

and be sure to check out various vendor sites (like belsign, cert,
entrust, ibm, belsign, verisign, etc.) for some of their reports and/or
conference/white papers. 

/j

Ph.D. Candidate				Voice: (850) 942-1628
School of Information Studies		Fax:   (850) 942-0709
Florida State University		Email: judiemul@kc-inc.net 
Tallahassee, FL 32306                   judiemul@lab.housing.fsu.edu



On Sun, 28 Jun 1998 DoWneR@mail.dma.be wrote:

> Hi guys,
> 
> My name is Olivier Dellicour. I'm 24, I'm Belgian and I live in 
> Brussels. I'm a Business Ingeneer student and like every students 
> around the world I have to write a final year thesis. Mine is about 
> electronic certification and SPKI. I have to compare SPKI 
> certificate and its competitors (X.509, ...) and demonstrate that 
> SPKI is better (at least try to !!!). As you can imagine, I'm not a 
> 100% "techi guy" even if I love computers and that's why I need your 
> help! Could you plz give me some clues about where to find 
> informations about SPKI, what are according to you the advantages of 
> SPKI, is there other products competing with SPKI, is SPKI going to 
> become a standard soon, ... In fact every information is welcome!!!
> Thank you very much in advance,
> Olivier
> ___________________________________________________
> DELLICOUR Olivier
> UCL - IAG - INGE23
> Av. de Mai, 272
> 1200 Brussels
> BELGIUM
> ___________________________________________________
> 




References: