Subject: RE: Scale (and the SRV record)

From: WHenry <[email-masked]>
Date: Wed, 28 Oct 1998 12:42:33 -0500

Phillip,

 The problem with this remark is that 9/10 of all SSL sites are using SSLv2,
and there is no "real" authentication happening here.

 Example...  just because Verisign's cert is posted in my browser doesn't
mean:
	1. I should trust that this embedded cert is valid, and
	2. I should trust an online vendor that he/she is who they say they
are.

 Verisign's own Certification Practice Statement (CPS) says it all: Versign
is not liable for verifying the identity of certificate users.

 Bill Henry
 Fairfax, VA

	"Look at the one already deployed and work it out. The SSL secured
part of
	the Web does not stop working if directory.verisign.com goes down."

> -----Original Message-----
> From:	Phillip M Hallam-Baker [SMTP:[email-masked]]
> Sent:	Wednesday, October 28, 1998 11:37 AM
> To:	Alan Lloyd
> Cc:	Stephen Kent; [email-masked]
> Subject:	Scale (and the SRV record)
> 
> Alan issued the following challenge,
> 
> > I need to be enlightened - How does one deploy a large scale distributed
> > PKI without a large scale object oriented distributed (and protected by
> > ACI, etc) directory system?
> 
> Seems like a good question, it occured to me that now is a good time to
> raise it.
> 
> Look at the one already deployed and work it out. The SSL secured part of
> the Web does not stop working if directory.verisign.com goes down.
> 
> I have had this arguement before with the hypertext establishment. They
> could never figure out how it was possible to have global network
> hypertext
> without an 'object oriented distributed' database. They were completely
> wrong but that did not stop them from rejecting every conference paper
> on the Web, until the time came when they were clamouring for Tim B-L to
> give the keynote!
> 
> The greater the scale the less weight a base information system can carry.
> A transactional database can scale to tens of hosts at best - and even
> then
> this requires carefull choice of the transactions allowed. A directory
> system
> scales further because it guarantees so much less in terms of consistency
> across transactions. Finally at global scale it is not practical to deal
> in
> data, we must deal in names instead, names in this case being of Pierce's
> 'thirdness' quality and whose persistence can defined (Time To Live) to
> make the DNS sytem tractable, precisely because they have Sebok's 'Name'
> property - the relationship between the symbol and the designatum is
> purely conventional.
> 
> Compare this approach to what we do with PKI, we use public key to
> establish a trust framework we then leverage with private key. Or as
> an analogy consider the task of throwing a heavy rope across a chasm,
> starting with a thin, light piece of string and working up.
> 
> Making PKI scale to global reach is no more than a matter of naming. Bind
> the network level directory infrastructures to the internet naming system
> which is and will continue to be DNS.
> 
> There is already a DNS resource record defined for the purpose - SRV. If
> we assume that every enterprise has deployed a border LDAP directory
> populated with the certificates of its employees we can send encrypted
> S/MIME messages to any certificate holder as follows:
> 
> Email client is to send to [email-masked], there is no cert in the address
> book:
> 
> 1) The client obtains the DNS RR's for arius.com
> 2) The client examines the SRV records, there are three
> 	_ldap._tcp.arius.com	SRV 0 0 389 directory.arius.com
> 	_ldap._tcp.arius.com	SRV 1 3 389 fast.backup-site.net
> 	_ldap._tcp.arius.com	SRV 1 1 389 slow.backup-site.net
> 3) The client attempts to connect to the server with the lowest priority
> 	number which offers a directory protocol that is understood,
> 	in this case directory.arius.com offers LDAP over TCP/IP
> 4) The client does a search for an entry with a mail atribute of
> 	[email-masked]
> 5) The client retrieves the certificates for the entry, there are three
> 	of which one is a currently valid one for [email-masked]
> 6) The client encrypts the email
> 7) The client sends the email
> 
> 
> Note that we have only one large scale infrastructure and it is DNS. I
> don't know if that meets the definition of 'object oriented' or not.
> 
> Note also that this could equally well be achieved using some other
> type of server since as far as the client is concerned it is making
> an unambiguous query to a server. The question of the ideal server
> to server protocol is irrelevant to the client.
> 
> 
> The question of whether the certificate returned is one that can be
> trusted is orthogonal. Note that it is not one which in this case
> may be made by the server since it is most unlikely the client will
> in the general case be willing to share its trust criteria with an
> untrusted service.
> 
> 
> There is just one minor change we might want to make to the current
> SRV proposal. It would be useful to have a means of differentiating
> directories on the basis of the information held. Specifically it
> would be useful to be able to differentiate a directory acting as a
> PKIX repository for a particular domain.
> 
> I would suggest that we ask that the SRV naming convention be extended
> a single level to provide a 'category' modifier, in this case PKIX.
> The above RRs would therefore be :-
> 
> 	__pkix._ldap._tcp.arius.com	SRV 0 0 389 directory.arius.com
> 	__pkix._ldap._tcp.arius.com	SRV 1 3 389 fast.backup-site.net
> 	__pkix._ldap._tcp.arius.com	SRV 1 1 389 slow.backup-site.net
> 
> The same convention could be reused in other areas, for example
> there is an urgent need for the universities to have some kind of
> protocol for discovery of journal articles, pre-publications and
> such. Say a working group sets up a set of conventions and a schema
> for such stuff called 'LIBRY', they might have __LIBRY._ldap._tcp
> and __LIBRY._http._tcp SRVs defined. And of course there would be
> __ocsp._http._tcp.
> 
> The point here is that we can leverage a widely deployed
> infrastructure. Paul Vixie modified the bind code three years ago and
> the upgrade has largely percollated.
> 
> We can either spend time arguing what a global X.500 infrastructure
> will do fo us when it arrives or we can build on what we have deployed.
> 
> So before proposing a change to the DNS/namedroppers folk what is the
> PKIX list view?
> 
> 
> 		Phill
> 
>

---

From: "Perry E. Metzger" <[email-masked]>
Date: Wed, 28 Oct 1998 13:59:19 -0500

> is not liable for verifying the identity of certificate users.

Reminds me of four different talks given at the Usenix E.C. conference 
a couple of months ago, all of which were of the substance "third
party certificates with liability disclaimers are worthless..."

.pm