[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: Edward Lewis <lewis@tislabs.com>
Cc: Simon Josefsson <simon+dnssec@josefsson.org>, <dnssec@cafax.se>
From: Derek Atkins <warlord@MIT.EDU>
Date: 04 Sep 2001 17:45:05 -0400
In-Reply-To: Edward Lewis's message of "Tue, 4 Sep 2001 17:02:03 -0400"
Sender: owner-dnssec@cafax.se
Subject: Re: CERTificates and public keys

Edward Lewis <lewis@tislabs.com> writes:

> At 4:22 PM -0400 9/4/01, Simon Josefsson wrote:
> >I'm suggesting to let SSH put a raw public key in a CERT record, using
> >a "SSH" Certificate type.
> 
> Then it is up to the SSH community to define a SSH certificate format and a
> PKI to generate and support it.  (This doesn't necessarily mean cut code -
> they could say "X509" and have someone run a world-wide trusted CA in
> Finland to sign  certificates.)  Then they'd be open to using the CERT
> record.

No, they could say "NONE" and have the CERT record maintain raw keys
in an ssh-specific manner.  It works just as well.

> I don't think a raw public key signed by someone else quite qualifies as a
> certificate, at least not one sufficient to be stored in a CERT RR.  (IMHO.)

And I think this is where we differ.  I don't see 'CERT' as requiring
any particular 'Certificate' format.  Nor do I believe that the key
data held within a CERT record needs any self-certifying information.
The CERT record key data is just a blob of bits that the application
uses.  If the application thinks it's X.509, fine.  If the application
thinks it's a raw key, that's fine too.  The CERT RR shouldn't care.

All the CERT RR needs to provide is for the application to know the
key was meant for it.

> Why not?  What's wrong with burning another RR number.  Applications need
> only handle one or the other.

It's the "one or the other" that's the problem.  We should CHOOSE ONE.
There is NO REASON for two RRs.  Key data is key data, regardless of
the format surrounding it.  Different applications require the key
data in different formats.  Fine.  You have a tag so that applications
can know the format (and then use or discard the RR based on that
tag).

> I think the APPKEY is needed to add data the CERT assumes is in the
> certificate.  For one, I can see the CERT being omitted from the signed
> portion of a zone (see opt-in) and the APPKEY always includede in the
> signed portion.

I have no qualms if APPKEY usurps CERT, but in the end, we need one
and ONLY one application-level key-data resource record.  And this
resource record, whether APPKEY, CERT, or something else, should
handle both raw keys as well as 'self-certifying' keys (ala X.509 and
PGP).

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available

Home | Date list | Subject list