Re: CERTificates and public keys

[Jakob Schlyter <jakob@crt.se>]

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

for applications that use certificates, we can use CERT. today. but for
applications that uses raw public keys, such as ssh and IPsec w/o X.509,
we need something, i.e. DNSSEC, to sign the raw keys. I believe that not
putting such data in CERT actually simplifies things. CERT has nothing
more to do with DNSSEC than TXT or A. KEY and APPKEY has since their
entire existance depends on the DNSSEC signature mechanism.


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

these application need there own revocation system, such as the provided
by X.509. we can't revocate KEY and we might not have to - one could use
very short signature lifetimes and achive something very similar to
revocation.


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

few people have suggested giving up the existing infrastructure - CERT is
build to interface to that infrastructure. on the other hand, we're trying
to build something that did exist before - a DNS you can trust in.


	jakob