Re: CERTificates and public keys

[Simon Josefsson <jas@extundo.com>]

Edward Lewis <lewis@tislabs.com> writes:

> We actually found the use of CERT to be a real problem.  The reason is that
> there is no standing certification authority that could back the CERT
> record.  That is a major stumbling block, for without this, the CERT record
> is far worse than the KEY RR.  This is because the KEY RR is at least
> backed by "standard" DNSSEC key chaining policy (we can debate whether a
> resolver follows the "standard" - which is defined in RFC 3007 or 3008 -
> but at least the resolver follows a DNS based infrastructure).
>
> So, Wes and I would like to hear comments on why certificates would be an
> improvement upon public keys when managing infrastructure keying material -
> e.g., host keys for SSH, IPsec, etc.

I do not think I understood the first paragraph (what do you mean by
there being no CA backing the CERT record?  I agree with the
statement, but I do not see why it matters), but here are my
top-of-the-head reasons for preferring certificates in CERT over
public keys in KEY.

* No requirement on DNSSEC to protect the keys.

  DNSSEC isn't happening now, while applications using public keys
  (SSH, IPSec, S/MIME, PGP..) is happening.

* DNSSEC only guarantee origin authentication.

  This is probably too weak for some applications. I want to trust
  that a public key belong to a certain host or person.  Only being
  able to trust the origin of the information is weaker.  Putting a
  SSH KEY RR in DNS doesn't authenticate that key as belonging to the
  host (which is what you want) but rather that you trust that the
  public key came from a certain origin.  Maybe this is subtle and can
  be ignored for SSH or IPSEC (where you could assume that if it came
  from the domain where the machine lives in you trust it as belonging
  to the host). But I wouldn't trust a key for S/MIME or PGP purposes
  based only on the fact that I know where the key came from (how do I
  know they checked the identity of the user before signing his public
  key?).

* Key revocation.

  Keys used by several applications have different requirements than
  DNSSEC KEY's, several applications need revocation functionality.

* Reuse of trust infrastructure in applications.

  Today applications usually trust some predefined set of CAs.
  Changing the trust infrastructure in the application to support the
  DNSSEC way is more difficult than retrieving keys signed by the CAs
  using DNS.  (And I don't see any advantages of doing the change,
  only some disadvantages, like giving up revocation.)