Subject: RE: Cert binding to ?

From: Andrew Probert <[email-masked]>
Date: Wed, 3 Mar 1999 16:02:48 +1100

Well, there is the school of thought that Certficates are largely anonymous
e.g. the Issuer is known but that the certificiate contains a unique but
quite arbitrary name.

Bindings are accomplished by Attribute certficates, countersigned by CAs to
impart privileges, they can contain private data specific to each CA /
business purpose, but if necessary are never transmitted / seen by the world
at large.

Is this a better mapping to ecommerce where one currently has a hand-written
signature, which is forensically provable, but privileges imparted are
specific to each organisation / purpose!

Andew Probert
Rotek Consulting   http://www.rotek.com.au
a Division of Secure Network Solutions
Tel  +61 3 9690 8877
Fax +61 3 9690 8171

> -----Original Message-----
> From:	Martin Smith [SMTP:[email-masked]]
> Sent:	Wednesday, March 03, 1999 2:06 PM
> To:	PKIX list
> Subject:	Cert binding to ?
> 
> Please excuse the naive and perhaps slightly off-topic intervention, but
> I can't shake the feeling that more thought needs to be given to what a
> certificate is being bound to.  I have become thoroughly disenchanted
> with DNs, or names for that matter, in any namespace scheme.  Consider
> the increasing irrelevance of political boundaries; the transience of
> employment status, not to mention the rise of self-employment.  After
> all, the idea of an heirarchcal namespace seems to have been a device
> simply to assure uniqueness under distributed management. What a lot of
> baggage for that end!
> 
> Leaving aside the naming issue, it seems that the heart of what PKI
> should be about (if it is to make the cost/benefit cut) is binding an
> assertion or value to a key.  The commonest "assertion" of interest
> seems to be identity.  But what is identity?  As a guy named "Smith", I
> have to tell you it's not enough to know my name to know who I am or to
> find me.  Cutting to the chase: binding to identity comes down to
> "binding to the meat".  In the end, identity binding means I anticipate
> the need to apply physical compulsion to the object of my interest.  I
> want to be able to put him in jail, or ship him out of the country.  The
> obvious binding for identity is therefore to a (digitized) physiological
> characteristic: fingerprint, retinal scan, DNA.  And by the way:
> uniqueness is pretty much taken care of, too.  No problem to add a
> handle for user-friendliness.  Mine's Mike Smith and this is my partner,
> Jane Doe.
> 
> The other bindings of interest are to attributes:  a Swiss account
> number; a surety bond; a role (supervisor; treasurer; judge.)  These may
> often be attached to a meat binding, but not necessarily.  Why not be
> able to open an account anonomously, receive a key for that account, and
> present the key to make a withdrawal.  The DEA might care who you are,
> but the banker should not. And why should a role be bound to a person?
> Why not to a process?
> 
> Moving right along, what does this line of thinking imply for the matter
> of transitive trust (cross-certificates?)  Most of the time I hear
> people (who are actual or prospective CAs/RAs) talking about trusting a
> foreign certificate they mean they trust that the other CA has made
> reasonably sure the holder is (or recently was) an employee of the other
> CA's company.  Generally the name is not meaningful (to the local CA;
> perhaps it is to the ultimate relying party if it's an e-mail
> correspondence.)  And generally other attributes (like: is the person an
> employee, or just a contractor?  Cleared for SECRET?; authorized to make
> purchases?) are not known.  To do real business (not supported by a web
> of other, non-electronic information) you need the attribute bindings.
> Most certainly making inferences from a DN is hazardous.  My only point
> here is that for a given transaction, you will typically need a cluster
> of bindings, and that those bindings will have different trust paths
> leading to CA's that are in charge of (that is, they warrant with
> effective recourse for the relying party) different assertions or
> values.  In other words, fussing about naming schemes is is distraction.
> 
> Martin Smith (or not)
>  << File: Card for Martin Smith >>

---

From: WHenry <[email-masked]>
Date: Thu, 4 Mar 1999 11:46:11 -0500

This is an interesting concept. However, tying a cert to something "meaty"
like a fingerprint doesn't preclude the fact that a relying party still
trusts a 3rd party (the CA) to create the binding between a user and a
public key.

 How can I be sure that a cert issued by CA "X" for Bill Henry is in fact
Bill Henry (even with a fingerprint association)? Nothing prevents a corrupt
CA from issuing certs to users with falsified fingerprint info. Unless I
have access to a national fingerprint database, I'm still trusting the CA's
representation of who Bill Henry is.

 Bill Henry
 Performance Engineering Corporation
 Fairfax, VA

> Sent:	Tuesday, March 02, 1999 10:06 PM
> To:	PKIX list

---

From: Alan Lloyd <[email-masked]>
Date: Sun, 7 Mar 1999 23:43:59 +1000

Oh dear...
The reason why LDAP "succeded" was that directory vendors including
those who supply X.500 directory services adopted it. It just now that
people are realising that single non distributed LDAP servers are just a
good as a traditional database approach ie highly limited - and that all
that has happend is that in this case people have swapped SQL for LDAP -
wow!
When one has to replicate everything to everywhere with LDAP only
systems - they be come a nonsense.

Anyway we provide directory services that permuit LDAP access and LDAP
servers to be connected as subordinate servers. Its just that we do
distribution part - the complex part - the essential part - and many
other things that make a distributed information system work - including
LDAP.

LDAP is -- an access protocol - to what?

X.500 defines that.

I often think that if I stood in the street and tried to sell car doors
- people would think I was strange. But if I say LDAP does it all - then
that makes me an industry leader! :-)

regards alan

PS we are using X.500 as back ends for DNS/DHCP and RADIUS servers so
that the ISPs using them can scale their operations - ie there is a bit
of a dependency here with ISPs and X.500.

----------
From: Martin Smith
To: Alan Lloyd
Cc: 'PKIX list '
Sent: 3/5/99 12:13:19 PM
Subject: Re: Cert binding to ?

It seems to me that the problem with the X-standards was not that they
were
too complex, but that they were being run by the wrong people.  It's
been
observed more than once that the "lightweight" in LDAP is fast
disappearing.
And why not, with RAM at $1/meg and disk at $100/gig?  The reason LDAP
succeeds is "running code and rough concensus."

Alan Lloyd wrote:
snip

> the directory service of usage of DNs does not mean that the system is
> geopolitical. Its just many have seen X.500 as too big (12 mb) DAP as
> too big (130 kb), that X.500 is THE global directory not A directory
> service, one of many) and that PKI roots = directory roots, etc.

> snip