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

[Bill Sommerfeld <sommerfeld%sun.com@localhost>]

On Thu, 2005-03-24 at 12:08, Joseph Galbraith wrote:

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

if the relying party is set up to require CRL's, bits don't move.

> Or does even the empty revocation list have to be signed in some
> fashion? 

Correct.

> And if so, what if the root certificate is revoked?  Or 
> is that even possible?

CRL's are signed and have validity periods; they must be periodically
reissued.
If you're doing CRL checking and the peer hands you a stale CRL, you
reject it.

> And if so, what if the root certificate is revoked?  Or 
> is that even possible?

It's not.

> Adding language to explicitly state that we refuse to carry
> such information in the SSH protocol and that it must be
> out-of-band is pretty easy (and wimpy, but I'm a first class
> wimp.)

This is probably the right way to go for now.  

Note that in the firewall-traversal case you can reduce information
leaks through a published CRL by having a distinct CA for the access
points which is *not* the CA for your users or your internal servers,
and by having your remote clients configured to trust the
access-point-CA directly.

The firewall-traversal server can presumably talk to the internal PKI
infrastructure for validating the client certificates.

and if you only have one access point, you don't need to be using X.509
for the access points.

								- Bill