Following my recent post about the availability of the new Microsoft Card Module API and Base Smart Card Crypto Provider, I went digging for documentation about the pilot deployment of that technology.  I found a good whitepaper here.

I can't resist making a couple of comments about it, though :)  For one thing, the author includes a bit of a digression about digital certificates and attempts to make an analogy to drivers' licenses.  Apologies in advance that I include the whole paragraph for reference, but it's so ripe for commentary.

"Note: Digital certificates, similar to identification cards, are an
encrypted set of electronic authentication credentials that are used to
certify the online identities of individuals, organizations, and
computers.  Certificates are issued and certified by certification
authorities (CAs).  Like driver's licenses, digital certificates are
issued by CAs to provide proof for verifying the identity of online
entities.  However, instead of containing a photograph and the signature
of the owner of the certificate, a digital certificate contains
information that identifies the certificate's owner on the network and the
owner's public key, binding the two elements together.  Furthermore, a
certificate identifies the CA (called the issuer) that issued the
certificate, and this CA must be authorized within the enterprise, to
issue authentication certificates."

1.  Digital certificates are not generally encrypted.  In fact, Microsoft's PKI depends on the more-or-less 'public' nature of certificates, at least within the scope of a given enterprise.  For example, if I steal your smart card, I can read off the certificates and decipher all information included therein.  But unless I have obtained both your card and your PIN, I can't open up the metaphorical door for which the card and PIN are the key.  So encryption of the certificate won't buy you anything more than broken scenarios.

That said, some enterprises are pushing for inclusion of personally identifiable information (PII) or other more private data in their users' certificates.  Note that this still doesn't imply that the certificates are encrypted.  Still, the private data push is interesting, and it certainly places new and different burdens on the applications in which certificates have been used.  For example, digital certificates are sometimes used to bootstrap key agreement protocols.  How can two parties confidently exchange certificates over an untrusted link if the certificates contain PII?

2.  Back to the whitepaper ... I don't think the author intended to imply that drivers licenses are issued by Certification Authorities.  I would prefer to state that drivers licenses are issued by "Licensing Authorities" (e.g. the Department of Motor Vehicles).

3.  Contrary to the second-to-last sentence, certificates may in fact contain, or at least refer to, a photograph and/or signature of the owner.  See this RFC.

One final comment on the whitepaper brings me back to the original point:  the following snippet is a testament to the quality of the new smart card interface and CSP (which are indeed publicly available, contrary to what is stated later in the paper).

"The benefits the card management team derived from using a CSP developed
by Microsoft were that it was small, very secure, efficient, fast, very
reliable, and offered clear end-user error messaging.  In short, its
performance met all Microsoft IT requirements for its clients."