Re: CERTificates and public keys

[Edward Lewis <lewis@tislabs.com>]

After doing some re-reading of an April thread, and more recent mail:

The problem of mingling DNSSEC keys and applications keys consists of three
issues:
   1) size of the apex key set (which may be added to the additional section)
   2) parent signing of child's application key (application data)
   3) subtype processing (having the resolver pick just the dnssec keys)

The problem of putting application keys in KEY RR consists of:
   1) Not enough protocol and flag field bits

The problem of putting DNSSEC keys into a newer alternative (APPKEY):
   1) Backwards compatibility

The issue of putting unsigned public keys in the CERT RR:
   1) Why not just use the TXT record for this?

Before arguing with the rest of this, please make comments on the above.
Let's establish what it is we are trying to solve.  Assuming my break down
above is correct, I conclude:

The KEY RR shouldn't be modified, and although I am skeptical of having
multiple RR types for one purpose (holding a public key), I think the KEY
RR should be recommended to be used solely for dnssec protocol keys

The CERT RR should remain designed for publishing certificates that are the
products of a PKI (DNSSEC is not a PKI).

A newer, more flexible and expandable RR is needed for applications, and it
seems that Jakob's APPKEY RR is perhaps at minimum the only documented
proposal to meet this.  (Not to downplay it, but saying it is the best is
about as vacuous.)

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: lewis@tislabs.com

You fly too often when ... the airport taxi is on speed-dial.

Opinions expressed are property of my evil twin, not my employer.