Re: draft-igoe-secsh-x509v3-00

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

On Tue, Dec 15, 2009 at 12:10:19PM +1000, Douglas Stebila wrote:
> And some points for further discussion:
> 
> 6) Extended key usage key purpose IDs.  I must confess to being a bit
> confused about this one.  In the original X.509 in SSH draft, you say
> that SSH implementations SHOULD NOT use extended key usage extensions,
> but then go on to provide some anyway.  Can you help me understand
> what appears to be a contradiction?  Would we need to get new OIDs or
> could we reuse the ones from the previous document?

The document should (must!, IMO) define an EKU for ssh.  For the rest,
the EKU rules in RFC5280 should suffice.  This is all about ensuring
that there's a way to create certificates that can only be used for
specific protocols, as opposed "any protocol".  Administrators need not
actually require use certs with EKUs if they don't want to, but they
must have the option to.

> 7) Certificate revocation list / OCSP responses.  You've suggested
> including CRL or OCSP data alongside the certificate chain for
> efficiency purposes.  I'm not a PKI expert either, so I'd like to hear
> more feedback, especially from implementers, on whether this would be
> of interest to them.  I know that SunSSH's support for X.509 has some
> consideration of CRL/OCSP, so maybe Jan can comment on what he thinks
> of including that data with the cert chain or handling it outside of
> the protocol.

First, SunSSH does not support x.509 yet.

Second, I *strongly* recommend that both, the client and server be able
to send OCSP responses for their own certs to the other, and that
servers be able to send OCSP responses for the client's certs back to
the client.  This has a number of major benefits:

 - OCSP scales much better than CRLs, and while OCSP can be used by the
   relying party...

 - ...having each party send OCSP responses for its cert (and cert
   chain) to the other is an optimization:

    - reduces latency (the relying party need not go find OCSP
      responders, resolve them, and send requests to them; clients can
      cache OCSP responses and thus reduce the amount of time spent
      talking to online infrastructure);

    - reduces OCSP responder load;

    - puts the onus for caching OCSP responses on the client's
      shoulders.

   Think of cert+OCSP_response as being like a Kerberos ticket.  The
   server will not have to use any online infrastructure in order to
   authenticate the client.  (It's better than a Kerberos ticket: the
   x.509 client can use the same credential to authenticate to many
   servers, whereas the Kerberos client has to talk to online
   infrastructure at least once for every server it wishes to
   authenticate to.)

 - If a client cannot reach OCSP responders or does not support OCSP
   directly, the server can still send it OCSP responses for the
   client's certs so that the client can be responsible for caching and
   subsequently send those responses to other servers.

In fact, I can't imagine new PKIX applications not supporting use of
OCSP in these ways.

The main issue, I think, is not whether to use OCSP but how to know when
a peer needs various large items (cert chains) a priori, whether to
incur extra round-trips to exchange those.

Nico
--