Re: CERTificates and public keys

[Dan Massey <masseyd@isi.edu>]

On Thursday, August 30, 2001 at 01:42PM, Ed Lewis wrote:
| 
| So, Wes and I would like to hear comments on why certificates would be an
| improvement upon public keys when managing infrastructure keying material -
| e.g., host keys for SSH, IPsec, etc.
| 

Certificates would be an improvement because they offer some additional
flexibility and potential ties to other PKIs.  In addition, it helps avoid 
several keys at the apex/large key set problems.  Since other proposed 
solutions like DS and naming schemes at least partly address the keys at 
apex/large key problem and have been discussed before, I'll toss out the 
additional flexibility idea....

With the KEY option, you are assuming that whoever has access to the
foo.bar private zone key is also authorized to determine the SSH/IPSEC/etc
key for machine.foo.bar.   With the CERT option, some applications could
do a little better and in the worst case all applications would be no worse 
off.

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