Re: CERTificates and public keys

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

I don't know if it's the best idea to use the CERT record for a "catch-all"
application key record.  If there is another supporting infrastructure to it
(like a non-DNSSEC signature), than it could be encoded into a CERT record.
If the application is relying on DNS to provide the data/origin
authentication, then a KEY (or APPKEY?  or some other method) should be
used.

In my opinion, a CERT record should be used if some other signing entity
(CA, etc) is used.  If the application does not have a signature from any
other source, DNSSEC could be used to provide a "lightweight" authentication
system - a SIG record accompanying the KEY record.  CERT records can then be
used/authenticated without the use of DNSSEC, if it's an encoded certificate
and not just a public key.

I hope that makes sense.  in other words:  if out of band signing is used
and the application is expecting a key and signature, then CERT should be
used.  If the application is only looking for a key and is not expecting a
supporting signature, the KEY record (or APPKEY, if approved) should be used
and verified using DNSSEC.

Scott

----- Original Message -----
From: "Dan Massey" <masseyd@isi.edu>
To: <dnssec@cafax.se>
Sent: Tuesday, September 04, 2001 9:57 AM
Subject: Re: CERTificates and public keys


> On Friday, August 31, 2001 at 05:45PM, Ed Lewis wrote:
> | First, this thread got a bit larger than it needed - there is (should
be)
> | little debate about the relative flexibility of public key structures
and
> | certificate structures (obviously because a public key is an important
> | ingrediant of a certificate).  There is also no reason to argue that DNS
> | (with or without DNSSEC) is in any way a PKI.
> |
> | The original question was whether or not certificates made sense in
> | applications - and the one Wes and I had in mind was SSH (as a starter).
> | SSH has no current certificate processing code in it - that can be
easily
> | overcome.  What is problematic is the lack of a PKI to produce
certificates
> | for SSH - and the lack of a defined means of chaining trust through
"SSH"
> | certificates.
> |
>
> I think the original question was whether the an SSH key should be stored
in
> the DNS as a CERT or KEY record.  My answer to this is that application
keys
> belong in the CERT record.
>
> I don't think anyone was suggesting that you define a seperate SSH PKI or
a
> means of chaining through SSH certificates.  In fact, I would argue for
the
> opposite.  Any SSH PKI is clearly outside the scope of DNSSEC and the
resolver
> should not be involved in certificate chaining in any way.
>
> You just want to make sure that:
>
>   1. you store the keys in the way that makes the most sense for the
resolver.
>      CERT record in my opinion.  you don't gain any security by using a
>      KEY and the drawback is that the KEY record ends up holding both
>      application and infrastructure data.
>   2. you don't prevent other people from building an SSH PKI
>      if an SSH certificate or PKI is created, would the SSH key then be
>      stored in both a CERT and a KEY??
>
> | My sense of this thread is that the debate of "public key versus
> | certificate" is one that cannot be generalized.  The issue is an
> | application-by-application problem.  I guess a future mental exercise is
to
> | design a "PKI" (and I don't mean reimplement OpenSSL) infrastructure for
> | SSH.  (This would be off-topic for this list.)
> |
>
> Perhaps instead of asking to reserve type 22 from the KEY record, why not
> reserve type 4 of the CERT record and use this for "Generic Public Key".
> You could then store your ssh key in this record.
>
> Dan