Re: OpenSSH certified keys

[Nicolas Williams <Nicolas.Williams%sun.com@localhost>]

On Wed, Mar 17, 2010 at 04:19:28AM +1100, Damien Miller wrote:
> OpenSSH 5.4p1 introduced a novel, lightweight certificate format for
> user and host keys. These were designed to reuse SSH wire-encoding and
> signature primitives to minimise the additional attack surface exposed
> pre-auth. In particular, we are not comfortable with the complexity
> (syntactically or sematically) of X.509.
> 
> Here is the document from the OpenSSH source distribution that describes
> them (PROTOCOL.certkeys). If there is interested from other implementors
> in interoperating with these certificates then I'm willing to write this
> up as an I-D.

On the one hand I think a simpler PKI than PKIX is always appealing.  On
the other hand I think that any simpler-than-PKIX PKI spec had better
get some things right, foremost, I think, is the OCSP model of
revocation instead of CRLs.

OCSP is often used in this manner: the user agent gets an OCSP Response
for its cert then presents both to relying parties.  I like to think of
OCSP as a ticketing system not too unlike Kerberos.  You start with a
long-term key pair and certificate issued by a long-term CA, present it
to an "online CA" that issues short-term certificates attesting that
long-term ones are still valid, and then you use both certs to
authenticate to relying parties.

It's also useful, I think, to state all trade-offs explicitly.  For
example, a certificate might not bear anything like subject and subject
alternative names or other data useful for authorization, leaving RPs to
handle authorization entirely on their own.  Or a certs might not bear
names or other such data but a directory might be used to lookup such
things using a cert (issuer&serial, whatever) as a lookup key.  In the
latter case there's a requirement for online infrastructure, much as in
the case of OCSP, Kerberos, ...  But even a PKI with CRLs requires
online infrastructure for CRL distribution.

Nico
--