Re: CERTificates and public keys

[Edward Lewis <lewis@tislabs.com>]

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.

>In my mind, this isn't even abusing [my understanding of] the
>intention of the CERT record, a raw public key somehow signed by
>someone else (be it DNSSEC, TSIG or whatever) _is_ a certificate and
>thus OK to store in a CERT RR.

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 even if this is abusing the intention of the CERT record, I don't
>see any technical arguments against this.

I think that this woule be opening up the scope of the CERT RR too wide for
reasonable use in an application.  For one, if an application wanted to be
able to handle any kind of CERT RR, if would need an ASN.1 parser to handle
X509's. Shudder.

>Using APPKEY would work equally fine to me, but having both CERT and
>APPKEY for similar purposes is not good.

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

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.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: lewis@tislabs.com

You fly too often when ... the airport taxi is on speed-dial.

Opinions expressed are property of my evil twin, not my employer.