Re: OpenSSH certified keys

["denis bider \(Bitvise\)" <ietf-ssh2%denisbider.com@localhost>]

I second Nicolas's concern. Your spec doesn't even mention revocation. 
How is revocation handled? Are the keys expected to be certified only 
for a very short term?

If certification is expected to be for only a very short term, are you 
putting an infrastructure in place that allows a client to obtain a 
fresh certificate before it connects?

If you are putting such infrastructure in place, do you have a spec for 
how the client obtains the fresh certificate?

Otherwise, if you are planning for these certificates to be long-term, 
what is your solution for revocation?


----- Original Message ----- 
From: "Nicolas Williams" <Nicolas.Williams%sun.com@localhost>
To: "Damien Miller" <djm%mindrot.org@localhost>
Cc: <ietf-ssh%NetBSD.org@localhost>
Sent: Tuesday, March 16, 2010 14:55
Subject: Re: OpenSSH certified keys


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
--