Subject: RE: the KEY debate

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 5 Aug 2002 08:29:07 -0700

> - The APPKEY/CERT/whatever stuff isn't as far along.  No doubt you
>   recall the SIKED BOF this year in Minneapolis, at which several
>   people asked some pretty fundamental questions about the problem
>   spaces people were trying to solve and what the underlying trust
>   models were.  No good answers at that time.  Not saying there
>   -aren't- good answers, but at that BOF there didn't appear to be any
>   kind of consensus on the subject.  So proponents of this idea have
>   some work cut out that either has not yet been done at all yet or
>   has been done but has not yet been walked through the IETF process.

I would pretty much agree with Rob here except that I would say that
there was no consensus in that meeting on how to use DNSSEC alone to
address that problem rather than a lack of consensus in the PKI world
on how to address that problem.

The complaint from the application vendors attempting to PKI enable 
apps has been that traditional PKI mechanisms are just too hard to
implement. One of the reasons for the complexity of X.509/PKIX PKI
is that it was not originally designed as a PKI, it was designed as an
after the fact security extension to a directory model.

Sound familiar?

The PKI world has been working on a key retrieval model PKI for 3
years now and we have a working group in a standards body and actual
deployments of XKMS.

XKMS is considerably simpler to implement on the client side than 
PKIX or DNSSEC can hope to be. This is possible because the XKMS
design was legacy free. The application makes a Web Service call 
of the form:

	Locate the parameters of key with [cryptographic key usage]
	to communicate with ([identifier] via [protocol]) *.

	e.g.

	Locate the parameters of an encryption key to communicate
	with [email-masked] via S/MIME or PGP.

Deployment of XKMS does not depend on DNSSEC but it would definitely
be useful if an application can locate the XKMS service for
wherever.test by means of a DNS SRV record, it is clearly more
useful still if that connection is DNSSEC secured.

Note that I am the principal advocate of this approach in the 
XKMS group. The other PKI vendors are understandably nervous about
a PKI linkage to DNS which is an area where VeriSign has market
share and they do not. At present the SRV argument is accepted on 
the merits. However I do not see any possibility any of them would
go any further down the DNS route.

If I thought that the keys in DNS approach had technical merit then
it would be in my company interest to push it as hard as I can.

Storing DNS keys in DNS makes sense, an argument can be made for 
storing XKMS keys in DNS, storing unrestricted application keys in
DNS makes no more sense than using DNS as an all purpose directory
for every piece of application data that might be requested.

Maintaining DNS records that are primarily bound to machines is very
different from maintaining Public Key records which may be bound to
a user, a machine or anything in between.

Finally, before attempting to address problems that are already being
addressed in open standards process elsewhere DNSEXT needs to first
agree to protocol changes that make DNSSEC deployable in .com and
.net. Until those changes are made DNSSEC will have precisely as much 
credibility as a group who has been trying to deploy for 10 years
deserves.

If DNS is as claimed so complex that necessary changes such as opt 
in have to be delayed three years (and counting) while non-security
experts get comfortable with the idea it is utterly futile to attempt
to use DNSSEC as a vehicle for a proposal that has the security area
directors distinctly uncomfortable.

		Phill

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 7 Aug 2002 09:04:51 -0700

The problem with the SIKED BOF is that the organizers had a preconcieved
notion of their solution and platform.

The reason that there was little interest in the SIKED approach is that
there is already an Open Working Group that is developing a key centric PKI
that provides a superset of the proposed SIKED functionality with much less
complexity called XKMS.

XKMS is supported by all the major PKI vendors and many others. It is an
important part of the infrastructure being developed to support Web Services
Security.

The IETF has spent ten years each developing PKIX and DNSSEC. There is no
likelihood that SIKED or anything like it will complete in under three
years. Nor after the DNS Directorate/OPTIN debacle can the IETF claim any
particular credibility as an open standards organization over W3C or OASIS.

This group has no business making proposals for general purpose PKI
infrastructure until it has proposed a deployable infrastructure to support
DNS itself.

	Phill