Subject: RE: A different architecture? (was Re: certificate path services [ was RE: NEW Data type for certificate selection ? ])

From: Alan Lloyd <[email-masked]>
Date: Wed, 28 Oct 1998 11:50:27 +1100

Phill - again you promote a separation - in an abstract way. But I
question why would one implement 509 without X.500? What is the
separation in terms of distributed information system engineering and
what is your solution of dealing with the need to have single logon on
to distributed services and single information entities representing
customers, staff and assets - that have certificates applied.?

Many organisations have many customer databases - islands of "may be
replicated" information. This equals high operational costs, high risks
to business because of inconsistency, inability to scale, long service
provisioning times - ie. a high cost mess. Directory technologies
provide a damn good vehicle to consolidate these information systems.

It seems you are proposing to put PKIs over a fragmented and legacy
information pradigm. Wont this add to the mess?
Your words
	"In other words you do not want to have a directory
intermediating
	between the PKI and your application."

Can you tell us how you do this? given that the application has to chase
across the planet in a standard way for an object that represents the a
certficate user (or CA)- and that such an object will have other
business details and attributes,  will have to exist somewhere in a
distributed environment - and for the sake of efficiency and cost and
the integrity of service provisioning (by large corporates) should exist
in one place -- by NAME.

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?
Isnt this a bit like deploying secure telephones (with customised wires)
without a telephone network?

regards alan
> -----Original Message-----
> From:	Phillip M Hallam-Baker [SMTP:[email-masked]]
> Sent:	Tuesday, 27 October 1998 8:25
> To:	[email-masked]
> Cc:	Alan Lloyd; Al Arsenault; Stephen Kent; [email-masked]
> Subject:	RE: A different architecture? (was Re: certificate path
> services [ was RE: NEW Data type for certificate selection ? ])
> 
> 
> 
> > there are business operations with account-based systems with
> >100million
> > entries and raw
> > data in tens of terabytes. for business process that have to access
> the
> > account record to complete the transaction, splitting responsibility
> for
> > the transaction between an account infrastructure and a PKI
> infrastructure
> > ... doesn't improve availability ... it actually lowers it since now
> there
> > has to be two things that are operational for transaction completion
> 
> I would not propose such a split. In fact I think it argues to my
> point.
> 
> Perhaps I have been unclear, the functional division I see as
> essential
> is at a somewhat abstract level. I want to avoid bluring the
> distinctions
> between PKI functions and information distribution functions precisely
> so that applications such as Lynn's can be supported.
> 
> 
> You want the authentication information from the PKI to directly mesh
> into the authorization information supplied by your application.
> 
> In other words you do not want to have a directory intermediating
> between the PKI and your application.
> 
> The question to ask is 'what box (program etc.) have I just added
> that can break?'
> 
> If there is a per-transaction protocol connection required for PKI
> use, it will as you said reduce your availability. But PKI is not
> inherently protocol oriented. Nor is it necessarily a 'box to
> break'. It would be more accurate to view being 'PKI aware' as being
> a quality of systems rather than "THE PKI" being a discrete system
> in its own right that can be pointed out in the control room and
> thumped with a hammer when it breaks:-)
> 
> In other words the PKI should not mandate a 'coherent directory
> infrastructure' since the PKI abstraction should not care how the
> bits arrived so long as they are properly signed. But what the PKI
> suite of standards MUST do is to state how to link to a directory
> to obtain such information in the case where one is available.
> 
> 
> To permit scale your PKI protocol infrastructure needs to be entirely
> integrated within your transaction protocol infrastructure - at least
> for that *particular* application. That does not mean however that
> there is no 'PKI' component or indeed that every piece of the
> infrastructure must be integrated at that level - certificate
> issue could well be independent.
> 
> A good reason to be ruthless when insisting on separation of function!
> It is very easy to propose tweaks that look very good in a limited
> context but fail in a larger one.
> 
> 		Phill
> 
> 
> [PS OK I'll admit that it is much the same once you get up to
> Terabytes
> of data but I was talking about input bandwidth, not just static
> storage :-) I think that you Steve and myself are essentially arguing
> the same point though.]
>

---

From: "Phillip M Hallam-Baker" <[email-masked]>
Date: Wed, 28 Oct 1998 11:37:21 -0500

Alan issued the following challenge,

> 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