Currently we do smart card authentication using SSH's normal public key authentication, but keeping the private key on the smart card. This is not how smart cards are meant to be used as it completely ignores the certificate.
The "correct" way is to use a PKI scheme. In that scheme, the client sends over the certificate instead of the user name and authenticates by proving it has the matching private key (i.e. the same way SSH's public key auth. works). The server must then figure out which user the certificate maps to, and that the certificate is valid for this server.
The validity is done by verifying the issuer (CA) signature on the certificate. The server must have a list of issuer keys it trusts. It usually also checks with some central database that the certificate hasn't been revoked.
Mapping to a user is implementation defined. Microsoft requires the certificate to include the user name, and Novell stores the mapping in eDirectory.
OpenSSH doesn't currently have any support for PKI. There is a hackish patch floating around, but it is very crude and doesn't use public interfaces like PKCS#11, so it is not suited for our needs. We would most likely have to implement everything ourselves.
To aid us, Mozilla's NSS library contains all the certificate handling we need. It can check signatures, revocation lists and all such menial tasks. There is also a draft RFC for how the PKI handshake should be done over SSH. It is an expired draft, but it is still better than inventing something new ourselves.
http://roumenpetrov.info/openssh/ might be useful.
Time est. is just a wild guess. This project has too many unknowns to make a proper estimate.
We also need to replace Putty with OpenSSH as it would be really wasteful making this gigantic effort on both implementations.
This effort has now been resurrected at the IETF and it seems to be very close to be properly standardised:
It's now a formal RFC!
Somewhat related, red hat is pushing a patch to be able to put authorized_keys in more dynamic places: