Re: CERTificates and public keys

[Simon Josefsson <simon+dnssec@josefsson.org>]

Edward Lewis <lewis@tislabs.com> writes:

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

I agree with the above with the exception of the CERT RR issue.

Doesn't the "why not TXT instead?" issue apply to most things in DNS
not intended for DNS-internal consumption?  Couldn't the same "issue"
be used against, say, APPKEY?  Why not use TXT instead of APPKEY?

Certificates (and public keys) are meant for use by computers, and not
even in text format, so using TXT for this would be a bad idea, I
think.  Using TXT as a kitchen sink doesn't seem right.

So, I don't see any issues against putting unsigned public keys in
CERT RR.  This is what I have failed to learn from this discussion,
please argue against my reasoning above or provide other arguments
against putting public keys in CERT and I'll be happy with APPKEY.