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

[Joseph Galbraith <galb-list%vandyke.com@localhost>]

Bill Sommerfeld wrote:
> On Thu, 2005-03-24 at 02:47, Henrick Hellstr?m wrote:
>
>
> > > 3) text regarding recommendations for certificate revocation checks.
> > >
> > > 4) discussion of how to handle certificate chains.
> >
> > These two points are already covered by PKIX documents. I don't think 
> > there are any secsh specific considerations here.
>
>
> There's at least one:  we should either provide an in-band way to carry
> cert chains, CRL's, OCSP, etc., or explicitly declare that such traffic
> must flow out-of-band.

Well... hmmm...

Now, I'll admit, I'm not an PKI expert (I'm an SSH expert which is why
you got a document describing how to encode x.509 into the SSH protocol 
:-)  So perhaps this is naive...

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?

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'm afraid my x.509 knowledge is sufficient to call someone elses
(Microsoft's) API and let them deal with all of this stuff.

> A use case which came up in pki4ipsec: a firewalled enclave with its pki
> infrastructure inside it, with <insert protocol name here> as the only
> way in. 

Unfortunately, this may be a more common use case in SSH than
in ipsec because of it's adhoc nature.  In particular, this use
case applies to me!  (I suspect it is not unusual for SSH to be
the only thing going through a firewall.)

I can imagine extending the format to be

string name ("x509v3-sign-rsa2", "x509v3-sign-dss2" or "x509v3-sign")
string der-encoded certificate
string der-encode crl list
string certs-in-chain[0..n]

I'm mildly reluctant to do so, since the sender has no way
to probe whether the (potentially volumous) data is needed
by the peer or not.  If we have to worry about securing
the CRL list and the certificate chain, I begin to get more
than just mildly reluctant.

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

Thanks,

Joseph