Subject: Scale (and the SRV record)

From: Russ Housley <[email-masked]>
Date: Wed, 28 Oct 1998 13:28:48 -0500

Alan asks:

> 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?

Directory is the preferred certificate repository, but it is not the only
repository that will scale.  People have used FTP, Finger, HTTP, and other
mechanisms to distribute certificates.

The PKI is not dependent on the deployment of a Directory, as these other
mechanism can be used until the Directory become widely available.

Further, a trusted repository is not a requirement.  Since certificates and
CRLs are signed, the repository cannot make undetected modification to the
data structures.  Denial of service is allways an issue; it is a concern in
all of the possible repository alternatives.

Russ

---

From: [email-masked]
Date: Wed, 28 Oct 1998 13:56:23 -0500

>Denial of service is allways an issue; it is a concern in

At the risk of stating the obvious, a denial of service that
prevents you from getting revocation information (such as a
CRL) can be Very Bad, given the implementation quality of most
network services that I've seen...

---

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

Russ,

	You are right of course! Note that the scheme I propose allows a
certificate repository whose naming scheme is PKIX compatible to also be
advertised. We might have:

	__pkix._http._tcp.arius.com
	__pkix._ldap._tcp.arius.com
	__pkix._finger._tcp.arius.com

	or even!

	__pkix._verynewprotocol.arius.com

	And since an SRV record is simply an MX record on steroids each
can define server priorities and preferences.

	What would then be required is a draft describing the naming
conventions such a server would conform to and how clients should
interpret the scope of the statement. __pkix._http._tcp.arius.com
is essentially saying "look at the corresponding server where you
will find a PKIX repository whose scope includes (all?) certificates
issued which are bound to DNS names within the scope 'arius.com'."

	Alan will have a directory there (we presume) as I would expect
would most enterprises. There might be a move in favour of an HTTP
service acting as a border directory and an LDAP server providing
a more flexible, searchable service inside the enterprise.

		Phill

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf
> Of Russ Housley
> Sent: Wednesday, October 28, 1998 1:29 PM
> To: Alan Lloyd
> Cc: [email-masked]
> Subject: Scale (and the SRV record)
>
>
> Alan asks:
>

---

From: Bill Burr <[email-masked]>
Date: Wed, 28 Oct 1998 17:21:03 -0500

Phill, 

I'm in a bit over my head here now (arguably I have been all along),
because I don't understand SRVs very well, and I had the impression that
they're more a proposal than a reality.  Would we be betting on the come
here?  Or is support SRVs really in DNS servers and resolvers now?

Regards,

Bill Burr

---

From: Bruce Greenblatt <[email-masked]>
Date: Wed, 28 Oct 1998 20:56:54 -0800

I know the answer to this one...  SRV records are a reality, and are
supported in the current version of Bind (the most common implementation).
It is also my understanding that several other implementations have support
for SRV records.  Another interesting DNS resource record that could be
useful in this area is the NAPTR record.  Note that SRV records are defined
in RFC 2052, and NAPTR records are defined in RFC 2168.

Bruce

>here?  Or is support SRVs really in DNS servers and resolvers now?
================================================
Bruce Greenblatt              [email-masked]
http://www.innetix.com/~bruceg
================================================

---

From: "Phillip M Hallam-Baker" <[email-masked]>
Date: Thu, 29 Oct 1998 10:24:07 -0500

> here?  Or is support SRVs really in DNS servers and resolvers now?

The proposal is actually quite old - the RFC has been out for two years
as 'experimental'. But the code is widely deployed in the bind code, not
surprising sinc Paul Vixie was the author of the SRV draft and the re-author
of bind.

The Vixie-bind code is greatly preferred over its predecessors in any
case since it has considerable proofing against DNS spoofing attacks added.
Irresprective of whether a site was to use SRV they should upgrade to
the latest release of bind.

The Microsoft situation is slightly different. I could not persuade my
NT DNS server to accept an SRV record, but as Microsoft stated at the TWG
they are awfully keen on it. Basically the SRV record is the glue between
the DNS system and active directory it appears.

		Phill