Re: CERTificates, public keys, and the forgotten(?) generic protocol number draft

["Scott Rose" <scottr@antd.nist.gov>]

The CERT also helps if the client software does not trust DNSSEC, using a
unsecure resolver, or knows there is a break in the resolution chain (and
can't trace the CERT SIG back to a known public key).  If the CERT is signed
by some other (non-DNS) entitiy that the client trusts, it should not have
to rely on DNSSEC to support the other protocol (SSH, IPSec, or whatever).

Similar to the subject, I know Ed's draft on a "generic" protocol number was
up for discussion, but we didn't get to it at the London meeting.  A generic
protocol number and the use of a SRV-like naming scheme could help the KEY
issue, but is not really necessary for CERT (in my opinion).  Is the idea of
a "Generic" protocol code number for a KEY something people still want?

Scott

> On Thursday, August 30, 2001, Dan wrote:

> For example, I don't administer the isi.edu zone and I would not have
access
> to the isi.edu private key.  But I do administer the machine muddy.isi.edu
> and the isi.edu zone administrators are not authorized to set or change
muddy's
> SSH key.  I also have access to a certification authority I'll call CA#1.
> I claim I'm better off if my SSH key is in a CERT instead of a KEY.
>
> The muddy.isi.edu SSH key is stored in CERT, signed by CA#1.  This
> CERT record is entered in the zone by the isi.edu DNS administrators
> and signed with the isi.edu key.  The same rules that would have allowed
> the isi.edu administrators to enter the muddy KEY apply to entering the
> muddy CERT (plus the isi.edu administrator SHOULD also check try to
validate
> the CERT rr data before signing it)
>
> Your resolver uses standard DNSSEC resolver techniques to get and verify
> the muddy.isi.edu CERT record.  You may not know anything about the
> certification authority used in the CERT record (or perhaps it is just
> a self-signed record if no CA was available to sign) so your ssh client
> has to decide whether to trust the potentail muddy key based on only the
> SIG from isi.edu.  In other words, you are back where you would have been
> if it was just a KEY record.
>
> But other people know the muddy ssh key should be signed by CA#1.  These
> people get the benefit of DNSSEC (ie isi.edu zone administrators says
> this is the right ssh key) and they also get the benefit of CA#1.  For
> these clients, I have two layers of defense on my SSH key since a forgery
> has to compromise both CA#1 and the isi.edu zone.  For the other clients
> who don't know about CA#1, they are no worse off than they would have been
> with just a KEY.
>
> Dan