Re: CERTificates and public keys

[Dan Massey <masseyd@isi.edu>]

On Thursday, August 30, 2001 at 04:20PM, Ed Lewis wrote:
| At 3:29 PM -0400 8/30/01, Simon Josefsson wrote:
| >I do not think I understood the first paragraph (what do you mean by
| >there being no CA backing the CERT record?  I agree with the
| >statement, but I do not see why it matters), but here are my
| >top-of-the-head reasons for preferring certificates in CERT over
| >public keys in KEY.
| 
| Assuming a certificate is not self-signed, the signature attached to the
| certificate is generated by another entity.  The idea being that I, as a
| user of a certificate, can start with the public key of a CA (whether as a
| key or an assumed certificate), and chain through a set of certificates to
| ascertain the goodness of the certificate in question.  Once that is
| accomplished I can "trust" that the name in the certificate (and ancillary
| data) is bound to any data with a signature that is verified by the
| certificate's public key.
| 

But this chaining through certificate authorities isn't something you 
want the resolver to do, is it?  The resolver should just verify the
record.  The resolver shouldn't care whether the record type is A, PRT, 
CERT, TXT, or whatever.  

| The problem that Wes and I discussed involved entering an SSH host key into
| a certificate.  Who signs the certificate?  Would it be self-signed?  Would
| it be signed by the administrator of the machine?  Would it be signed by a
| site-wide adminitistrator?  Ultimately, how would I, as an arbitrary user
| come to trust the SSH key certificate - in a way that is less cumbersome
| than configuring the public key in my client?
| 

The internal signatures in the CERT record are any of the above.  It could
be self-signed, signed by some admin, etc, etc.   Let the ssh administrator
decide that.  

The resolver can trust the data contained in CERT was signed by the zone's 
private key.  Nothing more and nothing less.  If that trust isn't enough 
for your ssh client to believe the key information, then calling it a
KEY instead of a CERT isn't going to help you.

After the resolver does its work, an ssh client (not resolver) should 
try to validate the certificate data using some outside CA if it has them.  
If it can do this, great.  If it can't, then just tell the user that the 
DNS chain of trust is the only thing authenticating this potential key.  
What did you lose vs a KEY record?

| If we use the KEY RR, and I already have a public key for the root zone,
| then I could just follow the DNS hierarchy (assuming a completed tree).
| For a fragmented tree, I just need the enclosing island of trust's key.
| 

You still do this for the CERT.  If you can use the signature inside the 
CERT then good.  If not, you still have that same DNS trust.

| I am aware of the benefits of a CERT (more fields, hence more information)
| over a KEY, but that assumes there is a supporting infrastructure.  KEY
| already has one - the DNS itself, but what is behind the CERT?
| 
| >
| >* 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.
| >
| 
| Without CA's, there applications aren't better off than DNS.
| 
But no worse off either.

| >* DNSSEC only guarantee origin authentication.
| >
| >  This is probably too weak for some applications. I want to trust
| >  that a public key belong to a certain host or person.  Only being
| >  able to trust the origin of the information is weaker.  Putting a
| >  SSH KEY RR in DNS doesn't authenticate that key as belonging to the
| >  host (which is what you want) but rather that you trust that the
| >  public key came from a certain origin.  Maybe this is subtle and can
| >  be ignored for SSH or IPSEC (where you could assume that if it came
| >  from the domain where the machine lives in you trust it as belonging
| >  to the host). But I wouldn't trust a key for S/MIME or PGP purposes
| >  based only on the fact that I know where the key came from (how do I
| >  know they checked the identity of the user before signing his public
| >  key?).
| 
| If SRV naming is used, then the key can be tied to a host via the domain
| name, which is covered by the SIG RR.  For identity of folks, there is a
| email-address convention defined (replace the @ with .).
| 

Still doesn't help my muddy.isi.edu example...

| >
| >* Key revocation.
| >
| >  Keys used by several applications have different requirements than
| >  DNSSEC KEY's, several applications need revocation functionality.
| 
| This is true, KEY can't do that but CERT can.
| 
| >* 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.)
| 
| What are the predefined set of CA's?  That's what isn't obvious.
| 
| What applications are you referring to?  Netscape is shipped with
| certificates signed by Verisign.  I don't know of an SSH that uses
| certificates.
| 

But same applies to your approach.  There is no signed root so what are 
the predefined trusted DNS keys?  Each scheme starts with some trusted
starting points, it could be zone keys or CAs.  Why not let it be both
if that doesn't hurt either one?

For your particular ssh implementation to use CERTs instead of KEYs, 
your implementation just says like "Something like no trusted CA's to 
verfiy   certificate data.  Do you want to trust the key data based on 
DNSSEC?" I don't see where you lose...  

Dan