RE: CERTificates and public keys

["Loomis, Rip" <GILBERT.R.LOOMIS@saic.com>]

As another member of the "Security Mafia" I find
I have to both agree and disagree with Derek:

1. I would strongly prefer to have all the random
	keys that are *not* part of the DNS
	infrastructure end up in a single place.
	This eases the load on DNS implementors,
	and (in my opinion) provides a clearer
	interface even for application authors.
	Based on current DNSSEC implementations,
	if an application wants to use DNSSEC as
	the security to protect a bare public
	key, then the application needs to walk
	the signature chain itself anyway--so
	from that point of view there is no real
	advantage to segregating "appkeys" (that
	rely on DNSSEC) from "certs" (that provide
	an alternate verification path.)

	The only advantage would be if, as was
	stated in another e-mail, the APPKEY record
	needs to be a "heavier" (more featureful)
	record for bare keys than for certificates,
	since the certificates already contain
	relevant information.

2. CERT, in many peoples minds, *does* mean an
	X.509 certificate.  Plain and simple.
	Words in RFC 2538 *do* tend to confirm
	this, in my opinion.  Pushing bare keys
	into the CERT record would seem likely to
	cause confusion.

Overall, I recommend *again* that we deprecate
CERT in favor of APPKEY or something.  We (okay, I)
want a single stowage box for all the random keys,
certificates, CRLs, and other non-DNS items that
are going to get represented in the DNS--and I
would prefer that the name of that box be more
general than CERT.

Let's go meddle in the affairs of IESG wizards and
ask for another RR type.   We need APPKEY (or
something similar) anyway, rather than shoehorning all
the refugee non-DNSSEC keys into CERT.  Whether we
then deprecate CERT is an open question--but I think
it's cleaner to deprecate CERT.  (Some folks in
the security field spend time deprecating CERT anyway,
but that's a CERT of a different color.)

Am I missing anything?

--
Rip Loomis
Senior Systems Security Engineer
SAIC Center for Information Security Technology 

> -----Original Message-----
> From: Havard Eidnes [mailto:he@uninett.no]
 
> > It would be less confusing than having to have each app 
> decide whether
> > it's looking for a 'Cert' or 'Appkey' record when it wants 
> to look for
> > a key in the DNS.  Having a single place to look is a Good 
> Thing (TM).
> 
> In my humble opinion, this is simply wrong.
> 
> As I said before: a key is not a certificate and a certificate is not
> a key (although it *contains* one), and we should *not* promulgate the
> confusion that those two are the same.  The misnomer "pgp key" comes
> to mind.
> 
> An application writer or protocol designer knows up front whether the
> application should ask for a certificate with its own built-in
> integrity/authenticity verification system, or just raw (public) key
> material which would then depend on DNSSEC for the integrity/
> authenticity verification.
>