Re: Comments on draft-ietf-secsh-x509-00

[pgut001%cs.auckland.ac.nz@localhost (Peter Gutmann)]

Joseph Galbraith <galb-list%vandyke.com@localhost> writes:

>But, can we really safely carry the data?  Let's say the client is trying to
>authenticate using a revoked certificate.  If we allow the client to send us
>the revocation list, doesn't the bad guy just not send anything?

The assumption is that you always have to send some sort of CRL, if there's
nothing revoked then you send an empty one.  This weird requirement is an
unfortunate side-effect of the blacklist-based checking used in X.509, if it
was done properly with a liveness proof this wouldn't be an issue.

>Or does even the empty revocation list have to be signed in some fashion?
>And if so, what if the root certificate is revoked?  Or is that even
>possible? Or is securing the CRL during transit from a untrusted source stuff
>we have to specify as part of specifying a way to carry CRLs in the SSH
>protocol?

I would just ignore all this, allow the server to send a cert or cert chain
and leave the rest to the user.  Otherwise you have to deal with cached CRLs,
fetched CRLs, OCSP, out-of-band checks, etc etc etc.  Then you have to decide
what you want to do with delta CRLs (do you send the last full CRL and all
deltas, the latest delta, ... )?.  This is a complete mess, and given that the
interest in use of X.509 certs in SSH to date has been within epsilon of
absolute zero, it's just not worth bothering with.  Tell 'em they can include
certs/cert chains and leave it at that.

Peter.