Re: draft-ietf-secsh-x509

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

Heikki Nousiainen wrote:
> Hello Joseph, Oskari,
>
> I was talking with Oskari today about the draft on X.509 certificates 
> and figured I might as well write my thoughts down on e-mail.

Thanks... I've cc'd the mailing list on this so we can get
more input.

> I recall there was an issue about signature schemes used in X.509 specs 
> on the IETF SecSh list a long time ago (alas, I can't find any of the 
> e-mails). IIRC, It was noted that locking a method for specific hash 
> scheme might be problematic as not all hardware tokens can do multiple 
> schemes. This issue is pretty much moot as virtually any token out there 
> does signatures over SHA1, which is used in the X.509 spec as well. 
> However, it might be a problem in future, if local policy, say NIST in 
> FIPS, would mandate use of SHA256 instead of SHA1. Now, x509v3-sign and 
> PKCS#7 can handle all kinds of imaginable signatures, but there's no way 
> of communicating capabilities or policy variables of either the client 
> or the server to the other end.
>
> Consider the following: client has a token that can do SHA1 and SHA256, 
> server only allows SHA256 by local policy. Client first signs over SHA1, 
> which is refused by server. Client has no way of knowing what went 
> wrong, should it now re-try with SHA256 or skip that certificate?

Yes... I know this is a problem.

> In the spirit of the rest of the protocol, I'd suggest naming the
> methods along the lines 'x509-sign-dss-sha1' and
> 'x509-sign-rsa-sha1-pkcs1.5' to remove that ambiguity.

Unfortunately, this doesn't help for userauth as the server
never sends a list of publickey algorithms it is willing
to accept for userauth.

And in the hostkey case, we just really can't solve
the problem adequately, and I've been kind of reluctant
to introduce the ugliness for a inadequate solution.

Consider a certificate chain that uses mixed algorithms;
the leaf certificate user DSA w/ SHA1, an intermediate
certificate doing RSA w/ MD5 and a root certificate doing
RSA w/ SHA256.

Such algorithm requirements can't be expressed in the
SSH protocol-- well, not reasonably anyway.

We could do something like make the algorithm name:

x509v3-sign-{algo-hash-method}-{algo-hash-method}-...-{algo-hash-method}

where the first {algo-hash-method} was for the leaf certificate,
and the last was for the root certificate.  But if I remember
correctly, the algorithm list in total must be less that
255 characters... so I can easily imagine us running short
of space here.

For hostkeys, I think the only solution is for admins to make
sure that their certificate chains are compatilble with the
servers and clients in use-- I don't think we can really
solve this problem (without a prohibitive amount of work.)

For the user auth request, I suppose we could define a new
message:

     byte      SSH_MSG_USERAUTH_SIGN_ALGORITHM_UNSUPPORTED
     string    hash[0..n]

where hash[0..n] is a list of algorithm oids of hashes which
can be used with the server.  The server MUST send this
message if the algorithms used in the pkcs7 signature are
not acceptable, regardless of whether the signature is
correct or incorrect.  The server SHOULD NOT count the
attempt as a authentication attempt.

I'm mildly against such a proposal, but I could live with it.
I'm not sure if it would need to be more complex; are there more
algorithms than the hash which need to be negotiated?

Thanks,

Joseph