Re: Certificates and public keys

[Ólafur Guðmundsson <ogud@ogud.com>]

At 05:01 PM 9/6/2001, Simon Josefsson wrote:
>On Thu, 6 Sep 2001, Ólafur Guðmundsson wrote:
>
> > APPKEY with SRV naming is the best solution that I have seen for
> > applications because
> >          1. it keeps key sets small (only one application related keys in
> >             each set) thus minimizing the work in applications while
> >             searching for the relevant record.
> >          2. It allows for version handling (by changing name)
>
>How is this better than using e.g. CERT with SRV naming?  APPKEY is also
>sub-typed.  CERT with SRV naming also meet your requirements, as far as
>I'm able to tell.
>
>If APPKEY is supposed to be CERT Done Right, which I think would be a nice
>goal for it, should it repeat the presumed mistake of sub-typing?

No APPKEY is not CERT done right, it is "cheap, dirty and simple" key
advertisement record for various application protocols.
CERT has baggage both in data and understanding (see rfc2828) for all
the different terms certificates have associated with them.
I think there is value in having CERT records but ONLY for real certificates.



> > The alternative solution in my mind is to use NEW RR type for each
> > application but due to DNS server and resolver frequent lack of support
> > for new RR types this is not a good solution.
>
>*ponders*  So if I understand correctly, CERT is flawed because it uses
>sub-typing.  APPKEY using SRV naming is "better" (altough I fail to see
>how) but still uses sub-typing, so with the same reasoning it wouldn't be
>good either.  New RRs is better but would be harder to put into use because
>of implementation issues.

CERT if flawed due to the fact that PGP and X509 formats are stored in
the same record.
APPKEY is flawed because RSA, ECC, DSA, DH keys are stored in the same format.
Using APPKEY we avoid all the (non technical) issues related to when is
the contents of a CERT record certificate and when is it key.

*thinking out loud* Maybe we should fix this problem by creating a
collection of key record types, DHKEY, RSAMD5KEY, DSAKEY, RSASHA1KEY, ECCKEY
and have applications either ask for a particular record type or a meta
record type that gives you all.


>This suggests that no method of storing application keys or certificates
>in DNS is satisfactory, and that they simply shouldn't be stored in DNS.
>Is everyone happy with that conclusion?

You are getting to sensitive here, the question is what is the most reasonable
of the alternatives.

>Maybe an agreement of one of the suggested methods can be made instead.
>After this thread I don't care much about which one, just as long as there
>is one.  But considering that CERT exists and is implemented, I think it
>is a good candidate.

If we are going to do this lets try to get as much right as possible.
we have plenty of type codes to burn.

         Olafur