Subject: PKIX Scale (and the SRV record)

From: "Phillip M Hallam-Baker" <[email-masked]>
Date: Fri, 30 Oct 1998 11:15:10 -0500

All,

	I would like to propose a minor extension to the SRV record
to allow classes of information service to be advertised. The reason
for this is that certificate repositories will play a critical role 
in PKIX. Those repositories will probably be implemented using LDAP 
but may be implemented using protocols such as HTTP.

	In either case there is a distinction between the 'data class'
and the 'data transport'. An enterprise may well have many directories
holding different categories of data. The directory the PKIX clients
need to access is quite likely only one of these. I propose using a
'data class' prefix with the SRV record thus: 
	__pkix._ldap._tcp.xyz.net

	The problem is even more acute when using HTTP. A company may 
have 60 or more HTTP servers, but only one or two are likely to be
the certificate repositories.

	Also we need to have a hook for drafts which define what the
expectations of a 'PKIX' service would be. I would like to be able
to stipulate that if a SRV record is in the DNS advertising a
__pkix that it will have a certain relationship to the DNS names. Ie
advertising 

	__pkix._ldap._tcp.xyz.net SRV 0 0 389 certs.xyz.com

	indicates that certs.xyz.com has a PKIX compatible schema and is
populated with certificates with email addresses matching [email-masked]'.

	I see this usage being upwards/backwards compatible with 
the current SRV proposal.

	The way forward I would suggest is that namedroppers modify the
SRV draft to allow this usage - stipulating that the definition of 
'data class' terms is an IANA task. Then a parallel draft can go
into PKIX which would define the interpretation of __pkix.

		Phill

This is the post I sent to the PKIX list where the idea is generally
well received except by our resident X.500 fanatics who want to replace
DNS:

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: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Sat, 31 Oct 1998 09:16:55 -0500

I don't see anything wrong with this idea and I don't think it
requires any change in the SRV RR.  A separate draft describing how to
do this and giving IANA considerations for "data class" seems fine.
There might even be cases where "data class" is hierarchial.

Thanks,
Donald

From:  "Phillip M Hallam-Baker" <[email-masked]>
To:  "Namedroppers" <[email-masked]>
Date:  Fri, 30 Oct 1998 11:15:10 -0500
Message-ID:  <[email-masked]>